Speichert Java seine Laufzeitoptimierungen?

Question

Mein Professor hat einen informellen Benchmark für ein kleines Programm durchgeführt und die Java-Zeiten waren:1,7 Sekunden für den ersten Lauf und 0,8 Sekunden für die folgenden Läufe.

• Liegt dies ausschließlich am Laden der Laufzeitumgebung in die Betriebsumgebung?

  ODER

• Wird es dadurch beeinflusst, dass Java den Code optimiert und die Ergebnisse dieser Optimierungen speichert (leider kenne ich den Fachbegriff dafür nicht)?

Answer 1

Ich bin damit einverstanden, dass der Unterschied in der Leistung durch das Plakat gesehen wird höchstwahrscheinlich durch Datenträgerlatenz verursacht die JRE in dem Speicher zu bringen. Die Just In Time-Compiler (JIT) würde keine Auswirkungen auf die Leistung eines kleinen Anwendung.

Java 1.6u10 ( http://download.java.net/jdk6/ ) berührt die Laufzeit JAR-Dateien in einem Hintergrundprozess (auch wenn Java läuft nicht), um die Daten in den Festplatten-Cache zu halten. Dies verringert erheblich Startzeiten (was ein großer Vorteil für Desktop-Anwendungen ist, aber wahrscheinlich von marginalem Wert auf Server-Seite-Anwendungen).

Bei großem, langen laufenden Anwendungen macht die JIT einen großen Unterschied im Laufe der Zeit - aber die Zeit, für die JIT erforderlich ausreichende Statistiken zu sammeln, um in Tritt und optimieren (5-10 Sekunden) ist sehr, sehr kurz im Vergleich zu die gesamte Lebensdauer der Anwendung (die meisten laufen für Monate und Monate). Während der Speicherung und die JIT Ergebnisse Wiederherstellung ist eine interessante akademische Übung, ist die praktische Verbesserung nicht sehr groß (weshalb das JIT-Team auf Dinge wie GC Strategien zur Minimierung des Speicher-Cache-Misses fokussierter war, etc ...).

Die Vorkompilierung der Laufzeitklassen tut Hilfe Desktop-Anwendungen ziemlich viel (wie auch die zuvor erwähnte 6u10 Disk-Cache Vorbelastung).

Answer 2

Okay, fand ich, wo ich das gelesen. Das ist alles aus "Learning Java" (O'Reilly 2005):

  

Das Problem mit einer herkömmlichen JIT-Kompilierung ist, dass Code zu optimieren Zeit in Anspruch nimmt. So kann ein JIT-Compiler anständige Ergebnisse produzieren kann aber eine signifikante Latenzzeit leiden, wenn die Anwendung startet. Dies ist in der Regel kein Problem für lang laufende serverseitige Anwendungen, sondern ist ein ernstes Problem für die clientseitige Software und Anwendungen, die auf kleineren Geräten mit begrenzten Fähigkeiten laufen. Um dem abzuhelfen, Suns Compiler-Technologie, die so genannte HotSpot, verwendet einen Trick adaptive Kompilierung genannt. Wenn man sich anschaut, welche Programme verbringen tatsächlich ihre Zeit zu tun, stellt sich heraus, dass sie verbringen fast ihre ganze Zeit einen relativ kleinen Teil des Codes immer wieder ausgeführt wird. Der Teil des Codes, der wiederholt ausgeführt wird, kann nur ein kleiner Teil des Gesamtprogramms sein, aber sein Verhalten bestimmt die Gesamtleistung des Programms. Adaptive Kompilierung ermöglicht auch der Java-Laufzeitvorteil von neuen Arten von Optimierungen zu nehmen, die einfach nicht in einer statisch kompilierten Sprache erfolgen, damit die Behauptung, dass Java-Code ausführen kann schneller als C / C ++ in einigen Fällen.

     

Um die Vorteile dieser Tatsache zu nehmen, beginnt HotSpot aus als normale Java-Bytecode-Interpreter, aber mit einem Unterschied: es misst (Profile), um den Code, wie es ausgeführt wird, um zu sehen, welche Teile wiederholt ausgeführt werden. Sobald es weiß, welche Teile des Codes, um die Leistung von entscheidender Bedeutung sind, stellt HotSpot diese Abschnitte in optimalen nativen Maschinencode. Da es nur einen kleinen Teil des Programms in Maschinencode kompiliert, kann es sich leisten, die Zeit zu ergreifen, um jene Teile zu optimieren. Der Rest des Programms kann nicht alles nur interpretiert sparende Speicher und Zeit kompiliert werden müssen. In der Tat, Suns Java-Standard VM kann in einem von zwei Modi laufen:. Client und Server, die es sagen, ob eine schnelle Startzeit und Speichererhaltung oder flach Outperformance betonen

     

Eine natürliche Frage an dieser Stelle fragen ist, warum jedes Mal all diesen gute Profilierung Informationen wegzuwerfen eine Anwendung heruntergefahren? Nun, Sun hat teilweise dieses Thema mit der Veröffentlichung von Java 5.0 durch die Verwendung von Shared angeschnitten, read-only-Klassen, die dauerhaft in einer optimierten Form gespeichert sind. Dies reduziert sowohl die Startzeit und Aufwand für viele Java-Anwendungen auf einer bestimmten Maschine ausgeführt wird. Die Technologie dafür ist komplex, aber die Idee ist einfach:. Die Teile des Programms optimieren, die schnell gehen müssen, und mach dir keine Sorgen über den Rest

Ich bin Art von Fragen, wie weit Sun mit ihm seit Java 5.0 bekommen hat.

Answer 3

Ich bin mir nicht bekannt, dass virtuelle Maschine weit verbreitet, die statistischen Nutzungsdaten zwischen Programm Anrufungen spart - aber es ist sicherlich eine interessante Möglichkeit für die zukünftige Forschung

.

Was Sie sehen, ist fast sicher auf Disk-Caching.

Answer 4

Ich bin damit einverstanden, dass es wahrscheinlich das Ergebnis von Disk-Caching.

FYI, hat die IBM Java 6 VM eine Voraus-Time-Compiler (AOT) enthalten. Der Code ist nicht ganz so optimiert, was der JIT produzieren würde, aber es ist für die virtuellen Rechner gespeichert, ich glaube, in einer Art permanenten gemeinsamen Speicher. Sein Hauptvorteil ist Startleistung zu verbessern. Die IBM VM standardmäßig JITs ein Verfahren, nachdem es 1000 mal aufgerufen. Wenn es weiß, dass ein Verfahren 1000 mal gerade während der VM Anlauf aufgerufen werden wird (man denke an eine häufig verwendete Methode, wie java.lang.String.equals(...)), dann vorteilhaft es ist für sie, dass zu speichern in der AOT-Cache, so dass es nie Zeit zu verschwenden hat Kompilieren zur Laufzeit.

Answer 5

Sie sollten beschreiben, wie Ihr Benchmark durchgeführt wurde.Vor allem dann, wenn man anfängt, die Zeit zu messen.

Wenn Sie die JVM-Startzeit einbeziehen (die für das Benchmarking der Benutzererfahrung nützlich, aber nicht so nützlich für die Optimierung von Java-Code ist), kann es sich um einen Dateisystem-Caching-Effekt handeln oder durch eine Funktion namens „Java Class Data Sharing“ verursacht werden:

Für Sonne:

http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

Dies ist eine Option, bei der die JVM ein vorbereitetes Abbild der Laufzeitklassen in einer Datei speichert, um ein schnelleres Laden (und Teilen) dieser Klassen beim nächsten Start zu ermöglichen.Sie können dies mit -Xshare:on oder -Xshare:off mit einer Sun JVM steuern.Der Standardwert ist -Xshare:auto, wodurch das Bild der gemeinsam genutzten Klassen geladen wird, falls vorhanden. Wenn es nicht vorhanden ist, wird es beim ersten Start geschrieben, sofern das Verzeichnis schreibfähig ist.

Mit IBM Java 5 ist das übrigens noch leistungsfähiger:

http://www.ibm.com/developerworks/java/library/j-ibmjava4/

Ich kenne keine Mainstream-JVM, die JIT-Statistiken speichert.

Answer 6

Java JVM (eigentlich könnte aus verschiedenen Implementierungen des JVM ändern), wenn zuerst den Bytecode interpretiert beginnt. Sobald es erkennt, dass der Code genug Anzahl von Malen JITs es zu nativem Maschinensprache ausgeführt werden, so dass es schneller läuft.