September 2014 - core-libs-dev

Fwd: No for each loop comment?
by Paul Benedict 29 Sep '14

29 Sep '14

Open JDKers, I am forwarding an email to get some clarification. It's been a common understanding that foreach should perform no differently than the equivalent for-loop . However, some fellow developers claim there is a noticable difference in their microbenchmarking. Can you help explain what is really going on? It's either the case there is a true difference (a result that would surprise me) or the results are within a margin of error that make the results insignificant. Please advise. Cheers, Paul ---------- Forwarded message ---------- From: Remko Popma <remko.popma(a)gmail.com> Date: Fri, Sep 26, 2014 at 8:43 AM Subject: Re: No for each loop comment? To: Log4J Developers List <log4j-dev(a)logging.apache.org> On Windows it looks like normal for loops are slightly faster than for-each loops, especially for small arrays of primitives. This could be noise, since we are talking about 5 nanoseconds where the baseline (an empty method invocation) is 12 nanos. On Solaris 10 and Red Hat Enterprise Linux the baseline is so large (255 nanos and 1910 nanos respectively) that any difference we are seeing is just noise. All benchmarks were run with one fork, one thread, 10 warmup iterations and 10 test iterations. *Windows 7 (64bit) with Java 1.8.0_05, 2-core Intel i5-3317u CPU @1.70Ghz with hyperthreading switched on (4 virtual cores)* Benchmark Mode Samples Score Score error Units o.a.l.l.p.j.LoopsBenchmark.baseline sample 154947 12.432 0.550 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop sample 126597 2759.592 3.431 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop sample 126494 2761.729 3.127 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop sample 154124 292.880 1.065 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop sample 156155 288.751 1.101 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop sample 191980 41.826 0.870 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop sample 193770 36.894 0.782 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop sample 190847 22.393 0.618 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop sample 192552 17.146 0.560 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop sample 173839 31959.057 14.341 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop sample 171137 32461.985 14.353 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop sample 97495 3591.200 4.852 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop sample 101560 3445.998 4.010 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop sample 102796 438.207 1.923 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop sample 102333 439.576 2.139 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop sample 113924 58.957 1.247 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop sample 120416 60.712 1.284 ns/op // For loops for Object arrays are similar but return the total XOR of the element hashcodes. private int forEachLoop(final int[] array) { int result = 0; for (final int element : array) { result ^= element; } return result; } private int forLoop(final int[] array) { int result = 0; for (int i = 0; i < array.length; i++) { result ^= array[i]; } return result; } *Solaris 10 (64bit) with JDK1.7.0_06-b24 (Oracle Hotspot), 2 quad-core Xeon X5570 dual CPUs @2.93Ghz with hyperthreading switched on (16 virtual cores)* Benchmark Mode Samples Score Score error Units o.a.l.l.p.j.LoopsBenchmark.baseline sample 110212 255.300 0.201 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop sample 187808 3938.055 1.207 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop sample 187897 3937.929 0.748 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop sample 123989 606.631 0.626 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop sample 123973 609.565 0.416 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop sample 126933 294.204 0.280 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop sample 127070 296.411 0.223 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop sample 113400 261.519 0.181 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop sample 111637 260.435 0.115 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop sample 115872 48154.673 18.846 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop sample 116777 47793.868 17.615 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop sample 138432 5256.767 2.451 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop sample 136644 5325.377 2.388 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop sample 166653 773.541 0.330 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop sample 166570 774.513 0.574 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop sample 178754 317.232 0.134 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop sample 180165 316.189 0.238 ns/op *64 bit RHEL 6.5 (Linux 2.6.32-431.el6.x86_64) with JDK1.7.0_05-b06 (Oracle Hotspot), 4 quad-core Xeon X5570 CPUs @2.93GHz with hyperthreading switched on (16 virtual cores)* Benchmark Mode Samples Score Score error Units o.a.l.l.p.j.LoopsBenchmark.baseline sample 114783 1910.576 29.256 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop sample 194584 5132.885 25.137 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop sample 196672 4811.572 52.072 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop sample 133119 1967.213 28.970 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop sample 133804 2004.501 31.554 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop sample 142439 1575.329 6.457 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop sample 142215 1957.714 27.815 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop sample 130826 1980.301 30.818 ns/op o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop sample 132654 1589.120 8.449 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop sample 126947 43301.320 50.589 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop sample 126117 43574.129 55.272 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop sample 143697 5831.250 19.667 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop sample 163244 4823.096 13.180 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop sample 162502 1930.819 24.136 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop sample 171619 1625.806 10.385 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop sample 172226 1888.683 22.554 ns/op o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop sample 188838 1581.979 6.322 ns/op On Fri, Sep 26, 2014 at 2:56 AM, Matt Sicker <boards(a)gmail.com> wrote: > The foreach over an array looks like it's supposed to compile to the same > thing: > > https://jcp.org/aboutJava/communityprocess/jsr/tiger/enhanced-for.html > > Same goes for .length which is supposed to be a final field which would > allow for inlining by the JIT I'd imagine (hence why we use final > everywhere): > > http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.7 > > >>>> On 24 September 2014 22:12, Gary Gregory <garydgregory(a)gmail.com> >>>> wrote: >>>> >>>>> Why does this "//noinspection ForLoopReplaceableByForEach" comment >>>>> mean? >>>>> >>>>> Why not for an enhanced for each loop? >>>>> >>>>> private static boolean contains(final Marker parent, final Marker... >>>>> localParents) { >>>>> //noinspection ForLoopReplaceableByForEach >>>>> for (int i = 0, localParentsLength = localParents.length; >>>>> i < localParentsLength; i++) { >>>>> final Marker marker = localParents[i]; >>>>> if (marker == parent) { >>>>> return true; >>>>> } >>>>> } >>>>> return false; >>>>> } >>>>> >>>>> Thanks, >>>>> Gary >>>>> >>>>> >>>>>

5 8

RFR: 8059269 - FileHandler may throw NPE if pattern is a simple name and the lock file already exists
by Daniel Fuchs 29 Sep '14

29 Sep '14

Hi, Please find below a patch for [1] 8059269: FileHandler may throw NPE if pattern is a simple name and the lock file already exists [1] https://bugs.openjdk.java.net/browse/JDK-8059269 The webrev is here: http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.00 This is a regression which I unfortunately introduced with my patch for JDK-8048020 - and which I stumbled upon while writing another test (which should have failed but didn't). It happens in the uncommon case where: 1. a lock file for the given name pattern already exists, and hasn't been created by another FileHandler in the same VM, and 2. the file name pattern is a simple file name (not composite - that is, it doesn't contain any file separator). In that case, FileHandler will attempt to reuse the existing lock file, but it will first check whether the directory in which the lock file should be created is writable, which it does by calling Files.isWritable(lockFilePath.getParent()). We want to check whether the directory is writable because there's no point in locking the existing lock file if we can't create any new file in that directory. Unfortunately, lockFilePath.getParent() returns null if the file name is simple, and a NullPointerException is thrown. best regards, -- daniel

2 6

RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
by Aleksey Shipilev 25 Sep '14

25 Sep '14

Hi, Can I have a review and a sponsorship for this tiny readability cleanup in String.hashCode()? http://cr.openjdk.java.net/~shade/8058643/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8058643 Thanks, -Aleksey.

7 22

RFR [9]: 8050142: Optimize java.util.Formatter
by Claes Redestad 24 Sep '14

24 Sep '14

Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting String.format. See bug for more details. webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 bug: https://bugs.openjdk.java.net/browse/JDK-8050142 Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), SPECjbb2013 and microbenchmarks Thanks! /Claes

8 32

[9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services
by Miroslav Kos 24 Sep '14

24 Sep '14

Hi everybody, please review patch fixing following issue: JBS: https://bugs.openjdk.java.net/browse/JDK-8038966 webrev: http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/ http://cr.openjdk.java.net/~mkos/8038966/jdk.01/ It is second part of fix ensuring that content of type xsd:any/content=mixed stays unchanged when processed with JAX-B RI. Regression test within webrev. Sean, could you sponsor it for me? Thanks Miran

2 9

How to extract matches from (\d+[hms])+ ?
by Wang Weijun 24 Sep '14

24 Sep '14

Hi Sherman I want to match a time duration like "1h20m30s" and "2h". It looks like if I directly use the pattern "((\\d+)([hms]))+", group(2) and group (3) only return the last match (i.e. 30 and s for 1h20m30s). So I tried multiple matching with "(\\d)([hms])" only, but find() does not always match from the beginning, and lookingAt() does not advance after one call. This is my code now; int start = 0; while (true) { if (!m.find() || m.start() != start) { throw new Exception(); } start = m.end(); print(m.group(1), m.group(2)); if (m.hitEnd()) break; } print("Done"); Is this the correct way? Thanks Max

3 3

JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized
by Brian Burkhalter 23 Sep '14

23 Sep '14

Hello, Another relatively small numerics fix: Issue: https://bugs.openjdk.java.net/browse/JDK-4477961 Webrev: http://cr.openjdk.java.net/~bpb/4477961/webrev.00/ Summary: Change constructs like “a * B / C” and “u / V * W” to “x * (Y / Z)” where lower case denotes a variable and upper case a constant. This forces the constant value (Y / Z) to be evaluated only once per VM instance, and replaces division of the variable with multiplication. The resulting performance improvement is more than 300% as measure by JMH on a MacBookPro11,1 dual core i7 running Mac OS 10.9.5. Thanks, Brian

4 13

RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
by Daniel Fuchs 23 Sep '14

23 Sep '14

Hi, Please find below a proposed patch for 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes https://bugs.openjdk.java.net/browse/JDK-8043306 Proposed Patch: http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/ JDK-8029805 Removed LogManager addPropertyChangeListener and removePropertyChangeListener methods which were deprecated. These methods were deprecated in Java SE 8 and flagged for removal because they were problematic for modularity efforts. The idea was that an application needing to be informed of configuration changes could subclass LogManager and override readConfiguration. The proposed patch adds to new methods to LogManager: public void LogManager.addConfigurationListener(LogManager.ConfigurationListener listener); public void LogManager.removeConfigurationListener(LogManager.ConfigurationListener listener); These methods can be used by those applications for which subclassing LogManager would be too impractical. best regards, -- daniel

7 39

RE: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8
by Salter, Thomas A 23 Sep '14

23 Sep '14

This response confuses me. Are you saying that the UTF8 encoder is not really producing UTF8? RFC 2279 and 3629 both clearly state that surrogates must be combined to form a 32-bit value which is then encoded as a 4-byte sequence. In fact, the RFCs refer to the alternate encoding CESU_8 definition which encodes each half of the surrogate pair as a 3-byte UTF-8 sequence. I guess returning 3.0 for maxBytesPerChar works for the purpose of allocating a big enough byte buffer, but the explanation in this thread is confusing. Tom Salter ------------------------------ Date: Tue, 23 Sep 2014 11:37:07 +0400 From: Ivan Gerasimov <ivan.gerasimov(a)oracle.com> To: Xueming Shen <xueming.shen(a)oracle.com>, Martin Buchholz <martinrb(a)google.com> Cc: nio-dev(a)openjdk.java.net, core-libs-dev <core-libs-dev(a)openjdk.java.net> Subject: Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8 Message-ID: <54212323.5080907(a)oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Martin, Sherman thanks for clarification! Closing the bug as not a bug. > The "character" in the nio Charset and CharDe/Encoder is specified as > "sixteen-bit Unicode > code unit", so it is reasonable to interpret the "character" in the > "maximum number of bytes > that will be produced for each character of input" to be the Java > "char" as well. In case of > UTF8, each 4-byte form supplementary character is always coded into 2 > surrogate chars, > it's "2 byte per char". > Do we have a real escalation that complains about this? > Yes, the link in on the bug page: https://bugs.openjdk.java.net/browse/JDK-8058875 I'm going to try to explain what I've just realized about this function :-) Sincerely yours, Ivan

2 1

java.time.Clock$TickClock wrong javadoc
by Steven Schlansker 23 Sep '14

23 Sep '14

Hi core-libs-dev, Quick note that it seems that the Javadoc for Clock$TickClock has copypasta from Clock$OffsetClock. Not a huge deal for a non-public class but probably worth fixing. http://hg.openjdk.java.net/jdk9/client/jdk/file/5edbebb72540/src/java.base/… /** * Implementation of a clock that adds an offset to an underlying clock. */ static final class OffsetClock extends Clock implements Serializable { /** * Implementation of a clock that adds an offset to an underlying clock. */ static final class TickClock extends Clock implements Serializable {

2 1