Garbage Collection Issue (to beat a dead horse)

[Wonder Giant]

I have seen MANY threads on here about garbage collection and ultimately TweenMax is doing its own collection, but I have a situation that seems to be showing me otherwise (though very slowly leaking).

 

I have a test file setup that is forcing garbage collection (I know this is for debug only), and checking the memory every second:

private function forceClear (event:TimerEvent):void {
		System.gc();
		System.gc();
		try {
		new LocalConnection().connect('gc');
		new LocalConnection().connect('gc');
		} catch (e:*) {}
		trace (getMemory ());
}

private function getMemory ():String {
		var mem:String = Number( System.totalMemory / 1024 / 1024 ).toFixed( 2 ) + 'Mb';
		var time:Number = getTimer();
		var hours:Number = Math.floor (time/3600000)
		var min:Number = Math.floor ((time - (hours * 3600000)) / 60000);

		return String(mem + " | "+ hours + "hr " + min + "min");
}

 

Then my swf has a bunch of particles inside of it that generally do nothing, but will randomly grow:

public function passiveAnim ():void {
	TweenMax.delayedCall (Math.random ()* 140, grow);
}

private function grow ():void {
TweenMax.to (center, .5, {scaleX:centerStartScale + .3, scaleY:centerStartScale + .3, yoyo:true, repeat:1, onComplete:passiveAnim});
}

 

If watch the memory traces I see this:

108.14Mb | 0hr 0min

108.21Mb | 0hr 0min

108.29Mb | 0hr 0min

108.25Mb | 0hr 0min

108.21Mb | 0hr 0min

108.23Mb | 0hr 0min

108.25Mb | 0hr 0min

108.29Mb | 0hr 0min

108.27Mb | 0hr 0min

108.33Mb | 0hr 0min

108.38Mb | 0hr 0min

108.40Mb | 0hr 0min

108.41Mb | 0hr 0min

108.36Mb | 0hr 0min

108.41Mb | 0hr 0min

108.41Mb | 0hr 0min

108.56Mb | 0hr 0min

108.59Mb | 0hr 0min

108.58Mb | 0hr 0min

108.64Mb | 0hr 0min

 

You can definitely see a pattern of growth. But if I turn the tween off, and the particles just sit there my trace is as follows:

109.22Mb | 0hr 0min

109.24Mb | 0hr 0min

109.24Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.23Mb | 0hr 0min

109.22Mb | 0hr 0min

 

It is almost perfectly steady.

 

Any ideas? I can let this thing run for hours and it will climb slowly the entire time.

[Wonder Giant]

Kind of solved it/have another question...

 

My particles had a slight dropshadow applied to them. When i removed the drop-shadow the memory would stay at a semi-consistent level. For whatever reason, using a drop-shadow or cacheAsBitmap will both make the memory increase slowly if I use TweenMax on those objects.

 

So this would obviously indicate that the "cache" from the cacheAsBitmap is being retained in memory. Any idea if it would ever leave, or a way to force it? It doesn't seem to be ever removing itself from memory

[GreenSock]

Hmm...are you sure this is related to GreenSock stuff? Have you tried removing TweenMax from the equation but still tweening the DropShadowFilter (with another method/class) to see if you get the same results? I'm not aware of any such issues and unfortunately I'm traveling at the moment and can't dive into researching it right now.

[Wonder Giant]

No, I am not sure it is TweenMax related. It is interesting that tweening something with a drop-shadow is seemingly causing a memory leak though.

 

I will perform some more tests and report back as soon as I get through this project.