How does cached memory work for executables?

Question

I always understood cached memory in Linux (as in free -m) as pages of memory that can be reused if they are needed again, or quickly freed if more memory is needed by new applications (I found this article to be helpful a few years ago).

It seems that both executables (e.g., a program like thunderbird) and data (e.g., the content of a log file) can be cached. In fact, I don't think there is a distinction between text and executable files on *nix.

I can see how it could work for data that does not change much (e.g., a text file), but how does it work for programs that are dynamic by nature? Surely, the cached memory cannot restore objects that were dynamically allocated? Is it only the bytecode (or instructions in the case of scripts) that is cached then?

EDIT 1

By cached memory, I mean the memory under the column "cached" when I run "free":

$ free -m
             total       used       free     shared    buffers     cached
Mem:          7985       6650       1334          0        150       3201
-/+ buffers/cache:       3298       4686
Swap:        13178          2      13176

EDIT 2

Thanks to ls-lrt who gave me the hint I was missing. As this response on SE clearly mentions (should have searched there first), "The cached memory is the disk cache used by the VFS". This means that for executables, only the instructions (bytecode, script lines, etc.) are represented under this column and it has nothing to do with things that are dynamically allocated. I was under the impression that entire pages of memory (including dynamically created objects) were "cached".

EDIT 3

Nice examples about using the disk cache.

Answer 1

The cache shown in free is file system cache. At the file system level, everything is just octets of data. Whether application or file data, no difference at that level. While it is possible to reload an executable that has been swapped out from file cache (executables are not written to the swap file, they are simply kicked out of memory), this would be rare because the file cache is usually sacrificed first.

Now, be clear on the distinction between file cache as shown by free and any other kind of memory that may be involved by a running program. For it is not clear what you mean by "the cached memory cannot restore objects that were dynamically allocated." Any memory in use by the application is not involved with the file cache. No memory allocations of any kind by an application are cached by the file cache. The file cache is only an intermediary between the disk and the OS.

To answer dour question: "Is it only the bytecode (or instructions in the case of scripts) that is cached then?"

The file cache only caches the octets on disk. It does not care what memory is used by the application.

Answer 2

There is basically no difference in the way the Linux kernel treats various types of data in memory: the part of the kernel doing caring about this is called the "virtual memory subsystem", and it only cares whether a certain portion of memory is in use by a program or not.

The Linux kernel partitions the available RAM into little chunks called "pages". Then classifies pages into "in use" (for instance: pages containing code or data for a program that is currently running), and "unused" pages. For the "in use" pages, it does not matter whether they contain executable code, text data, Java bytecode or whatever -- the only thing that matters is that they are "in use": they need to be in RAM because that data is constantly being accessed.

Since RAM is the fastest storage device available, it is a waste to let "unused" pages be inactive, so the kernel "recycles" unused pages to cache data that has been fetched from the disk and could be needed again shortly. The kernel has some algorithms to make this prediction; I/O system performance depends to a large extent on how good this algorithms can foretell the actual workload of your computer.

In addition, to speed up I/O operations, part of the RAM will be used to buffer data that is being written to the disk: you might have noticed that, when you copy a large file to a slow disk (e.g., an USB stick), the cp command finishes before the data is fully written to the device: this happens precisely because the kernel is holding some data in "free" memory to speed up the (slow) write operation; data will be written back to disk some seconds later, when the cp program has possibly already finished. As soon as data is written to disk, these pages will be again considered free (and re-used for caching data, or moved to the "in use" pool if the need arises).

As you point out, the "cached" pages can be (relatively) quickly reclaimed by the kernel, in case there is a need to allocate more pages for "in use" data, since the "cache" pages are just holding data that is available from disk (the cached data will be fetched from disk again when it is asked for).

Further reading:

• Virtual Memory Basics
• Paging and Swapping