{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}



Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
78 Declarative Computation Model There exist garbage collection algorithms, called real-time garbage collectors, that can run continuously, interleaved with the program execution. They can be used in cases, such as hard real-time programming, in which there must not be any pauses. Garbage collection is not magic Having garbage collection lightens the burden of memory management for the developer, but it does not eliminate it completely. There are two cases that remain the developer’s responsibility: avoiding memory leaks and managing external resources. Avoiding memory leaks It is the programmer’s responsibility to avoid mem- ory leaks. If the program continues to reference a data structure that it no longer needs, then that data structure’s memory will never be recovered. The program should be careful to lose all references to data structures no longer needed. For example, take a recursive function that traverses a list. If the list’s head is passed to the recursive call, then list memory will not be recovered during the function’s execution. Here is an example: L=[1 2 3 ... 1000000] fun {Sum X L1 L} case L1 of Y|L2 then {Sum X+Y L2 L} else X end end {Browse {Sum 0 L L}} Sum sums the elements of a list. But it also keeps a reference to L , the original list, even though it does not need L . This means L will stay in memory during the whole execution of Sum . A better definition is as follows: fun {Sum X L1} case L1 of Y|L2 then {Sum X+Y L2} else X end end {Browse {Sum 0 L}} Here the reference to L is lost immediately. This example is trivial. But things can be more subtle. For example, consider an active data structure S that contains a list of other data structures D1 , D2 , ..., Dn . If one of these, say Di , is no longer needed by the program, then it should be removed from the list. Otherwise its memory will never be recovered. A well-written program therefore has to do some “cleanup” after itself: making sure that it no longer references data structures that it no longer needs. The Copyright c 2001-3 by P. Van Roy and S. Haridi. All rights reserved.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
2.4 Kernel language semantics 79 cleanup can be done in the declarative model, but it is cumbersome. 9 Managing external resources A Mozart program often needs data structures that are external to its operating system process. We call such a data structure an external resource . External resources affect memory management in two ways. An internal Mozart data structure can refer to an external resource and vice versa. Both possibilities need some programmer intervention. Let us consider each case separately. The first case is when a Mozart data structure refers to an external resource. For example, a record can correspond to a graphic entity in a graphics display or to an open file in a file system. If the record is no longer needed, then the graphic entity has to be removed or the file has to be closed. Otherwise, the graphics display or the file system will have a memory leak. This is done with a technique called finalization
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page1 / 30


This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon bookmark
Ask a homework question - tutors are online