On Thu, 12 Jan 2023 00:15:08 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org>
wrote:
> So, for static methods, it could go down two ways: either we don't even look
> at referenced method bodies, give up and just declare "sorry, escaping". Or,
> if we look into method bodies, and see that the relationship between inner
> and outer parameter is as simple, it's just like assignment again:
Right - and just to reconfirm, it's only the non-overridable methods in the
same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method
that (might) exist in another compilation unit is off limits, so we have to
assume the worst case and declare a leak if we are passing it any 'this'
references.
> in order to try and build a mental problem of what the problem that needs to
> be solved is
Gotcha.
Let's be clear about what exactly we're worrying about. It's this situation:
You have a class `B extends A`, where `B` and `A` are in different compilation
units, and during the `super()` call that constructor `B()` makes to its
superclass constructor `A()`, some code in class `B` gets executed (really,
it's some field in `B` getting accessed that actually matters) prior to `A()`
returning.
So the basic goal is to analyze `A` constructors and watch 'this' references
until if/when they go to someplace where we can no longer watch them. At that
point we have to assume that some code in `B` might get invoked and so we
generate a warning.
OK, so where can a 'this' reference go?
Well, here are all of the possible places a Java reference can exist:
1. On the Java stack
(a) The current 'this' instance
(b) A method parameter
(c) A local variable
(d) A temporary value that is part of the current expression being evaluated
(e) The return value from a method that just returned
(f) A caught exception
1. In a field of some object...
(a) A normal field
(b) An outer 'this' instance
(c) Other synthetic field (e.g., captured free variable)
1. As an element in a reference array
1. In native code as a native reference
Those are the only possibilities AFAIK.
So one way to locate yourself on the spectrum from "simple" to "complex" is to
answer this question: Which of those are you going to try to keep track of, and
for each one, how hard are you going to try?
The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely
(it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the
notion of indirect references (it doesn't try very hard). We do not track 1(f)
or 4.
So to think about the overall problem, imagine how you might or might not
address all of those cases.
-------------
PR: https://git.openjdk.org/jdk/pull/11874
