[lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0"

[Xiaohong Gong]

On Thu, 7 Dec 2023 03:39:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened.
>> 
>> This patch fixes them with following main changes:
>> 
>>  1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed.
>> 
>>  2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails.
>> 
>>  3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the
>> assertion failure [3].
>> 
>> When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a
>> flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field
>> value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the
>> matched field value is expected to be a valid oop.
>> 
>> The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer.
>> 
>>  4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened.
>> 
>> The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4].
>> 
>> Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found.
>> 
>> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318
>> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812
>> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050
>> [4] https://github.com/openjdk...
>
> Hi @XiaohongGong ,
> 
> I am seeing following assertion failures in Vector API JTREG tests with flattening disabled, not yet spent time in root causing it.
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/jatinbha/sandboxes/lworld+vector/valhalla/src/hotspot/share/opto/narrowptrnode.cpp:45), pid=342594, tid=342623
> #  assert(t->isa_narrowoop()) failed: only narrowoop here
> #
> # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-adhoc.root.valhalla)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-adhoc.root.valhalla, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x14a9044]  DecodeNNode::Value(PhaseGVN*) const+0x124
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/core.342594)
> #
> # An error report file with more information is saved as:
> # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/hs_err_pid342594.log
> #
> # Compiler replay data is saved as:
> # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/replay_pid342594.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #

Sorry for cannot continuing on this PR. I have to close it. @jatin-bhateja may create another PR for it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/958#issuecomment-1851242103