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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Fri Aug 16 14:28:05 PDT 2013

Hi Stefan,

the problem is that globalDefinitions defines __STDC_FORMAT_MACROS.
inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and
globalDefinitions.hpp through globalDefinitions_<compiler>.hpp.
If jvm.hpp comes first, inttype.hpp is added without the macro defined,
and the print formats are missing.

I could also define __STDC_FORMAT_MACROS in jni.hpp or the like.

The name "globalDefinitions" somehow says that the definitions should be seen
everywhere ... so it's basically bad that the file does not end up at the top of the include
chain.  Maybe I should include it in jni.hpp? or jvm.hpp?

What do you think?

Best regards,

From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Friday, August 16, 2013 3:09 PM
To: Lindenmaier, Goetz
Cc: 'Vladimir Kozlov'; 'David Holmes'; '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

Hi Goetz,

On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote:


- I removed the throw()

- I removed the #ifndef in port.hpp

- I fixed the typeo.


I always build without precompiled headers, the nightbuild with



-#include "prims/jvm.h"

 #include "utilities/globalDefinitions.hpp"

+#include "prims/jvm.h"

I don't think your change to debug.hpp is the correct way to solve the problems you were seeing with metaspace.hpp. Swapping the files just means that someone else might hit the same problem adding prims/jvm.hpp to another file.

You probably have a circular include dependency somewhere in the code. Could you revert the change to utilities/debug.hpp and try to figure out what the real problem is?



Yes, there will be makefiles for aix, and the platform files.  tTe prototype

patches are here



But the make change contains mostly new files, except for

--- a/make/defs.make     Tue Jul 23 21:07:11 2013 +0200

+++ b/make/defs.make     Tue Jul 23 22:13:05 2013 +0200

@@ -166,11 +166,15 @@

   HOST := $(shell uname -n)


-# If not SunOS, not Linux and not BSD, assume Windows

+# If not SunOS, not Linux not BSD and not AIX, assume Windows

 ifneq ($(OS), Linux)

   ifneq ($(OS), SunOS)

     ifneq ($(OS), bsd)

-      OSNAME=windows

+      ifneq ($(OS), AIX)

+        OSNAME=windows

+      else

+        OSNAME=aix

+      endif




Best regards,


-----Original Message-----

From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]

Sent: Friday, August 16, 2013 7:21 AM

To: David Holmes

Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>'; 'hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>'

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

I thought trow() was added long time ago. But it was added, I think by accident, very recently:


I missed it when I did the review of those changes.

We should remove throw.


On 8/15/13 5:14 PM, David Holmes wrote:

On 16/08/2013 7:54 AM, Vladimir Kozlov wrote:

On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote:

Hi Vladimir,

throw is needed because it`s there in the implementation in nmethod.cpp.

(So you are using it a bit at least :))

xlc says

"nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator

new(size_t, int)" has a conflicting declaration.

"nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on

line 268 of "nmethod.hpp".

Okay, it is just declaration.

Why do we have throw here:

void* nmethod::operator new(size_t size, int nmethod_size) throw () {

   // Not critical, may return null if there is too little continuous memory

   return CodeCache::allocate(nmethod_size);


Seems to me it should be removed if anything.



int64 is defined correctly, uint64 is not defined, but never used in


I can not reproduce an error, but that's rather old coding from our VM.

We also switched from xlc8 to xlc10 in the course of this project.

I will test some more and talk to the person who implemented that


and if possible remove the change.

Okay, I will test it also.


Best regards & thanks for the review,


-----Original Message-----

From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]

Sent: Thursday, August 15, 2013 5:52 PM

To: Lindenmaier, Goetz

Cc: 'hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>'; ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>;

Albert Noll (albert.noll at oracle.com<mailto:albert.noll at oracle.com>)

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


I only see 2 problems which you did not explain:

nmethod.hpp. Why the next change? we don't use C++ exceptions:

-  void* operator new(size_t size, int nmethod_size);

+  void* operator new(size_t size, int nmethod_size) throw ();

port.hpp. Did AIX has the same definitions for jlong and julong?:

+#ifndef _AIX

+// These conflict with /usr/include/sys/inttypes.h on aix.

   typedef jlong int64;            // Java long for my 64-bit type

   typedef julong uint64;          // Java long for my 64-bit type


And of cause we need to test these changes with compilers we use.



On 8/15/13 5:10 AM, 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

- Fixes to get the code compiling with xlC/on AIX

- 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.


Aix defines hz to be 100, see sys/m_param.h. Renamed.


With other include order we get a lot of

memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not


Please review and test this change. Comments are welcome.

Thanks and best regards,


More information about the hotspot-dev mailing list