Java Reference
In-Depth Information
Handle
Memory Block
Figure12.15
Using handles for dynamic memory management. The memory
manager returns the address of the handle in response to a memory request. The
handle stores the address of the actual memory block. In this way, the memory
block might be moved (with its address updated in the handle) without disrupting
the application program.
memory manager, it might be possible to get more memory from the system-level
new
operator, such as is done by the freelist of Section 4.1.2.
The last failure policy that we will consider is garbage collection. Consider
the following series of statements.
int[]p=newint[5];
int[]q=newint[10];
p=q;
While in Java this would be no problem (due to automatic garbage collection), in
languages such as C
++
, this would be considered bad form because the original
space allocated to
p
is lost as a result of the third assignment. This space cannot
be used again by the program. Such lost memory is referred to as garbage, also
known as a memory leak. When no program variable points to a block of space,
no future access to that space is possible. Of course, if another variable had first
been assigned to point to
p
's space, then reassigning
p
would not create garbage.
Some programming languages take a different view towards garbage. In par-
ticular, the LISP programming language uses the multilist representation of Fig-
ure 12.5, and all storage is in the form either of internal nodes with two pointers
or atoms. Figure 12.16 shows a typical collection of LISP structures, headed by
variables named A, B, and C, along with a freelist.
In LISP, list objects are constantly being put together in various ways as tem-
porary variables, and then all reference to them is lost when the object is no longer
needed. Thus, garbage is normal in LISP, and in fact cannot be avoided during
routine program behavior. When LISP runs out of memory, it resorts to a garbage
collection process to recover the space tied up in garbage. Garbage collection con-
sists of examining the managed memory pool to determine which parts are still
being used and which parts are garbage. In particular, a list is kept of all program
variables, and any memory locations not reachable from one of these variables are
considered to be garbage. When the garbage collector executes, all unused memory
locations are placed in free store for future access. This approach has the advantage
that it allows for easy collection of garbage. It has the disadvantage, from a user's
