In order to detect stack overflow, a few OS pages at the end of stack are marked inaccessible, as illustrated in `class StackOverflow`, i.e. "guard zone". Such guard pages are constructed in `StackOverflow::create_stack_guard_pages`, it consists of mainly two steps (calls):
1. os::create_stack_guard_pages -- some preparation work
2. os::guard_memory -- mark guard-pages as inaccessible
The postcondition is that those guard-pages should be inaccessible (i.e. raising OS signal on access).
Since those guard-pages are supposted to be inaccesible, we can use reserved-memory, instead of committed-memory. for them.
Implementatin note:
- Linux main thread reserves stack memory dynamically, so need to take special care in `create_stack_guard_pages` for it.
From https://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html
"""
A thread's stack size is fixed at the time of thread creation.
Only the main thread can dynamically grow its stack.
"""
- Windows requires committed-memory for guard-pages.
From https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect:
"You can set the access protection value on committed pages only."
===================== previous content ===================================
NMT currently mark stack guard pages are committed:
0x00007fc5b47f2000 - 0x00007fc5b48f3000] reserved 1028KB for Thread Stack from
[0x00007fc60891e467] thread_native_entry(Thread*)+0xe7
[0x00007fc5b47f2000 - 0x00007fc5b47f6000] committed 16KB from
[0x00007fc608accb97] StackOverflow::create_stack_guard_pages()+0x57
[0x00007fc608b8de01] JavaThread::run()+0x31
[0x00007fc608b913fe] Thread::call_run()+0xde
[0x00007fc60891e467] thread_native_entry(Thread*)+0xe7
but smaps says otherwise:
7fc5b47f2000-7fc5b47f6000 ---p 00000000 00:00 0
Size: 16 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
1. os::create_stack_guard_pages -- some preparation work
2. os::guard_memory -- mark guard-pages as inaccessible
The postcondition is that those guard-pages should be inaccessible (i.e. raising OS signal on access).
Since those guard-pages are supposted to be inaccesible, we can use reserved-memory, instead of committed-memory. for them.
Implementatin note:
- Linux main thread reserves stack memory dynamically, so need to take special care in `create_stack_guard_pages` for it.
From https://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html
"""
A thread's stack size is fixed at the time of thread creation.
Only the main thread can dynamically grow its stack.
"""
- Windows requires committed-memory for guard-pages.
From https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect:
"You can set the access protection value on committed pages only."
===================== previous content ===================================
NMT currently mark stack guard pages are committed:
0x00007fc5b47f2000 - 0x00007fc5b48f3000] reserved 1028KB for Thread Stack from
[0x00007fc60891e467] thread_native_entry(Thread*)+0xe7
[0x00007fc5b47f2000 - 0x00007fc5b47f6000] committed 16KB from
[0x00007fc608accb97] StackOverflow::create_stack_guard_pages()+0x57
[0x00007fc608b8de01] JavaThread::run()+0x31
[0x00007fc608b913fe] Thread::call_run()+0xde
[0x00007fc60891e467] thread_native_entry(Thread*)+0xe7
but smaps says otherwise:
7fc5b47f2000-7fc5b47f6000 ---p 00000000 00:00 0
Size: 16 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
- links to
-
Review openjdk/jdk/14896
-
Review(master) openjdk/jdk/26571