On 10 April 2013 18:07, Dicebot <m.stras...@gmail.com> wrote: > On Wednesday, 10 April 2013 at 06:14:24 UTC, Rainer Schuetze wrote: > >> I'm not sure if these have been proposed already in this long thread, but >> 2 very small patches could help a lot for realtime applications: >> >> 1. a thread local flag to disallow and detect GC allocations >> 2. a flag per thread to specify that the thread should not be paused by >> the GC during collections. >> >> The latter would then put the responsibility on the programmer to ensure >> that no references are mutated in the non-pausing thread that don't exist >> anywhere else (to avoid the collection of objects used in the realtime >> thread). As anything in a realtime thread usually has to be pre-allocated >> anyway, that doesn't put a lot more constraints on it but to ensure having >> references to the pre-allocated data in other threads or global state. >> > > One concept is abused quite nicely in Erlang VM/GC - there is one gc > instance per process(fiber) and it gets own pre-allocated memory pool for > all its needs. That memory is prohibited to escape to other processes. When > process lifespan is short enough (and it is Erlang Way, spawning hell lot > of small processes), true garbage collection is never called, whole memory > block is just sent back to pool on process termination. > > I have tested it few times and such approach allowed to meet some soft > real-time requirements. Don't know if something like that can be abused in > D with its fibers and scope storage class. >
That sounds horribly non-deterministic. What if you have 256mb of ram, and no pagefile, and you fill it up till you have 1mb headroom spare?