Future of memory management in D

Stanislav Blinov stanislav.blinov at gmail.com
Wed Nov 17 07:50:06 UTC 2021


On Wednesday, 17 November 2021 at 07:35:43 UTC, Tejas wrote:
> On Wednesday, 17 November 2021 at 07:25:45 UTC, Stanislav 
> Blinov wrote:
>> On Wednesday, 17 November 2021 at 07:16:35 UTC, Imperatorn 
>> wrote:
>>> What do you mean by "you can't *actually* disable the GC"? 🤔
>>
>> I mean the GC.disable/GC.enable. The spec needs to be WAY more 
>> strict and, well, specific, for those to be of use.
>
> `GC.disable()` disables the running of a collection phase(and 
> runs a collection __only__ when even the OS returns `Out of 
> Memory` error), but allows allocation.

That is not at all how it's documented. "Collections may continue 
to occur in instances where the implementation deems necessary 
for correct program behavior, such as during an out of memory 
condition."
IOW, it's basically allowed to collect anyway whenever, and not 
"__only__ when even the OS returns OoM".

> `@nogc` disables all allocations via the `GC`.

Not talking about @nogc.

> How else do you propose we further formalize these two notions? 
> GC should throw Error if even the OS returns OoM rather than 
> run collection cycle?

If it's disabled - yes. Because "disable" should mean "disable", 
and not "disable, but..." Failing that, it should be renamed to 
"disableBut", and specify exactly when collections may still 
occur, and not wave it off as implementation-defined. I wouldn't 
want to depend on implementation details, would you?


More information about the Digitalmars-d mailing list