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

[David Holmes]

On Fri, 10 Dec 2021 12:38:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.
>
>> Hi, @tstuefe ,
>> 
>> It’s exactly as you said. I tried to change _default_stack_size to be set in the main thread or get the stack size of other thread, but it doesn't work well. I wonder if there might be another way to do this.
> 
> I only have bad ideas:
> 
> Bad idea:
> 1) start a thread on windows with stacksize 0. Measure stack size. Now you know the stack size. Obviously bad since we pay for the startup of one whole thread, pointlessly. Whose only point of existing is to tell us its stack size. 
> 
> Slightly better idea, but still bad:
> 
> 2) set _default_stack_size=0 meaning unknown. The first thread created with stacksize=0 measures its own stack and updates that variable. Obviously bad because: too much complexity (e.g. how does the child know it was created with stacksize=0), and at least the first stacksize=0 thread will still be printed with "stacksize=0" by its parent.
> 
> Also bad, but differently bad :-) :
> 
> 3) Just measure default stack size on a developer machine, assume it is the same as on every runtime machine. Hard-code that into the VM. Obviously also bad.
> 
> So, for now I don't see a good idea. If you come up with something better, feel free. But its not a big problem tbh, so probably not worth many brain cycles.
> 
> Cheers, Thomas

Two reviews are needed for hotspot changes, so we need to wait to see if @tstuefe is okay with this.

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

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