Hi Paul, I've created a tool called JITWatch[1] which might be useful here. It parses the LogCompilation output, shows the source/bytecode/assembly and can highlight inlining failures due to exceeding the thresholds. If you could point me to the code you're having trouble with I'd be happy to run it through the tool and let you know the findings. Kind regards, Chris [1] https://github.com/AdoptOpenJDK/jitwatch On Mon, September 29, 2014 19:03, Vitaly Davidovich wrote:
Bytecode isn't that interesting when discussing peak performance of jit'd code. Do you have assembly dumps?
The only noteworthy aspect of the bytecode is that the enhanced for loop version is slightly bigger, and combined with other code in some method, may inhibit inlining.
Speaking of which, have you tried running the jmh benchmarks with tiered compilation disabled? If not, please do as it may introduce variance/noise.
Sent from my phone On Sep 29, 2014 1:58 PM, "Paul Benedict" <pbenedict@apache.org> wrote:
Bytecode output courtesy of Mikael Ståldal:
With standard loop:
private static boolean contains(org.apache.logging.log4j.Marker, org.apache.logging.log4j.Marker...); Code: 0: iconst_0 1: istore_2 2: aload_1 3: arraylength 4: istore_3 5: iload_2 6: iload_3 7: if_icmpge 29 10: aload_1 11: iload_2 12: aaload 13: astore 4 15: aload 4 17: aload_0 18: if_acmpne 23 21: iconst_1 22: ireturn 23: iinc 2, 1 26: goto 5 29: iconst_0 30: ireturn
With for-each:
private static boolean contains(org.apache.logging.log4j.Marker, org.apache.logging.log4j.Marker...); Code: 0: aload_1 1: astore_2 2: aload_2 3: arraylength 4: istore_3 5: iconst_0 6: istore 4 8: iload 4 10: iload_3 11: if_icmpge 34 14: aload_2 15: iload 4 17: aaload 18: astore 5 20: aload 5 22: aload_0 23: if_acmpne 28 26: iconst_1 27: ireturn 28: iinc 4, 1 31: goto 8 34: iconst_0 35: ireturn
Cheers, Paul
On Mon, Sep 29, 2014 at 11:31 AM, Vitaly Davidovich <vitalyd@gmail.com> wrote:
I think Paul's email already has jmh output.
I looked at the generated asm on 7u60 x64 linux, and didn't see any material difference.
Paul, have you or anyone else looked at the machine code diffs between the two? Looking at timing is useful, but it's possible to get caught up in noise; the generated assembly should provide more conclusive data on whether any real difference is there or not.
On Mon, Sep 29, 2014 at 11:21 AM, Andrew Haley <aph@redhat.com> wrote:
On 09/29/2014 03:29 PM, Paul Benedict wrote:
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.
The actual code that such a forEach loop generates is this:
private int forLoop(final int[] array) { int result = 0; int[] a = array; int len = a.length; for (int i = 0; i < len; i++) { int element = a[i]; result ^= element; } return result; }
If you get different timings for this one, then the measurements are suspect.
Java microbenchmarking is notoriously difficult. Please try to use jmh; you'll get better and easier to interpret results.
Andrew.