Hacker News Reader

Comment by justinsaccount | Hacker News Reader

OS X does memory compression.

A few years ago I was trying to reproduce a memory issue in a C++ app by sending it a ton of the same thing over and over again.. on my OS X laptop I couldn't reproduce the problem at all, until I had it send random data.

If you open "Activity Monitor" and look at the memory tab, it will show you a value for "Compressed"

see https://appleinsider.com/articles/13/06/13/compressed-memory... or similar for more info.

View on HN

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]

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.

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.

Section 3 are library calls, section 2 has the actual syscalls.

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

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.

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.

Windows 10 also enables memory compression by default, on Linux it is optionally available (zram); Android phones typically make use of it.

On Linux there are also zswap with a compressed cache in front of the real swap. Depending on workload either zram or zswap may work better under the memory pressure.

Also, there is a matter of the compression algorithm selection. With modern kernel using anything but lz4 or zstd is rather suboptimal.

But then again I have Samsung 980 PRO SSD in my laptop and with it I just disabled memory compression and use the real swap. The read speed is like 2 times faster then lz4 decompression and while the write speed is like 3 times less than lz4, it does not tax CPU which is a big bonus when I compile a big C++ project that does occasionally triggers the need for SWAP even with 32 GB of RAM.

M1 pro/max has huge memory bandwidth (including L1, L2 and DDR: 102GB/s), I guess it helps compression faster than x86?

https://www.anandtech.com/show/17024/apple-m1-max-performanc...

memory compression allowed me to to allocate and store 20GB of genomics data in memory on my old 16GB MBP. ZRAM in Linux allowed me to do the same.

You used the ASCII encoding for it, I presume? That's trivial to compress to 2/8 = 25%, or 5GB in your case.

if it's one byte per 3-base codon, that's 6/8 compression 15GB/20GB

Reply on news.ycombinator.com