While comparing between linking loader and linkage editor I came across a point that in case of linking loader linking and relocation takes place for each execution of the program( and happens at time of loading) while in case of linkage editor, linking takes place only once and program can be loaded and used multiple times.Does this mean that a program is loaded into primary memory only when execution control is given to it(or OS has decided that it is the next program to be executed)?To be specific is loading of a program into primary memory a guarantee of immediate execution slot?

closed as unclear what you're asking by Celada, Anthon, Networker, jimmij, John WH Smith Feb 11 '15 at 15:54

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


A couple of things need to be clarified here:

  1. There is virtually no difference between a program being on the hard storage or in memory. If the kernel doesn't find the file already mapped into memory, mmap happens and from then on, the file is accessed through the memory pages, mapped into the virtual memory of a program. Note that this whole mechanism is transparent while many things happen in the background: a file may already be cached from previous use, actual memory may have been swapped out to disk if there's lack of space, and so on...
  2. Dynamically linked libraries are loaded once even if many executables are linked to them. Again, the pages get mapped into the virtual memory of the process that needs them.
  3. Having the contents of an executable loaded into memory has nothing to do with the code being run. Each time a new process is created (through fork), it gets its own virtual memory layout, and doesn't care where the pages are stored and who else is using them. When exec is called (execve usually), the binary (probably elf format) will get parsed, different contents mapped to different pages (program code, static data, stack gets allocated and so on), and the linker looks up the unresolved symbols in the code and maps them to the addresses in the dynamically linkable libraries, which also get mapped into the virtual address space at this stage. The execution is then passed to the entry point in the code in the exec'ed program.

Note that each execution of a particular program is its own new process, and doesn't really care where the code comes from. It's possible that the code has already been in RAM - or not, memory management is very dynamic. It may also be that the same physical memory page that contains the code, is mapped into several process' address space, and the dynamically linked libraries definitely use the same shared pages, but that's it.

It's possible to pre-load frequently used libraries at boot time, so the processes execute more quickly: but what this means is just that the linker already finds the pages loaded into RAM and doesn't need to read them from the hard drive. That's again a way of caching and is simply a side-effect of the fact that the kernel is shuffling the pages around in any way it wants, all you see is the virtual address space.

If you are referring to a situation when invocation of some command is reusing an existing process, that's something completely different. You may have some communication protocol that looks for an existing instance and tells it what to do. Or you may have a sleeping process that wakes up when there's more to do. But in these cases, you are not actually running a new process.

I'm not exactly sure what was your question, but I hope this answers it at least partially.

  • Orion, does this mean that relocation and linking takes place wrt virtual memory addresses assigned to a process/program and not wrt the physical memory pages occupied by it primary memory? – Kir Feb 11 '15 at 15:17
  • 1
    @Kir: Yes, virtual memory addresses are used. Programs (in user space) don't generally know or care what physical addresses these virtual addresses correspond to, or even whether or not the pages are present in RAM at all, and they don't know or care whether or not the memory is shared by another process. The kernel's virtual memory layer keeps these details hidden from programs. – Celada Feb 12 '15 at 1:09

Your question is quite difficult to understand and may contain some misconceptions.

Does this mean that a program is loaded into primary memory only when execution control is given to it(or OS has decided that it is the next program to be executed)

In UNIX, control is handed over to the next program through the execve() system call (and variants). This system call takes the filename of the program to execute as an argument. So it is like a request to load and execute the program. The program has not been loaded beforehand. So in that sense, the answer to your question is "yes".

We'll ignore the fact that the program's code may still reside cached in physical memory if it has been read or executed before. That's an optimization.

The first thing the kernel does is to load the file in question.

If it is a dynamically linked executable, then it also loads a dynamic linker, which is a helper program that will perform run-time linking on the program. This helper does its job, which usually involves loading other pieces of code (shared libraries).

Once dynamic linking is done (or if no dynamic linking is done because the program is not dynamically linked) then control is passed over to the program's code proper.

is loading of a program into primary memory a guarantee of immediate execution slot?

I don't understand "immediate execution slot".

There may be many different reasons to load a file (containing a program) into memory: to run it, to copy it, to edit it, etc...

  • Celada, thanks for the first part."immediate execution slot" in my question is related to linking and loading process.Can linking be done(static linking like that done by linkage editor where linked program along with all libraries used by it is converted into a single executable ) without bringing all components into memory?If linking process can only be done in memory it means that the program is already loaded into memory along with all libraries needed by it for linking process.After linking,as this program with all libraries is in memory won't the OS transfer execution control to it? – Kir Feb 11 '15 at 15:35
  • Re: "If linking process can only be done in memory it means that the program is already loaded into memory along with all libraries needed by it for linking process" Sure. The linker will load the files (or pieces of files) it needs into memory in order to work on them. This is just how computers work in general: there is no way to see, edit, transform, or create data directly on a storage device like a hard drive without loading the data into memory first. – Celada Feb 12 '15 at 1:12
  • Celada, does this mean that in a system supporting virtual memory, as every program is mapped to an unpredictable memory location by the OS there is no need for program relocation by loader?What is the duty of a loader in a virtual memory based system? – Kir Feb 12 '15 at 14:44
  • @Kir: that is a completely different question, but briefly: yes, indeed, virtual memory means that program relocation is not needed because every program can be pre-linked to run at the same predictable (virtual) address. However, shared libraries must either be compiled with position-independant code or suffer the overhead of runtime relocation because they are loaded at unpredictable addresses. – Celada Feb 13 '15 at 2:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.