From hamiltcl at verizon.net Sun Jan 10 14:04:51 2016 From: hamiltcl at verizon.net (Curtis Hamilton) Date: Sun, 10 Jan 2016 09:04:51 -0500 Subject: PPC-AIX Port to FreeBSD PowerPC Support Message-ID: <011601d14baf$e0305940$a0910bc0$@verizon.net> 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aix-port_aix_ppc.log URL: From volker.simonis at gmail.com Mon Jan 11 10:22:02 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 11 Jan 2016 11:22:02 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: <011601d14baf$e0305940$a0910bc0$@verizon.net> References: <011601d14baf$e0305940$a0910bc0$@verizon.net> Message-ID: 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 > > [image: https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Jan 11 13:39:53 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Jan 2016 14:39:53 +0100 Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack on AIX In-Reply-To: References: Message-ID: Hi all, could I please have a review? Thank you! ..Thomas On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe wrote: > Hi all, > > please review this AIX-only patch. > > This ports a more sophisticated native callstack printer for AIX to the > OpenJDK. It prints out more information and is more robust in cases the > stack is corrupted. > > bug: https://bugs.openjdk.java.net/browse/JDK-8145184 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.00/webrev/ > > Note that also some of functions were moved and made more coding-conform > to the OpenJDK: the old getFuncName() and getModuleName() functions are > moved to AixSymbols::get_function_name() and AixSymbols::get_module_name(). > > Thanks and Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamiltcl at verizon.net Mon Jan 11 14:21:05 2016 From: hamiltcl at verizon.net (Curtis Hamilton) Date: Mon, 11 Jan 2016 09:21:05 -0500 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: References: <011601d14baf$e0305940$a0910bc0$@verizon.net> Message-ID: <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> 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 thomas.stuefe at gmail.com Mon Jan 11 16:23:04 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Jan 2016 17:23:04 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> Message-ID: 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 dalibor.topic at oracle.com Mon Jan 11 16:27:32 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 11 Jan 2016 17:27:32 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> Message-ID: <5693D7F4.6080108@oracle.com> I'd suggest asking on bsd-port-dev, fwiw. cheers, dalibor topic On 11.01.2016 17:23, Thomas St?fe wrote: > 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____ > > ____ > > ____ > > __ __ > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From hamiltcl at verizon.net Mon Jan 11 20:28:50 2016 From: hamiltcl at verizon.net (Curtis Hamilton) Date: Mon, 11 Jan 2016 15:28:50 -0500 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> Message-ID: <004001d14cae$aecb3af0$0c61b0d0$@verizon.net> 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 david.holmes at oracle.com Tue Jan 12 00:52:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jan 2016 10:52:16 +1000 Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack on AIX In-Reply-To: References: Message-ID: <56944E40.1070606@oracle.com> Hi Thomas, On 11/01/2016 11:39 PM, Thomas St?fe wrote: > Hi all, > > could I please have a review? Are you waiting for another AIX person to review, or a runtime team member to rubber stamp? David > Thank you! > > ..Thomas > > On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe > wrote: > >> Hi all, >> >> please review this AIX-only patch. >> >> This ports a more sophisticated native callstack printer for AIX to the >> OpenJDK. It prints out more information and is more robust in cases the >> stack is corrupted. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8145184 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.00/webrev/ >> >> Note that also some of functions were moved and made more coding-conform >> to the OpenJDK: the old getFuncName() and getModuleName() functions are >> moved to AixSymbols::get_function_name() and AixSymbols::get_module_name(). >> >> Thanks and Kind Regards, Thomas >> From thomas.stuefe at gmail.com Tue Jan 12 06:48:27 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 Jan 2016 07:48:27 +0100 Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack on AIX In-Reply-To: <56944E40.1070606@oracle.com> References: <56944E40.1070606@oracle.com> Message-ID: Hi David, I would prefer a real review. I'll ask Goetz later, maybe he is in the mood. Thanks, Thomas On Jan 12, 2016 01:53, "David Holmes" wrote: > Hi Thomas, > > On 11/01/2016 11:39 PM, Thomas St?fe wrote: > >> Hi all, >> >> could I please have a review? >> > > Are you waiting for another AIX person to review, or a runtime team member > to rubber stamp? > > David > > Thank you! >> >> ..Thomas >> >> On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe >> wrote: >> >> Hi all, >>> >>> please review this AIX-only patch. >>> >>> This ports a more sophisticated native callstack printer for AIX to the >>> OpenJDK. It prints out more information and is more robust in cases the >>> stack is corrupted. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8145184 >>> webrev: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.00/webrev/ >>> >>> Note that also some of functions were moved and made more coding-conform >>> to the OpenJDK: the old getFuncName() and getModuleName() functions are >>> moved to AixSymbols::get_function_name() and >>> AixSymbols::get_module_name(). >>> >>> Thanks and Kind Regards, Thomas >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jan 12 07:30:22 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Jan 2016 08:30:22 +0100 Subject: PPC-AIX Port to FreeBSD PowerPC Support In-Reply-To: <004001d14cae$aecb3af0$0c61b0d0$@verizon.net> References: <011601d14baf$e0305940$a0910bc0$@verizon.net> <001201d14c7b$4f210ef0$ed632cd0$@verizon.net> <004001d14cae$aecb3af0$0c61b0d0$@verizon.net> Message-ID: HI Chris, if you start with jdk8u-dev (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/) it will contain both, the bsd and the ppc64 port. So all you have to do is to create a new hotspot/src/os_cpu/bsd_ppc64 directory and populating it with the appropriate files. As boilerplate you can combine the versions from linux_ppc and bsd_x86. For orderAccess you'd probaly stick to orderAccess_linux_ppc.inline.hpp because that one is more and CPU than OS specific and the linux version already contains GCC specific code which should easily work on bsd as well. For other files like os_... it may be easier to start with the os_bsd_x86 version and port the CPU specific parts by looking at the corresponding implementation in os_linux_ppc. Regards, Volker On Mon, Jan 11, 2016 at 9:28 PM, Curtis Hamilton wrote: > 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 goetz.lindenmaier at sap.com Wed Jan 13 11:48:07 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Jan 2016 11:48:07 +0000 Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack on AIX In-Reply-To: References: Message-ID: <4295855A5C1DE049A61835A1887419CC41F13CDE@DEWDFEMB12A.global.corp.sap> Hi Thomas, I had a look at your change. The construction with #ifndef PLATFORM_PRINT_NATIVE_STACK is quite unconventional ... but it was there before, so it's not an issue of your change. It's good to have this now, I've experienced missing stack traces before. Is it necessary to use macro ERRBYE? It doesn't really help reading the code, as the 'return' is hidden in it. I would remove it with this change. Don't you have to remove the '== 0' here? You changed the return value from '0' to true. - if (getFuncName((codeptr_t) p, funcname, sizeof(funcname), &displacement, - NULL, NULL, 0, false) == 0) { + if (AixSymbols::get_function_name(p, funcname, sizeof(funcname), + &displacement, NULL, true) == 0) { Get_module_name has wrong indentation of parameters. Probably they fit into one line. Besides that looks good. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Montag, 11. Januar 2016 14:40 > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: RFR(m): 8145184: [aix] Implement > os::platform_print_native_stack on AIX > > Hi all, > > could I please have a review? > > Thank you! > > ..Thomas > > On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe > > wrote: > > > Hi all, > > > > please review this AIX-only patch. > > > > This ports a more sophisticated native callstack printer for AIX to the > > OpenJDK. It prints out more information and is more robust in cases the > > stack is corrupted. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8145184 > > webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement- > os_platform_print_native_stack/webrev.00/webrev/ > > > > Note that also some of functions were moved and made more coding- > conform > > to the OpenJDK: the old getFuncName() and getModuleName() functions > are > > moved to AixSymbols::get_function_name() and > AixSymbols::get_module_name(). > > > > Thanks and Kind Regards, Thomas > > From thomas.stuefe at gmail.com Thu Jan 14 15:08:49 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Jan 2016 16:08:49 +0100 Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack on AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F13CDE@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41F13CDE@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, thanks a lot for reviewing! See here the new webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.01/webrev/ Comments inline. On Wed, Jan 13, 2016 at 12:48 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > I had a look at your change. > > The construction with #ifndef PLATFORM_PRINT_NATIVE_STACK is quite > unconventional ... but it was there before, so it's not an issue of your > change. > > Yes.. :-/ > It's good to have this now, I've experienced missing stack traces before. > > Is it necessary to use macro ERRBYE? It doesn't really help reading the > code, as the 'return' is hidden in it. I would remove it with this change. > > You are right, I removed than macro. > Don't you have to remove the '== 0' here? You changed the return value > from '0' to true. > - if (getFuncName((codeptr_t) p, funcname, sizeof(funcname), > &displacement, > - NULL, NULL, 0, false) == 0) { > + if (AixSymbols::get_function_name(p, funcname, sizeof(funcname), > + &displacement, NULL, true) == 0) { > > Good catch! Found two places where I did not revert the logic, fixe and tested. > Get_module_name has wrong indentation of parameters. Probably they fit > into > one line. > Besides that looks good. Thanks! Kind Regards, Thomas > > Best regards, > Goetz. > > > > > > -----Original Message----- > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > > Sent: Montag, 11. Januar 2016 14:40 > > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Subject: Re: RFR(m): 8145184: [aix] Implement > > os::platform_print_native_stack on AIX > > > > Hi all, > > > > could I please have a review? > > > > Thank you! > > > > ..Thomas > > > > On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe > > > > wrote: > > > > > Hi all, > > > > > > please review this AIX-only patch. > > > > > > This ports a more sophisticated native callstack printer for AIX to the > > > OpenJDK. It prints out more information and is more robust in cases the > > > stack is corrupted. > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8145184 > > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement- > > os_platform_print_native_stack/webrev.00/webrev/ > > > > > > Note that also some of functions were moved and made more coding- > > conform > > > to the OpenJDK: the old getFuncName() and getModuleName() functions > > are > > > moved to AixSymbols::get_function_name() and > > AixSymbols::get_module_name(). > > > > > > Thanks and Kind Regards, Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Fri Jan 15 17:04:57 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 15 Jan 2016 18:04:57 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets Message-ID: <569926B9.4070806@oracle.com> Hi all, As per the previous discussion in mid-December[0] about moving the _vtable_length field to class Klass, here's the first RFR and webrev, according to my suggested plan[1]: > My current plan is to first modify the vtable_length_offset accessor to > return a byte offset (which is what it's translated to by all callers). > > Then I'll tackle moving the _vtable_len field to Klass. > > Finally I'll try to consolidate the vtable related methods to Klass, > where they belong. This change actually consists of three changes: * modifying InstanceKlass::vtable_length_offset to become a byte offset and use the ByteSize type to communicate the scaling. * modifying InstanceKlass::vtable_start_offset to become a byte offset and use the ByteSize type, for symmetry reasons mainly. * adding a vtableEntry::size_in_bytes() since in many places the vtable entry size is used in combination with the vtable start to compute a byte offset for vtable lookups. I don't foresee any issues with the fact that the byte offset is represented as an int, for two reasons: 1) If the offset of any of these grows to over 2 gigabytes then we have a huge footprint problem with InstanceKlass 2) The offsets are converted to byte offsets and stored in ints already in the cpu specific code I've modified. Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ Testing: JPRT on Oracle supported platforms, testing on AARCH64 and PPC64 would be much appreciated, appropriate mailing lists have been CC:ed to notify them of the request. [0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html Thanks! /Mikael From thomas.stuefe at gmail.com Sat Jan 16 08:42:42 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 16 Jan 2016 09:42:42 +0100 Subject: RFR(xxs): 8147508: [aix] Newlines missing in register info printout Message-ID: Please review this trivial change. Bug report: https://bugs.openjdk.java.net/browse/JDK-8147509 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8147509-aix-newline-missing-print-register-info/webrev.00/webrev/ (in the webrev, please disregard the mention of JDK-8145184 in the change summary. I do not know why webrev does this.). Thanks! Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Jan 18 10:53:54 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jan 2016 11:53:54 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569926B9.4070806@oracle.com> References: <569926B9.4070806@oracle.com> Message-ID: Hi Mikael, your change builds and runs fine on ppc64. Thanks for considering ppc64 in your patch, Volker On Fri, Jan 15, 2016 at 6:04 PM, Mikael Gerdin wrote: > Hi all, > > As per the previous discussion in mid-December[0] about moving the > _vtable_length field to class Klass, here's the first RFR and webrev, > according to my suggested plan[1]: > >> My current plan is to first modify the vtable_length_offset accessor to >> return a byte offset (which is what it's translated to by all callers). >> >> Then I'll tackle moving the _vtable_len field to Klass. >> >> Finally I'll try to consolidate the vtable related methods to Klass, >> where they belong. > > > This change actually consists of three changes: > * modifying InstanceKlass::vtable_length_offset to become a byte offset and > use the ByteSize type to communicate the scaling. > * modifying InstanceKlass::vtable_start_offset to become a byte offset and > use the ByteSize type, for symmetry reasons mainly. > * adding a vtableEntry::size_in_bytes() since in many places the vtable > entry size is used in combination with the vtable start to compute a byte > offset for vtable lookups. > > I don't foresee any issues with the fact that the byte offset is represented > as an int, for two reasons: > 1) If the offset of any of these grows to over 2 gigabytes then we have a > huge footprint problem with InstanceKlass > 2) The offsets are converted to byte offsets and stored in ints already in > the cpu specific code I've modified. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 > Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ > > Testing: JPRT on Oracle supported platforms, testing on AARCH64 and PPC64 > would be much appreciated, appropriate mailing lists have been CC:ed to > notify them of the request. > > > [0] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html > > Thanks! > /Mikael From mikael.gerdin at oracle.com Tue Jan 19 07:41:46 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Jan 2016 08:41:46 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: References: <569926B9.4070806@oracle.com> Message-ID: <569DE8BA.4000809@oracle.com> Hi Volker, On 2016-01-18 11:53, Volker Simonis wrote: > Hi Mikael, > > your change builds and runs fine on ppc64. Thanks for testing the changes. /Mikael > > > Thanks for considering ppc64 in your patch, > Volker > > > On Fri, Jan 15, 2016 at 6:04 PM, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset and >> use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset and >> use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a byte >> offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is represented >> as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have a >> huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already in >> the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and PPC64 >> would be much appreciated, appropriate mailing lists have been CC:ed to >> notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> Thanks! >> /Mikael From mikael.gerdin at oracle.com Tue Jan 19 10:27:58 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Jan 2016 11:27:58 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <1453198025.25458.8.camel@mylittlepony.linaroharston> References: <569926B9.4070806@oracle.com> <1453198025.25458.8.camel@mylittlepony.linaroharston> Message-ID: <569E0FAE.8020305@oracle.com> Hi Edward, On 2016-01-19 11:07, Edward Nevill wrote: > Hi Mikael, > > I tried a release and fastdebug build on aarch64. The release build builds fine and passes a basic smoke test but the fastdebug build fails with the following errors. > > /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp: In static member function 'static void CompilerToVM::Data::initialize()': > /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:153:37: error: cannot convert 'ByteSize' to 'int' in assignment > InstanceKlass_vtable_start_offset = InstanceKlass::vtable_start_offset(); > ^ > /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:154:38: error: cannot convert 'ByteSize' to 'int' in assignment > InstanceKlass_vtable_length_offset = InstanceKlass::vtable_length_offset() * HeapWordSize; > ^ > After fixing these the fastdebug build completed and passed the same basic tests. Thanks for testing! As to the compilation failures this is probably due to me creating the patch before hs-comp was merged into hs-rt. I'll rebase it and fix the jvmci issue. /Mikael > > All the best, > Ed. > > On Fri, 2016-01-15 at 18:04 +0100, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset >> and use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset >> and use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a >> byte offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is >> represented as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have >> a huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already >> in the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >> PPC64 would be much appreciated, appropriate mailing lists have been >> CC:ed to notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> Thanks! >> /Mikael > > From volker.simonis at gmail.com Tue Jan 19 18:57:06 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Jan 2016 19:57:06 +0100 Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change Message-ID: Hi, can somebody please review and sponsor this change. Despite the bug summary, I still had to do some small shared changes to make this work, so unfortunately I can not push this on my own. The change also affects aarch64 (although it is minimal and I don't expect it to break anything) so I cc-ed aarch64-port-dev. http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ https://bugs.openjdk.java.net/browse/JDK-8145336 As described in the bug, this change only fixes the string intrinsics for the -XX:-UseCompactStrings mode which is still the default on ppc64. Additionally, support for the new StrIndexOfChar intrinsic was added because we already had a similar intrinsic for constant string needles of length one anyway. A later change (which we're already working on) will add the intrinsics which can handle compact strings. The current intrinsics can handle both, the new byte-array based string representation as well as the old char-array based string representation because we internally still use the new hotspot with older versions of the class libraries. I've also ported some of our internal string tests into a new regression test (TestStringIntrinsics2.java) because the existing tests didn't exercise all of our intrinsics. Following the shared changes I had to do: Until now, UseSSE42Intrinsics was a global shared option which was used to control the availability of the stringIndexOf intrinsics. But UseSSE42Intrinsics is actually a x86-specific feature so it doesn't make a lot of sense to define it for other architectures. I've therefore moved the flag to globals_x86.hpp and changed the condition which checks for the ability of the stringIndexOf intrinsics from: if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) { to: if (!Matcher::match_rule_supported(Op_StrIndexOf)) { The Matcher::match_rule_supported() method already calls Matcher::has_match_rule() anyway. And it is implemented in the .ad file so I've moved the check for UseSSE42Intrinsics into x86.ad. Other platforms can now decide in their .ad file if they unconditionally support the intrinsic or if they need a special feature check. This change was already briefly discussed in [1]. The other shared change I had to make was in LibraryCallKit::make_string_method_node() for the "Op_StrEquals" case. We have optimized intrinsics for the case that one of the strings to compare is constant, but the StrEqualsNode is constructed without taking into account that one of the string length values could be a constant. This prevented our optimized instruction from being matched in the ad-file. All the other changes are ppc-specific. Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/thread.html#20400 From thomas.stuefe at gmail.com Wed Jan 20 07:53:03 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 20 Jan 2016 08:53:03 +0100 Subject: RFR(xxs): 8147508: [aix] Newlines missing in register info printout In-Reply-To: References: Message-ID: May I please have a review? This is a very easy change. On Sat, Jan 16, 2016 at 9:42 AM, Thomas St?fe wrote: > Please review this trivial change. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8147509 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8147509-aix-newline-missing-print-register-info/webrev.00/webrev/ > > (in the webrev, please disregard the mention of JDK-8145184 in the change > summary. I do not know why webrev does this.). > > Thanks! Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Jan 20 08:12:59 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jan 2016 09:12:59 +0100 Subject: RFR(xxs): 8147508: [aix] Newlines missing in register info printout In-Reply-To: References: Message-ID: Looks good! Volker On Wed, Jan 20, 2016 at 8:53 AM, Thomas St?fe wrote: > May I please have a review? This is a very easy change. > > On Sat, Jan 16, 2016 at 9:42 AM, Thomas St?fe > wrote: >> >> Please review this trivial change. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8147509 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8147509-aix-newline-missing-print-register-info/webrev.00/webrev/ >> >> (in the webrev, please disregard the mention of JDK-8145184 in the change >> summary. I do not know why webrev does this.). >> >> Thanks! Thomas > > From thomas.stuefe at gmail.com Wed Jan 20 08:22:02 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 20 Jan 2016 09:22:02 +0100 Subject: RFR(xxs): 8147508: [aix] Newlines missing in register info printout In-Reply-To: References: Message-ID: Thanks, Volker! On Wed, Jan 20, 2016 at 9:12 AM, Volker Simonis wrote: > Looks good! > > Volker > > > On Wed, Jan 20, 2016 at 8:53 AM, Thomas St?fe > wrote: > > May I please have a review? This is a very easy change. > > > > On Sat, Jan 16, 2016 at 9:42 AM, Thomas St?fe > > wrote: > >> > >> Please review this trivial change. > >> > >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8147509 > >> webrev: > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8147509-aix-newline-missing-print-register-info/webrev.00/webrev/ > >> > >> (in the webrev, please disregard the mention of JDK-8145184 in the > change > >> summary. I do not know why webrev does this.). > >> > >> Thanks! Thomas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Jan 20 10:20:27 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jan 2016 11:20:27 +0100 Subject: [aarch64-port-dev ] RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change In-Reply-To: <569F579F.4060906@redhat.com> References: <569F579F.4060906@redhat.com> Message-ID: Hi Andrew, thanks for looking at it. Regards, Volker On Wed, Jan 20, 2016 at 10:47 AM, Andrew Haley wrote: > On 19/01/16 18:57, Volker Simonis wrote: >> The change also affects aarch64 (although it is minimal and I don't >> expect it to break anything) so I cc-ed aarch64-port-dev. >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ >> https://bugs.openjdk.java.net/browse/JDK-8145336 > > That's find by us. We only defined UseSSE42Intrinsics in order to get > the String.indexOf intrinsic. Of course, we should really have done it > some other way but we were working on our own outside the main HotSpot > tree. > > Andrew. > From martin.doerr at sap.com Wed Jan 20 11:43:40 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 20 Jan 2016 11:43:40 +0000 Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change In-Reply-To: References: Message-ID: <7C9B87B351A4BA4AA9EC95BB418116567228C120@DEWDFEMB19C.global.corp.sap> Hi Volker, thank you very much for adapting the non-CompactStrings version of the intrinsics. I especially like that you changed shared code to improve matching of special cases. Here are some minor change requests: - I guess you will have to adapt Copyright messages. - There's a typo in the new comment in library_call: "optimzed". - The comment for the instruction count (used for loop alignment) is wrong in MacroAssembler::string_indexof_1 (should start with 3 instead of 2). I have more change requests regarding ppc.ad: The computation of chr is incorrect for little endian in string_indexOf_imm1_char and string_indexOf_imm1. Some numbers for compute_padding should be adapted: int string_indexOf_imm1_charNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } int string_indexOfCharNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } int string_compareNode::compute_padding(int current_offset) const { return (2*4-current_offset)&31; } Some kill effects are missing: - ctr in all string_indexOf nodes - cr0, cr1 in string_indexOf_imm1, string_indexOfChar The new comment for string_indexOfChar claims "// Kill ... needle" which is not true. Thanks, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Dienstag, 19. Januar 2016 19:57 To: hotspot compiler Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change Hi, can somebody please review and sponsor this change. Despite the bug summary, I still had to do some small shared changes to make this work, so unfortunately I can not push this on my own. The change also affects aarch64 (although it is minimal and I don't expect it to break anything) so I cc-ed aarch64-port-dev. http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ https://bugs.openjdk.java.net/browse/JDK-8145336 As described in the bug, this change only fixes the string intrinsics for the -XX:-UseCompactStrings mode which is still the default on ppc64. Additionally, support for the new StrIndexOfChar intrinsic was added because we already had a similar intrinsic for constant string needles of length one anyway. A later change (which we're already working on) will add the intrinsics which can handle compact strings. The current intrinsics can handle both, the new byte-array based string representation as well as the old char-array based string representation because we internally still use the new hotspot with older versions of the class libraries. I've also ported some of our internal string tests into a new regression test (TestStringIntrinsics2.java) because the existing tests didn't exercise all of our intrinsics. Following the shared changes I had to do: Until now, UseSSE42Intrinsics was a global shared option which was used to control the availability of the stringIndexOf intrinsics. But UseSSE42Intrinsics is actually a x86-specific feature so it doesn't make a lot of sense to define it for other architectures. I've therefore moved the flag to globals_x86.hpp and changed the condition which checks for the ability of the stringIndexOf intrinsics from: if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) { to: if (!Matcher::match_rule_supported(Op_StrIndexOf)) { The Matcher::match_rule_supported() method already calls Matcher::has_match_rule() anyway. And it is implemented in the .ad file so I've moved the check for UseSSE42Intrinsics into x86.ad. Other platforms can now decide in their .ad file if they unconditionally support the intrinsic or if they need a special feature check. This change was already briefly discussed in [1]. The other shared change I had to make was in LibraryCallKit::make_string_method_node() for the "Op_StrEquals" case. We have optimized intrinsics for the case that one of the strings to compare is constant, but the StrEqualsNode is constructed without taking into account that one of the string length values could be a constant. This prevented our optimized instruction from being matched in the ad-file. All the other changes are ppc-specific. Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/thread.html#20400 From mikael.gerdin at oracle.com Wed Jan 20 12:31:30 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jan 2016 13:31:30 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569926B9.4070806@oracle.com> References: <569926B9.4070806@oracle.com> Message-ID: <569F7E22.3090905@oracle.com> Hi again, I've rebased the on hs-rt and had to include some additional changes for JVMCI. I've also updated the copyright years. Unfortunately I can't generate an incremental webrev since i rebased the patch and there's no good way that I know of to make that work with webrev. New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ Testing: JPRT again (which includes the JVMCI jtreg tests) /Mikael On 2016-01-15 18:04, Mikael Gerdin wrote: > Hi all, > > As per the previous discussion in mid-December[0] about moving the > _vtable_length field to class Klass, here's the first RFR and webrev, > according to my suggested plan[1]: > >> My current plan is to first modify the vtable_length_offset accessor to >> return a byte offset (which is what it's translated to by all callers). >> >> Then I'll tackle moving the _vtable_len field to Klass. >> >> Finally I'll try to consolidate the vtable related methods to Klass, >> where they belong. > > This change actually consists of three changes: > * modifying InstanceKlass::vtable_length_offset to become a byte offset > and use the ByteSize type to communicate the scaling. > * modifying InstanceKlass::vtable_start_offset to become a byte offset > and use the ByteSize type, for symmetry reasons mainly. > * adding a vtableEntry::size_in_bytes() since in many places the vtable > entry size is used in combination with the vtable start to compute a > byte offset for vtable lookups. > > I don't foresee any issues with the fact that the byte offset is > represented as an int, for two reasons: > 1) If the offset of any of these grows to over 2 gigabytes then we have > a huge footprint problem with InstanceKlass > 2) The offsets are converted to byte offsets and stored in ints already > in the cpu specific code I've modified. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 > Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ > > Testing: JPRT on Oracle supported platforms, testing on AARCH64 and > PPC64 would be much appreciated, appropriate mailing lists have been > CC:ed to notify them of the request. > > > [0] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html > > > Thanks! > /Mikael From volker.simonis at gmail.com Wed Jan 20 16:23:27 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jan 2016 17:23:27 +0100 Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116567228C120@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB418116567228C120@DEWDFEMB19C.global.corp.sap> Message-ID: Hi Martin, thanks for your thorough review. I've uploaded a new webrev to: http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336.v1/ Please find my comments inline. Regards, Volker On Wed, Jan 20, 2016 at 12:43 PM, Doerr, Martin wrote: > Hi Volker, > > thank you very much for adapting the non-CompactStrings version of the intrinsics. I especially like that you changed shared code to improve matching of special cases. > > Here are some minor change requests: > - I guess you will have to adapt Copyright messages. Done. > - There's a typo in the new comment in library_call: "optimzed". Fixed. > - The comment for the instruction count (used for loop alignment) is wrong in MacroAssembler::string_indexof_1 (should start with 3 instead of 2). > Right, fixed. > I have more change requests regarding ppc.ad: > > The computation of chr is incorrect for little endian in string_indexOf_imm1_char and string_indexOf_imm1. > Good catch. Fixed. > Some numbers for compute_padding should be adapted: > int string_indexOf_imm1_charNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } > int string_indexOfCharNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } > int string_compareNode::compute_padding(int current_offset) const { return (2*4-current_offset)&31; } > Right, and also: int string_indexOf_imm1Node::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } I have now put a comment in each method which points to the macro assembler method it depends on to make this dependency explicit. > Some kill effects are missing: > - ctr in all string_indexOf nodes Added kill effect for ctr register to all str_indexof intrinsics. > - cr0, cr1 in string_indexOf_imm1, string_indexOfChar > Fixed. > The new comment for string_indexOfChar claims "// Kill ... needle" which is not true. > Right, fixed. > Thanks, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Dienstag, 19. Januar 2016 19:57 > To: hotspot compiler > Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change > > Hi, > > can somebody please review and sponsor this change. > > Despite the bug summary, I still had to do some small shared changes > to make this work, so unfortunately I can not push this on my own. > > The change also affects aarch64 (although it is minimal and I don't > expect it to break anything) so I cc-ed aarch64-port-dev. > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ > https://bugs.openjdk.java.net/browse/JDK-8145336 > > As described in the bug, this change only fixes the string intrinsics > for the -XX:-UseCompactStrings mode which is still the default on > ppc64. Additionally, support for the new StrIndexOfChar intrinsic was > added because we already had a similar intrinsic for constant string > needles of length one anyway. A later change (which we're already > working on) will add the intrinsics which can handle compact strings. > > The current intrinsics can handle both, the new byte-array based > string representation as well as the old char-array based string > representation because we internally still use the new hotspot with > older versions of the class libraries. > > I've also ported some of our internal string tests into a new > regression test (TestStringIntrinsics2.java) because the existing > tests didn't exercise all of our intrinsics. > > Following the shared changes I had to do: > > Until now, UseSSE42Intrinsics was a global shared option which was > used to control the availability of the stringIndexOf intrinsics. But > UseSSE42Intrinsics is actually a x86-specific feature so it doesn't > make a lot of sense to define it for other architectures. I've > therefore moved the flag to globals_x86.hpp and changed the condition > which checks for the ability of the stringIndexOf intrinsics from: > > if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) { > > to: > > if (!Matcher::match_rule_supported(Op_StrIndexOf)) { > > The Matcher::match_rule_supported() method already calls > Matcher::has_match_rule() anyway. And it is implemented in the .ad > file so I've moved the check for UseSSE42Intrinsics into x86.ad. Other > platforms can now decide in their .ad file if they unconditionally > support the intrinsic or if they need a special feature check. This > change was already briefly discussed in [1]. > > The other shared change I had to make was in > LibraryCallKit::make_string_method_node() for the "Op_StrEquals" case. > We have optimized intrinsics for the case that one of the strings to > compare is constant, but the StrEqualsNode is constructed without > taking into account that one of the string length values could be a > constant. This prevented our optimized instruction from being matched > in the ad-file. > > All the other changes are ppc-specific. > > Thank you and best regards, > Volker > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/thread.html#20400 From martin.doerr at sap.com Wed Jan 20 16:45:44 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 20 Jan 2016 16:45:44 +0000 Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB418116567228C120@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116567228C273@DEWDFEMB19C.global.corp.sap> Hi Volker, thanks for the update. Looks good. Best regards, Martin -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 20. Januar 2016 17:23 To: Doerr, Martin Cc: hotspot compiler ; ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change Hi Martin, thanks for your thorough review. I've uploaded a new webrev to: http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336.v1/ Please find my comments inline. Regards, Volker On Wed, Jan 20, 2016 at 12:43 PM, Doerr, Martin wrote: > Hi Volker, > > thank you very much for adapting the non-CompactStrings version of the intrinsics. I especially like that you changed shared code to improve matching of special cases. > > Here are some minor change requests: > - I guess you will have to adapt Copyright messages. Done. > - There's a typo in the new comment in library_call: "optimzed". Fixed. > - The comment for the instruction count (used for loop alignment) is wrong in MacroAssembler::string_indexof_1 (should start with 3 instead of 2). > Right, fixed. > I have more change requests regarding ppc.ad: > > The computation of chr is incorrect for little endian in string_indexOf_imm1_char and string_indexOf_imm1. > Good catch. Fixed. > Some numbers for compute_padding should be adapted: > int string_indexOf_imm1_charNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } > int string_indexOfCharNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } > int string_compareNode::compute_padding(int current_offset) const { return (2*4-current_offset)&31; } > Right, and also: int string_indexOf_imm1Node::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } I have now put a comment in each method which points to the macro assembler method it depends on to make this dependency explicit. > Some kill effects are missing: > - ctr in all string_indexOf nodes Added kill effect for ctr register to all str_indexof intrinsics. > - cr0, cr1 in string_indexOf_imm1, string_indexOfChar > Fixed. > The new comment for string_indexOfChar claims "// Kill ... needle" which is not true. > Right, fixed. > Thanks, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Dienstag, 19. Januar 2016 19:57 > To: hotspot compiler > Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change > > Hi, > > can somebody please review and sponsor this change. > > Despite the bug summary, I still had to do some small shared changes > to make this work, so unfortunately I can not push this on my own. > > The change also affects aarch64 (although it is minimal and I don't > expect it to break anything) so I cc-ed aarch64-port-dev. > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ > https://bugs.openjdk.java.net/browse/JDK-8145336 > > As described in the bug, this change only fixes the string intrinsics > for the -XX:-UseCompactStrings mode which is still the default on > ppc64. Additionally, support for the new StrIndexOfChar intrinsic was > added because we already had a similar intrinsic for constant string > needles of length one anyway. A later change (which we're already > working on) will add the intrinsics which can handle compact strings. > > The current intrinsics can handle both, the new byte-array based > string representation as well as the old char-array based string > representation because we internally still use the new hotspot with > older versions of the class libraries. > > I've also ported some of our internal string tests into a new > regression test (TestStringIntrinsics2.java) because the existing > tests didn't exercise all of our intrinsics. > > Following the shared changes I had to do: > > Until now, UseSSE42Intrinsics was a global shared option which was > used to control the availability of the stringIndexOf intrinsics. But > UseSSE42Intrinsics is actually a x86-specific feature so it doesn't > make a lot of sense to define it for other architectures. I've > therefore moved the flag to globals_x86.hpp and changed the condition > which checks for the ability of the stringIndexOf intrinsics from: > > if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) { > > to: > > if (!Matcher::match_rule_supported(Op_StrIndexOf)) { > > The Matcher::match_rule_supported() method already calls > Matcher::has_match_rule() anyway. And it is implemented in the .ad > file so I've moved the check for UseSSE42Intrinsics into x86.ad. Other > platforms can now decide in their .ad file if they unconditionally > support the intrinsic or if they need a special feature check. This > change was already briefly discussed in [1]. > > The other shared change I had to make was in > LibraryCallKit::make_string_method_node() for the "Op_StrEquals" case. > We have optimized intrinsics for the case that one of the strings to > compare is constant, but the StrEqualsNode is constructed without > taking into account that one of the string length values could be a > constant. This prevented our optimized instruction from being matched > in the ad-file. > > All the other changes are ppc-specific. > > Thank you and best regards, > Volker > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/thread.html#20400 From vladimir.kozlov at oracle.com Wed Jan 20 17:08:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Jan 2016 09:08:18 -0800 Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116567228C273@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB418116567228C120@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB418116567228C273@DEWDFEMB19C.global.corp.sap> Message-ID: <569FBF02.6080707@oracle.com> +1. Finally UseSSE42Intrinsics was moved! I will sponsor it. Thanks, Vladimir On 1/20/16 8:45 AM, Doerr, Martin wrote: > Hi Volker, > > thanks for the update. Looks good. > > Best regards, > Martin > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Mittwoch, 20. Januar 2016 17:23 > To: Doerr, Martin > Cc: hotspot compiler ; ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change > > Hi Martin, > > thanks for your thorough review. I've uploaded a new webrev to: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336.v1/ > > Please find my comments inline. > > Regards, > Volker > > > On Wed, Jan 20, 2016 at 12:43 PM, Doerr, Martin wrote: >> Hi Volker, >> >> thank you very much for adapting the non-CompactStrings version of the intrinsics. I especially like that you changed shared code to improve matching of special cases. >> >> Here are some minor change requests: >> - I guess you will have to adapt Copyright messages. > > Done. > >> - There's a typo in the new comment in library_call: "optimzed". > > Fixed. > >> - The comment for the instruction count (used for loop alignment) is wrong in MacroAssembler::string_indexof_1 (should start with 3 instead of 2). >> > > Right, fixed. > >> I have more change requests regarding ppc.ad: >> >> The computation of chr is incorrect for little endian in string_indexOf_imm1_char and string_indexOf_imm1. >> > > Good catch. Fixed. > >> Some numbers for compute_padding should be adapted: >> int string_indexOf_imm1_charNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } >> int string_indexOfCharNode::compute_padding(int current_offset) const { return (3*4-current_offset)&31; } >> int string_compareNode::compute_padding(int current_offset) const { return (2*4-current_offset)&31; } >> > > Right, and also: > int string_indexOf_imm1Node::compute_padding(int current_offset) const > { return (3*4-current_offset)&31; } > > I have now put a comment in each method which points to the macro > assembler method it depends on to make this dependency explicit. > >> Some kill effects are missing: >> - ctr in all string_indexOf nodes > > Added kill effect for ctr register to all str_indexof intrinsics. > >> - cr0, cr1 in string_indexOf_imm1, string_indexOfChar >> > > Fixed. > >> The new comment for string_indexOfChar claims "// Kill ... needle" which is not true. >> > > Right, fixed. > >> Thanks, >> Martin >> >> >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis >> Sent: Dienstag, 19. Januar 2016 19:57 >> To: hotspot compiler >> Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >> Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change >> >> Hi, >> >> can somebody please review and sponsor this change. >> >> Despite the bug summary, I still had to do some small shared changes >> to make this work, so unfortunately I can not push this on my own. >> >> The change also affects aarch64 (although it is minimal and I don't >> expect it to break anything) so I cc-ed aarch64-port-dev. >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ >> https://bugs.openjdk.java.net/browse/JDK-8145336 >> >> As described in the bug, this change only fixes the string intrinsics >> for the -XX:-UseCompactStrings mode which is still the default on >> ppc64. Additionally, support for the new StrIndexOfChar intrinsic was >> added because we already had a similar intrinsic for constant string >> needles of length one anyway. A later change (which we're already >> working on) will add the intrinsics which can handle compact strings. >> >> The current intrinsics can handle both, the new byte-array based >> string representation as well as the old char-array based string >> representation because we internally still use the new hotspot with >> older versions of the class libraries. >> >> I've also ported some of our internal string tests into a new >> regression test (TestStringIntrinsics2.java) because the existing >> tests didn't exercise all of our intrinsics. >> >> Following the shared changes I had to do: >> >> Until now, UseSSE42Intrinsics was a global shared option which was >> used to control the availability of the stringIndexOf intrinsics. But >> UseSSE42Intrinsics is actually a x86-specific feature so it doesn't >> make a lot of sense to define it for other architectures. I've >> therefore moved the flag to globals_x86.hpp and changed the condition >> which checks for the ability of the stringIndexOf intrinsics from: >> >> if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) { >> >> to: >> >> if (!Matcher::match_rule_supported(Op_StrIndexOf)) { >> >> The Matcher::match_rule_supported() method already calls >> Matcher::has_match_rule() anyway. And it is implemented in the .ad >> file so I've moved the check for UseSSE42Intrinsics into x86.ad. Other >> platforms can now decide in their .ad file if they unconditionally >> support the intrinsic or if they need a special feature check. This >> change was already briefly discussed in [1]. >> >> The other shared change I had to make was in >> LibraryCallKit::make_string_method_node() for the "Op_StrEquals" case. >> We have optimized intrinsics for the case that one of the strings to >> compare is constant, but the StrEqualsNode is constructed without >> taking into account that one of the string length values could be a >> constant. This prevented our optimized instruction from being matched >> in the ad-file. >> >> All the other changes are ppc-specific. >> >> Thank you and best regards, >> Volker >> >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/thread.html#20400 From volker.simonis at gmail.com Wed Jan 20 17:11:35 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jan 2016 18:11:35 +0100 Subject: RFR(M): 8145336: PPC64: fix string intrinsics after CompactStrings change In-Reply-To: <569FBF02.6080707@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB418116567228C120@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB418116567228C273@DEWDFEMB19C.global.corp.sap> <569FBF02.6080707@oracle.com> Message-ID: Great! Thanks a lot Vladimir, Volker On Wed, Jan 20, 2016 at 6:08 PM, Vladimir Kozlov wrote: > +1. Finally UseSSE42Intrinsics was moved! > I will sponsor it. > > Thanks, > Vladimir > > > > On 1/20/16 8:45 AM, Doerr, Martin wrote: >> >> Hi Volker, >> >> thanks for the update. Looks good. >> >> Best regards, >> Martin >> >> -----Original Message----- >> From: Volker Simonis [mailto:volker.simonis at gmail.com] >> Sent: Mittwoch, 20. Januar 2016 17:23 >> To: Doerr, Martin >> Cc: hotspot compiler ; >> ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >> Subject: Re: RFR(M): 8145336: PPC64: fix string intrinsics after >> CompactStrings change >> >> Hi Martin, >> >> thanks for your thorough review. I've uploaded a new webrev to: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336.v1/ >> >> Please find my comments inline. >> >> Regards, >> Volker >> >> >> On Wed, Jan 20, 2016 at 12:43 PM, Doerr, Martin >> wrote: >>> >>> Hi Volker, >>> >>> thank you very much for adapting the non-CompactStrings version of the >>> intrinsics. I especially like that you changed shared code to improve >>> matching of special cases. >>> >>> Here are some minor change requests: >>> - I guess you will have to adapt Copyright messages. >> >> >> Done. >> >>> - There's a typo in the new comment in library_call: "optimzed". >> >> >> Fixed. >> >>> - The comment for the instruction count (used for loop alignment) is >>> wrong in MacroAssembler::string_indexof_1 (should start with 3 instead of >>> 2). >>> >> >> Right, fixed. >> >>> I have more change requests regarding ppc.ad: >>> >>> The computation of chr is incorrect for little endian in >>> string_indexOf_imm1_char and string_indexOf_imm1. >>> >> >> Good catch. Fixed. >> >>> Some numbers for compute_padding should be adapted: >>> int string_indexOf_imm1_charNode::compute_padding(int current_offset) >>> const { return (3*4-current_offset)&31; } >>> int string_indexOfCharNode::compute_padding(int current_offset) const { >>> return (3*4-current_offset)&31; } >>> int string_compareNode::compute_padding(int current_offset) const { >>> return (2*4-current_offset)&31; } >>> >> >> Right, and also: >> int string_indexOf_imm1Node::compute_padding(int current_offset) const >> { return (3*4-current_offset)&31; } >> >> I have now put a comment in each method which points to the macro >> assembler method it depends on to make this dependency explicit. >> >>> Some kill effects are missing: >>> - ctr in all string_indexOf nodes >> >> >> Added kill effect for ctr register to all str_indexof intrinsics. >> >>> - cr0, cr1 in string_indexOf_imm1, string_indexOfChar >>> >> >> Fixed. >> >>> The new comment for string_indexOfChar claims "// Kill ... needle" which >>> is not true. >>> >> >> Right, fixed. >> >>> Thanks, >>> Martin >>> >>> >>> -----Original Message----- >>> From: hotspot-compiler-dev >>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Volker >>> Simonis >>> Sent: Dienstag, 19. Januar 2016 19:57 >>> To: hotspot compiler >>> Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >>> Subject: RFR(M): 8145336: PPC64: fix string intrinsics after >>> CompactStrings change >>> >>> Hi, >>> >>> can somebody please review and sponsor this change. >>> >>> Despite the bug summary, I still had to do some small shared changes >>> to make this work, so unfortunately I can not push this on my own. >>> >>> The change also affects aarch64 (although it is minimal and I don't >>> expect it to break anything) so I cc-ed aarch64-port-dev. >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8145336/ >>> https://bugs.openjdk.java.net/browse/JDK-8145336 >>> >>> As described in the bug, this change only fixes the string intrinsics >>> for the -XX:-UseCompactStrings mode which is still the default on >>> ppc64. Additionally, support for the new StrIndexOfChar intrinsic was >>> added because we already had a similar intrinsic for constant string >>> needles of length one anyway. A later change (which we're already >>> working on) will add the intrinsics which can handle compact strings. >>> >>> The current intrinsics can handle both, the new byte-array based >>> string representation as well as the old char-array based string >>> representation because we internally still use the new hotspot with >>> older versions of the class libraries. >>> >>> I've also ported some of our internal string tests into a new >>> regression test (TestStringIntrinsics2.java) because the existing >>> tests didn't exercise all of our intrinsics. >>> >>> Following the shared changes I had to do: >>> >>> Until now, UseSSE42Intrinsics was a global shared option which was >>> used to control the availability of the stringIndexOf intrinsics. But >>> UseSSE42Intrinsics is actually a x86-specific feature so it doesn't >>> make a lot of sense to define it for other architectures. I've >>> therefore moved the flag to globals_x86.hpp and changed the condition >>> which checks for the ability of the stringIndexOf intrinsics from: >>> >>> if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) { >>> >>> to: >>> >>> if (!Matcher::match_rule_supported(Op_StrIndexOf)) { >>> >>> The Matcher::match_rule_supported() method already calls >>> Matcher::has_match_rule() anyway. And it is implemented in the .ad >>> file so I've moved the check for UseSSE42Intrinsics into x86.ad. Other >>> platforms can now decide in their .ad file if they unconditionally >>> support the intrinsic or if they need a special feature check. This >>> change was already briefly discussed in [1]. >>> >>> The other shared change I had to make was in >>> LibraryCallKit::make_string_method_node() for the "Op_StrEquals" case. >>> We have optimized intrinsics for the case that one of the strings to >>> compare is constant, but the StrEqualsNode is constructed without >>> taking into account that one of the string length values could be a >>> constant. This prevented our optimized instruction from being matched >>> in the ad-file. >>> >>> All the other changes are ppc-specific. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/thread.html#20400 From chris.plummer at oracle.com Thu Jan 21 03:17:35 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 20 Jan 2016 19:17:35 -0800 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569F7E22.3090905@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> Message-ID: <56A04DCF.9090204@oracle.com> Hi Mikael, The changes look good except I think you should get someone from the compiler team to make sure the change in HotSpotResolvedJavaMethodImpl.java and HotSpotVMConfig.java are ok. I'm not sure why you chose to remove instanceKlassVtableStartOffset() rather than just fix it. I think some of your changes may conflict with my changes for JDK-8143608. Coleen is pushing JDK-8143608 for me once hs-rt opens up. I'd appreciate it if you could wait until after then before doing your push. thanks, Chris On 1/20/16 4:31 AM, Mikael Gerdin wrote: > Hi again, > > I've rebased the on hs-rt and had to include some additional changes > for JVMCI. > I've also updated the copyright years. > Unfortunately I can't generate an incremental webrev since i rebased > the patch and there's no good way that I know of to make that work > with webrev. > > New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ > > Testing: JPRT again (which includes the JVMCI jtreg tests) > > /Mikael > > On 2016-01-15 18:04, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset >> and use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset >> and use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a >> byte offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is >> represented as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have >> a huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already >> in the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >> PPC64 would be much appreciated, appropriate mailing lists have been >> CC:ed to notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> >> >> Thanks! >> /Mikael >