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

[David Holmes]

On 24/10/2013 6:04 AM, Gerard Ziemski wrote:
> 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.

I'd certainly like to see the "fix" constrained to Mavericks. It seems 
strange to ask for the stacksize but then assume it is 2048 pages 
anyway. I assume OSX has some means of controlling the default initial 
stacksize? In which case this change will break things if a size smaller 
than 2048 is actually used. I'm concerned by this line in the table in 
the bug report, but don't understand what the "start JAVAVM" tag means:

OS:  USE_MAIN_THREAD: START_JAVAVM: CLAIMED PAGES:  USABLE PAGES:
10.9     YES             YES            128              124

won't your change break this case?

Would checking only for the 128 value be more, or less, robust?

Thanks,
David

>
> 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
>>>
>>
>