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

[Martin Buchholz]

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