On 2020-04-28 16:28, Erik Joelsson wrote:
On 2020-04-28 03:49, Magnus Ihse Bursie wrote:
On 2020-04-28 12:17, David Holmes wrote:
Hi Magnus,
On 28/04/2020 7:42 pm, Magnus Ihse Bursie wrote:
We should use the official -Xss argument[1] in command lines,
instead of the non-standard -XX:ThreadStackSize.
Bug: https://bugs.openjdk.java.net/browse/JDK-8243991
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8243991-fix-Xss-in-java-args/webrev.01
This isn't right. ThreadStackSize takes a value in KB, whereas -Xss
is a value in bytes. You won't be able to even start the VM with the
values you have specified.
Hm, I need to double-check that. I've extracted this as a separate
fix for another bug I've been working on, since it was mostly
unrelated to that fix, but I had no issues starting the VM.
I fail to understand, though, why we use this peculiar value for the
stack size. Now that you mention it, I'm not even sure if that the
original author intended this to be in bytes or kilobytes. My gut
feeling is that 1536 bytes is a very small stack, and 1536 kB is a
very large stack. I always assumed that the intention was to make the
stack smaller than the default (which is, if I understand the
documentation correct -- and the documentation corresponds to
reality) 1024 kB, to make apps that spawn a large number of threads
take less memory. But if your statement is correct it is actually
making the stacks 50% larger!
Maybe I need to expand on this patch a bit and check different values
of the stack size. And maybe we should not even set the argument at
all, if we can build correctly without it.
Do you see any reason to keep the argument if we can build fine
without it?
I really don't know the history on why those values are set. If the
build works without, and there is no significant performance loss,
then I would vote remove.
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.
/Magnus
/Erik
/Magnus
Cheers,
David
/Magnus
[1]
https://docs.oracle.com/en/java/javase/14/docs/specs/man/java.html#extra-options-for-java
