Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

254
Views
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 answers
Answer question

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!