<div dir="ltr">On 10 April 2013 18:07, Dicebot <span dir="ltr"><<a href="mailto:m.strashun@gmail.com" target="_blank">m.strashun@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, 10 April 2013 at 06:14:24 UTC, Rainer Schuetze wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
1. a thread local flag to disallow and detect GC allocations<br>
2. a flag per thread to specify that the thread should not be paused by the GC during collections.<br>
<br>
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.<br>

</blockquote>
<br></div>
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.<br>

<br>
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.<br>
</blockquote></div><br></div><div class="gmail_extra" style>Actally, now that I think about it though, I do something like this a lot in games.</div><div class="gmail_extra" style>I have a block of memory that only lasts the life of a single frame, any transient allocations go in there, and they are never released, the pointer is just reset and it overwrites the buffer each frame.</div>
<div class="gmail_extra" style>Allocation is virtually instant: void* alloc(size_t bytes) { offset += bytes; return buffer[offset-bytes..offset]; }</div><div class="gmail_extra" style>and releasing: offset = 0;</div><div class="gmail_extra" style>
This is a great realtime allocator! ;)</div><div class="gmail_extra" style>I usually have separate allocation functions to do this, but in D there is the problem that all the implicit allocations (array concatenation/strings/etc) can't have their alloc source controlled :/</div>
</div>