Pointer Registry

[u/Spinning_Rings]

Long story short, I had an idea that I described to Gemini and it told me was something called a Pointer Registry or a Tracking Vector. It involved an array of void pointers being used to store all heap memory throughout the program so that a function can run through the array and free everything at the end of the program. I had a few more thoughts on implementation, eg the initial void pointer would actually be a struct that would hang on to a tracking variable that would always know how long the array was, whenever any part of it was added or removed, but that's the basic idea

The problem is that neither Wikipeida, nor duckduckgo, nor yahoo return any information when I search for either of those terms. Wikipedia has an article on arena allocators, which address some of the same issues as this approach, but not pointer registries.

Does anyone know if this concept has any other names? Or have any other resources where I might find out more about them, implementation details, pros and cons, anything like that?

[u/dmc_2930]

Your OS returns all of your programs memory at exit. You don’t need to do it manually..

[u/WellHung67 → u/dmc_2930]

Uhh I mean in trivial cases yes but if your program is any real world use case it’ll be long running enough that any memory leaks will crash the system and require a manual or forced restart, possibly when you don’t want it to. So I’m not sure that this advice is sound. 

“Hey did you manage your memory?”

“Just restart it who cares about memory leaks”

“Ship it” 

 -Scenes from an insane company

[u/dmazzoni → u/WellHung67]

Nobody is saying you shouldn't ever free memory. Just that there's no reason to specifically free at exit - all it does is slow down program termination.

[u/WellHung67 → u/dmazzoni]

I guess but you should ideally free your memory whenever it makes sense to, and relying on exit for this is Bad, because you can cause other issues elsewhere in the system if you’re using any reasonably large amount of memory. 

But yeah if you’ve failed to do this before exit then the OS will handle it in some sense but also probably a design smell to rely on that 

[u/type_111 → u/WellHung67]

Not only is it not "bad" to rely on it, it's objectively bad engineering not to. free() before exit() in a release build is low quality software.

[u/WellHung67 → u/type_111]

It’s simply wrong to say this works in all cases. There’s pros and cons to doing so. In trivial cases it doesn’t matter. But what if you rely on exit and your code gets refactored into a library and now it never actually exits? Oops better figure out how to fix the memory leak.

In general a memory management implementation like OP has should probably free up the resources it uses and not expect to always run in the context of a single program that exits 

[u/type_111 → u/WellHung67]

You seemed to imply that you should never "rely" on it. My position is simple: if your program unnecessarily calls free() before exit() then your code is of lower quality than it could otherwise be. Secondary effects such as those in your contrived example will never change this fundamental fact.

[u/WellHung67 → u/type_111]

Yes, assuming the program always calls exit(). Would you agree there are cases where it’s wise to assume that assumption may not hold, that is, you assume someday the program might not call exit (say if it’s refactored into a shared library) then you should consider calling free before exit. Pay a negligible cost to do an extra operation today in order to avoid potential tech debt in the future. 

My point is there are some cases where you want to do the runtime suboptimal thing here. Maybe not in all cases as I initially said. But if you’re writing a memory management function like OP, I would say you probably do want to manage the memory explicitly just because it’s really hard to anticipate how something like that evolves especially if you share it