News for hackers. Stuff that matters.
Re:Three kinds of memory leaks by maxlybbert on Monday April 30, 2018 @09:21PM (#16963958)
It happens in other VMs. It can happen without a VM if whoever wrote your platform’s memory allocation system hasn’t read anything from the last thirty years (“first fit” versus “best fit”).

I remember hearing about a server program that worked around this problem by creating two memory arenas. All allocations came from, say, arena A until it was full, then they came from arena B. That’s the whole strategy. Things were still deallocated normally. The basic idea was that by the time arena B was full, everything in arena A would have been cleaned up normally and the memory allocator would have coalesced adjacent free memory; in other words, the strategy was to guarantee the allocator had a chance to clean up fragmentation (usually the allocator doesn’t need the help, but this approach guaranteed correct behavior as long as everything was eventually cleaned up; i.e., there were no classic leaks).

Re:Three kinds of memory leaks by GauntletWizard on Monday April 30, 2018 @10:10PM (#16964125)
Some systems forego memory freeing for performance gains, especially in environments with fixed allocations per process, e.g. Kubernetes. TCMalloc [1] intentionally doesn't release memory to the OS, keeping your max memory size forever.

[1] http://goog-perftools.sourceforge.net/doc/tcmalloc.html