RFR: 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps [v2]

[Vicente Romero]

On Tue, 6 May 2025 20:17:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.
>> 
>> When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.
>> 
>> The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.
>> 
>> I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.
>> 
>> Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.
>> 
>> Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This can be null with goto

looks sensible

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25071#pullrequestreview-2819568071