RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2)
david.holmes at oracle.com
Thu Oct 24 18:49:20 PDT 2013
My only comment is whether the check for >= 10.9 should just be == ?
Assuming they fix this for 10.10 then == would mean no need to make any
future changes, whereas >= would. On the other hand if they don't fix it
then we'd need to change the code again if using ==.
How confident are you they will actually fix this? Was the choice of >=
a deliberate one? :)
On 25/10/2013 12:51 AM, Gerard Ziemski wrote:
> Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks)
> 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
> 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, because:
> 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