RFR: 8273373: Zero: Handle thread stack sizes with a generic Linux code

[Thomas Stuefe]

On Mon, 6 Sep 2021 09:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

Hi,

I do not see a reason why this would be dependent on !zero. Maybe @GoeLin did not want to deal with it, or the problem did not show up on zero in the first place. 

I think you are right in that gtestlauncher is the only launcher where we end up running in the primordial thread.

Removing ia64 code block is fine. Arguably zero may be the last variant where ia64 would still be useful. Debian seems still to build Zero+ia64 in openjdk15: https://buildd.debian.org/status/logs.php?pkg=openjdk-15&arch=ia64

About the zero gtest errors, do you understand why they only happen in other_vm resp. death tests? Something must be special here. I am curious since invoking JNI on the primordial thread may not be that well tested.

I tried to understand the primordial-thread-stack-boundaries coding, but it left a number of questions. For instance we try to find the primordial stack dimensions by:

- read /proc/self/stat, column 28 ("stackstart", bottom address)
- then we go and find the VMA containing this address, and assume the highest address of this VM is the stack top.

I am not sure the latter always works. Is that not dependent on memory layout? It relies on the process stack having its own VMA, but could the kernel not fold it with a neighboring VMA and show it as one line in /proc/self/maps? In that case, the stack start address we calculate could be bogus.

src/hotspot/os/linux/os_linux.cpp line 3371:

> 3369:       assert((uintptr_t)addr >= stack_extent,
> 3370:              "Sanity: addr should be larger than extent, " PTR_FORMAT " >= " PTR_FORMAT,
> 3371:              p2i(addr), stack_extent);

Should we not do something in non-debug builds too? Maybe guarantee() instead?

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

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