RFR: 8265473: Move os::Linux to its own header file [v4]

[Ioi Lam]

On Mon, 11 Jul 2022 06:48:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 1. Provides access control for members, which is unavailable with namespaces.
> 2. Avoids [Argument Dependent Lookup][ADL] (ADL).
> 3. Closed for additional members.  Namespaces allow names to be added in multiple contexts, making it harder to see the complete API.

I agree with Thomas that for the `os` interface, `#3` is actually the biggest disadvantage of using a class. `os` is a hodge-podge of porting interfaces. Usually no one cares what the "complete API" is (the only bad thing I can think of is that namespace allows declaration of new overloaded functions, which may make the code very hard to read; also see point `#2` below).

However, I agree `#1` and `#2` are advantages of using class.

For `#1`, even if we declare 'private' members in separate header files,  they can be easily be leaked when we have inline functions like:


/* public */ inline int os::getFoo() {
    return os::_private_foo;
}


Any file that includes `os_inline.hpp` will inadvertently see the private members. We can use naming convention to mark the members that shouldn't be accessed by outside code, but we can't use the C++ compiler to check for violations.

For `#2` (https://en.wikipedia.org/wiki/Argument-dependent_name_lookup), we can partially address it by forbidding the use of `using namespace os`. Again, this is not enforceable by the C++ compiler.

---

So without a clear consensus, I don't want to pursue the namespace solution.

But I do want to move `os::Linux` outside of os.hpp. Can we still entertain my os_linux_impl.hpp proposal for now?

Separately, we should split up the `os` class, like moving the string operations to a different header.

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

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