I write mostly C++ or Rust programs. In these languages memory is freed as soon as it's no longer in use (thanks to destructors). So, usually this shouldn't be actively kept in mind. The only exception are cases like caches, but long-running programs should use caching carefully - limit cache size and free cache entries after some amount of time.

Programs, which allocate large amounts of memory without strict necessity to do so, are just a consequence of swap existence. "Thanks" to swap they weren't properly tested in low-memory conditions and thus no necessary optimization were done.

▲

Rohansi 4 days ago | parent | next [-]

You'll also need to consider that the allocator you're using may not immediately free memory to the system. That memory is free to be used by your application but considered as used memory mapped to your program.

Anyway, it's easy to discuss best practices but people actually following them is the actual issue. If you disable swap and the software you're running isn't optimized to minimize idle memory usage then your system will be forced to keep all of that data in RAM.

▲

man8alexd 4 days ago | parent [-]

You are both confusing swap and memory overcommit policy. You can disable swap by compiling the kernel with `CONFIG_SWAP=no`, but it won't change the memory overcommit policy, and programs would still be able to allocate more memory than available on the system. There is no problem in allocating the virtual memory - if it isn't used, it never gets mapped to the physical memory. The problem is when a program tries to use more memory than the system has, and you will get OOMs even with the swap disabled. You can disable memory overcommit, but this is only going to result in malloc() failing early while you still have tons of memory.

▲

Rohansi 3 days ago | parent [-]

Overcommit is different. We are referring to infrequently used memory - allocated, has been written to, but is not accessed often.

	▲	man8alexd 3 days ago \| parent [-]
		> Programs, which allocate large amounts of memory without strict necessity to do so, are just a consequence of swap existence. This. The ability to allocate large amounts of memory is due to memory overcommit, not the "swap existence". If you disable swap, you can still allocate memory with almost no restrictions. > This is all handled automatically when you have swap enabled And this. This statement doesn't make any sense. If you disable swap, kernel memory management doesn't change, you only lose the ability to reclaim anon pages.

▲

csmantle 4 days ago | parent | prev | next [-]

A side note, stack memories are usually not physically returned to the OS. When (de)allocating on stack, only the stack pointer is moved within the pages preallocated by the OS.

▲

jibal 4 days ago | parent | prev | next [-]

> Programs, which allocate large amounts of memory without strict necessity to do so, are just a consequence of swap existence. "Thanks" to swap they weren't properly tested in low-memory conditions and thus no necessary optimization were done.

Who told you this? It's not remotely true.

Here's an article about this subject that you might want to read:

https://chrisdown.name/2018/01/02/in-defence-of-swap.html

▲

rwmj 4 days ago | parent | prev [-]

> In these languages memory is freed as soon as it's no longer in use (thanks to destructors).

Unless you have an almost pathological attention to detail, that is not true at all. And even if you do precisely scope your destructors, the underlying allocator won't return the memory to the OS (what matters here) immediately.