Three kinds of memory leaks
blog.nelhage.com
blog.nelhage.com
I eventually decided to just fork() the ruby process, do the processing, compute the JSON results (which were comparatively small) and hand the results back as a string over a socket to the parent process, which would cache them and respond. It pretty much solved the memory issue, since the forked process would just exit() gave all the memory back.
In fact, I think I ended up doing a GC.disable() inside the forked process (because I was going to exit anyway) and it sped the process up from taking >2 minutes to just a few seconds. Ruby's GC was utterly terrible back then.
It was an internal tool that never was touched by the general internet, which is why we could "afford" to have it do such intensive work behind a single request, but I always wonder if there was a better approach that wasn't so awful.
Instagram found deactivating parts of Python's memory management actually helped with efficiency in such a scenario: https://instagram-engineering.com/dismissing-python-garbage-...
One of the main ways to tune Erlang systems for speed is to figure out the amount of memory each type of actor will need, and pass an option to spawn the actor with an arena pre-allocated to that size, so that it can just quietly do its job and quit, never having asked to allocate or deallocate at all.
I wouldn't consider the third category a memory leak.
That may (or may not) be true of the GC heap, but the GC heap is only one consumer of JVM memory allocations. I don't know enough to confirm one way or another.
Speaking from experience, OpenJ9's JIT compiler aggressively returns transient compilation memory back to the operating system.
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).
IIRC Java and C# have a moving GC, so the GC may decide to move the object and will update all the references to make the change automatic. This is slower and you can't pass the pointers to an external function that is not aware of the GC. But the memory is compacted and it avoids the #3 type of leaks, and also allocating new memory is faster because the allocator has a big block of free memory instead of having to lookup a good place in the fragmented free memory.
In any case, the GC or malloc lib can use madvise() or posix_madvise() with MADV_DONTNEED. This tells the OS that one or more pages are now junk and can be forgotten, but it leaves the pages mapped. If the process touches them again the kernel will page fault and re-allocate a new page of physical memory but otherwise the physical memory is available for the OS to re-use without swapping to storage.
Modern well-designed VMs will defer acting on this advice unless it actually needs the memory. If the process touches the pages before they are reclaimed very little actual work is performed.
Compacting GCs are another story; they can always wait some time period after a new highwater mark is reached then madvise() on the empty heap areas with little penalty.
I'll also caution people to remember that free memory is wasted memory. If a program isn't using it then the file cache should be.
The big problem for these languages is that you can't move objects around in memory because other objects may have pointers to them, and there's not enough metadata at runtime to figure out where those pointers are and fix them up to a new location. This means that if you have an large amount of free memory and have just one little object allocated after it then there's no way, even in principle, to return that free memory to the operating system. In practice I don't think any C allocators even try to return memory to the OS.
There are a couple of mitigating factors to this though:
* If you allocate a huge amount of memory and then free it and don't use much afterwards, eventually the OS will move those unused virtual memory pages to disc in the page file. Your process will still appear to be using a lot of memory, but in practical terms the system will behave as if you had freed it.
* You can allocate memory allocated using memory-mapped files [2], a term which is distorted to include memory allocated by this mechanism but not necessarily backed by an actual file. These are not in the contiguous block of process data and their memory pages really are returned to the OS when the file is unmapped. This requires quite a lot of manual effort on the part of the developer, but for some applications it's worth it.
Some allocators even use mmap exclusively.
On at least modern GNU/Linux, malloc can and does still use brk/sbrk, but will also use mmap for particularly large allocations, as can (on my system) be shown by stracing this C program:
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
printf("%p %p\n", malloc((size_t)1 << 14),
malloc((size_t)1 << 20));
return 0;
}
Regarding the other two factors you mention: firstly, if you make a large number of allocations on a brk-based heap and then free most of them, a page from that heap can still only be paged out if none of the live allocations intersects it. (If you make a single large allocation, see above re automatic use of mmap.) If the heap is highly fragmented, you may not be able to page out many pages. If the heap is a brk-based heap and is not highly fragmented after the free phase, it's more likely there would be a bunch of space near the top, and then malloc could shrink the heap at the OS level too. One allocation pattern I can imagine where what you say would have a higher chance of happening, though, is “allocate many times for intermediary data during an operation, then allocate for the result, then free all the intermediary data”, in which case the result might well be stuck at the top of the heap with a bunch of dead pages underneath. But you still take lazy disk I/O doing the paging, and you still take a reservation across system virtual memory as a whole. On the whole I'm not all that convinced that this is a “mitigation” that's worth paying attention to from a developer perspective; it might be more useful from a sysadmin perspective.
For the second, terminology-wise, I've never heard “memory-mapped file” used to refer to anonymous mmap; I think I've only ever heard it called mmap in a Unixy context. On Windows, VirtualAlloc and MapViewOfFile are separate API functions, and VirtualAlloc is the equivalent of anonymous mmap.
Windows allows the creation of additional heaps for HeapAlloc such that a heap can be destroyed all at once, and I presume these use their own VirtualAlloc regions underneath. There are various C libraries that allow arena-based allocation on Unixy systems as well. These can even both reduce manual effort and increase performance if your memory usage patterns involve a large number of allocations for some operation followed by freeing everything, because then you don't have to free every block individually; you just throw away the entire arena, like an in-process equivalent of what exit() does to whole-process memory resources. Your main option in C if malloc is causing fragmentation/performance problems for you isn't usually to jump to raw mmap unless you're writing your own allocator on top of that; it's to jump to picking a more advanced malloc and maybe giving it some extra context about what you're doing with the memory.
I think you're right that I accidentally made up usage of "memory-mapped file" for mapped memory that doesn't correspond to any file. But it is possible to create them on Windows with MapViewOfFile; this function takes a handle returned from CreateFileMapping, which can accept a file handle of INVALID_HANDLE_VALUE [1]
[1] https://msdn.microsoft.com/en-gb/library/windows/desktop/aa3...
One example: on pages that self-refreshed at regular intervals, the same page URL was added to the history list each time. That ended up leaking a ton of memory if you left the page open over several days.
> If you’re writing in C or C++, especially C++ without ubiquitous use of smart pointers to manage memory lifetimes, this is your first guess.
What absolute rubbish. Ever heard of a constructor/destructor (aka RAII)? You can go really far without the usage of any new/delete or a smart pointer, and this probably should be the case all the way up till the OS boundary.
https://www.google.ru/url?sa=t&source=web&rct=j&url=%23&ved=...
(Sorry for weird url, YouTube seems to be currently blocked here and I'm too lazy to wait for a VPN connection).
This is a good idea where it can be done, and it's worth noting that move semantics replace some uses where a unique pointer would've have been necessary pre-C++11. But there are plenty of applications where it's really not possible. A big one is that if you're using inherence and virtual methods (out of fashion though they are) then you'll almost certainly need a pointer. Plenty of large complex applications cannot avoid object lifetimes with complex rules, which shared pointers track nicely, usually because objects are shared between threads or network requests. For example, if you're using ASIO (which is the basis of standard library networking in C++20) it's hard to imagine how you'd avoid using shared pointers.