I really appreciate your great art, which facilitates high productivity compared to other products. In these years, give the opportunity to develop my improvement thought in core. During coding experiment, your resource and past experience help me a lots. Although we’re working on different ways these years, I’m looking forward to having technical discussion with you one day. Congratulate to Techholic!
I’m glad to be the early employee in your part. The unfailingly patient leader is very important to me in first job. Even though we’re good at different profession, we learned from each other to complish great big tasks these years. That is very good experience, and rare in many kinds of job career.
We cannot launch GC thread of JVM from JNI. And, it shows
1
[os,thread] Failed to start thread - pthread_create failed (EINVAL) for attributes: stacksize: 1024k, guardsize: 0k, detached.
The main reason is the glibc bugs for native C code issues. For example, we allocate thread-local variables by static library linking.
1
2
3
__thread int buf[1048576];
thread_localint buf[1048576];
#pragma omp threadprive(buf);
And then, glibc 2.12 will move them on stack, and require minimum stack size at least 1024k bytes. But, the default configuration JVM of JDK11 will minimum stacksize to be 1024k bytes as default in Linux OS. Therefore, the pthread_create throws the error EINVAL for specific stacksize setting.
The glibc library allocates some thread-local storage (TLS) in the stack of a newly created thread, leaving less stack than requested for the thread to do its work. This is particularly a problem for threads with small stack sizes. It is an inherited issue from a well-known glibc problem, ‘Program with large TLS segments fail’ [0] and has been observed in Java applications. In one of the reported JVM failure instances, the issue manifests as a StackOverflowError on the process reaper thread, which has a small stack size. The java.lang.Thread constructor enables users to specify the stack size for a new thread. The created thread may encounter the TLS problem when the specified size is too small to accommodate the on-stack TLS blocks.
In JDK 8, a system property, jdk.lang.processReaperUseDefaultStackSize, was introduced to address the TLS issue only for reaper threads. Setting the property gives a bigger stack size to the reaper threads.
To address the issue for all threads, a general purpose workaround was implemented in Java which adjusts thread stack size for TLS. It can be enabled by using the AdjustStackSizeForTLS command-line option:
When creating a new thread, if AdjustStackSizeForTLS is true, the static TLS area size is added to the user requested stack size. AdjustStackSizeForTLS is disabled by default.