5 ms·

Kudos to the devs who fixed it. In my c++ project I was trying for weeks to figure out how to release back to the OS the memory that my std::vector was occupyin

Kudos to the devs who fixed it. In my c++ project I was trying for weeks to figure out how to release back to the OS the memory that my std::vector was occupying, only to find out that there is no straight forward way of achieving so.

gsvelto 5y ago
Detecting low memory scenarios is surprisingly hard on desktop operating systems, but trivially simple on Android/iOS. Firefox for Android already made extensive use of this feature while desktop Firefox' available memory watcher underwent a lot of changes over the years before becoming fairly reliable.
- iggldiggl 5y ago
  Though unfortunately especially on Android some vendors are overly aggressive in signalling memory pressure, so while the API might be easier to use, the practical result still isn't really good, either, because now instead tabs get unloaded too often. (And the move to multi-process on Android has the unfortunate side-effect that a too-aggressive system OOM killer can now pick out individual content processes and randomly kill tabs without regards to any priority as to which tabs should be unloaded first.)
keithalewis 5y ago
Right curly brace '}'
- whatever1 5y ago
  I wish it was that easy. Destructing of your vectors does not guarantee that the memory will be released back to the OS, and it is not, if your OS is desktop Linux. See an example here: https://stackoverflow.com/questions/26020580/huge-stdvectorstdvector-does-not-release-all-memory-on-destruction https://stackoverflow.com/questions/26020580/huge-stdvectors...
  - keithalewis 5y ago
    This is not a problem a C++ compiler vendor can solve.
shultays 5y ago
Small allocations are allocated using sbrk and never truly freed. Larger ones use mmap which gets freed. Guess the solution would be either preallocating/reserving everything, or maybe using custom allocators that works with bigger chunks

gsvelto 5y ago

Detecting low memory scenarios is surprisingly hard on desktop operating systems, but trivially simple on Android/iOS. Firefox for Android already made extensive use of this feature while desktop Firefox' available memory watcher underwent a lot of changes over the years before becoming fairly reliable.

iggldiggl 5y ago
Though unfortunately especially on Android some vendors are overly aggressive in signalling memory pressure, so while the API might be easier to use, the practical result still isn't really good, either, because now instead tabs get unloaded too often. (And the move to multi-process on Android has the unfortunate side-effect that a too-aggressive system OOM killer can now pick out individual content processes and randomly kill tabs without regards to any priority as to which tabs should be unloaded first.)

keithalewis 5y ago

Right curly brace '}'

whatever1 5y ago
I wish it was that easy. Destructing of your vectors does not guarantee that the memory will be released back to the OS, and it is not, if your OS is desktop Linux. See an example here: https://stackoverflow.com/questions/26020580/huge-stdvectorstdvector-does-not-release-all-memory-on-destruction https://stackoverflow.com/questions/26020580/huge-stdvectors...
- keithalewis 5y ago
  This is not a problem a C++ compiler vendor can solve.

shultays 5y ago

Small allocations are allocated using sbrk and never truly freed. Larger ones use mmap which gets freed. Guess the solution would be either preallocating/reserving everything, or maybe using custom allocators that works with bigger chunks