 |
 |
 |
 |
 |
|
|
|
|
|
|
|
The comment at the beginning of this procedure (2251) says most of what needs to be said about the procedure, except for the question of “swapping out” when not enough core is available.
Note that “expand” takes no particular notice of the contents of the user data area or stack area.
If the expansion is actually a contraction, then trim off the excess from the high address end;
“savu” stores the values of r5 and r6 in “u.u_rsav”;
If sufficient main memory is not available ...
The environment pointer and stack pointer are recorded again in “u.u_ssav”. But note that since no new procedures have been entered, and since there has been no cumulative stack growth, the values recorded are the same as at line 2281;
“xswap” (4368) copies the core image for the process designated by its first parameter to disk.
Since the second parameter is non-zero the main memory area occupied by the data segment is returned to the list of available space.
However the computation continues using the same area in main memory until the next call on “retu” (2193) in “swtch”.
Note also that the call on “savu” at line 2189 in “swtch” stores new values in “u.u_rsav” after the disk image has been made (and therefore serves no useful purpose since the core image has already been officially “abandoned”);
The “SSWAP” flag is set in the process’s proc array element. (This is not swapped out, so the effect is not lost);
“swtch” is called, and the process, still running in its old area suspends itself. Since the call on “xswap” will have resulted in the “SLOAD” flag being switched off, there is no way that “swtch” will choose the process for immediate reactivation.
Only after the disk image has been copied back into core again can the process be activated again. The “return” executed by “swtch” is a return to the procedure which called “expand”.
|
|
|
|
|
|