On AIX, we run into intermittent StackOverflows during certain tests, see e.g. JDK-8173817. When analysing, I see variations of the following output (-Xlog:os+thread):

[2.483s][info][os,thread] Thread started (pthread id: 20047, attributes: stacksize: 384k, guardsize: 0k, detached).
[2.484s][info][os,thread] Thread is alive (tid: 20047, kernel thread id: 62980151, stack [0x000000011f23d888 - 0x000000011f29b110 (374k using 4k pages)).

Notice: thread is created with 384k stack size but, when started, only has 374k. The delta in this case is -10Kb, but experiments show that it can be as large as 58Kb.

So, we prepare the thread start with pthread_attr_setstacksize, then call pthread_create. In newborn thread we query the stack bounds using pthread_getthrds_np(). This value is smaller than what we did request, by some variable and random amount.

This hurts in situations where the stack is small. Minimum user-usable stack size is currently 64K (see os_aix_ppc.cpp):

// Minimum usable stack sizes required to get to user code. Space for
// HotSpot guard pages is added later.
size_t os::Posix::_java_thread_min_stack_allowed = 64 * K;

But if the OS gives us up to 64K less space than what is requested (see comments), we will hit StackOverflow Errors almost immediately.

Note that this affects more situation than may be appearant at the first glance, because the VM guard areas need to be deducted from the Xss stack size, so any value below -Xss 384K is affected by this behaviour.