FULL PRODUCT VERSION :
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

FULL OS VERSION :
15.5.0 Darwin Kernel Version 15.5.0

A DESCRIPTION OF THE PROBLEM :
When you specify a stack size >= 2GB there is an overflow in the calculation that causes the value to be garbage.



THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
for i in {1..8}; do echo "${i}G:"; java -Xss${i}g -XX:+PrintFlagsFinal -version 2>&1 | grep ' ThreadStack'; done
1G:
     intx ThreadStackSize := 1048576 {pd product}
2G:
     intx ThreadStackSize := 18014398507384832 {pd product}
3G:
     intx ThreadStackSize := 18014398508433408 {pd product}
4G:
     intx ThreadStackSize := 0 {pd product}
5G:
     intx ThreadStackSize := 1048576 {pd product}
6G:
     intx ThreadStackSize := 18014398507384832 {pd product}
7G:
     intx ThreadStackSize

EXPECTED VERSUS ACTUAL BEHAVIOR :
Correct stack size would be set.

Stack size ends up as garbage
REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
The bug is here: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/file/ae5624088d86/src/share/vm/runtime/arguments.cpp#l2885

The conversion to an int gets sign extended to `Register` on 64bit, which causes the value to end up overflowed:

2GB: 0x80000000
Gets sign extended to: 0xFFFFFFFF80000000
This gets divided by 1024 (0x400):-

0x3FFFFFFFE00000 == 18,014,398,507,384,832

Which is the value that comes out in the print of final options.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Don't set the stacksize to >= 2GB

or explicitly use the -XX:ThreadStackSize parameter

TBH it should be fixed for correctness, but it's not like anyone would actually use a 2GB stack.