The following arguments can be passed to the JVM to gather verbose garbage collection statistics. These can entered in "JVM Arguments" field on the "Java and JVM" settings page in the ColdFusion MX administrator.
-XX:+PrintGCTimeStamps will output time in seconds from application initialization to GC.
-XX:+PrintHeapAtGC will output detailed heap statistics ( Young Generation and Old Generation ) in conjunction with Maximum Permanent Generation statistics.
-Xloggc will log verbose garbage collection, PrintHeapatGC and PrintGCTimeStamps to a file. ( typically in the bin directory, CFusionMX\bin or Jrun4\bin directory ). This argument prints the same information as the -verboseGC switch. However using -Xloggc: is more efficient as it prints directly to a file rather than redirecting the JVM output. Direct file write buffering is more efficient than piped redirect buffering. Also using -verboseGC writes to the default-out.log and is therefore interspersed with ColdFusion related messages making the information unwieldly and hard to parse.
Using these arguments results in a file with the following informational format:
The above gives detailed information on the following:
1. Specific times for specific GC events ( Full or minor garbage collection ) within the application lifecycle - In the above example, 5.248 seconds after Coldfusion MX started, a full GC ran.
2. Size of Objects in the heap before GC and after GC - In the above example, before GC, object size in the heap was 2566K. After a full GC, object size in the heap is 2535K. So 21KB of dereferenced objects were garbage collected.
3. Current size of the heap. Note the heap size changes dynamically. According to an internal algorithm, the JVM will try and free up memory before going to the operating system for more. Although the MAX HEAP size is set to 512MB in the above example, you can see the current heap size is only 13504K.
4. Time required for GC to run - In the above example, full garbage collection took 0.0611974 seconds to complete.
5. Number of GC invocations. In the above example we can see that garbage collection has occurred 13 times. ( combination of both minor and full )
6. Details on the Young Generation, Old Generation and Maximum Permanent Generation size
When ColdFusion MX starts up, all of the internal ColdFusion MX core classes and Java JVM classes and methods are loaded into the Permanent Generation. Cached ColdFuson MX templates are also loaded into the Permanent Generation. Short term lived objects are loaded in the Young Generation and are garbage collected. An example of a short term object would be a local variable. After the page has processed the local variable, the object is dereferenced and is therefore garbage collected. If you were to cache variable data into a shared scope, then it would be promoted from the Young Generation to the Old generation and would reside there until such time ( depending on your shared scope variable settings ) that it would be garbage collected. Therefore, how memory utilization get allocated and deallocated in the HEAP is application specific. Running your application under simulated peak load with a large heap and monitoring memory utilization in your application is the best way to determine the optimal heap setting
In the above example, when broken down further, the numbers are:
1. Young Generation: 0K memory - no objects residing in the Young Generation - Total available memory 7744K
2. Old Generation: 2535K memory - current size of all objects residing in the Old Generation. - Total available memory 5760K
0K + 2535K = 2535K ( YGen + OldGen )
7744K + 5760K = 13504K ( Current size of the heap - See item 3 above )
3. Permanent Generation:
7312K memory - current size of all objects residing in the Permanent Generation.
16384K - current total size of the Permanent Generation ( Note, just like the heap, the Permanent Generation will change dynamically according to the applications need )
The MAX HEAP Size comprises of maximum amount of memory that can be allocated to the Young and Old Generations in combination. The MAX PERM Size comprises the total amount of memory that can be allocated to the Permanent Generation. So total memory required/used could be equated to MAX HEAP + MAX PERM + Memory required by jrun.exe to load the JVM's reflective data. ( The JVM's own class and method objects )
