RFR: 8255367: C2: Deoptimization during vector box construction is broken [v2]

Vladimir Kozlov kvn at openjdk.java.net
Fri Nov 20 19:14:11 UTC 2020


On Fri, 20 Nov 2020 17:16:28 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!
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8255367.vector_box
>  - Trivial cleanup
>  - Fix deoptimization during vector boxing

Good.

The only concern with such approach is that array could be allocated twice if deoptimization happens during Vector object allocation (after compiled code allocated array). We saw some JVMTI issues with Graal which too does reallocation in some cases during deoptimization.

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

Marked as reviewed by kvn (Reviewer).

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


More information about the hotspot-compiler-dev mailing list