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).
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...
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.
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.