That's fair, although you're not free()'ing 128GB in 0.1ms either :)
The amortized cost of GC is more efficient that malloc/free, but it's traditionally not good for latency sensitive systems due to long pause times causing jank/dropped frames. Now that GC algorithms like ZGC have advanced to give sub ms pause times, you no longer have that worry.
Technically we didn't need ZGC for this to begin with. IBM launched metronome a while back for real-time systems, but it was never as widely available as ZGC.
In a game you should keep allocations during gameplay to a minimum anyways, malloc() is not O(1) is has variable runtime based upon the current layout of free memory. Additionally, long running malloc/free based applications have unfixable memory leaks due to memory fragmentation.
In my opinion there's very few cases where you should be dynamically allocating memory, and not using a garbage collector.
The amortized cost of GC is more efficient that malloc/free, but it's traditionally not good for latency sensitive systems due to long pause times causing jank/dropped frames. Now that GC algorithms like ZGC have advanced to give sub ms pause times, you no longer have that worry.
Technically we didn't need ZGC for this to begin with. IBM launched metronome a while back for real-time systems, but it was never as widely available as ZGC.
In a game you should keep allocations during gameplay to a minimum anyways, malloc() is not O(1) is has variable runtime based upon the current layout of free memory. Additionally, long running malloc/free based applications have unfixable memory leaks due to memory fragmentation.
In my opinion there's very few cases where you should be dynamically allocating memory, and not using a garbage collector.