JDK-4852809 : Linux: do not use alternate signal stack
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2003-04-23
  • Updated: 2025-08-06
  • Resolved: 2003-10-08
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
5.0 b22Fixed
Related Reports
Relates :  
JDK-8009302 - Mac OS X: JVM crash on infinite recursion on Appkit Thread
Relates :  
JDK-7154055 - Please add alternate signal stacks to Linux JVM for better error reporting
Relates :  
JDK-4929857 - Clean up os::reserve_memory
Description
Alternate signal stack is used on Linux to support stack banging. 

Stack banging needs to touch page below current ESP; however, this will 
generate SIGSEGV on Linux. To work around the problem, we install alternate 
signal stack for SIGSEGV at the lower end of thread stack. When we receive 
a SEGV due to stack bang, we will touch the same page again from SEGV 
handler. Because we are now running on alternate signal stack with a smaller
ESP, this time we can succeed.

There are other ways to get around the problem without using alt signal
stack:

1. mmap() the page directly. This may have some performance issue, as mmap()
   on old systems will create a new memory region. Using mmap() for stack
   bang may create too many memory regions. With Tiger, we'll drop some old
   systems, so we might be able to use mmap(). Need to test.
2. Temporarily adjust ESP to lower address within SEGV handler. However, when
   stack space is already low, and if there's another signal delivered after
   SEGV, changing ESP might leave too little space to handle the new signal. 
   We can get around this by temporarily masking all signals.

Here are the benefits from not using alternate signal stack:

1. Allow smaller thread stack, and more threads. Currently, every thread
   needs 40K alternate signal stack, minimum stack size is 96K. Removing alt
   signal stack can reduce minimum stack size by about 40%.
2. Only need one set of guard pages. Right now, we have HotSpot guard pages
   between alt signal stack and normal thread stack, and regular glibc guard
   page below alt signal stack. We don't need glibc guard pages when there
   is not alternate signal stack. HotSpot guard pages are enough. Creating
   guard page on Linux is very expensive. Using a micro benchmark, not
   creating glibc guard (or HotSpot guard) can reduce thread creation time
   by about 40%.
3. Easier to maintain. Same model on all platforms.

###@###.### 2003-04-23
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger-b22
14-06-2004
EVALUATION Using alternate signal stack could cause problems if there is native code that creates new thread and it handles SIGSEGV (e.g. through signal chaining). If a newly created thread does not set its own alternate signal stack, it will inherit its creator's alternate signal stack. If the child thread and parent thread have SIGSEGV at the same time, both SEGV's will be handled on the same alternate signal stack, causing the two threads to overwrite each other's stack frame. Using alt signal stack is problematic even the two threads never have SEGV at the same time. pthread_getspecific() in fixed stack LinuxThreads (default on SuSE, Debian, and many other Linux distros) obtains current thread by shifting stack pointer (%esp). Because child thread's SEGV is handled on its creator's stack space, pthread_getspecific() will return wrong value if called from child thread's signal handler, causing hard to find problems. VM should not use alternate signal stack. ###@###.### 2003-09-14 -------------------------------- Fixed by removing alternate signal stack. To manually expand thread stack without alt stack, we temporarily adjust stack pointer to lower address (i.e. method 2 as mentioned in the description section), and all signals are masked when we are working on the stack. Furthermore, we don't wait until the first SIGSEGV to expand initial thread's stack; instead, its entire stack region is expanded when the thread is first attached. With this change, we won't receive any SIGSEGV during stack banging unless an attached thread was created by user code with MAP_GROWSDOWN flag, which is very unlikely. ###@###.### 2003-09-23
23-09-2003