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

[Xiaohong Gong]

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.

That's great! Thanks so much for your help!

> > 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?

Yes, I can reproduce now. The failure is randomly that the test can pass sometimes on my ARM system. I'm currently working on looking at this issue, but not too much progress now. 

> > 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?

Yes, make sense to me. Thanks a lot for the explanation!

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

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