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

David Holmes david.holmes at oracle.com
Thu Jun 20 03:59:21 UTC 2019


Florian,

On 19/06/2019 12:30 am, Florian Weimer wrote:
> * Jiangli Zhou:
> 
>> Would it be do-able to implement cpu-specific code within the JVM to
>> handle those cases when needed (?).
> 
> Not really.  It depends on the kernel as well, and how the kernel sets
> up things.
> 
> There could be other reasons why the small stack assumption no longer
> holds.  The stack may no longer fit if a library function (used via JNI
> or internally in the JVM) increases an on-stack buffer from 1024 to 4096
> bytes, perhaps to avoid a buffer truncation/buffer overflow scenario.
> If that happens, setting a minimum stack size, irrespective of what the
> application requested, is the only way out right now.

That is all true regardless of this current TLS issue. We don't try to 
account for such things in the OS, the system libraries, the VM or the 
JDK libraries. Every action requires a certain amount of stack and that 
amount can change if you update any of the pieces in the software stack. 
In such cases if applications encounter problems it is generally up to 
the application to make adjustments to its requested stack sizes. If we 
introduce excessive stack usage in the VM then we can sometimes revert 
that. If we find that the default settings of the VM or JDK libs are no 
longer appropriate on some platform, then again we can make adjustments.

What we're looking at here is not changing the minimum stack sizes, but 
a means to expand the requested stack sizes by a set amount (based on 
knowledge of where the extra stack usage has come from.)

Thanks,
David

> Thanks,
> Florian
> 


More information about the hotspot-runtime-dev mailing list