"os" - make this a real namespace?

[Thomas Stüfe]

Hi Rickard,

I definitely like some of the aspects of that patch. But like others I'm
not a big fan of renaming the files - I like the current naming scheme
<os>_<cpu> just fine, I am used to it and it helps me in many places. I
work both in IDEs (CDT) and on the command line with vi and grep, and
having the platform in the file name makes it a easier to work with
multiple platforms. I am also quite sure that having different versions of
a file with the same name in some locations would bite us at some places.

Kind Regards, Thomas


On Thu, Oct 20, 2016 at 10:27 AM, Rickard Bäckman <
rickard.backman at oracle.com> wrote:

> Hi Thomas,
>
> I tried something like that a couple of years ago and still think it is
> a good idea.
>
> Link to the discussion and patches:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008884.html
>
> /R
>
> On 10/19, Thomas Stüfe wrote:
> > Hi all,
> >
> > a small question.
> >
> > I sometimes stumble over the fact that "os" is a class, not a namespace.
> > And that we include the platform dependent additions into the middle of
> > this class.
> >
> > This has a number of repercussions, like not being able to include the
> > platform dependent files (os_<os>_<cpu>) directly, not being able to
> > 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?
> >
> > 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.
> >
> > 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.
> >
> > Thanks, and Kind Regards, Thomas
>