On Friday, 15 January 2021 at 15:50:50 UTC, H. S. Teoh wrote:
DMD *never* frees anything. *That's* part of why it's so fast;
it completely drops the complexity of tracking free lists and
all of that jazz.
That's also why it's a gigantic memory hog that can be a big
embarrassment when run on a low-memory system. :-D
This strategy only works for DMD because a compiler is, by its
very nature, a transient process: you read in source files,
process them, spit out object files and executables, then you
exit. Add to that the assumption that most PCs these days have
gobs of memory to spare, and this allocation scheme completely
eliminates memory management overhead. It doesn't matter that
memory is never freed, because once the process exits, the OS
reclaims everything anyway.
But such an allocation strategy would not work on anything that
has to be long-running, or that recycles a lot of memory such
that you wouldn't be able to fit it all in memory if you didn't
free any of it.
T
Are we talking about the same things here? You mentioned DMD but
I was talking about programs compiled with DMD (or GDC, LDC), not
the nature of the DMD compiler in particular.
Bump the pointer and never return any memory might acceptable for
short lived programs but totally unacceptable for long running
programs, like a browser you are using right now.
Just to clarify, in a program that is made in D with the default
options, will there be absolutely no memory reclamation?
