<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<blockquote type="cite" cite="mid:CANSoFxuFidOo2U93bu0tOjKHuz5=XuZ8NV7VWbxOkiQ0USfg-w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>First of all, when should this rule apply?</div>
<div><br>
</div>
<div>At any point in a constructor (one that successfully
compiles), the new object is always definitively in one of
three states:<br>
</div>
<div>
<div><br>
</div>
<div>State 0: neither <span style="font-family:monospace">super()</span>
nor <span style="font-family:monospace">this()</span> has
been invoked; neither the superclass nor this class are
initialized</div>
<div>State 1: <span style="font-family:monospace">super()</span>
has been invoked, so the superclass is initialized, but at
least one final field in this class has not been
initialized<br>
</div>
<div>State 2: <span style="font-family:monospace">super()</span>
has been invoked and all final fields in this class have
been initialized</div>
<div><br>
</div>
<div>BTW, the current state is easily tracked within the
existing DA/DU analysis of the prototype patch.<br>
</div>
<div><br>
</div>
<div>The possible state transitions are:</div>
<div><br>
</div>
<div>- <span style="font-family:monospace">super()</span>
takes you from:</div>
<div> - State 0 → State 1 if there remain any uninitialized
final fields</div>
<div> - State 0 → State 2 if there are no remaining
uninitialized final fields</div>
<div>- <span style="font-family:monospace">this()</span>
takes you from State 0 → State 2</div>
<div>- Initializing the last final field takes you from:</div>
<div>
<div> - State 0 → State 0<br>
</div>
<div> - State 1 → State 2</div>
<div><br>
</div>
<div>Presumably the 'this' escape analysis should only
apply in State 1. This is when the object is vulnerable
because it's half initialized.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
In actuality, `this` can escape in any of the states; escaping means
that `this` is exposed before the return from the constructor.
(Even the very last line of the constructor is suspect. A class
could have subclasses, which means we're still in "the middle" of
the subclass constructor, and even for a final class, the write
barrier does not get emitted until after the constructor
completes.) <br>
<br>
All of this said, we should probably tune warnings to the various
states, since escape during State 0 is "even worse" than escape
during State 2. And we should add: <br>
<br>
State 3: we're still in the constructor<br>
<br>
In any case, let's start with the strictest view and work backwards
to relaxation. The receiver may escape if:<br>
<br>
- a non-final instance method is invoked (*)<br>
- an instance method declared in a superclass is invoked<br>
- the variable `this` is used for anything other than field access
<br>
<br>
We should analyze not only constructor code, but instance
initializer blocks and instance field initializers as well. We can
exclude final instance methods declared in the same class if the
same analysis of the method (recursively) shows no escape of `this`
(this is the * in the first bullet above.) <br>
<br>
Inner class creation is a similar story as calling final methods in
the same class; we can do a similar analysis of the inner class
constructor to verify non-escape. <br>
<br>
<blockquote type="cite" cite="mid:CANSoFxuFidOo2U93bu0tOjKHuz5=XuZ8NV7VWbxOkiQ0USfg-w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">For the meaning of "known to be equal
to 'this'", we would be limited in our ability to infer it in
the usual ways (Turing complete, blah blah), so you'd still be
able to evade the warning e.g.:<br>
</div>
</div>
</blockquote>
<br>
For this to happen, `this` must have already escaped or have been
assigned to another variable. The above already detects this.<br>
<br>
<br>
</body>
</html>