| This pass implements dataflow analysis for Java programs.
Liveness analysis checks that every statement is reachable.
Exception analysis ensures that every checked exception that is
thrown is declared or caught. Definite assignment analysis
ensures that each variable is assigned when used. Definite
unassignment analysis ensures that no final variable is assigned
more than once.
The second edition of the JLS has a number of problems in the
specification of these flow analysis problems. This implementation
attempts to address those issues.
First, there is no accommodation for a finally clause that cannot
complete normally. For liveness analysis, an intervening finally
clause can cause a break, continue, or return not to reach its
target. For exception analysis, an intervening finally clause can
cause any exception to be "caught". For DA/DU analysis, the finally
clause can prevent a transfer of control from propagating DA/DU
state to the target. In addition, code in the finally clause can
affect the DA/DU status of variables.
For try statements, we introduce the idea of a variable being
definitely unassigned "everywhere" in a block. A variable V is
"unassigned everywhere" in a block iff it is unassigned at the
beginning of the block and there is no reachable assignment to V
in the block. An assignment V=e is reachable iff V is not DA
after e. Then we can say that V is DU at the beginning of the
catch block iff V is DU everywhere in the try block. Similarly, V
is DU at the beginning of the finally block iff V is DU everywhere
in the try block and in every catch block. Specifically, the
following bullet is added to 16.2.2
V is unassigned everywhere in a block if it is
unassigned before the block and there is no reachable
assignment to V within the block.
In 16.2.15, the third bullet (and all of its sub-bullets) for all
try blocks is changed to
V is definitely unassigned before a catch block iff V is
definitely unassigned everywhere in the try block.
The last bullet (and all of its sub-bullets) for try blocks that
have a finally block is changed to
V is definitely unassigned before the finally block iff
V is definitely unassigned everywhere in the try block
and everywhere in each catch block of the try statement.
In addition,
V is definitely assigned at the end of a constructor iff
V is definitely assigned after the block that is the body
of the constructor and V is definitely assigned at every
return that can return from the constructor.
In addition, each continue statement with the loop as its target
is treated as a jump to the end of the loop body, and "intervening"
finally clauses are treated as follows: V is DA "due to the
continue" iff V is DA before the continue statement or V is DA at
the end of any intervening finally block. V is DU "due to the
continue" iff any intervening finally cannot complete normally or V
is DU at the end of every intervening finally block. This "due to
the continue" concept is then used in the spec for the loops.
Similarly, break statements must consider intervening finally
blocks. For liveness analysis, a break statement for which any
intervening finally cannot complete normally is not considered to
cause the target statement to be able to complete normally. Then
we say V is DA "due to the break" iff V is DA before the break or
V is DA at the end of any intervening finally block. V is DU "due
to the break" iff any intervening finally cannot complete normally
or V is DU at the break and at the end of every intervening
finally block. (I suspect this latter condition can be
simplified.) This "due to the break" is then used in the spec for
all statements that can be "broken".
The return statement is treated similarly. V is DA "due to a
return statement" iff V is DA before the return statement or V is
DA at the end of any intervening finally block. Note that we
don't have to worry about the return expression because this
concept is only used for construcrors.
There is no spec in JLS2 for when a variable is definitely
assigned at the end of a constructor, which is needed for final
fields (8.3.1.2). We implement the rule that V is DA at the end
of the constructor iff it is DA and the end of the body of the
constructor and V is DA "due to" every return of the constructor.
Intervening finally blocks similarly affect exception analysis. An
intervening finally that cannot complete normally allows us to ignore
an otherwise uncaught exception.
To implement the semantics of intervening finally clauses, all
nonlocal transfers (break, continue, return, throw, method call that
can throw a checked exception, and a constructor invocation that can
thrown a checked exception) are recorded in a queue, and removed
from the queue when we complete processing the target of the
nonlocal transfer. This allows us to modify the queue in accordance
with the above rules when we encounter a finally clause. The only
exception to this [no pun intended] is that checked exceptions that
are known to be caught or declared to be caught in the enclosing
method are not recorded in the queue, but instead are recorded in a
global variable "Set thrown" that records the type of all
exceptions that can be thrown.
Other minor issues the treatment of members of other classes
(always considered DA except that within an anonymous class
constructor, where DA status from the enclosing scope is
preserved), treatment of the case expression (V is DA before the
case expression iff V is DA after the switch expression),
treatment of variables declared in a switch block (the implied
DA/DU status after the switch expression is DU and not DA for
variables defined in a switch block), the treatment of boolean ?:
expressions (The JLS rules only handle b and c non-boolean; the
new rule is that if b and c are boolean valued, then V is
(un)assigned after a?b:c when true/false iff V is (un)assigned
after b when true/false and V is (un)assigned after c when
true/false).
There is the remaining question of what syntactic forms constitute a
reference to a variable. It is conventional to allow this.x on the
left-hand-side to initialize a final instance field named x, yet
this.x isn't considered a "use" when appearing on a right-hand-side
in most implementations. Should parentheses affect what is
considered a variable reference? The simplest rule would be to
allow unqualified forms only, parentheses optional, and phase out
support for assigning to a final field via this.x.
This is NOT part of any API supported by Sun Microsystems. If
you write code that depends on this, you do so at your own risk.
This code and its internal interfaces are subject to change or
deletion without notice.
| 