July 2016 - core-libs-dev

Re: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests
by Dmitrij Pochepko 04 Aug '16

04 Aug '16

Sure, now including core-libs-dev Thanks, Dmitrij On 29.07.2016 20:16, joe darcy wrote: > Hello, > > I also recommend sending this review request over to core-libs-dev > since it affect the jdk repo. > > Thanks, > > -Joe > > > On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >> Hi Dmitrij, >> >> The change itself looks good. >> >> One note: this change adds a little overhead (a very little) for >> running tests in jdk repository, but it's required only for VM >> specific tests stored in jdk. As alternative of this change I can >> suggest moving VM specific tests from the 'jdk' to 'hotspot' >> repository. Perhaps, such massive update is too late for JDK9 time >> frame and could be done only in JDK10. >> So, if the changes depending on 8162727 are not so critical and could >> be deferred I would prefer to postpone this fix. >> >> Thanks, >> Dima >> >> >> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>> It affects all groups. Should be reviewed on hotspot-dev. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> please review small patch for 8162727 - Testbug: additional >>>> requires properties can't be used for filtering server vm in jdk >>>> jtreg tests >>>> >>>> A problem is that tests under jdk repo can't use additional jtreg >>>> requires properties(like vm.flavor to filter out client or server >>>> vm). The same functionality was introduced for hotspot repo as part >>>> of JDK-8154956. So, in order to filter tests using these additional >>>> properties a small fix is created. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>> >>>> Thanks, >>>> Dmitrij >> >

4 7

Why is there no Math.ceilDiv?
by Philipp Nowak 04 Aug '16

04 Aug '16

Hello, I hope this is the right place to ask this question. If it is not, I would kindly ask you to direct me to the correct place. I was wondering why there is no Math.ceilDiv() method, when a floorDiv() method got added in Java 8 through JDK-8023217 [1]. Is there any reason why such method did not get added with floorDiv(), and, if not, is there any process to request such a method? Best regards, Philipp Nowak [1] https://bugs.openjdk.java.net/browse/JDK-8023217

3 2

RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests
by Frank Yuan 04 Aug '16

04 Aug '16

Hi Would you like to review http://cr.openjdk.java.net/~fyuan/8067170/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8067170 In this change, I enabled security manager for JAXP unit tests with improving the implementation approach and fixing some defects. Now jaxp tests use TestNG annotation to enable security manager and apply policies combination, like the following example(this full example is at: http://cr.openjdk.java.net/~fyuan/8067170/webrev.00/test/javax/xml/jaxp/uni…) @Listeners({ jaxp.library.FilePolicy.class, jaxp.library.InternalAPIPolicy.class }) public class Bug8003147Test { There are also 2 additional patterns for some special cases: 1. JAXPTestUtilities.runWithTmpPermission(Runnable, Permission.) is used for some cases which require their own special permissions, e.g. http://cr.openjdk.java.net/~fyuan/8067170/webrev.00/test/javax/xml/jaxp/uni…. 2. JAXPTestUtilities.tryRunWithPolicyManager(Runnable, Permission.) is used for cases where some test methods need to be run with security manager and some others need to be run without security manager because they have different behaviors when having sm or not. E.g. http://cr.openjdk.java.net/~fyuan/8067170/webrev.00/test/javax/xml/jaxp/uni…. Such cases must run in single thread, all other cases don't require it, are thread safe. Btw, I moved internaltest into unittest because it's unnecessary to separate them. Thanks, Frank

5 27

[8u] request for approval: "8152172: PPC64: Support AES intrinsics"
by Volker Simonis 03 Aug '16

03 Aug '16

Hi, could you please approve the backport of the following, mostly ppc64 change to jdk8u-dev: 8152172: PPC64: Support AES intrinsics Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thre… URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f As you can see, the change consists of two parts - the main one in the hotpsot repo and a small part in the jdk repo. The jdk part applied cleanly to jdk8u (with the usual directory shuffling). The hotspot part required a small tweak, but only in the ppc-only part. This is because the feature detection for the AES instructions was already active in jdk9 when the original change was made but is not available in jdk8u until now. You can find the additional changes at the end of this mail for your convenience. The required shared changes cleanly apply to jdk8u. As Vladimir pointed out in a previous thread, shared Hotspot changes have to go through JPRT even in jdk8u-dev. So I need a sponsor to do that and synchronously push both parts. @Hiroshii: could you please verify that you are fine with the change? I've done some tests on Power8LE but just want to be sure this downport satisfies your needs as well. Thank you and best regards, Volker ===================== diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 @@ -452,6 +476,7 @@ a->popcntw(R7, R5); // code[7] -> popcntw a->fcfids(F3, F4); // code[8] -> fcfids a->vand(VR0, VR0, VR0); // code[9] -> vand + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher a->blr(); // Emit function to set one cache line to zero. Emit function descriptor and get pointer to it. @@ -495,6 +520,7 @@ if (code[feature_cntr++]) features |= popcntw_m; if (code[feature_cntr++]) features |= fcfids_m; if (code[feature_cntr++]) features |= vand_m; + if (code[feature_cntr++]) features |= vcipher_m; // Print the detection code. if (PrintAssembly) { diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 @@ -42,6 +42,7 @@ fcfids, vand, dcba, + vcipher, num_features // last entry to count features }; enum Feature_Flag_Set { @@ -56,6 +57,7 @@ fcfids_m = (1 << fcfids ), vand_m = (1 << vand ), dcba_m = (1 << dcba ), + vcipher_m = (1 << vcipher), all_features_m = -1 }; static int _features; @@ -83,6 +85,7 @@ static bool has_fcfids() { return (_features & fcfids_m) != 0; } static bool has_vand() { return (_features & vand_m) != 0; } static bool has_dcba() { return (_features & dcba_m) != 0; } + static bool has_vcipher() { return (_features & vcipher_m) != 0; } static const char* cpu_features() { return _features_str; }

2 4

RFR: 8162439: Runtime.Version.parse needs fast-path for major versions
by Claes Redestad 01 Aug '16

01 Aug '16

Hi, please review this patch to address a startup regression due to use of Runtime.Version.parse("8") etc in JarFile, as introduced by JDK-8150680. This solution introduce a fast-path in case of what appears to be a single number is sent to Runtime.Version.parse to avoid initializing Runtime.VersionBuilder: Webrev: http://cr.openjdk.java.net/~redestad/8162439/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8162439 Passes all existing tests. Thanks! /Claes

3 6

RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace
by Langer, Christoph 01 Aug '16

01 Aug '16

Hi, please review my change for the XSLT namespace issue. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162598.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8162598 The issue has already been discussed in this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042525.html Apart from the real fix in LiteralElement.java, method translate(), I've done some further cleanups in a few places. @Joe: The cleanups collide with some places of your proposed change for https://bugs.openjdk.java.net/browse/JDK-8158084 where we'd like to do the same things. So we'll have to synchronize on pushing. I've also enhanced the test case "TransformerTest" and added a method which does a regression test for the bug reported. Thanks in advance for reviewing. Best regards Christoph

4 8

java.io.Writer uses CharSequence.toString()
by Fabian Lange 30 Jul '16

30 Jul '16

Hi, this week I learned that java.io.Writer while having append(CharSequence) methods, will invoke toString() on them before actually appending. This is especially sad because after having mad the String, write() will then copy out the chars of the string and then iterate over the chars individually. Something an iteration over chars of the CharSequence could have achieved much better. Fabian

5 7

[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

Change of the toString implementation for annotations
by Rafael Winterhalter 29 Jul '16

29 Jul '16

Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property. When calling toString on an annotation: @interface Foo { Class<?> value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as: @Foo(class Bar) while in Java 9 it is printed as: @Foo(Bar.class) Is this change intended? I do not see a big benefit of this implementation change and it could break code. In my case, the problem is not that big, it is an easy fix but still, I found it a bit surprising. Thank you. Best regards, Rafael

2 4

Files.read/readAllBytes can loop once with zero size buffer
by Fabian Lange 29 Jul '16

29 Jul '16

Hi, I just noticed that when one uses Files.readAllBytes() to read for example from the Linux proc file system, where file size is claimed to be 0, Files.read() will allocate a buffer of size 0 before then adjusting in a second loop (arraycopying the zero size buffer) In my opinion an initial size of 0 should not be used. I admit this might be a regression for files which are really empty and return an empty byte array, but I think it is actually more common to read from files which incorrectly report to be zero sized. Fabian

5 6