[lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize" cannot work well

[Tobias Hartmann]

On Mon, 21 Aug 2023 03:50:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> > Are you inclined to re-instantiate the old behavior ?
>>> 
>>> May I ask what the "old behavior" do you mean? Thanks!
>> 
>> Hi @XiaohongGong ,
>> Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options :  "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0"
>> [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt)
>> [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt)
>> [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
>> 
>> Please find attached relevant logs and replay file.
>> 
>> Best Regards,
>> Jatin
>
>> > > Are you inclined to re-instantiate the old behavior ?
>> > 
>> > 
>> > May I ask what the "old behavior" do you mean? Thanks!
>> 
>> Hi @XiaohongGong , Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options : "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0" [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt) [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt) [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
>> 
>> Please find attached relevant logs and replay file.
>> 
>> Best Regards, Jatin
> 
> Thanks for pointing out this! I can reproduce this issue after I rebase my patch to latest `lworld` branch. I will try my best to look at what is changed. 
> 
> Best Regards,
> Xiaohong

Hi @XiaohongGong,

> I think there maybe some potential issues exposed after this change, since almost all value objects cannot be flattened anymore with -XX:InlineFieldMaxFlatSize=0, which may need the buffer allocated.

Yes, I think it's likely that this change reveals some existing issues. I can help with debugging but only later next month.

> Could you please show more env/options information on this issue? I cannot reproduce it even with -XX:InlineFieldMaxFlatSize=0 -XX:TieredStopAtLevel=1 on our internal Arm NEON machine.

It fails quite reliable in our testing on x86_64 with one of the following flag combinations:
- `-Xcomp -XX:TieredStopAtLevel=1 -DIgnoreCompilerControls=true`
- `-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true`
- `-DWarmup=0 -DVerifyIR=false`
- `-DWarmup=0 -XX:TieredStopAtLevel=1`

But you can reproduce this now, right?

> Actually I don't quite understand what this assertion mean? Why the null_free value type must be allocated in this routine?

The `is_allocated` assertion checks that the InlineTypeNode should always have a valid oop to a heap buffer now that we just loaded it from an oop value. That's not guaranteed if the field/argument can be NULL though, that's why the assert checks for `!null_free`. Does that make sense?

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1689445893