On Saturday, 15 May 2021 at 18:24:19 UTC, Alain De Vos wrote:
> Thanks, good idea but,
It does not initiate a GC cycle or free any GC memory.
Personally I wish D would re-implement "delete" and make it "just work" like one would assume, but from what I've seen there have been many many debates on that and it isn't going to happen. If the goal is to absolutely squeeze the GC back down after using new or dynamic arrays, I find destroy + GC.free often fails to do the trick (e.g. GC.stats.usedSize remains high). For whatever reason (I glanced at the code but haven't found the magic yet), the deprecated __delete does a more thorough job of making sure that memory actually gets "given up" on a collection cycle (particularly if you invoke it manually with GC.collect(); GC.minimize();. Presumably this isn't a desirable coding behavior, though. In my field (games), I do do something like this after initially loading the data to free up all the unused clutter and scaffolding, but it's very slow to call it every frame if you've been using the GC to create and delete game entities. So like Adam says, standard C malloc/free are probably the best way to go in this case.
import core.stdc.stdlib;
import core.lifetime;
class Foo {}
auto foo = cast(Foo) malloc(__traits(classInstanceSize, Foo));
emplace!Foo(foo, /*constructor args*/);
// ...
destroy(foo);
free(cast(void*)foo);
Another alternative is something like the memutils library:
https://code.dlang.org/packages/memutils
class Foo {}
auto foo = ThreadMem.alloc!Foo(/*constructor args*/)
ThreadMem.free(foo); // calls destroy for you, but can still destroy manually
You'll still need to be very careful about any GC mem that gets allocated within a class like this as it can get lost into the ether and cause permanent bloat.
I've been doing a lot of iteration tests lately across a whole bunch of different memory management solutions and the state of discrete memory management in D for gaming applications is.. not great. I love D, but for all that it's designed to help reduce programmer error, it goes the opposite way once you start breaking free of the GC and having to be extra careful tiptoeing around its edges. Unfortunately I don't like doing the pure @nogc/betterC route either, the GC is still really handy to have when you need it (and are aware that it's being used!), but GC collections during high intensity gaming are unacceptable (and deferring them to some later point doesn't help much either).
Fair warning, I'm not one of the D elite with a deep guru-level knowledge of just precisely how everything is operating under the hood, so part of this may come down to learning better practices, but a problem I see IMO is a perceived lack of support or sympathy for coders who want to use the GC when it's nice, but not have it smack them in the face when it isn't. Even with the various articles and forum threads explaining D's memory options, there's still a general air of "You really should just be using the GC, so enjoy your no-man's land, you're on your own." Whether this is only an unfair perception and matter of documentation, or something that actually needs to be addressed in the language, is beyond simply me to decide, but I think a lot of outsiders coming into D may run into the same situation.
Permalink
Reply
