REAL MEMORY MANAGEMENT
REAL MEMORY MANAGEMENT
SEGMENT
ALLOCATED MEMORY
Figure 3-5. Hiding Boundary Tags
There are two ways to reserve slots in a descriptor table:
BOUNDARY TAG
SEGMENT
1
BOUNDARY TAG121960·300
I. Code absolute selector values in the program and use the Builder's RESERVE statement to prevent the Builder from allocating other descriptors to those slots. This is the method used in this example.
2. Use EXTERNALs to dummy segments coded in an ASM286 module, and allow the Builder to assign slots for the descriptors of the dummy segments. The Builder resolves the EXTERNALs.
PL/M-286 Code
This example separates management functions from descriptor-management functions. The space-management procedures are DELINK, FIND_FIRST_FIT, and RETURN_SPACE. The public procedures ALLOCATE and FREE_SEG call on POINT~T and NULLIFY to manipulate descrip-tors for allocated segments. (Refer to Chapter 2 for definitions of POINT~Tand NULLIFY.) The PL/M-286 built-ins used to manipulate system structures in this example include
5 E LEe TOR S 0 F (pointer)
GET $ 5 E G M E Ii T $ LIM I T ( selector)
The external procedure GET$SEGMENT$BASE extracts the segment base address from the speci-fied descriptor.
When the procedure FIND_FIRST_FIT finds an available space that is much larger than requested, it allocates the higher-addressed portion of the space and leaves the lower-addrcssed portion in the free-space list. Figure 3-7 illustrates the process of splitting an available free-space.
3-6 121960·001
REAL MEMORY MANAGEMENT
I
n+3CURRENT n+2 TASK DESCRIPTORS n: 1
1 WORK DESCRIPTORS FOR MEMORY
I
m'l1+ .L 2MANAGER m
o
GLOBAL DESCRIPTOR TABLE
,
,
I I I I I I
,
LOT ALIAS LOT TSS ALIAS
TSS I I
SLOT C SLOT B SLOT A
, ,
I I ,
GOT ALIAS NULL
RESERVED FOR OPERATING SYSTEM
Figure 3-6. Example GDT Layout
121960-19
When returning an unneeded segment to the available list, the procedure RETURN_SPACE checks the boundary tags of both the lower and higher adjacent segments to see whether there is another free segment with which to combine. Four cases are possible, as illustrated in figure 3-8 at the end of this chapter. Table 3-1 summarizes the actions taken in each of the four cases.
See figure 3-9 at the end of this chapter for the PL/M-286 code that implements this example of a memory manager.
Protection Structure
Where in the two-dimensional grid of protection offered by the iAPX 286 should the memory-management module lie? There are two approaches that offer different advantages:
1. The module can be structured as privileged procedures that execute as part of every task that calls them.
2. The module can execute as a separate task.
inler
REAL MEMORY MANAGEMENTBEFORE AFTER
I "USED" I
SIZE"" 16 BYTES
I "USED" I I "FREE" I
(
.. NEWSTART\
I NEW SIZE "FREE" NEXT PRIOR I121960-20
Figure 3-7. Splitting an Available Block of Memory
GLOBAL PROCEDURES
Placing the module's segment descriptors in the GDT allows all tasks in the system to share the module yet requires only one copy of the module's segments to be present in memory. This approach allows for fastest communication between the application and the memory manager.
The procedures of the memory manager synchronize with the calling procedure (that is to say, the calling procedure waits until the memory-management procedure returns). However, more than one task can be executing the memory-management procedures at one time. This can be an advantage (as when there are mUltiple CPUs and the requests are for different regions of the memory space), but it requires synchronization of changes to space-management data structures (not shown in this example).
Segments containing procedures and data structures internal to this most critical operating-system module should have the greatest protection possible. Because none of these procedures and data struc-tures are PUBLIC, no other modules can gain knowledge of the locations of data and procedures. This by itself, however, does not constitute positive protection from accidental or intentional snooping or destruction. The segments containing these procedures and data should have privilege level 0 (PL 0) so that the processor can prevent any access from less trusted procedures.
3-8 121960-001
REAL MEMORY MANAGEMENT
Table 3-1. Actions for Combining Segments
Case 0 Case 1 Case 2 Case 3
Action
Lo Hi Lo Hi Lo HI Lo HI
Free Free Free Used Used Free Used Used
CURR~VLBL= Lo Lo This This
START START Base Base
CURR_LlNK.PRIOR = Hi
Null
- -
LlNK.PRIORCURR_LlNK.NEXT= Hi
FIRST~VLBL
- -
LlNK.NEXTDELINK HI Yes No No No
FIRST~VLBL=
No No No Yes
CUR~VLBL?
PRIOR FREE
LlNK.NEXT= No No Yes No
CURR~VLBL?
NEXT FREE
LlNK.NEXT= No No Yes Yes
CURR~VLBL?
The PUBLIC interface procedures ALLOCATE and FREE_SEG should execute at PL 0 to access the internal data structures and procedures, which are also at PL
o.
ALLOCATE and FREE_SEG should have gates at PL 3, however, so that even least trusted application procedures can get the space they need for such purposes as dynamic data structures.SEPARATE TASK
Another possible structure, not exemplified here, is to treat the memory-management module as a separate task. The iAPX 286 features for isolation of tasks provide the needed protection for the criti-cal memory-management structures and procedures. Within the memory-management task, privilege levels can be used to isolate the various internal procedures and data structures from one another. The memory-manager task can use a message passing mechanism such as that shown in Chapter 5 to receive requests and to pass segments to the requesting task.
With the memory-manager executing as a separate task, serialization of requests for space is automatic, thereby eliminating the need for synchronization when modifying space-management structures. The separate-task approach is also advantageous when there is a need to have the requesting task wait until sufficient memory becomes available to fullfil a request. While one task is waiting, the memory manager can continue to service requests from other tasks.
REAL MEMORY MANAGEMENT