1. 11
  1.  

  2. 4

    This feels like it’s partway toward reinventing 1970s garbage collection. The remaining steps:

    • rather than each subsystem having an array of objects it gives out, the whole system picks from a single array.
    • now that you only ever give out objects based on their index in the array, you can see which indices are no longer in use and reclaim their space.

    One implementation I read about (in the Smalltalk green book, but I don’t think it was new when it appeared in the documented Smalltalk implementation) was to maintain two handle tables. Periodically, swap to the other table for new allocations, and when objects are accessed migrate them and every object that can be reached from them from the prior table to the new one. When it comes time to swap back to the first table, clear out any objects that are still only found there.

    1. 4

      You’ll find that these systems often use arena/slab allocation–a level loads, and the whole thing is chucked away after the subsystem is shutdown.

      More general GC stuff is usually not of huge interest to game developers, and with good reason.

      1. 3

        There was an article (unfortunately I can’t find a link at the moment because I can’t think of the title or enough search terms to recover it) in the early 1980s suggesting that the short-lived object collector run all the time and the full tracing collector run when the user takes a break, such as when they leave the computer for a coffee. “The user has not yet pressed fire to start the next level” would be an analogous case.

    2. 2

      This sounds a lot like Entity Component Systems

      1. 1

        Entity Component Systems usually utilize this pattern but this pattern doesn’t make an ECS. 👍

      Stories with similar links:

      1. Handles are the better pointers via friendlysock 4 hours ago | 12 points | 5 comments