RFR: 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
Andrew Haley
aph at openjdk.org
Tue Aug 23 08:57:31 UTC 2022
On Mon, 22 Aug 2022 08:37:50 GMT, Andrew Haley <aph at openjdk.org> wrote:
>>> I'm not at all sure about this one. It may be a bug. Before committing this patch we should find out why AArch64 and LoongArch are consuming more stack than others. 10M of stack is huge.
>>
>> I do not have a particularly good idear to locate this problem `find out why AArch64 and LoongArch are consuming more stack than others` at present. From the test results, AArch64 require more stack space than X86_64. And on the same platform, tier3 `-XX:TieredStopAtLevel=3` consumes more stack space than tier4`-XX:TieredStopAtLevel=4`.
>>
>> On the x64 platform, tier4 needs at least set `-Xss700k` and tier3 needs at least set `-Xss1m`. On the aarch64 platform, tier4 needs at least set `-Xss900k` and tier3 needs at least set `-Xss1228k`.
>>
>> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?
>
>> For safety, I set to `-Xss10m`. Maybe it's more reasonable to change it to `-Xss2m`?
>
> I don't think so. If we were making automobiles and our model consumed 40% more fuel than our competitor's, our response would not be to solve the problem by fitting a larger fuel tank. The stack layout of AArch64 is, as close as we can make it, identical to that of x86-64. So, this difference in memory use is not expected and should be investigated.
> @theRealAph Do you have any good ways to observe the use of X86 and AArch64 stack space?
If it were me:
I'd run the test case in GDB. At the point the StackOverflowException happened, I'd trigger an infinite loop, then dump the stack using the `pfl()` call. I'd also use GDB's `bt` to view information about the native stack. I'd do that for both x86 and AArch64, to see what's causing the difference, and to see how significant it is.
-------------
PR: https://git.openjdk.org/jdk/pull/9934
More information about the compiler-dev
mailing list