RFR (M): 8023033: PPC64 (part 13): basic changes for AIX
david.holmes at oracle.com
Thu Aug 15 23:26:55 PDT 2013
Let's start a new thread on this :)
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
>>> 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 :(
> 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()
> 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"
>>> - 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
>>> Some details about the compilation problems:
>>> xlC wants initialization in inline implementation.
>>> BAD is defined in AIX system header sys/param.h. Renamed.
>>> 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?
>>> Aix defines hz to be 100, see sys/m_param.h. Renamed.
>> It #defines a lowercase constant! Ouch! :)
>>> With other include order we get a lot of
>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not
>> Curious. BTW have you tested with and without precompiled headers
>>> Please review and test this change. Comments are welcome.
>> Typo in src/share/vm/memory/universe.cpp: preserverd
>> Is this recognized as a compiler bug?
>>> Thanks and best regards,
More information about the hotspot-dev