RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9 (round 2)

[Igor Veresov]

Hopefully the fix will be in the next update (probably the minor one) and then we can put an upper bound on the version that need this hack. Which would probably require parsing the minor version digits.

igor

On Oct 25, 2013, at 6:58 AM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:

> Yes it was a deliberate choice:
> 
> Using == would be a time bomb if Apple failed to fix it post 10.9 (would have to be reactive action)
> 
> Using >= means we do things on our own terms as the workaround is harmless even on well behaved system, so we don't have to rush to change the code, unless we want to (is proactive action)
> 
> 
> cheers
> 
> On 10/24/2013 8:49 PM, David Holmes wrote:
>> Hi Gerard,
>> 
>> 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? :)
>> 
>> Cheers,
>> David
>> 
>> On 25/10/2013 12:51 AM, Gerard Ziemski wrote:
>>> Please review this proposed workaround (round 2) for OS X 10.9 (Mavericks)
>>> 
>>> Description:
>>> 
>>> 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, 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
>>> https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html 
>>> that's the size of the main thread for OS X.
>>> 
>>> 
>>> Testing:
>>> 
>>> Issue's own test, UTE vm.quick and nsk.stack
>>> 
>>> 
>>> References:
>>> 
>>> http://cr.openjdk.java.net/~hseigel/8020753/
>>> <http://cr.openjdk.java.net/%7Ehseigel/8020753/>
>>> https://bugs.openjdk.java.net/browse/JDK-8020753
>>> 
>>> 
>>> cheers
>>> 
>> 
>