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.

• Parallel and concurrent garbage collectors
• How does garbage collection work?

Enjoy reading.

Today we updated our web site with the new logo of our company and product. We hope you like it.

It is modern, unique, and resembles our company colors. The font is distinct and the X is pretty eye-catching, because it has been carefully designed and crafted to express the uniqueness of Xceptance and it’s product and service offers.

Today we released update 4 of XLT 4.0. You will find all the details about it at the usual place: https://lab.xceptance.de/releases/xlt/4.0.4/. Check out the release notes too. This release addresses minor script developer defects.

As always, updates are free for all customers and all people using XLT despite the license.

When you talk about code styleguides, you often talk about basic formatting. This means you probably already fought the holy war over the curly brackets {} and where to put them.

Of course, the next line is the only right place. A curly bracket is a hermit and does not like to be put next to any other character… 

What is your opinion?

Cartoon courtesy of Geek and Poke under CC-BY-ND-2.0

Today we released a minor update of XLT 4.0. You will find all the details about it at the usual place: https://lab.xceptance.de/releases/xlt/4.0.2/. Check out the release notes too. We mainly fixed some issues around the script recorder, such as start up time and behavior when invisible elements were encountered.

An update of the AWS cloud images will follow in the next hours.

A database error caused several ATMs of the Commonwealth Bank to give away money for free in Australia. Read more at ZDNet. There is another short article about that failure in this news.

Up to 40 Commonwealth Bank Automatic Teller Machines are spewing cash across NSW just hours after suffering a computer error this morning.

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.

So, let’s take a look at the upcoming XLT feature that provides you with more details about garbage collection (GC) without the need to use any external tool to monitor or analyze logs or JVMs runtime behavior.

Perfect GC behavior

This is a chart displays nice memory statistics that indicate absolutely no problems with the garbage collection. As you can see the memory usage (first chart in the image) is alternating but never touching the upper limit. The second chart gives you the times when full garbage collection occurred, basically these are the bad events. Events that block the virtual machine from continuing to run. We should avoid these at any cost… nearly, because a full GC is costly. There was only one full GC right at the beginning at the test. This is a normal JVM behavior. So we seem to have done a pretty good job. No major collection of garbage. Sweat!

There are still the minor collections. Minor collections occur frequently and they reclaim small portions of memory with short living objects. The third charts shows us, that minor collection took about 10 to 30 ms, some spikes up to 70 ms. This is acceptable.

GC with Issues

Ok, let’s have a bad example in comparison. It runs with almost default VM settings. This means just min and max heap were set (Xms256MB/Xmx512MB). You can see clearly that a lot of major collections were running for up to 800 ms each. Also the minor collections were longer.

Clearly, the new charts help you see and fix misbehavior quickly. “What about the settings?” you might ask now. Yes, this example is not very helpful without revealing the difference between both test runs. So, we will give you the settings of the good one. The bad run had only Xms and Xmx set, as mentioned before.

## Set minimum memory to use
-Xms512m

## Set maximum permitted memory
-Xmx512m

## Enable concurrent old GC to avoid sudden long pauses
-XX:+UseConcMarkSweepGC

## When to start GC for the tenured/old area of the memory.
## This has to be low enough to avoid that threads need
## memory and can not get any before the GC has finished.
## This will lower the wait time.
-XX:CMSInitiatingOccupancyFraction=70

That’s really all. The use of the Concurrent-Mark-Sweep-Collector (CMS) is the most important setting. The CMS does not block the main VM worker threads, but collects the garbage concurrently. Because there might be situations were the CMS collector is not fast enough in cleaning up, this means the old space runs out of free memory, we give the CMS a hint with the last line. This line explicitly tells the CMS to start early with the clean up. In this case at a 70% fill level. The default is 96% and way too high.

One last thing. Setting Xms and Xmx to the same number helps the VM to relax because it will not try to get back to the minimal memory limit (Xms) and so it cleans less aggressively.

If you want to lean more about Java Garbage Collection, take a look at this Oracle documents: GC Tuning.

Steve collected a very nice list of QA and testing blogs. 100 + 4 different blogs to take a look at. Check it out: Top 100 Software Testing Blogs.

Today, we released XLT 4.0.1. This is an minor update to XLT 4.0 that fixes five defects. Additionally, it provides some documentation enhancements. You can download the release from here: https://lab.xceptance.de/releases/xlt/4.0.1/. At the same location, you will find the documentation as well as the release notes.

We just published four brand-new screencasts about XLT 4.0, its features, and how to work with them. This is our first attempt to use screencasts as a way of documenting our software. They do not replace the written documentation, of course, but they do provide a quick and easy way to become familiar with XLT.

You might be especially interested in the new Script Developer. Our main feature of XLT 4.0.

The script developer is our approach to write and execute scripts efficiently within Firefox. It is a tool to quickly automate web application, share scripts without the hassle of complicated installations, while maintaining full control over possible other ways to execute scripts. The script developer lays the foundation to run test within the browser, execute scripts during builds, create and run test-driven tests, and, if required, export scripts into Java to unleash the power of a modern programming language.

Enjoy the screencasts and of course feedback is always welcome.