JDK-8189170 : Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2017-10-11
  • Updated: 2021-02-01
  • Resolved: 2017-11-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8 Other
10 b34Fixed 8u192Fixed openjdk8u292Fixed
Related Reports
CSR :  
JDK-8189423 - Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM
Relates :  
JDK-8242552 - Use system stack size with primordial thread
Relates :  
JDK-8257192 - Integrate AArch64 JIT port into 8u
Description
A DESCRIPTION OF THE REQUEST :
Non-Java language runtimes sometimes interoperate with the JVM via JNI, starting the JVM via JNI_CreateJavaVM. R is one such language runtime (with its rJava package). This leads to issues when both language runtimes attempt to do stack overflow checking on the same (initial) thread. It would be nice to have an option to disable stack overflow checking (not insert guard pages) to the stack of the initial thread of the JVM 

JUSTIFICATION :
In a way the initial thread is owned by the runtime that calls CreateJavaVM, the thread might have been created by it, and so the JVM should not take space from that thread's stack, not even space to insert guard pages. On Linux in Java 9 and older, the situation now is particularly bad as Java caps the stack size at 2M (inserts guard pages) no matter what the stack size established by rlimit is. The cap was a workaround for a bug in old Linux systems (JDK-4466587) and has been removed for Java 10 (in response to JDK-8170307). However, there is now a new cap of 8M for stack that is unlimited by rlimit. In theory, the language runtime that calls CreateJavaVM could set a finite rlimit before initializing the JVM, but really, simple option to disable the guard pages would be a lot simpler and cleaner solution. With such option, language runtimes calling CreateJavaVM would be unaffected by  OS-specific workarounds for handling stack size and stack overflow in the JVM, which may indeed otherwise be needed for standalone use of Java.
Comments
The alternative to doing something in the VM is for R (or whoever) to create the a new thread, similar to ContinueInNewThread in the java launcher.
14-11-2017
On Linux, AIX and Solaris we already have existing mechanisms that identify the primordial/initial process thread. On Windows there seems to be no way to easily and/or reliably determine whether you are in the primordial (primary in win32 terms) thread. But on Windows we have never tried to treat the primordial thread differently to any other thread - so we can continue to ignore the distinction. On OSX the pthread APIs are used, which provide no means to directly identify the main thread. Interestingly the NSThread class does provide an API to identify and retrieve the "main" thread - though it is unclear if that "main" thread is truly the process primordial thread or simply the initial thread for that particular threading library. Regardless we don't try to do anything special with the primordial thread so again we can just leave it that way. BSD shares the OSX code. The proposal is that we elevate os::XXX:is_initial_thread (where it exists) to os::is_initial_thread. On Windows, BSD and OS X this will simply return "false". We then modify void JavaThread::create_stack_guard_pages() { if (!os::uses_stack_guard_pages() || ! _stack_guard_state != stack_guard_unused || + (DisablePrimordialThreadGuardPages && os::is_initial_thread())) { return; }
14-11-2017
Yes, not using the primordial thread is a potential workaround - though R is single-threaded so they understandably don't want to introduce a separate thread to deal with this. The aim here was to do something quite simple that assisted with the problem while not affecting normal java launcher operation is any way.
14-11-2017
This also means that if using -XX:+DisablePrimordialThreadGuardPages that -Xss has no affect on the primordial thread.
11-10-2017
Correction to the description. The cap has been removed in Java 9 and in 8u, except for the case of unlimited stack in which case it is set to 8M. This request is for the option to disable insertion of Java guard pages if the VM is created on the primordial process thread. I support this request as an aid to non-Java runtimes. It has no affect on OpenJDK operation as our launchers always create a new thread to load the VM and so never do so on the primordial thread. Suggest: -XX:+/-DisablePrimordialThreadGuardPages (default: false)
11-10-2017
This is an enhancement request to disable stack overflow checking in initial thread for use with JNI_CreateJavaJVM. Forwarding development team's evaluation
11-10-2017