Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

252
Vistas
JMH usando java 17, sin eliminación de código muerto

Ejecuto el punto de referencia JHM de muestra que se supone que muestra la eliminación del código muerto. El código se reescribió para que sea conciso de jhm github sample .

 import org.openjdk.jmh.annotations.*; import java.util.concurrent.TimeUnit; @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(1) public class Sample08DeadCode { private double x = Math.PI; @Benchmark public void benchmark() {} @Benchmark public void measureIncorrect() { Math.log(x); } @Benchmark public double measureCorrect() { return Math.log(x); } }

Ejecutar usando JDK 1.8.0_211, Java HotSpot(TM) 64-Bit Server VM, 25.211-b12 produce los siguientes resultados:

 Benchmark Mode Cnt Score Error Units Sample08DeadCode.benchmark avgt 5 0,229 ± 0,018 ns/op Sample08DeadCode.measureCorrect avgt 5 12,013 ± 0,047 ns/op Sample08DeadCode.measureIncorrect avgt 5 0,228 ± 0,016 ns/op

pero al usar java JDK 17.0.2, Java HotSpot(TM) 64-Bit Server VM, 17.0.2+8-LTS-86, los resultados no muestran signos de eliminación de código inactivo:

 Benchmark Mode Cnt Score Error Units Sample08DeadCode.benchmark avgt 5 0,341 ± 0,004 ns/op Sample08DeadCode.measureCorrect avgt 5 6,244 ± 0,072 ns/op Sample08DeadCode.measureIncorrect avgt 5 6,263 ± 0,094 ns/op

¿Por qué el método measureIncorrect() no está optimizado con Java 17?

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Esas muestras dependen de los componentes internos de JDK.

Parece que desde JDK 9 y JDK-8152907 , Math.log ya no está intrínseco en la representación intermedia C2. En su lugar, se realiza una llamada directa a un stub rápido respaldado por LIBM. Esto suele ser más rápido para el código que realmente usa el resultado. Fíjese en cómo measureCorrect es más rápido en la salida de JDK 17 en su caso.

Pero para las muestras de JMH, limita las optimizaciones del compilador alrededor de Math.log , y las muestras de código muerto/plegado no funcionan correctamente. Se soluciona para crear muestras que no dependan de los componentes internos de JDK sin una buena razón y, en su lugar, utilicen una carga útil escrita personalizada.

Esto se está haciendo en JMH aquí:

  • https://bugs.openjdk.java.net/browse/CODETOOLS-7903094
  • https://github.com/openjdk/jmh/pull/60
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda