[1] The word footprint generally refers to the extent of physical dimensions that an object occupies, giving a sense of its size.
This includes all sorts of active memory regions like code segment containing (mostly) program instructions (and occasionally constants), data segment (both initialized and uninitialized),[1] heap memory, call stack, plus memory required to hold any additional data structures, such as symbol tables, debugging data structures, open files, shared libraries mapped to the current process, etc., that the program ever needs while executing and will be loaded at least once during the entire run.
An application's memory footprint is roughly proportionate to the number and sizes of shared libraries or classes it loads, whereas static libraries, executable programs and static data areas contribute to a fixed (constant) portion.
Traditionally, low-memory-footprint programs were of importance to running applications on embedded systems where memory would often be a constrained resource[1] – so much so that developers typically sacrificed efficiency (processing speeds) just to make program footprints small enough to fit into the available RAM.
For example, Sun Microsystems brought out a version of its Java Virtual Machine (JVM) for such constrained devices; it goes by the name of KVM.