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

[Jie He]

On Sat, 9 May 2020 02:20:19 GMT, Jie He <github.com+10233373+jhe33 at openjdk.org> wrote:

>> LGTM
>
>> 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.

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

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