"os" - make this a real namespace?

[David Holmes]

Hi Thomas,

On 19/10/2016 4:10 PM, Thomas Stüfe wrote:
> Hi all,
>
> a small question.
>
> I sometimes stumble over the fact that "os" is a class, not a namespace.

?? AFAIK everything in hotspot is a class not a namespace - we don't use 
"namespaces".

> And that we include the platform dependent additions into the middle of
> this class.

Build-time specialization. It allows for the os API to actually be 
different on different platforms, as opposed to just being implemented 
differently.

> This has a number of repercussions, like not being able to include the
> platform dependent files (os_<os>_<cpu>) directly, not being able to

I'd call that a feature - they are not intended to be standalone APIs.

> forward declare functions from the "os" namespace (e.g. os::malloc) etc. I
> also cannot split implementations from "os" functions to different
> implementation files without problems.
>
> It seems to me all compiler nowadays support namespaces, would it not make
> sense to convert "os" to a real namespace?

Not being a C++ aficionado I'm not sure exactly what that would entail - 
as far as I know we don't use C++ namespaces anywhere in hotspot.

> While we are at it, what is the reason for the "<os>" sub classes? e.g.
> os::Bsd, os::Aix etc? It makes integrating patches between platforms
> difficult and, to me, does not seem to serve any clear purpose.

Must admit this arrangement has also had me confused at times. I think 
it is way to add a per-OS helper class for the main os API implementation.

> If the purpose is to be a very low wrapper around OS particularities, it
> makes no sense to have them in the "os" namespace and to make them visible
> to the shared sections of the VM. E.g. there should be no reason to access
> "os::Bsd" functions from outside os/bsd/vm, or to access "os::Posix"
> functions outside implementations specific for Posix platforms.

Not sure how you make, for example os::BSD accessible from all classes 
in os/bsd/vm yet not be visible anywhere else ??

Plus it also needs to potentially be visible from os_cpu/bsd_XXX/vm.

There is a lot of cleanup in this area slated for the future - hopefully 
Java 10. POSIX refactoring etc.

Cheers,
David

> Thanks, and Kind Regards, Thomas
>