We have 3 stack size related runtime flags:

ThreadStackSize
VMThreadStackSize
CompilerThreadStackSize

that have a "magical" value of 2048 set on aarch64 platforms and a value of 1024 on x86_64 (and 512 on 32 bit x86)

The values come from various practical approaches and might have to be updated with new OS, platforms, architectures, features, etc.

The current value of 2048 on Linux aarch64 comes from LargePage requirement (still trying to nail down more details here) https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2013-July/000092.html

macOS aarch64 doesn't (currently) support large page, so it probably would be OK with a lower value, but since it was a direct port based on Linux aarch64, it inherited those values.

More background:

In https://bugs.openjdk.java.net/browse/JDK-8140520 we had a problem with TestOptionsWithRanges.java that would crash (on Solaris) with a value of "1". A value of "1" does not really make sense here, but since "0" was allowed, as a special value meaning "use system default", then the test wouldn't know any better and would try the next larger number, and crash. To work around the issue, and since we didn't like "0" as a special value, we have bumped up the value to something we thought was reasonable.

According to http://xmlandmore.blogspot.com/2014/09/jdk-8-thread-stack-size-tuning.html stack sizes are allocated RAM, not just reserved, and they also needed to be zeroed out, which takes time, so we should keep them as small as possible.

If large pages is turned ON, then we should bump up the sizes on those platforms that support large pages.

Otherwise we should let the OS dictate the system default values.

Hardcoding them, as they are right now, means more maintenance and higher resource usage if they are not tuned (and they do not seem to be tuned)

We should revert back to using system defaults, and we should find a mechanism for specifying that, since we are not happy with using "0" as the default value.