3 ms·
> Virtually all "memory leaks" are freed eventually, usually when a program closes. I think that's literally the definition -- it can only be freed upon progra
by setr 5y ago
> Virtually all "memory leaks" are freed eventually, usually when a program closes.
I think that's literally the definition -- it can only be freed upon program death. More specifically, there's no way I could choose to free it, because all aliases have been lost (but that memory is still allocated).
If I create a bunch of intermediate objects unnecessarily while I'm doing some computation, I'm not leaking memory -- I'm just being inefficient. Unnecessary generation of thunks definitely falls in the same place; it's only a leak once I've lost track of it.
Otherwise you're just using memory leak to mean "My objects live longer than I thought", which is an issue probably affecting more than 99% of existing programs.
- rovolo 5y agoYou can also define a memory leak as retaining memory outside of the scope its needed. The program lifespan is one of those scopes, but there are also smaller scopes you can leak memory to. An example is the per-request scope on a server. > Otherwise you're just using memory leak to mean "My objects live longer than I thought", which is an issue probably affecting more than 99% of existing programs. Yes, it's a class of errors. Big programs always have errors, so it's not necessarily helpful to say "this program has a null-pointer error" or "this program has a memory leak". The scope of the problem depends on the impact caused by the error. For example, a memory leak during a computation could still bring down your program. Imagine a file uploader which does an md5 computation of a file before uploading the file. If the uploader pulls the entire file into memory for checksumming when it didn't intend to, a large file could cause an OOM error and crash your program. That is a memory leak even though it is scoped to the md5 operation and not the program lifetime.