• arc@lemm.ee
    link
    fedilink
    arrow-up
    25
    arrow-down
    3
    ·
    14 days ago

    The weird thing to me whenever anyone complains how much memory a browser takes up, is what do they think the free RAM is doing otherwise? It’s free so why can’t an application use it? And that’s what browsers do, taking the memory to use as a cache, and releasing it back to the system if available memory dips below some threshold.

    • Psythik@lemmy.world
      link
      fedilink
      arrow-up
      10
      arrow-down
      2
      ·
      14 days ago

      Also, modern OSes are designed to fill as much of your RAM as possible. Windows does it, Android does it; pretty sure Linux and MacOS does too. The number you’re looking at only shows the RAM usage by currently running processes. Unused RAM is wasted RAM, so your OS will fill as much of it as possible with prefetched data so that your machine will be more responsive when you actually need to use the data that was stored in advance for you.

      • IceFoxX@lemm.ee
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        14 days ago

        Um, isn’t only the addressable area reserved for the respective application? In other words, it doesn’t even mean that the application fully utilizes the memory, but that the memory is continuously available for the application.

        • Buddahriffic@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          13 days ago

          Each application has a full address space limited only by the number of address bits they use (which is way higher than the amount of physical RAM any machine uses, maybe even more than all RAM in existence for 64bit, since it can address space into the quintillions of bytes, or millions of terabytes).

          It’s only when they try to use a page of memory that the OS then reserves a physical page of memory that maps into your physical RAM. Allocating that space is a part of the page miss interrupt handler, which gets raised when a program in user space tries to access a memory address that isn’t stored in the CPU’s MMU.

          When it gets that interrupt, the OS will check its own memory allocation table for that address (which stored in RAM and is larger than the CPU’s hardware table) to see if it just needs to add the entry to the MMU, page it in from disk to a free page in RAM (possibly needing to page another page out to disk if there are no fee pages), or allocate a new entry to a free page (again maybe requiring a page out).

          I believe Windows task manager (or Linux top) displays the total number of allocated pages * page size for how much memory a program is using. There might be a seperate column for how many pages are in physical RAM vs the page file.

          Though there might be another path to get the OS to allocate pages before a page fault occurs, so it might not reflect the actual used memory. But allocating a new page on page miss isn’t very expensive when there’s free pages. Just a few table lookups and it goes back to the program. Paging out is more expensive, since each byte needs to be written to disk. Paging in is most expensive, since it usually involves a page out (because memory needs to fill up before a page out, so there’s a good chance one needs to be freed) and then every byte of the desired page needs to be read from disk.