On Feb 16, 11:19 am, Dorioo <[email protected]> wrote: > Disclaimer: Not a java person > > I. I'm experiencing the behavior where, throughout the course of the > day, less and less memory is recovered by garbage collection. As part > of my testing, I switched to the jrockit JVM and used mission > control's memory leak to observe what was happening in memory. > > With over 5 million instances each and 40%+ combined of the heap, I > took a look at the entries of type "java.util.HashMap$entry" and > "coldfusion.runtime.Variable" > > So, I clicked on "show allocation traces" and some of what I saw was: > > A. Allocation Stack Trace for: coldfusion.runtime.Variable > > 54% coldfusion.runtime.LocalScope.bindInternal [LocalScope.java:360] > 35% coldfusion.runtime.LocalScope.bindVariable [LocalScope.java.208] > > B. Allocation Stack Trace for: java.util.HashMap$Entry > > 50% coldfusion.runtime.LocalScope.bindInternal [LocalScope.java:363] > 16% coldfusion.runtime.LocalScope.bindVariable [LocalScope.java.210] > > Again, not a java person, but after seeing that I'm thinking my friend > "local" scope in CF9 is back to bite in me the butt. >
coldfusion.runtime.LocalScope is not related to the new local scope in CF9. It's just a class that gets used for lots of scopes in CF. What are the actual variables that are hanging around in memory? That's more important than the coldfusion.runtime.Variable wrappers that you're seeing. -- Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en
