WO2007056364A1

WO2007056364A1 - Apparatus and associated methods for reducing application startup latency

Info

Publication number: WO2007056364A1
Application number: PCT/US2006/043338
Authority: WO
Inventors: Dong Zhou; Mahesh Kallahalla; Manuel Roman
Original assignee: Ntt Docomo, Inc.
Priority date: 2005-11-10
Filing date: 2006-11-07
Publication date: 2007-05-18

Abstract

A method and apparatus is disclosed herein for reducing application startup latency. In one embodiment, a method comprises receiving a request to start an application on a mobile terminal, where the application has a first set of one or more pages of an executable image used when an application is initially started and a second set of one or more pages of the executable image stored in different logical devices in the mobile terminal used after the first set of one or more pages, and loading only the first set of one or more pages initially in response to the request.

Description

APPARATUS AND ASSOCIATED METHODS FOR REDUCING APPLICATION STARTUP LATENCY

PRIORITY

[0001] The present patent application claims priority to and incorporates by reference the corresponding provisional patent application serial no. 60/735,304, titled, "Apparatus and Associated Methods For Reducing Application Startup Latency", filed on November 10, 2005.

FIELD OF THE INVENTION

[0002] The present invention relates to an apparatus and associated methods for reducing application startup latency by identifying and using different handling of virtual memory (VM) pages used in application startup.

BACKGROUND OF THE INVENTION

[0003] One aspect of the usability of a mobile device is the startup latency of applications executed on the device. Startup latency is the time elapsed from a user commanding the "start" of an application (e.g., by double-clicking the icon of the application), to the application becoming ready to process user inputs (e.g., choosing a file to be opened, clicking on a hyperlink or a menu item to go to next screen). [0004] The need to optimize startup times is also important for applications used on mobile devices (as well as on desktop platforms) that are network-based and need to be downloaded, on-demand, onto devices for execution. For such applications, the startup time is the time elapsed from the start of the downloading process to the time when the application is ready to accept user requests. Short application startup latency, or "instantly on", is expected for mobile devices that offer good overall user experience. The state-of-the-art approach for reducing startup latency uses linearly addressable memory, such as NOR Flash, to execute applications "in-place". Execute in-place (XIP) improves startup speed as the executable image of the software is already in the physical memory space of the device and is in ready-to-execute form, thus saving the costs for loading the image from storage device into the main memory. [0005] XIP, however, also has several disadvantages. First, XIP increases the cost of a mobile device, both because NOR Flash memory is more expensive than NAND Flash or DRAM memory, and because XIP images cannot be compressed (thus requiring more storage space). Second, XEP code needs to be pre-linked. This means that it cannot use shared libraries, thereby increasing the size of the executable and, again, the storage space required. Third, Flash memory is typically several times slower than DRAM. Consequently, although an application that uses XIP starts up faster, it runs slower for its ensuing execution compared with a same application that does not use XEP (i.e., loaded into, and executed from, DRAM). [0006] Because of these drawbacks, mobile operating systems, such as some mobile editions of Linux, do not use XIP. In fact, they compress applications' executable images to reduce storage requirements. Such compression further increases application startup latency as uncompressing an executable image is much more costly than loading an executable image into memory.

[0007] US patent application no. 2002/0165993 discloses a system and method for separating GUI components from a monolithic component-based application, so that GUI components can be downloaded to and executed on client devices, while the rest of the application can execute on the server. The disclosed method for identifying a GUI component determines if the component has a software element that relates to a user interface. Wrappers are generated for GUI components and a protocol is described to enable components on a client device and on the server to talk to each other. The entire process can occur at the runtime of the application program. One drawback of this approach is that portions of the application used during startup are different from GUI components. Identifying GUI components does not help in identifying startup components. Consequently, it either does not help at all or does not help as much in reducing startup latency. Another drawback is that it is for component-based applications (Their example used is Java Beans), but not for non- component based applications. Typically, GUI components in applications are well defined and clearly demarcated, which makes them easy to locate and separate from the rest of the application.

[0008] US patent application no. 2004/0088701 discloses applying XD? to some selected applications, but not to other applications. Selection is based on monitored application usage. More frequently used applications are configured to execute in-place, while other applications are compressed and stored on secondary storage. Such a selection can be reconfigured online as application usage changes. One drawback of this approach is that its selection of XIP applications is solely based on application usage frequencies, regardless of the applications' original startup latencies. Therefore, the fact that applications with very short startup latency do not need to use XIP to further reduce startup latency is not addressed. Another drawback is that XIP is used for the entire application, which undermines the performance of the ensuing execution of the application (the read latency of XIP Flash memory is substantially more than that of DRAM). Lastly, their approach is not applicable for network-based applications.

[0009] Lee et al., at the 1999 USENIX Windows NT Symposium, for reducing the startup latency of Web and desktop applications. The described approach is based on page reordering and demand paging: procedures that are likely to be used by the application are placed into a single continuous block in the binary, and are downloaded before the application can be executed, while the rest of the binary is downloaded on demand. One drawback of Lee et al.'s approach is that they separate procedures that will likely be used from the rest of the executable image. Since the combined size of procedures that will likely be used is likely much larger than that of start up memory pages, their approach is less effective in reducing startup latency. Another limitation of their approach is that their techniques do not exploit the possibility of storing two parts on different memory/storage modules, which can be used to further reduce startup latency for devices with resource constraints.

SUMMARY OF THE INVENTION

[0010] A method and apparatus is disclosed herein for reducing application startup latency. In one embodiment, a method comprises receiving a request to start an application on a mobile terminal, where the application has a first set of one or more pages of an executable image used when an application is initially started and a second set of one or more pages of the executable image stored in different logical devices in the mobile terminal used after the first set of one or more pages, and loading only the first set of one or more pages initially in response to the request. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only. [0012] Figure IA is a data flow diagram of one embodiment of a process for identifying startup pages (SUPs), reorganizing an executable image, and loading and mapping SUPs and non-SUPs.

[0013] Figure IB is a data flow diagram of one embodiment of a process for starting up an application.

[0014] Figure 2A and 2B illustrate a layout of traditional executable images and a layout of modified executable images, respectively.

[0015] Figure 3 is a data flow diagram of one embodiment of a process for profiling executable images and executing hybrid executable images. [0016] Figure 4 is a data flow diagram of one embodiment of a process for analyzing page fault information.

[0017] Figure 5 illustrates a storage system to store startup pages and non- startup pages.

[0018] Figure 6 is a data flow diagram of one embodiment of a process for loading a hybrid executable image.

[0019] Figure 7 is a data flow diagram of one embodiment of a process for determining a cut-off time.

[0020] Figure 8 illustrates another embodiment of a storage system to store startup pages and non-startup pages.

[0021] Figure 9 is a block diagram of one embodiment of a mobile device, and

[0022] Figure 10 is a block diagram of one embodiment of a computer system.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

[0023] An apparatus and associated methods for reducing application startup latency are described. In one embodiment, the apparatus described herein identifies virtual memory pages involved in the startup of an application, then stores, loads, and maps such pages differently from other pages of the executable image of the application. In one embodiment, startup pages are identified through a page fault logger and an offline analyzer. In one embodiment, the executable image of the application is transformed into a hybrid executable image, thereby separating startup pages from other pages. Startup pages and non-startup pages can be stored on different memory/storage devices and are loaded and mapped into the address space using different methods. In one embodiment, startup pages are stored in linearly addressable Flash memory in ready-to-execute form while non-startup pages are stored on a block storage device.

[0024] To reduce the startup latency of applications, and thereby contribute to the improvement of overall user experience, an embodiment of the invention distinguishes the part of the application that is involved in application startup, and treats it differently from the rest of the application to ensure a faster startup. In one embodiment, a virtual memory (VM) page based approach is used to identify and optimize the startup portion of applications. In this approach, VM page faults are first logged, and an offline analyzer identifies startup pages (SUP), i.e. pages that are used during application startup, based on this log. Executable images that separate SUPs and non-SUPs are then generated. These SUPs and non-SUPs may be stored on different devices and may be loaded and mapped into main memory using different methods.

[0025] In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention. [0026] Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0027] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0028] The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. [0029] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

[0030] A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.

Overview

[0031] One embodiment of the present invention extracts startup pages (SUP), which are memory pages that are used during the startup of an application, from the executable image of the application, and uses different methods to store, load and map

SUP and non-SUP pages.

[0032] Figure 1 is a data flow diagram of one embodiment of a process for extracting SUP pages and handling them differently than non-SUP pages. The process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.

[0033] Referring to Figure 1, the process begins by processing logic identifying pages that are used during the startup of the application from the executable image of an application (processing block 101). In one embodiment, a page fault logger is used to log page fault information and the information recorded in page fault log is then used by an offline analyzer to determine the set of pages used in application startup.

[0034] After identifying pages used during startup of an application, processing logic changes the layout of the executable image, so that SUPs are treated differently from non-SUPs (processing block 102). For purposes herein, the executable images with changed layout are referred to as hybrid executable images. In one embodiment, SUPs are laid-out in linear-addressable Flash memory for in-place execution, and non-SUPs are treated as usual file blocks. In another embodiment, while SUPs are stored on higher-speed, probably smaller capacity storage devide(s), non-SUPs are stored on slower-speed, possibly larger capacity storage device(s). [0035] When the changed executable image is executed at runtime, processing logic uses different methods to load and map SUPs and non-SUPs into the execution domain of the application (processing block 103). For example, in one embodiment, the mapping of XIP pages is different than the mapping of pages loaded from disk. [0036] In comparison, the traditional approach does not distinguish SUPs from non-SUPs, and it uses the same method to store, load and map all virtual memory pages of an executable image.

[0037] Figure IB is a data flow diagram of one embodiment of a process for starting up an application. The process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. [0038] Referring to Figure IB, the process begins by processing logic receiving a request to start an application on a mobile terminal (processing block 111). In one embodiment, the application has a first set of one or more pages (e.g., the SUP pages) of an executable image used when an application is initially started and a second set of one or more pages (e.g., the non-SUP pages) of the executable image stored in different logical devices in the mobile terminal used after the first set of one or more pages.

[0039] In one embodiment, the first set of pages is mapped into memory differently than the second set of pages. In one embodiment, the first set of pages is stored in linearly-addressable memory and the second set of pages are stored in a non- linearly addressable memory.

[0040] Processing logic subsequently loads only the first set of one or more pages (the SUP pages) initially in response to the request (processing block 112). In one embodiment, loading includes executing the first set of pages from the linearly- addressable memory as part of an in-place execution operation. [0041] Figures 2A and 2B illustrate the difference between the layouts of traditional executable images and that of our hybrid executable images. Figure 2 A illustrates the traditional executable images 201 and 202 have SUPs and non-SUPs on one logical device, logical device 211. In contrast, Figure 2B illustrates the hybrid executable images have SUPs 221 and 222 on logical device 231 and non-SUPs 223 and 224 on logical device 232. The purpose of such layout is for faster loading and mapping of SUPs, which results in faster application startup.

Profiling and Execution Process

[0042] Figure 3 is a data flow diagram of one embodiment of the profiling and execution processes. Both the processes can be separately repeated one or more times. The processes are performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. [0043] Referring to Figure 3, the profiling process begins with a page fault logger 301 recording page fault information 312 during profiling runs of the executable image 311 of an application. Using page fault information 312, an SUP analyzer 302 identifies SUPs based on recorded page fault information and the executable image of the program. SUP analyzer 302 outputs SUP information 313 indicative of the identified SUPs. A hybrid executable image generator 303 receives a traditional executable image and its SUP information and creates a hybrid executable image 314. A hybrid executable image can have its SUPs and non-SUPs separately stored.

[0044] After hybrid executable image 314 is generated, the execution process may be performed. The execution process involves a hybrid executable image loader 304 that can recognize hybrid executable images. Hybrid executable image loader 304 uses different methods to load and map SUPs and non-SUPs of hybrid executable image 314.

[0045] The following describes one embodiment of the page fault logger, the

SUP analyzer, the hybrid executable image generator, and the hybrid executable image loader.

Page Fault Logger [0046] During the profiling process, page fault logger 301 logs information about virtual memory (VM) pages that caused page faults. A page fault happens when the virtual memory page of an accessed instruction or a data is not currently in physical memory. Page fault logger 301 is invoked by the page fault handler of the operating system (OS) kernel. In one embodiment, for each page fault, page fault logger 301 logs the time when the fault happened, and the page (indicated by a number) that caused the fault. In one embodiment, page fault logger 301 runs for a certain amount of time, after which it stops logging page fault information; this is useful, for instance, in logging the startup page faults for initially loaded applications. In one embodiment, page fault logger 301 ignores faults caused by data pages that were not part of the static executable image.

[0047] Page fault logger 301 logs page fault events into a memory (e.g., a memory buffer). This information is passed to SUP analyzer 302 by one or more methods. For example, in one embodiment, the information is passed to SUP analyzer 302 by having page fault logger 301 shares the memory buffer with SUP analyzer 302. In another embodiment, the information is passed to SUP analyzer 302 by having page fault logger 301 write the log information periodically into a file. In yet another embodiment, the information is passed to SUP analyzer 302 by having page fault logger 301 sends log information periodically, through, for example, a network. SUP Analyzer

[0048] SUP analyzer 302 takes as input the page fault information created by page fault logger 301, as well as the executable image of the program, to identify SUPs within the executable image. Figure 4 is a data flow diagram of one embodiment of a process for analyzing page fault information. The processes are performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.

[0049] Referring to Figure 4, the process begins by processing logic in SUP analyzer 302 removing fault information for data pages (processing block 401), if page fault logger 301 also logged fault information for data pages. Then, processing logic in SUP analyzer 302 determines a cut-off determinator to determine a cutoff time (processing block 402). Page faults occurring at or before the cutoff time are considered to have happened during application startup, and those that occur thereafter are considered to have happened after startup and thus are discarded. [0050] In alternative embodiments, SUP analyzer 302 may identify SUP pages using an approach based on human intervention, or page fault rate based approaches measured based on a preselected time such as, for example, wall-clock time and/or CPU time.

[0051] After determining the cut-off determinator, processing logic in SUP analyzer 302 determines the unique SUP (processing block 403). In one embodiment, SUP analyzer 302 determines the unique SUP by extracting page numbers from remaining page fault log and removing duplicate page numbers. Note that other ways of determining the unique SUP are possible. A sample cutoff determinator is one that takes a configurable preset time (PT) as input, finds the last page fault (PF) that occurred before PT, and uses the timestamp of that PF as the cutoff time. [0052] Thereafter, processing logic in SUP analyzer 302 outputs the file block numbers for the SUP pages (processing block 404). The resulting page numbers are output to a buffer, a file, or a network connection.

A Hybrid Executable Image Generator

[0053] In one embodiment, hybrid executable image generator 303 uses the original executable image and the page numbers generated by SUP analyzer 302 to create hybrid executable image 314.

[0054] In one embodiment, hybrid executable image 314 is stored on two logical devices: a linearly addressable memory device (e.g., DRAM or NOR Flash) for

SUPs, and a block device for non-SUPs. In one embodiment, the block device is managed by a hosting file system (e.g., Cramfs), which is extended to understand hybrid executable images.

[0055] In one embodiment, hybrid executable image generator 303 first checks if the executable symbol has any un-resolved symbols. If the executable image has any unresolved symbols (e.g., accesses to shared libraries), the symbols are first resolved. Hybrid executable image generator 303 may resolve the symbols by statically linking in appropriate libraries. Hybrid executable image generator 303 then creates a page location table, which has a list of entries, one for each page in the original executable image. Each entry in the page location table has a flag field indicating whether the page is a SUP, and a field specifying the actual location of the page: for a SUP page, the location is the starting address of the page on the linearly addressable memory; for a non-SUP page, the location is the addresses, on the block device, of the blocks comprising the page.

[0056] The hosting file system is extended so that in its metadata for each file that it manages. The metadata includes a field indicating whether a file is a hybrid executable image is stored, and if true, the metadata also contains a pointer to the page location table generated by hybrid executable image generator 303 for the hybrid executable image 314.

[0057] Figure 5 illustrates a storage system to store startup pages and non- startup pages. Referring to Figure 5, memory block device 501 stores data blocks for non-SUPs, while linearly addressable memory device 504 stores SUP pages. Page location table 502 stores the locations of data blocks in memory block device 501 and locations of SUP pages in linearly addressable memory device 504. Meta data 503 for the files is also stored in the storage system.

A Hybrid Executable Image Loader

[0058] In one embodiment, the hosting operating system is also extended to include hybrid executable image loader 304 for the loading and mapping of hybrid executable images (into the address space of the run-time memory of the device). In one embodiment, hybrid executable image loader 304 is invoked by the operating system when a requested file is a hybrid executable image.

[0059] Figure 6 is a data flow diagram of one embodiment of a process for loading a hybrid executable image. The processes are performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the processing logic is part of hybrid executable image loader 304.

[0060] Referring to Figure 6, the process begins by processing logic receiving the entry for the page from the page location table (processing block 601). This occurs once hybrid executable image loader 304 receives the requested page address. Processing logic then checks whether the page is a SUP (processing block 602). If processing logic determines the page is a SUP, then processing logic directly returns the location of the page containing the block (processing block 603), otherwise, processing logic loads and maps the block(s) for the page from the block device (e.g., memory block device 501 of Figure 5) into a memory buffer and returns the address of the buffer (processing block 604).

Alternative Embodiments

[0061] In another embodiment, SUP analyzer 302 uses a cut-off determinator that determines the cutoff time based on decreases in page fault rate, instead of a time- based cut-off determinator.

[0062] Figure 7 is a data flow diagram of one embodiment of a process for determining a cut-off time. The processes are performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. [0063] The cut-off determinator takes in following configurable parameters:

- N - The timeline of page fault profiling is equally divided into N units.

- Nmin - The earliest time unit that can be considered as cutoff time.

- Nmax - The latest time unit that can be considered as cutoff time. maxN >= minN.

- Nw - The number of time units in the sliding time- window.

- R - A real number in the range of [0, 1]. It is the threshold rate of decrease in page fault rate.

[0064] Referring to Figure 7, the process of determining the cut-off time begins with processing logic dividing a profiling timeline into N units (processing block 701). Processing logic then determines whether (Nmax + Nw) is greater than N (processing block 702). If so, processing logic sets Nmax equal to N - Nw + 1 (processing block 703) and the process transitions to processing block 704. If not, the process transitions directly to processing block 704.

[0065] At processing block 704, processing logic initialize I to Nmin.

Processing logic determines whether I >= Nmax (processing block 705). If so, the process transitions to processing block 708 where processing logic returns the start time of I-th unit as the cut-off time and the process ends. If not, processing logic assigns a variable Fl equal to the average number of page faults per unit for units before the I-th unit, which the processing logic calculates (processing block 706) and assigns a variable F2 equal to the average number of page faults per unit for units in the time window that starts at I-th unit and has a length of Nw, which the processing logic calculates (processing block 707). Processing logic then determines if (F2 / Fl) < R (processing block 709). If so, the process transitions to processing block 708. If not, processing logic increment I by 1 (processing block 710) and the process transitions back to processing block 705.

[0066] In another alternative embodiment, the hybrid executable image generator uses block devices as the logical devices storing the SUP and non-SUP pages. In one embodiment, two block devices are the same device. In such an arrangement, the first logical device stores SUP pages in uncompressed form, while the second logical device stores non-SUP pages in compressed form. Each entry in the page location table still has a field indicating whether a page is SUP or non-SUP. The location field of a SUP entry lists the block(s) that comprise the page, while the location field of a non-SUP entry has three sub-fields: the number of the start block of the page, the offset in the start block, and the length of the compressed page. The hybrid executable image loader handles SUP pages differently than described above. In this embodiment, for SUP pages, the hybrid executable image loader uses usual load and map methods for block devices, while for non-SUP pages, it first loads and uncompress' the blocks into memory before mapping it into proper address space. [0067] In another alternative embodiment, instead of having the SUP pages in the same or same type of memory as the non-SUP pages, the device for SUP pages is a linearly addressable memory device, and that the location field of a SUP entry in the page location table is the starting address of the page on the linearly addressable memory.

[0068] In another alternative embodiment, the first logical device storing the

SUP pages represents a linearly addressable memory device or a block device and the second logical device storing the non-SUP pages represents a remote storage device. Figure 8 illustrates such an embodiment. Referring to Figure 8, memory device 801 stores local data blocks for SUP pages. The entry for the hybrid executable image in the file system metadata 810 has a field indicating the location of remote storage device 802 that stores data blocks for norϊ-SUP pages. In one embodiment, the value of the field is an array of bytes that can be interpreted as IP address plus port number or some implementation specific address encoding. Each entry in page location table 803 still has a field indicating whether a page is SUP or non-SUP. The location field of a SUP entry lists either the block(s) comprising the page, or the address of the page on a linearly addressable memory device. The location field of a non-SUP entry lists the block numbers (on the remote storage device) of the blocks that comprise the page and are stored on the remote storage device. In this embodiment, the hybrid executable image loader handles non-SUP pages by first sending a request to remote storage device 802 for the blocks comprising the page. The blocks returned may need to be uncompressed first, then loaded into memory and mapped into address space.

An Example of a Mobile Terminal

[0069] Figure 9 is a block diagram of one embodiment of a cellular phone that includes a transmitter and/or the receiver and using the techniques described above when performing application startup. Referring to Figure 9, the cellular phone 910 includes an antenna 911, a radio-frequency transceiver (an RF unit) 912, a modem

913, a signal processing unit 914, a control unit 915, an external interface unit

(external FF) 916, a speaker (SP) 917, a microphone (MIC) 918, a display unit 919, an operation unit 920 and a memory 921.

[0070] In one embodiment, the external terminal 916 includes an external interface (external I/F), a CPU (Central Processing Unit), a display unit, a keyboard, a memory, a hard disk and a CD-ROM drive.

[0071] The CPU in cooperation with the memories of cellular phone 910 (e.g., memory 921, memory, and hard disk of the external I/F 916) cooperate to perform the operations described above. In one embodiment, these memories include a linearly addressable memory to store SUPs and a non-linearly addressable memory to store non-SUPs.

[0072] Note that the transmitter and/or receiver may be included in a base station or other wireless devices (e.g., a wireless LAN). [0073] The external I/F can be connected to a notebook, laptop, desktop or other computer. This can enable the cell phone to act as a wireless modem for the computer. The cell phone can be the computer's connection to the internet, WiFi and WiMAX, a local area network, a wide area network, a personal area network, Bluetooth.

An Example of a Computer System

[0074] Figure 10 is a block diagram of an exemplary computer system that may perform one or more of the operations described herein. Referring to Figure 10, computer system 1000 may comprise an exemplary client or server computer system. Computer system 1000 comprises a communication mechanism or bus 1011 for communicating information, and a processor 1012 coupled with bus 1011 for processing information. Processor 1012 includes a microprocessor, but is not limited to a microprocessor, such as, for example, Pentium™, PowerPC™, Alpha™, etc. [0075] System 1000 further comprises a random access memory (RAM), or other dynamic storage device 1004 (referred to as main memory) coupled to bus 1011 for storing information and instructions to be executed by processor 1012. Main memory 1004 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 1012. [0076] Computer system 1000 also comprises a read only memory (ROM) and/or other static storage device 1006 coupled to bus 1011 for storing static information and instructions for processor 1012, and a data storage device 1007, such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 1007 is coupled to bus 1011 for storing information and instructions. [0077] Computer system 1000 may further be coupled to a display device

1021, such as a cathode ray tube (CRT) or liquid crystal display (LCD), coupled to bus 1011 for displaying information to a computer user. An alphanumeric input device

1022, including alphanumeric and other keys, may also be coupled to bus 1011 for communicating information and command selections to processor 1012. An additional user input device is cursor control 1023, such as a mouse, trackball, trackpad, stylus, or cursor direction keys, coupled to bus 1011 for communicating direction information and command selections to processor 1012, and for controlling cursor movement on display 1021.

[0078] Another device that may be coupled to bus 1011 is hard copy device

1024, which may be used for marking information on a medium such as paper, film, or similar types of media. Another device that may be coupled to bus 1011 is a wired/wireless communication capability 1025 to communication to a phone or handheld palm device.

[0079] Note that any or all of the components of system 1000 and associated hardware may be used in the present invention. However, it can be appreciated that other configurations of the computer system may include some or all of the devices. [0080] Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.

Claims

CLAIMSWe claim:

1. A method comprising: receiving a request to start an application on a mobile terminal, the application having a first set of one or more pages of an executable image used when an application is initially started and a second set of one or more pages of the executable image stored in different logical devices in the mobile terminal used after the first set of one or more pages; and loading only the first set of one or more pages initially in response to the request.

z. An article of manufacture having one or more computer readable medium storing instructions thereon which, when executed by a system, cause the system to perform a method comprising: receiving a request to start an application on a mobile terminal, the application having a first set of one or more pages of executable images used when an application is initially started and a second set of one or more pages of executable images stored in different logical devices in the mobile terminal used after the first set of one or more pages; and loading only the first set of one or more pages initially in response to the request.

3. A method comprising: changing a layout of an executable image of an application; and in response to changing the layout of the executable image of the application, causing a first set of pages from the executable image of the application that are used when an application is started to be handled differently than a second set of pages from the executable image that are not used when the application is started.

4. An article of manufacture having one or more computer readable medium storing instructions thereon which, when executed by a system, cause the system to perform a method comprising: changing a layout of an executable image of an application; and in response to changing the layout of the executable image of the application, causing a first set of pages from the executable image of the application that are used when an application is started to be handled differently than a second set of pages from the executable image that are not used when the application is started.

5. A method for identifying pages used for application startup, the method comprising: logging page fault information for pages of an application having one or more original executable images; analyzing the page fault information to determine which executable images are displayed when the application is starting; generating startup page information; and generating a set of one or more new executable images to be displayed based on the startup page information and the one or more original executable images.

6. An apparatus for identifying pages used for application startup, the apparatus comprising: a page fault logger module to log page fault information for pages of an application having one or more original executable images; an analyzer module to analyze the page fault information to determine which executable images are displayed when the application is starting and to generate startup page information; and an executable image generator to generate a set of one or more new executable images to be displayed based on the startup page information and the one or more original executable images.