Application.GarbageCollect not clearing memory leak

Target Platforms Mobile
1

First off,

Thanks to everyone that posted their experiences regarding memory leaks.

Having implemented all the forum knowledge that I could find in this ==FIFTH== incarnation of this damn APP I now have all the memory leaks down to a much lower level and a much smaller footprint in general.

However, this time around I tried breaking the APP into SCENES/LEVELS + Application.GarbageCollect at the hope each time I switched it would clear out the remaining memory leaks. No joy.

Let see if I can remember all the techniques that I tried:

  • Got rid of STRING + INT
  • No VAR in functions
  • No FOR EACH
  • Cached anything I needed outside of functions

I started using RESOURCE.LOAD in functions storing to the same var over and over… are there known problems with that?

That is all I can think of.

I think we (perhaps I) should to create a WIKI page that documents all collective knowledge of known memory leak causes (just started figuring out how to use the WIKI).

Should we start here or is there a fairly complete thread floating around?

Thanks.

2

None of those things that you listed cause memory leaks.

Strings are just plain slow, and may cause heap allocations, but won’t leak unless you specifically create a leak.

Int will never, ever leak as it gets allocated on the stack.

Having local variables doesn’t cause leaks.

Foreach doesn’t cause leaks. It sometimes caused heap allocations, but will never, ever leak.

And caching has absolutely nothing to do with memory leaks.

I can’t remember exactly, but if you use Resource.Load then you need to clean up after yourself manually otherwise that WILL cause a leak. Again, I’m not too sure though. Whatever the case is, you shouldn’t be loading the same thing over and over with Resource.Load. Load it once and store it.

3

Hmmm… I am reluctant to research all those threads again… and why a WIKI post is a good idea.

I will have to defer to you for the moment but each one of the above was in fact referenced in some form in a thread though maybe I am not correctly stating the related effects.

Perhaps we will get additional posts to clarify things.

I do appreciate your input though.

Thanks.

4

I think it’s somewhere on this thread below, i remember reading about it last time :stuck_out_tongue:

http://forum.unity3d.com/viewtopic.php?t=30745&postdays=0&postorder=asc&highlight=coroutine&start=15

5

Memory allocation != memory leak. There’s nothing wrong with allocating memory by itself; it’s just that if you do a lot of it in a short time, the garbage collector is going to run more often.

–Eric

6

Well, memory allocations are slow in themselves. IIRC malloc in C takes on average around 100 clock cycles, and I can’t imagine that Mono’s would be any faster, especially as it has to initialize stuff for the GC no doubt.

Even stack allocations are slow on ARM as there are no dedicated push or pop instructions in its architecture IIRC.

But yes, GC running more is also especially bad.

7

That’s true; I was thinking more along the lines that allocating memory doesn’t mean you’re going to eventually run out and crash, like would happen if you were leaking memory.

–Eric

8

I am not sure how the whole process works with garbage collection.

iPhone does not have garbage collection as it uses reference counting and you can either manually release an object or use the auto release pool depending on your needs. If you do not release an object after it has been used (and finished with) then you would have a memory leak.

So is it the case that when garbage collection runs (which can be indeterminate) what it is doing is manually releasing the objects that are no longer referenced ?

Carrying on with this assumption then is it the case that Application.GarbageCollectUnusedAssets(); does a tidy up by manually releasing each of the non referenced or null objects ?

myObject = null; // next time garbage collection runs then
[myObject release]; //claim back the memory

With Application.GarbageCollectUnusedAssets(); is it the case that you are not entirely sure when it will run ?

I am aware that there is an auto Application.GarbageCollectUnusedAssets(); between scenes.

Finally, if you Destroy an object will that once again create a manual release on the next run of the garbage collection ?

thanks - would like to see if my assumptions are correct or not

9

memory leaks is a big issue… for example when you switching between scenes and the memory will rise although the memory was not that much after firs loading the scene

10

One other point (to add to my last post) is that I read that forcing GC should only be done with caution which means its generally to be avoided.

Does the same apply to Application.GarbageCollectUnusedAssets(); which is the equivalent of GC.Collect ?

11

Application.GarbageCollectUnusedAssets has nothing to do with Objective-C allocated memory, or even memory allocated in Mono. It is purely for assets that the Unity engine is managing.

No, just Unity assets. It will no touch your C# objects and especially not your Objective-C objects.

No, it runs when you call it (among other times, as you know).

You mean the Unity engine Destroy(object) function? That will free the memory from that asset and will not need to be garbage collected.

Again, Application.GarbageCollectUnusedAssets is completely separately from the Mono Garbage Collector and also separate from any memory management in Objective-C.

12

GC.Collect runs the Mono GC, not Application.GarbageCollectUnusedAssets().

1 Like
13

Thanks Poita,

so when the reference types I create are null and GC runs, the memory will be reclaimed and this process has nothing to do with (alloc/init) release ?

the app I create runs with the Objective-c wrapped around it ?

14

Have you considered switching to an (nearly) empty screen in between your level scenes? I’ve read that suggestion multiple times. To get from Scene A to B, you switch to Scene C (an empty scene, save for a script which then loads Scene B).

15

CollectUnusedAssets isn’t required on scene switch as it is called on its own.

16

What is the best method to make sure there are no needless references in the “air” …something like gameobject = null for every object ?

17

thats not needed, any unity object that does not have DontDestroyOnLoad will be destroyed on scene switch

nulling unity objects is basically of no use as they still have references as they are engine objects.
Destroy / DestroyImmediate are the way to go here

18

ok thanks…

… im using in following code in my update(recommended by unity), maybe this will help somebody:

	if (Time.frameCount % 30 == 0)
	{
 	  System.GC.Collect();
 	 // Application.GarbageCollectUnusedAssets();
	}