JDK-8288631 : Avoid applying Linux NPTL stack guard workaround for glibc 2.27+
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-06-16
  • Updated: 2023-01-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
JDK-8169373 introduced code to work around Linux glibc NPTL pthread implementation bug about guard size prior to glibc 2.27. As [~simonis] mentioned, the glibc NPTL bug has been fixed in glibc 2.27 in https://sourceware.org/bugzilla/show_bug.cgi?id=22637.

Now running a JDK with glibc 2.27+ leads to less usable stack space due to the workaround code. We have observed JVM crashes with internal tests due to their high usage of stack space and the workaround code. Ideally we should avoid applying the workaround code for glibc 2.27+.

Several options are:
- Automatically detect glibc version, then apply the workaround depending on glibc version. We have an internal patch that does this, but it adds code complexity and is perhaps a bit overkill.

- Add a JVM flag so that users could disable the workaround if needed.

- Do nothing for now, and remove the workaround code once OpenJDK stops supporting glibc prior to 2.27. 
Comments
One particular problematic case we found is that a native thread is attaching to the JVM via attach_current_thread() in jni.cpp. This skips the os::create_thread() code path from JavaThread()'s constructor, which has "stack_adjust_size += guard_size;" workaround for the NPTL bug. Then the native thread could have set guard_size larger than the stack size, which leads to underflow at "*size -= guard_size;" in current_stack_region() in os_linux.cpp.
16-06-2022