RFR: 8225035: Thread stack size issue caused by large TLS size

[Jiangli Zhou]

I've created JDK-8229147
(https://bugs.openjdk.java.net/browse/JDK-8229147) for the guard-page
size overcounting issue in the default case on newer glibc.

Best regards,
Jiangli

On Sun, Jul 21, 2019 at 6:17 PM Jiangli Zhou <jianglizhou at google.com> wrote:
>
> Hi Florian,
>
> On Fri, Jul 19, 2019 at 5:09 AM Florian Weimer <fweimer at redhat.com> wrote:
> >
> > * Jiangli Zhou:
> >
> > > Here is the full webrev:
> > > http://cr.openjdk.java.net/~jiangli/8225035/webrev.05/, including the
> > > additional comments above get_static_tls_area_size.
> > >
> > > Best regards,
> > > Jiangli
> > >
> > > On Mon, Jul 8, 2019 at 2:27 AM Florian Weimer <fweimer at redhat.com> wrote:
> > >>
> > >> * Jiangli Zhou:
> > >>
> > >> > As you, Florian, Thomas all made great contributions to this
> > >> > workaround, I should list all of you as both contributors and
> > >> > reviewers in the changeset. If there is any objection, please let me
> > >> > know.
> > >>
> > >> Can you share a link with the final patch?  I would like to have another
> > >> look.
> >
> > Thanks, looks reasonable.
> >
> > Note that a funny consequence is that the flag may now actually lower
> > stack sizes on recent glibcs because when the flag is enabled, the guard
> > size accounting is again what it used be.  Without the flag and
> > new-enough glibc, the guard size is added twice to the stack size (once
> > in OpenJDK and once in glibc).
>
> Agree with your comment about the double-counted guard size overhead
> in the default case (without enabling of the stack size adjustment)
> with newer glibc. It might be a good idea to open an RFE/bug for that.
> It would need careful testing and some discussions on how to properly
> address that.
>
> Best regards,
> Jiangli
> >
> > Thanks,
> > Florian