Future of memory management in D

Tejas notrealemail at gmail.com
Wed Nov 17 08:01:13 UTC 2021


On Wednesday, 17 November 2021 at 07:50:06 UTC, Stanislav Blinov 
wrote:

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

Oops
Okay, that's not very nice :(

>> `@nogc` disables all allocations via the `GC`.
>
> Not talking about @nogc.

You can chose to ignore it, but I feel people will bring it up in 
these kinds of discussions anyways

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

Yeah, me neither.

I think such harsh constraints aren't making it in the language 
spec anytime soon. If you want such guarantees then you'll have 
to stick to `-betterC`... but that is only supposed to be used as 
a transition technology, not a dev platform in its own right...

Yeah, D is a no-go for latency-sensitive stuff, I think(Maybe ARC 
+ `@weak` pointers could help... but ARC itself seems far away, 
if even possible...)


More information about the Digitalmars-d mailing list