Because I do not know what is the current state of the Java G1 Garbage Collector, I decided to try G1 with JDK6u20. Somehow I was disappointed because after a short moment of predictable GC performance, the entire VM stopped and some major collection was running. You can easily see that in the charts of that run. Right around 20:09:45, the threads were stopped and the entire VM behaved ugly.

So, the G1 is not yet ready for production, of course nobody stated that it is ready for production. If I read the release notes of JDK6u21 correctly, it delivers plenty of G1 changes, so I might try that soon.

If you want to stay in touch with cutting-edge technology in terms of scalability of databases, high traffic sites, and large storage volumes, you should read these two articles on the new hstack.org blog.

Cosmin Lehene wrote two excellent articles on Adobe’s experiences with HBase: Why we’re using HBase: Part 1 and Why we’re using HBase: Part 2. Adobe needed a generic, real-time, structured data storage and processing system that could handle any data volume, with access times under 50ms, with no downtime and no data loss. The article goes into great detail about their experiences with HBase and their evaluation process, providing a “well reasoned impartial use case from a commercial user”. It talks about failure handling, availability, write performance, read performance, random reads, sequential scans, and consistency.

(via High Scalability)

Jeremy Manson schreibt in seinem Blog über Java Concurrency und interessante Dinge, die in einer JVM passieren, aber meist niemanden interessieren.

Jeremy ist bei Google angestellt und in viele JSR-Prozesse rund um das JDK involviert.

Diese Optionen für das JDK6 sollte man kennen, wenn man dem Garbage Collector bei der Arbeit zusehen will. Speziell für das GC-Tuning sind diese Optionen unerlässlich:

-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintReferenceGC

Details zu den Optionen und zur Auswertung kann man unter GC Tuning oder in der Liste der JDK-Optionen finden.

Wer das Problem hat, dass seine Java-Anwendung – zum Beispiel Freemind oder Visual GC – unter Windows wie in Zeitlupe die Fensterinhalte malt, der sollte mal diesen Parameter ausprobieren:

-Dsun.java2d.noddraw=true

Mehr dazu findet sich bei Sun unter Graphics Performance Improvements.

Wir hatten heute eine kurze Diskussion über Singletons und die Art und Weise ihrer Erzeugung, speziell wenn man sie faul (lazy) erzeugen möchte. Die Wikipedia hat dazu diesen schönen Eintrag – On Demand Holder Idiom:

In software engineering, the Initialization on Demand Holder idiom (design pattern) is a lazy-loaded singleton. The idiom can be implemented in both single-threaded/serial and concurrent environments, but care must be taken to correctly implement the idiom under concurrent conditions.

Ganz besondern wichtig ist die Erklärung, warum Lazy in diesem Fall so und nicht anders funktioniert:

The implementation relies on the well-specified initialization phase of execution within the Java Virtual Machine (JVM); see section 12.4 of Java Language Specification (JLS) for details.

When the class Something is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition LazyHolder within it is not initialized until the JVM determines that LazyHolder must be executed. The static class LazyHolder is only executed when the static method getInstance is invoked on the class Something, and the first time this happens the JVM will load and initialize the LazyHolder class.

Netter Artikel bei Heise Online, auch wenn man den Inhalt nur schwer versteht… selbst als Informatiker hat man da seine Probleme. Angeblich soll das Internet kurz vor Offline in weiten Teilen gestanden haben, weil ein Bedienfehler und mehrere Softwarefehler zusammentrafen.

Routing und Cisco-Zeugs  sind eh nicht jedermanns Sache… übrigens bin ich gegen Firmenmonopole. Cisco beherrscht das Netz durch sein Ausstattungsmonopol. Die meisten grossen Internetprovider und Backbone-Betreiber setzen auf Cisco.

Hoffen wir mal, dass Cisco ausreichend bezahlte Mitarbeiter hat und/oder ausreichend Codereviews macht. Sonst ist es vorprogrammiert, dass mal jemand eine Hintertür für seine Zeit nach Cisco legt.

Für das Sun JDK deutet sich ein neuer Garbage Collector an, der ein anderes Herangehen hat und damit lange  Pausen noch deutlicher als der CMS vermeiden soll. Dem geneigten Leser sei dieser Artikel empfohlen: The Garbage First Collector!

Im JDK 6v14 könnten wir ihn vielleicht sehen. Ich bin schon ganz aufgeregt, da ich mittlerweile oft und viel mit GC-Internas hantiere… keine Wunder bei Lasttests gegen 120 CPUs mit Java drauf.

Heute ist mir beim Testen dieser Javascript-Code über den Weg gelaufen. Ich liege jetzt noch auf dem Boden. Eigentlich ist es ja eher zum Heulen, aber naja:

if(8 < 3)
{
    display.setIndex(1, 8);
}

Aber wer weiss, manchmal werden Sachen einfach true.

Wer sich einen virtuellen Server gemietet hat und sich quält, Java vernünftig zum Laufen zu bringen, dem sei dieser Artikel ans Herz gelegt: Java Web Hosting HowTo – vServer memory and Java heap size trouble.

Java Virtual Machines and Linux virtual Servers do not play well with each other all the time. Some tweaking and configuration will be necessary to get it working and optimize the use of the (memory) resources.

Die VPS / Virtuellen Server haben leider die Angewohnheit, den Speicher als zu gross zu melden. Sie melden den Gesamtspeicher des Hosts und nicht den Speicher des Virtuellen Servers. Deswegen schlägt Java gnadenlos zu, und versucht sich reinzuoptimieren. Die einzige Lösung ist die Limitierung des Speichers schon beim Start von Java mit -Xms und -Xmx, um die Selbstoptimierung von Java zu umgehen.