Re: Diagnosing performance cliffs on JDK7.
On Aug 20, 2012, at 12:02 PM, "MacGregor, Duncan (GE Energy)" wrote: > While trying to do some minor performance tuning on how we handle multiple > return results I've finally managed to consistently provoke a performance > cliff in our benchmarks. Logging compilation I see that the method in > question is compiled a couple of times and then produces a > > COMPILE SKIPPED: out of nodes before macro expansion (not retry able) What JDK version are you seeing this problem with? -- Chris > > During an OSR, then another compile skipped during a non-use compilation, and > then zombies all the previous compiled versions. > > The benchmark method is attempting to get items from a set of arrays into > local variables, call a method on them, and then put them back into different > arrays, all in a tight loop (hence the OSR replacements). I don't think it's > going megamorphic on me as only three types of objects are involved in the > whole thing, but it performs much better if it is the only benchmark run so > it could be something in our main language infrastructure. > > The method itself is about 500 bytes long. > > The lambda branch of JDK8 doesn't exhibit this problem, though that benchmark > is roughly 3 times slower than on JDK7 (when the performance cliff isn't hit). > > Any tips on narrowing down the cause of this problem? > > Thanks, Duncan. > > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Diagnosing performance cliffs on JDK7.
While trying to do some minor performance tuning on how we handle multiple return results I've finally managed to consistently provoke a performance cliff in our benchmarks. Logging compilation I see that the method in question is compiled a couple of times and then produces a COMPILE SKIPPED: out of nodes before macro expansion (not retry able) During an OSR, then another compile skipped during a non-use compilation, and then zombies all the previous compiled versions. The benchmark method is attempting to get items from a set of arrays into local variables, call a method on them, and then put them back into different arrays, all in a tight loop (hence the OSR replacements). I don't think it's going megamorphic on me as only three types of objects are involved in the whole thing, but it performs much better if it is the only benchmark run so it could be something in our main language infrastructure. The method itself is about 500 bytes long. The lambda branch of JDK8 doesn't exhibit this problem, though that benchmark is roughly 3 times slower than on JDK7 (when the performance cliff isn't hit). Any tips on narrowing down the cause of this problem? Thanks, Duncan. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/langtools: rebase to current hsx/hotspot-comp
Changeset: 2b879840b663 Author:jrose Date: 2012-08-20 09:26 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/2b879840b663 rebase to current hsx/hotspot-comp ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: rebase to current hsx/hotspot-comp
Changeset: 3f168634278e Author:jrose Date: 2012-08-20 09:26 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/3f168634278e rebase to current hsx/hotspot-comp ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp
Changeset: 36e7d0f88e1d Author:jrose Date: 2012-08-20 09:26 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/36e7d0f88e1d rebase to current hsx/hotspot-comp ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
