RFR: 8290840: Refactor the "os" class [v3]

[Ioi Lam]

On Tue, 2 Aug 2022 07:12:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR.
> 
> I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS.
> 
> This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution.
> 
> I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too.
> 
> I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs.

Thanks for pointing this out. I've updated the comments in os.hpp to be more clear about the inline functions.

The design is -- if `os.hpp` declares an "inline" function without a body, the implementation must be  in `os_<os>.inline.hpp`  or `os_<os>_<cpu>.inline.hpp`.  It's not possible for some platforms to choose to implement such a function in a .cpp file.

Conversely, if a function is NOT declared "inline" in `os.hpp`, it must NOT be implemented in any of the `os*inline.hpp` files.

Hence, any source file that references this function must include `os.inline.hpp`.

Without such a rule, it's possible for the build to succeed on some platforms (especially if the compiler is more lenient on missing inline function definitions) and fail on others. As a result, it would be easier to break the repo as not everyone is able to build all platforms before integrating a PR.

This rule is similar to how we handle "inline" declarations in regular HotSpot headers.

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

PR: https://git.openjdk.org/jdk/pull/9600