RFR: JDK-8243991 Use standard -Xss argument in java command line

[Magnus Ihse Bursie]

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 
>>>>
>>