6 ms·

For the third type of "leak" (GC frees memory from the program, but never returns it to the OS) the article says that this is often an issue for Python and Ruby

For the third type of "leak" (GC frees memory from the program, but never returns it to the OS) the article says that this is often an issue for Python and Ruby... Does this happen in other languages with a GC like Java or Go, or are Ruby and Python the only ones/especially bad?

merb 8y ago
the JVM _NEVER_ returns memory to the os. but that is not a problem since memory can always be reused on the jvm. I wouldn't consider the third category a memory leak.
- cryptonector 8y ago
  A cynic might say that it's not a problem because if you're running the JVM then that's probably all you're running...
  - gowld 8y ago
    JVM has -Xmx for choosing how much memory you want it to use.
- gowld 8y ago
  Your Java program can have category 3 leak "inside* the JVM.
- ShroudedNight 8y ago
  >the JVM _NEVER_ returns memory to the os 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.
ryandrake 8y ago
I encountered a similar issue as a learning Objective-C programmer, with autorelease pools on macOS (probably iOS too): If you're allocating and autoreleasing ObjC objects in a thread without an autorelease pool, or not draining the pool, those allocations will still be billed to your application and not available to the OS.
maxlybbert 8y ago
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).
- GauntletWizard 8y ago
  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 http://goog-perftools.sourceforge.net/doc/tcmalloc.html
gus_massa 8y ago
IIRC the golang GC has a similar behavior, because it is a non-moving GC, so it is very fast and C-friendly. 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.
xenadu02 8y ago
Without compaction this is often very difficult to do because you don't have large chunks of completely empty memory pages that are convenient to return to the OS; often you end up with a single object on an otherwise empty page, or a free block header on the otherwise empty page. If your malloc library coalesces free regions (or doesn't store its metadata in the heap at all) then this may be a bit easier. 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.
tigershark 8y ago
In C# it cannot happen. The garbage collector phase is compacting. In the past you could have had this problem in the large object heap (that stores objects larger than 85k) because the GC there is not compacting. From .Net 4.5 or something similar they added an option to trigger a compacting GC in the large object heap, so this problem is solved. The article is missing maybe the biggest leak in GC languages that is when resources are not properly closed. A classic example is not unsubscribing an event in .Net that may cause massive leaks if you have a main window that through its ViewModel will listen to events of any child viewmodel but it doesn’t unsubscribe the event when the child window is closed. As a result the more child window you open and close the more memory is leaking.
quietbritishjim 8y ago
I'm surprised the article didn't point out that this applies to C and C++, considering that these are usually thought of as being more efficient than higher-level languages. On Unix-like operating systems (and Windows too I believe), all of a process's data is in a single contiguous block. You can grow or shrink that block by calling the brk() [1] system call, but this allows you to return memory to the operating system only if it's at the end of that block – there's no mechanism to free pages in the middle. 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. [1] https://en.wikipedia.org/wiki/Sbrk https://en.wikipedia.org/wiki/Sbrk [2] https://en.wikipedia.org/wiki/Memory-mapped_file https://en.wikipedia.org/wiki/Memory-mapped_file
- gpderetta 8y ago
  Note that some allocators (including the standard glibc allocator) do use mmap internally for some allocation sizes. In this case the memory can be returned to the os when the whole block is freed. Some allocators even use mmap exclusively.
  - quietbritishjim 8y ago
    I didn't realise that. Thanks for the correction!

merb 8y ago

the JVM _NEVER_ returns memory to the os. but that is not a problem since memory can always be reused on the jvm. I wouldn't consider the third category a memory leak.

cryptonector 8y ago
A cynic might say that it's not a problem because if you're running the JVM then that's probably all you're running...
- gowld 8y ago
  JVM has -Xmx for choosing how much memory you want it to use.
gowld 8y ago
Your Java program can have category 3 leak "inside* the JVM.
ShroudedNight 8y ago
>the JVM _NEVER_ returns memory to the os 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.

ryandrake 8y ago

I encountered a similar issue as a learning Objective-C programmer, with autorelease pools on macOS (probably iOS too): If you're allocating and autoreleasing ObjC objects in a thread without an autorelease pool, or not draining the pool, those allocations will still be billed to your application and not available to the OS.

maxlybbert 8y ago

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

GauntletWizard 8y ago
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 http://goog-perftools.sourceforge.net/doc/tcmalloc.html

gus_massa 8y ago

IIRC the golang GC has a similar behavior, because it is a non-moving GC, so it is very fast and C-friendly. 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.

xenadu02 8y ago

Without compaction this is often very difficult to do because you don't have large chunks of completely empty memory pages that are convenient to return to the OS; often you end up with a single object on an otherwise empty page, or a free block header on the otherwise empty page. If your malloc library coalesces free regions (or doesn't store its metadata in the heap at all) then this may be a bit easier. 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.

tigershark 8y ago

In C# it cannot happen. The garbage collector phase is compacting. In the past you could have had this problem in the large object heap (that stores objects larger than 85k) because the GC there is not compacting. From .Net 4.5 or something similar they added an option to trigger a compacting GC in the large object heap, so this problem is solved. The article is missing maybe the biggest leak in GC languages that is when resources are not properly closed. A classic example is not unsubscribing an event in .Net that may cause massive leaks if you have a main window that through its ViewModel will listen to events of any child viewmodel but it doesn’t unsubscribe the event when the child window is closed. As a result the more child window you open and close the more memory is leaking.

quietbritishjim 8y ago

I'm surprised the article didn't point out that this applies to C and C++, considering that these are usually thought of as being more efficient than higher-level languages. On Unix-like operating systems (and Windows too I believe), all of a process's data is in a single contiguous block. You can grow or shrink that block by calling the brk() [1] system call, but this allows you to return memory to the operating system only if it's at the end of that block – there's no mechanism to free pages in the middle. 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. [1] https://en.wikipedia.org/wiki/Sbrk https://en.wikipedia.org/wiki/Sbrk [2] https://en.wikipedia.org/wiki/Memory-mapped_file https://en.wikipedia.org/wiki/Memory-mapped_file

gpderetta 8y ago
Note that some allocators (including the standard glibc allocator) do use mmap internally for some allocation sizes. In this case the memory can be returned to the os when the whole block is freed. Some allocators even use mmap exclusively.
- quietbritishjim 8y ago
  I didn't realise that. Thanks for the correction!