Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8229147

Linux os::create_thread() overcounts guardpage size with newer glibc (>=2.27)

    XMLWordPrintable

Details

    • b21
    • linux

    Backports

      Description

        This issue was brought up by Florian Weimer (thanks!) during the code review for JDK-8225035. Please see https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-July/035322.html for detailed discussion.

        According to glibc bug "guard size is subtracted from thread stack size instead of adding it on top", https://sourceware.org/bugzilla/show_bug.cgi?id=22637:

        "Previously if user requested S stack and G guard when creating a thread, the total mapping was S and the actual available stack was S - G - static_tls, which is not what the user requested.
            
         This patch fixes the guard size accounting by pretending the user requested S+G stack. This way all later logic works out except when reporting the user requested stack size (pthread_getattr_np) or when computing the minimal stack size (__pthread_get_minstack)."

        With glibc 2.27 and new versions, the allocated thread stack size is user_requested_size+guard_size. Linux os::create_thread() adds an extra guard page size to the requested stack size in the default case:

        bool os::create_thread(Thread* thread, ThreadType thr_type,
                               size_t req_stack_size) {
        ...
            stack_adjust_size += guard_size;

        With glibc 2.27 and new versions, the above is no longer needed for the default case.

        Attachments

          Issue Links

            Activity

              People

                dholmes David Holmes
                jiangli Jiangli Zhou
                Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: