4 ms·
I remember running into GOAL and GOOL a ways back and was fascinated with it. One thing I never got good info on was how they handled their memory. Generally ga
by jefftime 8y ago
I remember running into GOAL and GOOL a ways back and was fascinated with it. One thing I never got good info on was how they handled their memory. Generally game developers frown upon garbage collection, so I'd love to find out if GOOL/GOAL did anything to target that specifically. I tried reaching out to one of the developers on his blog about it but never got a response
- white-flame 8y agoIf I recall correctly, they used manual memory management for many things. But regardless of specific tooling, you can still do memory pooling in GC languages just as well as in manual ones. The Lispiness that they took advantage of was metaprogramming via s-expressions, an interactive REPL, and dynamic updating of functions during runtime (which would require some form of GC in function memory footprint, but wouldn't be a drag on normal gameplay timing).
- Liquix 8y agoFrom what I could glean from the GamaSutra link, memory management was one of GOOL/GOAL's weak points: GOAL's ability both to execute code at the listener and to replace existing code in the game at run time introduced the problem of memory usage, and more specifically, garbage collection. As new code was compiled, older code (and other memory used by the compiler) was orphaned, eventually causing the PC to run low on free memory. A slow garbage collection process would automatically occur when available memory became sufficiently low, and the compiler would be unresponsive until the process had completed, sometimes taking as long as 15 minutes.