everflux

Java benoetigt eine ganze Menge an verschiedenen Klassen, selbst um einfache Programme auszuführen. Ich habe mich mit den verschiedenne JVM Optionen der Sun Java virtual machine beschäftigt. Seit Java 5, bzw. dem JDK 5, gibt es Classdata sharing. Nicht nur, dass die Daten geshared werden können, sie koennen sogar fuer die Plattform aufbereitet werden, und können dann per memory map einer einzelnen Datei eingeblendet werden.
Das reduziert die Startzeit natürlich enorm – bei groesseren Programmen wie z.B. Eclipse fällt das jedoch geringer ins Gewicht, da es sich um Fixkosten handelt.
Diese Cache Datei lässt sich mittels
sudo java -client -Xshare:dump (bzw. -server )
generieren. Der Effekt zeigt sich bei einem kleinen Programm am deutlichsten:
Um sicher zu stellen, dass der Systemcache nicht die Ergebnisse zu sehr beeinfluss, habe ich vor jedem Testlauf
echo 3 > /proc/sys/vm/drop_caches
durchgeführt. Hier die niedrigsten Werte von fünf Läufen ohne und mit Classdata sharing dump.

time java -client Demo
Demo for Fibonacci numbers:
Fibonacci 3: 5

real 0m3.050s
user 0m0.112s
sys 0m0.092s

Mit classdata sharing

time java -client Demo
Demo for Fibonacci numbers:
Fibonacci 3: 5

real 0m1.614s
user 0m0.056s
sys 0m0.052s

Man sieht deutlich, dass sich die Ersparniss bei einem kleinen Programm deutlich bemerkbar macht, jedoch lediglich bei kalten Cache. Sobald das Betriebssystem die nötigen Daten im eigenen Cache hat, fällt die Ausführungszeit auf deutlich unter 100ms. Bei der Server JVM ist von dem Cache aufgrund des initialen Compilevorgangs und der Optimierung auf hohe Ausführungsgeschwindigkeit im Gegensatz zur Startgeschwindigkeit bei der Client VM sowieso kaum noch etwas zu spüren. In so fern dürfte das auf der Devoxx 2009 angekündigte Update des JAR Formats erheblich mehr bringen.

Bereits seit Wochen Monaten gibt es nun das Problem, dass Java 6 ab Update 4 nicht mehr stabil auf AMD64 Plattformen läuft.

Die JVM crasht – und zieht natürlich die laufende Anwendung, wie z.B. Eclipse unter Java, mit in den Tod. Ein funktionierender Workaround ist tatsächlich den Hotspot Java Optimizer/Compiler zu deaktivieren, dazu ist das Programm/Java mit „-Xint“ zu starten. (Bei Eclipse geht das dann so: eclipse -vmargs -Xint)

Wirklich behoben zu sein scheint das Problem mit Java 6 Update 10 – derzeit ist diese Version im beta Stadium. Java 6 U10 wird auch die erste Version mit dem neuen modularen Java Kernel Konzept sein.

Wer das ganze testen möchte, findet auf der Homepage des Java Early Access program den entsprechenden Download von Java 6 Update 10 beta.

Für Ubuntu ist der Austausch folgendermaßen zu bewerkstelligen:

1. Download der Datei.
2. Kommandozeile öffnen
3. bash jdk-6u10-beta-linux-x64.bin
4. Lizenz (lesen und) bestätigen
5. in /usr/lib/jvm das ausgepackte Archiv unterbringen
6. den Link von java-6-sun auf das neue Archiv umbiegen (rm java-6-sun; ln -s jdk1.6.0_10 java-6-sun)

Fertig. Viel Erfolg beim beta testen.

Update:
Sun ist wohl hinter die Ursache gekommen, auch wenn sich der entsprechende Bugreport so ließt als müsse man erstmal Compilerbau gehört haben. Wie so oft gibt es auch nicht nur den einen Bugreport, sondern z.B. auch diesen – aber immerhin es sieht so aus, als sei eine Lösung in Sicht. Und der Bug schon lange – schlummernd – in der Java Codebasis.
Update 2:
Eine weitere Lösung stellt die Verwendung der IBM Java VM dar. Die gibt es inzwischen – endlich – auch als Java 6 Version und für 64 Bit Windows/Linux Rechner. Bei IBM ist für den Java Download eine Registrierung erforderlich. Die Nutzungsbedingungen sind u.U. andere als bei Sun. IBM Java Download.

Die Java Virtual Machine (JVM) crasht mit dem aktuellen Java 6 noch immer unter Ubuntu Hardy Heron.
Der (geringen) Menge an Bugreports und Blogeinträgen nach scheint es sich um ein eher esoterisches Problem mit der JVM zu handeln. Die betroffenen Applikationen wie Eclipse, Azureus sind SWT Applikationen. Vielleicht ist es also doch ein Problem das nicht der Java JVM angelastet werden sollte.
Jedenfalls berichten einige User, dass die JVM Option „-Xint“ geholfen hat – wenn auch alles „etwas“ langsamer wird.
Kein Wunder, -Xint schaltet nämlich die HotSpot Optimierungen der JVM aus. Aber immerhin wäre es ein passbler workaround gegen die permanenten jvm crashes.

Das aktuelle Java JRE (und JDK) scheinen gehörig überarbeitet worden zu sein – leider nicht unbedingt zum Positiven. Wie auch hier oder in den Bug Reports zu lesen ist, gibt es allerlei Abstürze.

Besonders ärgerlich, wenn man mit Eclipse (Europa) arbeiten möchte, und dies beim Projekt bauen oder Mylin initialisieren einfach die Java Virtual Machine tötet. Auch der Wechsel zum OpenJDK, das für Ubuntu verfügbar ist, hat leider keine Abhilfe schaffen können. Auch RSSowl funktioniert nicht richtig – stürzt aber wenigstens nicht ab – es werden einfach keine Feedeinträge angezeigt.

Als workaround empfehlen einige ein Downgrade auf eine ältere Java Version (vorsicht, hier können sich Sicherheitslücken einschleichen!) – oder eine 32bit Version zu verwenden. (Der Bug scheint sich lediglich bei AMD64 bzw. 64bit Intel Architektur auszuwirken.)

Ich versuche es mit dem Angriff nach vorne – Eclipse ganymed, dessen Startlogo fast suggeriert, dass bei „Ganymed“ ein Buchstabe vergessen wurde.

Update:

Also alle guten Vorsätzen und Versuchen haben nicht gefruchtet – allein ein Downgrade der Java Installation auf Ubuntu Gutsy 1.6.0_03 half ein stabiles Java zu erhalten. Da der Bug schon eine Weile bekannt ist, mache ich mir keine großen Hoffnungen, dass bis zum Erscheinen von Hardy Heron das Problem behoben ist.