United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6978641 Fix for 6929067 introduces additional overhead in thread creation/termination paths
6978641 : Fix for 6929067 introduces additional overhead in thread creation/termination paths

Details
Type:
Enhancement
Submit Date:
2010-08-20
Status:
Closed
Updated Date:
2011-04-23
Project Name:
JDK
Resolved Date:
2011-04-23
Component:
hotspot
OS:
linux
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs19

Related Reports
Backport:
JDK-2198381 - Fix for 6929067 introduces additional overhead in thread creation/termination paths
Backport:
JDK-2199995 - Fix for 6929067 introduces additional overhead in thread creation/termination paths
Backport:
JDK-2200018 - Fix for 6929067 introduces additional overhead in thread creation/termination paths
Backport:
JDK-2200244 - Fix for 6929067 introduces additional overhead in thread creation/termination paths
Backport:
JDK-2201477 - Fix for 6929067 introduces additional overhead in thread creation/termination paths
Backport:
JDK-2205918 - Fix for 6929067 introduces additional overhead in thread creation/termination paths
Relates:
JDK-6929067 - Stack guard pages should be removed when thread is detached

Sub Tasks

Description
The fix for 6929067 introduced a check for growable stacks by parsing /proc/self/maps when setting up and tearing down the stack guard pages. This can become a bottleneck when large numbers of threads start or terminate around the same time. Growable stacks are only expected in the main/initial thread as they are not used by the current day threads libraries. We can remove the bottleneck by only checking the stack bounds for the initial thread. But in case of future changes we maintain the existing behaviour in debug mode and add a check that if we find a growable stack that it does indeed belong to the initial thread.

Comments
EVALUATION

http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/9b2e416eda7f
2010-10-08 
EVALUATION

<moved to hs20 sub-CR>
2010-09-04 
EVALUATION

<moved to hs20 sub-CR>
2010-08-30 
EVALUATION

<moved to hs20 sub-CR>
2010-08-27 
PUBLIC COMMENTS

As a data-point on the performance impact of this change I wrote a simple microbenchmark that creates 1024 threads waiting on a CountDownLatch and then releases them. It was run on a 8-way linux box. With this fix in place it took 220ms to run. Without the fix it took 3 seconds!
2010-08-24 
EVALUATION

See description.
2010-08-20


Hardware and Software, Engineered to Work Together