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