"os" - make this a real namespace?

[Thomas Stüfe]

Hi David!

On Wed, Oct 19, 2016 at 9:02 AM, David Holmes <david.holmes at oracle.com>
wrote:

> 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".
>
>
I meant that it is used as one would use a C++ namespace, not a class. As
far as I see any class derived from AllStatic is actually a namespace in
the sense that it serves as bracket for a number of related static
functions.


> 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.
>
>
The "os" API is a shared, platform independent API, so there should be no
difference between platforms. There should be no need for it to export
platform specifics - its whole intent is to hide those specifics.

Looking into the various os_<os>.hpp files, I see:
1) things where the declaration does differ between oses and therefore they
cannot be called in shared code without #ifdefs (e.g. all <os> subclasses).
2)Things where the declaration is shared but the implementation differs.
Again, two cases:
    a) Either implementation is not time critical. In that case the
declaration should live in os.hpp and the implementation should live in
some platform dependent C++ file.
    b) Or implementation is time critical and must be inline, in which case
a separate platform dependent header would be needed.

For (1) and (2b), C++ namespaces would be more convenient. Now, you are
forced to include the platform specific file into the class os{}
declaration, because there can just be one:

os.hpp
class os {
...
#include <os_xxx.hpp>

};

. With a namespace, you can add functions to the namespace in various
disjunct places and hence could write:

os.hpp
namespace os { ... functions ... }

os_xxx.hpp
namespace os { ... functions ... }

which would be more natural and



> 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.


Right now os_<os>.hpp exports the os::<os> api, which one may want to use
separately from "os" because they expose platform dependent APIs which are
conceptionally lower than the os namespace. At least that is how I always
did interpret the intention behind os::<os>.

But actually, because the "Aix" class is part of "os", cannot be used
separately and is exposed to the whole of the VM, I always avoided putting
anything os::Aix if it could be helped. Hence, for AIX, we added
porting_aix.hpp for AIX specific functions which are not to be used outside
os/aix/vm. Or mostly just plain left functions to be file scope static
inside os_aix.cpp. So, os::Aix was pretty useless for me as a porter.


>
>
> 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.
>
>
We start using all kinds of modern C++ features. Templates pop up all over
the place. Namespaces in contrast are an old and easily understood feature.
We already use it inside our own port.


> 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 ??
>
>
I think there is no real reason for os::Bsd to exist at all. Either we have
shared functions with platform dependent implementation, then they should
be declared in "os". Or they are completely platform specific, then they
can be moved to a platform specific header outside of "os" like we did with
porting_aix.hpp.

 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.
>
>
Sure!

Kind Regards, Thomas


> Cheers,
> David
>
>
> Thanks, and Kind Regards, Thomas
>>
>>