RFR: 8261137: Optimization of Box nodes in uncommon_trap [v6]

[Vladimir Kozlov]

On Wed, 10 Mar 2021 11:32:38 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> Regarding `C->eliminate_boxing()`: why do you think it is needed? 
>> 
>> I'm asking because `is_pure_call() && result_not_used` doesn't have that check.
>> 
>> My understanding is the code encounters `is_boxing_method()` there only when `Compile::should_delay_boxing_inlining() == true` which requires both `EliminateAutoBox` and `AggressiveUnboxing`
>
> I will refactor these codes and add `is_boxing_call()` method. Thank you very much for your review.

I just hit bug where VectorReinterpretTest.java test run with -XX:-DoEscapeAnalysis but Vector API generates SafePointScalarObjectNode regardless that:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vector.cpp#L249

But during deoptimization we only restore allocations when DoEscapeAnalysis is true:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L377

(currently condition is always true because jvmci_enabled == true since JVMCI included into build but without JVMCI it will fail as I found).

It seems with this change you need to add EliminateAutoBox flag check to deoptimization condition.
Or guard your optimization with C->do_escape_analysis().

@iwanowww  Do you think we should add checks for EnableVectorAggressiveReboxing and  EliminateAutoBox into deoptimization code or guard Vector API code and this optimization with  C->do_escape_analysis()?

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

PR: https://git.openjdk.java.net/jdk/pull/2401