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

[Martin Buchholz]

On Sun, May 10, 2020 at 7:47 PM Jie He <github.com+
10233373+jhe33 at openjdk.java.net> wrote:

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

It might be a bug or misfeature in glibc, but it's JVM's job to deal with
it, if necessary writing glibc-version-dependent code.


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