[lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0"
Jatin Bhateja
jbhateja at openjdk.org
Thu Dec 7 03:42:57 UTC 2023
On Mon, 4 Dec 2023 08:50:45 GMT, Xiaohong Gong <xgong 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/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/in...
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
#
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/958#issuecomment-1844204851
More information about the valhalla-dev
mailing list