March 2016 - core-libs-dev

RFR: jsr166 jdk9 integration wave 5
by Martin Buchholz 03 Mar '16

03 Mar '16

A very boring jsr166 integration, focused on reliability. This one has the promised "even more unnecessarily robust" ThreadLocalRandom. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

3 6

RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method
by Kumar Srinivasan 03 Mar '16

03 Mar '16

Hello Remi, et. al., Webrev: http://cr.openjdk.java.net/~ksrini/8147755/webrev.00/ Can you please approve this patch, it is taken out of ASM's svn repo. change id 1795, which addresses the problem described in [1]. Note 1: A couple of @Deprecated annotations and doc comments have been disabled, because we have a catch-22 that an internal and closed component depends on these APIs, and the replacement is not available until we push this patch. A follow up bug [2] has been filed. Note 2: jprt tested, all core-libs, langtools and nashorn regressions pass. HotSpot team has verified that it address their issues. Thank you Kumar [1] https://bugs.openjdk.java.net/browse/JDK-8147755 [2] https://bugs.openjdk.java.net/browse/JDK-8151056

2 1

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

03 Mar '16

Hi all, Could someone please review this patch? Thanks, Yuji 2016-02-09 15:50 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: > Hi David, > > Thank you for your advice and cc-ing! > > I do not have any role yet, so I paste my patches as below. > > diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > @@ -222,20 +222,34 @@ > // choose protocol (single op if not reusable socket) > if (!conn.isReusable()) { > out.writeByte(TransportConstants.SingleOpProtocol); > } else { > out.writeByte(TransportConstants.StreamProtocol); > + > + int usableSoTimeout = 0; > + try { > + /* > + * If socket factory had set a non-zero timeout on its > + * own, then restore it instead of using the property- > + * configured value. > + */ > + usableSoTimeout = sock.getSoTimeout(); > + if (usableSoTimeout == 0) { > + usableSoTimeout = responseTimeout; > + } > + sock.setSoTimeout(usableSoTimeout); > + } catch (Exception e) { > + // if we fail to set this, ignore and proceed anyway > + } > out.flush(); > > /* > * Set socket read timeout to configured value for JRMP > * connection handshake; this also serves to guard against > * non-JRMP servers that do not respond (see 4322806). > */ > - int originalSoTimeout = 0; > try { > - originalSoTimeout = sock.getSoTimeout(); > sock.setSoTimeout(handshakeTimeout); > } catch (Exception e) { > // if we fail to set this, ignore and proceed anyway > } > > @@ -279,18 +293,11 @@ > * connection. NOTE: this timeout, if configured to a > * finite duration, places an upper bound on the time > * that a remote method call is permitted to execute. > */ > try { > - /* > - * If socket factory had set a non-zero timeout on its > - * own, then restore it instead of using the property- > - * configured value. > - */ > - sock.setSoTimeout((originalSoTimeout != 0 ? > - originalSoTimeout : > - responseTimeout)); > + sock.setSoTimeout(usableSoTimeout); > } catch (Exception e) { > // if we fail to set this, ignore and proceed anyway > } > > out.flush(); > > Thanks, > Yuji > > 2016-02-09 13:11 GMT+09:00 David Holmes <david.holmes(a)oracle.com>: >> Hi Yuji, >> >> Not sure who would look at this so cc'ing net-dev. >> >> Also note that contributions can only be accepted if presented via OpenJKDK >> infrastructure. Links to patches on http://icedtea.classpath.org are not >> acceptable. The patch needs to be included in the email (beware stripped >> attachments) if you can't get it hosted on cr.openjdk.java.net. Sorry. >> >> David >> >> >> On 9/02/2016 12:10 AM, KUBOTA Yuji wrote: >>> >>> Hi all, >>> >>> Could someone review this fix? >>> >>> Thanks, >>> Yuji >>> >>> 2016-02-04 2:27 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: >>>> >>>> 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-

1 0

Custom security policy without replacing files in the OpenJDK?
by Marcus Lagergren 03 Mar '16

03 Mar '16

Hi! Is it possible to override lib/security/local_policy on app level without patching jdk distro? i.e. -Duse.this.policy.jar= … or something? Can’t find a way to do it Regards Marcus

3 2

[8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary
by Ivan Gerasimov 03 Mar '16

03 Mar '16

Hello! I'm seeking for approval to backport this fix into jdk8u-dev. Comparing to Jdk9, the patch had to be changed mainly due to compact string support introduced in jdk9. However, the fix is essentially the same: we just avoid getting too close to Integer.MAX_VALUE when doing reallocations unless explicitly required. Would you please help review it? Bug: https://bugs.openjdk.java.net/browse/JDK-8149330 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/123593aacb48 Jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039018.h… http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039182.html Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8149330/04/webrev/ Sincerely yours, Ivan

3 4

RFR(S): 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' is null, 'step' and 'pred' have parameters
by Michael Haupt 03 Mar '16

03 Mar '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150957 Webrev: http://cr.openjdk.java.net/~mhaupt/8150957/webrev.00/ The bug was actually fixed with the push for JDK-8150635. This change adds a test for the issue. Thanks, 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

2 2

RFR [9] 8151140: Replace use of lambda/method ref in jdk.Version constructor
by Chris Hegarty 03 Mar '16

03 Mar '16

Since 8150163 [1], jdk.Version can now be used earlier in startup, but not always. It was noticed that the use of lambda / method ref in the constructor, in some cases, was the first usage of such, and incurred the initialization costs of the java.lang.invoke infrastructure ( which can take a significant amount of time on first access). The solution is to simple avoid the usage, as has been done in other “core" areas, that may be used early in startup. diff --git a/src/java.base/share/classes/jdk/Version.java b/src/java.base/share/classes/jdk/Version.java --- a/src/java.base/share/classes/jdk/Version.java +++ b/src/java.base/share/classes/jdk/Version.java @@ -28,10 +28,10 @@ import java.math.BigInteger; import java.security.AccessController; import java.security.PrivilegedAction; +import java.util.ArrayList; import java.util.regex.Matcher; import java.util.regex.Pattern; import java.util.stream.Collectors; -import java.util.Arrays; import java.util.Collections; import java.util.List; import java.util.Optional; @@ -208,11 +208,10 @@ + s + "'"); // $VNUM is a dot-separated list of integers of arbitrary length - version - = Collections.unmodifiableList( - Arrays.stream(m.group(VNUM_GROUP).split("\\.")) - .map(Integer::parseInt) - .collect(Collectors.toList())); + List<Integer> list = new ArrayList<>(); + for (String i : m.group(VNUM_GROUP).split("\\.")) + list.add(Integer.parseInt(i)); + version = Collections.unmodifiableList(list); pre = Optional.ofNullable(m.group(PRE_GROUP)); -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8150976

2 1

RFR: 8151123 - Collectors.summingDouble/averagingDouble unnecessarily call mapper twice
by Tagir F. Valeev 03 Mar '16

03 Mar '16

Hello! Please review and sponsor this small change: https://bugs.openjdk.java.net/browse/JDK-8151123 http://cr.openjdk.java.net/~tvaleev/webrev/8151123/r1/ User-supplied mapper function is unnecessarily called twice on each accumulation event in summingDouble and averagingDouble. This function could be computationally intensive which may degrade the performance up to 2x. The patch addresses this issue. Here's also simple JMH benchmark which illustrates the performance gain. http://cr.openjdk.java.net/~tvaleev/webrev/8151123/jmh/ Original: Benchmark (n) Mode Cnt Score Error Units AveragingTest.averageDistance 10 avgt 30 0,571 ± 0,049 us/op AveragingTest.averageDistance 1000 avgt 30 58,573 ± 1,194 us/op AveragingTest.averageDistance 100000 avgt 30 5854,428 ± 71,242 us/op Patched: Benchmark (n) Mode Cnt Score Error Units AveragingTest.averageDistance 10 avgt 30 0,336 ± 0,002 us/op AveragingTest.averageDistance 1000 avgt 30 31,932 ± 0,367 us/op AveragingTest.averageDistance 100000 avgt 30 3794,541 ± 21,599 us/op With best regards, Tagir Valeev.

2 1

RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all
by Thomas Stüfe 03 Mar '16

03 Mar '16

Hi all, please take a look at this proposed fix. The bug: https://bugs.openjdk.java.net/browse/JDK-8150460 The Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webr… Basically, the file descriptor table implemented in linux_close.c may not work for RLIMIT_NO_FILE=infinite or may grow very large (I saw a 50MB table) for high values for RLIMIT_NO_FILE. Please see details in the bug description. The proposed solution is to implement the file descriptor table not as plain array, but as a twodimensional sparse array, which grows on demand. This keeps the memory footprint small and fixes the corner cases described in the bug description. Please note that the implemented solution is kept simple, at the cost of somewhat higher (some kb) memory footprint for low values of RLIMIT_NO_FILE. This can be optimized, if we even think it is worth the trouble. Please also note that the proposed implementation now uses a mutex lock for every call to getFdEntry() - I do not think this matters, as this is all in preparation for an IO system call, which are usually way more expensive than a pthread mutex. But again, this could be optimized. This is an implementation proposal for Linux; the same code found its way to BSD and AIX. Should you approve of this fix, I will modify those files too. Thank you and Kind Regards, Thomas

7 20

JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times
by Amy Lu 03 Mar '16

03 Mar '16

Please review the patch for test tools/jar/JarEntryTime.java In which two issues fixed: 1. Test fails intermittently on checking the extracted files' last-modified-time are the current times. Instead of compare the file last-modified-time with pre-saved time value “now” (which is the time *before* current time, especially in a slow run, the time diff of “now” and current time is possible greater than 2 seconds precision (PRECISION)), test now compares the extracted file’s last-modified-time with newly created file last-modified-time. 2. Test may fail if run during the Daylight Saving Time change. bug: https://bugs.openjdk.java.net/browse/JDK-8038330 webrev: http://cr.openjdk.java.net/~amlu/8038330/webrev.00/ Thanks, Amy

3 5