Comprendre éviter les éliminations Dead-code consequnces

Question

Je lis des exemples JMH et maintenant je suis à la section sur safe-looping. Voici un exemple:

@Benchmark 
public void measureRight_2() { 
    for (int x : xs) { 
     sink(work(x)); 
    } 
} 

@CompilerControl(CompilerControl.Mode.DONT_INLINE) 
public static void sink(int v) { 
    // IT IS VERY IMPORTANT TO MATCH THE SIGNATURE TO AVOID AUTOBOXING. 
    // The method intentionally does nothing. 
} 

Mais ils ont fait une mise en garde à propos de cette technique (souligner la mienne). Parfois, le coût de l'enfoncement de la valeur dans un Blackhole est dominant le score de nano-benchmark. Dans ces cas, on peut essayer de faire un «plomb» de fortune avec une méthode non-inlineable. Cette astuce est très VM spécifique et ne peut être utilisée que si vous vérifiez le produit Code (qui est une bonne stratégie en traitant avec des nano-points de référence de toute façon). Je ne comprends pas très bien ce qu'actallall une VM spécifique ici. Nous utilisons une méthode qui n'est pas censée être inline. Le calcul ne peut donc pas être optimisé. Quel détail ai-je manqué?

Answer 1

Il n'y a aucune garantie que:

1. L'indice no-inline est communiquée correctement JVM;
2. L'indicateur de non-insertion n'est pas délibérément ignoré par JVM;
3. L'indicateur de non-insertion n'est pas accidentellement ignoré par JVM;
4. L'indicateur de non-habillage fonctionne, mais la JVM utilise une optimisation de méthode croisée qui évite de préparer des arguments pour des méthodes vides connues;
5. L'indice de non-linéarité fonctionne, mais la JVM utilise une autre optimisation magique que vous ne pouvez pas trouver en 15 minutes de réflexion;

Cela peut changer de la famille JVM à la famille JVM, ou même dans les versions mineures/correctifs d'une famille JVM donnée. C'est pourquoi on dit qu'il est très spécifique à la VM, et ne doit être utilisé que si vous contrôlez réellement ce qui se passe exactement.