Smartphone Operating System (779883), страница 34
Текст из файла (страница 34)
Note thatDLLs may not necessarily need to be loaded. This might be the caseif they are already in memory or they are contained on external flashstorage (in which case, they can be executed in place). If they are ininternal memory, they may be executed in-place.156MEMORY MANAGEMENT• Offloading of memory management to hardware : if there is an available MMU, it is used to its fullest extent. In fact, the more functionalitythat can be put into an MMU, the better the system performance.Even with the execution in-place rule, small platforms still need memory that is reserved for operation. This memory is shared with permanentstorage and is typically managed in one of two ways.
First, a very simpleapproach is taken by some operating systems and memory is not pagedat all. In these types of systems, context switching means allocating operating space – heap space, for instance – and sharing this operating spacebetween all processes. This method uses little or no protection betweenprocess memory areas and trusts processes to function well together.Palm OS takes this simple approach to memory management.The second method takes a more disciplined approach.
In this method,memory is sectioned into pages and these pages are allocated to operatingneeds. Pages are kept in a ‘free list’ managed by the operating systemand are allocated as needed to both the operating system and userprocesses. In this approach, because there is no virtual memory, whenthe free list of pages is exhausted, the system is out of memory andno more allocation can take place. Symbian OS is an example of thissecond method and Section 7.5 gives a more detailed examination of itsmemory-management policies.7.4 SegmentationWe have discussed two views of memory: a logical view and a physicalview. The logical view can be described as the view the program haswhile the physical view is the way memory is really used.
One of theduties of the operating system is to connect the two: to map the logicalview onto the physical view.Programmers and users typically view an application or program ashaving several parts or segments. A program contains code – a mainprogram and user-defined functions. The system provides libraries ofcallable code. Data must be stored somewhere in memory. Operatingspace – heap and stack – is also needed. Each of these conceptual objectsis usually viewed as a segment. Individual components of a segment areusually seen as accessible from the beginning of that segment as anoffset.SEGMENTATION157This separation into segments is an idea reinforced by compilationand assembly tools. In addition, the execution format of an executablefile also supports segments.
Consider the format of executable files thathave the ELF format (e.g., from the Solaris operating system), shown inFigure 7.7. The format supports a large number of segments as dictatedby compilers and assemblers. The assembler for the SPARC architectureforces programmers to use at least two sections: code and data. This istypical and compilation tools are free to expand on this.From previous discussions, we know that this logical view of segmentsof an application is not actually the way things are done. Memory isdivided by pages and program memory is placed into these pages, whichmay be arbitrarily scattered throughout physical memory.
Segmentation,then, is a way to keep the user view of memory segments intact evenwhen the implementation in physical memory is quite different.As with virtual memory, we must deal with logical-segment addressesand physical-segment addresses – and with the translation between them.Segments are typically numbered and this number can be used as part ofthe logical address. For example, we might use an address format suchas <segment number, offset>, where the segment number is given as theleftmost part of the address and the offset within the segment is given asthe rightmost part of the address.Access to segments is typically assisted by hardware.
As with virtualmemory and paging tables, MMUs keep a segment table to help accesssegments. This table aids physical-address calculation through the processELF headerProgram headertableSegment 1Segment 2...Segment nOptional sectionheader tableFigure 7.7 ELF executable file format158MEMORY MANAGEMENToutlined in Figure 7.8. Like page tables, segment tables change with everycontext switch.Figure 7.9 shows four segments: the main program, the static dataarea, the heap and library functions. Each of these segments is numbered.The segment table shown in Figure 7.9 maps each segment to a memorypage.MemorySegment OffsetCPU+Segment tableSegmentbaseFigure 7.8Segmentation hardware-address calculationMain programsegment 0Seg0123Static data areasegment 1Heapsegment 2Addr1500016000154001620015000Segment 015400Segment 21600016200Segment 1Segment 3Librarysegment 3Figure 7.9Example of segment tablesMEMORY IN SYMBIAN OS159It is possible to combine segmentation and virtual paging.
This amountsto a double table calculation: the segmentation table points to a virtualaddress, which is translated through a page table to a physical address.This is quite a bit of overhead in address calculation, so many machinearchitectures provide special registers to hold portions of the segmenttable.
For example, the Intel 80386 had six segment registers, supportingprograms with up to six segments. The advantage to using both segmentation and paging is in using a fully functional set of memory models.Paging can be used for system performance and segmentation can beused to support programmer modeling.7.5 Memory in Symbian OSSymbian OS provides a great example of a system that does not use avirtual-memory–swap-space model for its memory management. It does,however, use most other mechanisms we have discussed for managingits memory, including hardware MMUs.Symbian OS is a 32-bit operating system, which means addresses canrange up to 4 GB.
However, it employs the same abstractions as largersystems: programs must use logical addresses, which are mapped bythe operating system to physical addresses. Programs may be placed atarbitrary locations in memory. At any given time, a program does notknow where exactly it is in memory, so the use of logical addresses isimportant.As with most systems, Symbian OS divides memory into logical pagesand physical frames. Frame size is usually 4 KB, but is variable.
Sincethere can be 4 GB of memory, a frame size of 4 KB means a page tablewith over a million entries. With limited sizes of memory, Symbian OScannot dedicate 1 MB to the page table. In addition, the search and accesstimes for such a large table would be a burden on the system.To solve this, Symbian OS adopts a two-level page-table strategy, asshown in Figure 7.10. The first level, the page directory, provides a linkto the second level and is indexed by a portion of the logical address(the first 12 bits). This directory is kept in memory and is pointed to bythe translation table-base register (TTBR). A page-directory entry pointsinto the second level, which is a collection of page tables.
These tablesprovide a link to a specific page in memory and are indexed by a portionof the logical address (the middle 8 bits). Finally, the page in memory isindexed by the last portion of the logical address (the last 12 bits).160MEMORY MANAGEMENTVirtual address10000010110000000101000001100111Page directory indexPage table indexPage directory indexPage directoryPage tablesPhysical memoryMemory pageFigure 7.10 Paging and virtual addresses in Symbian OSHardware assists in this logical-to-physical address-mapping calculation. While Symbian OS cannot assume the existence of any kind ofhardware assistance, most of the architectures on which it is implementedhave MMUs.
The ARM processor, for example, has an extensive MMU,complete with a TLB to assist in address computation.What happens when a page is not in memory? In Symbian OS, thisrepresents an error condition, because all application-memory pagesshould be loaded when the application is started. Remember that DLLsare pulled into memory by small stubs of code linked into the applicationexecutable, not by a page fault on a missing memory page. Since SymbianOS can address 4 GB of memory and it is unlikely that a smartphonewould have such a large amount of physical memory, there might besituations when a page is referenced that is not in memory.
Such areference would cause an ‘unhandled exception’ error, terminating theuser’s application. Users of Symbian OS who have experienced a KERN-3EXEC error when running an application have seen this happen.Despite the lack of swapping, memory is very dynamic in Symbian OS.Applications are context-switched through memory and, as we stated,MEMORY IN SYMBIAN OS161are loaded into memory when they start execution. The memory pageseach application requires can be statically requested from the operatingsystem upon loading into memory.
Dynamic space – e.g., for the heap – isbounded, so static requests can be made for dynamic space as well.Memory frames are allocated to pages from a list of free frames; if no freeframes are available, then an error condition is raised. We cannot replacememory frames that are used with pages from an incoming application,even if the frames are for an application that is not executing currently.This is because there is no swapping in Symbian OS and there is no placeto which it can copy the displaced pages.There are four different versions of the memory implementation modelthat Symbian OS uses. Each model was designed for certain types ofhardware configuration.• The moving model was designed for early ARM architectures (ARMversion 5 and before). The page directory in the moving model is 4 KBlong and each entry holds 4 bytes, giving the directory a size of 16 KB.Memory pages are protected by access bits associated with memoryframes and by labeling memory access with a ‘domain’.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
