You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it seems the garbage collector is very fast, but still very minimal. When presenting Dao (e.g. at OpenAlt 2015, OpenAlt 2016, on the internet, and personally) I got repeatedly asked about real time capabilities of Dao (because the very minimalistic nature of Dao attracted many embedded and game developers). My answer usually boiled down to a garbage collector, which is in case od Dao more or less predictable with reasonably small stops, but still not built with real time in mind.
Could we add some benchmarks of the garbage collector under high pressure to find statistical boundaries of it's capabilities to determine which systems will be affected by garbage collection and which not? In case the results won't be that good, we might try to adopt some ideas from the real-time garbage collectors (as the linked ones do not support multithreading).
The text was updated successfully, but these errors were encountered:
dumblob
changed the title
Enhancement: use hard real-time garbage collector (useful for games, embedded, etc.)
Enhancement: Use real-time GC, real-time memory allocator, etc. (for games, embedded, etc.)
Feb 22, 2017
Currently it seems the garbage collector is very fast, but still very minimal. When presenting Dao (e.g. at OpenAlt 2015, OpenAlt 2016, on the internet, and personally) I got repeatedly asked about real time capabilities of Dao (because the very minimalistic nature of Dao attracted many embedded and game developers). My answer usually boiled down to a garbage collector, which is in case od Dao more or less predictable with reasonably small stops, but still not built with real time in mind.
Now I noticed that PUC Lua newly uses a "real-time non-copying garbage collection" initially published in ftp://ftp.cs.utexas.edu/pub/garbage/GC93/wilson.ps and later developed further (e.g. https://pdfs.semanticscholar.org/fafe/93e4fc99b4003adbbcdbfa4a1db2061f8e3f.pdf ).
Could we add some benchmarks of the garbage collector under high pressure to find statistical boundaries of it's capabilities to determine which systems will be affected by garbage collection and which not? In case the results won't be that good, we might try to adopt some ideas from the real-time garbage collectors (as the linked ones do not support multithreading).
I also found another quite mature attempt to make a highly efficient garbage collector nobody reviewed and tested. It might be worth taking a look at the ideas. Quad-Color Optimized Incremental Generational Mark & Sweep
The text was updated successfully, but these errors were encountered: