September 2014 - core-libs-dev

Impact of code difference in Collection#contains() worth improving?
by Fabian Lange 08 Sep '14

08 Sep '14

Hi all, I have been involved recently in some theoretical or nonsensical discussions about microbenchmarking, jit compiling assemblies and so fort. One example was LinkedList vs ArrayList. What I noticed is that those two have a different implementation for contains(): ArrayList: public boolean contains(Object o) { return indexOf(o) >= 0; } LinkedList: public boolean contains(Object o) { return indexOf(o) != -1; } Logically this is of course identical due to the contract of contains which returns either -1 or the >=0 index of the element. This code has been like this almost forever, and I was wondering if this actually makes a difference in CPU cycles. And in fact this code compiles into different assembler instructions. The array list does a test against 0 and conditional move, while the linked list does a jump equals on -1. Again that is not surprising, because the actual java source is different. But I wonder if both options are equally good in cold performance and when jitted based on parameter values. Wouldn't one implementation be better than the other? And why is not the "better" implementation taken in both classes (and maybe other Collections which use indexOf) ? Is the answer that this has always been like this and the benefit is not worth the risk of touching ancient code? And if not for performance, would code clarify and similarity be an argument? (this message was posted to jdk8-dev initially, thanks to Dalibor Topic for the pointer to this list) Fabian

10 29

RFR: JDK-8054987: (reflect) Add sharing of annotations between instances of Executable
by Joel Borggren-Franck 08 Sep '14

08 Sep '14

Hi all, Cleaning out the patch queue, I found this small patch that adds sharing of conceptually immutable annotation maps between instances of Executable representing the same executable. In short, Method/Constructor contain one bit of mutable state, if they have been set accessible or not. Core Reflection keeps a 'root' instance of an executable and copies it whenever you call get(Declared){Method|Constructor}. When using an Executable to look at annotations each copy you query for annotations, for exampel m1.getAnnotations(), gets its own LinkedHashMap containing the annotations. The map is then flattned and handed out to the client as a newly allocated array. This patch queries the root method for its map thus sharing annotation instances. It still hands out a unique array for each invocation but the Map and the instances are shared. Webrev: http://cr.openjdk.java.net/~jfranck/8054987/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8054987 cheers /Joel

3 8

JDP broadcaster issue
by Yasumasa Suenaga 08 Sep '14

08 Sep '14

Hi all, I'm trying to use JDP on my Fedora20 machine. My machine has two NICs and only one NIC is up. I passed system properties as below, however JDP broadcaster thread was not started: -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jdp.name=TEST I checked exceptions with jdb, SocketException was occurred in JDPControllerRunner#run(), and it was caused by another NIC is down. Currently, DiagramChannel which is used in JDPBroadcaster tries to send JDP packet through all "UP" NICs. However, NIC which is controlled by NetworkManager seems to be still "UP" when ifdown command is executed. (It seems to be removed IP address from NIC only.) This problem may be Fedora, however I think it should be improved in JDK. I've created a patch as below, and it works fine in my environment. (jdk9/dev/jdk) If this patch may be accepted, I will file this to JBS. -------------------- diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java Mon Sep 01 13:33:28 2014 +0200 +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java Tue Sep 02 23:25:50 2014 +0900 @@ -35,6 +35,7 @@ import java.nio.ByteBuffer; import java.nio.channels.DatagramChannel; import java.nio.channels.UnsupportedAddressTypeException; +import java.util.Enumeration; /** * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net @@ -79,6 +80,15 @@ if (srcAddress != null) { // User requests particular interface to bind to NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress); + + if (interf == null) { + throw new JdpException("Unable to get network interface for " + srcAddress.toString()); + } + + if (!interf.isUp() || !interf.supportsMulticast()) { + throw new JdpException(interf.getName() + " does not support multicast."); + } + try { channel.bind(new InetSocketAddress(srcAddress, 0)); } catch (UnsupportedAddressTypeException ex) { @@ -86,6 +96,23 @@ } channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf); } + else { + Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces(); + while (nics.hasMoreElements()) { + NetworkInterface nic = nics.nextElement(); + + if (nic.isUp() && nic.supportsMulticast()) { + try { + channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic); + } catch (IOException ex) { + System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage()); + } + } + + } + + } + } /** -------------------- Thanks, Yasumasa

4 9

RFR: 8057747: Several test failing after update to tzdata2014g
by Aleksej Efimov 08 Sep '14

08 Sep '14

Hello, There was a problem during tzdata2014g update with JSR310 implementation. It causes reported test failure: jdk/test/sun/util/calendar/zi/TestZoneInfo310.java. The https://bugs.openjdk.java.net/browse/JDK-8051641 bug was filled for this failure, but the test wasn't added to the ProblemList.txt. Please, review the addition of this test to ProblemList.txt: http://cr.openjdk.java.net/~aefimov/8057747/webrev.00 -Aleksej

2 2

RFR: JDK-8057746: Cannot handle JdpException in JMX agent initialization.
by Yasumasa Suenaga 07 Sep '14

07 Sep '14

Hi all, This issue is related to JDK-8057556: JDP should better handle non-active interfaces http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/01… JMX agent will be terminated silently when I run command as following: java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jdp.source_addr=255.255.255.255 -version I expect JdpException which is caused by "com.sun.management.jdp.source_addr" . Curently, sun.management.Agent#startDiscoveryService() throws AgentConfigurationError when JdpException is occurred. However, argument of AgentConfiguratonError constructor is incorrected. So NPE will be occurred. (I checked it with jdb.) I've created webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8057746/webrev.0/ I would like to contribute this patch. Please review and sponsoring. Thanks, Yasumasa

2 2

About JDK-8042694
by Harshad RJ 06 Sep '14

06 Sep '14

Hi, I hit this bug in my own application today: https://bugs.openjdk.java.net/browse/JDK-8042694 My app uses the h2 database which installs a shutdown hook. Works fine, but while running with JNLP, the shutdown hook thrown an exception, probably because the JAR gets closed too early. I can't find a way to register on the JIRA site, hence posting here. I would like to know why was the bug closed as "won't fix"? thanks, -- *Harshad RJ <http://lavadip.com>*

2 2

Re: [9] Review request : JDK-8057707: TEST library enhancement: copy sun.hotspot.whitebox classes from hotspot repo and enhance lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
by Konstantin Shefov 05 Sep '14

05 Sep '14

These test are for core-libs feature, but we want to test that unused lambda forms are garbage collected using WhiteBox.fullGC() method. There are three tests that use one common class, only one of them uses whitebox api. So it is hard to move one of tests to hotspot repo. - Konstantin -------- Исходное сообщение -------- От: Alan Bateman <Alan.Bateman(a)oracle.com> Дата:06.09.2014 0:38 (GMT+04:00) Кому: Konstantin Shefov <konstantin.shefov(a)oracle.com>,"VLADIMIR.X.IVANOV" <vladimir.x.ivanov(a)oracle.com>,core-libs-dev@openjdk.java.net,mlvm-dev@openjdk.java.net Тема: Re: [9] Review request : JDK-8057707: TEST library enhancement: copy sun.hotspot.whitebox classes from hotspot repo and enhance lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java On 05/09/2014 18:57, Konstantin Shefov wrote: > Hello, > > Please review the change in testlibrary > https://bugs.openjdk.java.net/browse/JDK-8057707 > This change is needed for new tests for the feature "Lambda Form > Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703 > > Webrev of the testlibrary change: > http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/ It seems a bit strange, are you sure this is right thing to do? I would have thought that tests using the hotspot whitebox library would be pushed to the hotspot/test tree. -Alan

1 0

RFR (JAXP) 8056202: Xerces Update: Catalog Resolver
by huizhe wang 05 Sep '14

05 Sep '14

Hi, This is an update to Xerces' Catalog Resolver implementation. The changes were mostly performance related, for example the changes to the normalizeURI method in Catalog.java to avoid creating new Strings if the input is already in normalized form. Bug: https://bugs.openjdk.java.net/browse/JDK-8056202 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8056202/webrev/ Thanks, Joe

2 2

[9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles
by Vladimir Ivanov 05 Sep '14

05 Sep '14

http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050173 Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses. Also, some cleanups: * rewrote MH.viewAsType on top of MH.copyWith; * extended MH.viewAsType to do strict checks w/ assertions turned on (new parameter: boolean strict); * extended MT.isViewableAs to accept both interface preserving and interface erasing conversions (new parameter: boolean keepInterfaces). Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

3 4

[9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods
by Vladimir Ivanov 05 Sep '14

05 Sep '14

http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057654 The idea is to separate construction logic and different checks performed before/during method handle construction. For example: move checks from MHs.foldArguments into MHs.foldArgumentChecks. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

5 7