¿Java JIT hace trampa al ejecutar el código JDK?

Estaba evaluando un código y no pude hacer que se ejecutara tan rápido como con java.math.BigInteger, incluso cuando se usa exactamente el mismo algoritmo. así que copié java.math.BigInteger source en mi propio paquete e intenté esto:

//import java.math.BigInteger;

public class MultiplyTest {
    public static void main(String[] args) {
        Random r = new Random(1);
        long tm = 0, count = 0,result=0;
        for (int i = 0; i < 400000; i++) {
            int s1 = 400, s2 = 400;
            BigInteger a = new BigInteger(s1 * 8, r), b = new BigInteger(s2 * 8, r);
            long tm1 = System.nanoTime();
            BigInteger c = a.multiply(b);
            if (i > 100000) {
                tm += System.nanoTime() - tm1;
                count++;
            }
            result+=c.bitLength();
        }
        System.out.println((tm / count) + "nsec/mul");
        System.out.println(result); 
    }
}

Cuando ejecuto esto (jdk 1.8.0_144-b01 en MacOS) sale:

12089nsec/mul
2559044166

Cuando lo ejecuto con la línea de importación sin comentar:

4098nsec/mul
2559044166

Es casi tres veces más rápido cuando se usa la versión JDK de BigInteger en comparación con mi versión, incluso si usa exactamente el mismo código.

Examiné el código de bytes con javap y comparé la salida del compilador cuando se ejecuta con opciones:

-Xbatch -XX:-TieredCompilation -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions 
-XX:+PrintInlining -XX:CICompilerCount=1

y ambas versiones parecen generar el mismo código. Entonces, ¿el punto de acceso está usando algunas optimizaciones precalculadas que no puedo usar en mi código? Siempre entendí que no. ¿Qué explica esta diferencia?

Sí, HotSpot JVM es una especie de “trampa”, porque tiene una versión especial de algunos BigInteger métodos que no encontrará en código Java. Estos métodos se llaman Intrínsecos de JVM.

En particular, BigInteger.multiplyToLen es un método intrínseco en HotSpot. hay un especial implementación de ensamblaje codificado a mano en base fuente JVM, pero solo para arquitectura x86-64.

Puede deshabilitar este intrínseco con -XX:-UseMultiplyToLenIntrinsic opción para obligar a JVM a usar la implementación de Java pura. En este caso, el rendimiento será similar al rendimiento de su código copiado.

PD Aquí hay un lista de otros métodos intrínsecos de HotSpot.

En Java 8 este es de hecho un método intrínseco; una versión ligeramente modificada del método:

 private static BigInteger test() {

    Random r = new Random(1);
    BigInteger c = null;
    for (int i = 0; i < 400000; i++) {
        int s1 = 400, s2 = 400;
        BigInteger a = new BigInteger(s1 * 8, r), b = new BigInteger(s2 * 8, r);
        c = a.multiply(b);
    }
    return c;
}

Ejecutando esto con:

 java -XX:+UnlockDiagnosticVMOptions  
      -XX:+PrintInlining 
      -XX:+PrintIntrinsics 
      -XX:CICompilerCount=2 
      -XX:+PrintCompilation   
       <YourClassName>

Esto imprimirá muchas líneas y una de ellas será:

 java.math.BigInteger::multiplyToLen (216 bytes)   (intrinsic)

En Java 9 por otro lado, ese método parece ya no ser intrínseco, pero a su vez llama a un método que es intrínseco:

 @HotSpotIntrinsicCandidate
 private static int[] implMultiplyToLen

Entonces, ejecutar el mismo código en Java 9 (con los mismos parámetros) revelará:

java.math.BigInteger::implMultiplyToLen (216 bytes)   (intrinsic)

Debajo está el mismo código para el método, solo un nombre ligeramente diferente.