Angenommen, ich habe diesen Code (es ist wirklich egal, denke ich, aber nur für den Fall, dass es hier ist):
%Vor%Und hier ist, wie ich es anrufe (mit Java-9):
%Vor%Was ich herausfinden möchte, ist, welche Methoden durch den intrinsischen Code ersetzt wurden. Der erste, der getroffen wird (innerhalb Unsafe):
%Vor%Und diese Methode ist tatsächlich in der Ausgabe des obigen Aufrufs vorhanden:
%Vor%Aber die gesamte Ausgabe ist seltsam (für mich):
%Vor%Warum ist getAndAddInt in der Ausgabe zweimal vorhanden?
Auch wenn getAndAddInt tatsächlich durch einen intrinsischen Aufruf ersetzt wird, warum muss alle anderen intrinsischen Methoden im Call-Stack ersetzt werden? l sie werden nicht mehr verwendet. Ich nehme an, es ist so einfach, wie der Stapel von Methodenaufrufen von unten durchlaufen wird.
Um die Compiler-Logik zu veranschaulichen, habe ich JVM mit den folgenden Argumenten ausgeführt.
%Vor%Und das ist es, was es druckt.
%Vor%AtomicInteger.getAndAdd
wird nicht nur aus Ihrem Code, sondern auch aus dem allgemeinen JDK-Code aufgerufen. AtomicInteger.getAndAdd
erreicht den Aufrufschwellenwert etwas früher als Ihr AtomicJDK9.atomicIncrement
. Dann wird getAndAdd
an die Kompilierungswarteschlange übergeben, und von dort kommt der erste intrinsische Ausdruck. AtomicInteger.getAndAdd
interpretiert wird, erreichen die Methoden Unsafe.getAndAddInt
und Unsafe.weakCompareAndSwapIntVolatile
auch den Aufrufschwellenwert und beginnen mit der Kompilierung. Die nächsten 3 intrinsics werden beim Kompilieren dieser Unsafe
-Methoden gedruckt. AtomicJDK9.atomicIncrement
auch Aufruf-Threashold und beginnt mit der Kompilierung. Der letzte intrinsische Ausdruck entspricht Ihrer Methode. Tags und Links java virtual-machine jvm java-9 jvm-arguments