RFR: 8225035: Thread stack size issue caused by large TLS size

[Andrew Haley]

On 6/14/19 6:46 AM, David Holmes wrote:
> 
>> - I am unsure about the sudden cutoff point. May have understood wrong, 
>> but lets assume we have 6K TLS to accommodate, for which 
>> pthread_minstack would return 6k + some 4K pages (2?) = 14K.
>>
>> requested stack size to real stack size, after the proposed correction, 
>> with the default cut off for the thread stack correction of 10%:
>> 100K -> 114K
>> 120K -> 134K (10% point)
>> 121K -> 121K (sudden dip? why?)
>>
>> My point is that the penalty for TLS we have to pay is as big at 10.1% 
>> as it is at 10%, so maybe we do not want a sudden cutoff?
> 
> The cut-off is unfair but also simple. Can you suggest some other way?

Yes. We should not make any accommodation for the likes of jemalloc at all.
It's up to the user to determine how they want to configure their system,
whether they want to link against jemalloc, and so on.

Any changes in this area are IMO more risky than leaving things alone.

>> Another point, but probably just a work item for us at SAP, is that we 
>> should test the patch on platforms with large page sizes. I am not sure 
>> what pthread_minstack would return e.g on linux ppc64 with 64K pages.
> 
> Thats a good point. We may have to factor in whether or not large pages 
> are in use.

Yes, that's a very good point.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671