2016-02-03 21 views
13

Słyszałem, żeCzy istnieje regresja czasu uruchamiania w Java 9 ea?

  1. JVM staje się szybszy (w pewnym sensie) z każdym głównym wydaniu
  2. modułowość 9 przyniesie czas szybciej startowego.

Próbując przyspieszyć kompilację Mavena, pobrałem jdk9-ea i stwierdziłem, że trwa to jeszcze dłużej. Co więcej, wydaje się, że przed rozpoczęciem Maven jest dłuższe opóźnienie.

Próbowałem grubsza mierzyć czas uruchamiania JVM używając następującego kodu

public class Sampler { 
    public static void main(String[] args) throws IOException, InterruptedException { 
     long t = System.currentTimeMillis(); 
     if (args.length == 0 || args[0].startsWith("-")) { 
      sample(30, args); 
     } else { 
      long t0 = Long.parseLong(args[0]); 
      System.out.println(t - t0); 
     } 
    } 

    static void sample(int n, String[] options) throws IOException, InterruptedException { 
     File samples = new File("samples.txt"); 
     for (int i = 0; i < n; i++) { 
      String javaPath = String.join(
        System.getProperty("file.separator"), 
        System.getProperty("java.home"), 
        "bin", 
        "java"); 

      List<String> command = new ArrayList<String>(); 
      command.add(javaPath); 
      command.addAll(Arrays.asList(options)); 
      command.add("Sampler"); 
      command.add(Long.toString(System.currentTimeMillis())); 

      ProcessBuilder processBuilder = new ProcessBuilder(command) 
        .inheritIO() 
        .redirectOutput(ProcessBuilder.Redirect.appendTo(samples)); 

      Process process = processBuilder.start(); 
      process.waitFor(); 
     } 
     prettyPrint(samples); 
     samples.delete(); 
    } 
    ... 
} 

I trwa dwa razy dłużej, aby rozpocząć z Java 9

 
>java -version 
java version "1.8.0_74" 
Java(TM) SE Runtime Environment (build 1.8.0_74-b02) 
Java HotSpot(TM) Client VM (build 25.74-b02, mixed mode, sharing) 

>javac Sampler.java && java Sampler 
n=30 units=milisec min=124 max=205 mean=143 median=132 


>java -version 
java version "9-ea" 
Java(TM) SE Runtime Environment (build 9-ea+111) 
Java HotSpot(TM) Client VM (build 9-ea+111, mixed mode) 

>javac Sampler.java && java Sampler 
n=30 units=milisec min=279 max=387 mean=301 median=294 

>javac Sampler.java && java Sampler -XX:+UseParallelGC 
n=30 units=milisec min=279 max=382 mean=297 median=292 


>java -version 
java version "1.8.0_76-ea" 
Java(TM) SE Runtime Environment (build 1.8.0_76-ea-b04) 
Java HotSpot(TM) Client VM (build 25.76-b04, mixed mode, sharing) 

>javac Sampler.java && java Sampler 
n=30 units=milisec min=123 max=227 mean=159 median=141 

>java Sampler -XX:+UseG1GC 
n=99 units=milisec min=188 max=340 mean=213 median=199 

Uwaga: Początkowo Użyłem VM serwerów (x64), ta sama podwójna przerwa, czas uruchomienia Java 9 wynosił około 0,6 s.


Po java -Xshare:dump

 
>java -version 
java version "9-ea" 
Java(TM) SE Runtime Environment (build 9-ea+111) 
Java HotSpot(TM) Client VM (build 9-ea+111, mixed mode, sharing) 

>javac Sampler.java && java Sampler 
n=50 units=milisec min=228 max=422 mean=269 median=269 

>javac Sampler.java && java Sampler -Xshare:on 
<error messages> 
n=44 units=milisec min=227 max=392 mean=247 median=238 

>javac Sampler.java && java Sampler -Xshare:off 
n=50 units=milisec min=280 max=513 mean=315 median=288 

>javac Sampler.java && java Sampler -Xshare:auto 
n=50 units=milisec min=228 max=361 mean=283 median=285 

z Java 8 ea

 
>java -Xshare:off Sampler 
n=99 units=milisec min=124 max=264 mean=150 median=136 

Komunikat o błędzie:

 
An error has occurred while processing the shared archive file. 
Unable to map ReadOnly shared space at required address. 
Error occurred during initialization of VM 
Unable to use shared archive. 

44 udane starty z 50 to najwyższa num ber mógłbym dostać. Najniższy był - 13.

+4

czy rzeczywiście koncentrujesz się na czasie uruchamiania maszyny wirtualnej, czasie budowy maszyny lub prędkości maszyny JVM? Wydaje się, że używasz wszystkich tych terminów, jakby były takie same, ale tak nie jest. – eis

+2

Skupiam się na czasie uruchamiania, jak sugeruje tytuł. Inne "terminy" nie powinny być używane jako równe, ale z pewnością powiązane ze sobą. Maven jest przykładem dobrze znanego programu, w którym czas uruchamiania ma znaczący udział w ogólnym czasie realizacji. Rozumiem, że istotną cechą wydajności maszyny wirtualnej (prędkości) i mvn jest początkowa wydajność maszyny wirtualnej.Nie jestem pewien, czy jest to bardziej jasne niż to, co początkowo smutne, ale tutaj. – user2418306

+2

Maven z pewnością nie jest jeszcze napisany w języku Java. Prędkość JVM zwykle odnosi się do prędkości wykonania - w zależności od trybów serwera/klienta, które możesz wybrać, jeśli chcesz podkreślić czas uruchamiania lub szybkość JVM i jakie rodzaje cech pamięci. – eis

Odpowiedz

9

Tak, na pewno istnieją pewne regresje startowe w aktualnych kompilacjach EA - niektóre przyczyny są znane i aktywnie działają - inne to bardziej "Śmierć przez tysiąc cięć", ciężka próba: mała, nieznaczna nieefektywność zgromadzona w trakcie rozwoju JDK 9 jako funkcje są zaimplementowane i zintegrowane, które następnie muszą zostać dopracowane i zoptymalizowane przed faktycznym wydaniem.

Zwracam również uwagę, że twoje biegi 8/8-ea obsługują udostępnianie danych klasowych, ale twoja instalacja 9-ea nie działa (zauważ brak "dzielenia się" na wyjściu -wersji). Możesz uzyskać lepsze liczby na 9-ea, jeśli uruchomisz java -Xshare: dump, aby wygenerować domyślne archiwum CDS, zobacz https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html po więcej szczegółów.

Edycja: Właśnie zdałem sobie sprawę, że udostępnianie zostało domyślnie wyłączone w 9 kompilacjach, więc musisz również dodać opcję -Xshare: auto w wersji 9-ea, aby umożliwić udostępnianie.

+0

Czy mógłbyś dodać listę * znanych przyczyn * do swojej odpowiedzi? – user2418306

+0

W połączonym przewodniku podano, że współużytkowanie danych w klasie * jest obsługiwane tylko przy użyciu seryjnego garbage collectora *. Czy możesz również o tym powiedzieć? – user2418306

+1

Sam układ Jigsaw obecnie dodaje kilka ustawień podczas uruchamiania, ale włącza optymalizacje uruchamiania w innym miejscu, np. [JDK-8152641] (https://bugs.openjdk.java.net/browse/JDK-8152641). 9 + 108 spowodowało regresję związaną z JAR-ami Multi-Release, które powinny przejść do 9 + 113, patrz [JDK-8152733] (https://bugs.openjdk.java.net/browse/JDK-8152733). –

3

Jest prawdopodobne, że G1 garbage collector, który jest domyślnie ustawiony na Java-9, powoduje znaczne opóźnienie uruchomienia. Wypróbuj -XX:+UseParallelGC na Java-9 lub -XX:+UseG1GC na Java-8, aby sprawdzić za pomocą tego samego garbage collectora.

+0

Jak możesz wyjaśnić, że 'ParallelGC' nie sprawia, że ​​Java 9 działa lepiej? – user2418306

+1

Wydajność uruchamiania G1 znacznie poprawiła się w Javie 9 w porównaniu do 8 (gdzie często można podwoić czasy uruchamiania). Wciąż ma on wymierny koszt w porównaniu do '-XX: + UseParallelGC', ale jest to albo szum, albo około 10 ms na większości sprzętu, na którym mierzymy. –