This is a question in regards to non garbage-collected languages (C, C , etc).

I've been told that one of the things that makes C faster than something like C# is the built-in garbage collection having the potential to slow things down. In addition, I've been told there are use cases for keeping deallocated memory on the stack.

As for the latter, I've never been given an example beyond:

Minecraft had issues with performance early on because it was written in Java and not C because of garbage collection.

I'm wondering if any of this has validity, and if there is any reason to not immediately delete any allocated objects as soon as all references to them are lost?

CodePudding user response：

In C/C , allocated memory is never on the stack, with the exception of compilers that provide the alloca() function. In which case, the memory will be freed at the end of the function.

As for performance: a good GC generally runs at the same speed as malloc()/free(). Both methods have overhead, but it's about the same. Obviously, you can always find an exception to the rule. And Java's GC hasn't always been a good GC.

In games, or anything else that synchronizes to video output, you also want to tune the GC to run once per frame, instead of having it trigger at random times. Otherwise, you easily get a stutter every time the GC triggers. That is not because the GC is slow, but because deallocation is delayed until it suddenly happens all at once. It just throws off the timing.

CodePudding user response：

I’m wondering if any of this has validity and if there is any reason to not immediately deleted any allocated objects as soon as all references to them are lost?

That's how all modern GCs work, they only trigger when the memory pressure increase reaches a set threshold (ie too many allocations in a short time, or when your used memory % gets close to the available 100%).

The reason for that is multi-threading. When all threads hold a reference to a piece of memory, moving it around as a result of a garbage collection and compacting pass will let the threads other than the GC's thread use it as normal, so if that becomes the case the GC has to freeze all other threads, do its work, and then unfreeze everything, which is very expensive. So instead it keeps objects alive in memory until there's an actual need for memory to be freed. Memory is there to be used, after all.

Minecraft had issues with performance early on because it was written in Java and not C because of garbage collection

If anything, it probably has issues because Java doesn't have value types and every single integer is an actual class object with everything that implies (managed box with a pointer to the actual data, synchonization mutex fields, etc). This has nothing to do with the garbage collector or with the aforementioned C# however.