RFR (M): 8023033: PPC64 (part 13): basic changes for AIX
david.holmes at oracle.com
Thu Aug 15 17:48:19 PDT 2013
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
> - 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 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
Is this recognized as a compiler bug?
> Thanks and best regards,
More information about the hotspot-dev