overwriting a component reference variable

Just a fast question about components and memory so that I can be extra exact for a chapter I'm writing on components. When the cfinvoke tag is used with a component name, the component is instantiated and a method of the component is run. In most cases, there is no reference to the component returned. In other words, it's 'gone'. Is any of the memory used by the template request freed up at the time? If another cfinvoke tag is run, will it use the allocated memory that was used by the previous cfinvoke tag or will it take more memory for the request. Basically, if I have 20 cfinvokes running in a request, will it's memory usage grow for each invoke or will the memory be stable (assuming all of the invokes use the same amount of memory)? If the memory used by a cfinvoke is freed up to be used by other variables or cfinvokes, what about component references that are killed. In other words, if I use cfobject to create a variable containing a reference to a component, will overwriting that variable free up that memory for other us during the template run or is that memory no longer usable with the component still existing in memory but no longer accessible? Yes, strange and probably useless questions, but... Thanks -- Michael Dinowitz

----- Excess quoted text cut - see Original Post for more ----- Components are really no different from any other variables. When no more references to a variable exist, that variable is marked for deletion. It will get deleted when the garbage collection gets around to it. If you invoke a method of a component that doesn't return an instance of that component, the component instance created by using CFINVOKE itself is marked for deletion immediately, I'd expect. But that doesn't mean you'll know when exactly it gets deleted, or that there is a single right answer for when it will be deleted - after all, you can configure the aggressiveness and parallel nature of garbage collection in jvm.config. It's highly unlikely that GC will happen during a specific single page request in such a way to delete component instances created and marked within that same request. So, I'd expect that each invocation within the request will end up allocating its own memory, and that memory won't be reused until sometime after the page request has completed. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite.

Dave, So if your right then a thousand iteration loop with each iteration doing a cfinvoke will cause the template request to keep growing in memory usage. There is no resource re-usage in the request. This also means that the statement "after a method is invoked using cfinvoke, the component instance is destroyed" is not 100% true. It is destroyed, but nothing is gained by the destruction. I was always under the impression that using cfinvoke was 'less costly' than creating a variable to contain a component instance. :( > It's highly unlikely that GC will happen during a specific single page > request in such a way to delete component instances created and marked > within that same request. So, I'd expect that each invocation within > the request will end up allocating its own memory, and that memory > won't be reused until sometime after the page request has completed.

On 10/03/2010 14:19, Michael Dinowitz wrote: > > Dave, > > So if your right then a thousand iteration loop with each iteration > doing a cfinvoke will cause the template request to keep growing in > memory usage. There is no resource re-usage in the request. there is a good reference to the effects of this, apparent memory leaks here: http://www.schierberl.com/cfblog/index.cfm/2006/10/16/memoryLeak_variablesScope > > This also means that the statement "after a method is invoked using > cfinvoke, the component instance is destroyed" is not 100% true. It is > destroyed, but nothing is gained by the destruction. I was always > under the impression that using cfinvoke was 'less costly' than > creating a variable to contain a component instance. :( it is only if you copy the result somewhere that you get the reference that gets saved. YOu can "unsave" it by rewriting the variable the reference is in. ----- Excess quoted text cut - see Original Post for more ----- correct. -- Yours, Kym Kovan mbcomms.net.au

> there is a good reference to the effects of this, apparent memory leaks > here: > http://www.schierberl.com/cfblog/index.cfm/2006/10/16/memoryLeak_variablesScope I wonder if his test has been repeated in CF9. I would expect that what he saw was fixed. If not, then people would be setting component references to "" in every high end application and framework. > it is only if you copy the result somewhere that you get the reference > that gets saved. YOu can "unsave" it by rewriting the variable the > reference is in. But doing so does not free up memory during the request, so the point seems moot, unless the variables scope memory leak Mike mentioned still exists. I just tried to run a 20,000 iteration loop with each iteration instantiating a cfc and invoking a method to run a query (which was stored in the local scope). Nothing returned from the method and no reference to the cfc, the method, or it's data kept. The memory used by CF grew during the whole time the request was running and did not shrink in the least. This implies no memory re-usage within a request, which seems to be the consensus.

> This implies no memory re-usage within a request, > which seems to be the consensus. Did you let it run until you reached the maximum heap space? 20,000 is pretty tame, unless each one somehow can actually claim a good chunk of random memory. A query really is not a good way to test this either, since there is quite a bit of magic behind the curtain that allows CFML access to underlying Java/jdbc logic, so just because you have 20,000 objects each with a query does not mean the JVM is not managing it in some arcane way and wont GC or pagefile when it has to. Try throwing something extreme at it just for fun-- make a new 500K block of random text in EACH bean. I have found that a well tuned JVM will always use most of the heap all of the time in production. GC only happens when needed and then it fills right back up. If something huge is thrown at it, you see the page file activity, and JVM manages to do the task. -- /Kevin Pepperman "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." - Benjamin Franklin

> So if your right then a thousand iteration loop with each iteration > doing a cfinvoke will cause the template request to keep growing in > memory usage. There is no resource re-usage in the request. That would be my expectation. > This also means that the statement "after a method is invoked using > cfinvoke, the component instance is destroyed" is not 100% true. It is > destroyed, but nothing is gained by the destruction. I was always > under the impression that using cfinvoke was 'less costly' than > creating a variable to contain a component instance. :( The ideal response would be to say "marked for deletion" instead of "destroyed". But from the programmer's perspective, the component will not exist. I suspect it is less costly to invoke a method directly, as there is a cost to creating a reference. I don't want to speculate on how much less costly it is, though. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite.

I cannot give a definite answer, but I can hazard a guess!  My understanding of the JVM is that memory is never reclaimed in-process. Instead it is re-claimed the next time GC is run. So in your example with 20 cfinvokes, I would expect a high likelihood that all 20 instances of that object still "exist" in memory when the request is completed but with no hard references.  They will get picked up the next time garbage collection executes. ~Brad Just a fast question about components and memory so that I can be extra exact for a chapter I'm writing on components.