Disable GC entirely

[Manu]

On 10 April 2013 18:07, Dicebot <m.strashun at 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.
>

Actally, now that I think about it though, I do something like this a lot
in games.
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.
Allocation is virtually instant: void* alloc(size_t bytes) { offset +=
bytes; return buffer[offset-bytes..offset]; }
and releasing: offset = 0;
This is a great realtime allocator! ;)
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 :/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/89d57d20/attachment.html>