June 2018 - core-libs-dev

RFR 8195650 Method references to VarHandle accessors
by Paul Sandoz 25 Jun '18

25 Jun '18

Hi, Please review the following fix to ensure method references to VarHandle signature polymorphic methods are supported at runtime (specifically the method handle to a signature polymorphic method can be loaded from the constant pool): http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195650-varhandle-mref/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195650-varhandle-mref/webrev/> I also added a “belts and braces” test to ensure a constant method handle to MethodHandle::invokeBasic cannot be loaded if outside of the j.l.invoke package. Paul.

4 4

Review Request: JDK-8205623: Replace use of Class::getPackage with Class::getPackageName
by mandy chung 25 Jun '18

25 Jun '18

This patch replaces the use of Class::getPackage with Class::getPackageName in jdk.internal.reflect.ReflectionFactory, sun.util.resources.BreakIteratorResourceBundle, and javax.xml.catalog.CatalogMessages. Class::getPackageName avoids the overhead of constructing Package objects. http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205623/webrev.00/ ReflectionFactory::packageEquals does not specify if the Class object is an array class. In the current implementation it returns true even if the input parameters are both array classes but in two different runtime package. I added an assert instead of retaining the current behavior. Mandy

2 1

RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count
by Roger Riggs 25 Jun '18

25 Jun '18

Please review a test improvement to avoid unexpected file opens/closes during the file channel CleanerTest. The test now follows the pattern of the other java/io/File*/UnreferencedXXXClosesFd tests by waiting for the cleaner and file descriptors to be reclaimed by GC. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/ Thanks, Roger

2 4

RFR: jsr166 integration 2018-06
by Martin Buchholz 25 Jun '18

25 Jun '18

JDK 11 draws nigh. http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.… 8202422: value of 'sizeCtl' in ConcurrentHashMap varies with the constructor called http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/sizeCtl/i… https://bugs.openjdk.java.net/browse/JDK-8202422 8203864: Execution error in Java's Timsort http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/TimSort/i… https://bugs.openjdk.java.net/browse/JDK-8203864 --- We've been unable to reach agreement on 8203662 - it remains in limbo. 8203662: remove increment of modCount from ArrayList and Vector replaceAll() http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAl… https://bugs.openjdk.java.net/browse/JDK-8203662 8203681: Miscellaneous changes imported from jsr166 CVS 2018-06 http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellan… https://bugs.openjdk.java.net/browse/JDK-8203681

4 7

[11]RFR 8196213: sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on ar_SA locale.
by Dora Zhou 25 Jun '18

25 Jun '18

Hello, Please help review the fix for JDK-8196213. Thank you. Set default locale to en-US so that the output display the date using Gregorian Calendar and Latn numbering system(0~9). Bug: https://bugs.openjdk.java.net/browse/JDK-8196213 Webrev: http://cr.openjdk.java.net/~ljiang/8196213/webrev/ <http://cr.openjdk.java.net/%7Eljiang/8196213/webrev/> Regards, Dora

2 1

Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions
by Vladimir Kozlov 25 Jun '18

25 Jun '18

On 6/22/18 3:58 PM, Paul Sandoz wrote: > Hi Smita, > > I am ok with it if Vladimir is :-) One slight concern is this may be biasing towards the x86 implementation of the intrinsic. Looking on code and it will be a lot of changes in Base64.java. I am concern about that late in JDK 11. I think we should keep duplicated code for x86 intrinsic as Smita suggested. And we can return to this when/if we intrinsify Decoder too. > I dunno if an int[] table is as useful for an AARCH64 intrinsic. We should ask RH to check. But I think SPARC is better operating on 32-bit values than 16-bit (at least it was issue before). Vladimir > > Paul. > >> On Jun 22, 2018, at 3:25 PM, Kamath, Smita <smita.kamath(a)intel.com> wrote: >> >> Hi Paul, >> >> I can change the Java arrays(toBase64URL and toBase64) to int[] and use them in the intrinsic if it is acceptable. Please let me know. >> >> Thanks, >> Smita >> >> -----Original Message----- >> From: Paul Sandoz [mailto:paul.sandoz@oracle.com] >> Sent: Friday, June 22, 2018 3:18 PM >> To: Kamath, Smita <smita.kamath(a)intel.com> >> Cc: Vladimir Kozlov <vladimir.kozlov(a)oracle.com>; hotspot compiler <hotspot-compiler-dev(a)openjdk.java.net> >> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions >> >> >> >>> On Jun 22, 2018, at 3:00 PM, Kamath, Smita <smita.kamath(a)intel.com> wrote: >>>> Looks like you changed all need place to implement intrinsic. >>>> One question so: why you have own copy of base64 charsets and not using one in library: >>>> >>>> private int encode0(byte[] src, int off, int end, byte[] dst) { >>>> char[] base64 = isURL ? toBase64URL : toBase64; >>>> >>> >>> Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. >>> Smita>> I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array. >>> >> >> Thanks, I also saw your reply to Vladimir and see why you need this [*]. We could still unify leveraging a Java int[] array at the expense of extra space required on non-intrisified platforms. IMHO the less stub code and the more Java code the better with regards to maintenance. >> >> >>> Naming wise for the Java methods here are some suggestions: >>> >>> generateImplEncode -> encodeBlockWithBoundsCheck implEncode -> >>> encodeBlock >>> >>> Also can generateImplEncode be private? >>> Smita>> I'll make these changes and send an updated webrev. >>> >> >> Ok. >> >> >>> Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks? >>> Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. >>> >> >> Ok. >> >> Thanks, >> Paul. >> >> [*] On AVX-512 it's tempting to explore permute/rearrange operations on bytes, if there are any such instructions, since the translation array of bytes (toBase64URL or toBase64) fits neatly into one z register, or for AVX-2 in two y registers if some masked variant, based on ranges, is possible. >

2 1

Re: <i18n dev> [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
by Dora Zhou 25 Jun '18

25 Jun '18

Hi Naoto, Thanks a lot for the review. I have made suggested changes, Kindly have a look at: http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev.01/> Regards, Dora > From: naoto.sato(a)oracle.com > To: dan.z.zhou(a)oracle.com, i18n-dev(a)openjdk.java.net, core-libs-dev(a)openjdk.java.net, security-dev(a)openjdk.java.net > Sent: Saturday, June 23, 2018 1:23:50 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi > Subject: Re: <i18n dev> [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale > > Hi Dora, > > You could move those two lines that sets the locale to en-US before the > for-loop, so that if "args" contains -J-Duser.language/country then it > can override the default en-US. > > The JIRA issue needs noreg-self label. > > Naoto > > On 6/22/18 1:26 AM, Dora Zhou wrote: >> Hello, >> >> Please help review the fix for JDK-8194152. Thank you. >> >> The test compares output with expected error messages in English, set >> locale to en-US so that the output are not translated into other languages. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194152 >> Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ >> <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev/> >> >> Regards, >> Dora

2 1

RFR JDK-8205090 / JDK-8204930
by Patrick Reinhart 25 Jun '18

25 Jun '18

Hi everybody, The JDK 11 ramp down fase is coming soon and I would like to have that fixed before that. Please review the CSR and the proposed webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8204930/webrev Thanks for your replies and a sponsoring committer -Patrick

3 4

RFR 8202292 : test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java fails with "raw fd count wrong"
by Roger Riggs 25 Jun '18

25 Jun '18

Please review a test improvement to avoid spurious errors caused by concurrent changes in open files during the test. The other existing conditions in the test are sufficient to verify the correct finalize behavior. Some additional diagnostics are added and the tests removed from the problem list. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-count-wrong-8202292/index.html Issue: https://bugs.openjdk.java.net/browse/JDK-8202292 Thanks, Roger

4 7

free(): corrupted unsorted chunks
by Oliver Kohll 25 Jun '18

25 Jun '18

Hi, I'm a Java developer getting a crash and error message 'free(): corrupted unsorted chunks' in the log. this sounds like it could be a low level issue in the core Java libraries so I'm posting here, but if it would be better in another list (or even a different community) please let me know. So I'm requesting help because I don't know how to debug this further. In summary, the issue is We're getting a crash nearly once a day on our production system, at a time of day when it's most busy (mid morning). This crash hasn't been seen on our development environment, which is the same apart from the server has less memory and CPU resources. The environment is: * A VPS host * Ubuntu LTS 18 (Bionic) * The default Java 10 packaged as 11 I believe ( https://askubuntu.com/questions/1037646/why-is-openjdk-10-packaged-as-openj… ) * However, javac seems to be from JDK8: root@server:~# file /etc/alternatives/java /etc/alternatives/javac /etc/alternatives/java: symbolic link to /usr/lib/jvm/java-11-openjdk-amd64/bin/java /etc/alternatives/javac: symbolic link to /usr/lib/jvm/java-8-openjdk-amd64/bin/javac We're running our webapp on Tomcat 8 (also the Ubuntu default). When this happens, the server stops responding to HTTP requests (in fact the java process has quit) and needs to be restarted. The crash doesn't seem to correspond to a particular activity on the server as far as I can see, though it's hard to tell as many people are logged in at the same time. Does anyone have any pointers of a) how to track the bug further so I can report it, ideally without a big impact on our live server b) more immediately, any workarounds to try In the meantime I will see if I can downgrade to JDK8 on the test server, but I'm not sure if that's possible or whether it would make a difference. Regards Oliver

3 4