Disable GC entirely

Manu turkeyman at gmail.com
Wed Apr 10 01:57:39 PDT 2013


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.
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/a1297f22/attachment.html>


More information about the Digitalmars-d mailing list