"os" - make this a real namespace?
David Holmes
david.holmes at oracle.com
Fri Oct 21 06:12:29 UTC 2016
On 21/10/2016 4:02 PM, Rickard Bäckman wrote:
> Yes the naming was just one try. There were multiple other ways of doing
> it. Other possibilities were keeping it as is, have one file named
> os_thread.hpp per platform that includes the os_thread_x86.hpp and just
> have the #include "os_thread.hpp" in files that need it... Macros
> *shudder*.
Note that we have already abstracted platform specific includes into
macros. eg:
#include OS_CPU_HEADER(os)
#include OS_HEADER(os)
in os.hpp.
David
> /R
>
> On 10/20, Thomas Stüfe wrote:
>> 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
>>>
More information about the hotspot-runtime-dev
mailing list