Escape this analysis does not consider anonymous class/local class

[Archie Cobbs]

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>