GB2460465A - Arranging frequently used computer code together - Google Patents

Arranging frequently used computer code together Download PDF

Info

Publication number
GB2460465A
GB2460465A GB0809927A GB0809927A GB2460465A GB 2460465 A GB2460465 A GB 2460465A GB 0809927 A GB0809927 A GB 0809927A GB 0809927 A GB0809927 A GB 0809927A GB 2460465 A GB2460465 A GB 2460465A
Authority
GB
United Kingdom
Prior art keywords
code
computer code
permanent storage
stored
unarranged
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0809927A
Other versions
GB0809927D0 (en
Inventor
Handley Dan
Dive-Reclus Corinne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Symbian Software Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj, Symbian Software Ltd filed Critical Nokia Oyj
Priority to GB0809927A priority Critical patent/GB2460465A/en
Publication of GB0809927D0 publication Critical patent/GB0809927D0/en
Publication of GB2460465A publication Critical patent/GB2460465A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44557Code layout in executable memory

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Computer code for a computer with a page based memory management system is arranged so that the most frequently needed parts of the code are grouped together. The code is then stored in the permanent storage of the computer. The code may replace a previous version of the code which had not been arranged with the method. The code may be arranged by re-linking previously compiled code. The code may be arranged in order of how often it is needed. How often the code is needed may be determined by a simulation. It may be determined from the frequency with which components of the code are fetched by a memory management system.

Description

ROM LAYOUT
FIELD OF THE INVENTION
The present invention relates to the arrangement of computer code to be stored in permanent storage.
BACKGROUND OF THE INVENTION
Most modern computer systems have a stored program architecture with a programmable microprocessor, a random access memory (RAM), and a more permanent storage means such as a ROM memory, optical storage or magnetic storage.
A computer program is a series of instructions executable by the microprocessor. The program is usually stored on the permanent storage, before being loaded into the main memory (the RAM). The program is then executed from the main memory by the microprocessor one instruction at a time.
A page is a fixed-length block of memory. It is usually the smallest unit of data for transfer between permanent storage and main memory. Page size is usually determined by the computer architecture and has a uniform size, e.g. 4k.
For large and complex programs, it maybe difficult or undesirable to load the entire program into RAM. Instead, parts of the program are loaded into RAM, whilst parts of the program are left in permanent storage and are only loaded into RAM when they are required. When an attempt is made to access program code that is not present in the main memory, a page fault is raised.
In response to the page fault, the missing page is fetched from the permanent storage to the main memory. If a program requires code to continue running and that code is not available in main memory, a page fault is raised and the program normally has to wait until the page containing the code has been fetched from permanent storage before it can continue. Consequently, page faults slow down the system and are undesirable.
In modern devices, especially portable and handheld devices such as smartphones, programs are often stored in a ROM. The ROM can be based on a NAND persistent storage technology. Programs stored in this way are often of the type known as firmware'. Firmware is used by the vast majority of digital cameras, mobile phones and other microprocessor-based portable electronic devices to store executable programs that do not need to be altered once the program has been finalised.
However, several problems exist with this technology. Firstly, ROM, and in particular NAND memory tends to be slow relative to RAM. This means that every time a page fault occurs, there is a significant delay in program execution. Secondly, NAND memory suffers from wear over time and, due to the read operation that is performed on every page fault, the more frequently a page fault occurs, the quicker the NAND memory will wear out.
Another problem exists with this arrangement. Since pages are of a fixed length, the code required by the program calling the page fault is likely to occupy only a subsection of the fetched page. It follows that when that page is loaded into main memory, part of the loaded data is not actually needed.
This is wasteful for two reasons. Firstly, loading data from permanent storage to main memory is slow and a waste of time when unnecessary. Secondly, the unnecessary data will occupy space in main memory. If many such pages are loaded into main memory, a substantial portion of main memory will be used to store data or code that is not needed by the processor.
Therefore, a solution is required that will reduce the number of times that pages are fetched from the permanent store and also reduce the amount of wasted main memory once the pages are loaded.
SUMMARY OF THE INVENTION
In a first aspect the present invention provides a method of arranging computer code to be stored in permanent storage and accessible by means of a page-based memory management system configured to fetch one or more pages containing a component of the computer code needed by a microprocessor from the permanent storage and place the one or more pages in main memory, the method comprising: based on usage data indicating which parts of the computer code are most frequently needed by a microprocessor, arranging the code such that the most frequently needed parts of the computer code are grouped together; and storing the arranged code in the permanent storage.
In a second aspect, the present invention provides a computing device comprising: a microprocessor; a main memory; permanent storage; and a page-based memory management system, wherein the permanent storage medium has stored therein computer code arranged according to the above method.
In a third aspect, the present invention provides a computer readable medium having program instructions stored thereon for performing the above method.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings: Figure 1 is a schematic representation of a computing device; and Figure 2 is a flow chart representing a method of arranging computer code to be stored in permanent storage.
DETAILED DESCRIPTION
Figure 1 shows a computing device 60 comprising a microprocessor 30, RAM (main memory) and permanent storage 10 (e.g. a hard disk or ROM), all interconnected by a main bus 110. The permanent storage 10 stores program code that can be executed by the microprocessor 30 to implement an operating system and user applications, making use of the RAM 20. A user can provide input to the system by means of suitable inputs such as a keypad 40 connected to a keypad controller 50, and a mouse 70 connected to a mouse controller 80. Output can be provided to a display 90 by means of a graphics hardware unit 100.
Programs executable on the device 60 include operating systems, user applications, and any other type of code executable on the device's microprocessor 30. To create executable code, a computer program must be compiled and linked. The linking step is distinct from the compiling step and can be performed without access to the original source code. The linking step involves using linker' software to link the program to any required libraries.
This compiling and linking process generates executable instructions and arranges all code and libraries into actual runtime memory locations.
The next step involves preparing the compiled and linked code so that it can be stored in permanent storage 10 available to the device 60. Such permanent storage 60 may comprise EPROM, Flash EEPROM memory (such as NAND memory), magnetic storage (such as a hard disk), or any other
suitable storage.
As most permanent storage memories are of a fixed size, it is possible and often very convenient to prepare an image' of a permanent storage memory in advance and write the image to the storage in one go, rather than to install programs and data separately. Such an image can describe the exact physical location in permanent storage that each byte of a compiled and linked program will occupy. This way, the location on the permanent storage medium of each function (stored for example, within a program or in a Dynamic Linked Library (DLL)) can be anticipated. As long as the physical properties of the permanent storage medium are constant between devices, an image prepared for one device can be used for any identical device.
Once an image is prepared, it is copied into the permanent storage 10.
Alternatively, the compiled and linked code may be copied directly into the permanent storage 10 without the step of preparing an image. It is particularly important, in the latter case, to ensure that any code is copied to the correct location within the permanent storage 10 -for example that any bootstrapping code (the first set of instructions executed by the device on power-on) is placed where the device 60 expects to find it.
When a program stored in the permanent storage 10 is executed by the device 60, portions of the program must be copied from the permanent storage 10 to RAM 20 before they can be processed by the microprocessor.
During a test phase, the program is run on the device 60 and put through a series of performance exercises which test the device's performance under high load. The program may be executed in a manner such that a particular feature of the program is tested to the limit of the device's hardware. This may involve placing especially burdensome tasks on specific functions of the program, such as operating the program to process high bit-rate video data, render complex HTML pages, or perform high speed data transfer between the device 60 and another device.
During the performance exercises, various aspects of the program and the device may be monitored to generate usage data. One statistic which may be monitored is the number of times the program triggers a page fault. This gives a broad indication of the proportion of code which is required in main memory when it has not been retrieved from permanent storage 20. Another statistic which may be monitored is the number of times each individual page is called by the program. A map of the pages can then be generated and used to identify frequently required code that is read time and time again. The map may comprise a list of the pages and the number of times each page has been called by the microprocessor 30. Preferably, the total number of page reads from the RAM 20 and the permanent storage 10 are counted; however, for simplicity of implementation the page reads listed in the map may be limited to those from permanent storage 10. A more detailed version of the map would include identification both of the pages read and the code within those pages that is actually required. Another statistic which may be monitored is that of the functions called most frequently. This will provide an indication as to which parts of the program should be kept constantly in main memory. This may be implemented using counters encoded into the functions, such that a counter incremented each time its function is called.
The value of the counters could then be used to derive a list of the most frequently used functions/libraries.
The performance exercises are described above as performed on the actual device 60. However, it is also possible instead to perform these exercises using a simulation of the code on the device. In some cases it may also be possible to generate the usage data theoretically, in the absence of real or simulated performance exercises, for example when it is known to the programmer that a particular function will necessarily be called very frequently.
The gathered usage data can then be sent either to the linker software or to the software responsible for generating the permanent storage medium image. The usage data provides the linker/image generator with information regarding the frequency with which certain components of the compiled program are required by the microprocessor 30. Each component may be a function (such as a function for processing an incoming video stream), resource (such as a frequently required bitmap), database, etc. A component may also comprise an entire DLL or other file, such as a JPEG image file.
The usage data may be used by the linker/image builder to prepare a revised version of the image in which each component of the compiled program is arranged in an optimised manner. This may include grouping the most frequently required components together in pages with other frequently required components. An advantage of this arrangement is that the majority of pages loaded into memory will comprise entirely of frequently required program components. This means that, since no portion of the pages will be wasted storing less frequently required code, the number of pages required to keep all the most frequently used components in memory is reduced and, since fewer pages will normally need to be read into RAM 20 to run a program, the memory footprint of the program will be reduced. Another advantage of this arrangement is that, since the many of the most frequently required components will already be loaded into RAM 20 when the program is running, the number of page faults raised for frequently required code will be reduced. As a result, when a task is performed that was the focus of the performance testing stage, the task can be performed more quickly, with fewer delays due to page faults. A final advantage of this arrangement is that, as fewer page faults occur, fewer reads are made from the ROM 10 and, consequently, the ROM 10 will sustain less wear and enjoy a longer usable life.
One optimised arrangement of pages involves arranging all the most frequently required components towards the beginning of the permanent storage 10 and the least frequently required components towards its end, such that a requirement frequency gradient is described across the memory space of the permanent storage 10. Preferably, where the permanent storage has a variable read speed depending on the location of the required data in the permanent storage 10, (e.g. the outer tracks of an optical disc loaded into a constant angular velocity optical drive can be read more quickly than the inner tracks), the most frequently required components are placed in the locations with the highest read speeds. Another optiniisation arrangement involves rearranging the most frequently required pages in a contiguous manner, so that the read access times for the most frequently required pages are reduced in the common event that adjacent pages are required.
A further advantage to optimising the arrangement of the program components within the permanent storage means is that the original program need not be recompiled to accommodate the optimisation process. If the optimisation process produces a relative arrangement of the program's components which is different to that of the original image, the physical location of the compiled program's components in the permanent memory store will be altered. This may require the linker to reform the links between the program components, but a recompiling step would not be necessary.
This allows optimisation of the software without access to the original source code. Therefore, a device manufacturer working to optimise the performance of their device could do so without access to the source code of the software running on the device.
The usage data may be used to optimise the paging out of memory pages.
Paging out occurs when the system has not required the contents of a particular page for a preset time period, whereupon it is either written back to permanent storage 10 and the corresponding space in the main memory is freed up, or in the case where the permanent storage 10 is read-only, deleted from RAM 20. In this embodiment, pages of memory which have been identified by the usage data as comprising infrequently required program components may be paged out sooner than those comprising more frequently required program components, when the RAM 20 becomes low on space. An advantage of this arrangement is the reduction in the fetching of pages, helping prevent thrashing behaviour.
Figure 2 illustrates an exemplary method of arranging computer code to be stored in permanent storage 10. In a first step 110, the computer code is arranged such that the most frequently needed parts of the computer code are grouped together. This arrangement is based on usage data indicating which parts of the computer code are most frequently needed by the microprocessor 30, The arranged code is then stored in the permanent storage 10.
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 the 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 individual 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 (18)

  1. CLAIMS1. A method of arranging computer code to be stored in permanent storage and accessible by means of a page-based memory management system configured to fetch one or more pages containing a component of the computer code needed by a microprocessor from the permanent storage and place the one or more pages in main memory, the method comprising: based on usage data indicating which parts of the computer code are most frequently needed by a microprocessor, arranging the code such that the most frequently needed parts of the computer code are grouped together; and storing the arranged code in the permanent storage.
  2. 2. The method of any preceding claim, wherein the unarranged code is stored in the permanent storage and storing the arranged code comprises replacing the stored unarranged code with the arranged code.
  3. 3. The method of any preceding claim, further comprising: re-linking the arranged computer code before it is stored in the permanent storage.
  4. 4. The method of any preceding claim, wherein arranging the computer code does not require the code to be recompiled.
  5. 5. The method of any preceding claim, wherein arranging the computer code further comprises grouping together the frequently required components into a contiguous arrangement.
  6. 6. The method of any preceding claim, wherein arranging the computer code further comprises grouping together infrequently required components of the computer code into a contiguous arrangement.
  7. 7. The method of any preceding claim, arranging the computer code further comprises contiguously grouping the components of the computer code in order of their frequency of requirement.
  8. 8. The method of any preceding claim, wherein the unarranged computer code is stored in permanent storage and storing the arranged computer code comprises replacing the unarranged computer code with the arranged computer code in the permanent storage.
  9. 9. The method of any preceding claim, wherein the usage data is simulated usage data obtained by analysing simulated use of the unarranged code.
  10. 10. The method of any of claims 1 to 8, wherein the usage data represents the frequency with which pages stored in permanent storage are fetched by a memory management system.
  11. 11. The method of any preceding claim, wherein the usage data represents the frequency with which components of the unarranged computer code stored in permanent storage are needed by a microprocessor.
  12. 12. The method of any preceding claim, wherein the usage data represents the frequency with which components of the unarranged computer code stored in permanent storage or in main memory are executed by a microprocessor.
  13. 13. The method of any preceding claim, wherein the analysed use is such that frequent paging of memory pages stored in permanent storage occurs.
  14. 14. The method of any of claims 1 to 12, wherein the analysed use is an expected typical use.
  15. 15. The method of any of claims 1 to 12, wherein the analysed use is such that frequent paging of memory pages containing a specific function of the unarranged computer code occurs.
  16. 16. The method of claim 15, wherein the specific function is a video data processing algorithm.
  17. 17. A computing device comprising: a microprocessor; a main memory; permanent storage; and a page-based memory management system, wherein the permanent storage medium has stored therein computer code arranged according to the method of any preceding claim.
  18. 18. A computer readable medium having program instructions stored thereon for performing the method of any of claims 1 to 16.
GB0809927A 2008-05-30 2008-05-30 Arranging frequently used computer code together Withdrawn GB2460465A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0809927A GB2460465A (en) 2008-05-30 2008-05-30 Arranging frequently used computer code together

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0809927A GB2460465A (en) 2008-05-30 2008-05-30 Arranging frequently used computer code together

Publications (2)

Publication Number Publication Date
GB0809927D0 GB0809927D0 (en) 2008-07-09
GB2460465A true GB2460465A (en) 2009-12-02

Family

ID=39637929

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0809927A Withdrawn GB2460465A (en) 2008-05-30 2008-05-30 Arranging frequently used computer code together

Country Status (1)

Country Link
GB (1) GB2460465A (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06332675A (en) * 1993-05-20 1994-12-02 Mitsubishi Electric Corp Shared library management mechanism
US5796989A (en) * 1995-03-20 1998-08-18 Apple Computer, Inc. Method and system for increasing cache efficiency during emulation through operation code organization
JP2003330730A (en) * 2002-05-15 2003-11-21 Matsushita Electric Ind Co Ltd Operating system arranging device
US20060041876A1 (en) * 2000-06-28 2006-02-23 Virtutech Ab Interpreter for executing computer programs and method for collecting statistics
JP2007102607A (en) * 2005-10-06 2007-04-19 Nec Corp Disk array device, data swap method, and program

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06332675A (en) * 1993-05-20 1994-12-02 Mitsubishi Electric Corp Shared library management mechanism
US5796989A (en) * 1995-03-20 1998-08-18 Apple Computer, Inc. Method and system for increasing cache efficiency during emulation through operation code organization
US20060041876A1 (en) * 2000-06-28 2006-02-23 Virtutech Ab Interpreter for executing computer programs and method for collecting statistics
JP2003330730A (en) * 2002-05-15 2003-11-21 Matsushita Electric Ind Co Ltd Operating system arranging device
JP2007102607A (en) * 2005-10-06 2007-04-19 Nec Corp Disk array device, data swap method, and program

Also Published As

Publication number Publication date
GB0809927D0 (en) 2008-07-09

Similar Documents

Publication Publication Date Title
US8589664B2 (en) Program flow control
US7823140B2 (en) Java bytecode translation method and Java interpreter performing the same
US9626170B2 (en) Method and computer program product for disassembling a mixed machine code
KR20130137702A (en) Systems, apparatuses, and methods for stride pattern gathering of data elements and stride pattern scattering of data elements
JP2006268833A (en) Method of instrumenting code having restrictive calling conventions
US20140149996A1 (en) Runtime emulating static thread local storage of portable executable software code
CN111158756B (en) Method and apparatus for processing information
CN102364430A (en) Microcontroller for supporting multi-programming on one time programmable memory and programming method
EP4152146A1 (en) Data processing method and device, and storage medium
WO2022057418A1 (en) Method and apparatus for running application program, terminal device and storage medium
JP2005182659A (en) Vliw type dsp and its operation method
US9262301B2 (en) Observability control with observability information file
CN103631971A (en) Recombining method and device for transplantable executive file
JP4870956B2 (en) Embedded program generation method, embedded program development system, and information table section
GB2460465A (en) Arranging frequently used computer code together
KR101670916B1 (en) Method for storing function and system device using the same
CN113971072A (en) Information processing method, device, equipment, storage medium and computer program product
CN112882753A (en) Program running method and device
CN115004150A (en) Method and apparatus for predicting and scheduling duplicate instructions in software pipelining loops
US6564178B1 (en) Method and apparatus for evaluating processors for architectural compliance
CN117313595B (en) Random instruction generation method, equipment and system for function verification
KR100329780B1 (en) Interrupt processing apparatus reducing interrupt response time
JP2005332110A (en) Simulation system
CN113495727A (en) Business component development method and device, electronic equipment and medium
CN116932044A (en) Instruction translation method and related equipment thereof

Legal Events

Date Code Title Description
COOA Change in applicant's name or ownership of the application

Owner name: NOKIA CORPORATION

Free format text: FORMER OWNER: SYMBIAN SOFTWARE LTD

WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)