java - technetwork - Regresión del rendimiento al migrar de jdk1.7.0_25 a jdk1.7.0_40

oracle java

Question

Estoy migrando una aplicación por lotes Spring 3.1.2 de jdk1.7.0_25 a jdk1.7.0_40 tanto x64 como por Oracle.

Al utilizar el sistema OperatingSystemMXBean.getProcessCpuTime() Sun como una métrica de rendimiento, los resultados muestran una disminución de 2.5x en el rendimiento (es decir, mi aplicación que se ejecuta en u25 es mucho más rápida).

• Por lo que puedo decir, esto no se debe a los changes java.util.HashMap y java.util.ArrayList changes ya que los resultados son los mismos cuando arranca u40 con las clases HashMap y ArrayList de u25 y estos cambios son simplemente demasiado pequeños para este tipo de diferencia.
• Tampoco está relacionado con la regression concurrencia de HashMap, ya que la aplicación es de un solo hilo y la regresión se fijó en u40.
• Las optimizaciones de hotswap tampoco parecen ser el problema, ya que la ejecución con -Xbatch y -Xcomp produce los mismos resultados (asumiendo que la compilación del servidor es la misma entre estos JDK).
• Hubo una regression rendimiento con respecto a java.lang.invoke.MethodHandles pero eso no parece estar relacionado. A menos que la primavera 3.1.2 haga uso de ellos, de lo cual no pude encontrar evidencia.
• javac compilación de javac parece sin cambios.

Algunas notas generales:

• Este problema aparece en todas las versiones de JDK 7> = u40 (así como en la versión más reciente de JDK 8 jdk1.8.0 ), mientras que las versiones <u40 parecen estar bien (incluidas varias versiones de JDK 6).
• El código Java antiguo (por ejemplo, ejecutar 1000 * 1000 * 1000 * some_calc) no tiene este problema de rendimiento, lo que significa que, de alguna manera, mi código o las bibliotecas usadas están haciendo algo extraño e inesperado.
• Las pruebas se realizaron utilizando la misma instancia de base de datos (MSSQL 2008 R2), pero no importa.
• Incluso si OperatingSystemMXBean no es confiable, el tiempo en la pared de las pruebas es igual de diferente.
• En ambos casos, parece que GC se inicia al mismo tiempo y por las mismas duraciones (he estado usando +UseSerialGC para las pruebas).
• La generación de perfiles no muestra puntos de acceso nuevos inusuales, aunque en general muestra un aumento en el tiempo de ejecución en toda la aplicación.
• Probar las versiones x86 de estos Sun JDKs o OpenJDK (los he usado) no cambia el resultado.
• Todo el código probado (excepto cuando se ejecuta en JDK 6) se compiló utilizando jdk1.7.0_40 .
• El mismo escenario se ha probado en dos computadoras diferentes: x64 y x86.

¿Algún consejo o ideas?

Editado para agregar: la estructura de la aplicación es un bucle externo que ejecuta simulaciones de carlos de monte financiero: es decir, muchas fechas, cálculos, etc. Como tal, actualmente es un poco complejo y, estoy de acuerdo, no es ideal para encontrar el problema. Tendré que intentar reducirlo.

Answer 1

Parece que el problema se debe al trabajo realizado en JDK-7133857 , en el que java.lang.Math.pow() y java.lang.Math.exp() se intrinsificaron y calcularon utilizando x87.

Estos métodos se utilizan ampliamente (!) En la aplicación perfilada y, por lo tanto, su efecto considerable.

JDK-8029302 describe y soluciona el problema para la potencia de 2 entradas; y la prueba de la aplicación con jdk1.8.0_25 (en la que se solucionó el problema) muestra un rendimiento mejorado, aunque no vuelve al nivel más alto de jdk1.7.0_25 antes de que se realizara la intrinsificación.

Aquí están mis puntos de referencia de JMH y sus resultados para Math.pow() en las tres versiones relevantes de JDK:

package org.sample;
import org.openjdk.jmh.annotations.*;
import java.lang.*;
public class MyBenchmark {
@State(Scope.Benchmark)
public static class ThreadState {
volatile double x = 0;
volatile double y = 0;
}
@Benchmark
@BenchmarkMode(Mode.Throughput)
public double powx(ThreadState state) {
state.x++;
state.y += 0.5;
return Math.pow(state.x, state.y);
}
@Benchmark
@BenchmarkMode(Mode.Throughput)
public double pow3(ThreadState state) {
state.x++;
return Math.pow(state.x, 3);
}
@Benchmark
@BenchmarkMode(Mode.Throughput)
public double pow2(ThreadState state) {
state.x++;
return Math.pow(state.x, 2);
}
}

Los resultados:

CPU Intel (R) Core (TM) i5-2520M @ 2.50GHz

jdk1.7.0_25 - antes de la intrinsificación

# VM invoker: x:/@sdks/jdks/jdk1.7.0_25/jre/bin/java.exe
...
Result: 4877658.355 (99.9%) 330460.323 ops/s [Average]
Statistics: (min, avg, max) = (1216417.493, 4877658.355, 6421780.276), stdev = 1399189.700
Confidence interval (99.9%): [4547198.032, 5208118.678]
# Run complete. Total time: 00:24:48
Benchmark Mode Samples Score Score error Units
o.s.MyBenchmark.pow2 thrpt 200 40160618.138 1561135.596 ops/s
o.s.MyBenchmark.pow3 thrpt 200 3678800.153 88678.269 ops/s
o.s.MyBenchmark.powx thrpt 200 4877658.355 330460.323 ops/s

jdk1.7.0_40 - intrinsificación

# VM invoker: x:/@sdks/jdks/jdk1.7.0_40/jre/bin/java.exe
...
Result: 1860849.245 (99.9%) 94303.387 ops/s [Average]
Statistics: (min, avg, max) = (418909.582, 1860849.245, 2379936.035), stdev = 399286.444
Confidence interval (99.9%): [1766545.859, 1955152.632]
# Run complete. Total time: 00:24:48
Benchmark Mode Samples Score Score error Units
o.s.MyBenchmark.pow2 thrpt 200 9619333.987 230749.333 ops/s
o.s.MyBenchmark.pow3 thrpt 200 9240043.369 238456.949 ops/s
o.s.MyBenchmark.powx thrpt 200 1860849.245 94303.387 ops/s

jdk1.8.0_25 - intrinsificación fija

# VM invoker: x:/@sdks/jdks/jdk1.8.0_25/jre/bin/java.exe
...
Result: 1898015.057 (99.9%) 92555.236 ops/s [Average]
Statistics: (min, avg, max) = (649562.297, 1898015.057, 2359474.902), stdev = 391884.665
Confidence interval (99.9%): [1805459.821, 1990570.293]
# Run complete. Total time: 00:24:37
Benchmark Mode Samples Score Score error Units
o.s.MyBenchmark.pow2 thrpt 200 81840274.815 1979190.065 ops/s
o.s.MyBenchmark.pow3 thrpt 200 9441518.686 206612.404 ops/s
o.s.MyBenchmark.powx thrpt 200 1898015.057 92555.236 ops/s

Si estoy leyendo esto correctamente, el problema de la potencia de 2 se solucionó en JDK-8029302 y la potencia de> 2 pulgadas (acabo de probar Math.pow(x, 3) ) el rendimiento se mejoró en jdk1.7.0_40 . En cuanto a la extraña Math.pow()s no int, como se hizo anteriormente en el powx() pruebas powx() , parece que todavía hay una regresión de rendimiento considerable (> 3x) al pasar de jdk1.7.0_25 a jdk1.7.0_40 .

Reemplazar Math.pow() y Math.exp() con sus métodos respectivos en org.apache.commons.math3.util.FastMath resuelve completamente el problema con un aumento en el rendimiento. Esta es la solución correcta en lo que a mí respecta .

Nota: Esto habría sido algo más simple si hubiera una manera fácil (es decir, sin el requisito de -XX:-InlineIntrinsics el JDK) para establecer el -XX:-InlineIntrinsics .