March 2016 - core-libs-dev

JDK 9 RFR of JDK-8152873: java/util/Locale/LocaleProviders.sh fails on several platforms
by Amy Lu 29 Mar '16

29 Mar '16

java/util/Locale/LocaleProviders.sh starts failing after JDK-8150432, there's simple issue in JDK-8150432. Please review this quick fix. bug: https://bugs.openjdk.java.net/browse/JDK-8152873 webrev: http://cr.openjdk.java.net/~amlu/8152873/webrev.00/ Thanks, Amy --- old/test/java/util/Locale/LocaleProviders.sh 2016-03-29 10:15:10.000000000 +0800 +++ new/test/java/util/Locale/LocaleProviders.sh 2016-03-29 10:15:10.000000000 +0800 @@ -25,7 +25,7 @@ # @test # @bug 6336885 7196799 7197573 7198834 8000245 8000615 8001440 8008577 # 8010666 8013086 8013233 8013903 8015960 8028771 8054482 8062006 - 8150432 +# 8150432 # @summary tests for "java.locale.providers" system property # @modules java.base/sun.util.locale # java.base/sun.util.locale.provider

2 1

RFR: 8152733: Avoid creating Manifest when checking for Multi-Release attribute
by Claes Redestad 28 Mar '16

28 Mar '16

Hi, the integration of the multi-release jar feature[1] caused a number of startup regressions, the primary cause of which was determined to be due to parsing manifests into java.util.jar.Manifest only to check for the Multi-Release attribute. This can be avoided by reusing the logic already in place to check for the Class-Path attribute. Bug: https://bugs.openjdk.java.net/browse/JDK-8152733 Webrev: http://cr.openjdk.java.net/~redestad/8152733/webrev.01/ Some additional cleanup was done in this joint effort: Paul suggested a few improvements/cleanups to the search code, two anonymous classes to check settings could be removed, and - even though JarFile doesn't provide any thread-safety guarantees - the checkForSpecialAttributes method can be made thread-safe with a synchronized block at little to no cost. Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8132734

4 8

Re: RFR(M): 8152172: PPC64: Support AES intrinsics
by Vladimir Kozlov 28 Mar '16

28 Mar '16

This question is for core libs. For JIT to generate optimal code we want to change type of AESCrypt::sessionK from Object[] to int[][]. Otherwise JIT have to generate checkcast code to make sure that elements of sessionK array are int[]. I see that sessionK field is private so we are not changing public API. Thanks, Vladimir On 3/24/16 6:17 PM, Hiroshi H Horii wrote: > Hi Vladimir, > > Thank you for your reviewing. > > Is it possible to modify the type of sessionK from Object[] to int[][]? > > We can guess, the type was designed for flexibility. However, only int[] is used > to store elements of sessionK, so far. In addition, this field is private. > Though adding checkcast is another solution, it produces overheads. > > I attached an additional patch (generated with hg diff -g) to jdk directory. > I would like to ask thoughts about this change of java code. > > > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, > IBM Research - Tokyo > > > Vladimir Kozlov <vladimir.kozlov(a)oracle.com> wrote on 03/24/2016 09:09:11: > > > From: Vladimir Kozlov <vladimir.kozlov(a)oracle.com> > > To: Hiroshi H Horii/Japan/IBM@IBMJP, "hotspot-compiler- > > dev(a)openjdk.java.net" <hotspot-compiler-dev(a)openjdk.java.net> > > Cc: "Doerr, Martin" <martin.doerr(a)sap.com>, Tim Ellison > > <Tim_Ellison(a)uk.ibm.com>, "Simonis, Volker" <volker.simonis(a)sap.com> > > Date: 03/24/2016 09:19 > > Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics > > > > I think we need to add gen_checkcast for objAESCryptKey node since > > java code has no guarantee that sessionK array elements are > > initialized with int[]. Or we should modify java code to declare sessionK > > as int[][]. > > > > Thanks, > > Vladimir > > > > Note, intrinsics are correctly handle case when > > On 3/22/16 8:47 AM, Hiroshi H Horii wrote: > > > Dear all: > > > > > > Can I please request reviews for the following change? > > > This change was created for JDK 9 to enable POWER8's AES > > > instructions for AES calculation. > > > > > > This request follows this discussion. > > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- > > March/021926.html > > > > > > Description: > > > This change adds stub routines support for single-block AES > > > encryption and decryption operations on the POWER8 platform. > > > They are available only when the application is configured to > > > use SunJCE crypto provider on little endian. > > > > > > These stubs make use of efficient hardware AES instructions > > > and thus offer significant performance improvements over > > > JITed code on POWER8 as on x86 and SPARC. AES stub routines > > > are enabled by default on POWER8 platforms that support AES > > > instructions (vcipher). They can be explicitly enabled or > > > disabled on the command-line using UseAES and > > > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher > > > and vnchiper of POWER8 need the same round keys of AES. > > > Therefore, inline_aescrypt_Block in library_call.cpp calls the > > > stub with AESCrypt.sessionK[0] as round keys. > > > > > > Summary of source code changes: > > > > > > *src/cpu/ppc/vm/assembler_ppc.hpp > > > *src/cpu/ppc/vm/assembler_ppc.inline.hpp > > > - Adds support for vrld instruction to rotate vector register values > > > with left doubleword. > > > > > > *src/cpu/ppc/vm/stubGenerator_ppc.cpp > > > - Defines stubs for single-block AES encryption and decryption > > > routines supporting all key sizes (128, 192 and 256-bit). > > > - Current POWER AES decryption instructions are not compatible > > > with SunJCE expanded decryption key format. Thus decryption > > > stubs read the expanded encryption keys (sessionK[0]) with > > > descendant order. > > > - Encryption stubs use SunJCE expanded encryption key as their > > > is no incompatibility issue between POWER8 AES encryption > > > instructions and SunJCE expanded encryption keys. > > > > > > *src/cpu/ppc/vm/vm_version_ppc.cpp > > > - Detects AES capabilities of the underlying CPU by using > > > has_vcipher(). > > > - Enables UseAES and UseAESIntrinsics flags if the underlying > > > CPU supports AES instructions and neither of them is explicitly > > > disabled on the command-line. Generate warning message if > > > either of these flags are enabled on the command-line > > > whereas the underlying CPU does not support AES instructions. > > > > > > *src/share/vm/opto/library_call.cpp > > > - Passes the first input parameter, reference to sessionK[0] to the > > > AES stubs only on the POWER platform. > > > > > > *src/share/vm/opto/graphKit.cpp > > > - Supports T_NARROWOOP type for GraphKit::load_array_element. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 > > > Webrev: http://cr.openjdk.java.net/~mdoerr/8152172_ppc64le_aes/webrev.00/ > > > > > > > > > Regards, > > > Hiroshi > > > ----------------------- > > > Hiroshi Horii, > > > IBM Research - Tokyo > > > > > >

2 1

[DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection
by KUBOTA Yuji 28 Mar '16

28 Mar '16

Hi all, Could someone please review and sponsor this fix ? I write the details of this issue again. Please review it. =Problem= Potential infinite waiting at TCPChannel#createConnection. This method flushes the DataOutputStream without the socket timeout settings when choose stream protocol [1]. If connection lost or the destination server do not return response during the flush, this method wait forever because the timeout settings is set the default value of SO_TIMEOUT, i.e., infinite. [1]: http://hg.openjdk.java.net/jdk9/dev/jdk/file/7adef1c3afd5/src/java.rmi/shar… I think this issue is rarely, however serious. =Reproduce= I write a test program to reproduce. You can reproduce by the below. * hg clone http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/ * cd fixLoopAtJMXConnectorFactory; mvn package * setting "stop_time" at debugcontrol.properties if you need. * java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar debugcontrol.DebugController This program keep to wait at TCPChannel#createConnection due to this issue. After "debugcontroltest.stop_time" ms, this program release the waiting by sending quit to jdb which is stopping the destination server. Finally, return 2. =Solution= Set timeout by using property-configured value: sun.rmi.transport.tcp.responseTimeout. My patch is below. http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi… If you run the test program with modified JDK9 by my patch, the test program will get java.net.SocketTimeoutException after the connection timeout happen, then return 0. Thanks, Yuji. 2016-01-13 23:31 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: > Hi all, > > Can somebody please review and sponsor this fix ? > > Thanks, > Yuji > > 2016-01-05 17:56 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: >> Hi Jaroslav and core-libs-dev, >> >> Thank Jaroslav for your kindness! >> >> For core-libs-dev members, links the information about this issue. >> >> * details of problem >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html >> >> * patch >> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi… >> >> * testcase for reproduce >> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi… >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018… >> >> Could you please review these reports? >> Hope this patch helps to community. >> >> Thanks, >> Yuji >> >> 2016-01-04 23:51 GMT+09:00 Jaroslav Bachorik <jaroslav.bachorik(a)oracle.com>: >>> Hi Yuji, >>> >>> On 4.1.2016 15:14, KUBOTA Yuji wrote: >>>> >>>> Hi all, >>>> >>>> Could you please review this patch? >>> >>> >>> Sorry for the long delay. Shanliang has not been present for some time and >>> probably this slipped the attention of the others. >>> >>> However, core-libs mailing list might be more appropriate place to review >>> this change since you are dealing with s.r.t.t.TCPChannel >>> (http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi…) >>> >>> Regards, >>> >>> -JB-

2 5

Re: [8u-dev] Request for approval: 8150704: XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees
by Aleksej Efimov 26 Mar '16

26 Mar '16

Hi Rob, Sure! Adding corelibs-dev and Joe (JDK9 reviewer). Hi Joe, Can you, please, review the backported changes: The source fix is identical (except file paths), but regression test changes differs. Best Regards, Aleksej On 03/25/2016 06:07 PM, Rob McKenna wrote: > Hi Aleksej, > > I'd like to see a review of the 8 change before approval. > > -Rob > > On 25/03/16 03:06, Aleksej Efimov wrote: >> Hi, >> >> Please, approve the backport of JDK-8150704 to JDK8. JAXP classes source fix >> applies cleanly after reshuffling. >> The only discrepancy is the test changes: >> In JDK9 the issue was tested by extending the functionality of existing JDK9 >> test: jaxp/javax/xml/jaxp/unittest/transform/TransformerTest.java >> Current test and test suite is absent in JDK8 and the added test case was >> backported to JDK8 as a standalone test application: >> jdk/test/javax/xml/jaxp/transform/8150704 - JDK8 webrev is provided. >> Also the cleanup changes of test code wasn't backported because tests are >> absent in JDK8. >> >> JTREG/JCK testing shows no failures with backported changes. >> >> Best Regards, >> Aleksej >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8150704 >> >> JDK8 webrev: >> http://cr.openjdk.java.net/~aefimov/8150704/8/00/ >> >> JDK9 changeset: >> http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0fe7231b64a6 >> >> JDK9 Review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039272.html

2 1

JDK 9 Build 111 still has ManagementFactory problems, but only on Linux - not on Windows
by Uwe Schindler 26 Mar '16

26 Mar '16

Hi Alan, I have installed build 111 of JDK 9 (which now includes Jigsaw - cool and thanks) on the Jenkins Server, but the (packaging) problems with ManagementFactory's SPIs seems to persist. Interestingly only on Linux (.tar.gz), but not on Windows builds (.exe). https://bugs.openjdk.java.net/browse/JDK-8152161 Is there a quick way via command line flag to disable the extra beans which are not found? I'd really like to test build 111. Uwe ----- Uwe Schindler uschindler(a)apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman@oracle.com] > Sent: Friday, March 18, 2016 10:43 AM > To: Uwe Schindler <uschindler(a)apache.org> > Cc: 'Rory O'Donnell' <rory.odonnell(a)oracle.com>; 'Core-Libs-Dev' <core-libs- > dev(a)openjdk.java.net> > Subject: Re: JDK 9 build 109 -> Lucene's Ant build works again; still missing > Hotspot patches > > > On 17/03/2016 18:39, Uwe Schindler wrote: > > Hi, > > > > JDK-9 build 109 works, build 110 does not work. This is *not* about Jigsaw, > just the standard JDK build. > > I have the feeling this is just a packaging bug. The META-INF/services file in > question contains a class that is missing in the jimage. > > > Just catching up on this thread. > > The EA builds on java.net don't include a number of Oracle "specials". > These specials integrate as service providers and until now, have > required a sprinkle of fairy dust in the build to create the service > configuration file with the complete list of PlatformMBeanProvider > implementations. The issue is that the build is incorrectly appending a > class name of an implementation that is not in the build. A non-issue > for OpenJDK builds, a non-issue for the builds in Oracle as these > service providers are present. Just an issue for the EA builds, sorry > about that. > > If the module system goes into JDK 9 next week for jdk-9+111 then it > should address this issue. The reason is that the service configuration > files go away, as has the make file recipes to combine things at build > time. If something bad happens and we can't integrate next week then we > can trivially fix the build that is causing the problem. > > Just to add Mandy's comment about com.sun.management being a > supported > API. Yes, it is JDK-specific supported (and documented [1]) API. It is > exported by the jdk.management module when we move to modules (next > week > I hope). > > -Alan > > [1] http://docs.oracle.com/javase/8/docs/jre/api/management/extension/

2 4

RFR: 8073872: Schemagen fails with StackOverflowError if element references containing class
by Aleksej Efimov 25 Mar '16

25 Mar '16

Hi, Please, help to review the fix for JDK-8073872 [1]. In JDK9 this bug was fixed as part of sync with upstream JAXWS project [2]. The changes that fixed stack overflow issue are located in XmlSchemaGenerator class [3]. JDK9 change that needs review is the addition of regression test for this issue: http://cr.openjdk.java.net/~aefimov/8073872/9/00/ I will be requesting JDK8 approval for partially backporting the fix for this bug to 8u-dev. Can I also ask to review the JDK8 changes: http://cr.openjdk.java.net/~aefimov/8073872/8/00/ Both JDK8/9 changes were tested with JCK/JTREG tests and no failures were observed. New test passes with the fix and successfully reproduces reported stack overflow on JDKs without the fix. Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8073872 [2] https://bugs.openjdk.java.net/browse/JDK-8150174 [3] http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/ebff1bd3627a#l3.2

2 4

RFR: 8152436: Add a test to verify that the root logger correctly reports the caller's information
by Daniel Fuchs 25 Mar '16

25 Mar '16

Hi, Please find below a new test that verifies that JDK-8152389 does not occur in JDK 9. bug: 8152436: Add a test to verify that the root logger correctly reports the caller's information https://bugs.openjdk.java.net/browse/JDK-8152436 Issue being verified by the test: https://bugs.openjdk.java.net/browse/JDK-8152389 Webrev (test only): http://cr.openjdk.java.net/~dfuchs/webrev_8152436/webrev.00/ best regards, -- daniel

4 5

RFR: JDK-8031767 Support system or alternative implementations of zlib
by Xueming Shen 25 Mar '16

25 Mar '16

Hi Please help codereview the change to build the jdk9 runtime to use the system zlib on Solaris and Linux platforms by default. Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ Background info: Compression is heavily used in Java based big data/middle-ware applications. There are many products in market today that help compression performance either through software or hardware acceleration and most likely these products support the zlib interface as API, for example Intel's IPP library has a faster version of compression libraries. To configure the Java runtime to use the system zlib would make these acceleration capabilities available to java users through java.util.zip package directly. The jdk already has a build configuration option to build the jdk to use the system zlib via "--with-zlib=system" and the OSX is by default built to use the system zlib. This proposal is to propose to build the jdk to use the system zlib library (the zlib bundled by the underlying Solaris/ Linuxplatforms), instead of the binary built from source code jdk repository (current 1.2.8 from the open source zlib.org) Thanks, Sherman btw, attached is the similar change in the closed repo: autoconf/generated-configure.sh ------------------------------------------------------------- # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1454436146 +DATE_WHEN_GENERATED=1454626552 ############################################################################### # # Initialization / Boot-strapping # ------------------------------------------------------------------------ @@ -58839,14 +58839,14 @@ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for which zlib to use" >&5 $as_echo_n "checking for which zlib to use... " >&6; } - DEFAULT_ZLIB=bundled - if test "x$OPENJDK_TARGET_OS" = xmacosx; then - # On macosx default is system...on others default is bundled DEFAULT_ZLIB=system + if test "x$OPENJDK_TARGET_OS" = xwindows; then + # On windows default is bundled...on others default is system + DEFAULT_ZLIB=bundled fi if test "x${ZLIB_FOUND}" != "xyes"; then # If we don't find any system...set default to bundled DEFAULT_ZLIB=bundled

7 21

RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.
by Daniel Fuchs 25 Mar '16

25 Mar '16

[Resending with a link to the patch] Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8150840 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present. http://cr.openjdk.java.net/~dfuchs/webrev_8150840/webrev.00 This patch also introduces a better separation between the SimpleConsoleLogger (created by the DefaultLoggerFinder when java.logging is not there), and the SurrogateLogger, which emulates the behavior of java.util.logging.Logger when java.logging is present but there is no custom configuration (used to be PlatformLogger.DefaultLoggerProxy). best regards, -- daniel

4 12