I came across this issue when answering the question at
https://stackoverflow.com/questions/59518898/why-doesnt-larger-xss-give-bigger-maximum-stack-depth

The above example shows that the effect of -Xss160k is completely different from -Xss159k and -Xss161k.

-Xss argument is processed twice: first by the launcher, then by the JVM. The launcher (libjli/java_md_solinux.c) simply calls pthread_attr_setstacksize(&attr, stack_size) without preprocessing the argument.

The behavior of pthread_attr_setstacksize differs on Linux and Mac OS X. E.g. the documentation https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/pthread_attr_setstacksize.3.html explicitly says that the function returns EINVAL, if stacksize is not a multiple of the system page size. The launcher silently ignores the error and continues with the default stack size. So, even if I run java -Xss3333k, the main thread will still have 512 KB stack size on macOS.

HotSpot, however, rounds ThreadStackSize to the page boundary, so new threads will have the correctly adjusted stack size.

The suggested fix is to round Xss in the launcher, too, in order to have the consistent behavior between main and other threads on all platforms.