Note on Garbage collection of circular references.

Question:
=========
I have 2 objects; A and B.
A has a reference to B and B has a reference to A.
If A and B are not referenced by any other objects are they eligible for garbage collection?

Answer:
=======
Yes, they will be collected.* Most people think the GC uses reference counting to keep track of referenced objects. In that case, A and B would both have a non-zero reference count and not be collected. Sun's JVM (1.1.x, 1.2) uses a mark-and-sweep algorithm (and I think most others do as well). It starts at a base point (I can't remember off hand what the base point is, it's something like all runnable thread classes) and starts following the references from there (like walking a tree). If something s reachable from a base point it is noted as such. After walking through all references, those not marked as reachable are removed. Since neither A nor B is reachable from the root, they will be removed.
Note that 1.2 introducted concepts such as strong references, weak references, and phantom references. 1.3 has a significantly more complex GC. In all cases however, the above more or less holds true. Sun hs documentation on the new refernce types as well as the HotSpot GC.
*The GC is obviously different in each JVM, but all JVMs I know of can handle this case correctly. There may be some that don't.

Reference:
==========
http://www.coderanch.com/t/322042/Java-General-advanced/java/Garbage-collection-circular-references

Quick steps to get heap dumps in glassfish app Server.

Step-1: export JAVA_HOME=
change ports in setup.xml if required.

Step-2: cd /glassfish

Step-3: chmod -R 777 ./lib

Step-4: ./lib/ant/bin/ant -f setup.xml

Step-5: ./bin/asadmin start-domain domain1
Get pid for the server process.

Step-6: Run following commands.

bash-3.00# kill -3 12617 if 12617 is the pid

bash-3.00# jmap -dump:format=b,file=/tmp/java_app-heap.bin 12617
Dumping heap to /tmp/java_app-heap.bin ...
Heap dump file created

bash-3.00# jhat -J-Xmx326m /tmp/java_app-heap.bin
Reading from /tmp/java_app-heap.bin...
Dump file created Thu Jul 16 20:18:55 PDT 2009
Snapshot read, resolving...
Resolving 1202039 objects...
Chasing references, expect 240 dots................................................................................................................................................................................................................................................
Eliminating duplicate references................................................................................................................................................................................................................................................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

Step-7: Access heap by browsing http://host:7000/

Approach to find memory leaks in Java

Note: Use the latest JDK 6, because it has the latest tools, with lots of bug fixes and improvements. All the later examples assume that JDK6’s bin directory is in the PATH.

Step 1. Start the application.
------------------------------
Start the application as you usually do:
java -jar java_app.jar

Alternatively, you could start java with hprof agent. But this is not required to use jhat and debug for memory leaks. Java will run slower, but the huge benefit of this approach is that the stack traces for created objects will be available which improves memory leak analysis greatly:

java
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9000
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-agentlib:hprof=heap=dump,file=/tmp/hprof.bin,
format=b,depth=10
-jar java_app.jar

When the application is up, perform various actions that you think might lead to memory leaks.

For example, if you open some documents in your app, the memory graph could rapidly go up. If closing the docs and invocation of full garbage collection did not bring the memory back to normal level, there is probably a leak somewhere.You might use jconsole from JDK 6 to see the memory consumption graph to have a clue whether memory leak is present or not:
jconsole
It will pop up a dialog with a list of Java applications to connect to. Find the one with java_app.jar and connect. Also, jconsole allows to invoke full GC providing nice button just for that.


Step 2. Find the application pid.
================================
Find out the application’s process id via:
jps

It will print something like:
15976 java_app.jar
7586 startup.jar
22476 Jps
12248 Main
5437 Bootstrap
In our case the pid is 15976.


Step 3. Dump the heap into file.
================================
Dump heap into the file:

jmap -dump:format=b,file=/tmp/java_app-heap.bin 15976

We just told jmap to dump the heap into /tmp/java_app-heap.bin file, in binary from (which is optimized to work with large heaps). The third parameter is the pid we found in Step 2.

Alternatively, if you started java with hprof agent, you could just use Ctrl-\ on Solaris/Linux or Ctrl-Break on Windows to dump heap into the file, specified in hprof agent arguments.


Step 4. Visualize the heap.
===========================
Use jhat tool to visualize the heap:

jhat -J-Xmx326m /tmp/java_app-heap.bin

Jhat will parse the heap dump and start a web server at port 7000. Connect to Jhat server by pointing your browser to:

http://localhost:7000

And start investigating.

Jhat allows you to see what objects are present in the heap, who has references to those objects, etc.

Here are some tips:
--------------------
* Investigate _instances_, not _classes_.
* Use the following URL to see the instances: http://localhost:7000/showInstanceCounts/
* Use “Reference Chains from Rootset” (Exclude weak refs!!!) to see who’s holding the instance.

******************************************************************************

Good article on dealing with memory leaks

http://olex.openlogic.com/wazi/2009/how-to-fix-memory-leaks-in-java/

JVM parameters for web containers to enable GC logging

-Xloggc:/tmp/gc.log -XX:+PrintClassHistogram -XX:+PrintGCTimeStamps

Easy way of testing class files

If code base is large and takes time to build, we can do the following to quickly test our fix.

1. Build class files in the sub directory where you made code change.

2. Prepare a jar file in the following format:
* Suppose package name is com.sun.identity.authentication for your class file, then create folder structure ~/ws/com/sun/identity/authentication in your workspace. Copy newly built class file into com/sun/identity/authentication. Do jar -cvf ~/test.jar * in your workspace ~/ws.

3. Place the complete path of this jar file like /home/lakshman/test.jar as first entry in classpath of your webserver server.xml file or app server domain.xml

4. Restart container.

Your fix will kick in and you can test your fix.

Java versions to track

Java version history:
http://en.wikipedia.org/wiki/Java_version_history

Unix tip

To reset a file to 0 bytes without making it stale, do
cp /dev/null filename

To find MAC address of a Solaris box, do:
arp host-name
This works for users with no root permission.

Deadlock resolution.

Whenever you hit a web server / app server hang problem because of an hosted web application, you can try the following:

1. Take a thread dump of the process. You can issue "kill -3 pid". The thread dump will be available in the web server errors log file.

2. Most of the threads will be waiting to acquire a lock on particular resource say R1. There will be one thread who had acquired the lock on R1 and probably in the following state.
Doing an indefinite wait on trying to acquire a lock on another resource R2. This lock on R2 could be with another thread that is in the wait queue trying to acquire R1 (OR) R2 will never be available because of resource starvation.

3. All threads have entered into lock.wait() and no notify call to wake up these guys.

Getting threaddump of a Java Process.

Analyzing thread dump is the best way to debug a hanging process.
There are 3 ways to get it.

1. Issue kill -9 command.
For ex: If you have started a Sun Web Server process and if it is hanging because of an web-app deployed in it, you can issue command kill -9 pid where pid is the process id of the child process. Note that there will be two processes. You need to issue this on child process id.

2. Attaching jdb. Refer to the following document for more details.
http://wiki.caucho.com/Thread_dump

3. Using JHAT tool. You need to start web server with JDK 1.6 and above to use this. This can be set in the server.xml file for the variable JAVA_HOME. JHAT is a heap analyzer tool which will give you all info related to the heap of the process in the process address space.