RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Oct 24 08:57:27 PDT 2013
line 86: # include <sys/sysctl.h>
line 87: #define DEFAULT_MAIN_THREAD_STACK_PAGES 2048
line 88: #define OS_X_10_9_0_KERNEL_MAJOR_VERSION 13
Since you indented 'include', to be consistent you should
also indent 'define' on lines 87-88.
line 843: if ((*size) <
line 849: *size =
Please add spaces around multiplication ('*') operators.
line 848: if (atoi(kern_osrelease) >=
Please add a comment like this above line 848:
// atoi() will ignore the minor and micro portions of the
Looks great. Thumbs up!
On 10/24/13 8:51 AM, Gerard Ziemski wrote:
> Please review this proposed workaround (round 2) for OS X 10.9
> On Mac Os X 10.9 (Mavericks) the pthread_get_stacksize_np() API
> returns 128 pages for both main (primodial, primary - ie. the one
> created by the OS itself) and secondary threads, when in fact 2048
> pages are available for the main thread. pthread_get_stacksize_np()
> correctly returns 2048 pages for main thread on 10.8, 10.7, 10.6 and
> probably all previous OS X versions.
> An issue has been filed with Apple, but in the meantime we need to
> substitute 2048 pages whenever pthread_get_stacksize_np() returns
> anything else (ie. 128) on main thread. The workaround is only active
> if the kernel version shows we are running on 10.9 or later (the
> workaround will have to be modified once Apple fixes the issue)
> The workaround uses hardcoded value of 2048 pages for main thread,
> 1. The correct value can in fact be found at runtime using signals
> (please see my test case attached to the bug's JDK issue), however,
> such code needs signal handlers and also takes about 3.5 ms, so it's
> probably not a viable solution.
> 2. According to
> that's the size of the main thread for OS X.
> Issue's own test, UTE vm.quick and nsk.stack
More information about the hotspot-dev