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

[David Holmes]

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?

@tkiriyama apologies for my confusion over this. So ... 

On Posix systems we read back the value of the stackSize from the pthread-attr object used to create the pthread. Very simple and accurate. 

On Windows there is no direct way to query the stackSize of the thread that was just created. Instead we used the requested stackSize: if it is > 0 then we assume we get what we asked for. If it is zero then it means use the VM default stackSize for JavaThreads - which is `ThreadStackSize` and which can be set directly or by `-Xss`. If that value is > 0 then again we assume the size of the stack we get is the size that we asked for. If `ThreadStackSize` itself is zero (the default value for Windows) that means "tell the operating system to use its own default" - and that is where we currently will print `stacksize: default` because we don't know what that operating system default is.

What this patch does is replace "default" with the value from `os::win32::default_stack_size()` which is set by calling `os::current_stack_size()` on the main thread during VM initialization. As the main thread is created by the launcher using the `-Xss` value (if set) the main thread's stack does represent the "default stack size" for all Java threads. So that sounds good.

The problem I have here is not with this patch per se, it is that `os::current_stack_size()` also has no direct way to query the stack size of the current thread. What it does is to use `VirtualQuery` passing in a stack allocated data structure, and asks for the `AllocationBase` for that structure. That in turn is the base address for the set of pages allocated by `VirtualAlloc` that are contiguous to and have the same state (regarding mapping and protection etc) as the address on the stack. So if the stack is allocated via a `VirtualAlloc` call as one coherent set of pages, then this gives us the base address of that set of pages. We then subtract that value from the one obtained from `os::current_stack_base()` to get the stack size. Where `os::current_stack_base()` itself uses `VirtualQuery` in a similar way to try to find the other end of this page range. The process is quite complex - more complex than I would expect as it tries to account for distinct regions that all have the s
 ame `AllocationBase` - which is not something that really makes sense to me. But at the end of that we will have a number that at least approximates the size of the stack of the main thread, and hence the default stack size.

It would be interesting (and I will try it out) to see what `os::win32::default_stack_size()` actually reports for different `-Xss` values.

Meanwhile I will approve the fix, but please update the test as requested. You will also need a second reviewer.

Thanks,
David

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

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