tracker issue : CF-3133682

Duplicate ID:	CF-3119991

Problem Description: Recently, we moved from ColdFusion 8 Enterprise stand alone to ColdFusion 9.01 Enterprise stand alone.  Since then we have had numerous performance and memory usage problems related to long running requests. I’ve sandboxed the problem to CFC instantiation within a loop within a CFM page.  I have confirmed that this is not a VAR problem and that the OUTPUT property within the CFC is set to false. Both of these things can lead to memory leaks. In sandboxing the problem, I’ve taken two identical VMs, one running CF8 and the other CF9.01 Hotfix 2.  In both cases, I’ve switched out the JVM with Oracle JRockit so that I can get real time visibility into JVM memory usage via JRockit Mission Control.  I can see exactly what objects are getting placed on the heap during long running requests.  Switching out the JVM for CF has made no difference in terms of relative behavior between out of the box CF8 and CF9.01 running on Java 1.6.0_17. CF8 is good. CF9 is bad. On both VM’s I run identical code.  I have a CFM page with a loop that runs 20 times. For each iteration, a very small CFC is instantiated 10000 times. During the request, long term GC in CF8 has no problem cleaning up objects and freeing up memory.  For each iteration of the loop, references are cleaned up and the underlying objects removed.  The number and size of the objects on the Tenured Generation of the heap are small.  There’s about 70 MB on the heap after GC. CF9 is a different story. During the request, long term GC will not clean up the references and their objects. CF9 also uses 3x as much memory completing the same request just in terms of object instantiation. As GC will not clean up objects during the course of the request, there’s about 417 MB on the heap prior to the end of the request life cycle. Currently we have a server with 28 Gig of available heap space and we are still getting Out of Memory Errors on some of our long running batch requests.

Steps to Reproduce:  I've attached the sample code in a zip file. Run the code in CF8. During the course of the request run GC within CF Server monitor. Note that memory is reclaimed and overall memory usage is low. Run the same code in CF9. During the course of the request run GC within the CF Server monitor. Note that memory is NOT reclaimed and memory usage is 3x that of CF8. In the attached zip I've included server settings for CF8 and CF9, snapshots of JRockit Mission Control and CF Server Monitor prior to the completion of each request in CF8 and CF9, a JRockit flight recording for CF8 and CF9 (you will need JRockit to view: (http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html), as well as a heap dump for CF9. Please pay special attention to snapshots of JRockit Mission control noting the type and size of objects in CF9 relative to those in CF8.

Actual Result: See above.

Expected Result: During long running requests GC should be able to clean up unused objects on the heap after every iteration of the loop with the CFM. In CF8, this is the case. I CF9, it is not. The size of coldfusion.runtime.NeoPageContext and coldfusion.runtime.Variable is also much, much higher in CF9.

Any Workarounds: We are having to rewrite our code shorten the request lifecyle. What used to be one requests now needs to be broken up in batches causing considerable expense.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3133682

External Customer Info:
External Company:  
External Customer Name: Runrocket
External Customer Email:  
External Test Config: My Hardware and Environment details: Please see attached file. Everything on necessary to recreate the problem has been included. If you have questions you can contact me at 503.685.1871.



Stephen Johnson

Adobe Advanced ColdFusion Certified Developer (ADB184437)

Mentor Graphics Inc.

Attachments:

1. March 09, 2012 00:00:00: 1_Statistics.zip

Comments: