Advanced JVM Tuning for Low Pause

The standard Java Virtual Machine (JVM) is configured to optimize for throughput. But some systems are more interested in low pause/reduced latency and GC (garbage collection) might be one source of pausing. (you can read an interesting article about what latency means to your business)

I have found a post on GigaSpaces forum providing some possible JVM configurations to optimize on latency:

-Xms2g -Xmx2g -Xmn150m 
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=10 
-XX:CMSIncrementalDutyCycle=50 -XX:ParallelGCThreads=8 
-XX:+UseParNewGC -XX:MaxGCPauseMillis=2000 
-XX:GCTimeRatio=10 -XX:+DisableExplicitGC

Please note that -XX:+UseConcMarkSweepGC has the heaviest impact on performance – decrease of 40%.

The following set of parameters shows 20% better performance than with -XX:+UseConcMarkSweepGC while the pause size still is below 100msec in embedded test with payload 10KB and 100 threads:

-Xms2g -Xmx2g -Xmn150m 
-XX:GCTimeRatio=2 -XX:ParallelGCThreads=8 
-XX:+UseParNewGC -XX:MaxGCPauseMillis=2000 
-XX:+DisableExplicitGC

While I’m pretty sure that most of the applications do no need such an advanced VM configuration, it is interesting to see what strategies are employed when low latency is needed.

Option	Details
-XX:+UseConcMarkSweepGC	Sets the garbage collector policy to the concurrent (low pause time) garbage collector (also known as CMS)
-XX:+CMSIncrementalMode	Enables the incremental mode. (works only with -XX:+UseConcMarkSweepGC)
-XX:+CMSIncrementalPacing	Enables automatic adjustment of the incremental mode duty cycle based on statistics collected while the JVM is running
-XX:CMSIncrementalDutyCycleMin	The percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing is enabled
-XX:CMSIncrementalDutyCycle	The percentage (0-100) of time between minor collections that the concurrent collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.
-XX:ParallelGCThreads	Sets the number of garbage collector threads
-XX:+UseParNewGC	Enables multi threaded young generation collection.
-XX:MaxGCPauseMillis	A hint to the throughput collector that it’s desirable that the maximum pause time is lowed than the given value. (n.b. it looks like this value can also be used with the CMS garbage collector)
-XX:GCTimeRatio	A hint to the virtual machine that it’s desirable that not more than 1 / (1 + GCTimeRation) of the application execution time be spent in the collector
-XX:+DisableExplicitGC	Disables explicit garbage collection calls (System.gc())

There is no need to learn all these flags by heart as you can find them covered in various documents:

• Tuning Garbage Collection
• Java Tuning White Paper
• Garbage Collector Ergonomics
• JVM 1.4.2

If you still need help you can try asking for help on the General Performance Forum.

Advertisement

The definitive guide to Grails

You may say that Grails is just yet another web framework, but this would definitely not be fair. Even if it is a quite young web framework – being now at version 0.4.1 – Grails has learnt a lot from existing Java web frameworks but also from frameworks outside Java space like RoR , Django, etc. I would even say that the fact that Grails is based on Groovy makes it unique to the Java space and I think it may prove its usability quite immediate. These were my reasons that made me start reading the book.

Grails forms just one framework that is driving the movement toward dynamic language-based frameworks. In this sense, anyone who is interested in the dynamic language field, whether you are from a Perl, Ruby, or Python background, would gain something from reading this book, if just to acquire insight into what the alternatives are.
(Graeme Rocher)

Graeme Rocher, the Grails project lead, took the opportunity to write The Definitive Guide to Grails, so that everybody can benefit of his knowledge in developing apps and become an expert in Grails.

As the book starts, you are already told about the rationale behind Grails:

Grails definitely has an ambitious name for being the Holy Grails all application developers have sought so far. But more than having mere ambition, Grails fulfills its promises by letting you be more productive than you could have ever thought.
(Guillaume Laforge)

and a bit further:

The goal of Grails was to go beyond what other languages and their associated frameworks could offer in the web application space. Grails aimed to do the following:

• Integrate tightly with the Java platform
• Be simple on the surface but retain flexibility to access the powerfull underlying Java frameworks and features
• Learn from the mistakes already made on the mature Java platform

However, it is not my intention to take away your pleasure to read the book, but just to point out a couple of things that kept up my interest while scanning it.

The book gets you started with Grails even from the first chapter where you set up your environment and the example application. It is impressive how quick things are working:

1. downloaded the binary distribution and unarchived it in a directory
2. configured the environment (just an environment variable)
3. run grails run-app
4. launch your brower: http://localhost:8080/bookmarks

All these steps and more details about Grails project, project organization are presented in the first chapters of the book. These are meant to make you feel comfortable creating new projects and handling the command line tools, but also to give you a quick introduction to Groovy.

Then the author delves into each Grails details walking you through building the domain and its persistence using GORM, creating web controllers, data binding and control flow, writing Groovy Server Pages using Groovy scriptlets and the extensive set of Grails tags.

One point about Grails controllers that I want to mention its the framework capability to define action interceptors, something that other web frameworks have proved to be a nice approach (see WebWork). Grails benefits of a large number of smart tags, some of them making usage of Ajax very easily. The Chapter 9 talks extensively about this, introducing the reader to before and after call interception, event handling, remote linking, applying effects with the help of sciptaculous JS library.

Aside of detailed each Grails Dynamic Tags, Chapter 8 is presenting the usefulness and usage of layouts and templates talking also about Layout-by-Convention.

Another thing I liked about Grails is the pagination tag, this being introduce in the same Chapter 8: Groovy Server Pages.

The last two chapters of the book are talking about more advanced topics like jobs scheduling, server-side Java integration, Hibernate, Spring, Acegi usage.

The whole book walks you through an interesting and nice app that will make things even easier to understand. All in all, I would say that The Definitive Guide to Grails was a very nice reading and I hope others will find it the same.

Groovy support for JMeter

After watching the excellent presentation on performance testing given by Goranka Bjedov (QA Engineer at Google), my interest on JMeter increased exponentially. Planning for some testing of InfoQ upcoming features (oh yes, we have some surprises on our bag for this beginning of the year) I have giving it a try.
It took me a while to identify the elements involved while creating a scenario (by the way: JMeter name for scenarios: Test plan is not quite correct) and the components to be used, but the online documentation is not so bad.
However, while playing around I have felt the need to create some monitoring scripts (n.b. I am still working on this part). JMeter offers support for BSF and BSH out of the box, but having in mind the release of Groovy 1.0 I thought to try to add Groovy support to JMeter.
So, last night, armed with the Groovy intro chapter from The Definitive Guide to Grails and Groovy in Action [note], I have started my attempt. The task wasn’t easy, but not because of some obvious reasons: different parts of JMeter are using different approaches (like being contributed by completely unrelated people that never looked at the existing code), so deciding how should I write it took me a while. However, in a couple of hours I am having an working version: 2 main classes that are reused for different UI parts and respectively for Groovy integration, an interface to allow extensions and a couple of almost empty classes for each component : PreProcessor, PostProcessor, Listener and Sampler. Total size: 12 classes, aprox. 300 usefull LOC, cca. 500 TLOC. The UI is not so nice but follows the existing JMeter UI (I haven’t done any GUI work in the last couple of years so I am a bit rusty [smile/]). After doing this job, I think most pieces are pretty reusable so integrating other scripting solution like JRuby or even the JDK6 scripting support would be a very easy task.

I am thinking to contribute this code to either JMeter or a Groovy module, but I still need to decide. Meanwhile, let me know if you are interested in this integration.

PS: I am still wondering how can I get my hands on any of the Manning books. I have pinged them a couple of times, submitted a complaint but never heard back from them.

Update: thanks to Dierk Koenig (author of Groovy in Action) and Olivia (from Manning) the above problem seems to start having a solution. Thanks.

From Java5 to Java6 in 200 pages

With the release of Java6, I was looking for a quick introduction of the new things. Indeed, there are plenty of materials out there, disecting each and every small addition or change, but I was looking for a centralized information source. And I’ve found it in the form of the Java6 Platform Revealed book: a 200 page introduction to what is new or updated. What is even more interesting is that most of the things discussed are accompanied by short examples that are giving a bit more than just an overview.
As a teaser, here are the chapters included in the book:

1. Java SE 6 at a Glance
2. Language and Utility Updates
3. I/O, Networking, and Security Updates
4. AWT and Swing Updates
5. JDBC 4.0
6. Extensible Markup Language
7. Web Services
8. The Java Compiler API
9. Scripting and JSR233
10. Pluggable Annotation Processing Updates

Even if you are not gonna need to work with all the aboves, it is always a good idea to know about them and I thinkg that having a place where to look for a short intro is quite cool (f.e. I got a better picture of what scripting inside the JDK is bringing). I have found pretty cool the idea of the tables summarizing deltas between Java5 and Java6 in the form:

Package Version Interfaces Classes Throwable Total
io       5.0      12         50      16+0      78
io       6.0      12         51      16+1      80
Delta              0          1       0+1       2

I am still a bit puzzled by why the Web Services are included in the JDK, but explaining the reasons is not the intend of the book.
Wish you a happy upgrade!

My Eclipse code-folding plugin

I will probably have to start with some apologies for letting you guys wait so long for the plugin I have announced in a couple of previous posts, but (as you probably already know the excuse) I’ve been very busy lately.
However in order to keep things short: here is the download link. It is not a real release, but the version I’ve been tweaking for a while and I am currently using. There are still problems with it, but most of the time it works (or at least using another programmer excuse: it works for me [smile/]). Please give it a try and let me know.

Eclipse code-folding plugin: Coffee-Bytes

In a previous post I was talking about some small changes I have applied to one of the first OSS projects I was a core developer and committer: Coffee-Bytes. After that post, I have received quite a few messages expressing their interest in this plugin and the changes I have done to make it work with Eclipse 3.2.

Lately I have been very busy (speaking at JavaZone and JAOO) and I haven’t been able to do much about it. Still, on this project we were two developers, so before doing anything I will have to discuss these details and see what are the options. However, I promise I will keep everybody interested posted.

category: Eclipse

Type resolution in JVM specification

The JVM spec covers the following details about the lifecycle of a program:

• VM start up
• class and interface loading
• linking
• initialization
• creation of new class instances
• unloading of classes
• VM exit

In this entry, we are interested in detailing how JVM is handling type resolution. Having the following code:

public class EntryPoint {
 public void someMethod() {
   ExternalDependecyClass.callMethod();
 }
}

import not.on.classpath.SomeClass

public class ExternalDependencyClass {
 public static void callMethod() {
   SomeClass cls= new SomeClass();
   // [...] work
 }
}

We are interested in finding out if the spec describes the behavior of the above code when the SomeClass is not found on the classpath (though the compilation was correctly performed).

So, the class EntryPoint is loaded, and it must be initialized before it can be invoked, and a type (class or interface) must always be linked before it is initialized.

Linking step involves:

• verification: checks if the loaded representation is well formed, has a proper symbol table, the bytecode obeys the semantic requiremetns of the JVM
• preparation: involves allocation of static storage and any data structures that are used internally by the virtual machine, such as method tables.
• resolution (optional)

Resolution is the process of checking symbolic references from the loaded class to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct.

The resolution step is optional at the time of initial linkage.

An implementation may resolve a symbolic reference from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from further loading and linking steps.)

This is an eager or static resolution implementation. There is also possible to do the resolution in a lazy way:

An implementation may instead choose to resolve a symbolic reference only when it is actually used; […]. In this case, if the class had several symbolic references to another class, the references might be resolved one at a time or perhaps not at all, if these references were never used during execution of the program.

If the JVM implementation has chosen to use the eager/static type resolution strategy than an exception will be thrown before the program is executed. For the “lazy” type resolution JVMs, an exception will be thrown if and only if the symbolic reference is used.

Now, you may wonder what is the solution. The only approach that will work in any JVM disregarding how the JVM implements the type resolution is to load the classes containing unsatisfied dependencies at the moment the execution needs them through reflection (for example if you are developing a library/framework than you will always have to do it this way because you don’t know on what JVMs the library will be used). But, if you are developing an application that is known to run only on a JVM that used the “lazy” type resolution strategy than the initial code is safe.

As a final note, SUN JVMs (at least 1.4 and 1.5) are using the lazy type resolution strategy.

Reference:
• Loading, Linking, and Initializing

category: JVM

Eclipse API and Code Folding

One of the my first open source projects I have worked on was Coffee-Bytes code folding plugin. It happened a long time ago and at some point the development has been discontinued.

However, tonight, working on some very long sources I have remembered it and I said I should give it a new try. Unfortunately, once I enabled it no editors could been displayed. Checking the .log file I have found the reason: the folding code was broken with a NoSuchMethod exception.

I have found in my archives the last version of the plugin and I thought I should check the API. To my surprise the API was still available (or at least reachable), but what made me post this entry is a feature added in Eclise 3.1: Access Restrictions, according to which when you create a plugin you can restrict others plugin access to its code. While I find the idea quite good (as it makes the API more clear), I have found out that almost everything related to java source code editors is restricted, and I am wondering why? I thought some other plugins would benefit from a clear API (for example AJDT), and now finding this makes me wonder about the reasons (I am quite sure there are good reasons).

However, getting back to the points of this entry, you can read more about Access restrictions: here.

Following the last advise specified at the above link:

But what if you really, really, really, really need to use the class? In that case, you can use it, but you need to be aware of what it means (four really’s usually does it for me).

I have done some small changes to readapt the code and now I have again Coffee-Bytes code folding working on Eclipse 3.2. Just look at the picture to see how reach it is compaired with the default code folding offered by Eclipse:

It offers you folding for:

• top level types
• normal methods
• constructors
• getters and setters
• main methods
• inner types
• static initializers
• import statements
• source headers
• comment blocks
• javadocs

and even User defined code folding:

category: Eclipse

TestNG revamped support for JUnit

I have spent a couple of hours this weekend on a new approach to running JUnit 3.x tests in TestNG

Previously, we have tried to emulate through TestNG the behavior of JUnit and things were quite complex. Also, considering how many extensions are there for JUnit we have never been sure we are able to run all existing JUnit tests.

So, I decided to give it another try and see if I can come out with a better approach. And instead of trying to emulate JUnit runtime behavior, I thought I can handle JUnit tests to JUnit itself and just make it report back the results. After a couple of hours of hacking I got it working and right now I think we will be able to run an even bigger percentage of existing JUnit code. And as a validation of the changes, I have run not only the TestNG tests (almost 300), but also JUnit internal tests (131) and all passed.

This new revamped support for JUnit will be released in the next version, but if you want to challenge it please feel free to build it yourself from the SVN trunk (or drop me an email) and put it to extensive work.

category: Software Testing, Testing, TestNG

TestNG gets a full book chapter

I was happy to discover that TestNG is now covered in a full chapter of the book Beginning POJOs by Brian Sam-Bodden.

The author puts aside JUnit, and introduces the reader to TestNG concepts. After a concise intro, the author builds more complex tests integrating DbUnit and EasyMock (as you may already know EasyMock 2 is already JUnit-free; in previous posts I have started posting ideas about a JUnit-free JMock).

Regarding the examples provided in the book, I have a single remark: having in mind that building a Hibernate SessionFactory is considered an expensive operation, I would use other mechanisms from TestNG that may help running the tests more quickly (by guaranteeing that the SessionFactory is created/initialized only once): @BeforeGroup (guaranteed to run once before a named group of tests), @BeforeTest (which is guaranteed to run once before the tests) or @BeforeSuite (running once before the whole suite).

category: Software Testing, Testing, TestNG, EasyMock