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