For the following thread stack mapping in smaps (machine: AMD, Ubuntu 18.04.6 LTS, glibc 2.27):
7f240d5c8000-7f240d5c9000 ---p 00000000 00:00 0
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
ProtectionKey: 0
VmFlags: mr mw me sd
7f240d5c9000-7f240d6ca000 rw-p 00000000 00:00 0
Size: 1028 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 8 kB
Pss: 8 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 8 kB
Referenced: 8 kB
Anonymous: 8 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
This is what gets computed in current_stack_region() and later stored in the thread object:
##Thread's stack base: 0x7f240d6ca000
##Thread's stack size: 1048576
##Thread's stack end: 0x7f240d5ca000
Comparing this to what pthread_attr_getstack() returns:
Stack bottom returned by pthread_attr_getstack(): 0x7f240d5c9000
Stack size returned by pthread_attr_getstack: 1052672
Here, the JVM code assumes that the guard page is included in the stack bottom address returned by pthread_attr_getstack(), but actually the guard page is not included with certain glibc version.
I see this behavior on the following configuration
AMD, Ubuntu 18.04.6 LTS, glibc 2.27
However, on "ARM, OL 7.9, glibc 2.17", the guard page does get included in the bottom address returned by pthread_attr_getstack, and the JVM behaves correctly.
7f240d5c8000-7f240d5c9000 ---p 00000000 00:00 0
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
ProtectionKey: 0
VmFlags: mr mw me sd
7f240d5c9000-7f240d6ca000 rw-p 00000000 00:00 0
Size: 1028 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 8 kB
Pss: 8 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 8 kB
Referenced: 8 kB
Anonymous: 8 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
This is what gets computed in current_stack_region() and later stored in the thread object:
##Thread's stack base: 0x7f240d6ca000
##Thread's stack size: 1048576
##Thread's stack end: 0x7f240d5ca000
Comparing this to what pthread_attr_getstack() returns:
Stack bottom returned by pthread_attr_getstack(): 0x7f240d5c9000
Stack size returned by pthread_attr_getstack: 1052672
Here, the JVM code assumes that the guard page is included in the stack bottom address returned by pthread_attr_getstack(), but actually the guard page is not included with certain glibc version.
I see this behavior on the following configuration
AMD, Ubuntu 18.04.6 LTS, glibc 2.27
However, on "ARM, OL 7.9, glibc 2.17", the guard page does get included in the bottom address returned by pthread_attr_getstack, and the JVM behaves correctly.
- duplicates
-
JDK-8229147 Linux os::create_thread() overcounts guardpage size with newer glibc (>=2.27)
- Resolved