On Fri, 13 Jan 2023 20:21:24 GMT, Vicente Romero <vrom...@openjdk.org> wrote:
>> Archie L. Cobbs has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use more idiomatic test for java.lang.Object.
>> - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>> - Fix formatting issue with the "this-escape" --help-lint description.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> line 1088:
>
>> 1086: private <T extends JCTree> void visitLooped(T tree, Consumer<T>
>> visitor) {
>> 1087: visitScoped(tree, false, t -> {
>> 1088: while (true) {
>
> I have also been thinking if the loop analysis could go wild and execute a
> large, unbound number of times. But it seems from Archie's experiments that
> this probably won't occur in "normal" code and worst case scenario if that
> were to occur we can always limit the number of times we will process loops
> to a set number of times
The number of times around any single loop is bounded by the number of new
references that can possibly be created during the analysis of that loop.
That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of
parameters and/or variables declared in that scope (the 2 is for direct or
indirect, and the 1's are for each of the singleton reference types `ThisRef`,
`OuterRef`, `ExprRef`, and `ReturnRef`).
If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared
therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 +
1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).
-------------
PR: https://git.openjdk.org/jdk/pull/11874
