[lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v13]

[Jatin Bhateja]

On Sat, 6 May 2023 00:15:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/runtime/deoptimization.cpp line 1146:
>> 
>>> 1144:         if (EnableVectorSupport && VectorSupport::is_vector(ik)) {
>>> 1145:           obj = VectorSupport::allocate_vector(ik, fr, reg_map, sv, THREAD);
>>> 1146:         } else if (EnableVectorSupport && VectorSupport::is_vector_payload_mf(ik)) {
>> 
>> Why do you need to handle both cases now? Anything special needed for `VectorSupport::is_vector()` case?
>
> Another question: is there a lurking problem in the original implementation? Can a backing array leak into debug info, so reallocation has to handle it? I believe it's not the case since vector scalarization logic relies on typed vector box to pass type information, but want to double-check with you.

> Why do you need to handle both cases now? Anything special needed for `VectorSupport::is_vector()` case?

Both VectorSupportMF* and its containing VectorBoxes are inline types (primitive / value classes) and there is lot of surface area involving Unsafe APIs in fallback implementation where we create a payload and update its fields before wrapping it into a box, this handling makes sure to re-materialize payloads in case de-optimization triggers before vector box creation. 

> Another question: is there a lurking problem in the original implementation? Can a backing array leak into debug info, so reallocation has to handle it? I believe it's not the case since vector scalarization logic relies on typed vector box to pass type information, but want to double-check with you.

Arrays [re-allocation](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1157)` / `[reassignment](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1572) is already handled during de-optimization, on a side note even escape analysis records the scalarized locations of small eliminated arrays whose size is less than EliminateAllocationArraySizeLimit since larger arrays are already allocated over heap. So existing stock implementation is already handling backing storage appropriately.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025254