Java Technology Community
Auxilius 060001319X Tags:  collection function pattern java xml programming design garbage 7 schema 2,314 Visits
Java Week - a very informative event being held in this community. Java Week 2 was held from 19th to 23rd September 2011. Every day there are some technical sessions being held on very interesting topics in JAVA. Everyday you get chance to make yourself aware of very interesting technical topics like JEE 6, parallel programming, performance, Java in Cloud, etc.
It was nice to be the part of this event as an speaker in the unconference. I feel privileged to be a speaker in IBM Java Technology Community. It was nice to deliver the talk on Java with Groovy to the interested set of people. As a coordinator of J2EE community in MindTree, it was a great chance to go further in our collaboration with IBM Java Technology Community.
All the sessions in the Java Week 2 were full of information. The session on Java 7 was very interestingly delivered. I came to know about a lot of Java 7 features which can actually be very useful. Garbage collection - one of the very hottest and interesting topic in Java Tech space. The session was on difference policies of garbage collection provided by the IBM JDK. IBM JDK contain some smart GC policies and hence causes better performance.
The unconference was another interesting discussion on different topics like function programming, XML schema design pattern, etc. It was nice to hear from different experts from enterprise development space. Unconference was an brilliant idea introduced in Java Week 2. It was a small discussion on technical topics over 10-15 mins. It was a quick and a heavy dose of information. I really liked it.
I would expect the Java Week 3 coming soon with more exciting topics and events. I am glad to be the part of the Java Week 2 and would be waiting for the next one to come soon.
Debugging Garbage Collection Performance Bottlenecks with GCMV [Garbage Collection & Memory Visualizer]
Garbage Collection is Java's promise of automatic memory management. In Java, developers need not worry about explicitly freeing up the memory they allocated (as is in the case of languages like C) as the Garbage Collection takes care of the same in Java. But the trade-off is performance. Garbage Collection is a Stop The World (STW) process. It means, that while the Garbage Collector is running all the other application threads (also called mutators) are suspended causing no useful work to be done during Garbage Collection. Longer Garbage Collection cycles (aka pause times) may results in performance issues causing the Java application to become sluggish and unresponsive.
When do we need to care about automatic memory management ?
Investing a bit of effort in understanding Garbage Collection can yield big benefits in terms of application throughput and responsiveness.
Garbage Collection logging data is generated using the -verbose:gc command line option which logs all Garbage Collection data to a file.(The performance overhead of enabling this option is negligible)
GCMV (Garbage Collection & Memory Visualizer) is a powerful tool that can be used to analyse verbosegc data. GCMV is available as a plug-in to IBM Support Assistant (ISA). [https://www.ibm.com/developerworks/java/jdk/tools/]
It analyzes verbose GC output to provide plots, summaries and recommendations. The tool profiles heap usage, heap sizes, pause timesThe Garbage Collection and Memory Visualizer is available as a plug-in to IBM Support Assistant (ISA). It analyzes verbose GC output to provide plots, summaries and recommendations. The tool profiles heap usage, heap sizes, pause times and many other properties. Flexibility of comparing multiple logs in the same plots and many views on data (reports, graphs, tables) are available. This is a powerful tool to debug performance bottlenecks in the Java application due to Garbage Collection.
Common GCMV usage scenarios:
– Long periods of pausing or unresponsiveness
– Check heap occupancy and adjust heap size if needed
– Examine GC characteristics, compare different policies
– Heap consumption slowly increasing over time
– Evaluate the general health of an application
Here is what I think of java garbage collection:
In java programs, the use of pointers is forbidden by virtue of a design strategy or a security policy. Without pointers, functions cannot access objects across stack frames, among many other limitations. The inability to pass objects to and from functions will limit the scope of a programming language at large. To remedy this, in java, user defined objects are inherently passed by address (termed as reference), in contrast to C and C++ where passing arguments by their addresses is a volitional choice.
Conventionally, when arguments are passed by value, what the callee recieves is an isolated copy of the passed object. In C, when passed by address, the callee can manipulate the caller's arguments. In C++ the same applies, along with the call by reference. The user objects are normally created on the stack. In cases of producer functions where the function generates and returns an object, the allocation has to be made in the heap (locally created objects cannot be returned from a function, which causes dangling reference). Such cases are not so often, so one can free the object manually which was 'newed'. Two modes of creating user objects are:
Class obj(); => object and the handle created on the stack.
Class *obj = new Class(); => object in the heap, reference on the stack.
In java, without pointers, the language semantics does not allow the above flexibility and we have only one way to create objects – either everything on the stack or in the heap, not both. Creating all the objects on the stack is a bad choice, since objects whose life span is greater than the defining method will be destroyed when the frame is popped off while the function’s return, essentially forbidding methods from returning generated objects, causing java to be an incomplete language. As a workaround, all the objects are created in the heap. Now, as a matter of fact, it is difficult for a programmer to delete all the objects he 'newed' which are quite many, rather most of them.
Hence the garbage and hence the collector.
In a non-java programming paradigm, it is like allocating memory at arbitrary heap locations, and later scanning the entire virtual memory to clean up the filth.
Garbage collection is not a java feature. It is a compromise. A consequence of refraining from pointers. A skillful attempt to mend a defect. An unchecked sun heredity and an unbridled software hypothesis which we carried and dragged all the way along.