perm filename SWAP.DOC[NEW,LSP] blob sn#548017 filedate 1980-11-26 generic text, type C, neo UTF8
C00001 00001
C00002 00002	∂25-Nov-80  2237	RPG  	Swapping 
C00005 ENDMK
∂25-Nov-80  2237	RPG  	Swapping 
To:   BIS, RPG    
The problems of swapping are:
	1. Deciding on the size of the swapping area.
	2. Deciding what goes in there to avoid thrashing
	   or swapping things you always use.
	3. There has to be a surrounding environment to
	   call the individual routines. If you say (baz 7),
	   and baz is in the swapping area, then the BAZ subr
	   pointer has to point the a header routine to do the right
	   thing. Example:

The Swapping area has a dispatch table at the head. Suppose the
routines are f1, f2, f3.

swap start address:
f1 --→ code1
f2 --→ code2
f3 --→ code3

code1 ←
 (cond ((swapped-in 'f1))
       (t (swap-in 'f2 (get-swap-specs))))
 (jrst f1)

Then the subr pointers are:

f1 swap start
f2 swap start + 1
f3 swap start + 2

	4. Maybe one should use least recently used?
	5. How many routines should be resident?
	6. Returns are hard! Suppose that you have:

(defun f1 (x)
  ...  (computation (f2 ...)) ...)

and to get f2 you swap out f1! You have to be able to know you're in
F1 and to not swap it out, so you need several routines per swapping

	7. Are these decisions automatic?

	8. Calling out of a function in a swap area that might
	   cause that guy to be swapped out means that the
	   return route has to be smart too. So every function
	   call out of one that could do this means a call like:

	      (outcall 'function arg1 arg2 ...)

	   which might need to be coded for the right number of args
	   or else be a lexpr.
	9. Each function swapped into the same area needs to
	   to be in a file with a call to some routine between
	   each. Like: