-
Bug
-
Resolution: Fixed
-
P4
-
19, 20
-
b09
-
linux_alpine
Use of std::thread causes problems in non-glibc systems (e.g. Alpine).
std::thread makes no assumption about the stack size of the created threads. There is no way to specify a stack size via std::thread for philosophical C++ reasons [1][2].
On Linux, std::thread is implemented by libstdc++, which just does a pthread_create() without setting the stack size. Therefore, we use whatever the system default is for pthread stack size. That one is implementation-dependent: on glibc, it depends on the RLIMIT_STACK of the calling thread. On muslc, being written with small memory footprints in mind, the default stack size is hard-wired to 128k [3].
Of course, both variants allow overwriting the stack size prior to thread creation with pthread_attr_setstacksize(). So if we were to use Posix threads, we'd have no problem. The problem is that std::thread does not offer this ability.
Therefore, if we want to be portable across systems, we must not use std::thread.
----
The small muslc stack size leads to problems across multiple Panama tests that do asynchronous upcall into the JVM and then crash out in varying places with SOE:
```
config TestUpcallBase.setup(): success
test TestUpcallAsync.testUpcallsAsync(0, "f0_V__", VOID, [], []): success
----------System.err:(13/1115)----------
java.lang.StackOverflowError
at java.base/java.lang.ClassLoader.defineClass0(Native Method)
at java.base/java.lang.System$2.defineClass(System.java:2369)
at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2449)
at java.base/java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:321)
at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:753)
at java.base/java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:849)
at java.base/java.lang.invoke.Invokers.varHandleMethodGenericLinkerHandleForm(Invokers.java:423)
at java.base/java.lang.invoke.Invokers.varHandleInvokeLinkerMethod(Invokers.java:370)
at java.base/java.lang.invoke.MethodHandleNatives.varHandleOperationLinkerMethod(MethodHandleNatives.java:578)
at java.base/java.lang.invoke.MethodHandleNatives.linkMethodImpl(MethodHandleNatives.java:482)
at java.base/java.lang.invoke.MethodHandleNatives.linkMethod(MethodHandleNatives.java:470)
at java.base/java.lang.foreign.MemorySegment.set(MemorySegment.java:1420)
```
I see this at least for
- java/foreign/enablenativeaccess/TestEnableNativeAccess.jtr
- java/foreign/TestUpcallAsync.java.
but there are more uses of std::thread.
--------
[1] https://www.reddit.com/r/cpp/comments/8izd5g/really_no_way_to_set_stack_size_of_stdthread_what/
[2] https://stackoverflow.com/a/13871812/3689118
[3] https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-stack-size
std::thread makes no assumption about the stack size of the created threads. There is no way to specify a stack size via std::thread for philosophical C++ reasons [1][2].
On Linux, std::thread is implemented by libstdc++, which just does a pthread_create() without setting the stack size. Therefore, we use whatever the system default is for pthread stack size. That one is implementation-dependent: on glibc, it depends on the RLIMIT_STACK of the calling thread. On muslc, being written with small memory footprints in mind, the default stack size is hard-wired to 128k [3].
Of course, both variants allow overwriting the stack size prior to thread creation with pthread_attr_setstacksize(). So if we were to use Posix threads, we'd have no problem. The problem is that std::thread does not offer this ability.
Therefore, if we want to be portable across systems, we must not use std::thread.
----
The small muslc stack size leads to problems across multiple Panama tests that do asynchronous upcall into the JVM and then crash out in varying places with SOE:
```
config TestUpcallBase.setup(): success
test TestUpcallAsync.testUpcallsAsync(0, "f0_V__", VOID, [], []): success
----------System.err:(13/1115)----------
java.lang.StackOverflowError
at java.base/java.lang.ClassLoader.defineClass0(Native Method)
at java.base/java.lang.System$2.defineClass(System.java:2369)
at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2449)
at java.base/java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:321)
at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:753)
at java.base/java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:849)
at java.base/java.lang.invoke.Invokers.varHandleMethodGenericLinkerHandleForm(Invokers.java:423)
at java.base/java.lang.invoke.Invokers.varHandleInvokeLinkerMethod(Invokers.java:370)
at java.base/java.lang.invoke.MethodHandleNatives.varHandleOperationLinkerMethod(MethodHandleNatives.java:578)
at java.base/java.lang.invoke.MethodHandleNatives.linkMethodImpl(MethodHandleNatives.java:482)
at java.base/java.lang.invoke.MethodHandleNatives.linkMethod(MethodHandleNatives.java:470)
at java.base/java.lang.foreign.MemorySegment.set(MemorySegment.java:1420)
```
I see this at least for
- java/foreign/enablenativeaccess/TestEnableNativeAccess.jtr
- java/foreign/TestUpcallAsync.java.
but there are more uses of std::thread.
--------
[1] https://www.reddit.com/r/cpp/comments/8izd5g/really_no_way_to_set_stack_size_of_stdthread_what/
[2] https://stackoverflow.com/a/13871812/3689118
[3] https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-stack-size
- relates to
-
JDK-8292352 32-bit Windows build failures after JDK-8290059
-
- Resolved
-
-
JDK-8290460 Alpine: disable some panama tests that rely on std::thread
-
- Resolved
-