Diagnosing performance cliffs on JDK7.

[MacGregor, Duncan (GE Energy)]

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.