Understanding GC for Memory Problems: Part-2

In earlier part we have seen how memory is allocated to JVM on start up and brief about what GC is, let’s look at what are the parameters are available to tune the Heap size and Garbage collector, to work efficiently.
Normally parameters selected default by JVM helps application to run smooth it is called Ergonomics where it dynamically adjust heap space, but when you require high performance with applications that has high load of concurrent users or large volume of data, The best performance can be achieved in two steps 

1. by tweaking the parameters for the heap size first and then
2. To use appropriate GC collectors for better throughput.

We will see both. There are many parameters available for JVM but I will present only few relevant here. 

To Change Heap Size

-Xmn<n>	Size of young generation. This will not have any effect if NewSize is mentioned.
-xms<n>	Initial size of total heap
-xmx<n>	Maximum size of total heap
–XX:NewSize=<n>	Initial size of young generation.
–XX:MaxNewSize=<n>	Maximum new size of young generation
-XX:PermSize=<n>	Initial Param Size, it is a non heap memory
-XX:MaxPermSize=<n>	Maximum Param Size
-XX:NewRatio=<n>	Ratio of new/old generation size. If NewSize is mentioned then this will be ignored or have no effect. Here it will be calculated as NewSize =(xms/<n>) For e.g. for 120mb heap NewSize will be 40mb if n is 3
- XX:SurvivorRatio=<n>	Ratio of Eden:survivor space. If ignored calculated internally and adjusted dynamically. Default is 8 so if I allocate NewSize = 200mb then survivor will be allocated 25mb each.

If we pass following parameters to JVM at startup see how memory is allocated
export JAVA_OPTS='-server -Xms1175m -Xmx1175m -XX:NewSize=550m -XX:MaxNewSize=550m -XX:PermSize=125m -XX:MaxPermSize=125m'  

note: m stands for size in megabytes  

heap size allocation

Note that if newratio is not mentioned, then Old/tenured size is calculated as (total heap) – (NewSize). Also note that survivorratio is taken as 8 here calculated dynamically  

For sizing Heap try to first find out existing allocation use JMAP/JVISUALVM or other tools for existing sizing. (I have mentioned below note about it) 

 GC Tunning Parameters 

Note + sign invokes multi threaded and – invokes single threaded GC

Used for Parallel Collector	-XX:+UseParNewGC	This flag turns on parallel garbage collection in the young generation. It can be enabled together with the CMS collector in the old generation.
Used for Parallel Collector	-XX:ParallelGCThreads=n	Sets the number of parallel GC threads that the JVM must run for performing garbage collection in the young generation. The default value of n is equal to the number of CPUs on the system.
Used for Parallel Collector	-XX:+UseParallelGC	This flag also turns on parallel garbage collection policy in the young generation; however, it does not work with the CMS collector in the old generation
Used for Parallel Collector/Throughput Collectors	-XX:+UseParallelOldGC	enable parallel compaction for old GC
Concurrent Collector/ low pause collector	-XX:+UseConcMarkSweepGC	This turns on concurrent garbage collection in the old generation
Concurrent Collector	-XX:CMSInitiatingOccupancyFraction= x	Sets the threshold percentage of the used heap in the old generation at which the CMS collection takes place. For example, if set to 60, the CMS collector will be initiated every time the old generation becomes 60% full
other	-XX:MaxTenuringThreshold=x	This switch determines how much the objects may age in the young generation before getting promoted to the older generation. The default value is 31. For a big enough young generation and “survivor space”, the long-lived objects may be copied up to 31 times between the survivor spaces before they are finally promoted to the old generation.This option will be good combination if used with CMS collector.
other	-XX:TargetSurvivorRatio=x	This flag sets the desired percentage of the survivor space heap which must be used before objects are promoted to the old generation. For example, setting z to 90 would mean that 90% of the survivor space must be used before the young generation is considered full and objects are promoted to the old generation. This would allow objects to age more in the young generation before being tenured. The default value is 50. Available from J2SE1.3

  

Points for tuning 

1. Try first Ergonomics — Automatic Selections and Behavior Tuning
2. If you cannot measure the application measure the machine. Means use large size of heap available on the machine that your hardware supports.
3. There is no problem having large heap if you know the GC pauses and are acceptable for application.
4. Swapping memory means starvation, it’s a hell.
5. GC performance is proportion to heap size dedicated to young.
6. Using serial collector (1cpu) make sure you do not allocate more than half of heap size. When using parallel collector it is better to specify desired behavior rather than exact heap size values. Let the collector automatically and dynamically modify the heap sizes in order to achieve that behavior
7. Most cases it is preferred to allocate 40-60 /30-70 ratio to young and old size.
8. Do not allocate more memory to parmgen, its waste… Try to find out how much it uses by accessing application first and then add 20% extra to it. Generally it will be 10-15% for your total heap size. Use jstat or jmap to find usage.

  

Tools to monitor GC performance and heap sizing 

JSTAT : this tool is a command line tool available with JDK5 it provides the GC statistic, helps to understand GC behavior. It can be invoked as below. 

jstat –gcutil <processeid> <n seconds to repeat> <n no of repeats>
e.g.  root$:> /home/jdk/bin/jstat –gcutil 6584  3s 5

Above command will give output as below after every 3 seconds five times

S0	S1	E	O	P	YGC	YGCT	FGC	FGCT	GCT
0.00	12.46	10.96	81.40	39.37	68539	1867.261	183	206.407	2073.667

  

Following is the column headings 

S0/s1 – survivor space, E – Eden, O- Old, P- Permgen, YGC – Young GC, YGCT – YGC Time, FGC – Full GC, FGCT – FGC Time, GCT – Cumulative GC Time. 

JMAP : this tool is a command line tool available with JDK5 it provides heap information allocated to JVM, it also helps to find live objects in the memory by taking heap dump. Command syntax is as follows

jmap –<heap/histo> <processeid>

e.g. 

root$:> /home/jdk/bin/jmap –heap 6584 
root$:> /home/jdk/bin/jmap –histo 6584 
root$:> /home/jdk/bin/jmap –histo:live 6584 

First example gives summery info of heap size allocation and also used and free space info. 

Second and third example gives dump of objects, its instance count and bytes allocated figures, if use “:live” option gives only live objects.   

JVISUALVM: this tool is a visual representation of GC and heap size. 

Read more articles:
More about GC and how it works in detail
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom
http://developers.sun.com/mobility/midp/articles/garbage/index.html 

Different tuning ideas and sizing examples mentioned
http://java.sun.com/performance/reference/whitepapers/tuning.html
http://blogs.sun.com/partnertech/entry/a_short_primer_to_java 

all jvm parameter options
http://blogs.sun.com/watt/resource/jvm-options-list.html
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#PerformanceTuning 

FAQ about GC
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html 

Mislenious
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java

Understanding GC for Memory Problems: Part-1

Hi, I hope everyone knows about most important but ignored part of the JVM is memory management i.e. GC, Garbage Collector that runs behalf of user application. I will present a brief about how GC is being allocated and works, here.

Normally when you run any application without any memory specific parameters to JVM on start-up, it will take his own defaults, and that works fine unless you are doing some fancy things in your code which will blow up memory quickly… JVM allocates heap space to default or user specified. Allocation of heap is arranged as follows

Note that the part which is mentioned as virtual is not being actually allocated but kept reserved, if required.

As you see above total heap size is divided as three major parts

Young (Eden + S0 + s1)	Young has two sub parts Eden and survivor space, Eden is the place where all objects are initially instantiated and allocated, survivor  has two sub parts again (s0 and s1) and is initially left blank and objects are moved from Eden to Survivor after first run of GC called Young GC or YGC. Here it is not actually GCed but they are verified for references are still mentioned or not. if no references are found then GCed.
Tenured / (old)	This is also called as old, Objects are moved here from survivor space that are live, referenced and going to live long enough.
Perm	This area is reserved for loading classes and its metadata information and it’s not GCed by collector.

There are normally two threads run for garbage collections, first one is lightweight and runs on Young/Eden generation it is called Young GC. Another one is major and runs on Old/Tenured generation it is also called as Full GC it traverse entire heap and sweep the space. If your FGC takes more than 98% of time in sweeping the memory and could hardly reclaim 2% of memory you will get out of memory error.

The Java HotSpot VM includes three different collectors, each with different performance characteristics.

• The serial collector is a single thread garbage collection, it is relatively efficient and best-suited to single processor machines. It can be explicitly enabled with the option -XX:+UseSerialGC.
• The parallel collector (also called throughput collector) used for minor collections in parallel, which can significantly reduce garbage collection overhead. It can be explicitly enabled with the option -XX:+UseParallelGC. New compaction feature is added in J2SE5 onwards that allows to perform major collections also in parallel. New Parallel compaction is enabled by adding the option -XX:+UseParallelOldGC .
• The concurrent collector runs on concurrent threads with application running, It is designed to keep garbage collection pauses short. It is useful with medium- to large-sized data sets applications for which response time is more important than overall throughput, It can be enabled with the option -XX:+UseConcMarkSweepGC.

OutofMemoryError is thrown when there is insufficient space to allocate object or your GC is unable to make space available even after sweep, this error do not necessarily imply that there is memory leak, it may be due to insufficient  space allocation at time of configuration of heap for an application. Whenever we get this error try to address it be getting its more information provided along with it.

• Java heap space: This indicates that an object could not be allocated in the heap. Young and Old space is already full. Possible causes would be 1) The issue may be just a configuration problem 2) it could be your application code which might creating some heavy objects/loading large data in memory 3) It also can be possible that your heap is keeping reference of objects that are not need to be referenced for long time (i.e. memory leak) or 4) It can be excessive use of finalizers by the application. This error can be fixed with maximum heap size specified by the –Xmx command line option.
• PeremGen space: This indicates that the permanent generation is full. As described earlier that this is the area of the heap where the JVM stores its metadata of classes. If an application loads a large number of classes you will get this error, then the permanent generation may need to be increased. You can do so by specifying the command line option –XX:MaxPermSize=n, where n specifies the size.
• Requested array size exceeds VM limit: This indicates that the application attempted to allocate an array that is larger than the heap size. For example, if an application tries to allocate an array of 512MB but the maximum heap size is 256MB, then this error will be thrown. In most cases the problem is likely to be either that the heap size is too small or that a bug results in the application attempting to create an array whose size is calculated to be incorrectly huge.

 In second part I will explain more details how heap allocation works and what the parameters available for tuning GC are.

 

References for detail readings:

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom

Bloating behavior of software

Software has tendency to bloat and become unmanageable after a while. The smooth clean software that you were writing in the end is just a huge cloud of a mess at the end of development cycle. The reasons behind this are many. Main culprits can be listed as

• Requirements go on changing. And the set of classes you had thought of well just become programware..(procedural functionalities.. )
• As the scope goes on increasing, multiple people are added. Each has own style of development and thought process.
• Testing cycle keeps on adding bugs that you need to fix. Sometimes they do not have a clean solution.

Now it is a fact that any major software development would bloat. How to control this behavior is really a point that seriously needs to be pondered. Some hints and tips from all my experience are as mentioned below

• Remove all your comments in one shot. If you can write a software piece once you would be able to write it again. Secondly VSS will give you all the necessary history if you keep the habit of writing tag comments in VSS.
• For any normal software forget about optimizations except the obvious ones. The first and foremost importance should be given to write code that is easily readable and understandable by an average programmer community.
• Keep refactoring functions as soon as they start getting beyond a page.
• Keep refactoring your classes as they get functionality not meant for that class.
• Bloating code on pretext of time constraint is self hurting. A bloated code will have thrice the time for fixing as against a well thought of code. Thus the time is self fulfilling.
• Write the unit test cases from requirement first. This will make crystal clear what is required, and most likely to produce good design, coding in first place. It is best if the unit test cases are written by developers themselves.
• Keep your code and functionality description and unit tests in synch with each other. That will save you a lot of time.

Happy coding and enjoy!!

NASSCOM Product Conclave & Expo 2009

Keynote address by Guy Kawasaki at NASSCOM Product Conclave on Oct 27 2009 in Bangalore.

Going With Mobile Virtualization

Mobile virtualization market is undergoing great innovation and change. Mobiles become a smart device with rich functionalities built in along with mobile services. Handset vendors are facing increasing competition pressure to bring rich phones to market. They have started thinking of migrating from proprietary operating system to open source operating system with same level of security and services, which helps them to get market faster. Besides just phone functionality mobiles provides features like music, photos, video, GPRS, data storage capability and also able to run enterprise applications like CRM, bill payments, banking, emailing, browsing, social networking etc and that’s make it more valuable.

What is mobile virtualization?

It is a thin layer of software that is embedded on a mobile phone to decouple the applications and data from the underlying hardware. It is optimized to run efficiently on low power consumption and memory constrains. it removes the dependency and virtualizes the hardware by allowing of same software or device drivers to run on multiple devices.

To whom and how it will benefit?

To Handset manufacturers: Typically a smart phone requires 2 to 3 processors in-built in phones to give rich functionality.

• A baseband processor which enable phone to communicate
• An application processor for running small and enterprise applications
• And a multimedia processor for handling graphics, audio and video things.

All these can be accomplished in just one or two processors instead of having of three which will certainly reduce their development cost and help to get market faster.

To mobile application developers: Here the problem of Operating system and applications, which are closely tied to hardware. Currently programmers have to rewrite every mobile application  for each of various OS including Symbian, Microsoft’s windows Mobile or Google’s Android,  virtualization software would enable a developer  to add application features regardless of operating system, so one can a grab a application written for different OS system and easily can integrate them in one.

To end user: This will benefit to end user in a way that their data can be easily ported from one to another handset. It also helps them to retrieve data more easily when handset is damaged. People who have configured emails, web access or applications can easily migrate entire image to another handset. It is also possible for users to run multiple personalities on same phone.

VirtualLogix Inc, Open Kernel Labs Inc, Vmware are few who have heavily invested in this project two years before to bring this to the market by end of 2012. Hope that virtualization will bring tremendous value addition to the mobile technology. But it is still uncertain and yet to prove.

WhiteHedge Technologies : Software Development Methodology

Software Development Methodology

WhiteHedge Methodology and Models encompasses multiple processes and methodologies to take the surprise out of projects and deliver measurable results for our customers.

WhiteHedge approaches any problem with a proven methodology. Our systematic approach toward solving a problem relies upon informed vision, organized blueprinting, efficient development, effective implementation, technology transfer, and superior maintenance. We recognize that processes and methodology are enablers for the project success; hence we follow processes still remaining flexible.

Our Unique Approach

WhiteHedge Technologies Software Development Methodology

6σ Six Sigma

Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects and improving existing and/or new process. WhiteHedge uses Six Sigma driven approach to develop processes and projects. Working from the business drivers to develop measurable goals for achieving customer expectations.

 

Rational Unified Process- RUP

The Rational Unified Process is a software engineering process that provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

PRINCE 2

PRINCE stands for PRojects IN Controlled Environments. It is a project management method covering the organization, management and control of projects. It is widely used in the UK and most of Europe.

For details please look at:
Software Development Methodology

WhiteHedge Technologies – Services Overview

WhiteHedge Technologies is ISO 9001:2008 certified, forward looking technology company with Customer as the focus. Over the past several years, we have worked with a wide variety of customers ranging from emerging companies to large corporations in developing commercial software products that meet the requirements of highly demanding and competitive markets. At WhiteHedge, we offer a comprehensive set of services to cover the entire life cycle of projects – from conceptualization to commissioning through to decommissioning of applications.

What we believe in:
WhiteHedge believes in forming a close, intensive relationship with its customers. We treat our customers as Partners.
We are committed to our client’s success. We measure our success in terms of achieving measurable and tangible results for our clients.

Welome to WhiteHedge Technologies Blog

Dear Customers, Press, Prospects & Partners,

I am delighted to invite you to our new WhiteHedge Blog. More and more businesses and individuals are relying on social networking to convey and receive information quickly and simply. This blog will enable us to enhance our communication and build closer relationships with customers. Whether it’s the latest news on our cenTTra suite of solutions or news in software services, WhiteHedge looks to educate and inform our customers.
Abhijit Joshi (AJ)

WhiteHedge Technologies
http://www.WhiteHedge.com