Garbage Collector API

  • Scripting: Added UnityEngine.Scripting.GarbageCollector API for enabling and disabling the garbage collector on Mono and IL2CPP scripting backends.

Just wondering the use cases and rationale for it, and if it’s leading somewhere…

1 Like

I think it could be usefull if you can disable the cleanup and force it when it is good for you. In many cases you allocate memory on the heap that you do not plan to free up, but the cleanup still triggers, it does not know that it still is used.

1 Like

Being able to control the garbage collector (GC) in some way has been requested by many customers. Until now there has been no way to avoid CPU spikes when the GC decided to run. This API allows you disable the GC and avoid the CPU spikes, but at the cost of managing memory more carefully yourself. I’ve copy-pasted the API docs and manual entry for this API at the bottom to provide more details.

I’m not quite sure what you mean with it leading anywhere, but this isn’t the beginning of any work to remove the GC or otherwise make fundamental changes to how you make games in Unity with MonoBehaviours. This is an on/off switch for the GC to avoid CPU spikes.

If you are interested in how to make high performance games, then the new Entity Component System betas provide a new alternative way of making games in Unity.

You could argue that the current GC behavior does the cleanup when it thinks it is good for you :slight_smile: With this new API you can disable the GC and when YOU think it is a good idea to free up memory in your game, then you can enable the GC, call GC.Collect() and then disable it again.

Current API docs:

Current Manual docs
Will be added to


Any chance of this getting backported into 2017.4 LTS?

“Not supported on WebGL platform and .NET scripting backend.” What is “.NET scripting backend” ? I thought there’s just 2 backends that is mono and IL2CPP :

  • Scripting: Added UnityEngine.Scripting.GarbageCollector API for enabling and disabling the garbage collector on Mono and IL2CPP scripting backends.

Since this is a new feature, there will be no backport to 2017.4 LTS.

When you target Universal Windows Platform (UWP), you can use the .NET Scripting Backend:

1 Like

Okay, fair enough. Thanks for replying.

1 Like

This is great.


Seems to me providing Unity can clean up it’s own allocations such as when you use OnCollisionStay contacts, I could freely use this new feature without ever needing a new garbage collector.

1 Like

Lets break normal expected behavior. Instead of having a GC optimized for many short lived objects lets have a no GC at all. Memory is cheap let it leak. After all everyone is already using object pooling why not script pooling? But lets not use c++ instead lets create a strange beast I will call it unity scripto pattern.

1 Like

This is an thing you can do, not something that's on automatically. It also in no way implies that work has stopped on a generational GC.

So what on earth are you angry about? They made a feature that's not useful for you?


As if Unity will give you so much control when this is called. Lets have one big leaky spike rather then many small ones. Lets just manage memory ourselves but without any of the normal tools. Really this makes no sense unless you feel like making hacky C# scripto.

The question you need to ask yourself why all this trouble instead of using c++;

The use case here is not setting when to call the GC. No it is lets just turn the GC off and leak, great idea bro.

Use C++ then? just link to it in Unity… bro.


Be very very careful with this:) I’ve been playing around with custom collectors in .net core (, and it’s really easy to crash your machine if you don’t have a very good handle on everything that is allocating memory. Whatever you think your object allocation is, it’s more. Plus I hit numerous times where I had an unexpected exception or something cause an alternative code path I hadn’t thought about, resulting in a pattern that took just a couple of minutes to kill my computer.

1 Like

Yep, I’m not planning on touching this for the live game. I will probably use it for editor tools though.

In practice there really wouldn’t be much difference between the two with Boehm. It’s not like a generational collector where you can fine tune the behavior (never mind that .net runtimes don’t expose the knobs to do that, but they are there).

It does make sense. We use C#. It’s garbage collected, that’s not going to change. But being able to manually call when it collects is much better than letting it do it whenever it wants. If we’re going to drop frames because of the GC, being able to control when it happens can result in a much better experience.

I believe the INSIDE had manual GC collection as well. I believe they only called it when you died. They were able to do it this way because they had source access, but now we can do it too.


There are very few built in Unity features that allocate garbage that remain. I can entirely avoid GC regardless if only things like Physics didn't ever allocate on my side...

Only if you know how. And getting to know how to avoid garbage creation isn’t an easy path, nor short.