WO2008071990A1

WO2008071990A1 - Dynamic memory allocation

Info

Publication number: WO2008071990A1
Application number: PCT/GB2007/004810
Authority: WO
Inventors: Toby Gray
Original assignee: Symbian Software Limited
Priority date: 2006-12-15
Filing date: 2007-12-14
Publication date: 2008-06-19
Also published as: GB0625088D0; GB2444746A

Abstract

A method for identifying a region in which to store a block of data in a memory, the memory being under the control of a memory controller arranged to treat the memory as comprising a plurality of memory sections of equal size and to maintain a record of which of those memory sections are allocated and which memory locations within those sections are in use, the method comprising: determining an overlap amount equal to the remainder when the size of the block of data is divided by the size of a memory section; and analysing the memory to identify a valid region in which to store the block of data, subject to the constraints that regions considered as valid: include contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory at least the size of the overlap amount but exclude contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory less than the size of the overlap amount.

Description

DYNAMIC MEMORY ALLOCATION

This invention relates to a method for identifying a region suitable for storing a block of data in a memory.

Executable code may be stored in non-execute-in-place (non-XIP) memory such as NOR Flash. NOR Flash is an electronically erasable and re-writable ROM (read only memory). Code stored in a non-XIP memory has to be loaded into Random Access Memory (RAM) before it can be executed. This means that some scheme must be used for determining where the information loaded from the memory should be stored in the RAM.

Loading code into RAM may involve forming a ROM image, which is a dataset in RAM containing a copy of the code from a read-only memory. One approach for loading the code from the non-XIP memory to the RAM is to place all code sections adjacent to each other statically when the ROM image is built. When the device that is to execute the code is switched on, the entire ROM image is loaded into RAM. However, this means that all the code sections are loaded into RAM, including code sections which have yet to be requested. This approach therefore uses memory in an inefficient way because it allocates memory for code before it is known if the code will be used. This is typically a waste of memory as not all of the code in a device is used all the time.

A second approach is to round up the size of each section of loaded code to a certain size and then allocate this memory when the code section is loaded. The size to round up to is typically the page size, which is 4096 bytes for most devices. A page is typically the minimum size of memory which can be allocated and de-allocated freely. This approach leads to a situation where each page is only ever occupied by one code section. This has the advantage that memory allocated to code sections that have not been used can be readily re-allocated (because each code section is allocated a whole number of pages). However, this approach also has the disadvantage of wasting memory (on average 2048 bytes of RAM per code section). This is because the size of the code sections is rounded up to whole pages and the unused "rounded space" is not used for anything else in the system.

Many schemes exist for dynamic memory allocation. However, these existing schemes are intended for allocating program data rather than program code. One of the simplest of these is a first fit heap. The first fit heap algorithm implements a list of free memory locations by maintaining a record of which pages are allocated. Allocated pages are those pages that are currently storing data and which have not been deallocated (e.g. because the data stored in that page has not been used). An allocated page need not have all its memory locations allocated at one time, i.e. an allocated page may be only partially filled. When the unit that is performing memory allocation receives a request for X bytes of storage, it searches the list for an available block of memory that can accommodate the X bytes. Typically the memory allocation unit searches the list of available memory until it finds a block of available memory of size greater than or equal to X bytes. The first identified block of memory of size greater than or equal to X bytes is then used to accommodate the X bytes of data.

The first fit heap algorithm may appear suitable for code allocation as it would tend to fit the code together in a sensible way without wasting RAM on rounding to page boundaries. However, the first fit heap scheme tends to suffer from memory fragmentation as relatively large blocks of memory tend to be split into smaller ones. Thus, it may be that future memory requests cannot be satisfied because although the sum of all free memory may be larger than the requested amount, that free memory does not form a contiguous block of memory and therefore cannot be used to store the required data. Therefore, small sections of memory that cannot be allocated are effectively wasted. A further disadvantage of the first fit heap algorithm is that it does not take page boundaries into account. Therefore, if the first fit heap algorithm were used to load code into a memory, a single code section would typically be allocated a section of memory that crossed one or more page boundaries. Although it is possible to de-allocate a page of memory within a heap if none of that page is used, it is not possible to de-allocate part of a page. Therefore, loading code into memory using the first fit heap algorithm would tend to result in wasted memory as unused code sharing a page with a used code section could not be de-allocated.

There is therefore a need for an improved method for allocating memory to program code.

According to a first embodiment of the invention, there is provided a method for identifying a region in which to store a block of data in a memory, the memory being under the control of a memory controller arranged to treat the memory as comprising a plurality of memory sections of equal size and to maintain a record of which of those memory sections are allocated and which memory locations within those sections are in use, the method comprising determining an overlap amount equal to the remainder when the size of the block of data is divided by the size of a memory section and analysing the memory to identify a valid region in which to store the block of data, subject to the constraints that regions considered as valid include contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory at least the size of the overlap amount but exclude contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory less than the size of the overlap amount.

The regions considered as valid may also include contiguous areas of memory sufficient to accommodate the block of data and that commence in an unallocated memory section.

The step of analysing the memory to identify a valid region may comprise identifying a contiguous area of memory sufficient to accommodate the block of data and determining if the identified area is considered to be valid. The step of analysing the memory may also comprise, if a first contiguous area of memory identified as being sufficient to accommodate the block of data is considered not to be valid, identifying a second contiguous area of memory sufficient to accommodate the block of data and determining if the second identified area is considered to be valid.

The step of identifying a second contiguous area may comprise identifying a contiguous area of memory sufficient to accommodate the block of data and that commences in an unallocated memory section adjacent to the allocated memory section of the first contiguous area.

The method may comprise repeatedly identifying valid regions in which to store the block of data and storing the block of data in the one of those regions that commences in an allocated memory section that includes unused memory closest in size to the overlap amount.

According to a second embodiment of the invention, there is provided a memory controller for identifying a region in which to store a block of data in a memory, the memory controller being arranged to treat the memory as comprising a plurality of memory sections of equal size and to maintain a record of which of those memory sections are allocated and which memory locations within those sections are in use, the memory controller being arranged to determine an overlap amount equal to the remainder when the size of a block of data is divided by the size of a memory section, analyse the memory to identify a valid region in which to store the block of data, subject to the constraints that regions considered as valid include contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory at least the size of the overlap amount but exclude contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory less than the size of the overlap amount.

The memory controller may be arranged to identify a contiguous area of memory sufficient to accommodate the block of data and determine if the identified area is considered to be valid. The memory controller may be arranged to, if the identified area is considered to be valid, store the block of data in the identified area.

The memory controller may be arranged to, if the identified area commences in an allocated memory section that includes unused memory exceeding the size of the overlap amount, store a part of the data block equal in size to the overlap amount in the allocated memory section and store the remainder of the data block in an unallocated memory section(s).

The memory controller may be arranged to identify a region in which to store a block of data in a memory according to embodiments of the invention.

According to a third embodiment of the invention, there is provided an operating system arranged to operate as a memory controller according to embodiments of the invention.

For a better understanding of the present invention, reference is made by way of example to the following drawings, in which:

Figure 1 shows data being stored in memory locations determined to be suitable according to an embodiment of the invention;

Figure 2 shows the steps of a memory allocation method according to an embodiment of the invention;

Figure 3 shows an example of a data block being stored in memory according to an embodiment of the invention;

Figure 4 shows an example of a data block being stored in memory according to an embodiment of the invention; and

Figure 5 shows a device on which the present invention can be implemented. One embodiment of the invention provides a method for identifying a region of memory that is suitable for storing a block of data. Where possible, embodiments of the invention match a data block with a partially allocated memory page, so as to try and maximise the amount of data allocated to each page. This is done in such a way as to minimise the number of pages partially filled by data relating to a particular code section.

In at least some embodiments of the invention, regions of memory may be considered as either valid or invalid for storing a data block. When determining where a data block may be stored, a contiguous area of memory is identified that is sufficiently large to be able to store the data block. If this identified area commences in an allocated memory section (i.e. a memory section that is already partly filled) the identified area may not be a valid area of memory for storing the data block. To determine whether or not the identified area is a valid region, a modulo operation is performed on the data block relative to the amount of data that can be stored in each memory section. The result of the modulo operation, the "overlap amount", is compared with the amount of spare memory capacity in the allocated memory section. If the overlap amount does not exceed that spare capacity, then the identified area of memory is considered to be a valid region of memory for storing that data. If the overlap amount does exceed that spare capacity, then the identified area of memory is considered not to be a valid region of memory for storing that data.

Preferably the identified section of memory is a contiguous memory section, e.g. a block of storage locations associated with a sequence of contiguous addresses, so that a particular code section can be easily read from memory. The contiguous sequence of addresses is typically a contiguous sequence of virtual addresses. However, the contiguous sequence of addresses may also be a contiguous sequence of physical addresses. The memory controller may maintain a record of which memory locations are available., i.e. those storage locations that are currently empty or which are available for reallocation. Unavailable storage locations may suitably be those which are currently storing data and which are not available for reallocation. The memory is preferably arranged in memory sections (e.g. pages) that each have the same number of memory locations associated with them. The memory controller is preferably arranged to monitor usage of data stored in the memory so that it can determine when data stored in a memory section is unused. When the memory controller identifies an allocated memory section that is storing only unused data the memory controller is preferably arranged to deallocate the memory locations associated with that memory section, i.e. so that those memory locations are once again available for storing data.

The methods of data allocation according to at least some embodiments of the invention are advantageous because they enable data relating to different code sections to share pages, thus avoiding the memory wastage of the "rounding" allocation scheme, and because they reduce the number of partial pages that are used to store a particular section of code. This is advantageous because a page is typically the smallest amount of memory that can be readily deallocated. This means that the storage capacity in a page storing data relating to two or more code sections cannot be reallocated unless each of those two or more code sections is unused. Therefore, if just one of the code sections is unused, the storage capacity allocated to data relating to that code section in the page is effectively "wasted" because that storage capacity cannot be reallocated. By minimising the number of pages partly filled with a particular section of code, the number of pages affected by an unused code section can be reduced.

A suitable method of identifying a section of memory for accommodating a code section is by searching through a list of storage locations to find a block of memory that is equal to or larger than the amount of data required to store the code section. This search may suitably be carried out in a similar way to the search according to the first fit heap algorithm.

The modulo operation may suitably be performed as an additional step in an algorithm otherwise similar to a first fit algorithm. For example, the modulo operation may be performed after a suitably sized section of memory has been identified which incorporates a partly filled page, in order to determine whether the overlap amount can be incorporated in the available memory locations of the partly filled page.

An example of how a memory allocation method according to an embodiment of the invention operates is shown in figure 1. In figure 1 , an amount of data to be stored in memory is shown at 101. The vertical lines 102 represent the page boundaries. In the diagram labelled A of figure 1 , a section of memory has been identified that is available and large enough to store the amount of data to be stored. The amount of data 101 is shown in this identified location. The hatched areas 103 represent storage locations in the same page as storage locations identified as being suitable for storing the data. Diagram A therefore shows two pages that could potentially be affected by wasted storage capacity if data 101 is not used. The two centre pages would not be affected by wasted storage capacity in the same way, as both pages would only be storing data relating to one code section. Therefore, if the code section is not used, the two centre pages can be readily deallocated.

The problem outlined above is addressed by calculating a value X. This is the amount that the requested size is over the next lower integer multiple of the page size, in other words the remainder when the requested size is divided by the page size. X can therefore be considered as the overlap amount.

If the start of the region which will be allocated to the code section is X or fewer bytes from the start of the next page then the placement is determined not to be suitable. If the placement is determined not to be suitable, it is determined whether the code section may be accommodated by storing that code section from the start of the next page. This is shown in diagram B of figure 1 , in which the code section is moved to the page boundary, leaving the space below as being available (as demonstrated by going from A to B). If the code section would not fit if it were moved up to the page boundary then another location should be found to place the code section. Finding another location for the code section preferably involves repeating the steps of identifying a suitable location and checking that the identified location is not within X of the next page. As can be seen from diagrams A and B of figure 1 , moving the code section up to the next page boundary if the space remaining between the start of the region to be allocated and that page boundary is insufficient to accommodate the overlap amount has the effect of reducing the number of partly filled pages affected by that code section from two to one.

Two worked examples will now be described, both of which demonstrate some of the advantages offered by storing data according to embodiments of the invention. The first example is shown in figure 3. Time is on the vertical axis, with time increasing down the page and location in memory is on the horizontal axis. Line 1 shows how two code segments, named CS 1 and CS 2, are allocated within the heap. In this example an attempt is made to allocate a code segment which is a page and a half in size. This makes X (the overlap amount) half a page. To start with there are 3 pages of RAM allocated on line 1 : page 1 , 2 and 6. A conventional first fit heap allocation algorithm would attempt to place the new allocation of a page and a half immediately above CS 1 , as this is where it first fits in memory. This is demonstrated on line 2. However, with the additional constraint that the start of the code section may not lie X or fewer bytes below a page boundary, the placement of the code in this position is not permitted. This is shown on line 3 where the forbidden range below the start of page 3 is shown. This leads to the chosen placement as being at the start of page 3. This is shown on line 4. At line 4 there are currently 5 pages of RAM allocated: page 1 , 2, 3, 4 and 6. Line 5 demonstrates why this extra constraint helps save the amount of RAM allocated. If CS 1 is deleted then only 3 pages of RAM still need to be allocated: page 3, 4 and 6. Had the first place which had been considered for the new code segment been used then page 2 would still need to be used, as the new code segment would have been within pages 2, 3 and 4, instead of just pages 3 and 4.

The second example is shown in figure 4 and demonstrates some of the advantages of embodiments of the invention over aligning code to page boundaries (e.g. the rounding method). In step 1 two pages are in use by the only loaded code segment, CS 3. CS 3 is 1.1 pages in size. As before an attempt is made to allocate a section of code 1.5 pages in size. Step 2 demonstrates where this code would be placed if a page aligned placement method was used instead of a heap. As shown in the figure, this would lead to all of the first 4 pages being used. Step 3 demonstrates the first place to be considered for placement. In this situation the start of the new code section is not within the forbidden range determined by X (the overlap amount). This means that this is an acceptable place for the new code section. Step 4 demonstrates how the code would be placed, needing one page less than if the page aligned placement method was used instead of the dynamic alignment heap method. Step 5 once more demonstrates that, when CS 3 is removed, only the two necessary pages for the newly allocated code will be used, demonstrating why this placement location was acceptable.

Embodiments of the invention therefore combine some of the benefits of using a heap to allocate code with some of the benefits of rounding the allocated size up to a multiple of the page size. Allocating in multiples of page size has the advantage that when code is no longer needed all the memory used by that code can be released. However, it has the disadvantage of wasting on average 2048 bytes of memory per code section. This problem is addressed in embodiments of the invention by, when suitable, sharing pages between different code sections.

The steps of a memory allocation method according to embodiments of the invention are shown in figure 2. In step 202 a memory block having sufficient storage capacity for accommodating a code section is identified. In step 204 it is checked whether the amount of storage space required to store the code section is an exact multiple of the page size. If the required storage space is an exact multiple of the page size, the method proceeds to step 206 which determines whether the identified memory block starts from a section boundary. If so, the code section is stored in the identified memory block in step 208. If the memory block does not start at a section boundary, the code section could be stored in the identified memory block. However, this is not a preferred option because storing the code section from part way into a page will result in the code section partially filling two pages rather than being confined to completely filled pages. Instead it is preferred to check whether there is sufficient storage capacity from the next page boundary to accommodate the code section (step 210). If there is sufficient storage capacity from the next page boundary, the code section is stored from that boundary in step 212. If not, the method returns to step 202 and to identifying a memory block that has sufficient storage capacity to store the code section.

If the required storage space is not a multiple of the page size, the method proceeds to step 214 which calculates the overlap amount by dividing the required amount of memory by the page size and setting the overlap amount to be the remainder of the division operation. This division operation need not be a separate step as shown in figure 2 but may be incorporated in step 204, i.e. so that the same operation is used to determine whether the code section is an exact multiple of the page size and to determine the overlap amount. In step 218 it is determined whether the overlap amount is capable being stored between the start of the identified memory block (which will typically be an available storage location located adjacent to an unavailable storage location) and the next page boundary. If there is sufficient storage capacity to accommodate the overlap amount in the partly-filled page, then the identified memory block is used to store the code section in step 208. If there is insufficient storage capacity in the partly-filled page to accommodate the overlap amount, the method proceeds to step 220 in which it is determined if the code section could be stored from the first page boundary in the identified memory block. If so, the code section is stored from that page boundary in step 212. If not, the method returns to step 202 and to identifying a memory block capable of identifying the code section.

Preferably the memory controller has access to a record of available and/or unavailable memory blocks. The memory controller may suitably identify an area of memory for storing a memory block by searching the record in order and stopping when a block of available memory that is capable of storing an amount of data equal to or greater than the amount of data to be stored is identified. If that memory block is determined to be unsuitable, the controller may continue to search the memory record from where the search was previously stopped.

The memory controller may search a list of memory locations to try and identify an allocated page that has sufficient available memory to store an amount of data equal to the overlap amount. Preferably, the memory controller searches for an allocated page that forms part of a contiguous sequence of memory locations sufficient to store the data block.

It may be that the identified memory block starts from a storage location that is located more than the overlap amount from the next page boundary. In this case, the method may include determining if the data to be stored can be accommodated by moving the start location away from that storage location to a storage location that is located the overlap amount from the next page boundary. In this way, the number of pages that are partly filled by the code section can be restricted to one page.

The memory controller may search the memory for a suitably sized area of memory commencing in an allocated page that contains unused memory equal in size to the overlap amount. If such an area of memory cannot be identified, the memory controller may instead select the area of memory having unused memory closest in size to the overlap amount.

If the identified memory block does not include a partly filled page then it may not be necessary to calculate the overlap amount as the code section will be stored from a section boundary.

The memory allocation methods described herein may suitably be performed by a memory controller. A memory controller according to embodiments of the invention may suitably be implemented in an operating system.

Although the methods described herein have referred specifically to allocating memory to program code, it should be understood that this is for the purposes of example only and that the methods and memory controller may be used for storing any type of data.

Embodiments of the invention may be advantageously used to load code from any storage memory into a randomly addressable memory so that the code may be executed. For example, embodiments of the invention may be advantageously used when loading code from a hard drive, from NAND flash or from ROM.

The memory allocation methods described herein can provide the following advantages:

• The methods allow for different code sections to be placed next to each other. Statistically, if it is assumed that all code segments are random in size, this leads to only wasting an average of 1024 bytes per allocation (as compared with the rounding method, which wastes on average 2048 bytes per allocation). However in reality the distribution of size of code sections is not uniformly random, which means that in practice only around 200 bytes are wasted per allocation: a 90% reduction in wasted memory.

• In the worst case scenario the method described herein uses the same amount of memory as the rounding method of placement. In current heap allocation systems, in which whole pages which are unused are de-allocated, it is possible for each code section to effectively use an extra 4000 bytes of memory compared to the rounding method due to the fragmentation mentioned earlier. This is demonstrated in figure 1 above by the shaded regions on line A compared with if the code was placed on a page boundary as it is in line B. The use of the allocation method according to embodiments of the invention is only as bad as the current methods in worst case scenarios, with the majority of cases being significantly better.

Embodiments of the invention are particularly suitable for use in mobile phones or other mobile products because they allow less RAM to be used. This in turn reduces the material cost of mobile phones and other mobile products because there are fewer RAM chips required in each product. Therefore, embodiments of the invention are of benefit to manufacturers as they allow a lower priced product or a greater profit margin. Preliminary investigations have indicated that embodiments of the invention can save around 550 kilobytes of RAM out of a total used across a system of 12720 kilobytes.

A further advantage of allocating memory according to embodiments of the invention is that the memory consumes less power as less RAM is used to store code than in existing methods of loading code into RAM. This is particularly the case if unused banks of RAM are powered down.

Figure 5 shows a mobile phone in which a memory allocation method according to an embodiment of the invention may suitably be implemented. The mobile phone, shown generally at 1 , includes a non-volatile memory 2 that stores instructions defining application programs (shown schematically at 3) and an operating system (shown schematically at 4). The mobile phone may be configured in such a way that the operating system controls the memory. The mobile phone has a CPU 5 which can execute the instructions stored in memory 2. The non-volatile memory also stores data (shown schematically at 6) defining a series of resource usage profiles. The mobile phone has a keypad 7 by which a user can control the operation of the phone. The mobile phone has an RF transceiver 8 coupled to an antenna 9, by means if which it can transmit and receive data according to a mobile phone radio protocol. The transceiver is coupled to the CPU. Data received by the transceiver is passed to the CPU and data can be passed from the CPU to the transceiver for transmission. The mobile phone has a display 10 for displaying data to a user, a loudspeaker 11 for producing sound (e.g. to reproduce audio data received through the transceiver 8) and a microphone 12 for receiving sound (e.g. to capture audio data that is subsequently to be transmitted by the transceiver 7). The mobile phone is powered by a battery 13. The mobile phone may be provided with a working memory, which may be on the CPU or in RAM (random access memory) 15 coupled to the CPU. The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A method for identifying a region in which to store a block of data in a memory, the memory being under the control of a memory controller arranged to treat the memory as comprising a plurality of memory sections of equal size and to maintain a record of which of those memory sections are allocated and which memory locations within those sections are in use, the method comprising: determining an overlap amount equal to the remainder when the size of the block of data is divided by the size of a memory section; and analysing the memory to identify a valid region in which to store the block of data, subject to the constraints that regions considered as valid:

- include contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory at least the size of the overlap amount but

- exclude contiguous areas of memory sufficient to accommodate the block of data and that commence in an allocated memory section that includes unused memory less than the size of the overlap amount.

2. A method as claimed in claim 1 , wherein the regions considered as valid include contiguous areas of memory sufficient to accommodate the block of data and that commence in an unallocated memory section.

3. A method as claimed in claim 1 or 2, wherein the step of analysing the memory to identify a valid region comprises identifying a contiguous area of memory sufficient to accommodate the block of data and determining if the identified area is considered to be valid.

4. A method as claimed in claim 3, wherein the step of analysing the memory to identify a valid region comprises, if a first contiguous area of memory identified as being sufficient to accommodate the block of data is considered not to be valid, identifying a second contiguous area of memory sufficient to accommodate the block of data and determining if the second identified area is considered to be valid.

5. A method as claimed in claim 4, wherein the step of identifying a second contiguous area comprises identifying a contiguous area of memory sufficient to accommodate the block of data and that commences in an unallocated memory section adjacent to the allocated memory section of the first contiguous area.

6. A method as claimed in any preceding claim, comprising repeatedly identifying valid regions in which to store the block of data.

7. A method as claimed in claim 6, comprising storing the block of data in the one of those regions that commences in an allocated memory section that includes unused memory closest in size to the overlap amount.

8. A memory controller for identifying a region in which to store a block of data in a memory, the memory controller being arranged to treat the memory as comprising a plurality of memory sections of equal size and to maintain a record of which of those memory sections are allocated and which memory locations within those sections are in use, the memory controller being arranged to: determine an overlap amount equal to the remainder when the size of a block of data is divided by the size of a memory section; analyse the memory to identify a valid region in which to store the block of data, subject to the constraints that regions considered as valid:

9. A memory controller as claimed in claim 8, wherein the memory controller is arranged to identify a contiguous area of memory sufficient to accommodate the block of data and determine if the identified area is considered to be valid.

10. A memory controller as claimed in claim 9, wherein the memory controller is arranged to, if the identified area is considered to be valid, store the block of data in the identified area.

11. A memory controller as claimed in claim 10, wherein the memory controller is arranged to, if the identified area commences in an allocated memory section that includes unused memory exceeding the size of the overlap amount, store a part of the data block equal in size to the overlap amount in the allocated memory section and store the remainder of the data block in an unallocated memory section(s).

12. A memory controller as claimed in any of claims 8 to 11 , wherein the memory controller is arranged to identify a region in which to store a block of data in a memory according to the method of any of claims 1 to 7.

13. An operating system arranged to operate as a memory controller according to any of claims 8 to 12.

14. A method substantially as herein described with reference to the accompanying drawings.

15. A memory controller substantially as herein described with reference to the accompanying drawings.

16. An operating system substantially as herein described with reference to the accompanying drawings.