Difference between virtual memory and job pool

Question

Both virtual memory and job pools store the processes temporarily on disk and bring them to memory at some later stage, so what is the actual difference in between them?

What I guess is that when a process is just created, it first goes to the job pool and then it is sent to the ready queue. Virtual memory is only used when available memory becomes smaller than the required memory for any process (please correct me if I am wrong).

If this is the case then doesn't it decrease performance? What is the need to store processes in job pool first? Why don't we send processes directly to memory?

Also somewhere it was written as “job contains the list of all the jobs in the system and jobs in the memory are a subset of the jobs in the job pool”. So what is meant by “all jobs in the system” here? Does it mean “all NEW jobs”?

Answer 1

All the jobs that enter the system are kept in the job pool. This pool consists of all processes residing on mass storage awaiting allocated of main memory. (Source)

When a job has to get executed, it needs to be residing in the main memory. But, due to the limitation of size of main memory, only the parts of job which are currently being executed are transferred onto main memory, and the rest reside in virtual memory.

So, in short, jobs which are created are sent to the job pool and are waiting to get their required resources and to get executed.

Why don't we send processes directly to memory?

Not always, is the main memory free. So, the job scheduler comes into the picture.

Because it is the job of the job scheduler to pick jobs from the job pool. Because, by default the job scheduler must be using some heuristic to schedule jobs i.e. according to priority or FIFO etc. You cannot break the custom and force it directly to the main memory, as that is the job of the job scheduler. This process, might have a bit of performance overhead, I understand, but things are pretty organised this way (the OS is so designed), and ensures no process starves.

All the jobs in the system mean the jobs in the hard disk and the jobs in the main memory combined. So, jobs in the memory are a subset of the total jobs in the 'system'.

Answer 2

The concept of “job pool” refers to a batch processing system, where jobs are queued to be executed when resources are available. The job pool contains both jobs that are currently executing and jobs that have been scheduled but are not yet being executed. Ancient computers (and some mainframes that are still in operation) worked this way. When a job is executing, it is fully present in memory.

Modern systems don't work that way. Computers that are big enough to run multiple tasks — even many embedded systems — have a memory management unit which translates virtual memory addresses to physical addresses, and the operating system uses that to move each page between memory and disk (this is called swapping or paging). This is an evolution from earlier multiprocessing systems: at first (before the MMU era) processes were swapped as a whole, but nowadays, if there isn't enough memory to fit all currently running processes, the operating system can swap out the parts of processes that aren't currently being used.

Systems designed for large non-interactive computations generally use job management even today. Swapping takes time; if the active processes require more memory than is available to run comfortably, this causes thrashing. To avoid this, job schedulers do use job pools, and arrange to start jobs, and possibly pause them, based on available resources. The system works on top of an operating system based on virtual memory, so once a job is paused it will naturally be swapped out as its pages in RAM are replaced by pages of active jobs.

(Note that job-based management is only marginally relevant to today's computing environment. I wouldn't set much store by a textbook that focuses on that in the 21st century. Virtual memory, on the other hand, is relevant to all but low-end embedded systems.)