Java Reference
In-Depth Information
}
}
}
The finalizer guardian forces
super.finalize
to be called if a subclass overrides
finalize
and does not explicitly call
super.finalize
.
If these optimizations are allowed for references that are stored on the heap, then a
Java compiler can detect that the
finalizerGuardian
field is never read, null it out, collect
the object immediately, and call the finalizer early. This runs counter to the intent: the
programmer probably wanted to call the
Foo
finalizer when the
Foo
instance became
unreachable. This sort of transformation is therefore not legal: the inner class object
should be reachable for as long as the outer class object is reachable.
Transformations of this sort may result in invocations of the
finalize
method occurring
earlier than might be otherwise expected. In order to allow the user to prevent this,
we enforce the notion that synchronization may keep the object alive.
If an object's
finalizer can result in synchronization on that object, then that object must be alive
and considered reachable whenever a lock is held on it.
Note that this does not prevent synchronization elimination: synchronization only
keeps an object alive if a finalizer might synchronize on it. Since the finalizer occurs
in another thread, in many cases the synchronization could not be removed anyway.
12.6.2. Interaction with the Memory Model
It must be possible for the memory model (§
17.4
) to decide when it can commit actions
that take place in a finalizer. This section describes the interaction of finalization with the
memory model.
Each execution has a number of
reachability decision points
, labeled
di
. Each action either
comes-before di
or
comes-after di
. Other than as explicitly mentioned, the comes-before
ordering described in this section is unrelated to all other orderings in the memory model.
If
r
is a read that sees a write
w
and
r
comes-before
di
, then
w
must come-before
di
.
If
x
and
y
are synchronization actions on the same variable or monitor such that
so(x, y)
At each reachability decision point, some set of objects are marked as unreachable, and
some subset of those objects are marked as finalizable. These reachability decision points
are also the points at which references are checked, enqueued, and cleared according to the
rules provided in the API documentation for the package
java.lang.ref
.
