RFR(S): 8020753: pthread_get_stacksize_np() workaround for OS X 10.9
gerard.ziemski at oracle.com
Thu Oct 24 04:49:52 PDT 2013
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
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.
More information about the hotspot-dev