RFR: 8329555: Crash in intrinsifying heap-based MemorySegment Vector store/loads

[Sandhya Viswanathan]

On Fri, 12 Apr 2024 03:57:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Problem is related to bi-morphic inlining of ms.unsafeBase() in presence of multiple receiver type profiles (OfFloat, OfByte) which results into formation of an abstract type phi node at JVM state convergence points.
> - Due to this, for mismatched memory segment access, inline expander is unable to infer the element type of array wrapped within the memory segment and this results into an assertion failure while computing the source lane count.
> - For non-masked mismatched memory segment vector read/write accesses, intrinsification can continue with unknown backing storage type and compiler can skip inserting explicit reinterpretation IR after loading from or before storing to backing storage which is mandatory for semantic correctness of big-endian memory layout.
> - For vector write access, this may prevent value forwarding, which may result into subsequent redundant vector loads from same address, but preventing intensification failure will offset that cost.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

src/hotspot/share/opto/vectorIntrinsics.cpp line 1040:

> 1038: 
> 1039:   bool mismatched_ms = from_ms->get_con() && !is_mask && arr_type != nullptr && arr_type->elem()->array_element_basic_type() != elem_bt;
> 1040:   BasicType mem_elem_bt = LITTLE_ENDIAN_ONLY(elem_bt) BIG_ENDIAN_ONLY(arr_type->elem()->array_element_basic_type());

mismatched_ms check is missing now for BIG_ENDIAN_ONLY path

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18749#discussion_r1566554997