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

[Gerard Ziemski]

On 10/23/2013 9:25 PM, David Holmes wrote:
> 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.
According to Apple's own doc on threads 
https://developer.apple.com/library/mac/documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html 
the main thread is 8MB (2048 pages) and I don't see any way to change 
main thread's stack size.

> 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?
That line in fact shows that JavaVM currently breaks the main stack size 
for 3rd party code (it unnecessarily restricts the stack size to 128 
even though 2048 pages are really available) and the presented 
workaround would in fact fox it.

>
> Would checking only for the 128 value be more, or less, robust?
I considered checking for 128 pages as well, but according to the link I 
provided to Apple doc, the main thread on OS X is 2048 pages, so that's 
a good number to check.

I believe restricting the workaround to Mavericks alleviates most 
concerns, but I agree that anything short of actually finding the stack 
size at runtime (which unfortunately is a no go here due to complexity 
and time cost) feels like well, a workaround.

Thank you David for the insightful questions.