Les optimisations JIT de Hotspot pour les exceptions de lancement rapide conduisent-elles à des résultats ambigus?

Question

This question traite des cas où le compilateur JIT détermine qu'il ne générera plus de stacktraces s'il estime qu'il l'a fait un certain nombre de fois auparavant. Je comprends que ce soit connu sous le nom de "jet rapide" ou "pré-alloué" des exceptions. En règle générale, si l'on devait rencontrer une telle exception préallouée, la piletrace manquante devrait être trouvée au moins une fois à un moment donné de la vie de la JVM, avant que JIT ne l'ait jugé digne de compilation. Ma question est de savoir si le mappage d'une occurrence signalée d'une exception préallouée à au moins une instance d'une exception antérieure peut être garanti déterministe, et sinon, est-il possible d'éviter que cela soit une source de ambiguïté à moins de désactiver l'optimisation en utilisant -XX: -OmitStackTraceInFastThrow.

Un exemple simpliste:

L'exception raccourci/préaffecté qui obtient rapporté est quelque chose générique tel que NullPointerException. S'il n'y avait qu'un seul type de stacktrace avec un NPE dans la première vie de la JVM, alors pas de problème. Mais que se passerait-il s'il y avait déjà plus d'un NPE à partir de différents points du code? La JVM ne donne aucune indication sur les piles précédentes ou sur celles qui en ont été compilées, alors comment pouvez-vous déterminer de manière déterministe ce que la pile aurait été autrement?

Cette situation peut-elle réellement se produire, ou le Hotspot JIT moderne est-il assez intelligent pour éviter de créer une telle ambiguïté?

Answer 1

La JVM elle-même n'essaie pas de mapper cette exception préallouée à une exception précédemment levée. En tant que développeur, vous pouvez essayer de deviner d'où viennent ces exceptions préallouées, mais il n'y a aucune garantie.

Si vous essayez de déboguer quelque chose et de voir des exceptions sans stacktrace, le plus sûr est de désactiver l'optimisation en utilisant -XX:-OmitStackTraceInFastThrow pendant que vous essayez de trouver la source du problème.