RFR: JDK-8330565 - C2: Multiple crashes with CTW after JDK-8316991
Vladimir Kozlov
kvn at openjdk.org
Mon May 6 21:53:53 UTC 2024
On Mon, 6 May 2024 21:02:07 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:
> Please consider this patch for fixing issues described in JDK-8330565 with a little overlap with issue JDK-8330795.
>
> The `# assert(false) failed: Bad graph detected in build_loop_late` failure was caused because a string concatenation optimization using [this method](https://github.com/openjdk/jdk/blob/819f3d6fc70ff6fe54ac5f9033c17c3dd4326aa5/src/hotspot/share/opto/graphKit.cpp#L4115) adds AddP and LoadN nodes to IR graph as NotNull _and_ because RAM was not "nullyfing" phis merging nullable pointers. I was only able to reproduce this problem using a classfile/jar compiled using an "old" version of JDK.. because newer version use InvokeDynamic to do string concatenation.
>
> The `assert(adr_t->is_known_instance_field()) failed: instance required` failure was caused because RAM uses `PhaseMacroExpand::can_eliminate_allocation` to check if an allocation can be eliminated and that method wasn't checking that the allocation uses an exact type or not.
>
> The `assert((uint)type <= T_CONFLICT && _zero_type[type] != nullptr) failed: bad type` failure was caused by the fact that we didn't have a "zero value" for the type T_METADATA. The RAM patch uses that data when it creates a Phi node merging Klass loads and UseCompressedClassPointers is disabled.
>
>
>
>
> Tested with JTREG tier1-4 on Linux x86_64 & ARM64.
src/hotspot/share/opto/macro.cpp line 578:
> 576: } else if (!res_type->klass_is_exact()) {
> 577: NOT_PRODUCT(fail_eliminate = "Not an exact type.";)
> 578: can_eliminate = false;
You already fixed this: [#18851](https://github.com/openjdk/jdk/pull/18851)
Please, merge latest changes into this PR.
Also you need new regression tests.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19111#discussion_r1591593729
More information about the hotspot-compiler-dev
mailing list