java PrintCompilation Ausgabe: was ist die Bedeutung von "nicht Teilnehmer" und "made zombie"

Beim ausführen eines Java 1.6 (1.6.0_03-b05) app, die ich Hinzugefügt habe, die -XX:+PrintCompilation Flagge. Auf die Ausgabe für einige Methoden, insbesondere einige von denen, die ich kenne, sind immer aufgerufen, eine Menge, ich sehe den text made not entrant und made zombie.

Was bedeuten diese? Beste Vermutung ist, dass es eine Dekompilierung Schritt vor dem kompilieren entweder Methode oder eine Abhängigkeit mit mehr Optimierung. Ist das wahr? Warum "zombie" und "Teilnehmer"?

Beispiel, mit sehr wenig Zeit zwischen diesen Zeilen:

[... near the beginning]
42       jsr166y.LinkedTransferQueue::xfer (294 bytes)

[... much later]
42    made not entrant  jsr166y.LinkedTransferQueue::xfer (294 bytes)
---   n   sun.misc.Unsafe::compareAndSwapObject
170       jsr166y.LinkedTransferQueue::xfer (294 bytes)
170   made not entrant  jsr166y.LinkedTransferQueue::xfer (294 bytes)
  4%      jsr166y.LinkedTransferQueue::xfer @ 29 (294 bytes)
171       jsr166y.LinkedTransferQueue::xfer (294 bytes)

[... even later]
42    made zombie  jsr166y.LinkedTransferQueue::xfer (294 bytes)
170   made zombie  jsr166y.LinkedTransferQueue::xfer (294 bytes)
171   made not entrant  jsr166y.LinkedTransferQueue::xfer (294 bytes)
172       jsr166y.LinkedTransferQueue::xfer (294 bytes)

[... no further logs]
InformationsquelleAutor Joe Kearney | 2010-05-28
  1. 23

    Habe ich zusammen gezogen, einige Infos über das auf mein blog. Eine Klippe, Klicken Sie auf Kommentar, den ich gefunden, der sagt:

    Zombie-Methoden sind Methoden, deren code wurde ungültig gemacht durch das laden von Klassen. In der Regel die server-compiler macht aggressive inlining Entscheidungen von non-final Methoden. Solange die inline-Methode wird nie überschrieben, der code ist korrekt. Wenn eine Unterklasse ist geladen und die Methode überschrieben, wird der kompilierte code ist gebrochen für alle zukünftigen Anrufe zu. Der code wird als "nicht Teilnehmer" (keine Zukunft Anrufer der gebrochenen code), aber manchmal vorhandenen Anrufer halten können mit dem code. Im Fall von inlining, das ist nicht gut genug; bestehende Anrufer stack-frames "deoptimized" wenn Sie zurückkehren, um den code aus geschachtelte Aufrufe (oder nur, wenn Sie sich in den code). Wenn die nicht mehr stack-frames halten PC ' s in die gebrochenen code, es ist erklärt, ein "zombie" - bereit für die Entfernung, sobald die GC herum an es.

    • Kris Mok schrieb eine Antwort auf JodaStephen, was ist nun mit von seinem blog und ist sogar noch komplett in seiner Beschreibung von -XX:+PrintCompilation; hier der link: gist.github.com/1165804#file_notes.md
    InformationsquelleAutor JodaStephen
  2. 9

    Dies ist absolut nicht eine Fläche von know-how für mich, aber ich war interessiert, und so hat sich auch ein bisschen Graben.

    Ein paar links, die Sie interessant finden könnte: OpenJDK:nmethod.cpp, OpenJDK:nmethod.hpp.

    Einen Auszug aus nmethod.hpp:

    //Make the nmethod non entrant. The nmethod will continue to be
//alive.  It is used when an uncommon trap happens.  Returns true
//if this thread changed the state of the nmethod or false if
//another thread performed the transition.
bool  make_not_entrant() { return make_not_entrant_or_zombie(not_entrant); }
//...

    Nur als Ausgangspunkt.

    • Das ist ein nützlicher Anfang, danke. Je mehr ich Blick in dem code der hotspot mehr Vokabeln, die ich finden ich weiß es nicht! So denken wir "not_entrant" bedeutet einfach "nicht ausführen, das kompilierten code wieder, müssen de-opt/kompilieren ersten"? Noch ein link: siehe Zeile 536 von google.com/codesearch/p?hl=en#aRIt9pqzOVI/src/share/vm/oops/...
    • Angesichts der Bedeutung der "Teilnehmer" meines denke wäre, dass es-flags kompiliert Methode nicht eingegeben wieder (obwohl einige threads, die eventuell noch drin sein), während die zombie-bedeutet, dass es keine weitere Verwendung und kann entsorgt werden. Genau wie eine Kasse verkünden konnte es nicht akzeptieren, Neukunden (nicht-Teilnehmer) würde aber trotzdem haben, um die Kunden in der Warteschlange vor dem schließen der Kasse (zombie). Aber es ist nur eine Vermutung.
    • Schöne Analogie :p
    InformationsquelleAutor Mark Peters
  3. 6

    Eine neuere Erklärung ist die, dass es Einträge wie diese im log:

    129   72       3       EscapeAnalysysTest::second (24 bytes)
.......... some more lines
135   76       4       EscapeAnalysysTest::second (24 bytes)
137   74       3       EscapeAnalysysTest::second (24 bytes)   made not entrant

    Dies bedeutet, dass eine Methode (second hier) zusammengestellt worden, unter tier-level 3, dann unter tier-level 4 wurde es noch weiter optimiert und es wurde gemacht nicht Teilnehmer für die 3-d-tier, das heißt, es wird ersetzt mit dem code aus der 4-TEN Rang.

    • könnten Sie bitte geben Sie mir die Quelle dieser Erklärung?
    • das ist, was ich erinnere mich beim Lesen jvm-Quellcode, ich erinnere mich nicht den genauen Pfad jetzt...
    InformationsquelleAutor Eugene
  4. 2

    Hier eine Zusammenfassung mit einer unglaublichen Menge an Informationen auf PrintCompilation. Konkret heißt es:

    Wenn deoptimization passiert, wenn es entschieden wird, um die Unwirksamkeit der beanstandeten nmethod es wird "nicht Teilnehmer" zuerst; und dann, wenn die NMethodSweeper findet, dass es keine Aktivierungen der es auf dem Stapel nicht mehr, es ist "made zombie";

    InformationsquelleAutor rolve
Schreibe einen Kommentar