- ppc-aix-port-dev - openjdk.org

PPC/AIX Port Status Update
by Volker Simonis 23 Oct '12

23 Oct '12

Hi, as you may have noticed, I've just pushed two changesets: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1efaab66c81d http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/a06818b39f7c which enable the VM to run JVM98 and bootstrap itself on AIX. One bigger part which still doesn't work is AWT/Swing because of some FontConfig issues. I don't think that there are really fundamental problems there, but I just had no time to look into it until now. If the nightly build will succeed today (still with the IBM J9 bootstrap JDK), I'll change the build to use the newly build version as of tomorrow for bootstrapping. If that will be successful as well, I'll tag the corresponding repository versions as 'ppc-aix-port-b02' and upload a binary of that version for your convenience. I'm currently also updating the README-ppc.html file with detailed AIX build instructions. The new version should be under the 'ppc-aix-port-b02' tag as well. At that point I'll kindly ask any interested party to verify our build experience on as many different AIX-platfomrs as possible and to start improving the class library part of the port:) If everything runs smoothly we can then start thinking about syncing with upstream (i.e. with the jdk7u master) which we haven't done for a while now. I'd propose to wait until the current hsx24 downport (and the corresponding class file change) is completed. This will hopefully enable us to use the same HotSpot (from jdk7u) to run both JDK7 and JDK8. Once we've verified that such a scenario is really working, I'd apply for a JDK8 forest to finally satisfy the long-cherished wish of some of the mailing list subscribers:) Regards, Volker PS: Goetz is currently heavily working on the C2 JIT compiler port which will be ready for submission soon...

2 1

hg: ppc-aix-port/jdk7u/jdk: Add some AIX-specific files which were missing from changeset 5101:a06818b39f7c
by volker.simonis＠gmail.com 23 Oct '12

23 Oct '12

Changeset: 72b9744943c7 Author: simonis Date: 2012-10-23 09:43 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/72b9744943c7 Add some AIX-specific files which were missing from changeset 5101:a06818b39f7c + src/solaris/classes/sun/nio/ch/AixAsynchronousChannelProvider.java + src/solaris/classes/sun/nio/ch/AixPollPort.java + src/solaris/native/sun/nio/ch/AixPollPort.c

1 0

hg: ppc-aix-port/jdk7u/jdk: Some basic AIX changes to let the VM bootstrap itself and run JVM98.
by volker.simonis＠gmail.com 22 Oct '12

22 Oct '12

Changeset: a06818b39f7c Author: simonis Date: 2012-10-22 18:27 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/a06818b39f7c Some basic AIX changes to let the VM bootstrap itself and run JVM98. - fix problem in verifier which is not prepared that malloc(0) can return NULL on AIX. - also added a basic implementation of NIO for AIX (to support logging/tracing in the class library) Swing/AWT is still not working because of some FontConfig issues, but at least the resulting JDK can now be used to bootstrap itself. ! make/common/Defs.gmk ! make/common/Program.gmk ! make/common/shared/Defs-utils.gmk ! make/java/jli/Makefile ! make/java/nio/Makefile ! make/sun/font/Makefile ! src/share/native/common/check_code.c ! src/solaris/bin/java_md_solinux.c ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/classes/sun/nio/ch/Port.java + src/solaris/classes/sun/nio/fs/AixFileStore.java + src/solaris/classes/sun/nio/fs/AixFileSystem.java + src/solaris/classes/sun/nio/fs/AixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c

1 0

hg: ppc-aix-port/jdk7u/hotspot: Basic AIX adaption. With this change the VM can successfully run 'HelloWorld' on AIX
by volker.simonis＠gmail.com 22 Oct '12

22 Oct '12

Changeset: 1efaab66c81d Author: simonis Date: 2012-10-22 18:15 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1efaab66c81d Basic AIX adaption. With this change the VM can successfully run 'HelloWorld' on AIX ! make/aix/makefiles/build_vm_def.sh ! make/aix/makefiles/jvmg.make ! make/aix/makefiles/ppc64.make ! make/aix/makefiles/vm.make ! src/cpu/ppc/vm/assembler_ppc.cpp ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp ! src/os/aix/vm/attachListener_aix.cpp ! src/os/aix/vm/globals_aix.hpp + src/os/aix/vm/libperfstat_aix.cpp + src/os/aix/vm/libperfstat_aix.hpp ! src/os/aix/vm/loadlib_aix.cpp ! src/os/aix/vm/osThread_aix.cpp ! src/os/aix/vm/os_aix.cpp ! src/os/aix/vm/os_aix.hpp ! src/os/aix/vm/perfMemory_aix.cpp ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_xlc.hpp

1 0

JavaOne Talk
by Andrew Hughes 11 Oct '12

11 Oct '12

Hi all, Following on from the PPC/AIX talk at JavaOne (which I found very interesting - thanks), I thought I'd point out that we have a buildbot setup here: http://builder.classpath.org/icedtea/buildbot/ which includes the status and build logs for our builds. This gets triggered to do a new build when a commit is made to IcedTea. I've CCed Mark Wielaard who did a great job of setting all this up and knows a lot more about it than I do. Maybe we can look at linking your builds into this as build slaves at some point. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

2 2

Is there something like $ORIGIN for AIX ld?
by Volker Simonis 30 Sep '12

30 Sep '12

Hi, in OpenJDK 7 the java executable is by default linked against libjli.so which is located under jre/lib/amd64/jli/libjli.so. libjli.so is found by the runtime linker because the java executable was linked with a corresponding "-Wl,-rpath,$ORIGIN/../jre/lib/amd64/jli" option which allows the executable to find the library relatively to its own location. My question is, if there exists a similar construct for AIX? The same question (in some more detail) has been already asked some time ago in a IBM developerworks forum (http://www.ibm.com/developerworks/forums/message.jspa?messageID=14036328) and because I'm just to lazy to reformulate it with my own words, here's it is: " ... I want to make my executable, which uses shared libraries, independent of any shared library path setings (LIBBPATH ...). Instead the shared libraries should always be searched for in the directory in which the executable resides. This is to ease installation and to ensure, my app always picks up the right libraries. On Platforms like linux, hpux and solaris this can easily be handeled by placing $ORIGIN in the link line (e.g. on linux: gcc -Wl,-rpath,$ORIGIN ... or on hpux: ld +b \$ORIGIN ... or on solaris: ld -R \$ORIGIN ...) By doing this and placing all shared libraries that my executbale needs in the same directory as the executbale itself, the shared libraries are always found from that location relative to the location of the executable in the filesystem. This works because $ORIGIN is resolved by the dynamic loader not at linktime but at execution time. It is resolved to the directory in which the executbale resides. I could not find anything like this for AIX. Is there such a mechanism on AIX as well? ... " Regards, Volker

3 3

Problem with the initialization of global objects in shared libraries on AIX
by Volker Simonis 30 Sep '12

30 Sep '12

Hi, I'm having a real strange problem with the initialization of global objects in our HotSpot port (libjvm.so) on AIX: CodeHeap * CodeCache::_heap = new CodeHeap(); void CodeCache::initialize() { if (!_heap->reserve(...)) { ... The problem is that 'CodeCache::_heap' is a global variable which should be initialized at the time when 'CodeCache::initialize()' is called. But in our OpenJDK port of the libjvm.so it isn't. Its actually NULL and the VM crashes. I'm also seeing this lack of initialization for globals in different compilation units from libjvm.so. In our internal SAP JVM version, we have exactly the same code and it works. I try to build the OpenJDK version with exactly the same command line flags so I really don't see the difference (we're using xlc 10 on AIX 5.3). C++ files are compiled with 'xlC_r -q64 -qpic=large -qlanglvl=extc99 -qnortti -qnoeh', the shared library (libjvm.so) is linked with 'xlC_r -q64 -b64 -bexpall -G -bnoentry -qmkshrobj -brtl -bnolibpath -Wl,-lC_r -lm -ldl -lpthread' and the java executable is linked with 'xlc_r -b64 -brtl -bnolibpath -liconv -lpthread'. Any idea what can cause this strange problem? Thank you and best regards, Volker

2 1

hg: ppc-aix-port/jdk7u/hotspot: Opto: hook to postprocess matcher output platform dependent.
by goetz.lindenmaier＠sap.com 26 Sep '12

26 Sep '12

Changeset: 50fbe70b4f3f Author: Goetz Lindenmaier Date: 2012-09-26 16:54 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/50fbe70b4f3f Opto: hook to postprocess matcher output platform dependent. On Power we need to add a special input, the toc, to nodes loading constants. This must happen after matching, but before register allocation. This change adds a class PdCompile which contains a method pd_post_matching_hook() on each platform. The method is - so far - empty everywhere. It's called in compile() after matching. + src/cpu/ppc/vm/compile_ppc.hpp + src/cpu/sparc/vm/compile_sparc.hpp + src/cpu/x86/vm/compile_x86.hpp + src/cpu/zero/vm/compile_zero.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp

1 0

hg: ppc-aix-port/jdk7u/hotspot: Extend Load and Store nodes to know about memory ordering.
by goetz.lindenmaier＠sap.com 21 Sep '12

21 Sep '12

Changeset: bcc03d1e64ee Author: Goetz Lindenmaier Date: 2012-09-18 14:10 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/bcc03d1e64ee Extend Load and Store nodes to know about memory ordering. On some platforms, Load and Store nodes can be reordered violating the semantics required by Java. E.g., a Store publishing the pointer to a new Java object may not be executed before the Stores initializing the object. PPC and IA64 for example have such weak memory ordering. This change adds a field sem to all Load/Store nodes. The field is either set to 'unordered', if the node may be reordered with others, or to 'acquire' for Loads and 'release' for Stores. The change also contains the code setting the field during IR construction. On platforms with weak memory ordering, the ad-file must specify two versions for each Load/Store node, checking the sem property and issuing an according operation. ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/vectornode.hpp

1 0

JDK7 System.loadLibrary on AIX
by Matthias Baesken 18 Sep '12

18 Sep '12

Hello , I noticed that the IBM J9 is more flexible in the System.loadLibrary(libName) function; in the OpenJDK JDK or SAPJVM we had a fix prefix and suffix for libraries to be loaded via System.loadLibrary(libName). E.g. for Linux the fix library name prefix was lib and the suffix .so , so for loading libtesting.so one would call System.loadLibrary("testing"); However IBM J9 would (at least) support also loading *.a and full-name for the library (maybe even more combinations ?) . E.g. libtesting.a => System.loadLibrary("testing"); // works (at least with 6 and 7 ) libtesting.so => System.loadLibrary("testing"); // works (at least with 6 and 7 ) as well System.loadLibrary("libtesting.so"); // works also with full name(at least with 6 and 7) Should we add this functionality also for OpenJDK ? Fortunately with the MacOS-X port in jdk7 they added recently the functionality to support more flexible naming for lib loading. See in jdk7 : solaris/classes/java/lang/ClassLoaderHelper.java (still empty implementation) or macosx/classes/java/lang/ClassLoaderHelper.java (where they support 2 extensions at the moment) In the SAPJVM7 implementation I'll switch to use the solaris/classes/java/lang/ClassLoaderHelper.java for this, might be an option also for OpenJDK AIX port . What do you think ? Thanks and best regards, Matthias (btw. I am a colleague of Goetz and Volker working with them in the SAPJVM group)

2 2