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: <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
References: <CABKx++vh4zSog2=aQ=robT4yX_oURDuOp+otY-CnFhdM2pfSXQ@mail.gmail.com>
 <CA+3eh11U5kjgo3hc2f10jH_+ng9VJyYYadSHk7X4r=o=ofP-TA@mail.gmail.com>
 <CABKx++u6XqZAYsb2A=70qjDXvQytLq=4J34RuwP7GMzHuWP3Fw@mail.gmail.com>
 <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com>
 <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
Message-ID: <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>

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 <bob.vandette at oracle.com>
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 <aph at redhat.com> 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. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>

On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette <bob.vandette at oracle.com>
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 <aph at redhat.com> 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. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20171101/1a42f4dc/attachment.html>

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: <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>
References: <CABKx++vh4zSog2=aQ=robT4yX_oURDuOp+otY-CnFhdM2pfSXQ@mail.gmail.com>
 <CA+3eh11U5kjgo3hc2f10jH_+ng9VJyYYadSHk7X4r=o=ofP-TA@mail.gmail.com>
 <CABKx++u6XqZAYsb2A=70qjDXvQytLq=4J34RuwP7GMzHuWP3Fw@mail.gmail.com>
 <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com>
 <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
 <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>
Message-ID: <CAC-Dh98jVN+8KE4UvXBZ6=Y5H=oZhQyYjS-e51emKHZfC-4nWw@mail.gmail.com>

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 <raduandritoiu at gmail.com> 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 <bob.vandette at oracle.com>
> 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 <aph at redhat.com> 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. <https://www.redhat.com>
>> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>
>>
>
> On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette <bob.vandette at oracle.com>
> 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 <aph at redhat.com> 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. <https://www.redhat.com>
>> > 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: <f35f3c15-d87c-9e24-36d1-62529fbd314c@redhat.com>
References: <CABKx++vh4zSog2=aQ=robT4yX_oURDuOp+otY-CnFhdM2pfSXQ@mail.gmail.com>
 <CA+3eh11U5kjgo3hc2f10jH_+ng9VJyYYadSHk7X4r=o=ofP-TA@mail.gmail.com>
 <CABKx++u6XqZAYsb2A=70qjDXvQytLq=4J34RuwP7GMzHuWP3Fw@mail.gmail.com>
 <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com>
 <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
 <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>
 <f35f3c15-d87c-9e24-36d1-62529fbd314c@redhat.com>
Message-ID: <CABKx++uPkwYaqH0Tv+S5kv-59-KDgYu+KDAqoT__8g11AL2FMw@mail.gmail.com>

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 <aph at redhat.com> 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. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20171110/f014a55c/attachment.html>

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: <CAC-Dh98jVN+8KE4UvXBZ6=Y5H=oZhQyYjS-e51emKHZfC-4nWw@mail.gmail.com>
References: <CABKx++vh4zSog2=aQ=robT4yX_oURDuOp+otY-CnFhdM2pfSXQ@mail.gmail.com>
 <CA+3eh11U5kjgo3hc2f10jH_+ng9VJyYYadSHk7X4r=o=ofP-TA@mail.gmail.com>
 <CABKx++u6XqZAYsb2A=70qjDXvQytLq=4J34RuwP7GMzHuWP3Fw@mail.gmail.com>
 <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com>
 <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
 <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>
 <CAC-Dh98jVN+8KE4UvXBZ6=Y5H=oZhQyYjS-e51emKHZfC-4nWw@mail.gmail.com>
Message-ID: <CABKx++t9ftw4qRBJ1CJQgGHXLMwa6pSkcHS1wGsJFe3cd_SgTA@mail.gmail.com>

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 <tiago.daitx at canonical.com>
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 <raduandritoiu at gmail.com>
> 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 <bob.vandette at oracle.com>
> > 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 <aph at redhat.com> 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. <https://www.redhat.com>
> >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >>
> >>
> >
> > On Tue, Oct 24, 2017 at 3:34 PM, Bob Vandette <bob.vandette at oracle.com>
> > 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 <aph at redhat.com> 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. <https://www.redhat.com>
> >> > 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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20171110/e79ff135/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk8u_hotspot.patch
Type: application/octet-stream
Size: 1176 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20171110/e79ff135/jdk8u_hotspot.patch>

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: <CABKx++vh4zSog2=aQ=robT4yX_oURDuOp+otY-CnFhdM2pfSXQ@mail.gmail.com>
 <CA+3eh11U5kjgo3hc2f10jH_+ng9VJyYYadSHk7X4r=o=ofP-TA@mail.gmail.com>
 <CABKx++u6XqZAYsb2A=70qjDXvQytLq=4J34RuwP7GMzHuWP3Fw@mail.gmail.com>
 <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com>
 <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
 <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>
 <CAC-Dh98jVN+8KE4UvXBZ6=Y5H=oZhQyYjS-e51emKHZfC-4nWw@mail.gmail.com>
 <051a6516-e9b1-fb89-f90a-7c364a4f7811@redhat.com>
Message-ID: <CAC-Dh9-Ed0Uhh64oaiUAvnnfk4QVBVG3snUp8G8Mr8w-Ds_q1w@mail.gmail.com>

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 <aph at redhat.com> 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. <https://www.redhat.com>
> 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: <CAC-Dh9-Ed0Uhh64oaiUAvnnfk4QVBVG3snUp8G8Mr8w-Ds_q1w@mail.gmail.com>
References: <CABKx++vh4zSog2=aQ=robT4yX_oURDuOp+otY-CnFhdM2pfSXQ@mail.gmail.com>
 <CA+3eh11U5kjgo3hc2f10jH_+ng9VJyYYadSHk7X4r=o=ofP-TA@mail.gmail.com>
 <CABKx++u6XqZAYsb2A=70qjDXvQytLq=4J34RuwP7GMzHuWP3Fw@mail.gmail.com>
 <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com>
 <C24770F1-9B76-4E2B-AB22-05AD3AD8E8B7@oracle.com>
 <CABKx++vwHQjt_e6mVD9n0=EpCeAxK-99LQUncBWpVdLRMKMFSw@mail.gmail.com>
 <CAC-Dh98jVN+8KE4UvXBZ6=Y5H=oZhQyYjS-e51emKHZfC-4nWw@mail.gmail.com>
 <051a6516-e9b1-fb89-f90a-7c364a4f7811@redhat.com>
 <CAC-Dh9-Ed0Uhh64oaiUAvnnfk4QVBVG3snUp8G8Mr8w-Ds_q1w@mail.gmail.com>
Message-ID: <CABKx++sA8Kw-36PHFpi5ik0SDkH=GcgpiHn+jLK64s74597o_g@mail.gmail.com>

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 <tiago.daitx at canonical.com>
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 <aph at redhat.com> 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. <https://www.redhat.com>
> > 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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20171115/33a5c91f/attachment.html>

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: <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.com>

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
<gromero at linux.vnet.ibm.com> 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: <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.com>
References: <5A1887FF.1030406@linux.vnet.ibm.com>
 <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.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
> <gromero at linux.vnet.ibm.com> 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: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>

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: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>
References: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>
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 <hotspot-dev at openjdk.java.net>
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: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>
 <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com>
Message-ID: <CA+3eh10o=dnMY9iAaHwBfBQY5WCxDtkxEgLRup1E0Tg_mCd34w@mail.gmail.com>

Thanks Martin!


On Mon, Nov 27, 2017 at 5:05 PM, Doerr, Martin <martin.doerr at sap.com> 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 <hotspot-dev at openjdk.java.net>
> 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: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>
References: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>
Message-ID: <F03F5854-DD39-422A-912F-869D97D80476@oracle.com>

Hi Volker,

This looks good.

Thanks,
Jiangli

> On Nov 27, 2017, at 7:55 AM, Volker Simonis <volker.simonis at gmail.com> 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: <F03F5854-DD39-422A-912F-869D97D80476@oracle.com>
References: <CA+3eh10A6nRTzpsyySjhrvJ0Lpw3XhhianGdQF+3DP6jAbNfjw@mail.gmail.com>
 <F03F5854-DD39-422A-912F-869D97D80476@oracle.com>
Message-ID: <CA+3eh12+VFVALgZ6WEHUzqurZZdvuR0ECVYe3Z1mzk-9QjAmJA@mail.gmail.com>

Hi Jiangli,

thanks for the review!

Regards,
Volker


On Mon, Nov 27, 2017 at 8:22 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
> Hi Volker,
>
> This looks good.
>
> Thanks,
> Jiangli
>
>> On Nov 27, 2017, at 7:55 AM, Volker Simonis <volker.simonis at gmail.com> 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: <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.com>
References: <5A1887FF.1030406@linux.vnet.ibm.com>
 <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.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
> <gromero at linux.vnet.ibm.com> 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>
 <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.com>
 <5A1EB043.2000101@linux.vnet.ibm.com>
Message-ID: <CA+3eh122u1+2LYPKDSitzhZBcq8xdQ465KcErYpawaBZx_jujw@mail.gmail.com>

On Wed, Nov 29, 2017 at 2:04 PM, Gustavo Romero
<gromero at linux.vnet.ibm.com> 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
>> <gromero at linux.vnet.ibm.com> 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: <CA+3eh122u1+2LYPKDSitzhZBcq8xdQ465KcErYpawaBZx_jujw@mail.gmail.com>
References: <5A1887FF.1030406@linux.vnet.ibm.com>
 <CA+3eh11Y7bYEHPaCJWtX4NRK-q6WPvTKuXJmZkSuBpRjsjcNrQ@mail.gmail.com>
 <5A1EB043.2000101@linux.vnet.ibm.com>
 <CA+3eh122u1+2LYPKDSitzhZBcq8xdQ465KcErYpawaBZx_jujw@mail.gmail.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.