RFR: 8320649: C2: Optimize scoped values [v7]

[Roland Westrelin]

On Thu, 8 Feb 2024 13:00:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - review comment
>>  - Merge branch 'master' into JDK-8320649
>>  - Update src/hotspot/share/opto/callGenerator.cpp
>>    
>>    Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestScopedValue.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - merge fix
>>  - Merge branch 'master' into JDK-8320649
>>  - test failures
>>  - white spaces + bug id in test
>>  - test & fix
>
> src/hotspot/share/opto/callGenerator.cpp line 1087:
> 
>> 1085:   // ScopedValueGetHitsInCache/ScopedValueGetLoadFromCache pair that is amenable to optimizations. The other from
>> 1086:   // the result of the parsing of the java code where the success path ends with an Halt node. The reason for that is
>> 1087:   // that some paths may end with an uncommon trap and if one traps, we want the trap to be recorded for the right bci.
> 
>> want the trap to be recorded for the right bci
> 
> Do we have testing for this kind of think, i.e. that we deopt correctly?

I added one: `testFastPath15`. It tests that we do deopt if the slow path needs to be taken and that on recompilation some test still branches to an uncommon trap: it should be the case of the cache non null test. So the test indirectly checks that the trap was recorded only at some bytecode of `ScopedValue.get()`. It does feel really complicated to test the deoptimization behavior exhaustively.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16966#discussion_r1491338380