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

[Gerard Ziemski]

I like that check - the issue lies inside the kernel most likely, so any 
fix would end up reving up the kernel version. Thank you.


On 10/23/2013 1:41 PM, Igor Veresov wrote:
> I guess it's reasonable.
>
> As for option (2) you can probably trigger the fix based on the kernel 
> version, that is rather easy to get:
>
> #include <errno.h>
> #include <sys/sysctl.h>
> char str[256];
> size_t size = sizeof(str);
> int ret = sysctlbyname("kern.osrelease", str, &size, NULL, 0);
>
> Versions 13.x.x would be Mavericks. You can use it to put an 
> additional assert.
>
> igor
>
>
>
>
> On Oct 23, 2013, at 7:20 AM, Gerard Ziemski <gerard.ziemski at oracle.com 
> <mailto:gerard.ziemski at oracle.com>> wrote:
>
>> Please review this proposed workaround 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) 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.6, 10.7 and 10.8 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 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. We could also look-up OS X version at runtime to only use the 
>> workaround for 10.9, but that requires parsing an xml file, looking 
>> for a value that is internationalized, so it's non trivial (though 
>> might be doable assuming the time to execute is low enough)
>>
>> 3. All JDK8 supported OS X versions (ie. 10.7, 10.8) return 2048.
>>
>> In the future, this workaround might need to be revisited (ie. 2), 
>> but I believe that it's reasonable for now, though I would love to 
>> hear others opinions on this.
>>
>>
>> Testing:
>>
>> In progress...
>>
>>
>> References:
>>
>> http://cr.openjdk.java.net/~iklam/8020753/ziemski_rev1/ 
>> <http://cr.openjdk.java.net/%7Eiklam/8020753/ziemski_rev1/>
>> https://bugs.openjdk.java.net/browse/JDK-8020753
>>
>>
>> cheers
>>
>