Java Reference
In-Depth Information
statements (like new or malloc) specify in which region an object is to be
allocated. Typically, regions are organized in a stack and have lexically scoped
lifetimes. In this respect, region-based memory management can be similar to
stack allocation. However, regions are more flexible than frames because it is
possible to allocate an object into a region other than the region on top of the
stack.
As an example, consider three procedures,
A
,
B
,and
C
. Each procedure
begins by creating a new region and ends by destroying that region.
A
calls
B
and
B
calls
C
. It is possible for
C
to allocate an object in the region created
by
A
. As a consequence, this object will be available during the lifetimes of
C
,
B
,and
A
, but it will be deallocated just before
A
returns, when
A
destroys its
region.
Because themaximumlifetime of anobject is essentiallydecided at compile-
time based on the region in which it is allocated, region-based memory man-
agement need not stop the program to identify garbage objects. In addition,
because entire regions are deallocated at once, region-based memory man-
agement can perform many individual deallocations in essentially constant
time and limit the sort of heap fragmentation possible under other manual
or automatic heap management approaches. However, region-based memory
management requires that the input program is annotated with region cre-
ation and destruction operations, and that object allocations include a region
parameter.
It is trivial to generate region annotations that are merely correct; one need
only create a single region at the beginning of the program, allocate every
object in this region, and destroy this region before the program terminates.
However, such a program would hardly use memory e
ciently. Statically
identifying region annotations that are correct and waste as little memory
as possible is a much trickier problem. E
ff
ective programming with explicit
regions would thus be quite di
cult (not to mention tedious). Furthermore,
leaving region management to the programmer would enable him or her to
introduce dangling pointer errors by deallocating a region when an object
contained within it is still live.
Fortunately, systems that support region-basedmemorymanagement typ-
ically generate region annotations automatically. In order to do this, compilers
include an analysis called
region inference
, which determines where to place
region creation and destruction operations as well as which regions should
hold particular objects. Like all sound static analyses, region inference is
con-
servative
in that it may not identify the region annotations that correspond to
the best possible use of memory. However, region inference is guaranteed to
be safe, in that the region annotations it identifies will never result in dangling
pointers or other runtime memory errors.
Region inference analyses and region-based memory managers typically
require languages with strong type systems that are relatively easy to analyze
