JMH - JIT por qué no elimina mi muerta de código

byebye:

Escribí dos puntos de referencia para demostrar que JIT puede ser un problema con el punto de referencia de escritura fina (por favor pase que yo utilizo doesnt @State aquí):

@Fork(value = 1)
@Warmup(iterations = 2, time = 10)
@Measurement(iterations = 3, time = 2)
@BenchmarkMode(Mode.AverageTime)
public class DeadCodeTraps {

    @Benchmark
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public static void summaryStatistics_standardDeviationForFourNumbers() {
        final SummaryStatistics summaryStatistics = new SummaryStatistics();
        summaryStatistics.addValue(10.0);
        summaryStatistics.addValue(20.0);
        summaryStatistics.addValue(30.0);
        summaryStatistics.addValue(40.0);
        summaryStatistics.getStandardDeviation();
    }

    @Benchmark
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public static void summaryStatistics_standardDeviationForTenNumbers() {
        final SummaryStatistics summaryStatistics = new SummaryStatistics();
        summaryStatistics.addValue(10.0);
        summaryStatistics.addValue(20.0);
        summaryStatistics.addValue(30.0);
        summaryStatistics.addValue(40.0);
        summaryStatistics.addValue(50.0);
        summaryStatistics.addValue(60.0);
        summaryStatistics.addValue(70.0);
        summaryStatistics.addValue(80.0);
        summaryStatistics.addValue(90.0);
        summaryStatistics.addValue(100.0);
        summaryStatistics.getStandardDeviation();
    }

}

Pensé que JIT eliminará código muerto, por lo que dos métodos serán ejecutadas al mismo tiempo. Pero al final, tengo:

summaryStatistics_standardDeviationForFourNumbers 0,158 ± 0,046 0,359 ± 0,294 DeadCodeTraps.summaryStatistics_standardDeviationForTenNumbers

¿Por JIT no optimizarlo? El resultado de summaryStatistics.getStandardDeviation();no es ni utilizados fuera del método y no es devuelto por él.

(Estoy usando OpenJDK acumulación 10.0.2 + 13-Ubuntu-1ubuntu0.18.04.4)

rustyx:

Si estamos hablando acerca de la Apache Commons Matemáticas SummaryStatisticsclase, entonces es una clase masiva. Su construcción será sin duda no ser inline. Para ver por qué, correr con-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:-BackgroundCompilation

eliminación de código muerto sucede después de inline. objetos no utilizados se propagan respaldo, pero el constructor no-inline se romperá la cadena porque el optimizador de JIT ya no puede estar seguro de que no hay efectos secundarios.

En otras palabras, el código que espera ser eliminado es demasiado grande.