From raduandritoiu at gmail.com Wed Nov 1 17:27:12 2017 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Wed, 1 Nov 2017 19:27:12 +0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: Hello, I still have one error that I can not fix in order to compile the "zero" jvm-variant for PPC32: - the error: Compiling /home/build/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp: In static member function 'static jlong Atomic::add(jlong, volatile jlong*)': /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: error: impossible constraint in 'asm' /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: error: impossible constraint in 'asm' gmake[6]: *** [atomic.o] Error 1 - the code from the file /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp where I get the error is: // Atomically copy 64 bits of data static void atomic_copy64(volatile void *src, volatile void *dst) { #if defined(PPC32) double tmp; asm volatile ("lfd %0, 0(%1)\n" "stfd %0, 0(%2)\n" : "=f"(tmp) : "b"(src), "b"(dst)); #elif defined(S390) && !defined(_LP64) double tmp; asm volatile ("ld %0, 0(%1)\n" "std %0, 0(%2)\n" : "=r"(tmp) : "a"(src), "a"(dst)); #else *(jlong *) dst = *(jlong *) src; #endif } - line 44 is this one: : "b"(src), "b"(dst)); Thank you, Radu On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette wrote: > As others have mentioned, you need to target ZERO and not PPC32 when > trying to build > a non supported cpu architecture with the Zero interpreter. > > You do need to have a libffi.so binary available for the build. Zero uses > this to manage the > native stack frames. > > Bob. > > > > On Oct 24, 2017, at 4:46 AM, Andrew Haley wrote: > > > > On 18/10/17 13:20, Radu Andritoiu wrote: > >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for > >> 'libffi'. > >> I read that it uses 'libffi' for JNA to bridge between the interpreter > and > >> native code. It does not use JNI. > > > > That's wrong. Zero supports JNI just fine. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette wrote: > As others have mentioned, you need to target ZERO and not PPC32 when > trying to build > a non supported cpu architecture with the Zero interpreter. > > You do need to have a libffi.so binary available for the build. Zero uses > this to manage the > native stack frames. > > Bob. > > > > On Oct 24, 2017, at 4:46 AM, Andrew Haley wrote: > > > > On 18/10/17 13:20, Radu Andritoiu wrote: > >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for > >> 'libffi'. > >> I read that it uses 'libffi' for JNA to bridge between the interpreter > and > >> native code. It does not use JNI. > > > > That's wrong. Zero supports JNI just fine. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiago.daitx at canonical.com Thu Nov 2 00:11:30 2017 From: tiago.daitx at canonical.com (Tiago Daitx) Date: Wed, 1 Nov 2017 22:11:30 -0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: Radu, Please check if this patch from Debian/Ubuntu fix your issue: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/head:/debian/patches/hotspot-powerpcspe.diff You might also need this one: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/head:/debian/patches/zero-missing-headers.diff I know that zero is buildable in PPC32 since we did it for Ubuntu and do it for Debian, but I'm not sure this is all you need. Regards, Tiago On Wed, Nov 1, 2017 at 3:27 PM, Radu Andritoiu wrote: > Hello, > > I still have one error that I can not fix in order to compile the "zero" > jvm-variant for PPC32: > - the error: > > Compiling /home/build/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp: In > static member function 'static jlong Atomic::add(jlong, volatile jlong*)': > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > error: impossible constraint in 'asm' > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > error: impossible constraint in 'asm' > gmake[6]: *** [atomic.o] Error 1 > > - the code from the file > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp where > I get the error is: > > // Atomically copy 64 bits of data > static void atomic_copy64(volatile void *src, volatile void *dst) { > #if defined(PPC32) > double tmp; > asm volatile ("lfd %0, 0(%1)\n" > "stfd %0, 0(%2)\n" > : "=f"(tmp) > : "b"(src), "b"(dst)); > #elif defined(S390) && !defined(_LP64) > double tmp; > asm volatile ("ld %0, 0(%1)\n" > "std %0, 0(%2)\n" > : "=r"(tmp) > : "a"(src), "a"(dst)); > #else > *(jlong *) dst = *(jlong *) src; > #endif > } > > - line 44 is this one: > > : "b"(src), "b"(dst)); > > > > Thank you, > Radu > > > > On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette > wrote: > >> As others have mentioned, you need to target ZERO and not PPC32 when >> trying to build >> a non supported cpu architecture with the Zero interpreter. >> >> You do need to have a libffi.so binary available for the build. Zero uses >> this to manage the >> native stack frames. >> >> Bob. >> >> >> > On Oct 24, 2017, at 4:46 AM, Andrew Haley wrote: >> > >> > On 18/10/17 13:20, Radu Andritoiu wrote: >> >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for >> >> 'libffi'. >> >> I read that it uses 'libffi' for JNA to bridge between the interpreter >> and >> >> native code. It does not use JNI. >> > >> > That's wrong. Zero supports JNI just fine. >> > >> > -- >> > Andrew Haley >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> > > On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette > wrote: > >> As others have mentioned, you need to target ZERO and not PPC32 when >> trying to build >> a non supported cpu architecture with the Zero interpreter. >> >> You do need to have a libffi.so binary available for the build. Zero uses >> this to manage the >> native stack frames. >> >> Bob. >> >> >> > On Oct 24, 2017, at 4:46 AM, Andrew Haley wrote: >> > >> > On 18/10/17 13:20, Radu Andritoiu wrote: >> >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for >> >> 'libffi'. >> >> I read that it uses 'libffi' for JNA to bridge between the interpreter >> and >> >> native code. It does not use JNI. >> > >> > That's wrong. Zero supports JNI just fine. >> > >> > -- >> > Andrew Haley >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> -- Tiago St?rmer Daitx Software Engineer tiago.daitx at canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE From raduandritoiu at gmail.com Fri Nov 10 12:31:50 2017 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Fri, 10 Nov 2017 14:31:50 +0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: Hello, This fix didn't work for me. But the one in the next mail did work, I guess when cross-compiling it should not use specific ASM instructions. Thank you, Radu On Wed, Nov 1, 2017 at 8:21 PM, Andrew Haley wrote: > On 01/11/17 17:27, Radu Andritoiu wrote: > > > > I still have one error that I can not fix in order to compile the > "zero" jvm-variant for PPC32: > > - the error: > > > > Compiling /home/build/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp: > In static member function 'static jlong Atomic::add(jlong, volatile > jlong*)': > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > error: impossible constraint in 'asm' > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > error: impossible constraint in 'asm' > > gmake[6]: *** [atomic.o] Error 1 > > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raduandritoiu at gmail.com Fri Nov 10 12:39:59 2017 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Fri, 10 Nov 2017 14:39:59 +0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: Hello, This really fixed it for me. I guess when cross-compiling it should not use specific ASM instructions. For the second diff patch, I used the one I attached here. Basically it is the same. Thank you, Radu On Thu, Nov 2, 2017 at 2:11 AM, Tiago Daitx wrote: > Radu, > > Please check if this patch from Debian/Ubuntu fix your issue: > http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/ > head:/debian/patches/hotspot-powerpcspe.diff > > You might also need this one: > http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/ > head:/debian/patches/zero-missing-headers.diff > > I know that zero is buildable in PPC32 since we did it for Ubuntu and > do it for Debian, but I'm not sure this is all you need. > > Regards, > Tiago > > > On Wed, Nov 1, 2017 at 3:27 PM, Radu Andritoiu > wrote: > > Hello, > > > > I still have one error that I can not fix in order to compile the "zero" > > jvm-variant for PPC32: > > - the error: > > > > Compiling /home/build/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp: In > > static member function 'static jlong Atomic::add(jlong, volatile > jlong*)': > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > > error: impossible constraint in 'asm' > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > > error: impossible constraint in 'asm' > > gmake[6]: *** [atomic.o] Error 1 > > > > - the code from the file > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp > where > > I get the error is: > > > > // Atomically copy 64 bits of data > > static void atomic_copy64(volatile void *src, volatile void *dst) { > > #if defined(PPC32) > > double tmp; > > asm volatile ("lfd %0, 0(%1)\n" > > "stfd %0, 0(%2)\n" > > : "=f"(tmp) > > : "b"(src), "b"(dst)); > > #elif defined(S390) && !defined(_LP64) > > double tmp; > > asm volatile ("ld %0, 0(%1)\n" > > "std %0, 0(%2)\n" > > : "=r"(tmp) > > : "a"(src), "a"(dst)); > > #else > > *(jlong *) dst = *(jlong *) src; > > #endif > > } > > > > - line 44 is this one: > > > > : "b"(src), "b"(dst)); > > > > > > > > Thank you, > > Radu > > > > > > > > On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette > > wrote: > > > >> As others have mentioned, you need to target ZERO and not PPC32 when > >> trying to build > >> a non supported cpu architecture with the Zero interpreter. > >> > >> You do need to have a libffi.so binary available for the build. Zero > uses > >> this to manage the > >> native stack frames. > >> > >> Bob. > >> > >> > >> > On Oct 24, 2017, at 4:46 AM, Andrew Haley wrote: > >> > > >> > On 18/10/17 13:20, Radu Andritoiu wrote: > >> >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for > >> >> 'libffi'. > >> >> I read that it uses 'libffi' for JNA to bridge between the > interpreter > >> and > >> >> native code. It does not use JNI. > >> > > >> > That's wrong. Zero supports JNI just fine. > >> > > >> > -- > >> > Andrew Haley > >> > Java Platform Lead Engineer > >> > Red Hat UK Ltd. > >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > >> > >> > > > > On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette > > wrote: > > > >> As others have mentioned, you need to target ZERO and not PPC32 when > >> trying to build > >> a non supported cpu architecture with the Zero interpreter. > >> > >> You do need to have a libffi.so binary available for the build. Zero > uses > >> this to manage the > >> native stack frames. > >> > >> Bob. > >> > >> > >> > On Oct 24, 2017, at 4:46 AM, Andrew Haley wrote: > >> > > >> > On 18/10/17 13:20, Radu Andritoiu wrote: > >> >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for > >> >> 'libffi'. > >> >> I read that it uses 'libffi' for JNA to bridge between the > interpreter > >> and > >> >> native code. It does not use JNI. > >> > > >> > That's wrong. Zero supports JNI just fine. > >> > > >> > -- > >> > Andrew Haley > >> > Java Platform Lead Engineer > >> > Red Hat UK Ltd. > >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > >> > >> > > > > -- > Tiago St?rmer Daitx > Software Engineer > tiago.daitx at canonical.com > > PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) > Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8u_hotspot.patch Type: application/octet-stream Size: 1176 bytes Desc: not available URL: From tiago.daitx at canonical.com Fri Nov 10 21:08:34 2017 From: tiago.daitx at canonical.com (Tiago Daitx) Date: Fri, 10 Nov 2017 19:08:34 -0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: <051a6516-e9b1-fb89-f90a-7c364a4f7811@redhat.com> References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> <051a6516-e9b1-fb89-f90a-7c364a4f7811@redhat.com> Message-ID: Thanks for the input Andrew, good to know it makes the powerpc build non Java compatible (I assume this means JCK, right? I never ran it for non-intel systems) That particular patch has been added to Debian's OpenJDK 7 back in 2013, which was then carried over to OpenJDK 8 as well. It was based on this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712686 If anyone has a better fix, I would be glad to replace the patch - or remove it altogether if it makes upstream to OpenJDK 7 and 8. ;-) Regards, Tiago On Fri, Nov 10, 2017 at 12:22 PM, Andrew Haley wrote: > On 02/11/17 00:11, Tiago Daitx wrote: >> Please check if this patch from Debian/Ubuntu fix your issue: >> http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/head:/debian/patches/hotspot-powerpcspe.diff > > That looks wrong to me. You need a real way to copy 64-bit items atomically > or you won't be Java compatible. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Tiago St?rmer Daitx Software Engineer tiago.daitx at canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE From dean.long at oracle.com Mon Nov 13 17:32:09 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 13 Nov 2017 09:32:09 -0800 Subject: RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs Message-ID: <480ed17b-fae1-8db4-1d12-3319be262d3d@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8190817 http://cr.openjdk.java.net/~dlong/8190817/webrev/ This fix replaces the problematic use of _normal_table.entry(Bytecodes::_return).entry(vtos) as a deoptimization entry point with a proper deopt entry point returned by deopt_reexecute_return_entry().? This is needed to handle the situation where compiled code is calling register_finalizer() and gets deoptimized. I also noticed that we generate duplicate entry points unnecessarily, so I cleaned that up at the same time. aarch64/ppc64/s390 folks, please check that compiler/runtime/Test8168712.java still passes. dl From raduandritoiu at gmail.com Wed Nov 15 10:25:41 2017 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Wed, 15 Nov 2017 12:25:41 +0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> <051a6516-e9b1-fb89-f90a-7c364a4f7811@redhat.com> Message-ID: Hello, The debian patch for *openjdk/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp* is almost the same with the other (previous) one. The only difference is it does not change the ASM code. In my case the if-condition fixes the error and makes it compile, which means the atomic_copy_64() is done like this: *(jlong *) dst = *(jlong *) src; What you are saying is that cross-compiling jdk8u for PPC32 with this patch makes the resulting JVM not java compatible, right? Is there another way to get it to compile for PPC32? Also what I saw is that "hotspot" rule only compiles the JVM . And in order to get a working JRE, that I can copy/install on a clean machine, I also have to compile the "jdk" rules. Right? Thank you, Radu On Fri, Nov 10, 2017 at 11:08 PM, Tiago Daitx wrote: > Thanks for the input Andrew, good to know it makes the powerpc build > non Java compatible (I assume this means JCK, right? I never ran it > for non-intel systems) > > That particular patch has been added to Debian's OpenJDK 7 back in > 2013, which was then carried over to OpenJDK 8 as well. It was based > on this bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712686 > > If anyone has a better fix, I would be glad to replace the patch - or > remove it altogether if it makes upstream to OpenJDK 7 and 8. ;-) > > Regards, > Tiago > > On Fri, Nov 10, 2017 at 12:22 PM, Andrew Haley wrote: > > On 02/11/17 00:11, Tiago Daitx wrote: > >> Please check if this patch from Debian/Ubuntu fix your issue: > >> http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/ > head:/debian/patches/hotspot-powerpcspe.diff > > > > That looks wrong to me. You need a real way to copy 64-bit items > atomically > > or you won't be Java compatible. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > -- > Tiago St?rmer Daitx > Software Engineer > tiago.daitx at canonical.com > > PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) > Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Fri Nov 24 20:58:39 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 24 Nov 2017 18:58:39 -0200 Subject: POWER9: Is there a way to improve the random number generation on PPC64? Message-ID: <5A1887FF.1030406@linux.vnet.ibm.com> Hi, POWER9 processors introduced a new single instruction to generate a random number called 'darn' (Deliver A Random Number) [1, 2]. The random number generator behind this instruction is NIST SP800-90B and SP800-90C compliant and provides a minimum of 0.5 bits of entropy per bit. That instruction is as simple as "darn RT, L", where RT is general 64-bit purpose register and L is a 2-bit operand to select the random number format. One can call 'darn' many times to obtain a new random number each time. Initially I think it can help on the improving (throughput) of SecureRandom.generateSeed() method & friends from JCE (NativePRNG provider). If that holds, so it has to be done both for Interpreter and JIT. Currently generateSeed() from NativePRNG basically reads from /dev/random by default (which blocks from time to time) or /dev/urandom if instructed to do so. Could somebody please help me to figure out the appropriate place to exploit such a P9 instruction for interpreted mode, given that code for generateSeed() is pure Java and behind scenes just opens /dev/random file and reads from it? For instance, is it correct to exploit it on a C/C++ code and attach that by means of a JNI? Finally, for JITed mode, I think that a way to exploit such a feature would be by matching an specific sub-tree in Ideal Graph and from that emit a `darn` instruction, however I could not figure one sound sub-tree with known nodes (AddI, LoadN, Parm, etc) that could be matched for that purpose. How do porters usually proceed in this case? Any comments shedding some light on that is much appreciated. Thanks and best regards, Gustavo [1] https://www.docdroid.net/tWT7hjD/powerisa-v30.pdf, p. 79 [2] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 From volker.simonis at gmail.com Fri Nov 24 22:04:04 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Nov 2017 14:04:04 -0800 Subject: POWER9: Is there a way to improve the random number generation on PPC64? In-Reply-To: <5A1887FF.1030406@linux.vnet.ibm.com> References: <5A1887FF.1030406@linux.vnet.ibm.com> Message-ID: Hi Gustavo, in one of my talks [1,2] I have an example on how to intrinsify Random.nextInt() in C2 by using the Intel 'rdrandl' instruction. But please notice that this is just a "toy" example - it is not production ready. In fact I think the right way would be to create a new SecureRandom provider where you may implement "engineNextBytes" by using the new Power instruction (maybe by calling a native function). This special implementation of "engineNextBytes" could then be intrinsified as described in the talk. Also, before you start this, please contact the security mailing list just to make sure you're not going into the wrong direction (I'm not a security expert :) Regards, Volker [1] https://vimeo.com/182074382 [2] https://rawgit.com/simonis/JBreak2016/master/jbreak2016.xhtml#/ On Fri, Nov 24, 2017 at 12:58 PM, Gustavo Romero wrote: > Hi, > > POWER9 processors introduced a new single instruction to generate a random > number called 'darn' (Deliver A Random Number) [1, 2]. The random number > generator behind this instruction is NIST SP800-90B and SP800-90C compliant and > provides a minimum of 0.5 bits of entropy per bit. That instruction is as simple > as "darn RT, L", where RT is general 64-bit purpose register and L is a 2-bit > operand to select the random number format. One can call 'darn' many times to > obtain a new random number each time. > > Initially I think it can help on the improving (throughput) of SecureRandom.generateSeed() > method & friends from JCE (NativePRNG provider). If that holds, so it has to > be done both for Interpreter and JIT. > > Currently generateSeed() from NativePRNG basically reads from /dev/random by > default (which blocks from time to time) or /dev/urandom if instructed to do so. > Could somebody please help me to figure out the appropriate place to exploit > such a P9 instruction for interpreted mode, given that code for generateSeed() > is pure Java and behind scenes just opens /dev/random file and reads from > it? For instance, is it correct to exploit it on a C/C++ code and attach that > by means of a JNI? > > Finally, for JITed mode, I think that a way to exploit such a feature would be > by matching an specific sub-tree in Ideal Graph and from that emit a `darn` > instruction, however I could not figure one sound sub-tree with known nodes > (AddI, LoadN, Parm, etc) that could be matched for that purpose. How do porters > usually proceed in this case? > > Any comments shedding some light on that is much appreciated. > > Thanks and best regards, > Gustavo > > [1] https://www.docdroid.net/tWT7hjD/powerisa-v30.pdf, p. 79 > [2] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 > From gromero at linux.vnet.ibm.com Mon Nov 27 13:08:43 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 27 Nov 2017 11:08:43 -0200 Subject: POWER9: Is there a way to improve the random number generation on PPC64? In-Reply-To: References: <5A1887FF.1030406@linux.vnet.ibm.com> Message-ID: <5A1C0E5B.4090508@linux.vnet.ibm.com> Hi Volker, On 24-11-2017 20:04, Volker Simonis wrote: > Hi Gustavo, > > in one of my talks [1,2] I have an example on how to intrinsify > Random.nextInt() in C2 by using the Intel 'rdrandl' instruction. But > please notice that this is just a "toy" example - it is not production > ready. In fact I think the right way would be to create a new > SecureRandom provider where you may implement "engineNextBytes" by > using the new Power instruction (maybe by calling a native function). > This special implementation of "engineNextBytes" could then be > intrinsified as described in the talk. Thanks for the references :-) > Also, before you start this, please contact the security mailing list > just to make sure you're not going into the wrong direction (I'm not a > security expert :) Sure. I just want to do a few experiments before to get at least an initial working "toy" example for 'darn'. The references you pointed out will help a lot. Thanks! Regards, Gustavo > Regards, > Volker > > [1] https://vimeo.com/182074382 > [2] https://rawgit.com/simonis/JBreak2016/master/jbreak2016.xhtml#/ > > On Fri, Nov 24, 2017 at 12:58 PM, Gustavo Romero > wrote: >> Hi, >> >> POWER9 processors introduced a new single instruction to generate a random >> number called 'darn' (Deliver A Random Number) [1, 2]. The random number >> generator behind this instruction is NIST SP800-90B and SP800-90C compliant and >> provides a minimum of 0.5 bits of entropy per bit. That instruction is as simple >> as "darn RT, L", where RT is general 64-bit purpose register and L is a 2-bit >> operand to select the random number format. One can call 'darn' many times to >> obtain a new random number each time. >> >> Initially I think it can help on the improving (throughput) of SecureRandom.generateSeed() >> method & friends from JCE (NativePRNG provider). If that holds, so it has to >> be done both for Interpreter and JIT. >> >> Currently generateSeed() from NativePRNG basically reads from /dev/random by >> default (which blocks from time to time) or /dev/urandom if instructed to do so. >> Could somebody please help me to figure out the appropriate place to exploit >> such a P9 instruction for interpreted mode, given that code for generateSeed() >> is pure Java and behind scenes just opens /dev/random file and reads from >> it? For instance, is it correct to exploit it on a C/C++ code and attach that >> by means of a JNI? >> >> Finally, for JITed mode, I think that a way to exploit such a feature would be >> by matching an specific sub-tree in Ideal Graph and from that emit a `darn` >> instruction, however I could not figure one sound sub-tree with known nodes >> (AddI, LoadN, Parm, etc) that could be matched for that purpose. How do porters >> usually proceed in this case? >> >> Any comments shedding some light on that is much appreciated. >> >> Thanks and best regards, >> Gustavo >> >> [1] https://www.docdroid.net/tWT7hjD/powerisa-v30.pdf, p. 79 >> [2] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 >> > From volker.simonis at gmail.com Mon Nov 27 15:55:27 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Nov 2017 16:55:27 +0100 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces Message-ID: Hi, can I please have a review for the following small, ppc64-only change which fixes CDS on Power: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ https://bugs.openjdk.java.net/browse/JDK-8191770 Don't rewrite invokefinal into fast_invokevfinal if running with DumpSharedSpaces or UseSharedSpaces. The Template-Interpreter of the ppc-Port was initially derived from the SPARC version which didn't had full CDS support at that time, that's why the guard against DumpSharedSpaces was missing at the place where invokefinal is rewritten. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/ppc64, Linux/ppc64le and AIX. Thank you and best regards, Volker From martin.doerr at sap.com Mon Nov 27 16:05:17 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 27 Nov 2017 16:05:17 +0000 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: References: Message-ID: <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com> Hi Volker, looks good. Thanks for fixing. Best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Montag, 27. November 2017 16:55 To: HotSpot Open Source Developers Cc: ppc-aix-port-dev at openjdk.java.net Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces Hi, can I please have a review for the following small, ppc64-only change which fixes CDS on Power: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ https://bugs.openjdk.java.net/browse/JDK-8191770 Don't rewrite invokefinal into fast_invokevfinal if running with DumpSharedSpaces or UseSharedSpaces. The Template-Interpreter of the ppc-Port was initially derived from the SPARC version which didn't had full CDS support at that time, that's why the guard against DumpSharedSpaces was missing at the place where invokefinal is rewritten. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/ppc64, Linux/ppc64le and AIX. Thank you and best regards, Volker From volker.simonis at gmail.com Mon Nov 27 17:16:51 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Nov 2017 18:16:51 +0100 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com> References: <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com> Message-ID: Thanks Martin! On Mon, Nov 27, 2017 at 5:05 PM, Doerr, Martin wrote: > Hi Volker, > > looks good. Thanks for fixing. > > Best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Montag, 27. November 2017 16:55 > To: HotSpot Open Source Developers > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces > > Hi, > > can I please have a review for the following small, ppc64-only change > which fixes CDS on Power: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ > https://bugs.openjdk.java.net/browse/JDK-8191770 > > Don't rewrite invokefinal into fast_invokevfinal if running with > DumpSharedSpaces or UseSharedSpaces. > > The Template-Interpreter of the ppc-Port was initially derived from > the SPARC version which didn't had full CDS support at that time, > that's why the guard against DumpSharedSpaces was missing at the place > where invokefinal is rewritten. > > With this change, all the CDS and upcoming AppCDS jtreg pass on > Linux/ppc64, Linux/ppc64le and AIX. > > Thank you and best regards, > Volker From jiangli.zhou at oracle.com Mon Nov 27 19:22:45 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 27 Nov 2017 11:22:45 -0800 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: References: Message-ID: Hi Volker, This looks good. Thanks, Jiangli > On Nov 27, 2017, at 7:55 AM, Volker Simonis wrote: > > Hi, > > can I please have a review for the following small, ppc64-only change > which fixes CDS on Power: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ > https://bugs.openjdk.java.net/browse/JDK-8191770 > > Don't rewrite invokefinal into fast_invokevfinal if running with > DumpSharedSpaces or UseSharedSpaces. > > The Template-Interpreter of the ppc-Port was initially derived from > the SPARC version which didn't had full CDS support at that time, > that's why the guard against DumpSharedSpaces was missing at the place > where invokefinal is rewritten. > > With this change, all the CDS and upcoming AppCDS jtreg pass on > Linux/ppc64, Linux/ppc64le and AIX. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Tue Nov 28 09:56:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 28 Nov 2017 10:56:18 +0100 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: References: Message-ID: Hi Jiangli, thanks for the review! Regards, Volker On Mon, Nov 27, 2017 at 8:22 PM, Jiangli Zhou wrote: > Hi Volker, > > This looks good. > > Thanks, > Jiangli > >> On Nov 27, 2017, at 7:55 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following small, ppc64-only change >> which fixes CDS on Power: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ >> https://bugs.openjdk.java.net/browse/JDK-8191770 >> >> Don't rewrite invokefinal into fast_invokevfinal if running with >> DumpSharedSpaces or UseSharedSpaces. >> >> The Template-Interpreter of the ppc-Port was initially derived from >> the SPARC version which didn't had full CDS support at that time, >> that's why the guard against DumpSharedSpaces was missing at the place >> where invokefinal is rewritten. >> >> With this change, all the CDS and upcoming AppCDS jtreg pass on >> Linux/ppc64, Linux/ppc64le and AIX. >> >> Thank you and best regards, >> Volker > From gromero at linux.vnet.ibm.com Wed Nov 29 13:04:03 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 29 Nov 2017 11:04:03 -0200 Subject: POWER9: Is there a way to improve the random number generation on PPC64? In-Reply-To: References: <5A1887FF.1030406@linux.vnet.ibm.com> Message-ID: <5A1EB043.2000101@linux.vnet.ibm.com> Hi Volker, On 24-11-2017 20:04, Volker Simonis wrote: > in one of my talks [1,2] I have an example on how to intrinsify > Random.nextInt() in C2 by using the Intel 'rdrandl' instruction. But > please notice that this is just a "toy" example - it is not production > ready. In fact I think the right way would be to create a new > SecureRandom provider where you may implement "engineNextBytes" by > using the new Power instruction (maybe by calling a native function). > This special implementation of "engineNextBytes" could then be > intrinsified as described in the talk. I've implemented a simple interpreter intrinsic for 'darn' for a given class/method provided by the user, similarly to what you did for Helloword.sayHello() in your example. Thanks! I'm now looking for the correct way to call back from the intrinsic a Java method to act as a fallback method, since ISA says [1]: When the error value is obtained [i.e. 'darn' did not return a random number], software is expected to repeat the operation. If a non-error value has not been obtained after several attempts, a software random number generation method should be used. The recommended number of attempts may be implementation specific. In the absence of other guidance, ten attempts should be adequate. and so I need to call back from the intrinsic, let's say, SecureRandom.netInt() non-intrinsified method after about 10 failures to get the random number so it can take over the task again. You did something like that here: https://github.com/simonis/JBreak2016/blob/master/examples/hs_patches/JBreak_HelloWorldIntrinsic.patch#L55 but for fputs() from libc. Do you know if it's possible to call, for instance, a loaded method like SecureRandom.nextInt() from the instrinsic? Thanks! Regards, Gustavo > Also, before you start this, please contact the security mailing list > just to make sure you're not going into the wrong direction (I'm not a > security expert :) > > Regards, > Volker > > [1] https://vimeo.com/182074382 > [2] https://rawgit.com/simonis/JBreak2016/master/jbreak2016.xhtml#/ > > On Fri, Nov 24, 2017 at 12:58 PM, Gustavo Romero > wrote: >> Hi, >> >> POWER9 processors introduced a new single instruction to generate a random >> number called 'darn' (Deliver A Random Number) [1, 2]. The random number >> generator behind this instruction is NIST SP800-90B and SP800-90C compliant and >> provides a minimum of 0.5 bits of entropy per bit. That instruction is as simple >> as "darn RT, L", where RT is general 64-bit purpose register and L is a 2-bit >> operand to select the random number format. One can call 'darn' many times to >> obtain a new random number each time. >> >> Initially I think it can help on the improving (throughput) of SecureRandom.generateSeed() >> method & friends from JCE (NativePRNG provider). If that holds, so it has to >> be done both for Interpreter and JIT. >> >> Currently generateSeed() from NativePRNG basically reads from /dev/random by >> default (which blocks from time to time) or /dev/urandom if instructed to do so. >> Could somebody please help me to figure out the appropriate place to exploit >> such a P9 instruction for interpreted mode, given that code for generateSeed() >> is pure Java and behind scenes just opens /dev/random file and reads from >> it? For instance, is it correct to exploit it on a C/C++ code and attach that >> by means of a JNI? >> >> Finally, for JITed mode, I think that a way to exploit such a feature would be >> by matching an specific sub-tree in Ideal Graph and from that emit a `darn` >> instruction, however I could not figure one sound sub-tree with known nodes >> (AddI, LoadN, Parm, etc) that could be matched for that purpose. How do porters >> usually proceed in this case? >> >> Any comments shedding some light on that is much appreciated. >> >> Thanks and best regards, >> Gustavo >> >> [1] https://www.docdroid.net/tWT7hjD/powerisa-v30.pdf, p. 79 >> [2] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 >> > From volker.simonis at gmail.com Wed Nov 29 13:21:46 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Nov 2017 14:21:46 +0100 Subject: POWER9: Is there a way to improve the random number generation on PPC64? In-Reply-To: <5A1EB043.2000101@linux.vnet.ibm.com> References: <5A1887FF.1030406@linux.vnet.ibm.com> <5A1EB043.2000101@linux.vnet.ibm.com> Message-ID: On Wed, Nov 29, 2017 at 2:04 PM, Gustavo Romero wrote: > Hi Volker, > > On 24-11-2017 20:04, Volker Simonis wrote: >> in one of my talks [1,2] I have an example on how to intrinsify >> Random.nextInt() in C2 by using the Intel 'rdrandl' instruction. But >> please notice that this is just a "toy" example - it is not production >> ready. In fact I think the right way would be to create a new >> SecureRandom provider where you may implement "engineNextBytes" by >> using the new Power instruction (maybe by calling a native function). >> This special implementation of "engineNextBytes" could then be >> intrinsified as described in the talk. > > I've implemented a simple interpreter intrinsic for 'darn' for a given > class/method provided by the user, similarly to what you did for > Helloword.sayHello() in your example. Thanks! I'm now looking for the correct > way to call back from the intrinsic a Java method to act as a fallback method, > since ISA says [1]: > > When the error value is obtained [i.e. 'darn' did not return a random number], > software is expected to repeat the operation. If a non-error value has not been > obtained after several attempts, a software random number generation method > should be used. The recommended number of attempts may be implementation > specific. In the absence of other guidance, ten attempts should be adequate. > > and so I need to call back from the intrinsic, let's say, SecureRandom.netInt() > non-intrinsified method after about 10 failures to get the random number so it > can take over the task again. You did something like that here: > > https://github.com/simonis/JBreak2016/blob/master/examples/hs_patches/JBreak_HelloWorldIntrinsic.patch#L55 > > but for fputs() from libc. > > Do you know if it's possible to call, for instance, a loaded method like > SecureRandom.nextInt() from the instrinsic? > I don't think that would be easy to do (if possible at all). The correct way to handle such situations would be to define a Java method with the exact semantics of your 'darn' instruction. All the other logic should be implemented in Java. So for example you would implement SecureRandom.darn() and call it from engineNextBytes(). At the call site of darn() you check the error value and dispatch to the corresponding Java implementation if necessary. > Thanks! > > Regards, > Gustavo > >> Also, before you start this, please contact the security mailing list >> just to make sure you're not going into the wrong direction (I'm not a >> security expert :) >> >> Regards, >> Volker >> >> [1] https://vimeo.com/182074382 >> [2] https://rawgit.com/simonis/JBreak2016/master/jbreak2016.xhtml#/ >> >> On Fri, Nov 24, 2017 at 12:58 PM, Gustavo Romero >> wrote: >>> Hi, >>> >>> POWER9 processors introduced a new single instruction to generate a random >>> number called 'darn' (Deliver A Random Number) [1, 2]. The random number >>> generator behind this instruction is NIST SP800-90B and SP800-90C compliant and >>> provides a minimum of 0.5 bits of entropy per bit. That instruction is as simple >>> as "darn RT, L", where RT is general 64-bit purpose register and L is a 2-bit >>> operand to select the random number format. One can call 'darn' many times to >>> obtain a new random number each time. >>> >>> Initially I think it can help on the improving (throughput) of SecureRandom.generateSeed() >>> method & friends from JCE (NativePRNG provider). If that holds, so it has to >>> be done both for Interpreter and JIT. >>> >>> Currently generateSeed() from NativePRNG basically reads from /dev/random by >>> default (which blocks from time to time) or /dev/urandom if instructed to do so. >>> Could somebody please help me to figure out the appropriate place to exploit >>> such a P9 instruction for interpreted mode, given that code for generateSeed() >>> is pure Java and behind scenes just opens /dev/random file and reads from >>> it? For instance, is it correct to exploit it on a C/C++ code and attach that >>> by means of a JNI? >>> >>> Finally, for JITed mode, I think that a way to exploit such a feature would be >>> by matching an specific sub-tree in Ideal Graph and from that emit a `darn` >>> instruction, however I could not figure one sound sub-tree with known nodes >>> (AddI, LoadN, Parm, etc) that could be matched for that purpose. How do porters >>> usually proceed in this case? >>> >>> Any comments shedding some light on that is much appreciated. >>> >>> Thanks and best regards, >>> Gustavo >>> >>> [1] https://www.docdroid.net/tWT7hjD/powerisa-v30.pdf, p. 79 >>> [2] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 >>> >> > From gromero at linux.vnet.ibm.com Wed Nov 29 14:56:29 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 29 Nov 2017 12:56:29 -0200 Subject: POWER9: Is there a way to improve the random number generation on PPC64? In-Reply-To: References: <5A1887FF.1030406@linux.vnet.ibm.com> <5A1EB043.2000101@linux.vnet.ibm.com> Message-ID: <5A1ECA9D.7000005@linux.vnet.ibm.com> Hi Volker, On 29-11-2017 11:21, Volker Simonis wrote: > I don't think that would be easy to do (if possible at all). > > The correct way to handle such situations would be to define a Java > method with the exact semantics of your 'darn' instruction. All the > other logic should be implemented in Java. So for example you would > implement SecureRandom.darn() and call it from engineNextBytes(). At > the call site of darn() you check the error value and dispatch to the > corresponding Java implementation if necessary. I see. Thanks for advising.