On 29 April 2012 16:53, Sean Kelly <[email protected]> wrote: > On Apr 29, 2012, at 2:38 AM, Manu <[email protected]> wrote: > > On 28 April 2012 18:16, Peter Alexander <[email protected]>wrote: > >> On Saturday, 28 April 2012 at 09:14:51 UTC, SomeDude wrote: >> >>> On Saturday, 28 April 2012 at 09:12:23 UTC, SomeDude wrote: >>> >>>> >>>> Real time guarantees on a GC is not something we are going to offer >>>> anytime soon anyway. While a minimal library, loosely based on the C >>>> standard library, with some more bells and whistles that could be borrowed >>>> from Phobos, this is a goal that is achievable in a foreseeable future. And >>>> both game developers and embedded programmers would be interested. >>>> >>> >>> Note that Kenta Cho, who wrote fast games in D1, used this approach, and >>> it worked very well for him. >>> >> >> I also write games in D. >> >> My approach is this: use the GC all you want during loading or other >> non-interactive parts of the game and then just make sure that you don't >> use it during gameplay. >> >> GC vs. manual memory allocation is a non-issue for real-time guarantees. >> The simple fact of the matter is that you should be using neither. I also >> don't use malloc/free during runtime because it has the same non-real-time >> problems as using the GC. A single malloc can stall for tens of >> milliseconds or more, and that's simply too much. >> >> Just learn how to write code that doesn't allocate memory. >> >> A bigger problem with GC for games is memory management i.e. controlling >> how much memory is currently allocated, and what systems are using what >> memory. Having deterministic memory usage is preferable for those cases >> because I know that as soon as I delete something that the memory is >> available for something else. I don't get that guarantee with a GC. >> > > I think that basically sums it up. > > I'm interested to know is whether using a new precise GC will guarantee > ALL unreferenced stuff will be cleaned on any given sweep. > I can imagine a model in games where I could: > 1 Use the GC to allocate as much as I like during initialisation > 2 During runtime you never allocate anyway, so disable the GC (this is > when it is important to know about hidden allocations) > 3 During some clean-up, first run the logic to de-reference all things > that are no longer required > 4 Finally, force a precise GC scan, which should guarantee that all > no-longer referenced memory would be cleaned up at that time. > > This would actually be a very convenient working model for games. But it > only works if I know everything that was released will definitely be > cleaned, otherwise I may not be ale to allocate the next level (games often > allocate all memory a machine has within 100k or so). > > > For a use pattern like this, one thing that may work is to add a GC proxy > immediately before loading a level. To unload the level, terminate that GC. >
Interesting work around, although there are many other things that don't get freed from state to state, and things that are shared by both state A and B are best to keep around, save the unload/reload time of that resource (there is always lots of sharing, it adds up). Is it technically possible to have a precise GC clean up all unreferenced memory in one big pass?
