CA2214648A1 - Methods and apparatus for performing heap management and protecting data structure integrity in non-volatile memory - Google Patents

Methods and apparatus for performing heap management and protecting data structure integrity in non-volatile memory Download PDF

Info

Publication number
CA2214648A1
CA2214648A1 CA002214648A CA2214648A CA2214648A1 CA 2214648 A1 CA2214648 A1 CA 2214648A1 CA 002214648 A CA002214648 A CA 002214648A CA 2214648 A CA2214648 A CA 2214648A CA 2214648 A1 CA2214648 A1 CA 2214648A1
Authority
CA
Canada
Prior art keywords
memory
block
allocated
list
blocks
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.)
Abandoned
Application number
CA002214648A
Other languages
French (fr)
Inventor
John M. Hoffer
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.)
Honeywell Inc
Original Assignee
Individual
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 Individual filed Critical Individual
Publication of CA2214648A1 publication Critical patent/CA2214648A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1441Resetting or repowering

Abstract

Methods and apparatus for performing heap management in programmable recording instruments used to record process data; and protecting the integrity of data structures stored in non-volatile memory included in such instruments should a power failure or power shut down occur while heap management operations are in progress. Furthermore, according to the invention, methods and apparatus are provided for (a) validating the integrity of the aforementioned data structures quickly on power up of the recording instrument; (b) finishing certain predetermined processes that were in progress when a power failure accurred, at the time when the recording instrument is powered back up; (c) locating any memory allocated to a user prior to a power failure or shut down; and (d) assuring the user, whenever power is restored to the system, that only pointers to previously allocated data blocks containing valid data are provided in response to users requests for such pointers.

Description

W O ~6/34337 PCTrUS96/05730 METHOl[)S AND APPARATUS F'OR PERFORMING
HEAP MANAGEMENT AND PROTECTING DATA
STRUCTURE INTEGRITY IN NON-VOLATILE MEMORY
RACKGROUND OF T~ ~ TION
5 1. Field of the Inventioll The invention relates generally to methods and a~p~udLu::i used for pc~ro~ g non-volatile memory "heap management", defined herein as allocating and/or freeing blocks of memory as requested by a user, in a manner that protects the integrity of the heap management data structure stored in the memory.
More particularly, the invention relates to methods and a~dLus for ~lro~l.ling heap management in programmable recording instruments used to recordprocess data; and protecting the integrity of data structures stored im non-volatile memory included such instruments should a power failure or power shut down occurwhile heap management operations are in progress.
Fur~h~rmore, according to the invention~ methods and ~d~llS are provided for (a) v~ tin~ the integrity of the aforementioned data structures quickly on power up of the recording instrument; (b) fini~hing certain pred~t~rmine-1 processes, that were in progress when a power failure occurred, at tlle time when the recording instrument is powered back up; (c) locating any memory allocated to a user prior to a 20 power failure or shut down; and (d) ~s~ ng the user, whenever power is restored to the system, that only pointers to previously allocated data blocks co.ll~;.,i-.~ valid data are provided in response to users requests for such pointers.
2. T)escr~ption of the Related Art Methods and a~p~dlus are well known for m~n~in~ the heap in, for 25 example, volatile random access memory (VRAM). For example standard, commercially available C malloc (memory allocation) and free (memory deallocation) utilities, used for VRAM heap management purposes, are well known by those skilled in the art.
In particular, heap management for VRAM can be accomplished by the 30 user m~;. .l5.; . .;~lg two lists. One list is a list of all blocks of memory that are not in use, often referred to as a "free list" of memory blocks; and a second list, which is a list of all W 096/34337 PCTtUS96tOS730 memory blocks that are in use, often referred to as the "used" or "allocated" list of memory blocks.
Techniques for VRAM list management per se, including procedures for adding and removing memory blocks from the aforementioned lists; procedures for s efficiently locating plo~clly sized blocks of memory to allocate; procedures for splitting and coalescing blocks for increasing allocation options and f~cilit~ting the efficient use of memory resources, etc., are also all known in the art.
In the VRAM context, when the recording instrument is powered down intentionally or due to a power failure, none of the memory is sustained unless an lo alternate source of power exists. ~sllming no such alternate power source, all the heap is free (available to be allocated again) when the m~ ine is powered back up. There is no need to worry about data ~Ll~ e corruption or having to locate previously allocated memory on power up.
In applications where it is iln,UUl L~lL to insure the integrity of heap management data ~Llul;Lulc;S, and other data stored in memory, well known approaches for achieving this objective include the use of an ullhlL~llu~Lible power source to insure pûwer at all times to the recording instrument itself; and/or the use of some type of "non-volatile" or "backed" memory device in the instrument, i.e., using a memorydevice that preserves the data structures and data stored therein for at least some predetermined time period.
Examples of non-volatile (backed) memory devices include capacitor backed random access memory (RAM), which preserves data stored therein over the time frame during which the capacitor discharges (thereby provides power to the memory device); battery backed RAM, etc.
For these types of recording instruments (those including some form of non-volatile memory for storing heap management data structures and process data), the prior art memory allocation and memory free utilities are problematic since: (a) if power goes down while removing or adding an entry to a list, parts of the list can be lost or the lists can be cross-linked depending on the list management technique used; (b) if power goes down while splitting or coalescing blocks, block sizes can be wrong; and (c) there is no way to get memûry allocated before the power went down back to the user and at ~ CA 02214648 1997-09-04 the same time assure the integrity of the previously allocated memory, after a power failure or reset has occurred.
Another prior art technique for preserving the integrity of data structures and the data stored in a non-volatile memory device, while avoiding the aforementioned s problems associated with splitting and coalescing memory blocks, is to require the use of memory blocks having fixed pre-allocated sizes for storing data. This technique,although addressing some of the aforementioned problems, wastes often limited non-volatile memory resources.
SUMMARY OF T~E ~VENTION
The present invention provides a method for performing heap management and protecting the integrity of data structures created and stored in non-volatile memory included in a programmable recording instrument used for recording process data, the method characterised by the steps of:
(a) definin~ a memory header data structure used for m~n~ging run time memory operations and aiding in the recovery of any data structures being modified when and if power to the instrument is lost, wherein said memory header incl~des a first pointer to a list of free memory blocks and a second pointer to a list of allocated memory blocks;
(b) defining an allocated memory block header, stored within each allocated memory block, used for determining block attributes, inclllrling an 2s indicator to signal when a given memory block has been locked into said list of allocated memory blocks, a block ownership indicator and a pointer to the next allocated memory block, if any;
(c) initi~li7ing said non-volatile memory whenever the recording instrument is powered up, incl~l-linp the steps of determining if said non-volatile memory ;s to be reset and the step of verifying the A ~ r~

stability of non-volatile memory whenever non-volatile memory is not reset;
(d) allocating memory from one of the memory blocks included in said list of free memory blocks, in s response to a user request for memory allocation, ili7:ing only atomic instructions to modify said memory header and said allocated memory block header; and (e) locking an allocated memory block into said list lo of allocated memory blocks in response to a user request for the lock, initi~ ing the block and setting the lock indicator with atomic instructions.
The present invention may provide the step of freeing a memory block included in the list of allocated memory blocks, in response to a user request for freeing s memory, utili7ing only atomic instructions to modify the memory header and the allocated memory block header.
According to a further preferred aspect of the invention, a "state"
indicator is m~int~ined in the aforementioned memory header which is modified by one atomic instruction. Any time a list is modified or a memory block header is modified (split or coalesced), the state is set to indicate what is occurring.
If power goes down while performing a heap management operation, and then power comes back up, the state is used to determine the last function that was performed to provide an indication of whether or not the non-volatile memory data structures that support heap management are "stable". If "unstable", stability can be 2s achieved by fini~hing certain predetermined processes that were in progress when a power failure occurred, at the time when the lecoldillg instrument is powered back up.
Non-volatile memory data structures can then be recovered using other entries in the memory header (to be described in detail hereinafter).
With regard to fini~hin~ operations in progress when, for example, recovering from a power failure, the heap management techniques contemplated by the preferred embodiment of the invention will never put blocks in the used list (list of allocated memory blocks). If power went down while trying to allocate a block of I ~ r ~

memory, it is known that the user was never given the memory. However, if power went down while trying to free a block of memory the processes contemplated by the invention will continue where they left off(for example in trying to coalesce blocks of free memory etc.), and put the approp. iate block of memory into the free list.
According to yet another preferred aspect of the invention the order in which data structures are manipulated is important so that there is a pointer to all blocks of memory at any point in time.
According to still another preferred aspect of the invention, to avoid cross linking lists (a) entries are always completely removed from one list before they are added to the other list; (b) removal of an entry from a list is always accomplished utilizing one atomic instruction; and (c) adding an entry to a list is performed utili7ing two atomic instructions (to be described in detail hereinafter) performed in a predefined order.
To avoid having incorrect block sizes specified following a power failure or reset7 a plere"ed embodiment ofthe invention calls for utili7.ing a "partition pointer'' to point to a block being coalesced or to the location in a block where a division will occur. A "working pointer" will already be pointing to the other block being coalesced or the block being split. These two pointers together as will be demonstrated hereinai'ter, can be used to determine if the header size in a block is correct.Yet another p. c;rel . ed aspect of the invention concerns the problem of returning only valid allocated memory to a user during power up by adding a unique user ID to each block of memory; and only allowing memory blocks previously "locked" by a user into the list of allocated memory blocks (to acknowledge block validity), to be returned. When the recording instrument powers up, according to the pl ~re" ed embodiment ofthe invention it will remove all lln~c~n~wledged ("unlocked") memory blocks from the used list and put them back in the free list.
The invention also provides appa~ s for pe, ro"l,i~lg heap management and protecting the integrity of data structures created and stored in non-volatile memory included in a prog, ~ able recording instrument used for recording process data, the apparatus characterised by:
(a) pro~,~"""able data processing means, inçlu~ing (al) means for initializing non-volatile memory used for at least temporarily storing process data;
(a2) means for allocating memory blocks upon request;
s (a3) means for freeing allocated memory upon request;
(a4) means for locking data blocks into a list of allocated memory blocks upon request; and (aS) means for obtaining and returning pointers o to previously locked allocated blocks of memory upon request following a restoration of power to said instrument; and (b) the non-volatile memory means, for coupling to said programmable data processing means, and for at least S temporarily storing process data received and/or derived by said instrument, includes a memory header data structure used for m~n~ging run time operations and for aiding in the recovery of any data structures being modified when and if power to the instrument is lost, and an allocated memory block header, stored within each allocated memory block, used for determining block attributes, including an indicator to signal when a given memory block has been locked into said list of allocated memory blocks, a block ownership indicator and a pointer to the next allocated memory block in said list of allocated memory blocks, if any, wherein the contents of said memory header data structure and said allocated memory block header may only be modified 11tili7in~ atomic instructions.

.. ,, -BR~EF DESCR~PTION OF THE DR~WING
FIG. 1 depicts an exemplary programmable process data recording instrument, of the type contemplated by one aspect of the invention, that includes non-volatile memory, in the form of a capacitor backed RAM, for at least temporarily storing s process data being recorded by the instrument.
FIG. 2 depicts the form and content of an exemplary memory header data structure, of the type contemplated by a preferred embodiment of the invention, suitable for use in pelro.llling run-time non-volatile memory heap management and data structure recovery following a power failure or reset.
FIG. 3 depicts the form and content of an exemplary allocated memory block header, of the type contemplated by a preferred embodiment of the invention, which may be used in conjunction with the memory header depicted in FIG. 2 (but on a per block basis), in performing non-volatile memory heap management and data structure recovery following a power failure or reset.
FIG. 4 depicts, in accordance with the teachings of one embodiment of the invention, an illustrative set of process steps for initi~ in~ non-volatile memory included in a programmable recording instrument, such as the exemplary recordinginstrument depicted in FIG. 1, whenever the recording instrument is powered up.
FIG. 5 depicts, in accordance with the te~ching~ of one embodiment of 20 the invention, an illustrative set of process steps for allocating memory from one of the memory blocks included in a list of free memory blocks, in response to a user request ~ENDED Sll,~t, W 096/34337 PCTrUS96105730 - The invention is also directed to a~pa,dLus for performing heap management and protecting the hllcl ;~;ly of data structures created and stored in non-volatile memory included in a programmable lecoldhlg instrument used for l~cor.lillg process data, ccmprising: (a) pro~a~ llable data processing me~ns, including: (al ) 5 means for initi~ ing non-volatile memory used for at least tc.ll~olcu;ly storing process data; (a~) means for allocating memory blocks upon request; (a3) means for freeing allocated memory upon request; (a4) means for locking data blocks into a list of allocated memory blocks upon request; and (a5) means for obtaining and lC~ g pointers to previously locked allocated blocks of memory upon request following a 0 l- ;,Loldtion of power to the instrument; and (b) non-volatile memory means, coupled to the pro~r~mm~hle data processing means, for at least temporarily storing raw process data received and/or derived by the instrument, wherein the non-volatile memory includes a memory header data structure used for m~n~ging run time recorder operations and aiding in the recovery of any data structures being modified when and if power to 5 the n~e~ is IG~t, ~nd a~ alloc~ted memory biock header, stored within each allocated memory block, used for determinin~ block attributes, including an indicator to signal when a given memory block has been locked into the list of allocated memory blocks, a block ownership indicator and a pointer to the next allocated memory block in the list of allocated memoly blocks, if any, whc.~ the contents of the memory header data 20 structure and the allocated memory block header may only be modified ~ltili~ing atomic instructions.
The invention features the ability to perform heap management in programrnable recording instruments in a manner that protects the integrity of data structures stored in non-volatile memory included in such instruments should a power 25 failure or power shut down occur while heap management operations are in progress.
Furthermore, the invention features methods and apparatus for (a) validating the integrity of the aforementioned data structures quickly on power up of the recording instrument; (b) insuring the stability of further heap management processing following the occurrence of a power failure of reset; and (c) locating any memory 30 allocated to a user prior to a power failure or shut down, and at the same time assuring, whenever power is restored to the instrument, that only pointers to previously allocated W 096r'.4337 ~CT,~S~ 573 _9_ I
t c ~ t~in;n~ 3,,0r~c to ~ or s~c~/ ¦
pointers. ~
The invention also features the ability to efficiently~the non-volatile memory resource (e.g., the backed RAM), in a pro~ble recording S instrurnent used to record process data, to maxim~umber of data blocks that can be created and accommodate the varying-gg&~es of information to be recorded.
These and other~embo-limentc. and features of the present invention and the man~taining them will become ~e.,t to those skilled in the art, and the in~n itself will be best understood by reference to the f~Detailed Description read in conjunction with ~accompanvinSz Drawiry~
RR~F,F l)F.~.CR~PTlON OF T~F I~ WTNG
FIG. 1 depicts an exemplary pro~l~.-able process data recording instrument, of the type contemplated by one aspect of the invention, that includes non-volatile memory, in the form of a capacitor backed RAM, for at least temporarily storing process data being recorded by the instrument.
FIG. 2 depicts the form and content of an exemplary memory header data structure, of the type contemplated by a p~c;r~ d embodiment of the invention, suitable for use in p~,.ro~",ing run-time non-volatile memory heap management and data structure recovery following a power failure or reset.
FIG. 3 depicts the form and content of an exemplary allocated memory block header, of the type contemplated by a p~ere.l~d embodiment of the invention, which may be used in conjunction with the memory header depicted in FIG. 2 (but on a per block basis), in p~. r.,. I~ling non-volatile memory heap management and data structure recovery following a power failure or reset.
FIG. 4 depicts, in accordance with the teachings of one embodiment of the invention, an illustrative set of process steps for initi~li7ing non-volatile memory included in a programmable recording instrument, such as the exemplary recordinginstrument depicted in FIG. 1, whenever the recording instrument is powered up.
FIG. 5 depicts, in accordance with the teachings of one embodiment of the invention, an illustrative set of process steps for allocating memory from one of the . memory blocks included in a list of free memory blocks, in response to a user request ~.M~ Er' '~

W O 96/34337 PCTrUS96/05730 for memory allocation, where only atomic instructions to modify the exemplary memory header depicted in FIG. 2 and the exemplary allocated memory block headerdepicted in FIG. 3.
FIG. 6 depicts, in accordance with the te~rhin~ of one embodiment of 5 the invention, an illustrative set of process steps for freeing a memory block included in a list of allocated memory blocks, in response to a user request for freeing memory, where only atomic instructions to modify the exemplary memory header depicted inFIG. 2 and the c~empl~ry allocated memory block header depicted in FIG. 3.
FIG. 7 depicts, in accordance with the te~hin~ of one embodiment of 0 the invention, an illustrative set of process steps for locking an allocated memory block into a list of allocated memory blocks in response to a user request for the lock.
FIG. 8 depicts, in accordance with the te~-.hin~.c of one embodiment of the invention, an illustrative set of process steps for providing a pointer to a block of memory owned by a user, in response to a user request for such pointer, only when the memory block contains valid data.
FIG. 9 depicts, in accordance with the tç~chings of the invention, an exemplary set of steps for removing an entry from one list and inserting it into another list, in a manner that avoids cross linking lists.
FIG. 10 depicts, in accordance with the te~ching.~ of the invention, an 20 exemplary set of steps indicating how a partition pointer may be used to partition a memory block, im a manner that protects data structure integrity.
nF,TATl,F,n DF~C~TPl[ION
Prior to describing the details of the al)p~dlus and process steps contemplated by the invention, certain requirements and assumptions have been made 25 regarding the proces~ing t;nvir~Jlllllent in which the invention may be practiced. The assurnptions made are for the sake of conveniently illustrating the princip~l~ of the invention and are not inten~le~1 to limit the scope or spirit of the invention.
The recording instruments in which the invention may be practiced are assumed to be "programmable" devices; that is, devices that are provided with access to 30 (and execute) programs which implement the various processes described herein for performing heap management and protecting the integrity of data structures created and stored in non-volatile memory included in the instrument.

W 096/34337 PCTrUS96/OS730 Specific examples of commercially available recording devices of the type cont~mpl~te~l by the invention (used to record process data) are microprocessor based video recorders and controllers available from Leeds & Northrup Company.
~ Those skilled in the art will readily be able to implement the processes s described herein in the form of programs suitable for execntiQn by a microprocessor after reviewing the description of the invention set forth he~ with reference to the various flow charts depicted in the Drawing.
Furthermore, in order to practice the ~rer~,l,ed embodiment of the instant invention:
(1) All entries in any ofthe data structures defined herein may only be changed using a single assembly instruction (they must be atomic operations).
(2) There must be a mech~ni~m that will keep the recording unit from starting the execution of an instruction if power starts to go down. This may beaccomplished, for example, by c~n~ing an ill~e~lU~)~ to be triggered when power starts to go down, monitoring a non-maskable hlL~llu~l line and not servicing the hll~ l until the last instruction being executed by the instrument is completed (~ g further that there is enough time to complete the last operation from the time the interrupt is triggered until the power gets too low to sustain processor operation).
(3) An external clock must exist that keeps time even when the recording instrument is powered off.
According to the embodiment of the invention described hereinafter with reference to FIG. 1, a capacitor backed RAM is used for the purposes of describing the invention, where the c~p~citor insures that if P~trrn~l power to the instrument is intelLTupted the RAM contents will be m~int~inrd for (in the exemplary capacitor backed 2s RAM in~t~nre) the discharge lilEe of the c~r~ritQr (e.g., approximately 90 minutes in one embodiment of the invention). Again, it is not n~ce~ry for the RAM included in the recording instrument to be capacitor backed (it could for example be battery backed).
Finally, before making reference to FIG. 1, it should be understood that according to the context in which the invention is set forth:
(1) Heap management is a matter of allocating and freeing blocks of memory as requested by the user. There are two lists that are kept. One list is a list of all blocks of ~ CA 02214648 1997-09-04 ~ wo 96/34337 ~Cr,~TS''G/~S7 memory that are not in use which is called the free list. The other list is a list of blocks of memory that are in use which is called the used list.
(2) It is ~csllmecl that the free list is a sorted list organized based on the size of the free blocks. The largest block is the first entry in the list. The used list is not sorted.
5 All new entries to this list are placed in the front of the list.
(3) It is ~csllm~d that when a user requests memory, the heap management processes in which the invention is practiced search the free list to see if there is a block of free memory that is the exact same size as the amount of memory that has beenrequested. If an exact match is found, that block of memory is selected. If an exact lo match cannot be found, the largest block is divided into two blocks, one that is the exact size requested and the r~m~ining memory makes up the other. The r.om~ining memory block is placed in the free list based on its size and the new exact size block is now selected. The selected block is removed from the free list and added to the used list. A
pointer to the memory (located right after the allocated memory block header to be 15 described in detail hereinafter with reference to FIG. 3) is then returned to the user.
(4) To free memory, the block is removed from the used list and added to the free list. When adding to the fTee list, there is first a check to see if there are free memory blocks on either side of the memory block that is being freed. If so, these free blocks are coalesced with the one now being fTeed. Any coalesced blocks are 20 temporarily removed fTom the fTee list. The block being fTeed (including any coalesced memory) is then added to the fiTee list based on the size of the block.
Ref~.e.lce should now be made to FIG. 1 which, as indicated hereinbefore, depicts an exemplary programmable process data recording instrument 100, of the type CO~ ,.pl~t~ by one aspect of the invention ¦~ g~ ;bed ;n ~ Li~;..;Le 2s ~ fiou31y incorpore~ r~ o~ tion)~ that includes non-volatile memory 101, in the form of a c~pacit- r backed RAM, for at least temporarily storing process data being recorded by instrument 100.
In particular, exemplary programrnable process data recording instrument 100 shown in FIG. 1 depicts the device as including:(a) programmable data processing 30 means 102 (shown as a rnicroprocessor), having access to (according to the preferred embodiment of the invention), program utilities that implement the various processes described herein for performing heap management and protecting the integrit~ of data ~ ù ~ ~

' CA 02214648 1997-09-04 W096/34337 P~T~J~9fi/OS7~0 structures created and stored in non-volatile memory 101. Non-volatile memory 101 is also shown in FIG. 1 to be coupled to programmable data processing means 102 via link 150, and may be used for at least temporarily storing raw process data received andlor derived by instrument 100.
~ Th~ ~th~r ~ n~nt ~f inctr~lm~nt 1 nt~ q~O AOC~ ~ibed in the previs~sl~
inr~ nr~r~t~A ~ n~nAi~ nqt~ ill not be ~ c~cced f~ r her~in~ft~
cin~ t~ y ~C~ not ~ ~ t~ 6 ~ :~on of thc prose.~t in~,~cntion boing 9el ~. h ~ ,i According to the invention, non-volatile memory 101 includes two important data structures for heap management purposes. First, a memory header data lo structure (to be explained in detail hereinafter with reference to FIG. 2) used for m~n~E~in~ run time recorder operations and aiding in the recovery of any data structures being modified when and if power to instrument 100 is lost; and secondly, an allocated memory block header, stored within each allocated memory block (to be explained in detail hereinafter with reference to FIG. 3), used for det~ fil hlg block attributes, including an indicator to signal when a given memory block has been locked into a list of allocated memory blocks, a block ownership indicator and a pointer to the next allocated memory block, if any.
As indicated hereinbefore, and as will be explained further hereinafter, the contents of the memor,v header data structure and the allocated memory block header may only be modified lltili7ing atomic instructions.
The afole.~ tioned program utilities conle,.lplated by the preferred embodiment of the invention are preferably, although not n~c~ss~ ily, implemented via soft.~vare that can be çxec~ltPd by data processing means 102. When made available to data processing means 102 and e~Pcuted thereby (in the context of a programmablerecording instrument like insl~,.cllt 100), instrurnent 100 is trans~ormed into apparatus of the type contemplated by the invention.
Each of the prograrn utilities contemplated herein are actually specific impl~m.~nt~tions of the following more generic means, which may all be readily implement~ by those skilled in the art ~,vith reference to the flowcharts shown in FIG. 4 thru FIG. 8 (inclusive), and the description set forth hereinafter with respect to these figures: (I) means for initi~li7ing non-volatile memory that is used for at least temporarily storing process data; (2) means for allocating memory blocks upon request;

' r..

W 096l34337 PCTrUS96/OS730 (3) means for freeing allocated memory upon request; (4) means for locking data blocks in allocated melrnory upon request; and (5) means for obtaining and let~ g pointers to previously locked allocated blocks of memory upon request following a l~,i,Lu.dLion of power to the instrument. These various means taken together are suitable for re~1i7ing the aforestated objects of the invention; and the various embodiments as aspects thereof as described hereinbefore in the Su~ of The Invention.
The tl~t~b~e upon which the ~l~,felled program utilities operate includes the aforementioned memory header data structure and allocated memory block header, described with reference to FIG. 2 and FIG. 3, respectively, h~le;ll~el.
o Reference should now be made to FIG. 2 which, as previously indicated, depicts the form and content of an exemplary memory header data structure 200, of the type contemplated by a l)lc;r~ d embodiment of the invention, suitable for use in ~llllillg run-time non-volatile memory heap management and data structure recovery following a power failure or reset.
In particular FIG. 2 depicts ~r~r~lled memory header 200 including the following entries used by the processes contemplated by the invention in the manner described hereinafter:
(a) Tniti~1i7~tion (Init) Indicator 20l may be used to d~t~ " ,i"e if non-volatile memory has been initi~1i7~o~1 If the value (for example, a predefined initi~1i7~tion completion code) is not in this part of the memory header when the non-volatile memory is initi~1i7e~1 it is assumed, according to one embodiment of the invention, that all of the memory must be returned to the aforl-mentioned free list.
(b) Time Stamp 202, a memory location that is updated at a fixed interval when the time stamp function (which is optional) is used, may be used to determine how long 2s power was off dLuring a power failure when the insh~ment is rebooted. Those skilled in the art will readily appreciate that in cases where the non-volatile memory has a window within which the memory is backed (such as when a capacitor is used to back the memory), the time stamp enhy should be included in the memory header contemplated by the invention to deterrnine if valid data remains in the backed memory when power is restored to the insh~ment. By way of conhrast, the enhy may not be needed if, for example, a battery backed RAM is used for non-volatile memory. If Init Indicator 20 l is valid, according to one embodiment of tbe invention, it can be ~c11mecl that the time , W O 96/34337 PCTrUS96/OS730 in Time Stamp 202 is a valid time on power up. According to the ~rerell~d embodiment of the invention, the time must be written to Time Stamp 202 at a fixed interval. The length of the in~erval depends on how accurate the time difference calculation used to - (1et~rmine how long the unit was powered down (such as finding the dirr~.cnce between the time in Time Stamp 202 and the time when power is restored to the instrument), needs to be.
(c) Current Working Pointer 203, points to a block of memory that is being allocated or freed. This pointer will locate a block that was being manipulated when power went down.
o (d) Current Partition Pointer 204, points to a block of memory that will be split off from a larger block of memory or will be coalesced (joined) with another block of memory. More particularly, Current Partition Pointer 204 points to a block of memory that is being separated from a block of memory that is pointed to by Current Working Pointer 203 during a memory allocation. It may also point to a block of memory that is being combined with a block of memory pointed to by Current Working Pointer 203 during a free.
(e) Used List Pointer 205, points to the first entry of a list of memory blocks that are in use. The list pointed to is the aforementioned list of allocated memory blocks in non-volatile memory.
(f) Free List Pointer 206, points to the first entry of a list of memory blocks that are not in use (free memory blocks in the aforementioned free list) in the non-volatile memory.
(g) State Indicator 207, is one of a predetermin~d set of values used to det~ormine the stability of non-volatile memory upon recovery from a power loss and determine the 2s last operation performed in the heap management process before power was lost, as will be explained in greater detail hereinafter.
Reference should now be made to FIG 3 which, as indicated hereinbefore, depicts the form and content of an exemplary allocated memory block header 300~ of the type contemplated by a preferred embodiment of the invention, which may be used in conjunction with memory header 200 depicted in FIG. 2 (but on a per block basis for every block allocated), in p~lrOllllillg non-volatile memory heap management and data structure recovery following a power failure or reset. As CA 022l4648 l997-09-04 W 096/34337 PCTrUS96/05730 indicated hereinbefore, the entries in allocated memory block header 300 describe attributes about the block, the owner and a pointer to the next allocated block, if any.
In particular, FIG. 3 depicts pler~ d allocated memory block header 300 including the following entries used by the processes collle~ )lated by the invention s in the manner described hereinafter:
(a) ID 301, is a unique identifier that is defined by the user of each block.
According to one embodiment of the invention ID 301 is specified by the user when the block is allocated. Furthermore, according to the illustrative embodiment of theinvention being set forth herein, all users of the non-volatile memory must agree to use 10 dirr~.el.t i~ientifier~.
(b) Block Size 302, is a value indicating the actual size of the memory block that has been allocated, not including the header. According to the illu~ ive embodiment of the invention, it is a multiple of a ~ ., . . block size that is used to control fr~gment~tion of the allocated memory.
(c) Pointer To Next Block 303, is an entry that points to the next block in the list. If the entry is in the used list, it points to the next block that is in use. If the entry is in the free list, it points to the next free block.
(d) Acknowledge Flag 304, is an entry that is used, according to the preferred embodiment of the invention, to lock a block of memory into the used list. When a 20 block is first allocated by a user, the colltellts of that block of memory is lln(1t?fined.
Once the user is given a block, he must fill that memory with known values, and then may invoke the process described herein with reference to FIG. 7 to fill in the Acknowledge Flag 304 entry with a value that indicates that it has been acknowledged.
This mechanism allows the process described herein with reference to FIG. 8 to return 2s pointers to users on power up with some assurance that the pointers returned point to valid data.
(e) Size Adjust 305, is a value indicating the difference between the actual block size and the amount of memory that the user requested. This entry is, according to one embodiment of the invention, used when a pointer is returned to a user on power up.
30 This number when subtracted from the actual block size which will produce the size of the block that the user really requested and this result is, according to the illustrative embodiment of the invention, also returned to the user along with the pointer.

/ W096~4337 ~CTrUS~6/OS~30 (f) Memory 306, is the actual block of memory itself that is managed by allocated memory block header 300.
Prior to making reference to FIG. 4 thru FIG. 8 for specific exarnples of the processes contemplated by the invention, it should recalled that, according to the s invention, the order in which data structures are manipulated is important so that there is a pointer to all blocks of memory at any point in time. This is the reason for the aÇo,~.l,elltioned pointers in the headers described hereinbefore with reference to FIG. 2 and FIG. 3.
Furthermore, it should be recalled that according to the invention the last o "state" ofthe non-volatile memory, as stored in State Indicator 207 (previously described herein with reference to memory header 200), is hlll)o~ t for ascertaining non-volatile memory stability following a power failure. If power goes down while manipulating the heap management data structures, State Indicator 207 makes cleanup fast and simple on power up as will be seen with reference to the exemplary processes 1S set forth hereinafter. q. p~ (Q~ c o~
It should also be recalled that, according tol~he invention, State Indicator 207 may only be modified in one atomic instruction; and that any time a list is modified or an allocated memory block header is modified (because of a split or coalesce), State Indicator 207 is set to indicate what is occurring. By following this procedure, if power 20 goes down while performing the heap management functions contemplated herein, and then power comes back up, State ln~lic~t~r 207 may be used to determine the lastfunction that was performed.
Reference should now be made to FIG. 4 which, as indicated hereinbefore (in accordance with the teachings of one embodiment of the invention), 25 depicts an illustrative set of process steps for initi~li7ing non-volatile memory included in a programrnable ~ecoldJilg instrument, such as ~he exemplary recording instrument depicted in FIG. 1, whenever the recording instrument is powered up.
When the recording instrument is powered up, the non-volatile memory must be initi~li7~1 According to the illustrative embodiment of the invention being set 30 forth herein, there are four exemplary conditions (reset conditions) that will cause all of the structure to be cleared and all of the memory to be freed:

A~ 7ENDt,~

CA 022l4648 l997-09-04 W 096134337 PCTrUS96/OS730 (1) Init Indicator 201 is not set to the proper value. This in~ t~s that the memory was never initialized or that the power source that sll~t~inlo~l the non-volatile memory was removed.
(2) The difference b~lweell the current time and Time Stamp 202 in s memory header 200 (when the time stamp is used) is greater than the m;1xi",l",. allowed time or the current time is less than the time stamp.
(3) The extem~l clock has failed.
(4) The user has specifically requested that the non-volatile memory be cleared.
o If none of the above conditions are met, the initi~li7~tion process contemplated by the invention must verify the stability of the data structures used for heap management purposes, particularly if power went down while any of the heap management data structures were being manipulated.
The aforementioned stability may be det~rmin~d by checking the aforementioned State Indicator 207 (in memory header 200) to see if a pre~letennined value that represents STABLE is present. If it is not stable, the initialization process contemplated by the invention ~ to repair the structures and bring them to a stable condition by completing certain operations in progress when power went down, as discussed hereinbefore.
With reference to FIG. 4 it may be seen that the non-volatile memory initialization process, contelllplated by the illustrative embodiment of the invention, is shown called by a root task at step 401.
Next, the flowchart is essentially divided into two portions, which the branch occurring at step 402 in FIG. 4: one branch is a process for resetting (clearing) memory if one of the aforementioned exemplary memory reset conditions exist, theother branch is a process verifying the stability of the data structures in the backed memory if a reset is not to be performed.
The exemplary reset process depicted in FIG. 4 is shown to include the steps of:
(1) performing a non-volatile memory hardware integrity test (shown at step 403), which is meant as a haldw~uc test to det~nnine if the memory chips are still good, that read/write operations to memory can properly be performed, etc.

W 096/34337 PCTrUS96/05730 (2) Retllrnin~ an error indication (at step 405) if it determinç~l at step 404 that the memory integrity test failed.
(3) Clearing non-volatile memor,v (show at step 406), which, according to a r~.led embodiment of the invention involves the steps (not showm in FIG. 4) of 5 creating (init~ 7ing) the aforementioned non-volatile memory headers and setting Init Indicator 201, in memory header 200, to in~lir.~te initi~li7~tion had been performed.
The exemplary stability vPrifi~tir,n process, inrh~tlinE~ steps to assure the integrity of the aforementioned data structures in non-volatile memory, is shown in FIG.
4 to include the steps of:
lo (1) pelrOllllillg a non-volatile memory hal.lw~; integrity test (shown at step 407), which is meant as a hardware test to cletPrrnine if the memory chips are still good, that read/write operations to memory can plop~,lly be performed, etc.
(2) Ret lrninp an error indication (at step 405) if it ~lPtPrmin~cl at step 408 that the memory integrity test failed.
(3) Fx~.;,.;.. g State Indicator 207 in memory header 200 (step 409), to ~letermin~ non-volatile memory stability theLeLolll (step 410).
(4) Completing any operation in progress at the time of a power loss that affects non-volatile memory stability (step 411), whenever it is ~lP~termined at step 410 that the non-volatile memory is unstable; and (5) Removing all allocated memory blocks not previously locked into the list of allocated memory blocks, lel...,.;..g the unlocked allocated blocks to the free list (step 412).
Reference should now be made to FIG. 5 which, as indicated hereinbefore, depicts (in accordance with the te~clling~ of one embodiment of the 2s invention), an illustrative set of process steps for allocating memory from one of the memory blocks included in a list of free memory blocks, in response to a user request for memory allocation. As stated hereinbefore, it is required, according to the te~chin of the invention, that only atomic instructions be used in performing the allocation function when modifying exemplary memory header 200 depicted in FIG. 2, and when30 modifying exemplary allocated memory block header 300 depicted in FIG. 3.
Before explaining the details of the process depicted in the flowchart, an overview of the allocation process contemplated by the invention will be set forth.

W O 96/34337 PCTrUS96/05730 To allocate a block of backed memory, the user provides two parameters to the heap management process contemplated herein: the size of the block being requested and the aforementioned unique user identifier.
The illustrative process depicted in FIG. 5 than finds the next closest 5 multiple of the miniml~m block size. Current Working Pointer 203 and Current Partition Pointer 204 (shown in memory header 200 described hereinbefore with reference to FIG. 2) are set to NULL.
After this is done, the free list is seal-;hcd for a block of memory that can be allocated. If a block of the exact size can be located, that block is used. If an exact 1 o size cannot be found, the biggest available block is used. The free list is sorted by block size (largest to smallest). If all available blocks are too small, a NULL is returned to the user.
If a block is located, Current Working Pointer 203 is filled in to point to that block. If the block is larger than the requested size, the block must be partitioned.
15 The part of the block that is larger than what is needed is made its own block of memory and inserted into the free list.
The block that is to be used is removed from the free list and added to the front of the used list which is not sorted.
With reference to FIG. S it may be seen that the non-volatile memory 20 allocation process, cont~mplzlte~l by the depicted illustrative embodiment of the invention, includes the steps of: (a) searching the list of free memory blocks for a block of memory to allocate (step 501); (b) cl~;l , .-i. ,i..g, whenever a block of memory to allocate is found (step 502), if the memory block found is larger than needed; and l~;l....-i.l~ the aforementioned Null when all available blocks of memory are too small 2s (step 503); (c) if the memory block found is not larger than needed (as determined at step 504) removing the memory block found from the free list (step SOS); (d) splitting the memory block found, if larger than needed, into a first block portion for allocation and a second block portion for return to the free list (step 506); (e) returning the second block portion to the free list whenever the second block portion is created (step 507);
30 and (f) removing the first block portion from said free list whenever the second block portion is created (step 508); and (g) adding the prop~lly sized block being allocated to the list of allocated memory blocks (step S09).

Reference should now be made to FIG. 6 which, as indicated hereinbefore, depicts (in accordance with the te~chin~.~ of one ernbodiment of the invention), an illu~trative set of process steps for freeing a memory block included in a ~ list of allocated memory blocks, in response to a user request for freeing memory. As stated hereinbefore, it is required, according to the te~hin~.c of the invention, that only atomic in~llu~;lions be used in p~lrOll~ g the freeing function when modifying exemplary memory header 200 depicted in FIG. 2, and when modifying exemplary allocated memory block header 300 depicted in FIG. 3.
According to the illustrative embodinnent of the invention being set forth herein, to free (return) a block of memory to the free list it is first removed from the used list and then placed into the free list. Any blocks of memory that can be combined (adjacent blocks of free memory), are combined when inserting an entry into the free list.
With reference to FIG. 6 it may be seen that the non-volatile memory allocation process, contemplated by the depicted illustrative embodiment of the invention, includes the steps of: (a) searching the used list (list of allocated memory blocks) for the memory block being freed (step 601 ); and if not found (as ~letennined at step 602), sign~lling an error (step 603); (b) removing the memory block being freed from the list of allocated memory blocks (step 604); (c) detennining if the block being freed can be joined with another free block in the list of free memory blocks (step 605);
(d) joining the free blocks together whenever it is deterrnin~od that at least two free memory blocks may be coalesced (step 606); and (e) adding the freed block to the freed memory list based on block size (according to the pler~.-ed embodiment of the invention; though not required per se) at step 607 (when no joining was performed), or at step 608 (following the coalescing of blocks of memory).
Reference should now be made to FIG. 7 which, as indicated hereinbefore (in accordance with the tP~chin~ of one embodiment of the invention), depicts an illustrative set of process steps for locking an allocated memory block into a list of allocated memory blocks in response to a user request for the lock.
As mentioned hereinbefore, it is desirable to know whether or not an allocated block of memory contains known values; and that if power goes down at any time, the user will be able to obtain pointers to allocated memory owned by the user on W 096/34337 PCTAUS96tOS730 -22-power up with some assurance that the data stored in the allocated memory is valid.
The problem with simply l~ll.l ll;ll~ a pointer to previously allocated memory to a user, without pClrO~ lg the acknowledge function (to lock an allocated block of memory into the used list) contemplated by the invention, is that the user may s not have had an op~ullul,lly to initi~li7P the allocated memory. Without the process (or similar processes) described with reference to FIG. 7, there would be no way to truly verify that the subject allocated memory has been initi~li7ed by the user.
The merh~ni~m to ensure that only pointers to ~rol)~lly initi~li7ecl memory blocks are returned to the user is the aforementioned acknowledge processlo contemplated as part of the present invention.
The acknowledge process, according to the ~ierc;~led embodiment of the invention, works as follows: When a user obtains requested allocated memory, the user initializes the memory and then invokes the acknowledge process contemplated herein.
~ Acknowledge Flag 304, described hereinbefore with reference to FIG. 3, is set in the 15 al~plo~l;ate allocated memory block header (e.g., allocated memory block header 300) - using one atomic instruction.
As previously indicated hereinbefore with reference to the initi~li7~tion process set forth in FIG. 4; on power up, all nn~ n~wledged memory blocks are removed from the used list and put them back in the free list (step 412 in FIG. 4).
With reference to FIG. 7 it may be seen that the non-volatile memory acknowledge (memory locking) process, contemplated by the depicted illustrative embodiment of the invention, includes the steps of: (a) receiving a user specified pointer to memory included in a given memory block (step 701); (b) det~nnining if the given memory block is in the list of allocated memory blocks (step 702), rt;ll" .~ g an error 2s indication if it is not in the list of allocated memory blocks (step 703); and (c) setting Acknowledge Flag 304 (the lock indicator) in the allocated memory block header associated with the given memory block to indicate that the given memory block has been locked into the list of allocated memory blocks (step 704).
Reference should now be made to FIG. 8 which, as indicated 30 hereinbefore (in accordance with the tez~chings of one embodiment of the invention), depicts an illustrative set of process steps for providing a pointer to a block of memory W 096134337 PCTrUS96/OS730 -23-owned by a user, in .c~o"se to a user request for such pointer, only when the memory block contains valid data.
According to the preferred embodiment of the invention, on power up, a - user tries to get any blocks of memory that they may have allocated before power went down. In order ~o do this, the user must provide his unique ID (~ cll~secl hereinbefore), together with an index (to be described hereinafter) to the heap management contemplated by the invention as responsible for ~ g pointers to previously allocated memory to the user.
The ID is used to identify the blocks that the user owns. The index is 10 used to ~etermin~ which block of memory that the user wants. For example, if the user always allocates three blocks, the user will (according to the illustrative embodiment of the invention being set forth herein) invoke the process that returns pointers (like the one illustrated by way of example in FIG. 8) three times using the indices 0, 1 and 2 l~e1Li~ely. If a NULL is retu~ned it means that no more blocks of memory have been 15 allocated by the user.
~ ccordingly, if a users invokes the exemplary process depicted in FIG. 8 three times, but gets a NULL when index 1 is used, it means that the users only had one block of memory allocated before power went down (index 0).
It should be noted that by the time a user is permitted to try and obtain 20 pointers to previously allocated blocks of memory, it is ~sllme~l that the aforementioned initialization process (described with reference to FIG. 4) was fo,."ed. Accordingly, any memory allocated but not locked into the list of allocated memory blocks had been returned to the free list.
With reference to FIG. 8 it may be seen that the process of providing a 25 pointer to a block of memory owned by a user (or blocks of memory if repetitively invoked), in response to a user request for such pointer (again, only if the memory block collL~ g the memory had been locked into the list of allocated memory blocks) onpower up, includes the illustrative steps of: (a) looking in the used list for memory allocated by the user (step 801); and if not found (as ~letermin~l at step 802), ~ign~l lin~
30 an error (step 803), and if found"et~.l ..i..g the pointer to the memory block to the user (step 804) with the assurance that the pointer is to memory that was initi~li7~cl by the user (by virtue of the lock bit having been set and resulting in the allocated memory W 096/34337 PCTrUS96/OS730 being kept in used list following the initi~li7~ion process previously described with reference to FIG. 4).
Reference should now be made to FIG. 9 which, as indicated hereinbefore (in accordance with the te~ inp;~ of one embodiment of the invention), s depicts an exemplary set of steps for removing an entry from one list and inserting it into another list, in a manner that avoids cross linking lists.
To avoid cross linking lists (the used list and the free list), entries are always completely removed from one list before they are added to the other list.Removal from a list is one atomic instruction. Before removing an entr,v lo from a given list, Current Working Pointer 203 (in memory header 200) must point to the entry that is going to be moved. This allows the initi~ tion process contemplated by the invention (described hereinbefore with reference to FIG. 4), following a power failure, to locate this entry if power goes down in the middle of performing these functions and complete the removal operation at step 411 in FIG. 4.
Adding to a new list, according to a pler~ ,d process contemplated by the invention, requires two instructions which must be performed in the following order:
(1) The block being added must set its Pointer To Next Block (exemplified by pointer 303 in Fig. 3), to the block that will follow it in the list.
(2) The block that will precede the new block must now be set to point 20 to the new block (one atomic instruction), i.e., the Pointer To Next Block (pointer 303) in the block that will precede the new block must now be set to point to the new block With reference to FIG. 9 it may be seen that an exemplary process. of the type contemplated by the invention, for removing entry B from used list 901 and inserting it into the free list 902, involves the following steps where pointers within 25 (and/or pointers to) the lists are altered.
First (step 1), the Current Working Pointer in memory header 202is set to point to entry B (the entry to be removed) in used list 901.
Next (step 2), to remove entry B from used list 901, the Pointer To Next Block in entry A's allocated memory block header is modified (via a single atomic 30 instruction) to point to entry C instead of entry B.
The insert process (two atomic instructions) may be seen as started at step 3 in FIG. 9, where the Pointer To Next Block in entry B's allocated memory block W 096/34337 PCTrUS96/05730 _~5_ header, is modified (via the first single atomic instruction) to point to entry E instead of entry C; and (in step 4) the insertion of entry B into free list 901 is completed by modifying the Pointer To Next Block in entry D's allocated memory block header (again via the first single atomic instruction) to point to entry B instead of entry E.s It should be noted with reference to FIG. 9 that steps 2 and 3 represent the area at risk if the te~ehinp;s of the invention were not employed to ~GlroLlll the ~rorc~ led removal and insertion operation. More particularly, if Current Working Pointer 203 were not in memory header 200, entry B would get lost if power went down before completing step 4.
lo Reference should now be made to FIG. 10 which, as indicated hereinbefore (in accold~ulce with the te;~r~in~S of one embodiment of the invention), depicts an exemplary set of steps indicating how a partition pointer may be used to partition a memory block, in a manner that protects data structure integrity.
According to the ~e~rllin ~ of the invention, to avoid having incorrect block sizes, the aforernentioned Current Partition Pointer 204 is ~ in memory header 200 to point to a partition. Current Partition Pointer 204 will point to a block being coalesced or to the location in a block where a division will occur. The aforementioned Current Working Pointer (pointer 203 in FIG. 2) will already be pointing to the other block being coalesced or the block being split. These two pointers together can be used to det~rrnin~ if the header size in a block is correct.
With reference to FIG. 10 it may be seen that the exemplary process of splitting a memory block (block A shown to include 100 bytes of memory), located in free list 1001, where (at step 1 in FIG. 10) block A points to block B (shown to include 30 bytes of memory), involves the following steps:
First (step 1), the Current Working Pointer 203 in memory header 200 is shown pointing to the block selected for being split (block A). Block A is shownpointing to block B in free list 1001.
Next, in step 2, the location in block A where the block division is to occur is pointed to by Current Partition Pointer 204. The size of the exemplary block being split off(25 bytes within block A), is tleC,i~te~ as block C in FIG. 10, and an allocated memory block header (e.g., allocated memory block header 300 shown in FIG.
3), is created for the new block.

W O 96/34337 PCT~US96/05730 Step 3 in FIG. 10 shows the partitioned block (block C with 25 bytes included therein), being added to free list 1001. This is accomplished as shown at Step 3 in FIG.
10 by modifying block B's pointer to the next block in the free list to point to block C
(reç~lling free list 1001 is preferably sorted by size).
Finally, step 4 in FIG. 10 ilh.~ les that the allocated memory block header for block A needs to be modified to reflect the fact that block A has been reduced from 100 bytes to 75 bytes.
It should be noted that the Current Working pointer 203 at all times points to block A (the block that needs to be modified as shown in step 4), and that the lo Current Partition Pointer facilitated being able to safely perform the splitting operation.
In particular, with reference to FIG. 10, it may be seen that step 3 is the area at risk if the Current Partition Pointer contemplated by the invention was not used in performing the exemplary splitting operation. By the time step 3 is performed, no opportunity existed to adjust block A's (the block pointed to by the Current Working Pointer) Block Size indicator 302 in exemplary allocated memory block header 300 (it should be 75 after the split of block A into blocks A and C); however, the partitioned block (block C) has already been added to free list 1001. Since the Current Partition Pointer is in the memory header 200 contemplated by the invention, one may check(after power is restored to the recording instrument) to see if the Current Working Pointer address plus the block size (block A's block size) overlaps the address that the Current Partition Pointer points to.
Those skilled in the art will recognize that processes for coalescing memory are essentially the inverse of any process used for splitting memory. According to the invention, the partitions must be deleted from the free list in the same manner as when moving from one list to another.
What has been described in detail hereinabove are methods and a~p~dL~ls which meet all of the afol~. aL~led objectives. As previously indicated, those skilled in the art will recognize that the foregoing description has been presented for the sake of illustration and description only. It is not inten-le~ to be exhaustive or to limit the invention to the precise form disclosed, and obviously many modifications and variations are possible in light of the above te~q~hing W 096/34337 PCT/Ub~G,'0~730 - l~e embo~imlont.~ and examples set forth herein were presented in order to best explain the principles of the instant invention and its practical application to thereby enable others skilled in the art to best utilize the instant invention in various embodiments and with various modifications as are suited to the particular use s contemplated.
In view of the above it is, therefore, to be understood that the clairns appended hereto are int~.n-led to cover all such modifications and variations which fall within the true scope and spirit of the invention.
What is claimed is:

Claims (19)

1. A method for performing heap management and protecting the integrity of data structures created and stored in non-volatile memory (101) included in a programmable recording instrument (100) used for recording process data, the method characterised by the steps of:
(a) defining a memory header data structure used for managing run time memory operations and aiding in the recovery of any data structures being modified when and if power to the instrument is lost, wherein said memory header (200) includes a first pointer (206) to a list of free memory blocks and a second pointer (205) to a list of allocated memory blocks;
(b) defining an allocated memory block header (300), stored within each allocated memory block, used for determining block attributes, including an indicator to signal when a given memory block has been locked into said list of allocated memory blocks, a block ownership indicator and a pointer to the next allocated memory block, if any;
(c) initializing said non-volatile memory whenever the recording instrument is powered up, including the steps of determining if said non-volatile memory is to be reset and the step of verifying the stability of non-volatile memory whenever non-volatile memory is not reset;
(d) allocating memory from one of the memory blocks included in said list of free memory blocks, in response to a user request for memory allocation, utilizing only atomic instructions to modify said memory header and said allocated memory block header; and (e) locking an allocated memory block into said list of allocated memory blocks in response to a user request for the lock, initialising the block and setting the lock indicator with atomic instructions.
2. A method according to Claim 1 characterised by freeing a memory block included in said list of allocated memory blocks, in response to a user request for freeing memory, utilizing only atomic instructions to modify said memory header and said allocated memory block header.
3. A method according to Claim 1 or 2 characterised:-(a) completely removing an entry said list of free memory blocks prior to adding said entry to said list of allocated memory blocks when performing said step of allocating memory; and (b) completely removing an entry said list of allocated memory blocks prior to adding said entry to said list of free memory blocks, when performing said step of freeing a memory block, to thereby avoid cross-linking lists when allocating memory and/or freeing a memory block.
4. A method according to any preceding Claim characterised in that said step of locking further comprises the steps of:
(a) receiving a user specified pointer to memory included in a given memory block;
(b) determining if the given memory block is in said list of allocated memory blocks; and (c) setting the indicator in the allocated memory block header associated with said given memory block to indicate that said given memory block has been locked into said list of allocated memory blocks.
5. A method according to any preceding Claim characterised by providing a pointer to a block of memory owned by a user, in response to a user request for such pointer, only if the memory block containing said memory has been locked into said list of allocated memory blocks.
6. A method according to any preceding Claim characterised in that said step of defining a memory header further comprises the step of including within said memory header (200) (a) an indicator (201) used to determine if non-volatile memory has been initialized; (b) a current working pointer (203) to a block of memory that is being allocated or freed; (c) a current partition pointer (204) to a block of memory that will be split off from a larger block of memory or will be coalesced with another block of memory; and (d) a state indicator (207) used to determine the stability of non-volatile memory upon recovery from a power loss.
7. A method according to any preceding Claim characterised in that the step of defining a memory header comprises the step of including within said memory header a timestamp (202) that is updated at a fixed interval, wherein said time stamp is used to determine how long power was off during a power failure.
8. A method according to any preceding Claim characterised in that said step of defining an allocated memory block header comprises the step of including within said allocated memory block header (300) (a) an allocated memory block size indicator (302); (b) a block size adjustment indicator (305) which is used to determine the actual size of the user memory allocation request; and (c) the actual set of memory locations (306)allocated to the user.
9. A method according to any preceding Claim characterised in that said step of determining if said non-volatile memory is to be reset further comprises the step of determining the validity of said indicator (207) used to determine if non-volatile memory has been initialized.
10. A method according to any preceding Claim characterised by whenever it is determined that said non-volatile memory is to be reset, (a) performing a non-volatile memory hardware integrity test;
(b) clearing non-volatile memory, wherein said step of clearing includes the steps initializing said memory header data structure and said allocated memory block header, and setting said indicator (207) used to determine if non-volatile memory has been initialized to indicate that initialization has occurred.
11. A method according to any preceding Claim characterised by a step of verifying the stability of non-volatile memory comprising:-(a) examining said state indicator (207) to determine non-volatile memory stability therefrom;
(b) completing any operation in progress at the time of a power loss that affects non-volatile memory stability whenever it is determined that said non-volatile memory is unstable; and (c) removing all allocated memory blocks not previously locked into said list of allocated memory blocks, returning the unlocked allocated blocks to said free list.
12. A method according to any preceding Claim characterised by a said step of allocating comprises the steps of:
(a) searching said list of free memory blocks for a block of memory to allocate;
(b) determining, whenever a block of memory to allocate is found, if the memory block found is larger than needed;
(c) removing said memory block found from said free list if it is not larger than needed;
(d) splitting the memory block found, if larger than needed, into a first block portion for allocation and a second block portion for return to said free list;
(e) returning said second block portion to said free list whenever said second block portion is created;
(f) removing said first block portion from said free list whenever said second block portion is created; and (g) adding the properly sized block being allocated to said list of allocated memory blocks.
13. A method according to any preceding Claim characterised by a step of freeing a memory bank comprises the steps of:
(a) searching said list of allocated memory blocks for the memory block being freed;
(b) removing said memory block being freed from said list of allocated memory blocks;
(c) determining if said block being freed can be coalesced with another free block in said list of free memory blocks;
(d) joining the free blocks together whenever it is determined that at least two free memory blocks may be coalesced; and (e) adding the freed block, as extended by any joining performed in step (d), to said list of free memory blocks.
14. A method according to Claim 13 characterised in that said step of adding the freed block to said list of free memory blocks further comprises the step of sorting said list of free memory blocks based on block size.
15. Apparatus for performing heap management and protecting the integrity of data structures created and stored in non-volatile memory included in a programmable recording instrument (100) used for recording process data, the apparatus characterised by:
(a) programmable data processing means (102), including (a1) means for initializing non-volatile memory (101) used for at least temporarily storing process data;
(a2) means for allocating memory blocks upon request;
(a3) means for freeing allocated memory upon request;
(a4) means for locking data blocks into a list of allocated memory blocks upon request; and (a5) means for obtaining and returning pointers to previously locked allocated blocks of memory upon request following a restoration of power to said instrument; and (b) the non-volatile memory means, for coupling to said programmable data processing means, and for at least temporarily storing process data received and/or derived by said instrument, includes a memory header data structure used for managing run time operations and for aiding in the recovery of any data structures being modified when and if power to the instrument is lost, and an allocated memory block header (300), stored within each allocated memory block, used for determining block attributes, including an indicator to signal when a given memory block has been locked into said list of allocated memory blocks, a block ownership indicator and a pointer to the next allocated memory block in said list of allocated memory blocks, if any, wherein the contents of said memory header data structure and said allocated memory block header may only be modified utilizing atomic instructions.
16. Apparatus according to Claim 16 characterised in that said memory header data structure further comprises:
(a) a first pointer to a list of free memory blocks in said non-volatile memory;
(b) a second pointer (205) to a list of allocated memory blocks in said non-volatile memory;
(c) an indicator (201) used to determine if non-volatile memory has been initialized;
(d) a current working pointer (203) to a block of memory that is being allocated or freed;
(e) a current partition pointer (204) to a block of memory that will be split off from a larger block of memory or will be coalesced with another block of memory; and (f) a state indicator (207) used to determine the stability of non-volatile memory upon recovery from a power loss.
17. Apparatus according to Claim 15 or 16 characterised in that said memory header data structure further comprises a time stamp (202) that is updated at a fixed interval, wherein said time stamp is used to determine how long power was off during a power failure.
18. Apparatus according to any of Claims 15 to 17 characterised in that said non-volatile memory is capacitor backed random access memory.
19. Apparatus according to any of Claims 15 to 18 characterised in that said allocated memory block header further comprises:
(a) an allocated memory block size indicator (302);
(b) a block size adjustment indicator (305) which is used to determine the actual size of the user memory allocation request; and (c) the actual set of memory locations allocated to the user.
CA002214648A 1995-04-26 1996-04-24 Methods and apparatus for performing heap management and protecting data structure integrity in non-volatile memory Abandoned CA2214648A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/429,346 1995-04-26
US08/429,346 US5625819A (en) 1995-04-26 1995-04-26 Methods and apparatus for performing heap management and protecting data structure integrity in non-volatile memory

Publications (1)

Publication Number Publication Date
CA2214648A1 true CA2214648A1 (en) 1996-10-31

Family

ID=23702850

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002214648A Abandoned CA2214648A1 (en) 1995-04-26 1996-04-24 Methods and apparatus for performing heap management and protecting data structure integrity in non-volatile memory

Country Status (7)

Country Link
US (1) US5625819A (en)
EP (1) EP0823087B1 (en)
JP (1) JPH11511878A (en)
AU (1) AU711846B2 (en)
CA (1) CA2214648A1 (en)
DE (1) DE69603180T2 (en)
WO (1) WO1996034337A1 (en)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2308471B (en) * 1995-12-22 1999-10-20 Nokia Mobile Phones Ltd Memory defragmentation
KR980013092A (en) 1996-07-29 1998-04-30 김광호 File management apparatus and method of exchange system
KR100260028B1 (en) * 1996-08-13 2000-06-15 윤종용 Data recovery method in a file system
US5950231A (en) * 1996-11-25 1999-09-07 Northern Telecom Limited Memory manager system
US6311290B1 (en) * 1997-02-14 2001-10-30 Intel Corporation Methods of reliably allocating, de-allocating, re-allocating, and reclaiming objects in a symmetrically blocked nonvolatile memory having a bifurcated storage architecture
US6182188B1 (en) * 1997-04-06 2001-01-30 Intel Corporation Method of performing reliable updates in a symmetrically blocked nonvolatile memory having a bifurcated storage architecture
US6065019A (en) * 1997-10-20 2000-05-16 International Business Machines Corporation Method and apparatus for allocating and freeing storage utilizing multiple tiers of storage organization
KR100303280B1 (en) 1997-12-26 2001-11-22 윤종용 Power supply for computer system
US6012063A (en) * 1998-03-04 2000-01-04 Starfish Software, Inc. Block file system for minimal incremental data transfer between computing devices
US6070202A (en) * 1998-05-11 2000-05-30 Motorola, Inc. Reallocation of pools of fixed size buffers based on metrics collected for maximum number of concurrent requests for each distinct memory size
US6314489B1 (en) * 1998-07-10 2001-11-06 Nortel Networks Limited Methods and systems for storing cell data using a bank of cell buffers
DE19831516A1 (en) * 1998-07-14 2000-01-20 Alcatel Sa Method for operating a server and server and control unit
US7111141B2 (en) * 2000-10-17 2006-09-19 Igt Dynamic NV-RAM
US6804763B1 (en) * 2000-10-17 2004-10-12 Igt High performance battery backed ram interface
US8550922B2 (en) 2006-03-03 2013-10-08 Igt Game removal with game history
US6757802B2 (en) * 2001-04-03 2004-06-29 P-Cube Ltd. Method for memory heap and buddy system management for service aware networks
US20030159471A1 (en) * 2002-02-27 2003-08-28 Wamin Optocomm Mfg. Corporation Method for fabricating fiber optic joints
US7392361B2 (en) * 2002-04-16 2008-06-24 Emc Corporation Generic reallocation function for heap reconstitution in a multi-processor shared memory environment
US6766432B2 (en) * 2002-05-24 2004-07-20 Sun Microsystems, Inc. Memory management system supporting object deletion in non-volatile memory
US8060680B2 (en) * 2002-09-16 2011-11-15 Hewlett-Packard Development Company, L.P. Method of allocating memory
US7849444B2 (en) * 2004-12-21 2010-12-07 National Instruments Corporation Test executive with buffer overwrite detection for parameters of user-supplied code modules
US7519867B2 (en) * 2004-12-21 2009-04-14 National Instruments Corporation Test executive which provides heap validity checking and memory leak detection for user code modules
US7406476B1 (en) * 2005-04-04 2008-07-29 Apple Inc. Updating a data structure
US20070150645A1 (en) * 2005-12-28 2007-06-28 Intel Corporation Method, system and apparatus for power loss recovery to enable fast erase time
US7951008B2 (en) * 2006-03-03 2011-05-31 Igt Non-volatile memory management technique implemented in a gaming machine
US9767676B2 (en) * 2012-01-11 2017-09-19 Honeywell International Inc. Security system storage of persistent data
US9443107B2 (en) * 2013-02-19 2016-09-13 Qualcomm Incorporated Method for protecting the integrity of a group of memory elements using an aggregate authentication code
US10025669B2 (en) 2014-12-23 2018-07-17 Nuvoton Technology Corporation Maintaining data-set coherency in non-volatile memory across power interruptions
US10860709B2 (en) 2018-06-29 2020-12-08 Intel Corporation Encoded inline capabilities
US20230289075A1 (en) * 2022-03-14 2023-09-14 Western Digital Technologies, Inc. Data Storage Device and Method for Host-Initiated Transactional Handling for Large Data Set Atomicity Across Multiple Memory Commands

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4814971A (en) * 1985-09-11 1989-03-21 Texas Instruments Incorporated Virtual memory recovery system using persistent roots for selective garbage collection and sibling page timestamping for defining checkpoint state
US4845632A (en) * 1985-10-16 1989-07-04 Pitney Bowes Inc. Electonic postage meter system having arrangement for rapid storage of critical postage accounting data in plural nonvolatile memories
US5021963A (en) * 1988-12-30 1991-06-04 Pitney Bowes Inc. EPM having an improvement in accounting update security
US5088036A (en) * 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
US5317752A (en) * 1989-12-22 1994-05-31 Tandem Computers Incorporated Fault-tolerant computer system with auto-restart after power-fall
US5634000A (en) * 1991-07-31 1997-05-27 Ascom Autelca Ag Power-fail return loop
US5367637A (en) * 1992-03-26 1994-11-22 International Business Machines Corporation Self-tuning virtual storage management for dedicated real-time computer system
US5491808A (en) * 1992-09-30 1996-02-13 Conner Peripherals, Inc. Method for tracking memory allocation in network file server

Also Published As

Publication number Publication date
AU5573096A (en) 1996-11-18
US5625819A (en) 1997-04-29
EP0823087A1 (en) 1998-02-11
DE69603180D1 (en) 1999-08-12
AU711846B2 (en) 1999-10-21
EP0823087B1 (en) 1999-07-07
WO1996034337A1 (en) 1996-10-31
DE69603180T2 (en) 1999-12-23
JPH11511878A (en) 1999-10-12

Similar Documents

Publication Publication Date Title
CA2214648A1 (en) Methods and apparatus for performing heap management and protecting data structure integrity in non-volatile memory
US6311290B1 (en) Methods of reliably allocating, de-allocating, re-allocating, and reclaiming objects in a symmetrically blocked nonvolatile memory having a bifurcated storage architecture
US7707555B2 (en) Interactive debugging system with debug data base system
US6622200B1 (en) Method of performing reliable updates in a symmetrically blocked nonvolatile memory having a bifurcated storage architecture
US7000225B2 (en) Method for inserting global breakpoints
US7827375B2 (en) Defensive heap memory management
US7127642B2 (en) System and method for self-diagnosing system crashes
US6618735B1 (en) System and method for protecting shared system files
EP1172729B1 (en) Apparatus and method for cataloguing symbolic data for use in performance analysis of computer programs
US5355469A (en) Method for detecting program errors
US10949342B2 (en) Persistent memory garbage collection
US7512765B2 (en) System and method for auditing memory
US20060288341A1 (en) Patch-impact assessment through runtime insertion of code path instrumentation
US20100125554A1 (en) Memory Recovery Across Reboots of an Emulated Operating System
CA2426619A1 (en) Defensive heap memory management
US7308547B2 (en) Apparatus and method for control of write filter
US7096339B2 (en) System and method for detecting memory management programming errors
US11934680B2 (en) Systems and methods for booting from NAND flash using squashfs to maximize memory
US10185653B2 (en) Integrated systems and methods for the transactional management of main memory and data storage
EP1423792A2 (en) Interactive debugging system with debug data base system
CN106874770B (en) Firmware guiding method and device for currency detector
KR20030044319A (en) Debugging method of memory allocation and deallocation for real-time operating system
Fraser Software Fault Isolation: a first step towards Microreboot in legacy C applications
JPS6237418B2 (en)

Legal Events

Date Code Title Description
EEER Examination request
FZDE Discontinued