RFR: 8277531: Print actual default stacksize on Windows thread logging

[Thomas Stuefe]

On Fri, 3 Dec 2021 09:29:59 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> On 26\/11\/2021 10\:33 pm\, Takuya Kiriyama wrote\:
>>> On Mon\, 22 Nov 2021 09\:22\:39 GMT\, Takuya Kiriyama \<duke at openjdk\.java\.net> wrote\:
>>> 
>>>> I modified to log actual stack size on Windows by using \`os\:\:win32\:\:default\_stack\_size\(\)\`\.
>>>> Could you please review this fix\?
>>> 
>>> Thank you so much for your review\.
>>> Sorry it took me so long to understand discussion\.
>>> 
>>> Is there something wrong to print out the value of default\_stack\_size\?
>>> I could not confirm the problem when I combine \-Xss with \-XX\:ThreadStackSize\.\, but it doesn\'t affect this patch\.
>> 
>> The problem is that os\:\;win32\:\:default\_stack\_size\(\) doesn\'t necessarily 
>> report the default stack size \- it simply reports the stackSize of the 
>> initial main JavaThread thread\. So if you print it\, it should only be 
>> for JavaThreads that are not CompilerThreads\.
>> 
>> But if you run \"java \-Xss256k \-XX\:ThreadStackSize\=512K\" it will print 
>> 256K as the default stack size when in fact all JavaThreads except the 
>> main thread will get a 512K stack because of ThreadStackSize\.
>> 
>> So given you can\'t actually print a value that you know to be correct\, 
>> it may be best just to leave this as \"default\" \- and perhaps this is why 
>> it was that way to begin with\.
>> 
>> Cheers\,
>> David
>
>> The problem is that os:;win32::default_stack_size() doesn't necessarily
>> report the default stack size - it simply reports the stackSize of the
>> initial main JavaThread thread. So if you print it, it should only be
>> for JavaThreads that are not CompilerThreads.
> 
> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed.
> According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread.
> default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
> 
>> But if you run "java -Xss256k -XX:ThreadStackSize=512K" it will print
>> 256K as the default stack size when in fact all JavaThreads except the
>> main thread will get a 512K stack because of ThreadStackSize.
> 
> Yes,this behavior is odd. However, this fix executed only if stacksize is not specified.
> This problem should be fixed in another issue.

Hi, @tkiriyama,

> > The problem is that os:;win32::default_stack_size() doesn't necessarily
> > report the default stack size - it simply reports the stackSize of the
> > initial main JavaThread thread. So if you print it, it should only be
> > for JavaThreads that are not CompilerThreads.
> 
> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed. According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread. default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.

Nope, unfortunately not. It runs on the thread invoking CreateJavaVM(). That is usually not the OS main thread (aka primordial thread). In the case of the standard java launcher, the primordial thread spawns a second thread to invoke CreateJavaVM() in, mainly to impose -Xss. In the case of a custom launcher, all bets are open which thread invokes CreateJavaVM(), but typically it's not the primordial thread either. In fact, we have platforms that explicitly forbid invoking CreateJavaVM() on the primordial thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6495