4 ms·
> The whole point of a good mempool is that you malloc once, and only call free when you exit the program So you're describing fork() and _exit(). That's my fa
by jart 3y ago
> The whole point of a good mempool is that you malloc once, and only call free when you exit the program
So you're describing fork() and _exit(). That's my favorite memory manager. For example, chibicc never calls free() and instead just forks a process for each item of work in the compile pipeline. It makes the codebase infinitely simpler. Rui literally solved memory leaks! No idea what you're talking about.
- thradams 3y agoOne issue I see with this approach (compiler leaking memory) is, for instance, if the requirements change and you need to utilize the compiler as a lib or service. For example, if the Cake source is used within a web browser compiled with Emscripten, leaking memory with each compilation would lead to a continuous increase in memory usage. Additionally, compilers often offer the option to compile multiple files. Therefore, we cannot afford to leak memory with each file compilation. Initially I was planning a global allocator for cake source. It had a lot of memory leaks that would be solved in the future. When ownership checks were added it was a perfect candidate for fixing leaks. (actually I also had this in mind)
- jart 3y agoTrue, but with some stuff you just ain't gonna need it. For example, chibicc forks a process for each input file. They're all ephemeral. So the fork/_exit model does work well for chibicc. You could compile a thousand files and all its subprocesses would just clean things up. Now needless to say, I have compiled some juicy files with chibicc. Memory does get a bit high. It's manageable though. I imagine it'd be more of an issue if it were a c++ compiler.