RFR (M): 8023033: PPC64 (part 13): basic changes for AIX

[Lindenmaier, Goetz]

Hi David,

I share your irritation about the long include chains, but didn't like includeDB
too much either.  Worst are os_cpu includes, and we have 5 additional platforms :(

I would prefer most if the platform file names would not include the platform, but 
os|cpu|os_cpu.  The path is sufficient to differentiate them. Then all could be 
configured by the search paths of the compiler.
It might lead to confusion with the editors (both, tools and people), though.

As the most realistic approach I would also see dispatch files.
In many cases, there is anyways a shared file named similarly.
assembler_<cpu> is a good example how to do it, I think.

By the way, I added aix before bsd, after linux,solaris,windows.
I think a complete  alphabetic ordering would be better.  
If this is consent, I'll do the editing.

Best regards,
  Goetz.



-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Friday, August 16, 2013 8:27 AM
To: Stefan Karlsson
Cc: Lindenmaier, Goetz; 'Vladimir Kozlov'; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX

Stefan,

Let's start a new thread on this :)

David

On 16/08/2013 3:58 PM, Stefan Karlsson wrote:
> On 8/16/13 2:48 AM, David Holmes wrote:
>> Hi Goetz,
>>
>> On 15/08/2013 10:10 PM, Lindenmaier, Goetz wrote:
>>> I prepared a webrev for
>>> 8023033: PPC64 (part 13): basic changes for AIX
>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/
>>>
>>> This contains the basic shared changes needed for the AIX port,
>>> as there are
>>> - #includes
>>
>> Aside: Seeing this I'm now firmly convinced that the platform-include
>> mechanism is worse than the old includeDB mechanism that it replaced.
>> We really need a way to #include these based on the value of the
>> platform variable :(
>
> Dave,
>
> You were always firmly convinced of that. :)
>
> Do you have a solution to the platform include problem that doesn't
> involve listing _all_ includes in separate list files?
>
> In the short term, we could at least hide os_<>.inline.hpp in a dispatch
> file. Just like we did for:
>   8003935: Simplify the needed includes for using Thread::current()
> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3852
>
> Here's a list of the added includes from the AIX patch:
>    18 +# include "os_aix.inline.hpp"
>     4 +# include "orderAccess_aix_ppc.inline.hpp"
>     3 +# include "jvm_aix.h"
>     2 +# include "c2_globals_aix.hpp"
>     2 +# include "c1_globals_aix.hpp"
>     1 +# include "vmStructs_aix_ppc.hpp"
>     1 +# include "utilities/globalDefinitions_xlc.hpp"
>     1 +# include "thread_aix_ppc.hpp"
>     1 +# include "thread_aix.inline.hpp"
>     1 +# include "threadLS_aix_ppc.hpp"
>     1 +# include "os_aix_ppc.hpp"
>     1 +# include "os_aix.hpp"
>     1 +# include "osThread_aix.hpp"
>     1 +# include "interfaceSupport_aix.hpp"
>     1 +# include "globals_aix_ppc.hpp"
>     1 +# include "globals_aix.hpp"
>     1 +# include "c2_globals_ppc.hpp"
>     1 +# include "atomic_aix_ppc.inline.hpp"
>
> StefanK
>
>>
>>> - Fixes to get the code compiling with xlC/on AIX
>>
>> Are there makefile changes for xlC support as well?
>>
>>> - Basic adaptions as in vm_version.cpp.
>>>
>>> It also determines the placement and naming of the aix files,
>>> which will go to os/aix and os_cpu/aix_ppc, as you can see in
>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/
>>>
>>>
>>> Some details about the compilation problems:
>>>
>>> relocInfo.hpp:
>>> xlC wants initialization in inline implementation.
>>>
>>> vmreg.hpp:
>>> BAD is defined in AIX system header sys/param.h. Renamed.
>>>
>>> allocation.hpp
>>> xlC complains:
>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private"
>>> member "StackObj::operator delete(void *)" cannot be accessed.
>>
>> Hmmm. So the whole point of these being private was so that they could
>> not be called but we had to override the use of the global operators.
>> The concrete implementations then give fatal errors if you do manage
>> to use them (impossible?). So making them public is undesirable.
>>
>> Is there some other way to resolve this? A pragma to tell xlC to
>> ignore the perceived problem?
>>
>>> sharedRuntimeTrig.cpp
>>> Aix defines hz to be 100, see sys/m_param.h. Renamed.
>>
>> It #defines a lowercase constant! Ouch! :)
>>
>>> debug.hpp
>>> With other include order we get a lot of
>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not
>>> declared.
>>
>> Curious. BTW have you tested with and without precompiled headers
>> enabled?
>>
>>>
>>> Please review and test this change. Comments are welcome.
>>
>> Typo in src/share/vm/memory/universe.cpp: preserverd
>>
>> src/share/vm/utilities/resourceHash.hpp:
>>
>> Is this recognized as a compiler bug?
>>
>> Thanks,
>> David
>>
>>> Thanks and best regards,
>>>    Goetz.
>>>
>