Escape-Analyse in Java

Soweit ich weiß die JVM verwendet die escape-Analyse für einige performance - Optimierungen wie lock coarsening und lock elision.
Ich bin interessiert, ob es eine Möglichkeit gibt für die JVM zu entscheiden, dass ein bestimmtes Objekt zugewiesen werden können-stack mit escape-Analyse.

Einige Ressourcen machen mich denken, dass ich Recht habe. Ist es JVMs, dass es wirklich tun?

Kommentar zu dem Problem
Oracle-Dokumentation: Nach der escape-Analyse, die server-compiler eliminiert scalar austauschbaren Objekt-Zuordnungen und damit verbundenen sperren aus den generierten code. Die server-compiler entfällt auch sperren für alle nicht-Global Flucht-Objekte. ES ERSETZT NICHT EIN HEAP MIT EINEM STACK-ALLOKATION. Kommentarautor: anstarovoyt
@anstarovoyt Es ersetzt nicht ein heap mit einem stack Allokation FÜR NICHT-GLOBAL FLUCHT-OBJEKTE. Kommentarautor: Aliaxander
@Aliaxander die Frage wurde in 2009 und meine Antwort war in 2013 🙂 Kommentarautor: anstarovoyt
@anstarovoyt lass den Kommentar sein, nur für den Fall um zu verhindern, dass Verwirrung in Anbetracht der neueren JDK-Versionen. Kommentarautor: Aliaxander

InformationsquelleAutor der Frage Denis Bazhenov | 2009-04-21

  1. 5

    Ich glaube nicht entkommen Analyse für stack-Allokation. Beispiel:

    public class EscapeAnalysis {

    private static class Foo {
        private int x;
        private static int counter;

        public Foo() {
            x = (++counter);
        }
    }
    public static void main(String[] args) {
        System.out.println("start");
        for (int i = 0; i < 10000000; ++i) {
            Foo foo = new Foo();
        }

        System.out.println(Foo.counter);
    }
}

    mit -server -verbose:gc -XX+DoEscapeAnalysis:

    starten 
[GC 3072K->285K(32640K), 0.0065187 Sek.] 
[GC 3357K->285K(35712K), 0.0053043 Sek.] 
[GC 6429K->301K(35712K), 0.0030797 Sek.] 
[GC 6445K->285K(41856K), 0.0033648 Sek.] 
[GC 12573K->285K(41856K), 0.0050432 Sek.] 
[GC 12573K->301K(53952K), 0.0043682 Sek.] 
[GC 24877K->277K(53952K), 0.0031890 Sek.] 
[GC 24853K->277K(78528K), 0.0005293 Sek.] 
[GC 49365K->277K(78592K), 0.0006699 Sek.] 
10000000

    Angeblich JDK 7 unterstützt Stapel-Allokation.

    InformationsquelleAutor der Antwort benmmurphy

  2. 91

    Mit dieser version von java -XX:+DoEscapeAnalysis Ergebnisse in weit weniger gc-Aktivität und 14x schnellere Ausführung.

    $ java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
    Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

$ uname -a
Linux xxx 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux

    Ohne escape-Analyse,

    $ java -server -verbose:gc EscapeAnalysis|cat -n
     1  start
     2  [GC 896K->102K(5056K), 0.0053480 secs]
     3  [GC 998K->102K(5056K), 0.0012930 secs]
     4  [GC 998K->102K(5056K), 0.0006930 secs]
   --snip--
   174  [GC 998K->102K(5056K), 0.0001960 secs]
   175  [GC 998K->102K(5056K), 0.0002150 secs]
   176  10000000

    Escape-Analyse,

    $ java -server -verbose:gc -XX:+DoEscapeAnalysis EscapeAnalysis
start
[GC 896K->102K(5056K), 0.0055600 secs]
10000000

    Sich die Ausführungszeit verringert deutlich die escape-Analyse. Für diesen loop wurde geändert, um 10e9 Iterationen,

    public static void main(String [] args){
    System.out.println("start");
    for(int i = 0; i < 1000*1000*1000; ++i){
        Foo foo = new Foo();
    }
    System.out.println(Foo.counter);
}

    Ohne escape-Analyse,

    $ time java -server EscapeAnalysis
start
1000000000

real    0m27.386s
user    0m24.950s
sys     0m1.076s

    Escape-Analyse,

    $ time java -server -XX:+DoEscapeAnalysis EscapeAnalysis
start
1000000000

real    0m2.018s
user    0m2.004s
sys     0m0.012s

    Also mit escape-Analyse am Beispiel lief rund 14x schneller als die non-escape-Analyse ausführen.

    InformationsquelleAutor der Antwort Janek Bogucki

  3. 2

    Escape-Analyse ist wirklich schön, aber es ist nicht eine vollständige erhalten von Gefängnis-frei-Karte. wenn Sie eine dynamisch große Sammlung innerhalb des Objekts, die escape-Analyse wird NICHT wechseln, von Haufen zu stapeln. Zum Beispiel:

    public class toEscape {
   public long l;
   public List<Long> longList = new ArrayList<Long>();
}

    Selbst wenn das Objekt erstellt wird, in eine Methode und absolut NICHT Flucht aus der syntaktischen Sicht, die der compiler nicht zu, markieren Sie diese für die Flucht. Ich vermute da, dass die longList ist nicht wirklich begrenzt in der Größe von einer rein syntaktischen Perspektive und es könnte blow your stack potenziell. Also ich glaube, es dauert ein pass auf diesen Fall. Ich experimentierte mit diesem, wo der longList war leer und noch immer verursacht, die Sammlungen in einem einfachen micro-benchmark.

    InformationsquelleAutor der Antwort Mike Ceruti

Schreibe einen Kommentar