[lworld] RFR: 8354068: [lworld] Fold strict final fields more aggressively

[Quan Anh Mai]

On Wed, 9 Apr 2025 13:17:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Note that the objects are still not scalarized due to a bug. When we try to decide if the return will unnecessarily keep the oop of an `InlineTypeNode` alive, we fail to consider the case that some outputs of the oop are memory barriers.
>
> Thanks for working on this @merykitty. I haven't looked at the changes in detail yet but I see some failures in testing.
> 
> 
> compiler/valhalla/inlinetypes/TestArrays.java
> -Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true
> 
> #  Internal Error (/workspace/open/src/hotspot/share/opto/node.hpp:913), pid=1752475, tid=1752491
> #  assert(is_CallJava()) failed: invalid node class: Unlock
> #
> # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-09-0511154.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-09-0511154.tobias.hartmann.valhalla2, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x15613fc]  optimize_strict_final_load_memory_from_local_object(ciField*, ProjNode*)+0x43c
> 
> 
> compiler/valhalla/inlinetypes/TestFieldNullMarkers.java
> -XX:-UseTLAB -DVerifyIR=false
> 
> java.lang.RuntimeException: assertEquals expected: null but was: x = -79
> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
> 	at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
> 	at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
> 	at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
> 	at compiler.valhalla.inlinetypes.TestFieldNullMarkers.main(TestFieldNullMarkers.java:799)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)

@TobiHartmann Thanks a lot for the testing, the first issue is due to me using the wrong method, while the second one is due to me overlooking the existence of the graph after macro expansion. The solution for the second issue is to stop trying the transformation after macro expansion.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1424#issuecomment-2790491413