From hamiltcl at verizon.net Fri Feb 12 06:26:14 2016 From: hamiltcl at verizon.net (Curtis Hamilton) Date: Fri, 12 Feb 2016 01:26:14 -0500 Subject: PPC-AIX Port to FreeBSD PowerPC Support References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> Message-ID: <00f201d1655e$465323c0$d2f96b40$@verizon.net> Thomas/Volker, Just wanted to give you an update on my bsd/ppc64 porting effort. I?m using the standard bsd openjdk8 port, as the bsd mercurial needs freebsd specific patches. I?ve made progress modding the linux/ppc files to work under bsd and can successfully build a native (ppc64) JVM. Here?s the output I get executing ?java ?version? root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # ./java -version openjdk version "1.8.0_72-debug" OpenJDK Runtime Environment (build 1.8.0_72-debug-b15) OpenJDK 64-Bit Server VM (build 25.72-b15-debug, mixed mode) root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # I can compile and execute the basic ?hello world?. However, compiling more complicated java code results in a core dump. See the following: root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # ./javac HelloWorld.java root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # ./java HelloWorld Hello, World root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # ./javac zip.java Trace/BPT trap (core dumped) root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # ./javac LargeZip.java Trace/BPT trap (core dumped) root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin # As you can see this is a debug build and I?ve been able to tell from the core dump, using gdb, that it?s getting a signal 5 at abort. Any recommendations on what to look at or how to further debug? Regards, Curtis From: Curtis Hamilton [mailto:hamiltcl at verizon.net] Sent: Monday, January 11, 2016 3:29 PM To: 'Thomas St?fe' Cc: 'Volker Simonis' ; 'ppc-aix-port-dev at openjdk.java.net' Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support Thomas, Thanks for the vector check! I agree that the AIX os is quite different from other unices (I have an old PowerStation 220 in my collection). However, the ppc-aix-port was the first that contained code specific to the ppc. Since there isn?t a ppc-bsd port, I needed somewhere to start. PPC code for both AIX and Linux can be found in the same port. The ports available on FreeBSD currently do contain any of the ppc headers or code. So I decided to use a port that already had the ppc code and go from there. Now that ppc code is being integrated into a more universal port, I just need to check which jdk8 port to work with. Any recommendation? Regards, Curtis From: Thomas St?fe [ mailto:thomas.stuefe at gmail.com] Sent: Monday, January 11, 2016 11:23 AM To: Curtis Hamilton < hamiltcl at verizon.net> Cc: Volker Simonis < volker.simonis at gmail.com>; ppc-aix-port-dev at openjdk.java.net Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support Hi Curtis, I am not sure that AIX ppc would be the best source for an BSD port. AIX os port contains a large number of AIX specifics and it is quite a bit different (sometimes, needlessly) from the other Unices. It is also a moving target, at least on jdk9, as we changed a lot in the AIX os port and will change more until the next feature close. So, it may be that linux ppc would be a better porting source for a bsd ppc port. Kind Regards, Thomas On Mon, Jan 11, 2016 at 3:21 PM, Curtis Hamilton > wrote: Volker, Thanks for the response. Yes, I?m using the mercurial jdk7u ppc-aix version. The reason I used this port version was because I was more familiar with the build layout of jdk7 versus jdk8/jdk9. And it seemed like an easier target to start with, since it already supported ppc64 on AIX and Linux. Full disclosure, I?ve been successful in building zero vm for both jdk7 and jdk8 on ppc64/FreeBSD. They both work great. The system performance is somewhat sluggish, but usable. So I decided to see if I could build native ppc64 versions leveraging the existing AIX and Linux ppc64 support in the ppc-aix-port, since the bsd-port lacks support for PowerPC. I?m aware of the integration effort for jdk9. So on your advice, I will start working with ppc-aix jdk8u. I don?t want anyone to waste time with jdk7u. Although my efforts with this older version is not completely wasted. I look forward to contributing to the ppc64/bsd port OpenJDK integration effort. Regards, Curtis From: Volker Simonis [mailto: volker.simonis at gmail.com] Sent: Monday, January 11, 2016 5:22 AM To: Curtis Hamilton < hamiltcl at verizon.net> Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support Hi Curtis, no, I'm not aware of any effort to port the ppc64 port to BSD. My first question is why are you building jdk7. It is quite old and we don't actually support it any more. It was also never integrated into the main jdk7u branch. I'd strongly recommend to use at least the jdk8u version. If you plan to contribute the ppc64/bsd port for integration into the OpenJDK, this has to be done into the head revision (currently jdk9) anyway. Once it's there, it may be possible to downport it to jdk8u (but not to jdk7u because that on doesn't even contain the ppc64 port). That said, which version of jdk7u are you using? Is it the one from http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ ? One problem you may encounter with jdk7u is that it was never compiled with new versions of gcc. I see you are using gcc4.8 but we used 4.1.2 back then when we were doing the port. Another problem is that we didn't support the serviceability agent in jdk7u. Support for the SA agent on Linux/ppc64 (but not for AIX) was added in jdk8. The error you see in vmStructs.cpp is most probably from SA coding. How does your file vmStructs_bsd_ppc.hpp looks like. As you can see, vmStructs_linux_ppc.hpp is empty in jdk7u for the ppc64 port while it has some code in jdk8u-dev and jdk9. Unfortunately the place in vmStructs.cpp where the error happens is deeply nested macro coding so it's hard to say what's wrong from the error message. You could preprocess the file and post that to the list, maybe we can see more. Just issue the following command from a shell from within /usr/ports/tmp/jdk7u/build/bsd-ppc/hotspot/outputdir/bsd_ppc64_compiler2/product: g++48 -DBSD -DPPC64 -D_ALLBSD_SOURCE -D_GNU_SOURCE -DPRODUCT -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/prims -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/precompiled -I/usr/ports/tmp/jdk7u/hotspot/src/cpu/ppc/vm -I/usr/ports/tmp/jdk7u/hotspot/src/os_cpu/bsd_ppc/vm -I/usr/ports/tmp/jdk7u/hotspot/src/os/bsd/vm -I/usr/ports/tmp/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"24.80-b11\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"root\"" -DHOTSPOT_LIB_ARCH=\"ppc\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDEFAULT_LIBPATH="\"/lib:/usr/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_bsd_ppc -DTARGET_OS_ARCH_MODEL_bsd_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -mpowerpc64 -pipe -DDONT_USE_PRECOMPILED_HEADER -O3 -fno-strict-aliasing -D_LP64=1 -m64 -mminimal-toc -mcpu=powerpc64 -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -DSAFEFETCH_STUBS -DINCLUDE_TRACE=1 -Werror -Wpointer-arith -Wconversion -Wsign-compare -E /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp Regards, Volker On Sun, Jan 10, 2016 at 3:04 PM, Curtis Hamilton > wrote: Hello, I?d like to know if there?s been any work done to support PPC for *BSD? I?ve hacked both the AIX and Linux PPC headers but have been unsuccessful in building HotSpot. All modules seem to build with the exception of VMStructs.cpp with the below error. /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp: In static member function 'static void VMStructs::init()': /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp:3015: error: cannot convert 'pthread**' to 'pid_t*' in initialization Build log is attached. Thanks in advance! Curtis -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Feb 12 07:08:22 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 12 Feb 2016 08:08:22 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: <00f201d1655e$465323c0$d2f96b40$@verizon.net> References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> <00f201d1655e$465323c0$d2f96b40$@verizon.net> Message-ID: Hi Curtis, I think it makes sense to post this on the bsd list too. See my comments inline. On Fri, Feb 12, 2016 at 7:26 AM, Curtis Hamilton wrote: > Thomas/Volker, > > > > Just wanted to give you an update on my bsd/ppc64 porting effort. I?m > using the standard bsd openjdk8 port, as the bsd mercurial needs freebsd > specific patches. > > > > I?ve made progress modding the linux/ppc files to work under bsd and can > successfully build a native (ppc64) JVM. Here?s the output I get executing > ?java ?version? > > > > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # ./java -version > openjdk version "1.8.0_72-debug" > OpenJDK Runtime Environment (build 1.8.0_72-debug-b15) > OpenJDK 64-Bit Server VM (build 25.72-b15-debug, mixed mode) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # > Great Job! > I can compile and execute the basic ?hello world?. However, compiling > more complicated java code results in a core dump. See the following: > > > > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # ./javac HelloWorld.java > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # ./java HelloWorld > Hello, World > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # ./javac zip.java > Trace/BPT trap (core dumped) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # ./javac LargeZip.java > Trace/BPT trap (core dumped) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin > # > > As you can see this is a debug build and I?ve been able to tell from the > core dump, using gdb, that it?s getting a signal 5 at abort. > > > I think SIGTRAP is used by the ppc JIT for some things (implicit nullchecks? Volker would know better). So, SIGTRAP must be handled for this to work. The JVM has a central signal handler, entry point is "signalHandler" in os_.cpp, and then it goes on to, in your case, JVM_handler_bsd_signal() in os_bsd_ppc.cpp. So, make sure that 1) SIGTRAP is handled by this signal handler - I think, by default bsd does not install a signal handler for SIGTRAP. See os::Bsd::install_signal_handlers(), and compare it with the Linux version. 2) Then, SIGTRAP must be handled in JVM_handler_bsd_signal(). Compare with the SIGTRAP handling for Linux (os_linux_ppc.cpp). But if you copied that code, maybe SIGTRAP handling is already in place and (1) was all that was missing. Also note: The jvm normally writes a error log on crashes which is very useful ("hs_err_") but in your case it was not written at all, because no signal handler was installed for SIGTRAP. So, if you took care of (1) but (2) is still missing, you may still crash but with a real error report log this time. Side note: Magnus Ihse Bursie is cleaning up and repairing the BSD port, see: http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-January/002739.html His changes are not yet committed, but he posted a webrev with his changes ( http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/). It may make sense to integrate this in your build, he did some worthwhile fixes. Kind Regards, Thomas > Any recommendations on what to look at or how to further debug? > > > > Regards, > > > > Curtis > > > > *From:* Curtis Hamilton [mailto:hamiltcl at verizon.net] > *Sent:* Monday, January 11, 2016 3:29 PM > *To:* 'Thomas St?fe' > *Cc:* 'Volker Simonis' ; ' > ppc-aix-port-dev at openjdk.java.net' > *Subject:* RE: PPC-AIX Port to FreeBSD PowerPC Support > > > > Thomas, > > > > Thanks for the vector check! > > > > I agree that the AIX os is quite different from other unices (I have an > old PowerStation 220 in my collection). However, the ppc-aix-port was the > first that contained code specific to the ppc. Since there isn?t a ppc-bsd > port, I needed somewhere to start. PPC code for both AIX and Linux can be > found in the same port. The ports available on FreeBSD currently do > contain any of the ppc headers or code. So I decided to use a port that > already had the ppc code and go from there. > > > > Now that ppc code is being integrated into a more universal port, I just > need to check which jdk8 port to work with. > > > > Any recommendation? > > > > Regards, > > Curtis > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > *Sent:* Monday, January 11, 2016 11:23 AM > *To:* Curtis Hamilton > *Cc:* Volker Simonis ; > ppc-aix-port-dev at openjdk.java.net > > *Subject:* Re: PPC-AIX Port to FreeBSD PowerPC Support > > > > Hi Curtis, > > > > I am not sure that AIX ppc would be the best source for an BSD port. AIX > os port contains a large number of AIX specifics and it is quite a bit > different (sometimes, needlessly) from the other Unices. It is also a > moving target, at least on jdk9, as we changed a lot in the AIX os port and > will change more until the next feature close. > > > > So, it may be that linux ppc would be a better porting source for a bsd > ppc port. > > > > Kind Regards, Thomas > > > > > > > > > > > > On Mon, Jan 11, 2016 at 3:21 PM, Curtis Hamilton > wrote: > > Volker, > > > > Thanks for the response. > > > > Yes, I?m using the mercurial jdk7u ppc-aix version. The reason I used > this port version was because I was more familiar with the build layout of > jdk7 versus jdk8/jdk9. And it seemed like an easier target to start with, > since it already supported ppc64 on AIX and Linux. > > > > Full disclosure, I?ve been successful in building zero vm for both jdk7 > and jdk8 on ppc64/FreeBSD. They both work great. The system performance > is somewhat sluggish, but usable. So I decided to see if I could build > native ppc64 versions leveraging the existing AIX and Linux ppc64 support > in the ppc-aix-port, since the bsd-port lacks support for PowerPC. > > > > I?m aware of the integration effort for jdk9. So on your advice, I will > start working with ppc-aix jdk8u. I don?t want anyone to waste time with > jdk7u. Although my efforts with this older version is not completely wasted. > > > > I look forward to contributing to the ppc64/bsd port OpenJDK integration > effort. > > > > Regards, > > Curtis > > > > *From:* Volker Simonis [mailto:volker.simonis at gmail.com] > *Sent:* Monday, January 11, 2016 5:22 AM > *To:* Curtis Hamilton > *Cc:* ppc-aix-port-dev at openjdk.java.net > *Subject:* Re: PPC-AIX Port to FreeBSD PowerPC Support > > > > Hi Curtis, > > no, I'm not aware of any effort to port the ppc64 port to BSD. > > My first question is why are you building jdk7. It is quite old and we > don't actually support it any more. It was also never integrated into the > main jdk7u branch. I'd strongly recommend to use at least the jdk8u > version. If you plan to contribute the ppc64/bsd port for integration into > the OpenJDK, this has to be done into the head revision (currently jdk9) > anyway. Once it's there, it may be possible to downport it to jdk8u (but > not to jdk7u because that on doesn't even contain the ppc64 port). > > That said, which version of jdk7u are you using? Is it the one from > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ ? > > One problem you may encounter with jdk7u is that it was never compiled > with new versions of gcc. I see you are using gcc4.8 but we used 4.1.2 back > then when we were doing the port. > > Another problem is that we didn't support the serviceability agent in > jdk7u. Support for the SA agent on Linux/ppc64 (but not for AIX) was added > in jdk8. The error you see in vmStructs.cpp is most probably from SA > coding. How does your file vmStructs_bsd_ppc.hpp looks like. As you can > see, vmStructs_linux_ppc.hpp is empty in jdk7u for the ppc64 port while it > has some code in jdk8u-dev and jdk9. > > Unfortunately the place in vmStructs.cpp where the error happens is deeply > nested macro coding so it's hard to say what's wrong from the error > message. You could preprocess the file and post that to the list, maybe we > can see more. Just issue the following command from a shell from within > /usr/ports/tmp/jdk7u/build/bsd-ppc/hotspot/outputdir/bsd_ppc64_compiler2/product: > > g++48 -DBSD -DPPC64 -D_ALLBSD_SOURCE -D_GNU_SOURCE -DPRODUCT > -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/prims > -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm > -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/precompiled > -I/usr/ports/tmp/jdk7u/hotspot/src/cpu/ppc/vm > -I/usr/ports/tmp/jdk7u/hotspot/src/os_cpu/bsd_ppc/vm > -I/usr/ports/tmp/jdk7u/hotspot/src/os/bsd/vm > -I/usr/ports/tmp/jdk7u/hotspot/src/os/posix/vm -I../generated > -DHOTSPOT_RELEASE_VERSION="\"24.80-b11\"" > -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"root\"" > -DHOTSPOT_LIB_ARCH=\"ppc\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > -DDEFAULT_LIBPATH="\"/lib:/usr/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd > -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_bsd_ppc > -DTARGET_OS_ARCH_MODEL_bsd_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC > -fno-rtti -fno-exceptions -pthread -fcheck-new -mpowerpc64 -pipe > -DDONT_USE_PRECOMPILED_HEADER -O3 -fno-strict-aliasing -D_LP64=1 -m64 > -mminimal-toc -mcpu=powerpc64 -mtune=power5 > -minsert-sched-nops=regroup_exact -mno-multiple -mno-string > -DSAFEFETCH_STUBS -DINCLUDE_TRACE=1 -Werror -Wpointer-arith -Wconversion > -Wsign-compare -E > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp > > Regards, > > Volker > > > > On Sun, Jan 10, 2016 at 3:04 PM, Curtis Hamilton > wrote: > > Hello, > > I?d like to know if there?s been any work done to support PPC for *BSD? > > I?ve hacked both the AIX and Linux PPC headers but have been unsuccessful > in building HotSpot. All modules seem to build with the exception of > VMStructs.cpp with the below error. > > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp: In static > member function 'static void VMStructs::init()': > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp:3015: > error: cannot convert 'pthread**' to 'pid_t*' in initialization > > Build log is attached. > > Thanks in advance! > > > > Curtis > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Feb 12 08:27:45 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 12 Feb 2016 08:27:45 +0000 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> <00f201d1655e$465323c0$d2f96b40$@verizon.net> Message-ID: <87a664accf3f4760b00d2d8411e9aedf@DEWDFE13DE09.global.corp.sap> Hi Curtis, If SIGTRAP ist he problem, you could try -XX:-UseSIGTRAP. This slows down null checks a bit, but this should not matter for now. Best regards, Goetz > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Freitag, 12. Februar 2016 08:08 > To: Curtis Hamilton > Cc: ppc-aix-port-dev at openjdk.java.net; bsd-port-dev at openjdk.java.net > Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support > > Hi Curtis, > > I think it makes sense to post this on the bsd list too. > > See my comments inline. > > On Fri, Feb 12, 2016 at 7:26 AM, Curtis Hamilton > wrote: > > > Thomas/Volker, > > > > Just wanted to give you an update on my bsd/ppc64 porting effort. > I?m using the standard bsd openjdk8 port, as the bsd mercurial needs > freebsd specific patches. > > > > I?ve made progress modding the linux/ppc files to work under bsd > and can successfully build a native (ppc64) JVM. Here?s the output I get > executing ?java ?version? > > > > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./java -version > openjdk version "1.8.0_72-debug" > OpenJDK Runtime Environment (build 1.8.0_72-debug-b15) > OpenJDK 64-Bit Server VM (build 25.72-b15-debug, mixed mode) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # > > > Great Job! > > > > I can compile and execute the basic ?hello world?. However, > compiling more complicated java code results in a core dump. See the > following: > > > > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./javac HelloWorld.java > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./java HelloWorld > Hello, World > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./javac zip.java > Trace/BPT trap (core dumped) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./javac LargeZip.java > Trace/BPT trap (core dumped) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # > > As you can see this is a debug build and I?ve been able to tell from the > core dump, using gdb, that it?s getting a signal 5 at abort. > > > > > I think SIGTRAP is used by the ppc JIT for some things (implicit nullchecks? > Volker would know better). So, SIGTRAP must be handled for this to work. > > The JVM has a central signal handler, entry point is "signalHandler" in > os_.cpp, and then it goes on to, in your case, JVM_handler_bsd_signal() > in os_bsd_ppc.cpp. > > So, make sure that > > 1) SIGTRAP is handled by this signal handler - I think, by default bsd does not > install a signal handler for SIGTRAP. See os::Bsd::install_signal_handlers(), > and compare it with the Linux version. > > 2) Then, SIGTRAP must be handled in JVM_handler_bsd_signal(). Compare > with the SIGTRAP handling for Linux (os_linux_ppc.cpp). But if you copied > that code, maybe SIGTRAP handling is already in place and (1) was all that > was missing. > > Also note: The jvm normally writes a error log on crashes which is very useful > ("hs_err_") but in your case it was not written at all, because no signal > handler was installed for SIGTRAP. So, if you took care of (1) but (2) is still > missing, you may still crash but with a real error report log this time. > > Side note: Magnus Ihse Bursie is cleaning up and repairing the BSD port, see: > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016- > January/002739.html > > His changes are not yet committed, but he posted a webrev with his changes > (http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source- > patches/webrev.01/). It may make sense to integrate this in your build, he > did some worthwhile fixes. > > Kind Regards, Thomas > > > > > Any recommendations on what to look at or how to further debug? > > > > Regards, > > > > Curtis > > > > From: Curtis Hamilton [mailto:hamiltcl at verizon.net > ] > Sent: Monday, January 11, 2016 3:29 PM > To: 'Thomas St?fe' > > Cc: 'Volker Simonis' >; 'ppc-aix-port-dev at openjdk.java.net > ' dev at openjdk.java.net > > Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support > > > > Thomas, > > > > Thanks for the vector check! > > > > I agree that the AIX os is quite different from other unices (I have an > old PowerStation 220 in my collection). However, the ppc-aix-port was the > first that contained code specific to the ppc. Since there isn?t a ppc-bsd port, > I needed somewhere to start. PPC code for both AIX and Linux can be found > in the same port. The ports available on FreeBSD currently do contain any of > the ppc headers or code. So I decided to use a port that already had the ppc > code and go from there. > > > > Now that ppc code is being integrated into a more universal port, I > just need to check which jdk8 port to work with. > > > > Any recommendation? > > > > Regards, > > Curtis > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > Sent: Monday, January 11, 2016 11:23 AM > To: Curtis Hamilton > > Cc: Volker Simonis >; ppc-aix-port-dev at openjdk.java.net > > > > Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support > > > > > > Hi Curtis, > > > > I am not sure that AIX ppc would be the best source for an BSD port. > AIX os port contains a large number of AIX specifics and it is quite a bit > different (sometimes, needlessly) from the other Unices. It is also a moving > target, at least on jdk9, as we changed a lot in the AIX os port and will change > more until the next feature close. > > > > So, it may be that linux ppc would be a better porting source for a bsd > ppc port. > > > > Kind Regards, Thomas > > > > > > > > > > > > On Mon, Jan 11, 2016 at 3:21 PM, Curtis Hamilton > > wrote: > > Volker, > > > > Thanks for the response. > > > > Yes, I?m using the mercurial jdk7u ppc-aix version. The > reason I used this port version was because I was more familiar with the build > layout of jdk7 versus jdk8/jdk9. And it seemed like an easier target to start > with, since it already supported ppc64 on AIX and Linux. > > > > Full disclosure, I?ve been successful in building zero vm for > both jdk7 and jdk8 on ppc64/FreeBSD. They both work great. The system > performance is somewhat sluggish, but usable. So I decided to see if I could > build native ppc64 versions leveraging the existing AIX and Linux ppc64 > support in the ppc-aix-port, since the bsd-port lacks support for PowerPC. > > > > I?m aware of the integration effort for jdk9. So on your > advice, I will start working with ppc-aix jdk8u. I don?t want anyone to waste > time with jdk7u. Although my efforts with this older version is not completely > wasted. > > > > I look forward to contributing to the ppc64/bsd port OpenJDK > integration effort. > > > > Regards, > > Curtis > > > > From: Volker Simonis [mailto:volker.simonis at gmail.com > ] > Sent: Monday, January 11, 2016 5:22 AM > To: Curtis Hamilton > > Cc: ppc-aix-port-dev at openjdk.java.net dev at openjdk.java.net> > Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support > > > > Hi Curtis, > > no, I'm not aware of any effort to port the ppc64 port to BSD. > > My first question is why are you building jdk7. It is quite old > and we don't actually support it any more. It was also never integrated into > the main jdk7u branch. I'd strongly recommend to use at least the jdk8u > version. If you plan to contribute the ppc64/bsd port for integration into the > OpenJDK, this has to be done into the head revision (currently jdk9) anyway. > Once it's there, it may be possible to downport it to jdk8u (but not to jdk7u > because that on doesn't even contain the ppc64 port). > > That said, which version of jdk7u are you using? Is it the one > from http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ ? > > One problem you may encounter with jdk7u is that it was > never compiled with new versions of gcc. I see you are using gcc4.8 but we > used 4.1.2 back then when we were doing the port. > > Another problem is that we didn't support the serviceability > agent in jdk7u. Support for the SA agent on Linux/ppc64 (but not for AIX) was > added in jdk8. The error you see in vmStructs.cpp is most probably from SA > coding. How does your file vmStructs_bsd_ppc.hpp looks like. As you can > see, vmStructs_linux_ppc.hpp is empty in jdk7u for the ppc64 port while it > has some code in jdk8u-dev and jdk9. > > Unfortunately the place in vmStructs.cpp where the error > happens is deeply nested macro coding so it's hard to say what's wrong from > the error message. You could preprocess the file and post that to the list, > maybe we can see more. Just issue the following command from a shell from > within /usr/ports/tmp/jdk7u/build/bsd- > ppc/hotspot/outputdir/bsd_ppc64_compiler2/product: > > g++48 -DBSD -DPPC64 -D_ALLBSD_SOURCE - > D_GNU_SOURCE -DPRODUCT - > I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/prims - > I/usr/ports/tmp/jdk7u/hotspot/src/share/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/precompiled - > I/usr/ports/tmp/jdk7u/hotspot/src/cpu/ppc/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/os_cpu/bsd_ppc/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/os/bsd/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/os/posix/vm -I../generated - > DHOTSPOT_RELEASE_VERSION="\"24.80-b11\"" - > DHOTSPOT_BUILD_TARGET="\"product\"" - > DHOTSPOT_BUILD_USER="\"root\"" -DHOTSPOT_LIB_ARCH=\"ppc\" - > DHOTSPOT_VM_DISTRO="\"OpenJDK\"" - > DDEFAULT_LIBPATH="\"/lib:/usr/lib:/usr/local/lib\"" - > DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_ppc - > DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_bsd_ppc - > DTARGET_OS_ARCH_MODEL_bsd_ppc_64 -DTARGET_COMPILER_gcc - > DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new - > mpowerpc64 -pipe -DDONT_USE_PRECOMPILED_HEADER -O3 -fno-strict- > aliasing -D_LP64=1 -m64 -mminimal-toc -mcpu=powerpc64 -mtune=power5 - > minsert-sched-nops=regroup_exact -mno-multiple -mno-string - > DSAFEFETCH_STUBS -DINCLUDE_TRACE=1 -Werror -Wpointer-arith - > Wconversion -Wsign-compare -E > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp > > Regards, > > Volker > > > > On Sun, Jan 10, 2016 at 3:04 PM, Curtis Hamilton > > wrote: > > Hello, > > I?d like to know if there?s been any work done to > support PPC for *BSD? > > I?ve hacked both the AIX and Linux PPC headers but > have been unsuccessful in building HotSpot. All modules seem to build with > the exception of VMStructs.cpp with the below error. > > > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cp > p: In static member function 'static void VMStructs::init()': > > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cp > p:3015: error: cannot convert 'pthread**' to 'pid_t*' in initialization > > Build log is attached. > > Thanks in advance! > > > > Curtis > > > > > > > From volker.simonis at gmail.com Fri Feb 12 08:28:10 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Feb 2016 09:28:10 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> <00f201d1655e$465323c0$d2f96b40$@verizon.net> Message-ID: Hi Curtis, congratulations from my side as well. Running HelloWorld is always an important milestone when porting the OpenJDK to a new platform! I think Thomas already gave you the right hints. It's true that SIGTRAP is used a lot within HotSpot and you really need to handle it correctly. As a quick workaround you could also try to use -XX:-UseSIGTRAP which should switch off the usage of SIGTRAP within the VM. You also have to use this switch when debugging the VM in a native debugger like gdb because the debugger also uses SIGTRAP internally. Regards, Volker On Fri, Feb 12, 2016 at 8:08 AM, Thomas St?fe wrote: > Hi Curtis, > > I think it makes sense to post this on the bsd list too. > > See my comments inline. > > On Fri, Feb 12, 2016 at 7:26 AM, Curtis Hamilton > wrote: >> >> Thomas/Volker, >> >> >> >> Just wanted to give you an update on my bsd/ppc64 porting effort. I?m >> using the standard bsd openjdk8 port, as the bsd mercurial needs freebsd >> specific patches. >> >> >> >> I?ve made progress modding the linux/ppc files to work under bsd and can >> successfully build a native (ppc64) JVM. Here?s the output I get executing >> ?java ?version? >> >> >> >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # ./java -version >> openjdk version "1.8.0_72-debug" >> OpenJDK Runtime Environment (build 1.8.0_72-debug-b15) >> OpenJDK 64-Bit Server VM (build 25.72-b15-debug, mixed mode) >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # > > > Great Job! >> >> I can compile and execute the basic ?hello world?. However, compiling >> more complicated java code results in a core dump. See the following: >> >> >> >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # ./javac HelloWorld.java >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # ./java HelloWorld >> Hello, World >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # ./javac zip.java >> Trace/BPT trap (core dumped) >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # ./javac LargeZip.java >> Trace/BPT trap (core dumped) >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd-ppc64-normal-server-slowdebug/jdk/bin >> # >> >> As you can see this is a debug build and I?ve been able to tell from the >> core dump, using gdb, that it?s getting a signal 5 at abort. >> >> > > > I think SIGTRAP is used by the ppc JIT for some things (implicit nullchecks? > Volker would know better). So, SIGTRAP must be handled for this to work. > > The JVM has a central signal handler, entry point is "signalHandler" in > os_.cpp, and then it goes on to, in your case, JVM_handler_bsd_signal() > in os_bsd_ppc.cpp. > > So, make sure that > > 1) SIGTRAP is handled by this signal handler - I think, by default bsd does > not install a signal handler for SIGTRAP. See > os::Bsd::install_signal_handlers(), and compare it with the Linux version. > > 2) Then, SIGTRAP must be handled in JVM_handler_bsd_signal(). Compare with > the SIGTRAP handling for Linux (os_linux_ppc.cpp). But if you copied that > code, maybe SIGTRAP handling is already in place and (1) was all that was > missing. > > Also note: The jvm normally writes a error log on crashes which is very > useful ("hs_err_") but in your case it was not written at all, because > no signal handler was installed for SIGTRAP. So, if you took care of (1) but > (2) is still missing, you may still crash but with a real error report log > this time. > > Side note: Magnus Ihse Bursie is cleaning up and repairing the BSD port, > see: > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-January/002739.html > > His changes are not yet committed, but he posted a webrev with his changes > (http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/). > It may make sense to integrate this in your build, he did some worthwhile > fixes. > > Kind Regards, Thomas > >> >> Any recommendations on what to look at or how to further debug? >> >> >> >> Regards, >> >> >> >> Curtis >> >> >> >> From: Curtis Hamilton [mailto:hamiltcl at verizon.net] >> Sent: Monday, January 11, 2016 3:29 PM >> To: 'Thomas St?fe' >> Cc: 'Volker Simonis' ; >> 'ppc-aix-port-dev at openjdk.java.net' >> Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support >> >> >> >> Thomas, >> >> >> >> Thanks for the vector check! >> >> >> >> I agree that the AIX os is quite different from other unices (I have an >> old PowerStation 220 in my collection). However, the ppc-aix-port was the >> first that contained code specific to the ppc. Since there isn?t a ppc-bsd >> port, I needed somewhere to start. PPC code for both AIX and Linux can be >> found in the same port. The ports available on FreeBSD currently do >> contain any of the ppc headers or code. So I decided to use a port that >> already had the ppc code and go from there. >> >> >> >> Now that ppc code is being integrated into a more universal port, I just >> need to check which jdk8 port to work with. >> >> >> >> Any recommendation? >> >> >> >> Regards, >> >> Curtis >> >> >> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> Sent: Monday, January 11, 2016 11:23 AM >> To: Curtis Hamilton >> Cc: Volker Simonis ; >> ppc-aix-port-dev at openjdk.java.net >> >> >> Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support >> >> >> >> Hi Curtis, >> >> >> >> I am not sure that AIX ppc would be the best source for an BSD port. AIX >> os port contains a large number of AIX specifics and it is quite a bit >> different (sometimes, needlessly) from the other Unices. It is also a moving >> target, at least on jdk9, as we changed a lot in the AIX os port and will >> change more until the next feature close. >> >> >> >> So, it may be that linux ppc would be a better porting source for a bsd >> ppc port. >> >> >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jan 11, 2016 at 3:21 PM, Curtis Hamilton >> wrote: >> >> Volker, >> >> >> >> Thanks for the response. >> >> >> >> Yes, I?m using the mercurial jdk7u ppc-aix version. The reason I used >> this port version was because I was more familiar with the build layout of >> jdk7 versus jdk8/jdk9. And it seemed like an easier target to start with, >> since it already supported ppc64 on AIX and Linux. >> >> >> >> Full disclosure, I?ve been successful in building zero vm for both jdk7 >> and jdk8 on ppc64/FreeBSD. They both work great. The system performance >> is somewhat sluggish, but usable. So I decided to see if I could build >> native ppc64 versions leveraging the existing AIX and Linux ppc64 support in >> the ppc-aix-port, since the bsd-port lacks support for PowerPC. >> >> >> >> I?m aware of the integration effort for jdk9. So on your advice, I will >> start working with ppc-aix jdk8u. I don?t want anyone to waste time with >> jdk7u. Although my efforts with this older version is not completely wasted. >> >> >> >> I look forward to contributing to the ppc64/bsd port OpenJDK integration >> effort. >> >> >> >> Regards, >> >> Curtis >> >> >> >> From: Volker Simonis [mailto:volker.simonis at gmail.com] >> Sent: Monday, January 11, 2016 5:22 AM >> To: Curtis Hamilton >> Cc: ppc-aix-port-dev at openjdk.java.net >> Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support >> >> >> >> Hi Curtis, >> >> no, I'm not aware of any effort to port the ppc64 port to BSD. >> >> My first question is why are you building jdk7. It is quite old and we >> don't actually support it any more. It was also never integrated into the >> main jdk7u branch. I'd strongly recommend to use at least the jdk8u version. >> If you plan to contribute the ppc64/bsd port for integration into the >> OpenJDK, this has to be done into the head revision (currently jdk9) anyway. >> Once it's there, it may be possible to downport it to jdk8u (but not to >> jdk7u because that on doesn't even contain the ppc64 port). >> >> That said, which version of jdk7u are you using? Is it the one from >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ ? >> >> One problem you may encounter with jdk7u is that it was never compiled >> with new versions of gcc. I see you are using gcc4.8 but we used 4.1.2 back >> then when we were doing the port. >> >> Another problem is that we didn't support the serviceability agent in >> jdk7u. Support for the SA agent on Linux/ppc64 (but not for AIX) was added >> in jdk8. The error you see in vmStructs.cpp is most probably from SA coding. >> How does your file vmStructs_bsd_ppc.hpp looks like. As you can see, >> vmStructs_linux_ppc.hpp is empty in jdk7u for the ppc64 port while it has >> some code in jdk8u-dev and jdk9. >> >> Unfortunately the place in vmStructs.cpp where the error happens is deeply >> nested macro coding so it's hard to say what's wrong from the error message. >> You could preprocess the file and post that to the list, maybe we can see >> more. Just issue the following command from a shell from within >> /usr/ports/tmp/jdk7u/build/bsd-ppc/hotspot/outputdir/bsd_ppc64_compiler2/product: >> >> g++48 -DBSD -DPPC64 -D_ALLBSD_SOURCE -D_GNU_SOURCE -DPRODUCT >> -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/prims >> -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm >> -I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/precompiled >> -I/usr/ports/tmp/jdk7u/hotspot/src/cpu/ppc/vm >> -I/usr/ports/tmp/jdk7u/hotspot/src/os_cpu/bsd_ppc/vm >> -I/usr/ports/tmp/jdk7u/hotspot/src/os/bsd/vm >> -I/usr/ports/tmp/jdk7u/hotspot/src/os/posix/vm -I../generated >> -DHOTSPOT_RELEASE_VERSION="\"24.80-b11\"" >> -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"root\"" >> -DHOTSPOT_LIB_ARCH=\"ppc\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" >> -DDEFAULT_LIBPATH="\"/lib:/usr/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_bsd_ppc >> -DTARGET_OS_ARCH_MODEL_bsd_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC >> -fno-rtti -fno-exceptions -pthread -fcheck-new -mpowerpc64 -pipe >> -DDONT_USE_PRECOMPILED_HEADER -O3 -fno-strict-aliasing -D_LP64=1 -m64 >> -mminimal-toc -mcpu=powerpc64 -mtune=power5 >> -minsert-sched-nops=regroup_exact -mno-multiple -mno-string >> -DSAFEFETCH_STUBS -DINCLUDE_TRACE=1 -Werror -Wpointer-arith -Wconversion >> -Wsign-compare -E >> /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Regards, >> >> Volker >> >> >> >> On Sun, Jan 10, 2016 at 3:04 PM, Curtis Hamilton >> wrote: >> >> Hello, >> >> I?d like to know if there?s been any work done to support PPC for *BSD? >> >> I?ve hacked both the AIX and Linux PPC headers but have been unsuccessful >> in building HotSpot. All modules seem to build with the exception of >> VMStructs.cpp with the below error. >> >> /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp: In static >> member function 'static void VMStructs::init()': >> /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp:3015: >> error: cannot convert 'pthread**' to 'pid_t*' in initialization >> >> Build log is attached. >> >> Thanks in advance! >> >> >> >> Curtis >> >> >> >> >> >> > > From gromero at linux.vnet.ibm.com Fri Feb 12 13:45:19 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 12 Feb 2016 11:45:19 -0200 Subject: RTM disabled for Linux on PPC64 LE Message-ID: <56BDE1EF.1020305@linux.vnet.ibm.com> Hi, As of now (tip 1922:be58b02c11f9, jdk9/jdk9 repo) Hotspot build for Linux on ppc64le of fails due to a simple uninitialized variable error: hotspot/src/share/vm/ci/ciMethodData.hpp:585:100: error: ?data? may be used uninitialized in this function hotspot/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp:2408:78: error: ?md? may be used uninitialized in this function So this straightforward patch solves the issue: diff -r 534c50395957 src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp --- a/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Thu Jan 28 15:42:23 2016 -0800 +++ b/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Mon Feb 08 17:13:14 2016 -0200 @@ -2321,8 +2321,8 @@ if (reg_conflict) { obj = dst; } } - ciMethodData* md; - ciProfileData* data; + ciMethodData* md = NULL; + ciProfileData* data = NULL; int mdo_offset_bias = 0; compiler/rtm if (should_profile) { ciMethod* method = op->profiled_method(); However, after the build, I realized that RTM is still disabled for Linux on ppc64le, failing 25 tests on compiler/rtm suite: http://hastebin.com/raw/ohoxiwaqih Hence after applying the following patches that enable RTM for Linux on ppc64le: diff -r 266fa9bb5297 src/cpu/ppc/vm/vm_version_ppc.cpp --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Thu Feb 04 16:48:39 2016 -0800 +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Feb 12 10:55:46 2016 -0200 @@ -255,7 +255,9 @@ } #endif #ifdef linux - // TODO: check kernel version (we currently have too old versions only) + if (os::Linux::os_version() >= 4) { // at least Linux kernel version 4 + os_too_old = false; + } #endif if (os_too_old) { vm_exit_during_initialization("RTM is not supported on this OS version."); diff -r 266fa9bb5297 src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp Thu Feb 04 16:48:39 2016 -0800 +++ b/src/os/linux/vm/os_linux.cpp Fri Feb 12 10:58:10 2016 -0200 @@ -135,6 +135,7 @@ int os::Linux::_page_size = -1; const int os::Linux::_vm_default_page_size = (8 * K); bool os::Linux::_supports_fast_thread_cpu_time = false; +uint32_t os::Linux::_os_version = 0; const char * os::Linux::_glibc_version = NULL; const char * os::Linux::_libpthread_version = NULL; pthread_condattr_t os::Linux::_condattr[1]; @@ -4332,6 +4333,21 @@ return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; } +void os::Linux::initialize_os_info() { + assert(_os_version == 0, "OS info already initialized"); + + struct utsname _uname; + + uname(&_uname); // Not sure yet how deal if ret == -1 + _os_version = atoi(_uname.release); +} + +uint32_t os::Linux::os_version() { + assert(_os_version != 0, "not initialized"); + return _os_version; +} + + ///// // glibc on Linux platform uses non-documented flag // to indicate, that some special sort of signal @@ -4553,6 +4569,7 @@ init_page_sizes((size_t) Linux::page_size()); Linux::initialize_system_info(); + Linux::initialize_os_info(); // main_thread points to the aboriginal thread Linux::_main_thread = pthread_self(); diff -r 266fa9bb5297 src/os/linux/vm/os_linux.hpp --- a/src/os/linux/vm/os_linux.hpp Thu Feb 04 16:48:39 2016 -0800 +++ b/src/os/linux/vm/os_linux.hpp Fri Feb 12 10:59:01 2016 -0200 @@ -55,7 +55,7 @@ static bool _supports_fast_thread_cpu_time; static GrowableArray* _cpu_to_node; - + static uint32_t _os_version; protected: static julong _physical_memory; @@ -198,6 +198,9 @@ static jlong fast_thread_cpu_time(clockid_t clockid); + static void initialize_os_info(); + static uint32_t os_version(); + // pthread_cond clock suppport private: static pthread_condattr_t _condattr[1]; 23 tests are now passing: http://hastebin.com/raw/oyicagusod Is there a reason to let RTM disabled for Linux on ppc64le by now? Could somebody explain what is currently missing on PPC64 LE RTM implementation in order to make all RTM tests pass? Thank you. Regards, -- Gustavo Romero From martin.doerr at sap.com Fri Feb 12 14:52:54 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 12 Feb 2016 14:52:54 +0000 Subject: RTM disabled for Linux on PPC64 LE In-Reply-To: <56BDE1EF.1020305@linux.vnet.ibm.com> References: <56BDE1EF.1020305@linux.vnet.ibm.com> Message-ID: Hi Gustavo, the reason why we disabled RTM for linux on PPC64 (big or little endian) was the problematic behavior of syscalls. The old version of the document www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt said: ?Performing syscalls from within transaction is not recommended, and can lead to unpredictable results.? Transactions need to either pass completely or roll back completely without disturbing side effects of partially executed syscalls. We rely on the kernel to abort transactions if necessary. The document has changed and it may possibly work with a new linux kernel. However, we don't have such a new kernel, yet. So we can't test it at the moment. I don't know which kernel version exactly contains the change. I guess this exact version number (major + minor) should be used for enabling RTM. I haven't looked into the tests, yet. There may be a need for additional adaptations and fixes. We appreciate if you make experiments and/or contributions. Thanks and best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero Sent: Freitag, 12. Februar 2016 14:45 To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RTM disabled for Linux on PPC64 LE Importance: High Hi, As of now (tip 1922:be58b02c11f9, jdk9/jdk9 repo) Hotspot build for Linux on ppc64le of fails due to a simple uninitialized variable error: hotspot/src/share/vm/ci/ciMethodData.hpp:585:100: error: ?data? may be used uninitialized in this function hotspot/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp:2408:78: error: ?md? may be used uninitialized in this function So this straightforward patch solves the issue: diff -r 534c50395957 src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp --- a/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Thu Jan 28 15:42:23 2016 -0800 +++ b/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Mon Feb 08 17:13:14 2016 -0200 @@ -2321,8 +2321,8 @@ if (reg_conflict) { obj = dst; } } - ciMethodData* md; - ciProfileData* data; + ciMethodData* md = NULL; + ciProfileData* data = NULL; int mdo_offset_bias = 0; compiler/rtm if (should_profile) { ciMethod* method = op->profiled_method(); However, after the build, I realized that RTM is still disabled for Linux on ppc64le, failing 25 tests on compiler/rtm suite: http://hastebin.com/raw/ohoxiwaqih Hence after applying the following patches that enable RTM for Linux on ppc64le: diff -r 266fa9bb5297 src/cpu/ppc/vm/vm_version_ppc.cpp --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Thu Feb 04 16:48:39 2016 -0800 +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Feb 12 10:55:46 2016 -0200 @@ -255,7 +255,9 @@ } #endif #ifdef linux - // TODO: check kernel version (we currently have too old versions only) + if (os::Linux::os_version() >= 4) { // at least Linux kernel version 4 + os_too_old = false; + } #endif if (os_too_old) { vm_exit_during_initialization("RTM is not supported on this OS version."); diff -r 266fa9bb5297 src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp Thu Feb 04 16:48:39 2016 -0800 +++ b/src/os/linux/vm/os_linux.cpp Fri Feb 12 10:58:10 2016 -0200 @@ -135,6 +135,7 @@ int os::Linux::_page_size = -1; const int os::Linux::_vm_default_page_size = (8 * K); bool os::Linux::_supports_fast_thread_cpu_time = false; +uint32_t os::Linux::_os_version = 0; const char * os::Linux::_glibc_version = NULL; const char * os::Linux::_libpthread_version = NULL; pthread_condattr_t os::Linux::_condattr[1]; @@ -4332,6 +4333,21 @@ return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; } +void os::Linux::initialize_os_info() { + assert(_os_version == 0, "OS info already initialized"); + + struct utsname _uname; + + uname(&_uname); // Not sure yet how deal if ret == -1 + _os_version = atoi(_uname.release); +} + +uint32_t os::Linux::os_version() { + assert(_os_version != 0, "not initialized"); + return _os_version; +} + + ///// // glibc on Linux platform uses non-documented flag // to indicate, that some special sort of signal @@ -4553,6 +4569,7 @@ init_page_sizes((size_t) Linux::page_size()); Linux::initialize_system_info(); + Linux::initialize_os_info(); // main_thread points to the aboriginal thread Linux::_main_thread = pthread_self(); diff -r 266fa9bb5297 src/os/linux/vm/os_linux.hpp --- a/src/os/linux/vm/os_linux.hpp Thu Feb 04 16:48:39 2016 -0800 +++ b/src/os/linux/vm/os_linux.hpp Fri Feb 12 10:59:01 2016 -0200 @@ -55,7 +55,7 @@ static bool _supports_fast_thread_cpu_time; static GrowableArray* _cpu_to_node; - + static uint32_t _os_version; protected: static julong _physical_memory; @@ -198,6 +198,9 @@ static jlong fast_thread_cpu_time(clockid_t clockid); + static void initialize_os_info(); + static uint32_t os_version(); + // pthread_cond clock suppport private: static pthread_condattr_t _condattr[1]; 23 tests are now passing: http://hastebin.com/raw/oyicagusod Is there a reason to let RTM disabled for Linux on ppc64le by now? Could somebody explain what is currently missing on PPC64 LE RTM implementation in order to make all RTM tests pass? Thank you. Regards, -- Gustavo Romero From hamiltcl at verizon.net Sat Feb 13 16:49:27 2016 From: hamiltcl at verizon.net (Curtis Hamilton) Date: Sat, 13 Feb 2016 11:49:27 -0500 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: <87a664accf3f4760b00d2d8411e9aedf@DEWDFE13DE09.global.corp.sap> References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> <00f201d1655e$465323c0$d2f96b40$@verizon.net> <87a664accf3f4760b00d2d8411e9aedf@DEWDFE13DE09.global.corp.sap> Message-ID: <017a01d1667e$82d20750$887615f0$@verizon.net> Thomas/Volker, et al Thanks to your assistance, I've been SUCCESSFUL in building a native ppc64 jdk8 on FreeBSD. To validate the build, I made a couple of regression test runs with results similar to the Zero VM build in the same environment. Although, not all tests completed successfully (some of the failed test were due to missing test files in the distribution). The regression test stats file is attached. I've created a set of initial patches for the code and several patches for the build system. However, there's one build system issue that I've not yet resolved. At the end of the Hotspot build, it errors because it cannot find jvmti.hmtl, jvmti.h, libjsig.so and libjvm.so. The files exist, but the "HOTSPOT_DIST" directory structure has not been created, with these files in the locations the build system expects. I'm sure that this is because of building a Compiler2 variant on a non-supported platform, as I don't have this issue with the Zero VM build. Thus, I manually created the "dist" structure and placed the files in the expected locations and the remainder of the build works as designed. Any thoughts? I'm going to continue to stress test the build, to ensure everything is in working order. Again, thanks for all the assistance. Regards, Curtis -----Original Message----- From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] Sent: Friday, February 12, 2016 3:28 AM To: Thomas St?fe ; Curtis Hamilton Cc: ppc-aix-port-dev at openjdk.java.net; bsd-port-dev at openjdk.java.net Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support Hi Curtis, If SIGTRAP ist he problem, you could try -XX:-UseSIGTRAP. This slows down null checks a bit, but this should not matter for now. Best regards, Goetz > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Freitag, 12. Februar 2016 08:08 > To: Curtis Hamilton > Cc: ppc-aix-port-dev at openjdk.java.net; bsd-port-dev at openjdk.java.net > Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support > > Hi Curtis, > > I think it makes sense to post this on the bsd list too. > > See my comments inline. > > On Fri, Feb 12, 2016 at 7:26 AM, Curtis Hamilton > wrote: > > > Thomas/Volker, > > > > Just wanted to give you an update on my bsd/ppc64 porting effort. > I?m using the standard bsd openjdk8 port, as the bsd mercurial needs > freebsd specific patches. > > > > I?ve made progress modding the linux/ppc files to work under bsd > and can successfully build a native (ppc64) JVM. Here?s the output I > get executing ?java ?version? > > > > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./java -version > openjdk version "1.8.0_72-debug" > OpenJDK Runtime Environment (build 1.8.0_72-debug-b15) > OpenJDK 64-Bit Server VM (build 25.72-b15-debug, mixed mode) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # > > > Great Job! > > > > I can compile and execute the basic ?hello world?. However, > compiling more complicated java code results in a core dump. See the > following: > > > > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./javac HelloWorld.java > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./java HelloWorld > Hello, World > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./javac zip.java > Trace/BPT trap (core dumped) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # ./javac LargeZip.java > Trace/BPT trap (core dumped) > root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- > ppc64-normal-server-slowdebug/jdk/bin # > > As you can see this is a debug build and I?ve been able to tell > from the core dump, using gdb, that it?s getting a signal 5 at abort. > > > > > I think SIGTRAP is used by the ppc JIT for some things (implicit nullchecks? > Volker would know better). So, SIGTRAP must be handled for this to work. > > The JVM has a central signal handler, entry point is "signalHandler" > in os_.cpp, and then it goes on to, in your case, > JVM_handler_bsd_signal() in os_bsd_ppc.cpp. > > So, make sure that > > 1) SIGTRAP is handled by this signal handler - I think, by default bsd > does not install a signal handler for SIGTRAP. See > os::Bsd::install_signal_handlers(), > and compare it with the Linux version. > > 2) Then, SIGTRAP must be handled in JVM_handler_bsd_signal(). Compare > with the SIGTRAP handling for Linux (os_linux_ppc.cpp). But if you > copied that code, maybe SIGTRAP handling is already in place and (1) > was all that was missing. > > Also note: The jvm normally writes a error log on crashes which is > very useful > ("hs_err_") but in your case it was not written at all, because > no signal handler was installed for SIGTRAP. So, if you took care of > (1) but (2) is still missing, you may still crash but with a real error report log this time. > > Side note: Magnus Ihse Bursie is cleaning up and repairing the BSD port, see: > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016- > January/002739.html > > His changes are not yet committed, but he posted a webrev with his > changes > (http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source- > patches/webrev.01/). It may make sense to integrate this in your > build, he did some worthwhile fixes. > > Kind Regards, Thomas > > > > > Any recommendations on what to look at or how to further debug? > > > > Regards, > > > > Curtis > > > > From: Curtis Hamilton [mailto:hamiltcl at verizon.net > ] > Sent: Monday, January 11, 2016 3:29 PM > To: 'Thomas St?fe' > > Cc: 'Volker Simonis' >; > 'ppc-aix-port-dev at openjdk.java.net > ' dev at openjdk.java.net > > Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support > > > > Thomas, > > > > Thanks for the vector check! > > > > I agree that the AIX os is quite different from other unices (I > have an old PowerStation 220 in my collection). However, the > ppc-aix-port was the first that contained code specific to the ppc. > Since there isn?t a ppc-bsd port, I needed somewhere to start. PPC code for both AIX and Linux can be found > in the same port. The ports available on FreeBSD currently do contain any of > the ppc headers or code. So I decided to use a port that already had > the ppc code and go from there. > > > > Now that ppc code is being integrated into a more universal > port, I just need to check which jdk8 port to work with. > > > > Any recommendation? > > > > Regards, > > Curtis > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > Sent: Monday, January 11, 2016 11:23 AM > To: Curtis Hamilton > > Cc: Volker Simonis >; ppc-aix-port-dev at openjdk.java.net > > > > Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support > > > > > > Hi Curtis, > > > > I am not sure that AIX ppc would be the best source for an BSD port. > AIX os port contains a large number of AIX specifics and it is quite a > bit different (sometimes, needlessly) from the other Unices. It is > also a moving target, at least on jdk9, as we changed a lot in the AIX > os port and will change more until the next feature close. > > > > So, it may be that linux ppc would be a better porting source > for a bsd ppc port. > > > > Kind Regards, Thomas > > > > > > > > > > > > On Mon, Jan 11, 2016 at 3:21 PM, Curtis Hamilton > > wrote: > > Volker, > > > > Thanks for the response. > > > > Yes, I?m using the mercurial jdk7u ppc-aix version. The > reason I used this port version was because I was more familiar with > the build layout of jdk7 versus jdk8/jdk9. And it seemed like an > easier target to start with, since it already supported ppc64 on AIX and Linux. > > > > Full disclosure, I?ve been successful in building zero vm for > both jdk7 and jdk8 on ppc64/FreeBSD. They both work great. The system > performance is somewhat sluggish, but usable. So I decided to see if > I could build native ppc64 versions leveraging the existing AIX and > Linux ppc64 support in the ppc-aix-port, since the bsd-port lacks support for PowerPC. > > > > I?m aware of the integration effort for jdk9. So on > your advice, I will start working with ppc-aix jdk8u. I don?t want > anyone to waste time with jdk7u. Although my efforts with this older > version is not completely wasted. > > > > I look forward to contributing to the ppc64/bsd port > OpenJDK integration effort. > > > > Regards, > > Curtis > > > > From: Volker Simonis [mailto:volker.simonis at gmail.com > ] > Sent: Monday, January 11, 2016 5:22 AM > To: Curtis Hamilton > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support > > > > Hi Curtis, > > no, I'm not aware of any effort to port the ppc64 port to BSD. > > My first question is why are you building jdk7. It is > quite old and we don't actually support it any more. It was also never > integrated into the main jdk7u branch. I'd strongly recommend to use > at least the jdk8u version. If you plan to contribute the ppc64/bsd > port for integration into the OpenJDK, this has to be done into the head revision (currently jdk9) anyway. > Once it's there, it may be possible to downport it to jdk8u (but not > to jdk7u because that on doesn't even contain the ppc64 port). > > That said, which version of jdk7u are you using? Is it > the one from http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ ? > > One problem you may encounter with jdk7u is that it was > never compiled with new versions of gcc. I see you are using gcc4.8 > but we used 4.1.2 back then when we were doing the port. > > Another problem is that we didn't support the > serviceability agent in jdk7u. Support for the SA agent on Linux/ppc64 > (but not for AIX) was added in jdk8. The error you see in > vmStructs.cpp is most probably from SA coding. How does your file > vmStructs_bsd_ppc.hpp looks like. As you can see, > vmStructs_linux_ppc.hpp is empty in jdk7u for the ppc64 port while it has some code in jdk8u-dev and jdk9. > > Unfortunately the place in vmStructs.cpp where the error > happens is deeply nested macro coding so it's hard to say what's wrong > from the error message. You could preprocess the file and post that to > the list, maybe we can see more. Just issue the following command from > a shell from within /usr/ports/tmp/jdk7u/build/bsd- > ppc/hotspot/outputdir/bsd_ppc64_compiler2/product: > > g++48 -DBSD -DPPC64 -D_ALLBSD_SOURCE - D_GNU_SOURCE > -DPRODUCT - I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/prims - > I/usr/ports/tmp/jdk7u/hotspot/src/share/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/precompiled - > I/usr/ports/tmp/jdk7u/hotspot/src/cpu/ppc/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/os_cpu/bsd_ppc/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/os/bsd/vm - > I/usr/ports/tmp/jdk7u/hotspot/src/os/posix/vm -I../generated - > DHOTSPOT_RELEASE_VERSION="\"24.80-b11\"" - > DHOTSPOT_BUILD_TARGET="\"product\"" - DHOTSPOT_BUILD_USER="\"root\"" > -DHOTSPOT_LIB_ARCH=\"ppc\" - DHOTSPOT_VM_DISTRO="\"OpenJDK\"" - > DDEFAULT_LIBPATH="\"/lib:/usr/lib:/usr/local/lib\"" - > DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_ppc - > DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_bsd_ppc - > DTARGET_OS_ARCH_MODEL_bsd_ppc_64 -DTARGET_COMPILER_gcc - > DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new - > mpowerpc64 -pipe -DDONT_USE_PRECOMPILED_HEADER -O3 -fno-strict- > aliasing -D_LP64=1 -m64 -mminimal-toc -mcpu=powerpc64 -mtune=power5 - > minsert-sched-nops=regroup_exact -mno-multiple -mno-string - > DSAFEFETCH_STUBS -DINCLUDE_TRACE=1 -Werror -Wpointer-arith - > Wconversion -Wsign-compare -E > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp > > Regards, > > Volker > > > > On Sun, Jan 10, 2016 at 3:04 PM, Curtis Hamilton > > wrote: > > Hello, > > I?d like to know if there?s been any work done > to support PPC for *BSD? > > I?ve hacked both the AIX and Linux PPC headers > but have been unsuccessful in building HotSpot. All modules seem to > build with the exception of VMStructs.cpp with the below error. > > > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cp > p: In static member function 'static void VMStructs::init()': > > /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cp > p:3015: error: cannot convert 'pthread**' to 'pid_t*' in > initialization > > Build log is attached. > > Thanks in advance! > > > > Curtis > > > > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Stats.txt URL: From volker.simonis at gmail.com Mon Feb 15 08:10:00 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 15 Feb 2016 09:10:00 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: <017a01d1667e$82d20750$887615f0$@verizon.net> References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> <00f201d1655e$465323c0$d2f96b40$@verizon.net> <87a664accf3f4760b00d2d8411e9aedf@DEWDFE13DE09.global.corp.sap> <017a01d1667e$82d20750$887615f0$@verizon.net> Message-ID: Hi Chris, as far as I can see, a lot of network/nio tests are failing. You'll probably have to take a look at the native network/nio implementation under: jdk/src/java.base/{share,unix}/native/{libnet,libnio} Unfortunately this code is quite old and ugly in the sense that it contains a lot of platform-specif ifdefs. It sometimes contains implicit assumptions like "bsd means macos" or "not solaris meaning linux" which have worked until no but which may now be wrong for FreeBSD. You'll probably have to take some of the failing tests and debug the native implementations to see what is happening. Regarding your other problem with the dist directory I'd advice to build on Linux with "make hotspot-only LOG=debug JOBS=1" to see where the corresponding directories are being created. You can then easily identify the corresponding makefile parts which you'll have to update. Regards, Volker On Sat, Feb 13, 2016 at 5:49 PM, Curtis Hamilton wrote: > Thomas/Volker, et al > > Thanks to your assistance, I've been SUCCESSFUL in building a native ppc64 jdk8 on FreeBSD. > > To validate the build, I made a couple of regression test runs with results similar to the Zero VM build in the same environment. Although, not all tests completed successfully (some of the failed test were due to missing test files in the distribution). The regression test stats file is attached. > > I've created a set of initial patches for the code and several patches for the build system. However, there's one build system issue that I've not yet resolved. At the end of the Hotspot build, it errors because it cannot find jvmti.hmtl, jvmti.h, libjsig.so and libjvm.so. The files exist, but the "HOTSPOT_DIST" directory structure has not been created, with these files in the locations the build system expects. I'm sure that this is because of building a Compiler2 variant on a non-supported platform, as I don't have this issue with the Zero VM build. Thus, I manually created the "dist" structure and placed the files in the expected locations and the remainder of the build works as designed. Any thoughts? > > I'm going to continue to stress test the build, to ensure everything is in working order. > > Again, thanks for all the assistance. > > Regards, > Curtis > > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: Friday, February 12, 2016 3:28 AM > To: Thomas St?fe ; Curtis Hamilton > Cc: ppc-aix-port-dev at openjdk.java.net; bsd-port-dev at openjdk.java.net > Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support > > Hi Curtis, > > If SIGTRAP ist he problem, you could try -XX:-UseSIGTRAP. > This slows down null checks a bit, but this should not matter for now. > > Best regards, > Goetz > >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> bounces at openjdk.java.net] On Behalf Of Thomas St?fe >> Sent: Freitag, 12. Februar 2016 08:08 >> To: Curtis Hamilton >> Cc: ppc-aix-port-dev at openjdk.java.net; bsd-port-dev at openjdk.java.net >> Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support >> >> Hi Curtis, >> >> I think it makes sense to post this on the bsd list too. >> >> See my comments inline. >> >> On Fri, Feb 12, 2016 at 7:26 AM, Curtis Hamilton > > wrote: >> >> >> Thomas/Volker, >> >> >> >> Just wanted to give you an update on my bsd/ppc64 porting effort. >> I?m using the standard bsd openjdk8 port, as the bsd mercurial needs >> freebsd specific patches. >> >> >> >> I?ve made progress modding the linux/ppc files to work under bsd >> and can successfully build a native (ppc64) JVM. Here?s the output I >> get executing ?java ?version? >> >> >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # ./java -version >> openjdk version "1.8.0_72-debug" >> OpenJDK Runtime Environment (build 1.8.0_72-debug-b15) >> OpenJDK 64-Bit Server VM (build 25.72-b15-debug, mixed mode) >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # >> >> >> Great Job! >> >> >> >> I can compile and execute the basic ?hello world?. However, >> compiling more complicated java code results in a core dump. See the >> following: >> >> >> >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # ./javac HelloWorld.java >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # ./java HelloWorld >> Hello, World >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # ./javac zip.java >> Trace/BPT trap (core dumped) >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # ./javac LargeZip.java >> Trace/BPT trap (core dumped) >> root at lenoil8:/usr/ports/java/openjdk8/work/openjdk/build/bsd- >> ppc64-normal-server-slowdebug/jdk/bin # >> >> As you can see this is a debug build and I?ve been able to tell >> from the core dump, using gdb, that it?s getting a signal 5 at abort. >> >> >> >> >> I think SIGTRAP is used by the ppc JIT for some things (implicit nullchecks? >> Volker would know better). So, SIGTRAP must be handled for this to work. >> >> The JVM has a central signal handler, entry point is "signalHandler" >> in os_.cpp, and then it goes on to, in your case, >> JVM_handler_bsd_signal() in os_bsd_ppc.cpp. >> >> So, make sure that >> >> 1) SIGTRAP is handled by this signal handler - I think, by default bsd >> does not install a signal handler for SIGTRAP. See >> os::Bsd::install_signal_handlers(), >> and compare it with the Linux version. >> >> 2) Then, SIGTRAP must be handled in JVM_handler_bsd_signal(). Compare >> with the SIGTRAP handling for Linux (os_linux_ppc.cpp). But if you >> copied that code, maybe SIGTRAP handling is already in place and (1) >> was all that was missing. >> >> Also note: The jvm normally writes a error log on crashes which is >> very useful >> ("hs_err_") but in your case it was not written at all, because >> no signal handler was installed for SIGTRAP. So, if you took care of >> (1) but (2) is still missing, you may still crash but with a real error report log this time. >> >> Side note: Magnus Ihse Bursie is cleaning up and repairing the BSD port, see: >> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016- >> January/002739.html >> >> His changes are not yet committed, but he posted a webrev with his >> changes >> (http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source- >> patches/webrev.01/). It may make sense to integrate this in your >> build, he did some worthwhile fixes. >> >> Kind Regards, Thomas >> >> >> >> >> Any recommendations on what to look at or how to further debug? >> >> >> >> Regards, >> >> >> >> Curtis >> >> >> >> From: Curtis Hamilton [mailto:hamiltcl at verizon.net >> ] >> Sent: Monday, January 11, 2016 3:29 PM >> To: 'Thomas St?fe' > > >> Cc: 'Volker Simonis' > >; >> 'ppc-aix-port-dev at openjdk.java.net >> ' > dev at openjdk.java.net > >> Subject: RE: PPC-AIX Port to FreeBSD PowerPC Support >> >> >> >> Thomas, >> >> >> >> Thanks for the vector check! >> >> >> >> I agree that the AIX os is quite different from other unices (I >> have an old PowerStation 220 in my collection). However, the >> ppc-aix-port was the first that contained code specific to the ppc. >> Since there isn?t a ppc-bsd port, I needed somewhere to start. PPC code for both AIX and Linux can be found >> in the same port. The ports available on FreeBSD currently do contain any of >> the ppc headers or code. So I decided to use a port that already had >> the ppc code and go from there. >> >> >> >> Now that ppc code is being integrated into a more universal >> port, I just need to check which jdk8 port to work with. >> >> >> >> Any recommendation? >> >> >> >> Regards, >> >> Curtis >> >> >> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com >> ] >> Sent: Monday, January 11, 2016 11:23 AM >> To: Curtis Hamilton > > >> Cc: Volker Simonis > >; ppc-aix-port-dev at openjdk.java.net >> >> >> >> Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support >> >> >> >> >> >> Hi Curtis, >> >> >> >> I am not sure that AIX ppc would be the best source for an BSD port. >> AIX os port contains a large number of AIX specifics and it is quite a >> bit different (sometimes, needlessly) from the other Unices. It is >> also a moving target, at least on jdk9, as we changed a lot in the AIX >> os port and will change more until the next feature close. >> >> >> >> So, it may be that linux ppc would be a better porting source >> for a bsd ppc port. >> >> >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jan 11, 2016 at 3:21 PM, Curtis Hamilton >> > wrote: >> >> Volker, >> >> >> >> Thanks for the response. >> >> >> >> Yes, I?m using the mercurial jdk7u ppc-aix version. The >> reason I used this port version was because I was more familiar with >> the build layout of jdk7 versus jdk8/jdk9. And it seemed like an >> easier target to start with, since it already supported ppc64 on AIX and Linux. >> >> >> >> Full disclosure, I?ve been successful in building zero vm for >> both jdk7 and jdk8 on ppc64/FreeBSD. They both work great. The system >> performance is somewhat sluggish, but usable. So I decided to see if >> I could build native ppc64 versions leveraging the existing AIX and >> Linux ppc64 support in the ppc-aix-port, since the bsd-port lacks support for PowerPC. >> >> >> >> I?m aware of the integration effort for jdk9. So on >> your advice, I will start working with ppc-aix jdk8u. I don?t want >> anyone to waste time with jdk7u. Although my efforts with this older >> version is not completely wasted. >> >> >> >> I look forward to contributing to the ppc64/bsd port >> OpenJDK integration effort. >> >> >> >> Regards, >> >> Curtis >> >> >> >> From: Volker Simonis [mailto:volker.simonis at gmail.com >> ] >> Sent: Monday, January 11, 2016 5:22 AM >> To: Curtis Hamilton > > >> Cc: ppc-aix-port-dev at openjdk.java.net >> >> Subject: Re: PPC-AIX Port to FreeBSD PowerPC Support >> >> >> >> Hi Curtis, >> >> no, I'm not aware of any effort to port the ppc64 port to BSD. >> >> My first question is why are you building jdk7. It is >> quite old and we don't actually support it any more. It was also never >> integrated into the main jdk7u branch. I'd strongly recommend to use >> at least the jdk8u version. If you plan to contribute the ppc64/bsd >> port for integration into the OpenJDK, this has to be done into the head revision (currently jdk9) anyway. >> Once it's there, it may be possible to downport it to jdk8u (but not >> to jdk7u because that on doesn't even contain the ppc64 port). >> >> That said, which version of jdk7u are you using? Is it >> the one from http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ ? >> >> One problem you may encounter with jdk7u is that it was >> never compiled with new versions of gcc. I see you are using gcc4.8 >> but we used 4.1.2 back then when we were doing the port. >> >> Another problem is that we didn't support the >> serviceability agent in jdk7u. Support for the SA agent on Linux/ppc64 >> (but not for AIX) was added in jdk8. The error you see in >> vmStructs.cpp is most probably from SA coding. How does your file >> vmStructs_bsd_ppc.hpp looks like. As you can see, >> vmStructs_linux_ppc.hpp is empty in jdk7u for the ppc64 port while it has some code in jdk8u-dev and jdk9. >> >> Unfortunately the place in vmStructs.cpp where the error >> happens is deeply nested macro coding so it's hard to say what's wrong >> from the error message. You could preprocess the file and post that to >> the list, maybe we can see more. Just issue the following command from >> a shell from within /usr/ports/tmp/jdk7u/build/bsd- >> ppc/hotspot/outputdir/bsd_ppc64_compiler2/product: >> >> g++48 -DBSD -DPPC64 -D_ALLBSD_SOURCE - D_GNU_SOURCE >> -DPRODUCT - I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/prims - >> I/usr/ports/tmp/jdk7u/hotspot/src/share/vm - >> I/usr/ports/tmp/jdk7u/hotspot/src/share/vm/precompiled - >> I/usr/ports/tmp/jdk7u/hotspot/src/cpu/ppc/vm - >> I/usr/ports/tmp/jdk7u/hotspot/src/os_cpu/bsd_ppc/vm - >> I/usr/ports/tmp/jdk7u/hotspot/src/os/bsd/vm - >> I/usr/ports/tmp/jdk7u/hotspot/src/os/posix/vm -I../generated - >> DHOTSPOT_RELEASE_VERSION="\"24.80-b11\"" - >> DHOTSPOT_BUILD_TARGET="\"product\"" - DHOTSPOT_BUILD_USER="\"root\"" >> -DHOTSPOT_LIB_ARCH=\"ppc\" - DHOTSPOT_VM_DISTRO="\"OpenJDK\"" - >> DDEFAULT_LIBPATH="\"/lib:/usr/lib:/usr/local/lib\"" - >> DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_ppc - >> DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_bsd_ppc - >> DTARGET_OS_ARCH_MODEL_bsd_ppc_64 -DTARGET_COMPILER_gcc - >> DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new - >> mpowerpc64 -pipe -DDONT_USE_PRECOMPILED_HEADER -O3 -fno-strict- >> aliasing -D_LP64=1 -m64 -mminimal-toc -mcpu=powerpc64 -mtune=power5 - >> minsert-sched-nops=regroup_exact -mno-multiple -mno-string - >> DSAFEFETCH_STUBS -DINCLUDE_TRACE=1 -Werror -Wpointer-arith - >> Wconversion -Wsign-compare -E >> /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Regards, >> >> Volker >> >> >> >> On Sun, Jan 10, 2016 at 3:04 PM, Curtis Hamilton >> > wrote: >> >> Hello, >> >> I?d like to know if there?s been any work done >> to support PPC for *BSD? >> >> I?ve hacked both the AIX and Linux PPC headers >> but have been unsuccessful in building HotSpot. All modules seem to >> build with the exception of VMStructs.cpp with the below error. >> >> >> /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cp >> p: In static member function 'static void VMStructs::init()': >> >> /usr/ports/tmp/jdk7u/hotspot/src/share/vm/runtime/vmStructs.cp >> p:3015: error: cannot convert 'pthread**' to 'pid_t*' in >> initialization >> >> Build log is attached. >> >> Thanks in advance! >> >> >> >> Curtis >> >> >> >> >> >> >> > From gromero at linux.vnet.ibm.com Mon Feb 15 14:22:38 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 15 Feb 2016 12:22:38 -0200 Subject: RTM disabled for Linux on PPC64 LE In-Reply-To: References: <56BDE1EF.1020305@linux.vnet.ibm.com> Message-ID: <56C1DF2E.8070603@linux.vnet.ibm.com> Hello Martin, Thank you for your reply. The problematic behavior of syscalls has been addressed since kernel 4.2 (already present in, por instance, Ubuntu 15.10 and 16.04): https://goo.gl/d80xAJ I'm taking a closer look at the RTM tests and I'll make additional experiments as you suggested. So far I enabled RTM for Linux on ppc64le and there is no regression in the RTM test suite. I'm using kernel 4.2.0. The following patch was applied to http://hg.openjdk.java.net/jdk9/jdk9/hotspot, 5d17092b6917+ tip, and I used the (major + minor) version to enable RTM as you said: # HG changeset patch # User gromero # Date 1455540780 7200 # Mon Feb 15 10:53:00 2016 -0200 # Node ID 0e9540f2156c4c4d7d8215eb89109ff81be82f58 # Parent 5d17092b691720d71f06360fb0cc183fe2877faa Enable RTM for Linux on PPC64 LE Enable RTM for Linux kernel version equal or above 4.2, since the problematic behavior of performing a syscall from within transaction which could lead to unpredictable results has been addressed. Please, refer to https://goo.gl/fi4tjC diff --git a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp --- a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp +++ b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp @@ -52,4 +52,9 @@ #define INCLUDE_RTM_OPT 1 #endif +// Enable RTM experimental support for Linux. +#if defined(COMPILER2) && defined(linux) +#define INCLUDE_RTM_OPT 1 +#endif + #endif // CPU_PPC_VM_GLOBALDEFINITIONS_PPC_HPP diff --git a/src/cpu/ppc/vm/vm_version_ppc.cpp b/src/cpu/ppc/vm/vm_version_ppc.cpp --- a/src/cpu/ppc/vm/vm_version_ppc.cpp +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp @@ -255,7 +255,12 @@ } #endif #ifdef linux - // TODO: check kernel version (we currently have too old versions only) + // At least Linux kernel 4.2, as the problematic behavior of syscalls + // being called from within a transaction has been addressed. + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7 + if (os::Linux::os_version() >= 0x040200) { + os_too_old = false; + } #endif if (os_too_old) { vm_exit_during_initialization("RTM is not supported on this OS version."); diff --git a/src/os/linux/vm/os_linux.cpp b/src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp +++ b/src/os/linux/vm/os_linux.cpp @@ -135,6 +135,7 @@ int os::Linux::_page_size = -1; const int os::Linux::_vm_default_page_size = (8 * K); bool os::Linux::_supports_fast_thread_cpu_time = false; +uint32_t os::Linux::_os_version = 0; const char * os::Linux::_glibc_version = NULL; const char * os::Linux::_libpthread_version = NULL; pthread_condattr_t os::Linux::_condattr[1]; @@ -4332,6 +4333,31 @@ return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; } +void os::Linux::initialize_os_info() { + assert(_os_version == 0, "OS info already initialized"); + + struct utsname _uname; + + uint32_t major; + uint32_t minor; + uint32_t fix; + + uname(&_uname); // Not sure yet how to bail out if ret == -1 + sscanf(_uname.release,"%d.%d.%d", &major, + &minor, + &fix ); + + _os_version = (major << 16) | + (minor << 8 ) | + (fix << 0 ) ; +} + +uint32_t os::Linux::os_version() { + assert(_os_version != 0, "not initialized"); + return _os_version; +} + + ///// // glibc on Linux platform uses non-documented flag // to indicate, that some special sort of signal @@ -4552,6 +4578,8 @@ } init_page_sizes((size_t) Linux::page_size()); + Linux::initialize_os_info(); + Linux::initialize_system_info(); // main_thread points to the aboriginal thread diff --git a/src/os/linux/vm/os_linux.hpp b/src/os/linux/vm/os_linux.hpp --- a/src/os/linux/vm/os_linux.hpp +++ b/src/os/linux/vm/os_linux.hpp @@ -56,6 +56,12 @@ static GrowableArray* _cpu_to_node; + // Ox00AABBCC + // AA, Major Version + // BB, Minor Version + // CC, Fix Version + static uint32_t _os_version; + protected: static julong _physical_memory; @@ -198,6 +204,9 @@ static jlong fast_thread_cpu_time(clockid_t clockid); + static void initialize_os_info(); + static uint32_t os_version(); + // pthread_cond clock suppport private: static pthread_condattr_t _condattr[1]; Should I use any test suite besides the jtreg suite already present in the Hotspot forest? Best Regards, Gustavo On 12-02-2016 12:52, Doerr, Martin wrote: > Hi Gustavo, > > the reason why we disabled RTM for linux on PPC64 (big or little endian) was the problematic behavior of syscalls. > The old version of the document > www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt > said: > ?Performing syscalls from within transaction is not recommended, and can lead to unpredictable results.? > > Transactions need to either pass completely or roll back completely without disturbing side effects of partially executed syscalls. > We rely on the kernel to abort transactions if necessary. > > The document has changed and it may possibly work with a new linux kernel. > However, we don't have such a new kernel, yet. So we can't test it at the moment. > I don't know which kernel version exactly contains the change. I guess this exact version number (major + minor) should be used for enabling RTM. > > I haven't looked into the tests, yet. There may be a need for additional adaptations and fixes. > > We appreciate if you make experiments and/or contributions. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero > Sent: Freitag, 12. Februar 2016 14:45 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RTM disabled for Linux on PPC64 LE > Importance: High > > Hi, > As of now (tip 1922:be58b02c11f9, jdk9/jdk9 repo) Hotspot build for Linux on ppc64le of fails due to a simple uninitialized variable error: > > hotspot/src/share/vm/ci/ciMethodData.hpp:585:100: error: ?data? may be used uninitialized in this function > hotspot/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp:2408:78: error: ?md? may be used uninitialized in this function > > So this straightforward patch solves the issue: > diff -r 534c50395957 src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp > --- a/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Thu Jan 28 15:42:23 2016 -0800 > +++ b/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Mon Feb 08 17:13:14 2016 -0200 > @@ -2321,8 +2321,8 @@ > if (reg_conflict) { obj = dst; } > } > - ciMethodData* md; > - ciProfileData* data; > + ciMethodData* md = NULL; > + ciProfileData* data = NULL; > int mdo_offset_bias = 0; compiler/rtm > if (should_profile) { > ciMethod* method = op->profiled_method(); > > However, after the build, I realized that RTM is still disabled for Linux on ppc64le, failing 25 tests on compiler/rtm suite: > > http://hastebin.com/raw/ohoxiwaqih > > Hence after applying the following patches that enable RTM for Linux on ppc64le: > > diff -r 266fa9bb5297 src/cpu/ppc/vm/vm_version_ppc.cpp > --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Thu Feb 04 16:48:39 2016 -0800 > +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Feb 12 10:55:46 2016 -0200 > @@ -255,7 +255,9 @@ > } > #endif > #ifdef linux > - // TODO: check kernel version (we currently have too old versions only) > + if (os::Linux::os_version() >= 4) { // at least Linux kernel version 4 > + os_too_old = false; > + } > #endif > if (os_too_old) { > vm_exit_during_initialization("RTM is not supported on this OS version."); > > > diff -r 266fa9bb5297 src/os/linux/vm/os_linux.cpp > --- a/src/os/linux/vm/os_linux.cpp Thu Feb 04 16:48:39 2016 -0800 > +++ b/src/os/linux/vm/os_linux.cpp Fri Feb 12 10:58:10 2016 -0200 > @@ -135,6 +135,7 @@ > int os::Linux::_page_size = -1; > const int os::Linux::_vm_default_page_size = (8 * K); > bool os::Linux::_supports_fast_thread_cpu_time = false; > +uint32_t os::Linux::_os_version = 0; > const char * os::Linux::_glibc_version = NULL; > const char * os::Linux::_libpthread_version = NULL; > pthread_condattr_t os::Linux::_condattr[1]; > @@ -4332,6 +4333,21 @@ > return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; > } > +void os::Linux::initialize_os_info() { > + assert(_os_version == 0, "OS info already initialized"); > + > + struct utsname _uname; > + + uname(&_uname); // Not sure yet how deal if ret == -1 > + _os_version = atoi(_uname.release); > +} > + > +uint32_t os::Linux::os_version() { > + assert(_os_version != 0, "not initialized"); > + return _os_version; > +} > + > + > ///// > // glibc on Linux platform uses non-documented flag > // to indicate, that some special sort of signal > @@ -4553,6 +4569,7 @@ > init_page_sizes((size_t) Linux::page_size()); > Linux::initialize_system_info(); > + Linux::initialize_os_info(); > // main_thread points to the aboriginal thread > Linux::_main_thread = pthread_self(); > > > diff -r 266fa9bb5297 src/os/linux/vm/os_linux.hpp > --- a/src/os/linux/vm/os_linux.hpp Thu Feb 04 16:48:39 2016 -0800 > +++ b/src/os/linux/vm/os_linux.hpp Fri Feb 12 10:59:01 2016 -0200 > @@ -55,7 +55,7 @@ > static bool _supports_fast_thread_cpu_time; > static GrowableArray* _cpu_to_node; > - > + static uint32_t _os_version; protected: > static julong _physical_memory; > @@ -198,6 +198,9 @@ > static jlong fast_thread_cpu_time(clockid_t clockid); > + static void initialize_os_info(); > + static uint32_t os_version(); + > // pthread_cond clock suppport > private: > static pthread_condattr_t _condattr[1]; > > > 23 tests are now passing: http://hastebin.com/raw/oyicagusod > > Is there a reason to let RTM disabled for Linux on ppc64le by now? Could somebody explain what is currently missing on PPC64 LE RTM implementation in order to make all RTM tests pass? > > Thank you. > > Regards, > -- > Gustavo Romero > From martin.doerr at sap.com Tue Feb 16 13:33:31 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 16 Feb 2016 13:33:31 +0000 Subject: RTM disabled for Linux on PPC64 LE In-Reply-To: <56C1DF2E.8070603@linux.vnet.ibm.com> References: <56BDE1EF.1020305@linux.vnet.ibm.com> <56C1DF2E.8070603@linux.vnet.ibm.com> Message-ID: <82585848434d4624ae08ccacac542a17@DEWDFE13DE14.global.corp.sap> Hi Gustavo, thanks for the information and for working on this topic. I have used SPEC jbb2005 to test and benchmark RTM on PPC64. It has worked even with the old linux kernel to some extent. There are currently the following problems: The C2's scratch buffer seems to be too small if you enable all options: -XX:+UnlockExperimentalVMOptions -XX:+UseRTMLocking -XX:+UseRTMForStackLocks -XX:+UseRTMDeopt I guess we need to increase MAX_inst_size in ScratchBufferBlob (compile.hpp). I didn't have the time to try, yet. The following issue is important for performance work: RTM does not work with BiasedLocking. The latter gets switched off if RTM is activated which has a large performance impact (especially in jbb2005). I would disable it for a reference measurement: -XX:-UseBiasedLocking Unfortunately, RTM was slower than BiasedLocking but faster than the reference (without both) which tells me that there's room for improvement. There are basically 3 classes of locks: 1. no contention 2. contention on lock, low contention on data 3. high contention on data I believe the optimal treatment for the cases would be: 1. Biased Locking 2. Transactional Memory 3. classical locking with lock inflating I think it would be good if the JVM could optimize for all these cases in the future. But that would add additional complexity and code size. Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Montag, 15. Februar 2016 15:23 To: Doerr, Martin ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Cc: Breno Leitao Subject: Re: RTM disabled for Linux on PPC64 LE Hello Martin, Thank you for your reply. The problematic behavior of syscalls has been addressed since kernel 4.2 (already present in, por instance, Ubuntu 15.10 and 16.04): https://goo.gl/d80xAJ I'm taking a closer look at the RTM tests and I'll make additional experiments as you suggested. So far I enabled RTM for Linux on ppc64le and there is no regression in the RTM test suite. I'm using kernel 4.2.0. The following patch was applied to http://hg.openjdk.java.net/jdk9/jdk9/hotspot, 5d17092b6917+ tip, and I used the (major + minor) version to enable RTM as you said: # HG changeset patch # User gromero # Date 1455540780 7200 # Mon Feb 15 10:53:00 2016 -0200 # Node ID 0e9540f2156c4c4d7d8215eb89109ff81be82f58 # Parent 5d17092b691720d71f06360fb0cc183fe2877faa Enable RTM for Linux on PPC64 LE Enable RTM for Linux kernel version equal or above 4.2, since the problematic behavior of performing a syscall from within transaction which could lead to unpredictable results has been addressed. Please, refer to https://goo.gl/fi4tjC diff --git a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp --- a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp +++ b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp @@ -52,4 +52,9 @@ #define INCLUDE_RTM_OPT 1 #endif +// Enable RTM experimental support for Linux. +#if defined(COMPILER2) && defined(linux) +#define INCLUDE_RTM_OPT 1 +#endif + #endif // CPU_PPC_VM_GLOBALDEFINITIONS_PPC_HPP diff --git a/src/cpu/ppc/vm/vm_version_ppc.cpp b/src/cpu/ppc/vm/vm_version_ppc.cpp --- a/src/cpu/ppc/vm/vm_version_ppc.cpp +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp @@ -255,7 +255,12 @@ } #endif #ifdef linux - // TODO: check kernel version (we currently have too old versions only) + // At least Linux kernel 4.2, as the problematic behavior of syscalls + // being called from within a transaction has been addressed. + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7 + if (os::Linux::os_version() >= 0x040200) { + os_too_old = false; + } #endif if (os_too_old) { vm_exit_during_initialization("RTM is not supported on this OS version."); diff --git a/src/os/linux/vm/os_linux.cpp b/src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp +++ b/src/os/linux/vm/os_linux.cpp @@ -135,6 +135,7 @@ int os::Linux::_page_size = -1; const int os::Linux::_vm_default_page_size = (8 * K); bool os::Linux::_supports_fast_thread_cpu_time = false; +uint32_t os::Linux::_os_version = 0; const char * os::Linux::_glibc_version = NULL; const char * os::Linux::_libpthread_version = NULL; pthread_condattr_t os::Linux::_condattr[1]; @@ -4332,6 +4333,31 @@ return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; } +void os::Linux::initialize_os_info() { + assert(_os_version == 0, "OS info already initialized"); + + struct utsname _uname; + + uint32_t major; + uint32_t minor; + uint32_t fix; + + uname(&_uname); // Not sure yet how to bail out if ret == -1 + sscanf(_uname.release,"%d.%d.%d", &major, + &minor, + &fix ); + + _os_version = (major << 16) | + (minor << 8 ) | + (fix << 0 ) ; +} + +uint32_t os::Linux::os_version() { + assert(_os_version != 0, "not initialized"); + return _os_version; +} + + ///// // glibc on Linux platform uses non-documented flag // to indicate, that some special sort of signal @@ -4552,6 +4578,8 @@ } init_page_sizes((size_t) Linux::page_size()); + Linux::initialize_os_info(); + Linux::initialize_system_info(); // main_thread points to the aboriginal thread diff --git a/src/os/linux/vm/os_linux.hpp b/src/os/linux/vm/os_linux.hpp --- a/src/os/linux/vm/os_linux.hpp +++ b/src/os/linux/vm/os_linux.hpp @@ -56,6 +56,12 @@ static GrowableArray* _cpu_to_node; + // Ox00AABBCC + // AA, Major Version + // BB, Minor Version + // CC, Fix Version + static uint32_t _os_version; + protected: static julong _physical_memory; @@ -198,6 +204,9 @@ static jlong fast_thread_cpu_time(clockid_t clockid); + static void initialize_os_info(); + static uint32_t os_version(); + // pthread_cond clock suppport private: static pthread_condattr_t _condattr[1]; Should I use any test suite besides the jtreg suite already present in the Hotspot forest? Best Regards, Gustavo On 12-02-2016 12:52, Doerr, Martin wrote: > Hi Gustavo, > > the reason why we disabled RTM for linux on PPC64 (big or little endian) was the problematic behavior of syscalls. > The old version of the document > www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt > said: > ?Performing syscalls from within transaction is not recommended, and can lead to unpredictable results.? > > Transactions need to either pass completely or roll back completely without disturbing side effects of partially executed syscalls. > We rely on the kernel to abort transactions if necessary. > > The document has changed and it may possibly work with a new linux kernel. > However, we don't have such a new kernel, yet. So we can't test it at the moment. > I don't know which kernel version exactly contains the change. I guess this exact version number (major + minor) should be used for enabling RTM. > > I haven't looked into the tests, yet. There may be a need for additional adaptations and fixes. > > We appreciate if you make experiments and/or contributions. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero > Sent: Freitag, 12. Februar 2016 14:45 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RTM disabled for Linux on PPC64 LE > Importance: High > > Hi, > As of now (tip 1922:be58b02c11f9, jdk9/jdk9 repo) Hotspot build for Linux on ppc64le of fails due to a simple uninitialized variable error: > > hotspot/src/share/vm/ci/ciMethodData.hpp:585:100: error: ?data? may be used uninitialized in this function > hotspot/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp:2408:78: error: ?md? may be used uninitialized in this function > > So this straightforward patch solves the issue: > diff -r 534c50395957 src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp > --- a/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Thu Jan 28 15:42:23 2016 -0800 > +++ b/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Mon Feb 08 17:13:14 2016 -0200 > @@ -2321,8 +2321,8 @@ > if (reg_conflict) { obj = dst; } > } > - ciMethodData* md; > - ciProfileData* data; > + ciMethodData* md = NULL; > + ciProfileData* data = NULL; > int mdo_offset_bias = 0; compiler/rtm > if (should_profile) { > ciMethod* method = op->profiled_method(); > > However, after the build, I realized that RTM is still disabled for Linux on ppc64le, failing 25 tests on compiler/rtm suite: > > http://hastebin.com/raw/ohoxiwaqih > > Hence after applying the following patches that enable RTM for Linux on ppc64le: > > diff -r 266fa9bb5297 src/cpu/ppc/vm/vm_version_ppc.cpp > --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Thu Feb 04 16:48:39 2016 -0800 > +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Feb 12 10:55:46 2016 -0200 > @@ -255,7 +255,9 @@ > } > #endif > #ifdef linux > - // TODO: check kernel version (we currently have too old versions only) > + if (os::Linux::os_version() >= 4) { // at least Linux kernel version 4 > + os_too_old = false; > + } > #endif > if (os_too_old) { > vm_exit_during_initialization("RTM is not supported on this OS version."); > > > diff -r 266fa9bb5297 src/os/linux/vm/os_linux.cpp > --- a/src/os/linux/vm/os_linux.cpp Thu Feb 04 16:48:39 2016 -0800 > +++ b/src/os/linux/vm/os_linux.cpp Fri Feb 12 10:58:10 2016 -0200 > @@ -135,6 +135,7 @@ > int os::Linux::_page_size = -1; > const int os::Linux::_vm_default_page_size = (8 * K); > bool os::Linux::_supports_fast_thread_cpu_time = false; > +uint32_t os::Linux::_os_version = 0; > const char * os::Linux::_glibc_version = NULL; > const char * os::Linux::_libpthread_version = NULL; > pthread_condattr_t os::Linux::_condattr[1]; > @@ -4332,6 +4333,21 @@ > return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; > } > +void os::Linux::initialize_os_info() { > + assert(_os_version == 0, "OS info already initialized"); > + > + struct utsname _uname; > + + uname(&_uname); // Not sure yet how deal if ret == -1 > + _os_version = atoi(_uname.release); > +} > + > +uint32_t os::Linux::os_version() { > + assert(_os_version != 0, "not initialized"); > + return _os_version; > +} > + > + > ///// > // glibc on Linux platform uses non-documented flag > // to indicate, that some special sort of signal > @@ -4553,6 +4569,7 @@ > init_page_sizes((size_t) Linux::page_size()); > Linux::initialize_system_info(); > + Linux::initialize_os_info(); > // main_thread points to the aboriginal thread > Linux::_main_thread = pthread_self(); > > > diff -r 266fa9bb5297 src/os/linux/vm/os_linux.hpp > --- a/src/os/linux/vm/os_linux.hpp Thu Feb 04 16:48:39 2016 -0800 > +++ b/src/os/linux/vm/os_linux.hpp Fri Feb 12 10:59:01 2016 -0200 > @@ -55,7 +55,7 @@ > static bool _supports_fast_thread_cpu_time; > static GrowableArray* _cpu_to_node; > - > + static uint32_t _os_version; protected: > static julong _physical_memory; > @@ -198,6 +198,9 @@ > static jlong fast_thread_cpu_time(clockid_t clockid); > + static void initialize_os_info(); > + static uint32_t os_version(); + > // pthread_cond clock suppport > private: > static pthread_condattr_t _condattr[1]; > > > 23 tests are now passing: http://hastebin.com/raw/oyicagusod > > Is there a reason to let RTM disabled for Linux on ppc64le by now? Could somebody explain what is currently missing on PPC64 LE RTM implementation in order to make all RTM tests pass? > > Thank you. > > Regards, > -- > Gustavo Romero > From christoph.langer at sap.com Fri Feb 19 15:29:53 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 19 Feb 2016 15:29:53 +0000 Subject: RFR(S): AIX only: Integrate fixes of 7178026 and other minor things to AIX perfMemory and attachListener Message-ID: <8c8ec4f3d2d64084b98e91d8b6b9eda5@DEWDFE13DE11.global.corp.sap> Hi, I?ve integrated some changes that have been done in the perfMemory and attachListener implementations of the Linux/Unix platforms to the AIX counterpart. They have obviously been missing there so far. This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150232.0/ This is the bug: https://bugs.openjdk.java.net/browse/JDK-8150232 Please review and push if no objections. I?ve run a build on AIX successfully ? Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Fri Feb 19 21:35:19 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 19 Feb 2016 19:35:19 -0200 Subject: RTM disabled for Linux on PPC64 LE In-Reply-To: <82585848434d4624ae08ccacac542a17@DEWDFE13DE14.global.corp.sap> References: <56BDE1EF.1020305@linux.vnet.ibm.com> <56C1DF2E.8070603@linux.vnet.ibm.com> <82585848434d4624ae08ccacac542a17@DEWDFE13DE14.global.corp.sap> Message-ID: <56C78A97.8080908@linux.vnet.ibm.com> Hi Martin, I can't afford the PECjbb2005 by now, since it's paid. Instead I'm using the SPECjvm2008 suite. Thanks for bringing up the problem on C2's scratch buffer. Indeed, I've got a core dump when I combined +UseRTMLocking, +UseRTMForStackLocks, and +UseRTMDeopt (http://goo.gl/Sc5Ekp). I've experimented a little with the MAX_inst_size value and found that at least doubling it is sufficient to solve the problem: # HG changeset patch # User gromero # Date 1455916590 7200 # Fri Feb 19 19:16:30 2016 -0200 # Node ID 721c2e526fa7ee5e46b0ab7219e2acac90c4239b # Parent a83242700c91e294886d23c89061c1916682836c Fix C2 scratch buffer too small diff --git a/src/share/vm/opto/compile.hpp b/src/share/vm/opto/compile.hpp --- a/src/share/vm/opto/compile.hpp +++ b/src/share/vm/opto/compile.hpp @@ -1118,7 +1118,7 @@ bool in_scratch_emit_size() const { return _in_scratch_emit_size; } enum ScratchBufferBlob { - MAX_inst_size = 1024, + MAX_inst_size = 2048, MAX_locs_size = 128, // number of relocInfo elements MAX_const_size = 128, MAX_stubs_size = 128 Do you think we can fix it upstream and enable the RTM for Linux on ppc64le? Any guidelines on it? BTW, I'm still taking a deeper reflection on your comments about biased, RTM and classic locking. Best regards, -- Gustavo Romero On 16-02-2016 11:33, Doerr, Martin wrote: > Hi Gustavo, > > thanks for the information and for working on this topic. > > I have used SPEC jbb2005 to test and benchmark RTM on PPC64. It has worked even with the old linux kernel to some extent. > > There are currently the following problems: > The C2's scratch buffer seems to be too small if you enable all options: > -XX:+UnlockExperimentalVMOptions -XX:+UseRTMLocking -XX:+UseRTMForStackLocks -XX:+UseRTMDeopt > I guess we need to increase MAX_inst_size in ScratchBufferBlob (compile.hpp). I didn't have the time to try, yet. > > The following issue is important for performance work: > RTM does not work with BiasedLocking. The latter gets switched off if RTM is activated which has a large performance impact (especially in jbb2005). > I would disable it for a reference measurement: > -XX:-UseBiasedLocking > > Unfortunately, RTM was slower than BiasedLocking but faster than the reference (without both) which tells me that there's room for improvement. > There are basically 3 classes of locks: > 1. no contention > 2. contention on lock, low contention on data > 3. high contention on data > > I believe the optimal treatment for the cases would be: > 1. Biased Locking > 2. Transactional Memory > 3. classical locking with lock inflating > > I think it would be good if the JVM could optimize for all these cases in the future. But that would add additional complexity and code size. > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 15. Februar 2016 15:23 > To: Doerr, Martin ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Cc: Breno Leitao > Subject: Re: RTM disabled for Linux on PPC64 LE > > Hello Martin, > > Thank you for your reply. > > The problematic behavior of syscalls has been addressed since kernel 4.2 > (already present in, por instance, Ubuntu 15.10 and 16.04): > https://goo.gl/d80xAJ > > I'm taking a closer look at the RTM tests and I'll make additional > experiments as you suggested. > > So far I enabled RTM for Linux on ppc64le and there is no regression in > the RTM test suite. I'm using kernel 4.2.0. > > The following patch was applied to > http://hg.openjdk.java.net/jdk9/jdk9/hotspot, 5d17092b6917+ tip, and I > used the (major + minor) version to enable RTM as you said: > > # HG changeset patch > # User gromero > # Date 1455540780 7200 > # Mon Feb 15 10:53:00 2016 -0200 > # Node ID 0e9540f2156c4c4d7d8215eb89109ff81be82f58 > # Parent 5d17092b691720d71f06360fb0cc183fe2877faa > Enable RTM for Linux on PPC64 LE > > Enable RTM for Linux kernel version equal or above 4.2, since the > problematic behavior of performing a syscall from within transaction > which could lead to unpredictable results has been addressed. Please, > refer to https://goo.gl/fi4tjC > > diff --git a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp > --- a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp > +++ b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp > @@ -52,4 +52,9 @@ > #define INCLUDE_RTM_OPT 1 > #endif > > +// Enable RTM experimental support for Linux. > +#if defined(COMPILER2) && defined(linux) > +#define INCLUDE_RTM_OPT 1 > +#endif > + > #endif // CPU_PPC_VM_GLOBALDEFINITIONS_PPC_HPP > diff --git a/src/cpu/ppc/vm/vm_version_ppc.cpp b/src/cpu/ppc/vm/vm_version_ppc.cpp > --- a/src/cpu/ppc/vm/vm_version_ppc.cpp > +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp > @@ -255,7 +255,12 @@ > } > #endif > #ifdef linux > - // TODO: check kernel version (we currently have too old versions only) > + // At least Linux kernel 4.2, as the problematic behavior of syscalls > + // being called from within a transaction has been addressed. > + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7 > + if (os::Linux::os_version() >= 0x040200) { > + os_too_old = false; > + } > #endif > if (os_too_old) { > vm_exit_during_initialization("RTM is not supported on this OS version."); > diff --git a/src/os/linux/vm/os_linux.cpp b/src/os/linux/vm/os_linux.cpp > --- a/src/os/linux/vm/os_linux.cpp > +++ b/src/os/linux/vm/os_linux.cpp > @@ -135,6 +135,7 @@ > int os::Linux::_page_size = -1; > const int os::Linux::_vm_default_page_size = (8 * K); > bool os::Linux::_supports_fast_thread_cpu_time = false; > +uint32_t os::Linux::_os_version = 0; > const char * os::Linux::_glibc_version = NULL; > const char * os::Linux::_libpthread_version = NULL; > pthread_condattr_t os::Linux::_condattr[1]; > @@ -4332,6 +4333,31 @@ > return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; > } > > +void os::Linux::initialize_os_info() { > + assert(_os_version == 0, "OS info already initialized"); > + > + struct utsname _uname; > + > + uint32_t major; > + uint32_t minor; > + uint32_t fix; > + > + uname(&_uname); // Not sure yet how to bail out if ret == -1 > + sscanf(_uname.release,"%d.%d.%d", &major, > + &minor, > + &fix ); > + > + _os_version = (major << 16) | > + (minor << 8 ) | > + (fix << 0 ) ; > +} > + > +uint32_t os::Linux::os_version() { > + assert(_os_version != 0, "not initialized"); > + return _os_version; > +} > + > + > ///// > // glibc on Linux platform uses non-documented flag > // to indicate, that some special sort of signal > @@ -4552,6 +4578,8 @@ > } > init_page_sizes((size_t) Linux::page_size()); > > + Linux::initialize_os_info(); > + > Linux::initialize_system_info(); > > // main_thread points to the aboriginal thread > diff --git a/src/os/linux/vm/os_linux.hpp b/src/os/linux/vm/os_linux.hpp > --- a/src/os/linux/vm/os_linux.hpp > +++ b/src/os/linux/vm/os_linux.hpp > @@ -56,6 +56,12 @@ > > static GrowableArray* _cpu_to_node; > > + // Ox00AABBCC > + // AA, Major Version > + // BB, Minor Version > + // CC, Fix Version > + static uint32_t _os_version; > + > protected: > > static julong _physical_memory; > @@ -198,6 +204,9 @@ > > static jlong fast_thread_cpu_time(clockid_t clockid); > > + static void initialize_os_info(); > + static uint32_t os_version(); > + > // pthread_cond clock suppport > private: > static pthread_condattr_t _condattr[1]; > > Should I use any test suite besides the jtreg suite already present > in the Hotspot forest? > > > Best Regards, > Gustavo > > On 12-02-2016 12:52, Doerr, Martin wrote: >> Hi Gustavo, >> >> the reason why we disabled RTM for linux on PPC64 (big or little endian) was the problematic behavior of syscalls. >> The old version of the document >> www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt >> said: >> ?Performing syscalls from within transaction is not recommended, and can lead to unpredictable results.? >> >> Transactions need to either pass completely or roll back completely without disturbing side effects of partially executed syscalls. >> We rely on the kernel to abort transactions if necessary. >> >> The document has changed and it may possibly work with a new linux kernel. >> However, we don't have such a new kernel, yet. So we can't test it at the moment. >> I don't know which kernel version exactly contains the change. I guess this exact version number (major + minor) should be used for enabling RTM. >> >> I haven't looked into the tests, yet. There may be a need for additional adaptations and fixes. >> >> We appreciate if you make experiments and/or contributions. >> >> Thanks and best regards, >> Martin >> >> >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero >> Sent: Freitag, 12. Februar 2016 14:45 >> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: RTM disabled for Linux on PPC64 LE >> Importance: High >> >> Hi, >> As of now (tip 1922:be58b02c11f9, jdk9/jdk9 repo) Hotspot build for Linux on ppc64le of fails due to a simple uninitialized variable error: >> >> hotspot/src/share/vm/ci/ciMethodData.hpp:585:100: error: ?data? may be used uninitialized in this function >> hotspot/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp:2408:78: error: ?md? may be used uninitialized in this function >> >> So this straightforward patch solves the issue: >> diff -r 534c50395957 src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp >> --- a/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Thu Jan 28 15:42:23 2016 -0800 >> +++ b/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Mon Feb 08 17:13:14 2016 -0200 >> @@ -2321,8 +2321,8 @@ >> if (reg_conflict) { obj = dst; } >> } >> - ciMethodData* md; >> - ciProfileData* data; >> + ciMethodData* md = NULL; >> + ciProfileData* data = NULL; >> int mdo_offset_bias = 0; compiler/rtm >> if (should_profile) { >> ciMethod* method = op->profiled_method(); >> >> However, after the build, I realized that RTM is still disabled for Linux on ppc64le, failing 25 tests on compiler/rtm suite: >> >> http://hastebin.com/raw/ohoxiwaqih >> >> Hence after applying the following patches that enable RTM for Linux on ppc64le: >> >> diff -r 266fa9bb5297 src/cpu/ppc/vm/vm_version_ppc.cpp >> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Thu Feb 04 16:48:39 2016 -0800 >> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Feb 12 10:55:46 2016 -0200 >> @@ -255,7 +255,9 @@ >> } >> #endif >> #ifdef linux >> - // TODO: check kernel version (we currently have too old versions only) >> + if (os::Linux::os_version() >= 4) { // at least Linux kernel version 4 >> + os_too_old = false; >> + } >> #endif >> if (os_too_old) { >> vm_exit_during_initialization("RTM is not supported on this OS version."); >> >> >> diff -r 266fa9bb5297 src/os/linux/vm/os_linux.cpp >> --- a/src/os/linux/vm/os_linux.cpp Thu Feb 04 16:48:39 2016 -0800 >> +++ b/src/os/linux/vm/os_linux.cpp Fri Feb 12 10:58:10 2016 -0200 >> @@ -135,6 +135,7 @@ >> int os::Linux::_page_size = -1; >> const int os::Linux::_vm_default_page_size = (8 * K); >> bool os::Linux::_supports_fast_thread_cpu_time = false; >> +uint32_t os::Linux::_os_version = 0; >> const char * os::Linux::_glibc_version = NULL; >> const char * os::Linux::_libpthread_version = NULL; >> pthread_condattr_t os::Linux::_condattr[1]; >> @@ -4332,6 +4333,21 @@ >> return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; >> } >> +void os::Linux::initialize_os_info() { >> + assert(_os_version == 0, "OS info already initialized"); >> + >> + struct utsname _uname; >> + + uname(&_uname); // Not sure yet how deal if ret == -1 >> + _os_version = atoi(_uname.release); >> +} >> + >> +uint32_t os::Linux::os_version() { >> + assert(_os_version != 0, "not initialized"); >> + return _os_version; >> +} >> + >> + >> ///// >> // glibc on Linux platform uses non-documented flag >> // to indicate, that some special sort of signal >> @@ -4553,6 +4569,7 @@ >> init_page_sizes((size_t) Linux::page_size()); >> Linux::initialize_system_info(); >> + Linux::initialize_os_info(); >> // main_thread points to the aboriginal thread >> Linux::_main_thread = pthread_self(); >> >> >> diff -r 266fa9bb5297 src/os/linux/vm/os_linux.hpp >> --- a/src/os/linux/vm/os_linux.hpp Thu Feb 04 16:48:39 2016 -0800 >> +++ b/src/os/linux/vm/os_linux.hpp Fri Feb 12 10:59:01 2016 -0200 >> @@ -55,7 +55,7 @@ >> static bool _supports_fast_thread_cpu_time; >> static GrowableArray* _cpu_to_node; >> - >> + static uint32_t _os_version; protected: >> static julong _physical_memory; >> @@ -198,6 +198,9 @@ >> static jlong fast_thread_cpu_time(clockid_t clockid); >> + static void initialize_os_info(); >> + static uint32_t os_version(); + >> // pthread_cond clock suppport >> private: >> static pthread_condattr_t _condattr[1]; >> >> >> 23 tests are now passing: http://hastebin.com/raw/oyicagusod >> >> Is there a reason to let RTM disabled for Linux on ppc64le by now? Could somebody explain what is currently missing on PPC64 LE RTM implementation in order to make all RTM tests pass? >> >> Thank you. >> >> Regards, >> -- >> Gustavo Romero >> > From volker.simonis at gmail.com Mon Feb 22 09:49:02 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Feb 2016 10:49:02 +0100 Subject: RFR(S): AIX only: Integrate fixes of 7178026 and other minor things to AIX perfMemory and attachListener In-Reply-To: <8c8ec4f3d2d64084b98e91d8b6b9eda5@DEWDFE13DE11.global.corp.sap> References: <8c8ec4f3d2d64084b98e91d8b6b9eda5@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, thanks for doing this cleanup! The change looks good - I'll sponsor it. Regards, Volker On Fri, Feb 19, 2016 at 4:29 PM, Langer, Christoph wrote: > Hi, > > > > I?ve integrated some changes that have been done in the perfMemory and > attachListener implementations of the Linux/Unix platforms to the AIX > counterpart. They have obviously been missing there so far. > > > > This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150232.0/ > > This is the bug: https://bugs.openjdk.java.net/browse/JDK-8150232 > > > > Please review and push if no objections. I?ve run a build on AIX > successfully J > > > > Thanks > > Christoph > > > > From martin.doerr at sap.com Mon Feb 22 10:35:10 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 22 Feb 2016 10:35:10 +0000 Subject: RTM disabled for Linux on PPC64 LE In-Reply-To: <56C78A97.8080908@linux.vnet.ibm.com> References: <56BDE1EF.1020305@linux.vnet.ibm.com> <56C1DF2E.8070603@linux.vnet.ibm.com> <82585848434d4624ae08ccacac542a17@DEWDFE13DE14.global.corp.sap> <56C78A97.8080908@linux.vnet.ibm.com> Message-ID: <9588015c37c247ebb4282f75d12f4f32@DEWDFE13DE14.global.corp.sap> Hi Gustavo, I think the change should get contributed. I have opened a bug for it which is the first thing we need: JDK-8150353 Can you create and upload a webrev, please? The hg change comment should be: 8150353: PPC64LE: Support RTM on linux Reviewed-by: mdoerr When the webrev is there, please send out a request for review with the headline: RFR(M) 8150353: PPC64LE: Support RTM on linux Information about how to do this and about the review process can be found here: http://openjdk.java.net/guide/webrevHelp.html http://openjdk.java.net/guide/ http://openjdk.java.net/guide/codeReview.html If you have questions or problems feel free to contact us. Btw., do you think the big endian linux kernel will also contain the syscall change? If not, I suggest to only set INCLUDE_RTM_OPT to 1 on AIX and PPC64LE in globalDefinitions_ppc.hpp. #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN) Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Freitag, 19. Februar 2016 22:35 To: Doerr, Martin ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Cc: Breno Leitao Subject: Re: RTM disabled for Linux on PPC64 LE Hi Martin, I can't afford the PECjbb2005 by now, since it's paid. Instead I'm using the SPECjvm2008 suite. Thanks for bringing up the problem on C2's scratch buffer. Indeed, I've got a core dump when I combined +UseRTMLocking, +UseRTMForStackLocks, and +UseRTMDeopt (http://goo.gl/Sc5Ekp). I've experimented a little with the MAX_inst_size value and found that at least doubling it is sufficient to solve the problem: # HG changeset patch # User gromero # Date 1455916590 7200 # Fri Feb 19 19:16:30 2016 -0200 # Node ID 721c2e526fa7ee5e46b0ab7219e2acac90c4239b # Parent a83242700c91e294886d23c89061c1916682836c Fix C2 scratch buffer too small diff --git a/src/share/vm/opto/compile.hpp b/src/share/vm/opto/compile.hpp --- a/src/share/vm/opto/compile.hpp +++ b/src/share/vm/opto/compile.hpp @@ -1118,7 +1118,7 @@ bool in_scratch_emit_size() const { return _in_scratch_emit_size; } enum ScratchBufferBlob { - MAX_inst_size = 1024, + MAX_inst_size = 2048, MAX_locs_size = 128, // number of relocInfo elements MAX_const_size = 128, MAX_stubs_size = 128 Do you think we can fix it upstream and enable the RTM for Linux on ppc64le? Any guidelines on it? BTW, I'm still taking a deeper reflection on your comments about biased, RTM and classic locking. Best regards, -- Gustavo Romero On 16-02-2016 11:33, Doerr, Martin wrote: > Hi Gustavo, > > thanks for the information and for working on this topic. > > I have used SPEC jbb2005 to test and benchmark RTM on PPC64. It has worked even with the old linux kernel to some extent. > > There are currently the following problems: > The C2's scratch buffer seems to be too small if you enable all options: > -XX:+UnlockExperimentalVMOptions -XX:+UseRTMLocking -XX:+UseRTMForStackLocks -XX:+UseRTMDeopt > I guess we need to increase MAX_inst_size in ScratchBufferBlob (compile.hpp). I didn't have the time to try, yet. > > The following issue is important for performance work: > RTM does not work with BiasedLocking. The latter gets switched off if RTM is activated which has a large performance impact (especially in jbb2005). > I would disable it for a reference measurement: > -XX:-UseBiasedLocking > > Unfortunately, RTM was slower than BiasedLocking but faster than the reference (without both) which tells me that there's room for improvement. > There are basically 3 classes of locks: > 1. no contention > 2. contention on lock, low contention on data > 3. high contention on data > > I believe the optimal treatment for the cases would be: > 1. Biased Locking > 2. Transactional Memory > 3. classical locking with lock inflating > > I think it would be good if the JVM could optimize for all these cases in the future. But that would add additional complexity and code size. > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 15. Februar 2016 15:23 > To: Doerr, Martin ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Cc: Breno Leitao > Subject: Re: RTM disabled for Linux on PPC64 LE > > Hello Martin, > > Thank you for your reply. > > The problematic behavior of syscalls has been addressed since kernel 4.2 > (already present in, por instance, Ubuntu 15.10 and 16.04): > https://goo.gl/d80xAJ > > I'm taking a closer look at the RTM tests and I'll make additional > experiments as you suggested. > > So far I enabled RTM for Linux on ppc64le and there is no regression in > the RTM test suite. I'm using kernel 4.2.0. > > The following patch was applied to > http://hg.openjdk.java.net/jdk9/jdk9/hotspot, 5d17092b6917+ tip, and I > used the (major + minor) version to enable RTM as you said: > > # HG changeset patch > # User gromero > # Date 1455540780 7200 > # Mon Feb 15 10:53:00 2016 -0200 > # Node ID 0e9540f2156c4c4d7d8215eb89109ff81be82f58 > # Parent 5d17092b691720d71f06360fb0cc183fe2877faa > Enable RTM for Linux on PPC64 LE > > Enable RTM for Linux kernel version equal or above 4.2, since the > problematic behavior of performing a syscall from within transaction > which could lead to unpredictable results has been addressed. Please, > refer to https://goo.gl/fi4tjC > > diff --git a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp > --- a/src/cpu/ppc/vm/globalDefinitions_ppc.hpp > +++ b/src/cpu/ppc/vm/globalDefinitions_ppc.hpp > @@ -52,4 +52,9 @@ > #define INCLUDE_RTM_OPT 1 > #endif > > +// Enable RTM experimental support for Linux. > +#if defined(COMPILER2) && defined(linux) > +#define INCLUDE_RTM_OPT 1 > +#endif > + > #endif // CPU_PPC_VM_GLOBALDEFINITIONS_PPC_HPP > diff --git a/src/cpu/ppc/vm/vm_version_ppc.cpp b/src/cpu/ppc/vm/vm_version_ppc.cpp > --- a/src/cpu/ppc/vm/vm_version_ppc.cpp > +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp > @@ -255,7 +255,12 @@ > } > #endif > #ifdef linux > - // TODO: check kernel version (we currently have too old versions only) > + // At least Linux kernel 4.2, as the problematic behavior of syscalls > + // being called from within a transaction has been addressed. > + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7 > + if (os::Linux::os_version() >= 0x040200) { > + os_too_old = false; > + } > #endif > if (os_too_old) { > vm_exit_during_initialization("RTM is not supported on this OS version."); > diff --git a/src/os/linux/vm/os_linux.cpp b/src/os/linux/vm/os_linux.cpp > --- a/src/os/linux/vm/os_linux.cpp > +++ b/src/os/linux/vm/os_linux.cpp > @@ -135,6 +135,7 @@ > int os::Linux::_page_size = -1; > const int os::Linux::_vm_default_page_size = (8 * K); > bool os::Linux::_supports_fast_thread_cpu_time = false; > +uint32_t os::Linux::_os_version = 0; > const char * os::Linux::_glibc_version = NULL; > const char * os::Linux::_libpthread_version = NULL; > pthread_condattr_t os::Linux::_condattr[1]; > @@ -4332,6 +4333,31 @@ > return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; > } > > +void os::Linux::initialize_os_info() { > + assert(_os_version == 0, "OS info already initialized"); > + > + struct utsname _uname; > + > + uint32_t major; > + uint32_t minor; > + uint32_t fix; > + > + uname(&_uname); // Not sure yet how to bail out if ret == -1 > + sscanf(_uname.release,"%d.%d.%d", &major, > + &minor, > + &fix ); > + > + _os_version = (major << 16) | > + (minor << 8 ) | > + (fix << 0 ) ; > +} > + > +uint32_t os::Linux::os_version() { > + assert(_os_version != 0, "not initialized"); > + return _os_version; > +} > + > + > ///// > // glibc on Linux platform uses non-documented flag > // to indicate, that some special sort of signal > @@ -4552,6 +4578,8 @@ > } > init_page_sizes((size_t) Linux::page_size()); > > + Linux::initialize_os_info(); > + > Linux::initialize_system_info(); > > // main_thread points to the aboriginal thread > diff --git a/src/os/linux/vm/os_linux.hpp b/src/os/linux/vm/os_linux.hpp > --- a/src/os/linux/vm/os_linux.hpp > +++ b/src/os/linux/vm/os_linux.hpp > @@ -56,6 +56,12 @@ > > static GrowableArray* _cpu_to_node; > > + // Ox00AABBCC > + // AA, Major Version > + // BB, Minor Version > + // CC, Fix Version > + static uint32_t _os_version; > + > protected: > > static julong _physical_memory; > @@ -198,6 +204,9 @@ > > static jlong fast_thread_cpu_time(clockid_t clockid); > > + static void initialize_os_info(); > + static uint32_t os_version(); > + > // pthread_cond clock suppport > private: > static pthread_condattr_t _condattr[1]; > > Should I use any test suite besides the jtreg suite already present > in the Hotspot forest? > > > Best Regards, > Gustavo > > On 12-02-2016 12:52, Doerr, Martin wrote: >> Hi Gustavo, >> >> the reason why we disabled RTM for linux on PPC64 (big or little endian) was the problematic behavior of syscalls. >> The old version of the document >> www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt >> said: >> ?Performing syscalls from within transaction is not recommended, and can lead to unpredictable results.? >> >> Transactions need to either pass completely or roll back completely without disturbing side effects of partially executed syscalls. >> We rely on the kernel to abort transactions if necessary. >> >> The document has changed and it may possibly work with a new linux kernel. >> However, we don't have such a new kernel, yet. So we can't test it at the moment. >> I don't know which kernel version exactly contains the change. I guess this exact version number (major + minor) should be used for enabling RTM. >> >> I haven't looked into the tests, yet. There may be a need for additional adaptations and fixes. >> >> We appreciate if you make experiments and/or contributions. >> >> Thanks and best regards, >> Martin >> >> >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero >> Sent: Freitag, 12. Februar 2016 14:45 >> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: RTM disabled for Linux on PPC64 LE >> Importance: High >> >> Hi, >> As of now (tip 1922:be58b02c11f9, jdk9/jdk9 repo) Hotspot build for Linux on ppc64le of fails due to a simple uninitialized variable error: >> >> hotspot/src/share/vm/ci/ciMethodData.hpp:585:100: error: ?data? may be used uninitialized in this function >> hotspot/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp:2408:78: error: ?md? may be used uninitialized in this function >> >> So this straightforward patch solves the issue: >> diff -r 534c50395957 src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp >> --- a/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Thu Jan 28 15:42:23 2016 -0800 >> +++ b/src/cpu/ppc/vm/c1_LIRAssembler_ppc.cpp Mon Feb 08 17:13:14 2016 -0200 >> @@ -2321,8 +2321,8 @@ >> if (reg_conflict) { obj = dst; } >> } >> - ciMethodData* md; >> - ciProfileData* data; >> + ciMethodData* md = NULL; >> + ciProfileData* data = NULL; >> int mdo_offset_bias = 0; compiler/rtm >> if (should_profile) { >> ciMethod* method = op->profiled_method(); >> >> However, after the build, I realized that RTM is still disabled for Linux on ppc64le, failing 25 tests on compiler/rtm suite: >> >> http://hastebin.com/raw/ohoxiwaqih >> >> Hence after applying the following patches that enable RTM for Linux on ppc64le: >> >> diff -r 266fa9bb5297 src/cpu/ppc/vm/vm_version_ppc.cpp >> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Thu Feb 04 16:48:39 2016 -0800 >> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Feb 12 10:55:46 2016 -0200 >> @@ -255,7 +255,9 @@ >> } >> #endif >> #ifdef linux >> - // TODO: check kernel version (we currently have too old versions only) >> + if (os::Linux::os_version() >= 4) { // at least Linux kernel version 4 >> + os_too_old = false; >> + } >> #endif >> if (os_too_old) { >> vm_exit_during_initialization("RTM is not supported on this OS version."); >> >> >> diff -r 266fa9bb5297 src/os/linux/vm/os_linux.cpp >> --- a/src/os/linux/vm/os_linux.cpp Thu Feb 04 16:48:39 2016 -0800 >> +++ b/src/os/linux/vm/os_linux.cpp Fri Feb 12 10:58:10 2016 -0200 >> @@ -135,6 +135,7 @@ >> int os::Linux::_page_size = -1; >> const int os::Linux::_vm_default_page_size = (8 * K); >> bool os::Linux::_supports_fast_thread_cpu_time = false; >> +uint32_t os::Linux::_os_version = 0; >> const char * os::Linux::_glibc_version = NULL; >> const char * os::Linux::_libpthread_version = NULL; >> pthread_condattr_t os::Linux::_condattr[1]; >> @@ -4332,6 +4333,21 @@ >> return (tp.tv_sec * NANOSECS_PER_SEC) + tp.tv_nsec; >> } >> +void os::Linux::initialize_os_info() { >> + assert(_os_version == 0, "OS info already initialized"); >> + >> + struct utsname _uname; >> + + uname(&_uname); // Not sure yet how deal if ret == -1 >> + _os_version = atoi(_uname.release); >> +} >> + >> +uint32_t os::Linux::os_version() { >> + assert(_os_version != 0, "not initialized"); >> + return _os_version; >> +} >> + >> + >> ///// >> // glibc on Linux platform uses non-documented flag >> // to indicate, that some special sort of signal >> @@ -4553,6 +4569,7 @@ >> init_page_sizes((size_t) Linux::page_size()); >> Linux::initialize_system_info(); >> + Linux::initialize_os_info(); >> // main_thread points to the aboriginal thread >> Linux::_main_thread = pthread_self(); >> >> >> diff -r 266fa9bb5297 src/os/linux/vm/os_linux.hpp >> --- a/src/os/linux/vm/os_linux.hpp Thu Feb 04 16:48:39 2016 -0800 >> +++ b/src/os/linux/vm/os_linux.hpp Fri Feb 12 10:59:01 2016 -0200 >> @@ -55,7 +55,7 @@ >> static bool _supports_fast_thread_cpu_time; >> static GrowableArray* _cpu_to_node; >> - >> + static uint32_t _os_version; protected: >> static julong _physical_memory; >> @@ -198,6 +198,9 @@ >> static jlong fast_thread_cpu_time(clockid_t clockid); >> + static void initialize_os_info(); >> + static uint32_t os_version(); + >> // pthread_cond clock suppport >> private: >> static pthread_condattr_t _condattr[1]; >> >> >> 23 tests are now passing: http://hastebin.com/raw/oyicagusod >> >> Is there a reason to let RTM disabled for Linux on ppc64le by now? Could somebody explain what is currently missing on PPC64 LE RTM implementation in order to make all RTM tests pass? >> >> Thank you. >> >> Regards, >> -- >> Gustavo Romero >> > From panqun at cn.ibm.com Wed Feb 24 01:51:08 2016 From: panqun at cn.ibm.com (Qun Pan) Date: Wed, 24 Feb 2016 09:51:08 +0800 Subject: Where to download a OpenJDK7 installation package for AIX5.3 ? Message-ID: <201602240151.u1O1pOb9028348@d23av01.au.ibm.com> Hi OpenJDK Team, I want to install OpenJDK7 on AIX5.3 server, would you please let me know where I can download a OpenJDK7 installation package for AIX5.3 ? Thanks a lot! Best Regards, Pan Qun(??) XIV Interop Test IBM China System & Technology Lab(CSTL) PMP Address: 2/F,Building 10, 399 Ke Yuan Road, Zhang Jiang High Tech Park Shanghai 201203, P.R.China Tel:021-60922543 ?????????????????399?10??2?2R-W053 ???201203 -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Feb 24 11:26:27 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Feb 2016 12:26:27 +0100 Subject: Where to download a OpenJDK7 installation package for AIX5.3 ? In-Reply-To: <201602240151.u1O1pOb9028348@d23av01.au.ibm.com> References: <201602240151.u1O1pOb9028348@d23av01.au.ibm.com> Message-ID: Hi Pan Qun, Generally, our project, as all the other OpenJDK project, doesn't provide binaries. You have to build it yourself. However, to ease the step of building (and because the IBM J9 JDK didn't qualify as a drop-in replacement of the bootstrap JDK) we provided two JDK binaries which could be used to bootstrap the build on AIX. Please notice that these binaries are old, not very well tested on not supported at all. Their only purpose is to enable other developers to bootstrap a recent version of OpenJDK on AIX. For more information please take a look at the following mail thread: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2015-December/002329.html I'd also suggest to move to jdk8 because it builds a lot easier and we don't support the jdk7 port any more. In general we would very much appreciate if IBM could play a more active role in the OpenJDK AIX porting project :) Regards, Volker On Wed, Feb 24, 2016 at 2:51 AM, Qun Pan wrote: > Hi OpenJDK Team, > > I want to install OpenJDK7 on AIX5.3 server, would you please let me know > where I can download a OpenJDK7 installation package for AIX5.3 ? Thanks a > lot! > > > > Best Regards, > Pan Qun(??) > > XIV Interop Test > IBM China System & Technology Lab(CSTL) > PMP > Address: 2/F,Building 10, 399 Ke Yuan Road, Zhang Jiang High Tech Park > Shanghai 201203, P.R.China > Tel:021-60922543 > ?????????????????399?10??2?2R-W053 > ???201203 >