Just found two nice blog entries by Chaotic Java which explain nicely how Java Garbage Collection works. Might be still too much if you have never dealt with the topic before, but good reading for the others.
Enjoy reading.
>
Just found two nice blog entries by Chaotic Java which explain nicely how Java Garbage Collection works. Might be still too much if you have never dealt with the topic before, but good reading for the others.
Enjoy reading.
Today we want to give you a small preview of an upcoming XLT feature. Most of you probably know that XLT features agent statistics. These statistics help you to keep an eye on the health of the test execution engines (agents) to ensure that you do not influence the test results by providing insufficient hardware or by applying no or incorrect settings.
Most modern programming languages are virtual machine based and these machines have knobs you can turn to adjust their behavior according to your requirements. XLT runs on Java and so all the things you might have already learnt from tuning your Java-based servers apply to XLT as well. If you do not have experience in tuning your Java-based servers, you will learn a lot that can be applied to your servers and help you to increase performance.
Continue reading XLT – Garbage Collector details visualized
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.
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:
12345 -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.
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.
Softreferenzen (soft references) in Java sind eine tolle Sache, denn es lassen sich tolle Caches und Notfallszenarien damit bauen. Was kaum jemand weiß, dass Softreferenzen nicht nur im Falle von akuter Speicherknappheit freigegeben werden, sondern durchaus auch früher. Letzteres kann zu unerwarteten Nebenwirkungen führen, speziell mit Blick auf Caching.
Soft references are kept alive longer in the server virtual machine than in the client. The rate of clearing can be controlled with the command line option
-XX:SoftRefLRUPolicyMSPerMB=
, which specifies the number of milliseconds a soft reference will be kept alive (once it is no longer strongly reachable) for each megabyte of free space in the heap.The default value is 1000 ms per megabyte, which means that a soft reference will survive (after the last strong reference to the object has been collected) for 1 second for each megabyte of free space in the heap. Note that this is an approximate figure since soft references are cleared only during garbage collection, which may occur sporadically.
Quelle: JDK 6 Garbage Collection Tuning Guide
Nachtrag: Erwähnenswert ist auch dieser Blogeintrag von Jeremy Manson.