How can we detect when Garbage Collection happens?

I can't figure out how to detect when the Garbage Collector does its thing. My app is getting periodic delays of just under 160 ms, I'd like to figure out if those points are when the GC is running. Especially since I disabled the Garbage Collector, and I'm still getting some of those delays.

 

You cannot disable the garbage collector. You can only change to the incremental GC which you can give a try.
GC shows up in the profiler btw.

Even if GC is the culprit, it‘s you generating the garbage, you need to locate the source and to do so the profiler is your best option.

 

Unity says you can disable the garbage collector:
https://docs.unity3d.com/Manual/performance-disabling-garbage-collection.html

We are in a special situation, we have a thread that requires millisecond timing, and we can *never* have the Garbage Collector fire off even once (hardware we are communicating with will throw an error if we ever go 50 ms without a communication). Removing every single memory allocation in the entire project isn't feasible, so disabling garbage collection is the best solution for this, or setting it to manual and calling it only when a certain menu opens.

GC might show up in the Profiler, but our app doesn't work if the Unity Editor is open, because the Editor is connecting to the hardware and keeping our standalone app from using it (and Garbage Collection can't be disabled in the Unity Editor because the "Scripting" namespace isn't accessible in the Editor).

 

Use the profiler and look when the GC runs?

 

We cannot use the profiler, because the profiler only works in the Unity Editor, but if we have the Unity Editor open, it connects to our hardware, which keeps our app from connecting to the hardware (I asked a separate question if the Profiler could be run standalone without the Unity Editor, https://forum.unity.com/threads/can-the-profiler-be-run-outside-of-the-unity-editor.1307508/)

 

Could you try incrementalTimeSliceNanoseconds and set it to such a small number is guaranteed to not spike past what you want? It might not be ideal but might allow of debugging what's causing the spikes.