RFR: 8255367: C2: Deoptimization during vector box construction is broken

[Tobias Hartmann]

On Mon, 9 Nov 2020 13:35:35 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Vector box allocation is a multi-step process: it involves 2 allocations (typed vector instance + primitive array) and 2 initializing stores (vector value store into primitive array and field initialization in typed vector instance). If deoptimization happens at any of the aforementioned allocation points the result is broken: either wrong instance is put on stack (primitive array instead of typed vector) or vector initializing store is missing.
> 
> There are 2 ways to fix the problem: 
> - piggy-back on rematerialization;
> - reexecute the bytecode which allocates the instance.
> 
> I chose the latter option because it's simpler to implement. (Rematerialization requires some adjustment of JVM state associated with each allocation to record vector type and value.) 
> 
> The downside is there shouldn't be any side effects present. It's not a problem right now, because boxing happens only at vector intrinsics use sites and the only intrinsic which has any side effects is vector store operation (it doesn't produce vectors, hence, no boxing needed).
> 
> The actual fix is small: adding `PreserveReexecuteState` in `LibraryCallKit::box_vector` is enough for the problem to go away. The rest is cleanups/refactorings.
> 
> Testing:
> - [x] jdk/incubator/vector tests w/ -XX:+DeoptimizeALot & -XX:UseAVX={3,2,1,0}
> - [ ] hs-precheckin-comp, hs-tier1, hs-tier2
> 
> Thanks!

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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