JDK-4362291 : Stack size argument ignored (-Xss and -ss)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux,windows_nt
  • CPU: x86
  • Submitted: 2000-08-14
  • Updated: 2012-11-02
  • Resolved: 2000-12-14
Related Reports
Relates :  
JDK-4349646 - JNI EXCEPTION_STACK_OVERFLOW outside the VM
Description

Name: rl43681			Date: 08/14/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

The java command in the 1.3 SDK appears to ignore the -Xss (and -ss) argument, and there
does not appear to be another way to specify stack size.  This results in a
stack overflow during a call to a JNI function.  The java command accepts a -Xss
argument, but always sets the stack to 256K (starting at approximately
0x06F788) regardless of the -Xss specification.  This means that my application,
which works fine with the JDK 1.2 does not work with 1.3.  The particular call
that results in the stack overflow is a call to the system service() function
for I/O on a socket.  This requires over 200K of stack space.

You can reproduce (or at least verify) this issue with
any JNI application.  Simply insert the following code near the beginning:

void * stack_ptr;
__asm mov stack_ptr, esp;
printf("ESP = %X\n", stack_ptr);

This prints the address of the top of the stack.  You'll see that it's the
same (about 0x68000) regardless of what's specified for -Xss.

(Review ID: 108285) 
======================================================================
Comments
WORK AROUND Don't use the primordial thread to do your work in. All other threads will have the correct stack size. If you absolutely must use the primordial thread, you can change the initial stack size using editbin.exe: Changing the reserved stack size back to, say, 1Mb is done using the Microsoft Binary File Editor (EDITBIN.EXE) EDITBIN /STACK:1048576 java.exe
11-06-2004
EVALUATION Okay, so I've verified that the stacks are being created at the requested size. Its possible that we're installing guard pages in the wrong spot and simulating a smaller stack. james.mcilree@eng 2000-12-12 The stacks are being created at different sizes, but we're overflowing at the same spot always. I'm looking at the guard page code now. james.mcilree@eng 2000-12-13 Okay, here is what is happening. The primordial stack isn't being affected by the -Xss argument, because its already been created when we parse the -Xss argument. If you run a test on any other thread, they are getting the correctly sized stack. james.mcilree@eng 2000-12-13 I've talked with some other runtime group members, this is a known problem. The issue is that the stack size for the primordial thread is set before we even parse the -Xss line, and there is no way to change it. The easiest and most portable solution is to do your work in another thread, instead of using the primordial thread. I'm closing this as WNF. james.mcilree@eng 2000-12-14
14-12-2000