4 ms·

Which is why, as an iOS developer, you should never respond to memory pressure notifications by actively freeing memory! You'll inevitably end up touching comp

Which is why, as an iOS developer, you should never respond to memory pressure notifications by actively freeing memory! You'll inevitably end up touching compressed memory pages in the process, increasing your app's memory use as pages get decompressed so you can free the allocations. [this is technically true on the Mac, but your Mac app isn't going to get jetsam'd like your iOS app will]

slimsag 5y ago
Would this be the case if you just used the `free(3)` syscall, and didn't otherwise touch the memory? I can imagine destructors in most languages involving touching the memory, just curious if a free syscall alone does it or not.
- astrange 5y ago
  Above 16KB (one page) it's safer. Depends how much work you need to do to figure out what can be freed. It's better to free things as you go rather than wait for warnings.
- namibj 5y ago
  Section 3 are library calls, section 2 has the actual syscalls.
  - matvore 5y ago
    Some related trivia. The `errno` command, for looking up syscall error codes, is not installed in `/usr/bin` in macOS like on typical Linux distros. But the same information is available in `intro(2)`, e.g. $ man 2 intro | grep -w 17 17 EEXIST File exists. An existing file was mentioned in an inappropriate
xenadu02 5y ago
This is not usually true. Memory compression prioritizes speed not compression ratio so even something like a bitmap from a JPEG source is not likely to be very compressed. Freeing the buffer is still a net win. Further the pages themselves (for a large allocation) don't all get touched when freed so the kernel can skip decompressing them. Measure the behavior of your application. Most of the time freeing cached values is the correct response to memory pressure, or use things like NSCache that handle it for you.
- astrange 5y ago
  It is true except for freeing large allocations; that's the only safe thing. Calculating what you have to free can also be problematic, or running a GC which has to decompress pages to scan pointers etc. This will come up if you see your app getting background killed. If nothing bad happens then nothing bad happens, of course. You honestly shouldn't use NSCache as nobody understands what it does, or tests its eviction behavior, and what it actually does - evict everything under memory pressure - is probably the time you want your cache to work.

slimsag 5y ago

Would this be the case if you just used the `free(3)` syscall, and didn't otherwise touch the memory? I can imagine destructors in most languages involving touching the memory, just curious if a free syscall alone does it or not.

astrange 5y ago
Above 16KB (one page) it's safer. Depends how much work you need to do to figure out what can be freed. It's better to free things as you go rather than wait for warnings.
namibj 5y ago
Section 3 are library calls, section 2 has the actual syscalls.
- matvore 5y ago
  Some related trivia. The `errno` command, for looking up syscall error codes, is not installed in `/usr/bin` in macOS like on typical Linux distros. But the same information is available in `intro(2)`, e.g. $ man 2 intro | grep -w 17 17 EEXIST File exists. An existing file was mentioned in an inappropriate

xenadu02 5y ago

This is not usually true. Memory compression prioritizes speed not compression ratio so even something like a bitmap from a JPEG source is not likely to be very compressed. Freeing the buffer is still a net win. Further the pages themselves (for a large allocation) don't all get touched when freed so the kernel can skip decompressing them. Measure the behavior of your application. Most of the time freeing cached values is the correct response to memory pressure, or use things like NSCache that handle it for you.

astrange 5y ago
It is true except for freeing large allocations; that's the only safe thing. Calculating what you have to free can also be problematic, or running a GC which has to decompress pages to scan pointers etc. This will come up if you see your app getting background killed. If nothing bad happens then nothing bad happens, of course. You honestly shouldn't use NSCache as nobody understands what it does, or tests its eviction behavior, and what it actually does - evict everything under memory pressure - is probably the time you want your cache to work.