I know GC moves variables around in memory during compacting phase. I assume GameObjects are no exception. So is there a way to ensure the same memory address for a GameObject throughout the application runtime?
I believe that Unity Objects actually are an exception due to the C++ layer, so this should not be a problem.
But Iâm not 100% sure about this.
1 Like
I believe GameObjects are not collected by GarbageCollecotr in the first place.
They stay in the scene even if you do not reference them from your code.
I dared to hope for game objects to be an exception. 2 opinions in this direction mean a lot. If I find more on this Iâll write in here. Thanks guys.
Though if you spawn new objects without thought you have created a memory leak.
Pooling can mitigate that
Technically, even if GameObjects werenât an exception and were normal C# objects, they wouldnât die automatically.
Because they would still be referenced by the Scene theyâre part of. So even if you let go of a reference, another one would still exist in the scene, and would keep the object alive.
1 Like
Now that Iâm thinking about it, doesnât this mean memory leak? I googled âunity gameobject garbage collectorâ but found nothing special on GameObject. If you or anybody else finds anything please, post a link.
And there are 2 related but distinct matters:
- collecting GameObjectâs as in freeing their memory once theyâre not referenced anymore. This is something out of users reach, handled by Unity.
- relocating or not GameObjectâs in their life (be it infinite). This Iâm hoping to be in usersâ grasp.
No.
Game Objects exist as a part of the scene (except when theyâre prefabs).
Loading the scene, kills previous objects in it. (unless they have a DontDestroyOnLoad flag set)
No, you can kill any GameObject with Destroy(), referenced or not.
And if you want to emulate GC behavior, create a class derived from IDisposable with a reference to a gameobject, and have it kill the gameobject within Dispose.
Personally, I wouldnât bother with that.
1 Like
Are GameObject not GC collected when destroyed and no longer referenced ?
If they stay on scene than this is a serious memory leak.
They stay in the scene. In fact I dont think gameobjects allocate the managed heap. Only their components if not native code. edit: Well the gameobject reference must allocate offcourse, but I wonder if one is created if managed code havent asked for it?
I found these:
talking about the garbage collector flavor used by Unity.
Theyâre old info but Iâm asking if somebody knows if the information is up-to-date for Unity 2019/2020.
Another point: AFAIK Mono framework uses a compacting GC so itâs a little contradiction with the articles.
The most up to date information I remember from various threads about moving to .net core and past hackweeks (somewhere in the 2017-2019 range) posts is that most of unityâs native side assumes that things never move which is why the transition to newer mono/.net versions would take a lot of effort that just now seems to be ramping up.
Mono has historically used the boehm gc before developing sgen. That is why mono now uses a compacting gc but unity is still using boehm due to historical reasons.
Currently it is likely that they are still on the incremental version of boehm (try to find the beta thread for incremental garbage collection somewhere in this forum). Thus currently objects might never be moved but that information might be out of date without trying to verify it.
To answer your initial question: To make sure that a managed object stays where it is you can use GCHandle but I would caution against using it extensively. As I havenât seen what your use case for them would be I canât be more specific.
2 Likes
This thread is way beyond anything Iâm likely to need to worry about but Iâm curious as to why one would want or need to do this⌠Performance optimization? It seems like trying to out-think the garbage collector which is normally way above my pay grade!
Even if this is the case today, utilizing this in your project should get the same caution as taking advantage of any other undocumented behavior of Unity. That is, if Unity isnât making any explicit guarantees about the behavior, donât be surprised when that behavior changes in future versions of Unity without any notice.
Types derived from UnityEngine.Object have two pieces: a C++ part and a C# âwrapperâ. The C++ part holds a reference to the C# part, though for many types this is populated lazily, so e.g. we donât create C# wrappers for Transform components that you never access from C# code.
The C++ part is destroyed using Object.Destroy() or Object.DestroyImmediate, or by operations that explicitly destroy objects (such as unloading a scene), or by what we call the âAsset GCâ (which is a separate garbage collector to the C# one, and can be manually invoked by calling Resources.UnloadUnusedAssets()).
6 Likes
So my guesswork above was on point, nice 