WO1996037846A1

WO1996037846A1 - Virtual memory management system with adaptive knowledge base

Info

Publication number: WO1996037846A1
Application number: PCT/US1996/007384
Authority: WO
Inventors: Wendell D. Brown; Rainer Poertner
Original assignee: Syncronys Softcorp
Priority date: 1995-05-22
Filing date: 1996-05-22
Publication date: 1996-11-28
Also published as: AU5924796A

Abstract

The present invention provides methods and apparatus for optimizing the size and speed of a volatile memory. In a preferred embodiment, the optimization is achieved through two interrelated componts, a compression driver and a knowledge base. The compression driver provides real time compression of a volatile memory while the knowledge base stores information related to the frequency of access of particular data and the optimal compression algorithm for that data. The information stored in the knowledge base may be used either to compress certain data according to a preferred algorithm or to determine whether that data should be stored in a hard disk or other memory that is slower than the volatile memory. Foe each page of an application program, the knowledge base stores the predicted or actual compression ratio of the page, the best compression algorithm to use for that page, the frequency that the page has been accessed, and, for pages with a very high compression ratio, the actual compression data. The knowledge base may be stored in a non-volatile memory and updated over time, thus increasing the statistical sample for the information stored in the knowledge base.

Description

VIRTUAL MEMORY MANAGEMENT SYSTEM WITH ADAPTIVE

KNOWLEDGE BASE

BACKGROUND OF THE INVENTION

1. Field of the Invention The present invention relates to apparatus and methods for managing data storage, and more particularly, to virtual memory management and data compression for computer memories including volatile computer memories.

2. Art Background

Computer hardware and software have evolved as computers have become increasingly important to both businesses and individuals. Software now includes programs that perform a wide variety of tasks and use ever increasingly sophisticated graphics and sound techniques for "multimedia" presentations. The sophistication of software requires a large amount of memory, such that multimedia programs are frequently stored on CD ROM and many commercial data compressors allow compression of hard disks and other storage devices. Neither prior art disk compressors nor increasing hardware sophistication, however, has allowed relatively large programs to run quickly, particularly when these programs are multitasked.

The problem during run time has been the unavailability of random access memory (RAM) that can accommodate one or more large programs. When a program exceeds the capacity of a RAM memory, many operating systems store part of the program in a hard drive. This technique is known as "virtual memory," and typically through a cache the operating system provides this stored program to RAM as it becomes needed. In turn, such operating systems must cache part of the program currently in the RAM to the hard disk. Transferring data back and forth between RAM and a hard drive greatly slows the operation of a program.

To avoid this difficulty, a user may add RAM memory to a computer. A computer's hardware and operating system must be configured to accommodate the additional RAM, which entails expenses in both the cost of the changes and the down time of the computer while the changes are being made. As will be described, the present invention provides a relatively inexpensive software alternative to purchasing additional RAM by efficiently compressing RAM memory.

SUMMARY OF THE INVENTION The present invention provides methods and apparatus for optimizing the size and speed of a volatile memory in a computer system. In a preferred embodiment, the computer system includes a central processing unit (CPU) coupled to a volatile memory, which may comprise a random access memory (RAM) and further coupled to a non¬ volatile memory, which may comprise a hard disk drive. In a preferred embodiment, the optimization of the RAM is achieved through two interrelated components, a compression driver and a knowledge base, although each of these components may be present without the other. The compression driver provides real time compression of a volatile memory while the knowledge base stores information related to the frequency of access of particular data and the optimal compression algorithm for that data. The information stored in the knowledge base may be used either to compress certain data according to a preferred algorithm, or to determine whether that data should be stored in a hard disk or other memory that is slower than the volatile memory.

The compression driver of the present invention organizes the volatile memory into a plurality of distinct regions. One region is reserved for code for the operating system while another region is reserved for compressed application program data. Since the application program data is stored in compressed form, the effective size of the volatile memory is increased. The volatile memory may further have a buffer that stores data to be compressed and written to the compressed region and also a buffer that stores compressed data that must be decompressed. If the precompression and predecompression are either full or not implemented, the compression driver compresses data to be written into the volatile memory in real time and decompresses data to be read from the volatile memory in real time.

The present invention includes a knowledge base to optimize system performance by customizing the compression driver to a particular application program. As previously described, the knowledge base of the present invention is useful for both data compression and virtual memory management either alone or in combination. For each page of an application program, the knowledge base stores the predicted or actual compression ratio of the page, the best compression algorithm to use for that page, the frequency that the page has been accessed, and, for pages with a very high compression ratio, the actual compression data. The knowledge base may be stored in a non-volatile memory and updated over time, thus increasing the statistical sample for the information stored in the knowledge base.

Accordingly, the present invention provides for the compression of a volatile memory, thereby increasing its size without significantly increasing processing time. The present invention further provides a knowledge base that facilitates memory management and decreases processing time either alone or in combination with the compression driver.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects features and advantages of the present invention will be apparent from the following detailed description of the preferred embodiment of the invention with references to the drawings in which:

Figure 1 is a functional block diagram illustrating one possible computer system incorporating the teachings of the present invention.

Figure 2 is a block diagram illustrating the architecture of the preferred embodiment of the present invention.

Figure 3 is random access memory (RAM) configured according to the teachings of the present invention.

Figure 4 illustrates tables that track the location of data in the RAM of Figure 3.

Figure 5 is a flow chart illustrating the steps for initializing the system of the present invention upon system start up.

Figure 6 is a flow chart illustrating the steps for writing data to memory according to the teachings of the present invention.

Figure 7 is a flow chart illustrating the steps for reading data from memory according to the teachings of the present invention.

Figure 8 illustrates a table for storing the knowledge base of the present invention.

Figure 9 is a flow chart illustrating the steps for installing the present invention on a computer system. NOTATION AND NOMENCLATURE

•The detailed descriptions which follow are presented largely in terms of display images, algorithms, and symbolic representations of operations of 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. These 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 proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, images, terms, numbers, or the like. 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.

In the present case, the operations are machine operations performed in conjunction with a human operator. Useful machines for performing the operations of the present invention include general purpose digital computers or other similar devices. In all cases, there should be borne in mind the distinction between the method operations of operating a computer and the method of computation itself. The present invention relates to method steps for operating a computer and processing electrical or other physical signals to generate other desired physical signals.

The present invention also relates to apparatus for performing these operations. 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. The algorithms, methods and apparatus presented herein are not inherently related to any particular computer. In particular, various general purpose machines may be used with programs in accordance with the teachings herein, or it may prove more convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given below.

DETAILED DESCRIPTION OF THE INVENTION

The present invention discloses apparatus and methods for compressing a computer memory. In the following description, numerous specific details are set forth such as the

Microsoft^® operating system, Windows^® programs and Intel^® based family of central processing units in order to provide a through understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well known circuits, structures and the like are not described in detail so as not to obscure the present invention unnecessarily.

System Hardware Referring to Figure 1 , the hardware configuration of the present invention is conceptually shown. As illustrated, the present invention's data management system includes a computer 20 which comprises four major components. The first of these is an input/output (I/O) circuit 22, which is used to communicate information in appropriately structured form to and from other portions of the computer 20. In addition, computer 20 includes a central processing unit (CPU) 24 coupled to the I/O circuit 22 and to a random access memory (RAM) 26. A hard disk 32 is also coupled to the I/O circuit 22. These elements are those typically found in most computers and, in fact, computer 20 is intended to be representative of a broad category of data processing devices. Indeed, it will be appreciated that the present invention may be used in conjunction with a plurality of RAM memories and other types of storage devices within a single computer system or over any type of computer network.

Also shown in Figure I is a keyboard 30 for inputting data and commands into computer 20 through the I/O circuit 22, as is well known. Similarly, a CD ROM 34 is coupled to the I/O circuit 22 for providing additional programming capacity to the system illustrated in Figure 1. It will be appreciated that additional devices may be coupled to the computer 20 for storing data, such as magnetic tape drives, buffer memory devices, and the like. A device control 36 is coupled to both the memory 26 and the I/O circuit 22, to permit the computer 20 to communicate with multi-media system resources. The device control 36 controls operation of the multi-media resources to interface the multi-media resources to the computer 20.

A display monitor 43 is coupled to the computer 20 through the I/O circuit 22. A cursor control device 45 includes switches^' 47 and 49 for signalling the CPU 24 and the cursor control device 45 (commonly referred to as a "mouse") permits a user to select various command modes, modify graphic data, and input other data utilizing switches 47 and 49. More particularly, the cursor control device 45 permits a user to selectively position a cursor 39 at any desired location on a display screen 37 of the display 43. It will be appreciated that the cursor control device 45 and the keyboard 30 are examples of a variety of input devices which may be utilized in accordance with the teachings of the present invention. Other input devices, including for example, trackballs, touch screens, data gloves or other virtual reality devices may also be used in conjunction with the invention as disclosed herein.

Data Management System

Figure 2 illustrates the preferred embodiment of the architecture of the present invention. A computer operating system 52 controls the operation of applications software 50. The computer operating system 52 interfaces with a virtual memory manager 54 that controls the division of storage between the RAM 26 and the hard disk 32. In the ' preferred embodiment, the present invention is implemented with the novel virtual memory manager of the present invention but other virtual memory managers may be used.

Unlike prior art memory management systems, according to the present invention, a compression/decompression driver 56, resident in the RAM 26 and operatively coupled to the CPU 24, interfaces the virtual memory manager 54 with the RAM 26 and the hard disk 32. The compression/decompression driver 56 compresses data provided by the applications software 50 and stores the compressed data in the RAM 26. Also, when a compressed area of the RAM 26 needs to be read, the compression/decompression driver decompresses the appropriate area of the RAM 26. If the RAM 26 does not have sufficient capacity to store further data, then the compression/decompression driver 32 stores uncompressed data to the hard drive 32. In an alternate embodiment, the compression/decompression driver 32 may write compressed data to the hard drive 32.

• Figure 3 illustrates the RAM 26 configured according to the driver 56. The RAM 26 is divided into two major blocks, 74 and 76, where block 74 comprises Windows^® code and block 76 is dedicated to the driver 56. Block 74 comprises a block 62, that includes the minimum necessary amount of RAM memory to boot Windows^®, typically 1 megabyte, and a block 64, that includes a sufficient amount of memory to allow Windows^® to operate.

Block 76 is governed by the driver 56. In a preferred embodiment, block 76 comprises a predecompression buffer 66, a precompression buffer 68, compressed memory 70 and a scratch pad memory 72 for variables stored by the driver 56. As will be described more fully below, the precompression buffer 68 contains data provided by the memory manager 54 that is to be resident in the RAM 26. The driver 56 compresses data stored in the buffer 68 and stores the compressed data in a compressed memory block 70. However, if no space is available in the block 68, the driver 56 may compress the data in real time and store it directly in the compressed block 70. The predecompression buffer 66 contains decompressed data previously resident within the block 70. It will be appreciated that the present invention may be employed without the predecompression buffer 66 or the precompression buffer 68.

In the preferred embodiment, the precompression buffer 68 comprises a plurality of 4K page buffers and the actual number of these buffers is updated according to the apparent need for such buffers. Data that the virtual memory manager 54 provided to the driver 56 is initially written to one of these buffers, if any are available, and control is immediate passed back to the operating system 52. Subsequently, a background process compresses these buffers and stores the compressed data in the RAM 26, freeing the previously occupied space in the precompression buffer 68.

When the precompression buffer 68 does not contain sufficient memory space, incoming data from the memory manager 54 is compressed in real time, which results in a slight delay in the operation of whatever applications program is being run. In the preferred embodiment, the predecompression buffer 66 comprises a plurality of 4K page buffers and the actual number of these buffers is updated according to the apparent need for such buffers. A background process decompresses data from the compressed area 70 and transfers the data to the predecompression buffer 66 when the process predicts that such data may soon be requested by the virtual memory manager 54.

The data is deposited in the predecompression buffer 66 and then decompressed. However, if the requested data was not previously predicted to be decompressed and therefore not decompressed by the background process, or data is being requested faster than the background process can decompress the data, the driver 56 must decompress data from the compressed area 74 in real time, causing a delay in processing.

The sizes of the predecompression buffer 66 and precompression buffer 68 may be adjusted according to the apparent need for such buffers by a buffer size manager. Incoming compression and decompression requests may be placed on a queue and the buffer size manager may adjust the buffers based upon the information in the queue.

In the preferred embodiment, the majority of the RAM 26 comprises the compressed area 70. Figure 4 illustrates the configuration of the compressed area 26. The driver 56 manages the compressed area 70 by maintaining two linked lists, 78 and 80, as illustrated in Figure 4 that are stored in the RAM 26. The linked list 78 tracks the occupied areas of the compressed area 70 while the linked list 80 tracks the unoccupied areas of the compressed area 70. Each of the linked lists 78 and 80 comprises two further lists, 82 and 84 for linked list 78 and 86 and 88 for linked list 80. The lists 84 and 86 contain an address, an offset from the base of the area 70, of used or unused memory and the lists 82 and 88 contain the length of the used or unused area.

The list 78 is stored linearly and not sorted. Conversely, the list 80 is continuously sorted in the order of the smallest freespace length to the largest freespace length. To minimize waste, incoming data is stored in a free area that contains the least amount of space that will accommodate all of the data and this free area is quickly found by the CPU 24 by scanning the sorted list 80. Since some memory gaps may be too small to be utilized, a background procedure reorganizes the area 70 to eliminate gaps between used and unused memory, maximizing unused space that may be written to. The system also maintains a page table in the RAM 26 that stores information for every page that is accessed during a session. The page table indicates the memory, RAM 26 or drive 32, that stores the page and the location of the page within that memory. The table also indicates whether the page is currently stored in compressed form, and, if so, what compression algorithm was used to compress the page.

Figure 5 is a flow chart of the initialization procedure for the driver 56 when the operating system 52 is booted. At block 100, the CPU 24 running the procedure determines whether the hardware or software configuration of the system has been changed by examining a validation key, as will be described more fully below. If the validation key does not match, the procedure branches to block 104 and the user is prompted to reconfigure the system. Otherwise, the system branches to block 102, where it is determined whether the driver 56 is enabled. If the driver 56 is not enabled, then the procedure exits. Otherwise, the procedure branches to block 106, where the system determines whether the compression/delay feature of the present invention, which will be described more fully below, is enabled. If this feature is not enabled, the procedure branches to block 112.

If this feature is enabled, control passes to block 108. At block 108, the system waits until the RAM 26 is filled to a predefined percentage or until windows shuts down. If windows shuts down without the RAM 26 being filled to the predefined percentage, then the driver 56 is never installed. Conversely, if the RAM 26 is filled to the predefined percentage, then the driver 56 is installed. The compression/delay feature thus allows the system to avoid using CPU time performing compression related tasks unless and until compression becomes necessary, as indicated when the RAM 26 is filled to a certain percentage. If the RAM 26 is filled to the predefined percentage, control passes to block 110 where the current contents of the RAM 26 are compressed.

At block 112, where control passes after block 110 and block 106, that portion of the driver 56 that performs real time compression is installed. Control then passes to block 114 where the part of the driver that performs background tasks is installed, as will be described more fully below. The memory management scheme of the present invention must interface with the virtual memory manager 54, which may not have been designed with regard to the driver 56 of the present invention. Thus, the driver 56 must intercept calls from the memory manager- 54 to read/write routines and pass back information to the memory manager 54 such that the driver 54 is transparent to the virtual memory manager 54.

There are at least three methods for interfacing the memory manager 54 with the driver 56 when the memory manager 54 is a Microsoft Windows^® memory manager. According to a first method, a Windows^® Virtual Device Driver may be installed and the Windows^® Virtual Memory Management routines mapped either in part or in total to the driver 56. According to a second method, a DOS logical disk drive is created and

Windows^® is then configured to direct all hard disk drive page-swapping activities through this new logical drive. The new logical drive is actually the driver 56 and not a physical disk drive and calls to the logical drive are actually calls to the driver 56. To avoid user confusion, the logical drive, which may be created and destroyed at will, may be hidden from a user. Finally, the memory manager 54 may be tailored to the driver 56 and the

Windows^® memory management software bypassed and replaced by the driver 56. In this case, the driver 56 is installed as a device in the Windows^® SYSTEM.INI file.

The presently preferred embodiment uses the third method of bypassing and replacing the Windows^® memory management software. The driver 26 is interfaced to the Windows^® operating system by replacing two primary Windows^® internal operating system VxD's. Before the driver 26 is installed, two device driver statements in the [386enn] section of the Windows^® SYSTEM.INI file point directly to each of two Windows^® internal VxD (virtual device driver) routines called PageSwap and PageFile. The "*" in the device statements in Windows^® means that the routines are embedded inside of Windows^® KERNAL.EXE file (which contains many separate Windows^® code modules).

The two device driver statements are then replaced with a direct pointer to two new VxD drivers for the driver 26 (note: VxD drivers have the file extension of 386). After the driver 26 is installed, the device driver statements then point directly to the two new drivers that point to the driver 26. One of the new drivers is a PageSwap driver and the other a PageFile. The new driver device names are then inserted into the [386enn] section of the Windows^® SYSTEM.INI file and the previous device names (i.e. *PageSwap and *PageFile) lines are removed from the SYSTEM.INI file. The diagrams show the device drivers pointed to by the Windows^® operating system. The arrows represent a Windows^® internal pointer or VxD device driver references. The following is a list of sample settings in the SYSTEM.INI file:

Setting Explanation

[386Enh] device=softram 1.386 compression driver device=softram2.386 compression driver

SoftRam= 1 compression driver enabled

SoftRamSize=8000 compression driver has created 8000KB of RAM

SoftRamMaxPhys=4000 compression driver allocated 4000KB physical RAM for its own use SoftRamMinOper= 1500 compression driver allocated 1500KB physical RAM for

Windows^® SoftRamExtended=8192 compression driver detected 8192KB of physical RAM

SoftRamSpeed = 1 compression driver is set to Maximum SoftRAM

By inserting the two device drivers into the SYSTEM.INI file, whenever a Windows^® PageFault occurs, the CPU's standard pagefault mechanism will thus jump first to driver 26's pagefault handler. The driver 26 then determines if that faulting Page's linear address was caused by a non-present (compressed) page, or if it was caused by a Windows^® Virtual Memory page (and thus will required accessing an external hard disk). The driver 26 then passes control directly to the original *PageSwap and the *PageFile routines within the Windows^® KERNAL.EXE Code routines.

If the driver 26 determines that the faulting Page was a compressed page, then driver 26 processes the pagefault request. Otherwise, the driver 26 then jumps to the pagefault handler within the standard *PageSwap and the *PageFile routines within the Windows^® KERNAL.EXE code routines. The technique of adding new pageswap and pagefile routines thus allows the driver 26 to use and process (i.e. compress and decompress, etc.) a pre-set range of the CPU's linear address space. A portion of the CPU's linear address space is reserved upon the initialization of Windows^® by code within the new pageswap file. The amount of linear RAM space reserved for driver 26 upon the booting of Windows^® is equal to the maximum amount of "doubled" RAM requested by the user. Thus, the driver 26 has direct, high-speed access to Windows^® internal routines which allows the driver 26 access to both linear and physical memory under Windows^®' control, and yet does not interfere with Windows^® normal processing tasks as an operating system.

Returning to the first two methods for interfacing the driver 26 with Windows^®, for either of these methods, when the operating system 52 writes to write to the RAM 26, it calls the virtual memory manager 54 whose input/output calls are redirected to the driver 56. If the first method is used, each attempted write causes a page fault and the page fault handling routine calls the driver 56. If the second method is used, a logical device drive handler routes the calls to the logical device, caused by write requests, to the driver 56.

Regardless of the type of interface between the driver 26 and Windows^®, the driver 56 writes the data to the RAM 26 or the hard disk 32 by performing the steps shown in the flow chart of Figure 6. At block 116, the routine determines whether there is available space in the precompression buffer 68, as previously described. If so, then the data is written to the precompression buffer 68 as illustrated in block 120 and compressed by a background task. The pointer of this incoming page is placed into a page pointer within the precompression buffer 26 and the buffer wkhin the precompression buffer 68 is marked as being in use. The routine then exits.

If there was insufficient space within the precompression buffer 68, then block 116 branches to block 118 where the routine determines whether there is sufficient space in the compressed area 70. If so, then the page is compressed in real time and written to the compressed area 70 as indicated in block 122. The routine then exits. Finally, if there was insufficient room in the compressed area 70, then the page must be written to the hard disk 32 as illustrated in block 124 where control passes from block 118. As previously described, in an alternate embodiment, before writing to me hard disk, the data may be compressed. The routine then exits.

•To compress a page, a database is first checked to determine whether there is an optimal compression algorithm for compressing that page. The database will be described more fully below. The optimal compression algorithm may comprise any prior art compression algorithm including modified Huffman compression or any Lempel-Ziv compression algorithms. The preferred algorithms for the present invention will be discussed below. If there is no entry in the database, then the page is compressed by the default algorithm, which, in the preferred embodiment, is run length encoding, which is well known in the art. After the page is compressed, the entry in the page table corresponding to the compressed page is updated to reflect the compression algorithm that was used to compress the page.

Reading data is the inverse of writing data. If the first method for interfacing the driver 56 with the memory manager 54 is used, then Windows^® is configured such that every read request causes a page fault, causing control to pass to the driver 56. If the second method is used, then a logical device drive handler routes the calls to the logical device, caused by read requests, to the driver 56.

The driver 56 then writes the data to the RAM 26 or the hard disk 32 by performing the steps shown in the flow chart of Figure 7. At block 130, the routine examines the page table to determine the location of the page. If the page is within the predecompression buffer 66, then control passes to block 132 and a pointer to the area within the predecompression buffer 66 is passed back to windows. If the page is resident within the compressed area 70, then control passes to block 134 where the data is decompressed in real time. To avoid decompressing this data a second time, the decompressed data may be stored in buffer. Finally, if the page resides on the hard drive

32, then control passes to block 136 where the page is read from the hard disk and then decompressed as illustrated in block 138. Compression Algorithms The presently preferred embodiment employs two rapid compression/decompression algorithms, Crunch Algorithm #1 and Crunch Algorithm #2, for real^* time data compression and decompression both to and from the RAM 26. During the compression stage, both algorithms compress the same input and the data compressed by the algorithm that produces the greatest compression ratio is then stored. The "winning" algorithm is also stored in the knowledge base, as will be described more fully below, such that future compressions of the page may be compressed according to the winning algorithm without performing the other algorithm.

Crunch Algorithm #1

This algorithm is a simple type of run length encoding limited to only one cycle of repeat where the repeat count is always 4K bytes. If the entire 4K byte page contains the same repeated 16 bit word repeated throughout the entire 4K byte page, the 16 bit word is stored. For 80x86 Intel^® based machines, to determine whether the entire 4K byte page contains the same repeated word repeated throughout the entire 4K byte page, the REP

(repeat) assembly command for wide-word string comparisons may be utilized.

To perform the comparison using the REP command, the first word of the 4K block is compared to all of the other words. If a not-equal compare occurs, then the attempt to compress the block according to Crunch Algorithm #1 is aborted. Otherwise, the next word is then compared to the remaining words and the process repeated until the compression attempt is aborted or all of the words have been compared with one another. If the words are identical, the value of the words is stored into a location specified in the page table. The "repeat count" is known and is fixed to always be the size of the pages, which is 4K in the preferred embodiment.

To decompress data compressed according to Crunch Algorithm #1, the decompressor determines that the stored data was compressed according to this algorithm and then substitutes the value of the stored word for each word in the 4K block. Crunch Algorithm #2 This algorithm is a variant of the well known Lempel-Ziv 1977 (LZ77) algorithm. The Crunch Algorithm #2 is a modified look-back index & repeat count Lempel-Ziv style algorithm optimized for the Intel^® 808x instruction set. The Crunch Algorithm #2 is closest to a variant of LZ77 sometimes referred to as LZRW. The Crunch Algorithm #2 and LZRW differ primarily in the optimizations for the microprocessor instruction set and the bit-length of the control word. This algorithm compresses only 4K byte length input data streams only (which equals the fixed-size 4K byte Page-swap size of the Intel^® x86 architecture).

As in other variants of the LZ77 algorithm, hashing or another search method such as a linkless tree structure is used to find repeated data. The Crunch #2 algorithm uses a fixed page-size, 4K bytes, and has optimizations to match the instruction set of common multi-word length microprocessors (i e. that have 8-bit byte, 16-bit word, and 32-bit long word instructions). The Crunch Algorithm #2 processes data in 4K byte blocks and the processing of each block is independent of other blocks. The algorithm does a single pass during compression, and a single pass during decompression.

The Crunch Algorithm #2 outputs a series of groups where each group comprises a 32-bit control word followed by 32 items except that a last group accommodates for the end condition of a group with possibly less than 32 items within a group. Each item represents either literal data, an 8 bit ASCII value, or represents a repeated data string

(range from a size of 3 to 18 bytes long). The 32-bit control word contains a bit for each item indicating whether the corresponding item is a literal or represents a repeated string, where a 0-bit indicates a literal item, and a 1-bit indicates a repeated string.

Items that represent repeated values are stored as 16 bits. Four of these bits represent the repeat count while the remaining 12 bits are a relative address into the page where the repeated data, which is to be substituted for the repeat item, is stored.

A hash-function is used to attempt to quickly find possible repeated data blocks, ranging in size from 3 to 18 bytes in length, in any part of the current 4K data block already processed. The bytes are first compared using 32-bit word compares, then when a 32-bit word no longer matches, 8-bit compares are used to resolve the byte with the word where the two strings no longer match.

Background Processes

As previously described with reference to block 114 of Figure 5, the system installs background processes upon system initialization. Separate background processes compress the precompression buffer, transfers and decompresses compressed data from the compressed area to the predecompression buffer, accumulates information for the knowledge base, transfers pages from the hard drive 32 to the RAM 26, transfers pages from the RAM 26 to the hard drive 32, removes duplicate pages from the RAM 26 and removes gaps within the compressed area. These processes are controlled by anodier background "Taskmaster" process which is spawned when Windows^® is booted. The background processes will now be discussed in turn.

Taskmaster process The "Taskmaster" process coordinates all of the other background process and calls these processes according to their respective priorities. This task also identifies pages within the compressed area that may be written to the hard drive 32. In addition, this task identifies and predicts pages within the compressed area to transfer to the predecompression buffer.

Precompress process As previously described, this process monitors the precompression buffer and compresses pages within the precompression buffer and transfers the pages to the compressed area. This process may examine the knowledge base to determine the optimal algorithm for a particular page.

Predecompress process This process decompresses data within the predecompression buffer, as previously described. Improve Knowledge Base This process continuously scans the RAM 26 to update the knowledge base. This procedure analyzes pages of frequently run applications programs to generate information regarding the optimal compression algorithm for each page. Different compression algorithms trade off compression ratio versus speed of compression and the optimal algorithm may most closely match user selected goals of speed and compression ratio. Alternatively, the system may have default goals.

Fetch Page from Drive This process retrieves pages from the hard disk that the Taskmaster Drive indicates may be required by an application program. To minimize conflict with a user, this task monitors the hard disk's recent activity, the keyboard, and the mouse to estimate the current amount of user anticipated hard disk accesses within a short period such as 0- 500 ms. If the process predicts a user hard disk access within this time, it waits until after the user's access to access the hard drive.

Put Page to Drive

This process is virtually identical to the Fetch Page process except that this process writes those pages to the hard disk that the Taskmaster process indicates are not likely to be used for a long period.

Remove Duplicate Pages This procedure continuously scans the compressed area to remove duplicate pages.

A page that is found to duplicate another page is deallocated from its memory space and a bit in the page table entry for the duplicate page is set to indicate that the entry is a "shared page." Thus, two entries in the page table will point to the same address. If this page needs to be written to, it is first duplicated and a separate entry in the page table generated to avoid incorrectly writing to two pages when only one page is altered.

Eliminate Gaps in Ram As previously described, this process removes gaps within the compressed area. This process examines the freespace list for gaps and then moves data to minimize the gaps and updates all necessary tables to reflect the movement. This task is generally at a very low priority except that its priority increases when the amount of available space in the compressed area falls to a critically low level. This routine is invoked upon the first request for a page which fails to find enough room in the RAM 26. If the routine fails, it is then reinvoked and if it fails for a second time, pages are then written to the hard disk 32. Alternatively, this routine may be run as a background process.

Knowledge Base

The present invention includes a knowledge base to optimize system performance by customizing the driver 56 to a particular application program. The knowledge base of the present invention is useful for both data compression and virtual memory management either alone or in combination. With regard to memory management, the driver 56 must organize the RAM 26 and hard disk 32 such that those pages that are most frequently used are stored in the RAM 26 while those pages that are less frequently used are stored in the hard disk 32. Similarly, pages that are more frequently accessed may be stored uncompressed in the RAM 32 while pages that are less frequently accessed may be stored in the compressed area 70 of the RAM 32. With regard to data compression, since there are many different compression algorithms that are optimal for different types of data, the driver 56 should compress a particular page according to the optimal algorithm.

The knowledge base of the present invention stores information that allows the driver 56 to make the optimal decisions with regard to data location and type of compression. For each page of an application program, the knowledge base stores the predicted or actual compression ratio of the page, the best compression algorithm to use for that page, the frequency that the page has been accessed, and, for pages with a very high compression ratio, the actual compression data. Figure 8 illustrates one possible record structure for a database that stores the information related to a particular page.

The frequency that the page has been accessed allows the driver 56 to store less frequently used pages on the hard disk 32. For example, many features of software applications are rarely, if ever, used and it is therefore optimal to maintain these pages on the hard disk 32.

The actual or predicted compression ratio of a page may be used to decide whether to compress that page. It may not be efficient to compress those pages that compress only a very small amount while those pages that may be greatly compressed may be stored in the RAM 26 rather than the hard disk 32. Alternatively, the background compressor may actually determine the compression ratio of a page.

The knowledge base begins with no information regarding the content of the pages related to a particular application program and a background task gathers the previously described information for applications programs that are used. Thus, the statistical value of die knowledge base improves as each time an application program is used. The knowledge base may be stored in a disk drive and updated over time or not stored in a disk drive and thus reset each time the computer is turned on. For those pages that are written to, and thus change, die knowledge base will be less useful since different data may have a different optimal compression algorithm and compression ratio. Nonetheless, for many applications programs, a large percentage of the pages corresponding to an application program do not change.

For Windows^® based systems, the Windows^®' internal memory manager keeps track of which RAM memory pages are allocated to each software application. The driver

56 receives this information and thus can associate RAM pages with specific software applications. Also, the different loading sequence and specific destination address of each of the application's RAM pages may be tracked using Windows^®' internal data. Thus, the order in which the applications were loaded and the actual RAM page address do not affect the knowledge base since, to track pages, the knowledge base stores offsets from an application program and not a physical RAM address for a page.

To minimize the size of the database, information on the user's most commonly used 10 applications may be stored in the RAM 32. If these applications average 2MB, the database illustrated in Figure 8 occupies only 20K bytes. A complete copy of the database is kept, updated, and read from the hard drive 32. To minimize memory consumed by the knowledge base, an option could be implemented to load only the actively used application's pages of the knowledge base, thereby saving approximately between 10K-50K of RAM. As new pages become active, the corresponding database information may be transferred from the hard disk 32 to the RAM 26. Figure 9 is a flow chart of a routine that is used to install the driver 56 on a computer. At block 150, the routine determines whether the driver 56 is already install on the computer. If not, the routine branches to block 152 where a windows setup routine is called, which will be described in more detail below. Block 152 passes control to block 154, where an optimization routine is called, as will be described more fully below.

Block 156 is a routine that initializes the knowledge base. Block 126 is a routine that searches for computer resources, such as compression hardware, networked computers or other RAM, that it may utilize to improve performance. Finally, at block 132, the routine creates a hardware "key", as previously described with reference to block 100 of Figure 5, formed by hashing together numbers corresponding to various system devices, that contains information regarding the configuration of the system.

With regard to initializing the knowledge base, corresponding to block 156 of Figure 9, there are four basic options. The database may be zeroed and all statistics generated after the installation. Alternatively, a preexisting database may be imported from an external source such as a software manufacturer. Where the driver 56 is being reinstalled, the existing database may be kept. Finally, statistics may be generated by a batch process when the computer is not being actively used, such as overnight.

Although the present invention has been described in terms of a preferred embodiment and with reference to Figures 1-9, it will be appreciated that various modifications and alterations might be made by those skilled in the art without departing from the spirit and scope of the invention. The invention should therefore be measured in terms of the claims which follow.

Claims

CLAIMSWe claim:

1. A method for increasing the speed of a memory management system in a digital computer, comprising the steps of: storing in a table information indicating the frequency that data has been accessed by an operating system; scanning said table to determine less frequently accessed data; and storing said less frequently accessed data in a non-volatile computer memory.