3 ms·

>with heavy use of GC Game logic can optionally use GC, the engine itself does not. so, it would only be heavy use of GC if you had lots of computationally hea

>with heavy use of GC Game logic can optionally use GC, the engine itself does not. so, it would only be heavy use of GC if you had lots of computationally heavy game logic. If you do, you might not use the GC!

pjmlp 7y ago
Just because it is possible to use GC, one doesn't need to use it all the time, not all platforms have a restricted GC that runs all the time without extra knobs to tune. So just like one would not do malloc() on specific engine code paths, it is possible not to use GC heap allocations as well.
- jstimpfle 7y ago
  > it is possible not to use GC heap allocations as well At this point you're almost doing manual memory management.
  - pjmlp 7y ago
    RAII and arenas are not manual memory management.
    - jstimpfle 7y ago
      I didn't notice the point at which this turned into a discussion about RAII or whatever a GC is in 1990's books' definitions. And why would an arena not be manual memory management if I make explicit allocations that make explicit use of such arena, and I free the arena on a suitable occasion? I'm even likely to write the arena myself, but not necessarily. I have this simple and (in my mind) very useful equation of manual memory management ~ writing code to manage memory. Conversely, GC ~ using an external runtime (such as that in JRE) that helps you to avoid writing any memory management code at the cost of giving up control. Ok, let's lose a sentence about ARC, I don't care if you name it GC or not, and I don't use it. I'm not interested in other pointless taxonomic discussions. Whatever, man.
      - pjmlp 7y ago
        Because many languages with GC do offer the necessary tooling for doing low level memory management if one so desires, while still enjoying some safety. Naturally the anti-GC crowd rather switches to their error prone C code instead. Thankfully that is not where the industry is going, eventually looms will be the dominating force, one generation at a time.

pjmlp 7y ago

Just because it is possible to use GC, one doesn't need to use it all the time, not all platforms have a restricted GC that runs all the time without extra knobs to tune. So just like one would not do malloc() on specific engine code paths, it is possible not to use GC heap allocations as well.

jstimpfle 7y ago
> it is possible not to use GC heap allocations as well At this point you're almost doing manual memory management.
- pjmlp 7y ago
  RAII and arenas are not manual memory management.
  - jstimpfle 7y ago
    I didn't notice the point at which this turned into a discussion about RAII or whatever a GC is in 1990's books' definitions. And why would an arena not be manual memory management if I make explicit allocations that make explicit use of such arena, and I free the arena on a suitable occasion? I'm even likely to write the arena myself, but not necessarily. I have this simple and (in my mind) very useful equation of manual memory management ~ writing code to manage memory. Conversely, GC ~ using an external runtime (such as that in JRE) that helps you to avoid writing any memory management code at the cost of giving up control. Ok, let's lose a sentence about ARC, I don't care if you name it GC or not, and I don't use it. I'm not interested in other pointless taxonomic discussions. Whatever, man.
    - pjmlp 7y ago
      Because many languages with GC do offer the necessary tooling for doing low level memory management if one so desires, while still enjoying some safety. Naturally the anti-GC crowd rather switches to their error prone C code instead. Thankfully that is not where the industry is going, eventually looms will be the dominating force, one generation at a time.