« Very large heaps and caches | Main | The listener pattern evolves »

February 28, 2007

Day 2, large Java heaps

We did more testing today and learned a few more things. First, we did explicit System.GC calls yesterday to time a full GC. This gives a worst case number. A normal full GC is preceded by concurrent mark. This is basically a background tax that starts to be paid when the JVM figures out the heap is nearly full. Threads are started to mark the heap in advance. The JVM tries to time it so that the mark finishes just as the heap fills. This cuts a fair bit of time from the GC pause when compared with an explicit GC like I did yesterday.

We then just studied a worst case type application. We made an ObjectGrid Map with 9GB of data and then started 16 threads to modify random records continously. This resulted a a pretty grim garbage scenario for these initial tests. We had the nursery at 400MB and were seeing 1500ms pauses every 500ms which is pretty brutal.

We studied the results and what we can see on verbose gc was that the flip rate was 54%. This means the nursery consisted of over 200MB of live objects when nursery GC was triggered. We identified some optimizations for ObjectGrid that will allow us to improve the flip rate to 90%, i.e. most objects every flip will be discarded rather than copied over which is the case now.

So, the nett from todays testing is normal GCs are better than explicit ones and we need to try to get the flip rate to 90% for good performance. We're making the optimizations now but we're hoping for a 10x performance improvement with the optimizations. We should see 1500ms drop to around 200ms every second.

I'll post results post optimization in a couple of days. I'm hoping posting all this helps customers doing 64 bit Java applications. I'm getting a lot of help from our J9 team, the JVM team and hopefully some of these tips will help others.

February 28, 2007 | Permalink

Comments

Billy,
At the place where I work (HSBC's technology wing) we want to compare and contrast IBM's dyna-cache caching framework vis-a-vis ObjectGrid, IBM's newer offering in the caching space (HSBC is also a major customer of IBM, BTW).
Does IBM have any literature comparing the pros and cons of dynacache versus ObjectGrid, and when to use what in which scenario?
Does IBM recommend to use ObjectGrid instead of dyncache for newer applications (so that the applications are 'future-proof')?

I have seen some of your postings on other forums comparing ObjectGrid with other open source offerings (http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=13820037&cat=9&thread=118448&treeDisplayType=threadmode1&forum=778#13820037) but no comparison between ObjectGrid and DynaCache itself.

regards,
Sanjeev.

Posted by: Sanjeev Karandikar | Mar 7, 2007 11:25:44 PM

Post a comment