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.