Memory Management Clause Samples
Memory Management. The code generation platform on which the C code generator is based was originally designed to target languages with implicit memory management, such as Java. In the context of C, this poses great difficulty in explicitly freeing allocated memory. For example, the VDM expression 1 + 2 + 3 , \z r translates to the following, independent of context: vdmSum( newInt ( 1 ) , vdmSum( newInt ( 2 ) , newInt ( 3 ) ) ) , \z r Because none of the intermediate values are assigned to TVP variables, none of the memory allocated here can be accessed and freed once the outer invo- cation of vdmSum() terminates. This is only a simple illustrative example of the difficulty in dealing with allocated memory explicitly. We solve this problem using a bespoke garbage collection (GC) strategy that is meant to obviate the need for explicit calls to vdmFree() anywhere in the generated code. All functions that allocate memory on the heap have corresponding GC-aware versions, such that intermediate values allocated as in the example above can be reclaimed in bulk with a call to the GC when it is known to be safe to do so. The garbage collector is kept simple by the specific structure of models in INTO-CPS. Due to the FMI approach of stepping simulations, an FMI step corresponds, in the VDM world, to one execution of a periodic task. It is known that all variables that are allocated during one execution either update class fields, which are not subject to garbage collection by design, or are otherwise intermediate. In this pattern of execution it is natural to invoke the garbage collector each time the periodic task has finished executing. The time and memory performance of this prototype garbage collection strat- egy has been summarily assessed using the VDM model shown in Listing 20. val : int ; public Co l la tz : int ==> Co l la tz Co l la tz ( v ) == val := v ; public run : ( ) ==> ( ) run () == i f val = 1 then return
Memory Management. The operating system shall provide state-of-the-art algorithms for management of virtual memory segments, cache memory, commonly accessible installed program images, and memory defragmentation.
Memory Management. Currently the code generator attempts to manage memory usage by emit- ting calls to vdmFree() based on the role of new TVP variables. The level of abstraction of VDM-RT from which the code generation process starts means that the strategies for freeing all allocated TVP values are difficult to implement. For example, the VDM expression 1 + 2 currently translates to the following, independent of context: vdmSum( newInt ( 1 ) , vdmSum( newInt ( 2 ) , newInt ( 3 ) ) ) Because none of the intermediate values are assigned to TVP variables, none of the memory allocated here can be accessed and freed once the outer invo- cation of vdmSum() terminates. This is only a simple illustrative example of the difficulty in dealing with allocated memory explicitly. Work is ongoing to implement memory freeing strategies such that memory allocated as in this example can be freed at the appropriate place with corresponding calls to vdmFree(). A parallel effort aims to develop a garbage collection strategy that is meant to obviate the need for explicit calls to vdmFree() anywhere in the generated code. All functions that allocate memory on the heap have been modified to accept the address of the memory location from which the allocated memory is referenced (a pointer to TVP). A table is kept recording the relationship between these two locations. When allocating intermediate memory as in the example above, a null pointer is passed indicating that this memory is safe to reclaim once the containing statement has finished executing. When the memory reclamation mechanism is executed, the value at each referencing location is checked against the corresponding address held in the allocation table. If these are not the same, then the memory in question can no longer be accessed from the corresponding location, and a call to vdmFree() is executed on it. If these values are the same then it is assumed that the reference is still in some scope, and therefore the memory referenced by it is still in use. The problem of variable scoping is handled based on the assumption that the evolution of the call stack will eventually overwrite local variables holding references to allocated memory. For example, assume that a function allocates a newInt() to variable ni. The variable ni is allocated on the call stack. The garbage collector is passed the address of ni through the call to newInt(). When the function exits, the stack pointer is modified such that the next function invocation will make us...