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:
- 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,
mmaphappens 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...
- 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.
- 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
execis called (
execveusually), the binary (probably
elfformat) 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.
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...