Finally I have a valid reason to learn about memory management. It was also hella weird when encountering it.

  • entwine@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    2 days ago

    This non-sarcastically. The operating system is better at cleaning up memory than you, and it’s completely pointless to free all your allocations if you’re about to exit the program. For certain workloads, it can lead to cleaner, less buggy code to not free anything.

    It’s important to know the difference between a “memory leak” and unfreed memory. A leak refers to memory that cannot be freed because you lost track of the address to it. Leaks are only really a problem if the amount of leaked memory is unbounded or huge. Every scenario is different.

    Of course, that’s not an excuse to be sloppy with memory management. You should only ever fail to free memory intentionally.

    • henfredemars@infosec.pub
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      2 days ago

      Absolutely. I once wrote a server for a factory machine that spawned child processes to work each job item. Intentionally we did not free any memory in the child process because it serves only one request and then exits anyway. It’s much more efficient to have the OS just clean up everything and provides strong guarantees that nothing can be left behind accidentally for a system where up time was money. Any code to manage memory was pointless line noise and extra developer effort.

      In fact I think in the linker we specifically replaced free with a function that does nothing.