RFR: 8170307: Stack size option -Xss is ignored

David Holmes david.holmes at oracle.com
Tue Nov 29 11:59:44 UTC 2016

Hi Thomas,

On 29/11/2016 8:39 PM, Thomas Stüfe wrote:
> Hi David,
> thanks for the good explanation. Change looks good, I really like the
> comment in capture_initial_stack().
> Question, with -Xss given and being smaller than current thread stack
> size, guard pages may appear in the middle of the invoking thread stack?
> I always thought this is a bit dangerous. If your model is to have the
> VM created from the main thread, which then goes off to do different
> things, and have other threads then attach and run java code, main
> thread later may crash in unrelated native code just because it reached
> the stack depth of the hava threads? Or am I misunderstanding something?

There is no change to the general behaviour other than allowing a 
primordial process thread that launches the VM, to now not have an 
effective stack limited at 2MB. The current logic will insert guard 
pages where ever -Xss states (as long as less than 2MB else 2MB), while 
with the fix the guard pages will be inserted above 2MB - as dictated by 


> Thanks, Thomas
> On Fri, Nov 25, 2016 at 11:38 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8170307
>     <https://bugs.openjdk.java.net/browse/JDK-8170307>
>     The bug is not public unfortunately for non-technical reasons - but
>     see my eval below.
>     Background: if you load the JVM from the primordial thread of a
>     process (not done by the java launcher since JDK 6), there is an
>     artificial stack limit imposed on the initial thread (by sticking
>     the guard page at the limit position of the actual stack) of the
>     minimum of the -Xss setting and 2M. So if you set -Xss to > 2M it is
>     ignored for the main thread even if the true stack is, say, 8M. This
>     limitation dates back 10-15 years and is no longer relevant today
>     and should be removed (see below). I've also added additional
>     explanatory notes.
>     webrev: http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>     <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>     Testing was manually done by modifying the launcher to not run the
>     VM in a new thread, and checking the resulting stack size used.
>     This change will only affect hosted JVMs launched with a -Xss value
>     > 2M.
>     Thanks,
>     David
>     -----
>     Bug eval:
>     JDK-4441425 limits the stack to 8M as a safeguard against an
>     unlimited value from getrlimit in 1.3.1, but further constrained
>     that to 2M in 1.4.0 due to JDK-4466587.
>     By 1.4.2 we have the basic form of the current problematic code:
>     #ifndef IA64
>       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur = 2 * K * K;
>     #else
>       // Problem still exists RH7.2 (IA64 anyway) but 2MB is a little small
>       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur = 4 * K * K;
>     #endif
>       _initial_thread_stack_size = rlim.rlim_cur & ~(page_size() - 1);
>       if (max_size && _initial_thread_stack_size > max_size) {
>          _initial_thread_stack_size = max_size;
>       }
>     This was added by JDK-4678676 to allow the stack of the main thread
>     to be _reduced_ below the default 2M/4M if the -Xss value was
>     smaller than that.** There was no intent to allow the stack size to
>     follow -Xss arbitrarily due to the operational constraints imposed
>     by the OS/glibc at the time when dealing with the primordial process
>     thread.
>     ** It could not actually change the actual stack size of course, but
>     set the guard pages to limit use to the expected stack size.
>     In JDK 6, under JDK-6316197, the launcher was changed to create the
>     JVM in a new thread, so that it was not limited by the
>     idiosyncracies of the OS or thread library primordial thread
>     handling. However, the stack size limitations remained in place in
>     case the VM was launched from the primordial thread of a user
>     application via the JNI invocation API.
>     I believe it should be safe to remove the 2M limitation now.

More information about the hotspot-dev mailing list