RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper

[Jie He]

On Mon, 11 May 2020 02:17:57 GMT, Jie He <github.com+10233373+jhe33 at openjdk.org> wrote:

>>> LGTM
>> 
>> thanks
>
>> _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) on
>> [tsan-dev](mailto:tsan-dev at openjdk.java.net):_
>> I was the one who introduced a small stack size for the process
>> reaper, trying to be a good citizen thread.
>> I still believe it is the right approach, and any stack overflow in
>> that thread indicated a serious JVM bug to fix.
>> Those StackOverflowErrors should have been a nudge to hotspot
>> implementers to eradicate StackOverflowError entirely.
>> But that never happened.
>> 
>> On Wed, May 6, 2020 at 2:49 AM Jie He
>> <github.com+10233373+jhe33 at openjdk.java.net> wrote:
>> 
>> > Process reaper has a small size stack by default, 128K. With tsan
>> > enabled, it often causes SOE failure when running jtreg tests. Set
>> > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test
>> > use default JVM stack size (global variable ThreadStackSize) in
>> > aarch64, which could be configured by -Xss.
>> > I took an investigation about the stackoverflow, [1].
>> > and found the different GLIBC behaviors between x86 and aarch64 stack
>> > allocation due to default stack size in openjdk. x86 will get the stack from
>> > glibc cached stack because it matches the threshold to allocate a stack from
>> > cached stack, but aarch64 not.
>> > [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg
>> > -------------
>> > Commit messages:
>> > - Process reaper uses default JVM stack size in aarch64
>> > Changes: https://git.openjdk.java.net/tsan/pull/8/files
>> > Webrev: https://webrevs.openjdk.java.net/tsan/8/webrev.00
>> > Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
>> > Patch: https://git.openjdk.java.net/tsan/pull/8.diff
>> > Fetch: git fetch https://git.openjdk.java.net/tsan pull/8/head:pull/8
>> > PR: https://git.openjdk.java.net/tsan/pull/8
> 
> yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, it reduces the effiective usable stack size.

> _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) on
> [tsan-dev](mailto:tsan-dev at openjdk.java.net):_
> On Sun, May 10, 2020 at 7:20 PM Jie He
> <github.com+10233373+jhe33 at openjdk.java.net> wrote:
> 
> > yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, it reduces the effiective usable stack size.
> 
> I have always thought that when the JVM is asked to create a thread
> with some stack size, then the JVM should try hard to ensure that all
> the requested space is usable for java stack frames, i.e. nothing is
> deducted for "overhead".
> 
> The spirit of Java (portability and reliability) hasn't reached stack
> space calculations yet.

I think the stack allocation mechanism in glibc will also hide some stack related issues by JVM.
in some cases, glibc will allocate a larger stack than you specified. it's out of scope of JVM.

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

PR: https://git.openjdk.java.net/tsan/pull/8