Escape this analysis does not consider anonymous class/local class
Archie Cobbs
archie.cobbs at gmail.com
Tue Oct 3 02:44:23 UTC 2023
Hi Remi,
You got me curious.... it turns out it's not hard to fix those cases as
well as do a few other minor improvements.
I've created JDK-8317376 <https://bugs.openjdk.org/browse/JDK-8317376> to
track this.
-Archie
On Mon, Oct 2, 2023 at 12:30 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:
> Hi Remi,
>
> On Mon, Oct 2, 2023 at 2:18 AM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> The compiler does not emit a warning when the access to "this" is buried
>> inside an anonymous class
>>
>
> This is a known limitation. In summary, the analyzer tracks 'this'
> references that are outer instance references from the current instance,
> but it doesn't track 'this' references that are outer instance references
> from arbitrary objects on the stack.
>
> So when you say "new Inner()", the analyzer doesn't track the fact that
> the object on top of the stack now has a 'this' reference via its outer
> instance.
>
> This is one of the (many) trade-offs that were made between precision vs.
> code complexity.
>
> There are a couple of possible ways to address this:
>
> 1. Using existing reference types: record "new Inner()" as having an
> indirect 'this' reference, and then update the logic for "Outer.this" to
> pessimistically assume any indirect reference is an outer reference.
> 2. Add a new reference type: OuterExprRef to mean "a 'this' reference
> from the outer instance of the object on the stack" and add tracking for it
>
> Option #1 would probably lead to a bunch of new false positives. Option #2
> is more precise and therefore better but requires more code.
>
> -Archie
>
> --
> Archie L. Cobbs
>
--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231002/0915c2c9/attachment.htm>
More information about the compiler-dev
mailing list