ist es möglich, zu deaktivieren javac ist inlining von static-final-Variablen?

Java statische compiler (javac) inlines einige static final-Variablen und bringt die Werte direkt in den Konstanten-pool. Betrachten Sie das folgende Beispiel. Klasse A definiert einige Konstanten (public static final-Variablen):

public class A {
    public static final int INT_VALUE = 1000;
    public static final String STRING_VALUE = "foo";
}

Klasse B verwendet diese Konstanten:

public class B {
    public static void main(String[] args) {
        int i = A.INT_VALUE;
        System.out.println(i);
        String s = A.STRING_VALUE;
        System.out.println(s);
    }
}

Beim kompilieren der Klasse B, javac bekommt die Werte dieser Konstanten aus der Klasse A und inlines diese Werte in B.class. Als Ergebnis, die Abhängigkeit B hatte die Klasse zur compile-Zeit werden gelöscht, aus dem bytecode. Dies ist ein eher eigenartiges Verhalten, weil Sie das Backen in der die Werte dieser Konstanten zu der Zeit der Zusammenstellung. Und Sie würden denken, dass dies ist eine der einfachsten Dinge, die der JIT-compiler zur Laufzeit.

Gibt es eine Möglichkeit oder irgendwelche versteckten compiler-option, mit der Sie diese Funktion deaktivieren inlining Verhalten von javac? Für den hintergrund, wir suchen zu tun bytecode-Analyse für die Abhängigkeit Zwecke, und es ist einer der wenigen Fälle, wo der bytecode-Analyse schlägt fehl, zu erkennen, compile-time Abhängigkeiten. Danke!

Bearbeiten: dies ist eine leidige Angelegenheit, weil wir in der Regel nicht alle Steuern auf die Quelle (z.B. third-party Bibliotheken, die Definition von Konstanten). Wir sind daran interessiert, die Erkennung dieser Abhängigkeiten, die aus der Perspektive der mit der Konstanten. Da die Referenz wird gelöscht, der code, der verwendet die Konstanten, es gibt keinen einfachen Weg, um Sie zu erkennen, kurz, tun, source-code-Analyse.

Gute Frage!!! Irgendwann in dieser inlining von Konstanten verursachen seltsame Probleme... Aber ich habe nicht gesehen, eine richtige Art und Weise zu beschränken.

InformationsquelleAutor sjlee | 2010-08-19

44

Element 93 von Java-Teilnehmer (Joshua Bloch) sagt, dass Sie arbeiten können, um diese durch die Verhinderung der endgültige Wert wird als konstant angenommen. Zum Beispiel:
```
public class A {
  public static final int INT_VALUE = Integer.valueOf(1000).intValue();
  public static final String STRING_VALUE = "foo".toString();
}
```
Natürlich nichts von alledem ist relevant, wenn Sie keinen Zugriff auf den code, der definiert die Konstanten.
- +1; Bloch decken diese in Java Teilnehmer. Er verwendet ident statt toX.
- Schön. Glaube nicht, dass der 🙂 Für die meisten Arten gibt es wahrscheinlich vorhandenen Methoden für die Arbeit (z.B. String.valueOf())
- Ich erinnerte mich nur der Zuordnung von System.out ist diese: public final static PrintStream out = nullPrintStream(); (der eigentliche stream ist später von native code). nullPrintStream() gibt null zurück, wenn currentTimeMillis()>0. Es schlug nie mich, warum Sie das getan hat (im Gegensatz zu nur ...out = null;), bis jetzt. Natürlich hätte ich Bock auf Lesen Sie die Dokumentation für nullInputStream() wäre es gewesen, klar zu machen...
- Die Unfähigkeit, deaktivieren Sie diese Optimierung bei der Kompilierung ist eine von vielen Möglichkeiten javac Krüppel, die Möglichkeit zu schaffen, einen richtigen debugger.
- das ist einer dieser Esoterik-Optimierungen, ich Liebe den Java-core-Entwickler. Da weder Objekte des Typs PrintStream noch die null Referenz kann immer sein compile-time-Konstanten, das inlining nur zu verweisen können, JIT, aber der JIT ist nicht egal, wo der Wert kam von vor der Zuweisung. Beachten Sie, dass beginnend mit Java 7 code nicht Aussehen public final static PrintStream out = null;.
- In Bezug auf Felder, die könnte wirklich werden compile-Zeit-Konstanten, wie in dieser Antwort, es wäre effizienter zu nutzen public static final int INT_VALUE; public static final String STRING_VALUE; static { INT_VALUE = 1000; STRING_VALUE = "foo"; } vermeidet unnötige Methodenaufrufe, nicht zu reden von den Boxen overhead Integer.valueOf(1000).
InformationsquelleAutor DJClayworth
13

Glaube ich nicht so. Die einfachste Lösung wäre, setzen diese Eigenschaften eher als Felder:
```
public class A {
    private static final int INT_VALUE = 1000;
    private static final String STRING_VALUE = "foo";

    public static int getIntValue() {
        return INT_VALUE;
    }
    public static String getStringValue() {
        return STRING_VALUE;
    }
}
```
Vergessen Sie nicht, dass in bestimmten Fällen das inlining ist unerlässlich, um die Verwendung der Wert - zum Beispiel, wenn Sie auf INT_VALUE als ein Fall in einem switch-block, der hat angegeben werden, da ein konstanter Wert.
- Jon, haben Sie irgendwelche Erkenntnisse darüber, warum die JLS legt die Zugriffs -, aber nicht schlagen privat mit der final-modifier (siehe meine Antwort)?
- Wäre es nicht möglich, dass es inlining der accessor-Funktion, wenn die privaten member war final (das Ergebnis konnte festgestellt werden, zur compile-Zeit), die im wesentlichen die Wiederherstellung des public static final Szenario? (spekulative Begründung meinerseits)
- Meine intuition wäre, dass die Funktionen dürfen nur inline zur Laufzeit. Sonst keine stub-Methode, die Sie erstellen (return null;) würde erfordern, dass Sie neu kompilieren aller Klassen nutzen Sie, nachdem Sie gekommen, um zu implementieren, die Methode.
- Ah, natürlich. Bit einer psychischen dort durchfallen, sorry. 🙂
- ein Grund dafür ist die Tatsache, dass kein code legt die (privaten) Bereich stellt einen final Modell überflüssig ... aus rein sprachlichen Sinne. (Stil überlegungen etwas anderes sagen, aber die JLS ist nicht versucht, Sie zu einer Stil-Handbuch.)
InformationsquelleAutor Jon Skeet
9

Stoppen inlining Sie brauchen, um die Werte nicht-compile-Zeit-Konstanten (der Begriff JLS). Sie können dies tun, ohne die Verwendung von Funktionen und erstellen ein minimum von bytecode durch die Verwendung eines null im initialiser Ausdruck.
```
public static final int INT_VALUE = null!=null?0: 1000;
```
Obwohl es sehr literal im code generation javac optimieren sollte dies ein push von einem unmittelbaren integer gefolgt von einem store, um das statische Feld in der static initialiser.
- Wie wäre es einfach 1000+0. Aber wäre das dann Arbeit in einer case-Anweisung?
- ist ein compile-Zeit-Konstante. Es unterscheidet sich nicht von 1000 so funktioniert es in einer case-Anweisung, aber dann wird es auch inline. Der magic in der Antwort ist, dass null ist nicht compile-Zeit-Konstante und daher kein Ausdruck, der verwendet, es ist entweder.
- Wenn Sie sicher sein wollen, dass der compiler erzeugt eine Zuordnung, Sie können einfach schreiben Sie es als solche public static final int INT_VALUE; static { INT_VALUE = 1000; }
- Während das ist klarer Weise der Herstellung exakt den gleichen bytecode, ich denke, es gibt mehr Nachteile. null!=null?0: zeigt deutlich eine Absicht zu tun, etwas so ist es weniger wahrscheinlich, getrennt werden, durch einen Reiniger. Obwohl die Redewendung nicht offensichtlich ist, sollte es nicht lange dauern, um herauszufinden, was das Ergebnis ist, wenn auch nicht der compile-Zeit-Konstante Semantik*. Es ist nicht völlig entstellt, indem Neuformatierung. Sie nicht haben, um match-IDS (passen Sie? don ' T Sie? Es ist eine seltsame Schreibweise, was?).
- Ich habe nicht darauf bestehen, wenn es in einer Linie; das ist nur, wie man Kommentare formatiert. Also, wenn ein formatter bricht es in mehrere Zeilen, ich bin in Ordnung damit. Ein Reinigungsmittel, smart genug zu verstehen, dass null!=null sinnvoll ist, sollte keine Probleme mit dem Verständnis der Unterschied zwischen compile-Zeit-Konstanten und-Variablen zugeordnet, die in einem Initialisierer. Seit ein static final variable nicht sofort zugeordnet muss zugewiesen bekommen, die in einer statischen Initialisierer und es muss genau einmal zugeordnet, kann der compiler überprüfen. Es ist die standard-idiom für Initialisierungen passt nicht in einen Ausdruck.
InformationsquelleAutor Tom Hawtin - tackline
7

JLS 13.4.9 mit diesem Thema umgeht. Ihre Empfehlung ist grundsätzlich zu vermeiden compile-Zeit-Konstanten, wenn der Wert in irgendeiner Weise ändern dürfte.
(Ein Grund für die inlining von
Konstanten ist, dass switch-Anweisungen
benötigen Konstanten auf jeden Fall, und keine
zwei solche Konstanten Werten kann die
gleiche. Der compiler überprüft
doppelte Konstante Werte in einem switch
Anweisung zur compile-Zeit; die Klasse
Datei-format nicht symbolische
die Verknüpfung von case-Werte.)

Der beste Weg, um Probleme zu vermeiden mit
"unbeständig Konstanten" in
weit verbreiteten code zu erklären
als compile-Zeit-Konstanten nur Werte
die sind wirklich kaum jemals
ändern. Andere als wahr
mathematische Konstanten, die wir empfehlen
daß der source-code sehr sparsam verwenden
der Klasse deklarierten Variablen
static und final. Wenn die nur-Lesen -
die Natur der final ist erforderlich, eine bessere
die Wahl ist zu deklarieren private static
variable und eine passende accessor
Methode, um seinen Wert. Damit wir
empfehlen:
```
private static int N;
public static int getN() { return N; }
```
statt:
```
public static final int N = ...;
```
Ist es kein problem mit:
```
public static int N = ...;
```
wenn N müssen nicht nur gelesen werden.
InformationsquelleAutor
2

Ich denke, das ist eine ernst bug. Java ist kein C/C++. Es ist ein Prinzip(oder auch nicht) "Compile once, run everywhere".

In diesem Fall, wenn Eine Klasse geändert wird. Alle Klassen referenzieren A. CONST_VALUE müssen neu kompiliert werden und Sie kaum wissen, ob Eine Klasse geändert wird.
- Es ist kein bug es ist ein feature. Es stellt sicher, dass, wenn Sie eine Konstante in einem Objekt in ein anderes Modul, dass kann auch nicht geladen werden, so dass, wenn Sie Sie Fragen nach einer BANANE, es geht nicht immer die Monkey-Klasse und die Dschungel-Paket zusammen mit ihm. Java bietet eine reflection und Serialisierung(zusammen mit anderen) zu vermeiden, caching, aber keinen Mechanismus, explizit-force-inlining, also bin ich euphorisch, es ist tatsächlich nicht inline(wenn Sie löschen Sie die utility-Klasse mit Konstanten, die Klasse über diese Konstanten wird immer noch funktionieren). Andere Lösungen vorschlagen, die Möglichkeiten, es zu tun, nur mit nicht compile-Zeit-Konstanten.
- Es ist ein bug. Denken Sie daran, dass Java nicht JIT-kompiliert, so ist es ein non-Optimierung, die gelegentlich verursacht großen Kummer.
- es sieht einfach aus, wenn Sie nur in Betracht ziehen, Lesen ein static Feld statt mit einem Wert. Aber stellen Sie sich vor, wie ein switch Aussage über die Konstanten der anderen Klasse sollte dann kompiliert, wenn es sollte zur Unterstützung von änderungen nach der Kompilierung. Ebenso ist die Sprache ist streng, wenn es um code-Erreichbarkeit. Ermöglicht Konstanten zu ändern, nach der Zusammenstellung würde die Niederlage der Sprache Sicherheit. Und es ist konsequent zu zwingen, alle verwendet, eine Konstante zu verwenden, die eine Konstante, anstatt zu Lesen, ein dynamischer Wert.
- Der javac ist nicht wirklich der java-compiler. Es ist nur die java-parser. Es ist der JIT optimiert. So interpretiert FALL ist nur eine hash-Tabelle. Ebenso, Java sollte Schlüsselwort optionale Parameter, wie jeder andere pre-C-Sprache haben, und die Effizienz ist nicht eine Frage, wie ist es mit C++, sagen. Vielleicht sehen wir den letzteren gegeben, C# hat es für einige Zeit.
- erzeugt bytecode. Dass bytecode enthalten eine kompilierte form der switch-Tabelle, unabhängig davon, wie es aussieht. Nun sagen Sie, wie die kompilierte form Aussehen sollte, wenn die Schlüssel-Werte waren erlaubt, änderungen nach der Kompilierung. Sie sagen, "hash-Tabelle", aber die hash-codes ist auch abhängig von dem tatsächlichen Wert, daher nicht erlauben, ändern wichtige Werte. Versuchen Sie nicht, um ablenken von dem Thema mit deiner "optionale Parameter" - Zeug. Bedeutet entweder, C++ oder C# ermöglichen die Schlüsselwerte eines switch - Anweisung zu ändern, nach der Zusammenstellung? Ich denke nicht so.
- wäre es nur wie ein array initialisiert mit Ausdrücken. Oder ein paar Anrufe, um eine hash-Funktion hinzufügen. Oder einige spezielle byte-code, der loader kann beheben. Und wir haben jetzt die Strings in hash-Tabellen, die brauchen ein bisschen Arbeit sowieso. Viele Möglichkeiten. Aber es nicht, und jeder so oft, dass Reisen Menschen bis schlecht.
- die strings in switch Aussagen erfordern immer noch constant Etiketten. Das ist wie switch funktioniert. Wenn Sie möchten, dass "ein array initialisiert mit Ausdrücken" statt oder einige hashing-Struktur, bewältigen kann, ändern von Schlüsseln, gut, einfach umzusetzen. "Viele Wege" Aber nicht die Schuld von Java nicht zu tun, ist etwas ganz anderes als schreiben in den source-code.
- der gemeinsame Sprung-Tabelle Optimierung der Technik für switch-Anweisungen benötigt Konstanten, die von der Laufzeit. Aber das ist gut, nach javac Zeit. Es könnte sein, laden Sie Zeit. Oder JIT-Zeit. Ferner, dass die Optimierung ist weder notwendig noch hinreichend. Ein guter compiler sollte eine Sprung-Tabelle "if (x==1) ... elseif (x==2)... elseif (x==3)...". Ebenso ist ein schalten ohne Konstanten, die nicht einfach zu optimiert ist auch sehr nützlich und unterstützt Sie in andere Sprachen. Java ist viel anspruchsvoller als C!
- ok, ich sollte gesagt haben: "Das ist wie Java - Schalter funktioniert". Es funktioniert so, und es erfordert eine ständige labels. Ja, andere Sprachen mit anderen Konstrukten. Aber das war nie das Thema. Das Thema ist Konstante Felder in Java. Die Art und Weise, Schalter funktioniert in Java die Möglichkeit, Anmerkungen Arbeit in Java, und die Möglichkeit, code erreichbarkeitsprüfungen Arbeit in Java, das Mandat nicht ändern, resp. kopiert Konstante Werte, wenn auch nur implizit. Ändern sich diese, ist nicht so trivial, wie Sie mit einem einfachen Feld Lesen. Das ist der Punkt. Der obligatorische code-flow-Kontrollen sind viel interessanter als die switch - Anweisung.
InformationsquelleAutor neoedmund

Rewrite-Klasse Ein wie:

public class A {
    public static final int INT_VALUE;
    public static final String STRING_VALUE;

    static {
        INT_VALUE = 1000;
        STRING_VALUE = "foo";
    }
}

InformationsquelleAutor rveach

1

jmake ist ein open-source-Projekt, das behauptet, die ganze Arbeit, die Verfolgung der Abhängigkeiten zwischen Java-Dateien und inkrementell kompilieren die minimale erforderliche Menge von Dateien. Er behauptet richtig zu verarbeiten, die änderungen an static final-Konstanten, auch wenn Sie manchmal benötigt das gesamte Projekt neu kompiliert werden. Es meistert sogar änderungen an einer feineren Granularität als die classfiles; wenn (beispielsweise) die Signatur einer Methode C. m() ändert, dann ist es nur neu kompiliert die Klassen, die tatsächlich davon abhängen, m (), anstatt alle Klassen, die Nutzung von C.

DISCLAIMER: ich habe keine Erfahrung mit jmake.
- Toter link, und scheint ein Totes Projekt.
InformationsquelleAutor mhagger

Kurzem stieß ich auf eine ähnliche Problem, und, wie es oben gesagt wurde, wie inlining umgangen werden kann mit nicht-compile-time Ausdrücke, sagen:

public final class A {

    public static final int INT_VALUE = constOf(1000);
    public static final String STRING_VALUE = constOf("foo");

}

wo die constOf Methode Familie ist nur:

//@formatter:off
public static boolean constOf(final boolean value) { return value; }
public static byte constOf(final byte value) { return value; }
public static short constOf(final short value) { return value; }
public static int constOf(final int value) { return value; }
public static long constOf(final long value) { return value; }
public static float constOf(final float value) { return value; }
public static double constOf(final double value) { return value; }
public static char constOf(final char value) { return value; }
public static <T> T constOf(final T value) { return value; }
//@formatter:on

Dieser ist ein wenig kürzer als andere Vorschläge wie Integer.valueOf(1000).intValue() oder null!=null?0: 1000

InformationsquelleAutor Lyubomyr Shaydariv

-2

Fühle ich java eng stützt sich auf die dynamische Kompilierung und es nicht tun, keine Lust auf Zusammenstellung Logik wie C++.

können Sie versuchen, einige Optionen mit JIT-Compilern, die nicht Laufzeit-Optimierung haben können, einige Optionen zu deaktivieren/aktivieren dieser.

in Verzug javac können Sie nicht bekommen, dass die option. Sie haben zu verwenden
1. irgendeine Art von dependency graph wie erweitert oder implementiert
2. mit der Methode basiert Verlinkung.

-s
- Ich bin mir nicht sicher, was du meinst... Das ist genau das javac (statische compiler) Verhalten, und es scheint, das ist wirklich diktiert die Sprache Skillung an.
InformationsquelleAutor kadalamittai

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.