Java Technology Community

This is a continuation from the blog post by Rajeev which provided an introduction to the IBM Health Center - Please read more here and the blog post from me which provided an information about Installing and Launching Health Center - Please read more here
Subsystems:
The Status Summary page lists the various subsystems profiled by the Health Center which include Classes, Environment, Garbage Collection, I/O data, Locking, Native Memory and Method Profiling. This page provides a summary of the “health” of the various subsystems. The summary will indicate if there are any potential problems with the particular subsystem (indicated in Red color), or tuning suggestions for optimizing the subsystem further (indicated in Amber) and an indication of a healthy subsystem (with no problems) denoted in Green color.





























Classes Subsystem:
Health Center provides class loading information, showing exactly when a class has been loaded into the Java Virtual Machine (JVM) and whether the class is cached or not (in the Shared Classes Cache). This helps users in determining whether their application is being affected by excessive class loading.

Environment Subsystem:
Health Center uses an 'environment perspective' to provide details of the Java version, Java classpath, boot classpath, environment variables, and system properties. This is particularly useful for identifying problems on remote systems or systems where you are not able to access the configuration details. If the Health Center detects mis-configured applications, it will provide recommendations on how to fix it. For example a debug trace option introduced during development cycle may have been left as is with possible performance implications when moved to production. Environment Subsystem will point to such a scenario.

Garbage Collection Subsystem:
Garbage Collection is the most significant performance bottleneck for Java applications. Tuning GC correctly can potentially deliver significant performance gains. Health Center identifies where garbage collection is causing performance problems and suggests more appropriate command line options.

IO Subsystem:
Health Center uses an 'I/O perspective' to monitor application input or output (I/O) tasks as they run. Users can use this perspective to monitor how many and which files are open, and to help solve problems such as when the application fails to close files.

Locking Subsystem:
Health Center records all locking activity and identifies the objects with most contention. Health Center analyses this information, and uses it to provide guidance about whether synchronization is impacting performance. 

Native Memory Subsystem:
"Native memory" subsystem gives a view of 'Process Virtual Memory' and 'Process Physical Memory' plotted against time with JVM start time as the reference.

Profiling Subsystem:
The Health Center uses a sampling method profiler to diagnose applications showing high CPU usage giving full call stack information for all sample methods. Health Center works without recompilation or bytecode instrumentation and shows where the application is spending its time.

 In the earlier post, I have discussed about the Locking mechanism in IBM J9 VM in Java 5 and Java 6. In this blog post, let us see the changes that are to be introduced in the new Locking mechanism R626.

We have seen that a thread does spinning in the following scenarios

-       When Flat Lock is Busy

-       When Inflated Lock is Busy

-       When native level Lock is Busy

As earlier mentioned, spinning increases efficiency as we are avoiding expensive context switches and also avoiding the need to immediately move to OS calls to manage Locking. However, CPU consumption is not free. If the system is already busy, spinning can eat away some CPU cycles which could otherwise be utilized elsewhere. For locks that are held for longer time, the spinning does not make sense (say the thread spins for a period X. And the lock is typically held for X+Y).

 

The following features are introduced in regard to the above:

Eliminate multiple spin

Disable excessive spinning. Suppose an object monitor which is in inflated mode. When a thread fails to acquire that lock in inflated mode with a spin, it does a spin again on JVM system monitor. 

We are disabling the secondary spinning that we do on JVM system monitors.

-Xthr:secondarySpinForObjectMonitors is the option to disable this feature and enable spin on JVM system monitors.

 

Adaptive Spinning

This feature decides whether spinning is beneficial for certain set of locks and disables if not necessary. This is enabled by default from IBM Java R626.

This feature is achieved by sampling lock acquiring information, whenever there is contention on the lock. It collects data related to hold times (the period for which the lock is held) and Slow percentages (percentage of lock acquires that made the thread wait to the total lock acquires).

Based on heuristic values obtained in our labs about the above entities, J9 JVM will disable spinning on that particular lock, if it is deemed as unnecessary. Once spinning on a lock is disabled, it is done so for the rest of the application run. Sampling will also be disabled too on that lock during that period.

-Xthr:adaptSpin/-Xthr:noAdaptSpin options are used to enable/disable this feature.

 

JAX is a common term used for JAX-B and JAX-WS technologies which are basic building blocks of WebService. WebService is a distributed web application which uses open XML-based standards and transport protocols to exchange data between remote devices. Starting from Java6 the said WebService fundamental classes are bundled within JDK itself. The main intention is to help WebService development instead of using an application container like Tomcat / WebSphere. JDK also bundles a light weight WebService container to host the WebService testing.

 

1) What is JAXB?

 

JAXB is also known as Java API for XML binding. JAXB technology make easier to transform and access data from XML within Java and also to create an XML from the representing Java objects. For JAXB, JDK provides API's (javax.xml.bind), compiler tools (xjc & schemagen) and a framework with implementation that automates mapping between

a) In memory Java Objects to XML

b) XML to in memory Java Object.

a) is commonly called as JAXB marshal while b) is commonly called as JAXB un-marshal. JAXB Marshalling provides a client application the ability to convert a JAXB-derived Java object tree back into XML data form. JAXB Marshalling process can be compared to Object serialization where java object is converted into network friendly way. JAXB Unmarshalling provides a client application the ability to convert XML data into JAXB-derived Java objects. JAXB UnMarshalling process can be compared to Object de-serialization, where network transmitted Object bytes are converted back to Java Objects.

 

JAXB provides an efficient and standard way of mapping between XML and Java Object. Comparing to XML parsing using DOM / SAX, JAXB uses lesser memory footprint. JAXB create objects based on demand and thus uses memory efficiently.

 

2) What are all JAXB Compilers tools?

 

JAXB compilers are used to generated JAXB artifact which are essential during JAXB runtime, for Marshalling and Un-Marshalling.

 

i) xjc : generate fully annotated Java classes from a XML schema file.

usage : xjc [-options ...] <schema file>

 

ii) schemagen : can generate a schema file from JAXB annotated Java classes

usage: schemagen [-options ...] [java source files]

Understanding DNS
Hostname Resolution.
Determining the IP Address of the machine from the Hostname is termed as Hostname Resolution. Every computer (host) has a name. The Hostname should correspond to an IP address mapping stored in local Hosts file or in a database on a DNS Server.
Translating (resolving) machine (and domain) names into the numbers actually used on the Internet is the business of machines that offer the Domain Name Service.
Definition of DNS:
Domain Name System is a hierarchical naming system for computers, services or any resources connected to the internet or a private network.It translates meaningful domain names to IP Addresses. An often-analogy to explain the Domain Name System is that it serves as phone-book for the internet by translating human-friendly computer hostname into IP Addresses.
Methods of Hostname Resolution.
Local hostname    Return value of command hostname or the name configured for the computer.
Hosts file              This name is compared with destination hostname.
DNS Server           This file maps hostname to IP Addresses.
Hostname Resolution on Windows/Linux:
Windows
a) Local hostname, if the destination address is same as local address then IP address for the same is returned and hostname resolution process is stopped.
b) If (a) returns false, then “DNS Client Resolver Cache” is looked upon to check whether it consists of required hostname, if true then IP Address is returned else DNS server is queried to get the IP Address.
Linux
If your application needs to know the IP address of a particular computer. The application requiring this information asks the 'resolver' on your Linux PC to provide this information;
a) The resolver queries the local host file (/etc/hosts and/or the domain name servers it knows about (the exact behavior of the resolver is determined by /etc/host.conf) ;
b) If the answer is found in the host file, this answer is returned;
if a domain name server is specified, your PC queries this machine
The DNS machine already knows the IP number for the required name, it returns it. If it does not, it queries other name servers across the Internet to find the information. The name server than passes this information back to the requesting resolver - which gives the information to the requesting application.
DNS Client Resolver Cache
“DNS Client Resolver Cache” is a RAM based table (dynamically constructed) consisting of entries in the Hosts file and the host names that OS has previously resolved successfully through DNS. Response received from DNS queries are cached for a certain period of time and that period of time is configurable thru the parameter “Time to Live” (TTL).
Managing DNS Resolver cache:
Following command line variables are used to maintain the DNS Resolver cache in Java.
networkaddress.cache.ttl
Specified in java.security to indicate the caching policy for successful name lookups from the name service. The value is specified as integer to indicate the number of seconds to cache the successful lookup.
networkaddress.cache.negative.ttl
Specified in java.security to indicate the caching policy for un-successful name lookups from the name service. The value is specified as integer to indicate the number of seconds to cache the failure for un-successful lookups. A value of 0 indicates never cache. A value of -1 indicates cache forever.
Starting Java 6 the default value for “networkaddress.cache.ttl” is changed to 30 and this can be determined thru the following program:
public class Foo {
public static void main (String[] args) {
System.out.println(sun.net.InetAddressCachePolicy.get());
}
}
Viewing and Flushing DNS Cache
view the contents of “DNS Client Resolver Cache” on windows  ---   Issue ipconfig /displaydns.from command prompt.
Flush the DNS Cache contents on windows                            ---   Issue ipconfig /flushdns from command prompt
Flush the DNS Cache contents on Linux.                                ---  restart the nscd daemon
On Linux the nscd daemon manages the DNS cache.                   To restart the nscd daemon, use the command
                                                                                                 `/etc/init.d/nscd restart`.
Hosts File is a common way to resolve hostname to IP Address through a locally stored text file containing IP-address-to-host-name mappings. The file is resident in /etc/hosts on UNIX platform and systemroot/System32/Drivers/Etc folder on windows.
Hostname resolution in Java.
The inetAddress class provides methods to resolve hostname to IP Address and vice-versa also. Following are the methods that can be used for hostname resolution:
getAddress                                        Returns the raw IP Address for this object.
getAllByName(String host)                  Given the name of host, an array of IP address is returned.
getByAddress(byte[] addr)                   Returns an InetAddress object given the raw IP address
getByAddress(String host, byte[] addr) Create an InetAddress based on the provided host name and IP address
getByName(String host)                       Determines the IP address of a host, given the host's name.
getCanonicalHostName()                      Gets the fully qualified domain name for this IP address.
getHostAddress()                                 Returns the IP address string in textual presentation
getHostName()                                    Gets the host name for this IP address
getLocalHost()                                     Returns the local host.
Simple Program exercising few of the above methods:
import java.net.*;
class InetAddressTest
{
public static void main(String args[]) throws
UnknownHostException {
InetAddress Address = InetAddress.getLocalHost();
System.out.println(Address);
Address = InetAddress.getByName("<Any URL Address>");
System.out.println(Address);
InetAddress SW[] = InetAddress.getAllByName("Any URL Address");
for (int i=0; i<SW.length; i++)
System.out.println(SW[i]);
System.out.println("InetAddress.getCanonicalHostName()"+Address.getCanonicalHostName());
}
}

 This is a continuation from the blog post by Rajeev which provided an introduction to the IBM Health Center - Please read more here

Health Center consists of two parts. An agent that needs to be enabled with the running Java application and an eclipse based client that comes with IBM Support Assistant which needs to be connected to the agent.

The Health Center Client is supported on Windows and Linux x86 operating systems whereas the agent is available for all the IBM supported platforms except HP and Solaris. The agent is shipped with the IBM JDK 5 SR9 and JDK 6 SR3 onwards. The latest agent can be downloaded from the IBM Support Assistant.

The IBM Health Center can be installed from the IBM Support Assistant(ISA). Follow the you tube link (http://www.youtube.com/watch?v=6WjE9U0jvEk)to know about
    1. How to install IBM Support Assistant
    2. How to install Health Center Client
    3. How to launch Health Center Client from IBM Support Assistant

To launch a Java application with the Health Center agent enabled, users need to provide -Xhealthcenter as Java Runtime parameter at the start of the application. For Java 5.0 SR9 and earlier or Java 6.0 SR4 and earlier users need to provide the –agentlib:healthcenter –Xtrace:output=healthcenter.out as Java Runtime parameter before the start of the application.

To launch the Health Center Client from IBM Support Assistant, users need to click on Analyze Problem tab in the Home page of IBM Support Assistant.Select Health Center and Click on Launch. Click on Next to get connection dialog box. Specify hostname, port number and basic authentication (if required) of the machine where the agent is running. Click on Next.

Once the Client is successfully connected users will see the hostname and port number on which the Health Center agent is started. Click on Finish to proceed to Status Summary page.

Last time, I ended on Parent Delegation model and reasons for "Why you should have a custom classloader for your application". Let me dwell on this a bit:
.
In the delegation model, all custom classloaders sit beneath the Application Classloader. I mentioned that when there's a classload requested for a classloader, it should ask its parent to try and load it. Well, the guys who wrote all this magic (a.k.a classloading) thought - "how do we improve this process of 'parent delegation'? "
Answer to that is the Classloader cache.
.
Every classloader has its own cache - which would hold the "defined class structure" of every successful classload it has performed.
So let me change the parent delegation definition a bit now:
.
"when a classload is requested out of a CL, the CL should look for the class structure in its cache . If it finds one, use it. Else, delegate to the parent .. (and they can live happily-ever-after till CNFE doesn't surface!)"
.
How does it help? Well, the very first time for any class - parent delegation is a must .
If the parents fail to load the class, it will come down to the current CL itself. If it finds the class, it goes and stores it in its cache.
So the next time a classload is requested, and say , you found it in the cache - you can use it because you are assured that a parent delegation 'had' occurred sometime in the past for this class .
All is well.
.
So, its handy you remember this when you write your own classloader
Lookup sequence:
CACHE (this.findLoadedClass()) >>> PARENT(super.loadClass()) >>> DISK(this.findClass() and then this.loadClass())
.
sample code :
.

---->
...
Class c = findLoadedClass(name);   //Used to check if the class is already loaded
 
if(c == null) {
        try {
            c = super.loadClass(name);  //ask the parent classloader
        } catch (CNFE) {
        }
        if(c == null)
            c = findClass(name); //else load from disk
    }
    return c;
}
<---

.
So, the classloader cache certainly pips speed of the classloading sequence a bit (not to be confused with Shared Class Cache, which I hope to blog in few days time).
To lessen the tax on the system , the JVM also employs what is called as a Lazy Loading - meaning a classload is initiated at the following times only
i) creation of the first object of that class
ii) first instance of any of the subclasses of this class
iii) any of this class's static field is initialized
.
This way you are assured of classloads of only the required classes. Saves space , saves time.
(Its opposite number is the Eager classloading - recursive loading of all classes referenced in our application - and I believe is used in Real Time applications.. )
.
.
Few things on Class Unloading:
Comes into effect ONLY if there's a custom classloader in your application - because the other three classloader loaded classes are never unloaded.
A class and its classloader are linked through its JVM internal structures. So only when a classloader is out of scope for the JVM will that classloader's classes will be unloaded.
(for more on this, you should attend the webinars on "Understanding Java Memory Management" and "Debugging Classloader Memory Leaks in the WebSphere Application Server" as part of the Java Week)
.
.
CNFE , NCDFE and the other usual suspects are coming soon.. and also some of the debugging techniques we use to find " 'em goons" ..
.
Happy Java Week!

  

In today’s complex and integrated environments, the ability to determine the “health” of an application quickly assumes high importance. The IBM Health Center is a light-weight profiling tool that provides a comprehensive view of the “health” of various subsystems for any Java based application.

Developers, performance engineers and practitioners can use the IBM Health Center tool to quickly identify any performance bottlenecks which is specifically helpful in an agile development environment. Designed to attach to a running Java process to explore what it is doing, how it is behaving, and what you could do to make it happier.

The IBM Health Center attempts to answer some of the following common questions that developers, performance engineers, service personnel and WebSphere administrators often ask:-

What is my Java application doing ?

Why is it doing that ?

Why is my application going so slowly ?

How can I make it go faster ? Is my application scaling well ?

Is our algorithm sensible ?

Do we need to tune the Java Virtual Machine ?

Is my configuration sensible ?

Is the system stable ?

Have I got a memory leak ?

Is the application about to crash ?

Classes, Environment, Garbage Collection, Locking and Method Profiling, Native Memory, I/O are areas of JVM activity which can be viewed and receive recommendations on, from the Health Center tool. The Health Center summary will indicate if there are any potential problems with the particular subsystem (indicated in Red color), or tuning suggestions for optimizing the subsystem further (indicated in Amber) and an indication of a healthy subsystem (with no problems) denoted in Green color

The IBM Health Center not only provides a visualization into the various subsystems of the JVM from a performance and reliability perspective but also provides a set of recommendations that can be applied to alleviate the identified problems. The performance overhead of the tool is negligible and can be deployed on production systems.

The IBM Health Center is available via the IBM Support Assistant framework. (www.ibm.com/software/support/isa/ )

The latest version of Health Center (version 1.3) comes with some very useful new features.  Options are available now in Health Center for you to generate dumps (Heap Dump, System Dump and Java Dump) at Runtime for more detailed analysis. For example, if the Health Center reports increasing heap usage over time and indicates a possible memory leak, you can generate a Heap Dump for further offline analysis.  

Health Center 1.3 now supports enablement of native trace points and the ability to disabling systems selectively to configure data collection to only monitor areas of interest.

An interesting youtube video providing a quick introduction to IBM Health Center: http://www.youtube.com/watch?v=5Tcktcl0qxs

The next couple of blog posts on this subject will cover the steps to install and launching the IBM Health Center and a detailed description of the various subsystems it profiles and provides recommendations on.

 

ORB aka object request broker, is the java implementation of the OMG's CORBA (Common Object Request Broker Architecture) specification, which enables the usage of remote objects usable like the local objects. It also lets objects communicate with each other independent of the platform and languages used to implement those objects.

The ORB is implemented as part of the java virtual machine and plays an integral part in the application server runtime environment. In the client/server communication, the ORB provides primarily the following functionality -
1) Provide a framework for clients to locate the remote objects on the server and invoke requests on them.
2) Manage the connections.
3) Manage the request and response messages to/from the remote Java objects.
4) Marshal/Demarshal, based on the CDR (Common Data Representation) , the messages sent over the wire.
 
Provide a framework for clients to locate the remote objects on the server and invoke requests
 
For a client to be able to successfully locate the remote object on the server, the remote object needs to be "registered to a naming registry" and "exported".  The "bind" call will ensure that the remote object is registered to a naming registry and  "javax.rmi.PortableRemoteObject.exportObject()" will ensure that the remote object is exported i.e. it is ready to be invoked. Once, the client does a look-up, "javax.rmi.PortableRemoteObject.narrow()" will have to be called on the reference returned by the look-up. The object returned by the "javax.rmi.PortableRemoteObject.narrow()" will be used to invoke the remote object.
 
Now lets look at what internally happens in the ORB when an  javax.rmi.PortableRemoteObject.exportObject() -
1) The tie and stub classes associated with the remote implementation are loaded.
2) The tie class to the remote implementation class and tie class to the stub class are cached for future faster look-up.
 
The "javax.rmi.PortableRemoteObject.narrow()" is fairly simple, it just checks whether the object returned by the look-up can be casted to the remote interface i.e. the object should extend javax.rmi.CORBA.Stub and implement the remote interface. The reference returned by the javax.rmi.PortableRemoteObject.narrow()  will be used to invoke the remote function.
 
The stub and tie play a key role in the remote communication. The reference returned by the  javax.rmi.PortableRemoteObject.narrow() is actually a stub. As the stub implements the "remote interface", the implemented remote functions will invoke the ORB to send the data to the server and receive the response from the server. At the server side, the data will be received by the ORB. The ORB will identify the corresponding tie and the tie will invoke the remote function implementation. Once the reply is received, the tie will pass the response data to the ORB and subsequently the data will sent to the stub at the client side.
 
In the next blog, we will explore how the ORB manages the connections.

Since its a java technology week. I start with the post on learning Java. This thing i.e. Karel helps not only learning and understanding Java concepts but it also helps in building Logic through the puzzles that it offers. the more puzzle you solve using this Robot, the more powerful your logic and problem solving ability gets sharpened.

Karel The Robot is a robot simulator that affords a gentle introduction to computer programming. Users write Karel programs and feed them to the simulator to watch them execute.

By solving karel problems you will build your logic and enjoy programming.


<-Karel 



 This is Karels World.








to download karel, click
to install: Download an assignment from clicck(in this assiggnments)
   

Import button

After downloading both the assignment and eclipse IDE, unrar it and open Eclipse.exe, then click on the import button ----------------------------------------------------------------->


Then use the browser to find Assignment-1 folder.When you do so, Eclipse will load the starter project and display its name in the Package Explorer window like this:


Then click on the small triangle and start doing solving the problem.



Q.we will solve a problem from assignment-1 ie CollectNewspaper(the documentation for the problem is available in, handouts-assignment 1)


clip of problem (we have to get the beeper):   

import stanford.karel.*;

public class CollectNewspaperKarel extends Karel{

    public void run(){
          move();
          turnRight();
          move();
          turnLeft();
          move();
          pickBeeper();
    }

    public void turnRight(){
          turnLeft();
          turnLeft();
          turnLeft();
    }
} 

Karels running interface is :








To learn Karel download the book : www.stanford.edu/class/cs106a/book/karel-the-robot-learns-java.pdf

To follow me and know more about programming stuff,

Facebook : http://www.facebook.com/code2learn
Website : http://www.code2learn.com

Here is what I think about the virtual methods in java.

In java, by design and specification, all the non-static, non-private, non-final, non-constructive methods are virtual. This means, the selection of the method to be invoked at a call site will depend on the actual (runtime) type of the invoker object (reciever), rather than its declared (static, compile time) type.

In the case of C++, this is true only when the invoker object is declared as a pointer type, and the method is declared explicitly as 'virtual'. If either of this is false, then the method is resolved (identify and select the definition) always to the definition in the defining class of the declared type of the invoker.

In contrast in java, since there is no pointer, there is no flexibility for methods to exhibit virtual and non-virtual behavior based on the type declaration mode - there is only one way to cite objects, that is through references. And moreover, in JRE implementations, java object looses its connection with the declaring type and gets associated with the defining class. At this point it is imperative that the virtual keyword be removed and designate all the normal methods as virtual.

But how often a program really requires the virtual property? Very rarely. What is the percentage of virtual methods who exercise this feature in a meaningful manner? less than 5%. Even in those cases where multiple subclasses are designed and methods redefined, an efficient programmer will go for an interface (or abstract class) for the base class, which means the base method is pure virtual(abstract), not virtual.

This precisely means that a normal, concrete java method (designed to be virtual) actually utilizing its virtual-ness is a rarest possibility.

Implementing virtual methods is easy in JREs, but their presence make the execution engine incapable of pre-linkage of the method call site, potentially slowing down the performance. In practice, the method resolution has to wait until the execution reaches the call site. Dynamic compilers devirtualize methods up to an extend, by tracing the source of the invoker object in the neighborhood of the call site, but this does not really alleviate the problem, and adds it's own additional computation overhead. One of the potential challenges of JIT today is the inability to perform inter-procedural analysis and compress the code any further owing the extremely delayed method resolutions. A powerful technique called ahead-of-time compilation is rendered ineffective because of the inability to resolve methods in advance.

The decision to qualify all the methods as virtual was not a well thought-out design, instead an un-anticipated side effect. An accidental by-product or an unexpected misfire came out of the pointer-less design.

Here is what I think of Java parameter passing conventions.

At programmer's level, Java is said to pass objects by reference and primitives by value. This means for references, what the callee receives is a  heap address of the object, and the object references themselves are actually passed by value. This also means Java saves some space and effort in copying the entire object onto the subroutine linkage channel (for example stack memory).

By definition, pass by reference means 'a parameter passing convention where the lvalue of the actual parameter (argument) is assigned to the lvalue of the formal parameter.'

When passed by reference, the callee method can manipulate the original object’s attributes, can invoke the methods of the object, can re-new, re-assign and purge the components of a composite object thus passed. These operations affect the original reference of the caller, because we have only one object in the heap, which are pointed to by both of these references.

For destroying an object, the C++ way is to 'delete' the object, and the C way is to 'free' the pointer. If passed by reference or address, both these languages have the flexibility of cleaning the object or a structure from anywhere in the caller-callee chain. The invalidation of an object indirectly invalidates other references or pointers cached elsewhere in the stack locations, and trying to reuse those references or pointers results in a crash.

This is different in java. Since there is no explicit freeing of objects, we rely on null assignment on the reference, which is the only way to force an object cleanup. Even after the callee nullifies an object, the object lives through the caller's reference. This means that an object cannot be freed (or initiated for freeing) from an assignee reference, when the a peer reference is alive, and vice versa.

This may be a conscious design to eliminate bad references and make sure that all the object references are either null or a valid object's address. This is because, in the garbage collection, the memory of unreferenced objects are not really freed into the system, rather kept in the internal free pool, and is still mapped into the process, and if accessed through stale references, such a bad dangling pointer will actually cause more damage than a crash.

But then how to clean up an unwanted java object? Set your object reference to null and wait for a gc to occur? might not work because, if there is a second reference elsewhere in the stacks and registers, consciously or unknowingly, the object is not collected. Consequently, many of the objects the programmer has explicitly discarded will lay remnant in the heap until the last reference of the object also went out of scope. This may be sooner or later, or never.

Many of the memory leaks including the infamous Classloader leaks can be attributed to this 'hidden and under-documented' behavior of java. And this is the very reason we see more OutOfMemoryErrors than NullPointerExceptions.

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.

  

Why do we want to solve problems quickly?

• It means a lower Total Cost of Ownership (TCO) for us and our customers.
• Problem determination and resolution has become a daunting task as more of today’s solutions involve complex collections of products and applications deployed in heterogenous environments
• Developing and deploying new solutions gets delayed by maintenance of diverse existing systems
• 25-50%  of  time is spent in problem determination and resolution
• The skills needed to do manual cross-product problem determination are scarce and expensive.

In this age of complex and integrated systems and short cycle times of deployment, the ability to respond to business demands in a timely manner is becoming critical. Pro-active problem determination, quick and easy access to relevant information, reduced turnaround times on interactions with support organizations are key - client "self assist" is the "buzzword"

Java developers frequently encounter runtime problems during development, migration and post production stages and spend significant amount of time diagnosing and resolving those issues. Quick turnaround for problem determination is a key focus area.

In the recent times a wide array of new tooling has emerged from the IBM Java Technology Center and WebSphere Serviceability teams that enable developers to debug Java Runtime issues in a convenient way. A  key focus area for IBM  is to make the user experience with these tools a convenient one. Tools should be easy to obtain, available from a single source and easy to update. The IBM Support Assistant (www.ibm.com/software/support/isa) is a free local workbench that includes rich features and serviceability tools for quick resolution to problems.  All the Java tools delivered through the IBM Support Assistant provide the capabilities of :

- "Visualization"                           Provide different graphical views for a diagnostic data input (a view of increased java heap usage over time for example)

- "Analysis"                                   Analysis reports based on the data analyzed (analysis of the increased heap usage over time indicating a memory leak for example)

-  "Recommendations"              Recommendations and suggestions to resolve the observed problem (Analysis of heapdumps to identify the cause of memory leak for example)

Some cool Java Runtime tools  to check out are: (all tools available on IBM Support Assistant)

• Garbage Collection and Memory Visualizer 

The 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.

• Memory Analysis Tool (MAT)

Memory Leaks in Java are a consequence of non obvious programming errors - and debugging memory leaks is not an exact science. The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption. The Memory Analyzer was developed to analyze productive heap dumps with hundreds of millions of objects. Once the heap dump is parsed, you can re-open it instantly, immediately get the retained size of single objects and quickly approximate the retained size of a set of objects.

• The IBM® Monitoring and Diagnostic Tools for Java™ – Health Center™

Health Center is a lightweight monitoring tool (with a performance overhead of not more than 2-3%)  which allows running Java™ Vitual Machines to be observed and health-checked. The Health Center enables insights into general system health, application and garbage collection activity. Developers, performance engineers and practitioners can use the IBM Health Center tool to quickly identify any performance bottlenecks which is specifically helpful in an agile development environment. Designed to attach to a running Java process to explore what it is doing, how it is behaving, and what you could do to make it happier.

More  information on these tools can be found at: http://www.ibm.com/developerworks/java/jdk/tools/index.html

*Java is the registered trademark of Oracle Inc.

 Let me start with something I said in my previous post - "The Just-In-Time compilation activity is an investment. To maximize the returns on this investment (RoI), the JIT needs to compile the right methods, at the right time, in the right manner". We can deduce a lot of understanding from this statement.

 

         The last two decades, I would say, have experienced a revolution in the way people think about computer programming. This revolution emanated out of the development and adoption of, moderately to extremely, rich programming languages. Richness spans from something as simple as platform-independence, to something as complex as dynamic typing. Irrespective of the amount of wealth hidden in them, these programming languages have often mandated a robust runtime environment to bolster an effective use of their wealth. Undoubtedly, Java has led this bandwagon and the Java Runtime Environment (JRE) has been constantly maturing to support this phenomenal programming language.

        Java gets most of its applauses for the fact that it is platform-independent. Java code, when compiled, is transformed into something called bytecode. Bytecode is a sequence of software instructions (the Java Virtual Machine has its own, well-defined and universal instruction set; just as how a hardware platform would have). The Java methods that you write are visible to the JRE as bytecode. It is this universally accepted bytecode that imparts the platform-independence to Java. The JRE has a stack-based interpreter that processes one bytecode instruction at a time. Bytecode instructions can be as simple as an add and as complex as a tableswitch -  an instruction that represents a switch statement. While executing a method, the interpreter loops through bytecode, triggering computations. The interpreter is an abstract execution engine that wraps around the physical machine - hardware bundled with the operating system.

        The interpreter hence forms an additional layer of abstraction between the application and the underlying physical machine. Other than platform-independence, this layer also allows the JRE to effectively exercise runtime control over the execution. I shall delve deeper into this in future. For now, it is important to realize that this layer introduces an operational delay and decreases the throughput of the application. This is a side-effect of interpretation. The best approach to work around this side-effect is dynamic compilation or Just-In-Time(JIT) compilation.

        Just-In-Time (dynamic) compilation transforms method bytecode into machine code. The compilation is called dynamic because it happens during application execution, unlike the classical static compilation of C/C++ programs. The unit of JIT compilation is a method. Not an entire class! JIT compilation picks up methods, at runtime, and translates their bytecode into machine instructions. All the subsequent invocations of this method, will not result into bytecode interpretation, but into machine-level execution (just like your statically compiled C/C++ program). The additional interpreter layer is hence peeled off! This leads to a large improvement in the method execution times and increases the application throughput. But there is a certain cost involved in JIT compilation.

        JIT compilation happens parallel to application execution. So, is it an overhead to the application ? Not exactly. JIT compilation is an investment, the return of which is execution speed caused by the peel-off of the interpreter layer. The best candidates for JIT compilation are methods which have been extensively interpreted. They have reached a stage where they deserve to be promoted to machine code. A small investment in the form of compilation will lead to a huge return in the form of an increased speed of execution. But there is a risk involved here. What if a JIT compiled method was never used again ? Will our investment not go in vain ? Yes, it will. So, the JIT compiler should make all the attempts to maximize the returns on this investment. This is possible simply by compiling the right methods, at the right time, in the right way! This is precisely what the IBM J9 Just-In-Time compiler achieves. I plan to discuss how it does so in the subsequent posts.

 

Computers may keep getting faster and more powerful, yet many organizations are still hampered by the inconsistent performance of their systems. While today’s systems are capable of processing most transactions within a matter of milliseconds, there is still a percentage of these transactions that will take an order of magnitude longer to complete, because systems temporarily slow down from extraneous or internal housekeeping operations that may tax system resources.

For a growing number of organizations today, such unpredictability is disruptive, costly and unacceptable. A trading desk at a brokerage firm cannot ensure the integrity of its transactions if some are slowed because of a systems bottleneck. Financial services organizations are under pressure to assure that both front-office and middle-office transactions not only are executed at blazing speed, but also are consistently fast across the board – or else face the scrutiny of regulatory agencies.

That is why real-time processing with determinism – or the ability to deliver predictable, consistent results – is becoming a necessity. Now, thanks to new developments in the market, real-time processing capabilities are available through standardized software solutions that don’t require massive investments in skills or additional hardware.

WebSphere Real Time offers a fast and deterministic version of the world’s best known development language.

Real-Time Java-based applications can be deployed with minimal impact on current configurations – with no need to re-learn a special-purpose language. WebSphere Real Time now makes it simple and affordable for organizations of all types to build out realtime operations with predictable performance.

WebSphere Real Time enables organizations to redirect critical resources to core business requirements rather than expending time and money in supporting customer, low-latency systems.

Programmers no longer have to rely on languages such as C, C++ or ADA 95 for real-time programming. This Java platform now represents a viable alternative environment for highly deterministic, distributed, real-time applications in critical system applications, ranging from command and control, weapons, industrial automation and financial systems to telecommunication infrastructures.

Financial services firms have been buying the latest and greatest technology for years, in an effort to manage an explosion of data, support complex transactions, meet stringent regulatory requirements, and compete in fast-changing markets. Functions such as value weighted average pricing (VWAP), derivatives pricing, and pre- and post-trade short-running analytic programs can benefit from real-time. In this industry, the ability to analyze and leverage the latest and freshest data means competitive advantage. To meet this challenge, firms are embracing high-performance trading and analytics systems.

Enterprises leveraging real-time capabilities can respond more quickly than their competition to new information and changing market conditions. Running their time-sensitive mission critical applications on Real-Time Linux, Java, and WebSphere middleware not only reduces process dispatch latencies, but also gives enterprises the time advantage they need to reduce the risks of financial losses, and retain leadership in their markets.

While financial services organizations are seeing the initial benefits of Real-Time Linux and Java, there are numerous advantages for other industries, from government to healthcare to manufacturing. Real-time processing will provide predictability to applications such as realtime product simulations, language translation, and audio/video streaming, among others. For many industries, the time is NOW to move.

Q Tell us a bit about yourself & your accomplishments.

As a kid, I always had imagined that computers are devices which answer any questions we have, solves any problem we have in life! No wonder this curiosity has put me on a high adrenaline rush, that is still making me  explore the extraordinary field  of computers.
Defining oneself is the hardest thing to do, asked my friends, most of them said I’m just a computer geek, the relative term is always confusing, I would define myself as a person who always likes to face challenges in life and has always tried to do something different. Completing my bachelors in computer science , I was much more adept than the normal curriculum and was more interested in doing new things by my own. Accomplishments indeed is a very relative term! The below are a few noticeable:

• Won the top speaker award in IBM Develothon 2010.
• First prize in State level technical paper presentation conducted by Infosys.
• Gave more than 50 ideas to Google wave, a few did got implemented.
• 201th best contributor in the world of Ubuntu brainstrom.
• Took part in the first ever open-web p2pu course from Mozilla.
• Gold medal in state level debate competition.
• One of the top 100 selected members in Adobe Flex boot camp.
• Mentor approval for GSOC for a true idea called "Ants and Algorithm".

Q. You were announced as the Best Speaker at IBM Develothon 2010, Bangalore, how was the experience?

This was the third time in a row I attended IBM developerWorks Unconference as a speaker, I have seen it evolving. This time there was pre talk voting, where the audience had to decide if they liked to hear someone speak about a particular topic. Crossing over that in itself was a tough task, especially amongst many on-spot entries. It’s always tricky to get the crowd mentality, sometimes the overwhelming preparation is just void and sometimes an extempore wins the crowd!!

Its been quite an epic victory, I was all excited [ most of the time I am when it related to speaking in front of a bombastic crowd ] . I had already updated my social networks as most of them would have saying, “Me selected to be one of the speakers in IBM develothon, wish me luck”, after the pre talk voting. Then when it was for the audience to select who was the best for that day amongst the lot.  It was a roller coaster ride, seeing so many people agreeing with my thoughts. It made me feel elated and got great opportunity to network during the yummy lunch time.
I have blogged it in detail here: http://www.h3manth.com/content/ants-journey-planet-called-ibm

Q. Do you have any favorite technology related websites/books that you can recommend to others?

Websites : {techcrunch, slashdot,news.ycombinator,reedit, mashable,readwriteweb}.com

Books : {founder,coder}@work, Design Patterns: Elements of Reusable Object-Oriented Software, Surely You're Joking, Mr. Feynman! and if you have read that all, for life time reading there is “The Art of Computer Programming (TAOCP)” for all of us :).

Q. What is the best advice you have ever been given?

The best advice, that my mother gave me once was, as humans everyone will have good and bad qualities, learn to see only the good qualities in them, I though it was just a cliche, but when I tried to apply it, I saw a different world all together!

Q. How do you find developerWorks useful ?

The very first article I read on developerWorks was that in the linux section, it was happy read.  Mydeveloperworks is rather drawing my attention these days with many renowned geeks blogging on their expertise. It is indeed a  great repository of good stuff.
It would be more nice if  there is live interaction with everyone on a simple chat application would be fun.

Q. Your blog has a vast amount of great content, what advice would you give a blogger trying to find new stories for their blog and producing new great content everyday?

First and foremost, write on everything you do which is in unison with your blogs genre, have a deadline, be self motivated and never think how others would react. As everyone is unique, we must find our own way and add variety of flavours in all our writings, as of my philosophy is to just write what I have tried, in an particular topic and not to worry about getting traffic into the blog and generating comments and for the fact of it when something is interesting and new, indeed people will like it, but after blogging a new post its much necessary at least for a few of your social media friends to know it, sharing is life.

Blogger block indeed happens to every blogger, few things I have followed is to lead the mind relax in a cool room start brainstorming on a particular topic, do look out for resources if already someone has done it try to think of a better ways of doing it.

Q. How do you wish to see your career shape in future?

Completing my degree in 2009 and a few start-up experience with me, I am eager to ply my potential to the fullest. Moving on  I’m confident enough to rely on my technical and articulation skills to achieve full satisfaction in whatever I get to work on.

Thanks for the candid responses Hemanth!

---

To network with Hemanth visit hemanth.hm