On 2020-04-28 18:33, Erik Joelsson wrote:
On 2020-04-28 09:14, Magnus Ihse Bursie wrote:
It builds without it. I tested running the tier1 test suite; but I
assume that if the build succeeds there's really all there is to it.
I'm not sure where to look for performance issues. Is there some
specific thing you're worried about? If anything, I think this might
be affecting machines with different memory sizes differently, but
I'm not really in the mood to try this on a wide range of machines
just to find that out.
Otherwise I'd assume you'd either get a stack overflow exception, or
everything is green. Shrinking the stack size could possibly mean
that the build will pass on low-end machines where it previously failed.
I did a bit of digging in the bug database and these settings are very
old. Here is a quote from a comment on a build problem on Solaris
Sparc 64 bit from 2001:
"There is a comment in the VM source tree which stated that the
ThreadStackSize needed to be increased to 512K in order to build the
JDK. The 64 bit VM uses twice as much memory as the 32 bit VM so it
might be worth increasing the ThreadStackSize for the JAVAC operations
to 1024K for 64 bit builds. The jdk builds currenty use 768K
ThreadStacks."
I think this makes it clear that the intention was to increase the
size of the thread stacks and at the time it was needed to even make
it build. I believe the JVM has matured enough since then to safely
remove these options now.
I traced the lineage of the XX:ThreadStackSize=1536 argument. It goes
back to the very first "Initial load" commit by Mr J. Duke, so the
origin is lost in the mist of the original proprietary Sun code base.
I think we can safely assume that we can remove that argument. :-) I'll
post an updated webrev shortly.
/Magnus
/Erik
