From sgehwolf at redhat.com  Tue Oct  2 10:33:46 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 02 Oct 2018 12:33:46 +0200
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
 and os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
Message-ID: <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>

Hi,

Pinging PPC porters. Does this look reasonable to you?

Thanks,
Severin


On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> Build changes look ok to me.
> 
> /Erik
> 
> 
> On 2018-09-26 04:26, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get reviews for this JDK 8 backport which fixes some
> > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > would report as "ppc64" via os.arch system property which breaks
> > tooling such as maven in as much as if some dependency needs native
> > libraries it would download BE binaries where it actually should
> > download LE binaries. Example for os.arch/java.library.path:
> > 
> > pre:
> > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > os.arch = ppc64
> > 
> > post:
> > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > os.arch = ppc64le
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/
> > 
> > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev
> > for JDK/hotspot changes.
> > 
> > This backport should only have minor differences to the changes in JDK
> > 11. We have been using similar patches in Fedora for months. Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> 
> 


From goetz.lindenmaier at sap.com  Tue Oct  2 10:40:31 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 2 Oct 2018 10:40:31 +0000
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
 os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
Message-ID: <666987d08f324a0c94208c6cca403214@sap.com>

Hi,

I'm fine with this.

If I remember correctly, this was proposed before but 
never pushed in the end.
Did you test this on ppc64 be, too?  

Best regards,
  Goetz.

> -----Original Message-----
> From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On
> Behalf Of Severin Gehwolf
> Sent: Dienstag, 2. Oktober 2018 12:34
> To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> os.arch value on ppc64le cause issues with Java tooling
> 
> Hi,
> 
> Pinging PPC porters. Does this look reasonable to you?
> 
> Thanks,
> Severin
> 
> 
> On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > Build changes look ok to me.
> >
> > /Erik
> >
> >
> > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Could I please get reviews for this JDK 8 backport which fixes some
> > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > would report as "ppc64" via os.arch system property which breaks
> > > tooling such as maven in as much as if some dependency needs native
> > > libraries it would download BE binaries where it actually should
> > > download LE binaries. Example for os.arch/java.library.path:
> > >
> > > pre:
> > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > java.library.path =
> /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > os.arch = ppc64
> > >
> > > post:
> > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > java.library.path =
> /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > os.arch = ppc64le
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8073139/jdk8/01/
> > >
> > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev
> > > for JDK/hotspot changes.
> > >
> > > This backport should only have minor differences to the changes in JDK
> > > 11. We have been using similar patches in Fedora for months. Thoughts?
> > >
> > > Thanks,
> > > Severin
> > >
> >
> >


From sgehwolf at redhat.com  Tue Oct  2 11:09:15 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 02 Oct 2018 13:09:15 +0200
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
 and os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <666987d08f324a0c94208c6cca403214@sap.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
 <666987d08f324a0c94208c6cca403214@sap.com>
Message-ID: <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com>

Hi Goetz,

On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> I'm fine with this.

Thanks for the review!

> If I remember correctly, this was proposed before but 
> never pushed in the end.

Interesting.

> Did you test this on ppc64 be, too?  

I have not. Will do so, though.

Thanks,
Severin

> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On
> > Behalf Of Severin Gehwolf
> > Sent: Dienstag, 2. Oktober 2018 12:34
> > To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> > os.arch value on ppc64le cause issues with Java tooling
> > 
> > Hi,
> > 
> > Pinging PPC porters. Does this look reasonable to you?
> > 
> > Thanks,
> > Severin
> > 
> > 
> > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > > Build changes look ok to me.
> > > 
> > > /Erik
> > > 
> > > 
> > > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Could I please get reviews for this JDK 8 backport which fixes some
> > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > > would report as "ppc64" via os.arch system property which breaks
> > > > tooling such as maven in as much as if some dependency needs native
> > > > libraries it would download BE binaries where it actually should
> > > > download LE binaries. Example for os.arch/java.library.path:
> > > > 
> > > > pre:
> > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > > java.library.path =
> > 
> > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > > os.arch = ppc64
> > > > 
> > > > post:
> > > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > > java.library.path =
> > 
> > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > > os.arch = ppc64le
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > 
> > 8073139/jdk8/01/
> > > > 
> > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev
> > > > for JDK/hotspot changes.
> > > > 
> > > > This backport should only have minor differences to the changes in JDK
> > > > 11. We have been using similar patches in Fedora for months. Thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > 
> > > 
> 
> 


From goetz.lindenmaier at sap.com  Tue Oct  2 12:39:16 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 2 Oct 2018 12:39:16 +0000
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
 os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
 <666987d08f324a0c94208c6cca403214@sap.com>
 <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com>
Message-ID: <6d0a6a512b39469b8afd25ae587c99ba@sap.com>

Hi Severin, 

here for example: http://mail.openjdk.java.net/pipermail/build-dev/2015-July/015370.html
While the fix proposed there looks different and the downport was never 
finished.

Best regards,
  Goetz.



> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Dienstag, 2. Oktober 2018 13:09
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Erik Joelsson
> <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> os.arch value on ppc64le cause issues with Java tooling
> 
> Hi Goetz,
> 
> On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I'm fine with this.
> 
> Thanks for the review!
> 
> > If I remember correctly, this was proposed before but
> > never pushed in the end.
> 
> Interesting.
> 
> > Did you test this on ppc64 be, too?
> 
> I have not. Will do so, though.
> 
> Thanks,
> Severin
> 
> > Best regards,
> >   Goetz.
> >
> > > -----Original Message-----
> > > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Severin Gehwolf
> > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
> and
> > > os.arch value on ppc64le cause issues with Java tooling
> > >
> > > Hi,
> > >
> > > Pinging PPC porters. Does this look reasonable to you?
> > >
> > > Thanks,
> > > Severin
> > >
> > >
> > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > > > Build changes look ok to me.
> > > >
> > > > /Erik
> > > >
> > > >
> > > > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > > > Hi,
> > > > >
> > > > > Could I please get reviews for this JDK 8 backport which fixes some
> > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > > > would report as "ppc64" via os.arch system property which breaks
> > > > > tooling such as maven in as much as if some dependency needs
> native
> > > > > libraries it would download BE binaries where it actually should
> > > > > download LE binaries. Example for os.arch/java.library.path:
> > > > >
> > > > > pre:
> > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > > > java.library.path =
> > >
> > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > os.arch = ppc64
> > > > >
> > > > > post:
> > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > > > java.library.path =
> > >
> > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > os.arch = ppc64le
> > > > >
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > >
> > > 8073139/jdk8/01/
> > > > >
> > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-
> dev
> > > > > for JDK/hotspot changes.
> > > > >
> > > > > This backport should only have minor differences to the changes in
> JDK
> > > > > 11. We have been using similar patches in Fedora for months.
> Thoughts?
> > > > >
> > > > > Thanks,
> > > > > Severin
> > > > >
> > > >
> > > >
> >
> >


From sgehwolf at redhat.com  Tue Oct  2 12:59:39 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 02 Oct 2018 14:59:39 +0200
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
 and os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <6d0a6a512b39469b8afd25ae587c99ba@sap.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
 <666987d08f324a0c94208c6cca403214@sap.com>
 <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com>
 <6d0a6a512b39469b8afd25ae587c99ba@sap.com>
Message-ID: <26f26253dd3bd909ae17e729b6286fce7c86f32c.camel@redhat.com>

Hi Goetz,

I'm a bit confused :-/

On Tue, 2018-10-02 at 12:39 +0000, Lindenmaier, Goetz wrote:
> Hi Severin, 
> 
> here for example: http://mail.openjdk.java.net/pipermail/build-dev/2015-July/015370.html

As far as I can see that was relating to the JDK-head fix which wasn't
available at the time (July vs. pushed in Dec). The original review
thread was here:
http://mail.openjdk.java.net/pipermail/build-dev/2015-December/016103.html

JDK-8073139 has been fixed in JDK 9+ since December 14, 2015.

> While the fix proposed there looks different and the downport was never 
> finished.

FWIW, this is a review request for the 8u backport :)

Thanks,
Severin

> Best regards,
>   Goetz.
> 
> 
> 
> > -----Original Message-----
> > From: Severin Gehwolf <sgehwolf at redhat.com>
> > Sent: Dienstag, 2. Oktober 2018 13:09
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Erik Joelsson
> > <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> > os.arch value on ppc64le cause issues with Java tooling
> > 
> > Hi Goetz,
> > 
> > On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote:
> > > Hi,
> > > 
> > > I'm fine with this.
> > 
> > Thanks for the review!
> > 
> > > If I remember correctly, this was proposed before but
> > > never pushed in the end.
> > 
> > Interesting.
> > 
> > > Did you test this on ppc64 be, too?
> > 
> > I have not. Will do so, though.
> > 
> > Thanks,
> > Severin
> > 
> > > Best regards,
> > >   Goetz.
> > > 
> > > > -----Original Message-----
> > > > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net>
> > 
> > On
> > > > Behalf Of Severin Gehwolf
> > > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > > To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > > > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > > > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
> > 
> > and
> > > > os.arch value on ppc64le cause issues with Java tooling
> > > > 
> > > > Hi,
> > > > 
> > > > Pinging PPC porters. Does this look reasonable to you?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > > > > Build changes look ok to me.
> > > > > 
> > > > > /Erik
> > > > > 
> > > > > 
> > > > > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Could I please get reviews for this JDK 8 backport which fixes some
> > > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > > > > would report as "ppc64" via os.arch system property which breaks
> > > > > > tooling such as maven in as much as if some dependency needs
> > 
> > native
> > > > > > libraries it would download BE binaries where it actually should
> > > > > > download LE binaries. Example for os.arch/java.library.path:
> > > > > > 
> > > > > > pre:
> > > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > > > > java.library.path =
> > > > 
> > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > > os.arch = ppc64
> > > > > > 
> > > > > > post:
> > > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > > > > java.library.path =
> > > > 
> > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > > os.arch = ppc64le
> > > > > > 
> > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > > > 
> > > > 8073139/jdk8/01/
> > > > > > 
> > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-
> > 
> > dev
> > > > > > for JDK/hotspot changes.
> > > > > > 
> > > > > > This backport should only have minor differences to the changes in
> > 
> > JDK
> > > > > > 11. We have been using similar patches in Fedora for months.
> > 
> > Thoughts?
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 


From goetz.lindenmaier at sap.com  Tue Oct  2 13:14:49 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 2 Oct 2018 13:14:49 +0000
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
 os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <26f26253dd3bd909ae17e729b6286fce7c86f32c.camel@redhat.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
 <666987d08f324a0c94208c6cca403214@sap.com>
 <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com>
 <6d0a6a512b39469b8afd25ae587c99ba@sap.com>
 <26f26253dd3bd909ae17e729b6286fce7c86f32c.camel@redhat.com>
Message-ID: <3c5196e76e1043ff820c55e61bed83a1@sap.com>

yes, there was the backport review requeset, and there was another one
before that, but both never got pushed to 8u.  There also were 
webrevs for the backport, which didn't apply any more after a while.
So it's good if someone drives this now, finally :)

Best regards,
  Goetz.

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Dienstag, 2. Oktober 2018 15:00
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Erik Joelsson
> <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> os.arch value on ppc64le cause issues with Java tooling
> 
> Hi Goetz,
> 
> I'm a bit confused :-/
> 
> On Tue, 2018-10-02 at 12:39 +0000, Lindenmaier, Goetz wrote:
> > Hi Severin,
> >
> > here for example: http://mail.openjdk.java.net/pipermail/build-dev/2015-
> July/015370.html
> 
> As far as I can see that was relating to the JDK-head fix which wasn't
> available at the time (July vs. pushed in Dec). The original review
> thread was here:
> http://mail.openjdk.java.net/pipermail/build-dev/2015-
> December/016103.html
> 
> JDK-8073139 has been fixed in JDK 9+ since December 14, 2015.
> 
> > While the fix proposed there looks different and the downport was never
> > finished.
> 
> FWIW, this is a review request for the 8u backport :)
> 
> Thanks,
> Severin
> 
> > Best regards,
> >   Goetz.
> >
> >
> >
> > > -----Original Message-----
> > > From: Severin Gehwolf <sgehwolf at redhat.com>
> > > Sent: Dienstag, 2. Oktober 2018 13:09
> > > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Erik Joelsson
> > > <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
> and
> > > os.arch value on ppc64le cause issues with Java tooling
> > >
> > > Hi Goetz,
> > >
> > > On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote:
> > > > Hi,
> > > >
> > > > I'm fine with this.
> > >
> > > Thanks for the review!
> > >
> > > > If I remember correctly, this was proposed before but
> > > > never pushed in the end.
> > >
> > > Interesting.
> > >
> > > > Did you test this on ppc64 be, too?
> > >
> > > I have not. Will do so, though.
> > >
> > > Thanks,
> > > Severin
> > >
> > > > Best regards,
> > > >   Goetz.
> > > >
> > > > > -----Original Message-----
> > > > > From: ppc-aix-port-dev <ppc-aix-port-dev-
> bounces at openjdk.java.net>
> > >
> > > On
> > > > > Behalf Of Severin Gehwolf
> > > > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > > > To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > > > > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > > > > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch
> directory
> > >
> > > and
> > > > > os.arch value on ppc64le cause issues with Java tooling
> > > > >
> > > > > Hi,
> > > > >
> > > > > Pinging PPC porters. Does this look reasonable to you?
> > > > >
> > > > > Thanks,
> > > > > Severin
> > > > >
> > > > >
> > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > > > > > Build changes look ok to me.
> > > > > >
> > > > > > /Erik
> > > > > >
> > > > > >
> > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Could I please get reviews for this JDK 8 backport which fixes
> some
> > > > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > > > > > would report as "ppc64" via os.arch system property which breaks
> > > > > > > tooling such as maven in as much as if some dependency needs
> > >
> > > native
> > > > > > > libraries it would download BE binaries where it actually should
> > > > > > > download LE binaries. Example for os.arch/java.library.path:
> > > > > > >
> > > > > > > pre:
> > > > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > > > > > java.library.path =
> > > > >
> > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > > > os.arch = ppc64
> > > > > > >
> > > > > > > post:
> > > > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > > > > > java.library.path =
> > > > >
> > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > > > os.arch = ppc64le
> > > > > > >
> > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > > > >
> > > > > 8073139/jdk8/01/
> > > > > > >
> > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-
> port-
> > >
> > > dev
> > > > > > > for JDK/hotspot changes.
> > > > > > >
> > > > > > > This backport should only have minor differences to the changes
> in
> > >
> > > JDK
> > > > > > > 11. We have been using similar patches in Fedora for months.
> > >
> > > Thoughts?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Severin
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >


From gromero at linux.vnet.ibm.com  Tue Oct  2 13:42:07 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 2 Oct 2018 10:42:07 -0300
Subject: [8u] RFR for backport of JDK-8164920: ppc: enhancement of CRC32
 intrinsic to jdk8u-dev (v3)
In-Reply-To: <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com>
References: <31e036a0-a7b7-70f2-422f-addd4049436f@linux.vnet.ibm.com>
 <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com>
Message-ID: <cfdce7bf-3d03-791e-41ec-ddd7320d0741@linux.vnet.ibm.com>

Hi,

On 09/25/2018 03:29 PM, Gustavo Romero wrote:
> Hi,
> 
> Maybe I please get reviews for the following changes (v2)?
> 
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8131048/
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8164920/
> 
> Change JDK-8131048 is a dependency to backport JDK-8164920 to 8u.
> 
> Goetz reviewed the first version of this backport and pointed out necessary
> changes and fixes that are present in this v2. Thank you, Goetz.
> 
> There is no code change except to adapt the file paths, to add has_vpmsumb()
> feature detection, and to adapt the signature before doing the runtime call
> to CRC32 intrinsic by casting T_INTs as T_LONGs, because PPC64
> c_calling_convention() requires T_LONGs on 8u, otherwise a proper assert()
> for that is hit.

Additional testing of v2 has found that the connection of CRC32 update method
for ByteBuffers to its intrinsic was missing in the Interpreter:


diff -r a9bebb701e31 src/cpu/ppc/vm/templateInterpreter_ppc.cpp
--- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp        Mon Sep 24 17:18:38 2018 -0400
+++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp        Sun Sep 30 21:58:58 2018 -0400
@@ -1327,9 +1327,12 @@
    case Interpreter::java_lang_math_exp     : entry_point = ((InterpreterGenerator*) this)->generate_math_entry(kind);    break;
    case Interpreter::java_lang_ref_reference_get
                                             : entry_point = ((InterpreterGenerator*)this)->generate_Reference_get_entry(); break;
-  case Interpreter::java_util_zip_CRC32_update  : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_update_entry(); break;
-  case Interpreter::java_util_zip_CRC32_updateBytes : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_updateBytes_entry(kind); break;
-  case Interpreter::java_util_zip_CRC32_updateByteBuffer : break;
+  case Interpreter::java_util_zip_CRC32_update
+                                           : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_update_entry(); break;
+  case Interpreter::java_util_zip_CRC32_updateBytes
+                                           : // fall thru
+  case Interpreter::java_util_zip_CRC32_updateByteBuffer
+                                           : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_updateBytes_entry(kind); break;
    default                                  : ShouldNotReachHere();                                                       break;
    }


Please find v3 which fixes that issue in:

http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/
http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/

Thank you.


Best regards,
Gustavo


From goetz.lindenmaier at sap.com  Tue Oct  2 14:03:09 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 2 Oct 2018 14:03:09 +0000
Subject: [8u] RFR for backport of JDK-8164920: ppc: enhancement of CRC32
 intrinsic to jdk8u-dev (v3)
In-Reply-To: <cfdce7bf-3d03-791e-41ec-ddd7320d0741@linux.vnet.ibm.com>
References: <31e036a0-a7b7-70f2-422f-addd4049436f@linux.vnet.ibm.com>
 <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com>
 <cfdce7bf-3d03-791e-41ec-ddd7320d0741@linux.vnet.ibm.com>
Message-ID: <5b1dbfc516844d519205dd1286a98a9a@sap.com>

Hi Gustavo, 

Your change looks good. 
I ran build and tests on aix and linux ppc64 be which are fine.

Best regards,
  Goetz.


> -----Original Message-----
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Dienstag, 2. Oktober 2018 15:42
> To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Cc: ppc-aix-port-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Doerr, Martin <martin.doerr at sap.com>
> Subject: Re: [8u] RFR for backport of JDK-8164920: ppc: enhancement of
> CRC32 intrinsic to jdk8u-dev (v3)
> 
> Hi,
> 
> On 09/25/2018 03:29 PM, Gustavo Romero wrote:
> > Hi,
> >
> > Maybe I please get reviews for the following changes (v2)?
> >
> > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8131048/
> > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8164920/
> >
> > Change JDK-8131048 is a dependency to backport JDK-8164920 to 8u.
> >
> > Goetz reviewed the first version of this backport and pointed out
> necessary
> > changes and fixes that are present in this v2. Thank you, Goetz.
> >
> > There is no code change except to adapt the file paths, to add
> has_vpmsumb()
> > feature detection, and to adapt the signature before doing the runtime call
> > to CRC32 intrinsic by casting T_INTs as T_LONGs, because PPC64
> > c_calling_convention() requires T_LONGs on 8u, otherwise a proper
> assert()
> > for that is hit.
> 
> Additional testing of v2 has found that the connection of CRC32 update
> method
> for ByteBuffers to its intrinsic was missing in the Interpreter:
> 
> 
> diff -r a9bebb701e31 src/cpu/ppc/vm/templateInterpreter_ppc.cpp
> --- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp        Mon Sep 24 17:18:38
> 2018 -0400
> +++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp        Sun Sep 30 21:58:58
> 2018 -0400
> @@ -1327,9 +1327,12 @@
>     case Interpreter::java_lang_math_exp     : entry_point =
> ((InterpreterGenerator*) this)->generate_math_entry(kind);    break;
>     case Interpreter::java_lang_ref_reference_get
>                                              : entry_point = ((InterpreterGenerator*)this)-
> >generate_Reference_get_entry(); break;
> -  case Interpreter::java_util_zip_CRC32_update  : entry_point =
> ((InterpreterGenerator*)this)->generate_CRC32_update_entry(); break;
> -  case Interpreter::java_util_zip_CRC32_updateBytes : entry_point =
> ((InterpreterGenerator*)this)->generate_CRC32_updateBytes_entry(kind);
> break;
> -  case Interpreter::java_util_zip_CRC32_updateByteBuffer : break;
> +  case Interpreter::java_util_zip_CRC32_update
> +                                           : entry_point = ((InterpreterGenerator*)this)-
> >generate_CRC32_update_entry(); break;
> +  case Interpreter::java_util_zip_CRC32_updateBytes
> +                                           : // fall thru
> +  case Interpreter::java_util_zip_CRC32_updateByteBuffer
> +                                           : entry_point = ((InterpreterGenerator*)this)-
> >generate_CRC32_updateBytes_entry(kind); break;
>     default                                  : ShouldNotReachHere();
> break;
>     }
> 
> 
> Please find v3 which fixes that issue in:
> 
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/
> 
> Thank you.
> 
> 
> Best regards,
> Gustavo


From volker.simonis at gmail.com  Thu Oct  4 08:35:06 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 4 Oct 2018 11:35:06 +0300
Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features
In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com>
References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com>
Message-ID: <CA+3eh13vqvCCa5FMf+w_W0Rj4UiDdAVQtBqKZYcUvBFyrikTmw@mail.gmail.com>

Hi Tim, Jeff,

Kim has assembled a quite detailed list of new C++ features intended for
use in HotSpot/OpenJDK (with links to the corresponding C++ standard)

https://bugs.openjdk.java.net/browse/JDK-8208089

Could you please provide a summary of which of these features are already
available since which version of xlC for AIX and potentially escalate the
implementation of the missing features within IBM?s xlC on AIX team.

Thank you and best regards,
Volker


Kim Barrett <kim.barrett at oracle.com> schrieb am Mi. 3. Okt. 2018 um 22:13:

> I've submitted a JEP for
>
> (1) enabling the use of C++14 Language Features when building the JDK,
>
> (2) define a process for deciding and documenting which new features
> can be used or are forbidden in HotSpot code,
>
> (3) provide an initial list of permitted and forbidden new features.
>
> https://bugs.openjdk.java.net/browse/JDK-8208089
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181004/177f45d6/attachment.html>

From sgehwolf at redhat.com  Thu Oct  4 14:40:01 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 04 Oct 2018 16:40:01 +0200
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
 and os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <666987d08f324a0c94208c6cca403214@sap.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
 <666987d08f324a0c94208c6cca403214@sap.com>
Message-ID: <f66ac7ea98d48b0ea13430d7b5381db55bc53153.camel@redhat.com>

Hi Goetz,

On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote:
[...]
> Did you test this on ppc64 be, too?  

I've tested this patch on PPC64 BE Linux now too. There is no change
(as expected):

$ ./jdk8-ppc64be-after/bin/java TestProperty
os.arch == ppc64
java.library.path == /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
$ ./jdk8-ppc64be-before/bin/java TestProperty
os.arch == ppc64
java.library.path == /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib

Thanks,
Severin

> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On
> > Behalf Of Severin Gehwolf
> > Sent: Dienstag, 2. Oktober 2018 12:34
> > To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> > os.arch value on ppc64le cause issues with Java tooling
> > 
> > Hi,
> > 
> > Pinging PPC porters. Does this look reasonable to you?
> > 
> > Thanks,
> > Severin
> > 
> > 
> > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > > Build changes look ok to me.
> > > 
> > > /Erik
> > > 
> > > 
> > > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Could I please get reviews for this JDK 8 backport which fixes some
> > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > > would report as "ppc64" via os.arch system property which breaks
> > > > tooling such as maven in as much as if some dependency needs native
> > > > libraries it would download BE binaries where it actually should
> > > > download LE binaries. Example for os.arch/java.library.path:
> > > > 
> > > > pre:
> > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > > java.library.path =
> > 
> > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > > os.arch = ppc64
> > > > 
> > > > post:
> > > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > > java.library.path =
> > 
> > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > > os.arch = ppc64le
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > 
> > 8073139/jdk8/01/
> > > > 
> > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev
> > > > for JDK/hotspot changes.
> > > > 
> > > > This backport should only have minor differences to the changes in JDK
> > > > 11. We have been using similar patches in Fedora for months. Thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > 
> > > 
> 
> 


From goetz.lindenmaier at sap.com  Thu Oct  4 14:47:47 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 4 Oct 2018 14:47:47 +0000
Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
 os.arch value on ppc64le cause issues with Java tooling
In-Reply-To: <f66ac7ea98d48b0ea13430d7b5381db55bc53153.camel@redhat.com>
References: <e535dccf4589d677c50e1cb2ed01a4507afcd9a2.camel@redhat.com>
 <af331112-a369-8d82-3274-fcb8a189705d@oracle.com>
 <c0c5dd1ff7c19429228f45e72d812c4e971211fc.camel@redhat.com>
 <666987d08f324a0c94208c6cca403214@sap.com>
 <f66ac7ea98d48b0ea13430d7b5381db55bc53153.camel@redhat.com>
Message-ID: <bd3009efb3ba47df82702859a97ce88d@sap.com>

Thanks!

I'm fine for this to go to 8.

Best regards,
  Goetz.

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Donnerstag, 4. Oktober 2018 16:40
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Erik Joelsson
> <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and
> os.arch value on ppc64le cause issues with Java tooling
> 
> Hi Goetz,
> 
> On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote:
> [...]
> > Did you test this on ppc64 be, too?
> 
> I've tested this patch on PPC64 BE Linux now too. There is no change
> (as expected):
> 
> $ ./jdk8-ppc64be-after/bin/java TestProperty
> os.arch == ppc64
> java.library.path ==
> /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> $ ./jdk8-ppc64be-before/bin/java TestProperty
> os.arch == ppc64
> java.library.path ==
> /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> 
> Thanks,
> Severin
> 
> > Best regards,
> >   Goetz.
> >
> > > -----Original Message-----
> > > From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Severin Gehwolf
> > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > To: Erik Joelsson <erik.joelsson at oracle.com>; hotspot-dev <hotspot-
> > > dev at openjdk.java.net>; ppc-aix-port-dev <ppc-aix-port-
> > > dev at openjdk.java.net>; build-dev <build-dev at openjdk.java.net>
> > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory
> and
> > > os.arch value on ppc64le cause issues with Java tooling
> > >
> > > Hi,
> > >
> > > Pinging PPC porters. Does this look reasonable to you?
> > >
> > > Thanks,
> > > Severin
> > >
> > >
> > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote:
> > > > Build changes look ok to me.
> > > >
> > > > /Erik
> > > >
> > > >
> > > > On 2018-09-26 04:26, Severin Gehwolf wrote:
> > > > > Hi,
> > > > >
> > > > > Could I please get reviews for this JDK 8 backport which fixes some
> > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build
> > > > > would report as "ppc64" via os.arch system property which breaks
> > > > > tooling such as maven in as much as if some dependency needs
> native
> > > > > libraries it would download BE binaries where it actually should
> > > > > download LE binaries. Example for os.arch/java.library.path:
> > > > >
> > > > > pre:
> > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty
> > > > > java.library.path =
> > >
> > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > os.arch = ppc64
> > > > >
> > > > > post:
> > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty
> > > > > java.library.path =
> > >
> > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> > > > > os.arch = ppc64le
> > > > >
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139
> > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > >
> > > 8073139/jdk8/01/
> > > > >
> > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-
> dev
> > > > > for JDK/hotspot changes.
> > > > >
> > > > > This backport should only have minor differences to the changes in
> JDK
> > > > > 11. We have been using similar patches in Fedora for months.
> Thoughts?
> > > > >
> > > > > Thanks,
> > > > > Severin
> > > > >
> > > >
> > > >
> >
> >


From kim.barrett at oracle.com  Thu Oct  4 21:53:27 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 4 Oct 2018 17:53:27 -0400
Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features
In-Reply-To: <CA+3eh13vqvCCa5FMf+w_W0Rj4UiDdAVQtBqKZYcUvBFyrikTmw@mail.gmail.com>
References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com>
 <CA+3eh13vqvCCa5FMf+w_W0Rj4UiDdAVQtBqKZYcUvBFyrikTmw@mail.gmail.com>
Message-ID: <3C557F9A-82B7-4941-850B-EA2D0ED44EDA@oracle.com>

> On Oct 4, 2018, at 4:35 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Tim, Jeff,
> 
> Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard)
> 
> https://bugs.openjdk.java.net/browse/JDK-8208089

Note that this list is intended as a starting point.  The JEP also describes a process for adding
to the list of permitted features, and I anticipate that process will be used.  There are several
that I personally think would be good to add (perhaps with some limits or restrictions), but that
I think may involve more detailed discussion. And other folks may have their favorite must have
feature(s) that didn?t seem to me to be needed in this initial seed list.




From goetz.lindenmaier at sap.com  Mon Oct  8 16:58:05 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 8 Oct 2018 16:58:05 +0000
Subject: Open ppc/s390/aix issues
Message-ID: <8c6b8ea2a811401eb7559ab68e821bd4@sap.com>

Hi,

We are now working on the ppc/s390/aix ports for quite some years.
With the release of jdk11 we delivered a very comprehensive and well 
maintained port I think. For example, the jdk and hotspot jtreg tests
can be run quite stable on these platforms. 

I filed bugs for all the remaining issues we see, at least in the 
test setup we run at SAP.

Everybody is invited to join in and fix these few finally :)

8207404: MulticastSocket tests failing on Aix
https://bugs.openjdk.java.net/browse/JDK-8207404
8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
https://bugs.openjdk.java.net/browse/JDK-8030957
8211769: Port Dtrace support to ppc.
https://bugs.openjdk.java.net/browse/JDK-8211769
8211771: Port Dtrace support to s390x.
https://bugs.openjdk.java.net/browse/JDK-8211771
8211767: jtreg: Some SA tests are failing on PPC64
https://bugs.openjdk.java.net/browse/JDK-8211767
8211844: [aix] ProcessBuilder: Piping between created processes does not work.
https://bugs.openjdk.java.net/browse/JDK-8211844
8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected"
https://bugs.openjdk.java.net/browse/JDK-8211847
8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fais: read times out
https://bugs.openjdk.java.net/browse/JDK-8211854
8211851: /java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix)
https://bugs.openjdk.java.net/browse/JDK-8211851
8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation error
https://bugs.openjdk.java.net/browse/JDK-8211841

Best regards,
  Goetz.


From HORIE at jp.ibm.com  Tue Oct  9 07:11:26 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Tue, 9 Oct 2018 16:11:26 +0900
Subject: RFR: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default
Message-ID: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>



Dear all,

Would you please review this simple change?
Bug: https://bugs.openjdk.java.net/browse/JDK-8211908
Webrev: http://cr.openjdk.java.net/~mhorie/8211908/webrev.00

Since PPC64 supports SLP with VSX, we can have the benefit from enabled
SuperWordLoopUnrollAnalysis on PPC64.

In the attached micro benchmarks, performance improved by 1.7x at maximum.
In SPECjvm2008, the score improved by a couple of % in xml.validation and
scimark.lu.large

(See attached file: microbench_slp.tar.gz)

Best regards,
--
Michihiro,
IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181009/e9aa6119/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: microbench_slp.tar.gz
Type: application/octet-stream
Size: 2252 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181009/e9aa6119/microbench_slp.tar.gz>

From gromero at linux.vnet.ibm.com  Tue Oct  9 13:20:11 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 9 Oct 2018 10:20:11 -0300
Subject: Open ppc/s390/aix issues
In-Reply-To: <8c6b8ea2a811401eb7559ab68e821bd4@sap.com>
References: <8c6b8ea2a811401eb7559ab68e821bd4@sap.com>
Message-ID: <b872bc35-93db-3e50-0e69-c8596764a68e@linux.vnet.ibm.com>

Hi Goetz,

On 10/08/2018 01:58 PM, Lindenmaier, Goetz wrote:
> Hi,
> 
> We are now working on the ppc/s390/aix ports for quite some years.
> With the release of jdk11 we delivered a very comprehensive and well
> maintained port I think. For example, the jdk and hotspot jtreg tests
> can be run quite stable on these platforms.
> 
> I filed bugs for all the remaining issues we see, at least in the
> test setup we run at SAP.
> 
> Everybody is invited to join in and fix these few finally :)

Thanks for tracking it.

I'll return to hunt the remaining SA failures you pointed out.

Hope to update on that soon.


Best regards,
Gustavo

> 8207404: MulticastSocket tests failing on Aix
> https://bugs.openjdk.java.net/browse/JDK-8207404
> 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
> https://bugs.openjdk.java.net/browse/JDK-8030957
> 8211769: Port Dtrace support to ppc.
> https://bugs.openjdk.java.net/browse/JDK-8211769
> 8211771: Port Dtrace support to s390x.
> https://bugs.openjdk.java.net/browse/JDK-8211771
> 8211767: jtreg: Some SA tests are failing on PPC64
> https://bugs.openjdk.java.net/browse/JDK-8211767
> 8211844: [aix] ProcessBuilder: Piping between created processes does not work.
> https://bugs.openjdk.java.net/browse/JDK-8211844
> 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected"
> https://bugs.openjdk.java.net/browse/JDK-8211847
> 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fais: read times out
> https://bugs.openjdk.java.net/browse/JDK-8211854
> 8211851: /java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix)
> https://bugs.openjdk.java.net/browse/JDK-8211851
> 8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation error
> https://bugs.openjdk.java.net/browse/JDK-8211841
> 
> Best regards,
>    Goetz.
> 


From martin.doerr at sap.com  Tue Oct  9 13:31:42 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 9 Oct 2018 13:31:42 +0000
Subject: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default
In-Reply-To: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>
References: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>
Message-ID: <1ada68961f734e8082d467482682f8a0@sap.com>

Hi Michihiro,

looks good. Thanks for doing some performance measurements.

The change itself could be considered as trivial, but the impact may be significant, so I'd appreciate a 2nd review.

We already tested this flag in our nightly tests for a few weeks and didn't see any issues. It's also enabled on other platforms which use vector instructions so I think we should use it on PPC, too.

Best regards,
Martin


From: Michihiro Horie <HORIE at jp.ibm.com>
Sent: Dienstag, 9. Oktober 2018 09:11
To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
Cc: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Gustavo Romero <gromero at linux.vnet.ibm.com>
Subject: RFR: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default


Dear all,

Would you please review this simple change?
Bug: https://bugs.openjdk.java.net/browse/JDK-8211908
Webrev: http://cr.openjdk.java.net/~mhorie/8211908/webrev.00

Since PPC64 supports SLP with VSX, we can have the benefit from enabled SuperWordLoopUnrollAnalysis on PPC64.

In the attached micro benchmarks, performance improved by 1.7x at maximum. In SPECjvm2008, the score improved by a couple of % in xml.validation and scimark.lu.large

(See attached file: microbench_slp.tar.gz)

Best regards,
--
Michihiro,
IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181009/47bb06e8/attachment.html>

From HORIE at jp.ibm.com  Tue Oct  9 16:08:10 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Wed, 10 Oct 2018 01:08:10 +0900
Subject: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default
In-Reply-To: <1ada68961f734e8082d467482682f8a0@sap.com>
References: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>
 <1ada68961f734e8082d467482682f8a0@sap.com>
Message-ID: <OF178B2C90.9DBD633B-ON00258321.0057B839-49258321.0058A3AE@notes.na.collabserv.com>


Hi Martin,

> looks good. Thanks for doing some performance measurements.
>
> The change itself could be considered as trivial, but the impact may be
significant, so I?d appreciate a 2nd review.
>
> We already tested this flag in our nightly tests for a few weeks and
didn?t see any issues. It?s also enabled on other platforms which use
vector instructions so I think we should use it on PPC, too.
Thank a lot for your review!


Best regards,
--
Michihiro,
IBM Research - Tokyo



From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>, hotspot compiler
            <hotspot-compiler-dev at openjdk.java.net>,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>
Cc:	"Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, Gustavo
            Romero <gromero at linux.vnet.ibm.com>
Date:	2018/10/09 22:31
Subject:	RE: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by
            default



Hi Michihiro,

looks good. Thanks for doing some performance measurements.

The change itself could be considered as trivial, but the impact may be
significant, so I?d appreciate a 2nd review.

We already tested this flag in our nightly tests for a few weeks and didn?t
see any issues. It?s also enabled on other platforms which use vector
instructions so I think we should use it on PPC, too.

Best regards,
Martin


From: Michihiro Horie <HORIE at jp.ibm.com>
Sent: Dienstag, 9. Oktober 2018 09:11
To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>;
ppc-aix-port-dev at openjdk.java.net
Cc: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz
<goetz.lindenmaier at sap.com>; Gustavo Romero <gromero at linux.vnet.ibm.com>
Subject: RFR: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default



Dear all,

Would you please review this simple change?
Bug: https://bugs.openjdk.java.net/browse/JDK-8211908
Webrev: http://cr.openjdk.java.net/~mhorie/8211908/webrev.00

Since PPC64 supports SLP with VSX, we can have the benefit from enabled
SuperWordLoopUnrollAnalysis on PPC64.

In the attached micro benchmarks, performance improved by 1.7x at maximum.
In SPECjvm2008, the score improved by a couple of % in xml.validation and
scimark.lu.large

(See attached file: microbench_slp.tar.gz)

Best regards,
--
Michihiro,
IBM Research - Tokyo





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181010/5770bf0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181010/5770bf0f/graycol.gif>

From goetz.lindenmaier at sap.com  Wed Oct 10 07:42:06 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 10 Oct 2018 07:42:06 +0000
Subject: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default
In-Reply-To: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>
References: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>
Message-ID: <2ea8652b2815445e9ce542d1e8b7648d@sap.com>

Hi Michihiro, 

the change looks good. 

We ran all our tests of jdk11u with the change, they are quite comprehensive.
This greatly reduces the chance of hidden error like spilling of vector registers 
etc.

Best regards,
  Goetz.

> -----Original Message-----
> From: Michihiro Horie <HORIE at jp.ibm.com>
> Sent: Dienstag, 9. Oktober 2018 09:11
> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; ppc-aix-
> port-dev at openjdk.java.net
> Cc: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Gustavo Romero
> <gromero at linux.vnet.ibm.com>
> Subject: RFR: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by
> default
> 
> Dear all,
> 
> Would you please review this simple change?
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211908
> Webrev: http://cr.openjdk.java.net/~mhorie/8211908/webrev.00
> 
> Since PPC64 supports SLP with VSX, we can have the benefit from enabled
> SuperWordLoopUnrollAnalysis on PPC64.
> 
> In the attached micro benchmarks, performance improved by 1.7x at
> maximum. In SPECjvm2008, the score improved by a couple of % in
> xml.validation and scimark.lu.large
> 
> (See attached file: microbench_slp.tar.gz)
> 
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo


From HORIE at jp.ibm.com  Wed Oct 10 08:11:07 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Wed, 10 Oct 2018 17:11:07 +0900
Subject: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default
In-Reply-To: <2ea8652b2815445e9ce542d1e8b7648d@sap.com>
References: <OF0A3D3478.2B464BFC-ON00258321.0023216A-49258321.00277FEF@notes.na.collabserv.com>
 <2ea8652b2815445e9ce542d1e8b7648d@sap.com>
Message-ID: <OF1406AC8B.E8DE82A0-ON00258322.002B221D-49258322.002CF694@notes.na.collabserv.com>


Hi Goetz,

> the change looks good.
>
> We ran all our tests of jdk11u with the change, they are quite
comprehensive.
> This greatly reduces the chance of hidden error like spilling of vector
registers
> etc.
Thanks a lot, Goetz! I am grateful for your tests, which sound quite
helpful to find corner cases.


Best regards,
--
Michihiro,
IBM Research - Tokyo



From:	"Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>, hotspot compiler
            <hotspot-compiler-dev at openjdk.java.net>,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>
Cc:	"Doerr, Martin" <martin.doerr at sap.com>, Gustavo Romero
            <gromero at linux.vnet.ibm.com>
Date:	2018/10/10 16:42
Subject:	RE: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by
            default



Hi Michihiro,

the change looks good.

We ran all our tests of jdk11u with the change, they are quite
comprehensive.
This greatly reduces the chance of hidden error like spilling of vector
registers
etc.

Best regards,
  Goetz.

> -----Original Message-----
> From: Michihiro Horie <HORIE at jp.ibm.com>
> Sent: Dienstag, 9. Oktober 2018 09:11
> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; ppc-aix-
> port-dev at openjdk.java.net
> Cc: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Gustavo Romero
> <gromero at linux.vnet.ibm.com>
> Subject: RFR: 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by
> default
>
> Dear all,
>
> Would you please review this simple change?
> Bug:
https://bugs.openjdk.java.net/browse/JDK-8211908

> Webrev:
http://cr.openjdk.java.net/~mhorie/8211908/webrev.00

>
> Since PPC64 supports SLP with VSX, we can have the benefit from enabled
> SuperWordLoopUnrollAnalysis on PPC64.
>
> In the attached micro benchmarks, performance improved by 1.7x at
> maximum. In SPECjvm2008, the score improved by a couple of % in
> xml.validation and scimark.lu.large
>
> (See attached file: microbench_slp.tar.gz)
>
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181010/ece830b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20181010/ece830b7/graycol.gif>

From gromero at linux.vnet.ibm.com  Tue Oct 16 21:09:45 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 16 Oct 2018 18:09:45 -0300
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
Message-ID: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>

Hi,

Could the following small change be reviewed please?

Bug   : https://bugs.openjdk.java.net/browse/JDK-8212481
Webrev: http://cr.openjdk.java.net/~gromero/8212481/v1/

It adds 'darn' instruction introduced with POWER9 CPUs to the Macroassembler and
uses it to set PowerArchitecturePPC64 to POWER9 when the instruction is
available on the CPU so it can be used in the future by any POWER9-specific
JVM code or by any JVM code specifically dependent on the 'darn' instruction,
using VM_Version::has_darn().

It was checked on POWER9 as the following:

gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ lscpu
Architecture:        ppc64le
Byte Order:          Little Endian
CPU(s):              176
On-line CPU(s) list: 0-175
Thread(s) per core:  4
Core(s) per socket:  22
Socket(s):           2
NUMA node(s):        8
Model:               2.2 (pvr 004e 1202)
Model name:          POWER9 (raw), altivec supported
CPU max MHz:         2800.0000
CPU min MHz:         2300.0000
L1d cache:           32K
L1i cache:           32K
L2 cache:            512K
L3 cache:            10240K
NUMA node0 CPU(s):   0-87
NUMA node8 CPU(s):   88-175
NUMA node250 CPU(s):
NUMA node251 CPU(s):
NUMA node252 CPU(s):
NUMA node253 CPU(s):
NUMA node254 CPU(s):
NUMA node255 CPU(s):
gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ LD_SHOW_AUXV=1 /bin/true | egrep "HWCAP|PLATFORM"
AT_HWCAP:        true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
AT_HWCAP2:       darn ieee128 arch_3_00 vcrypto tar isel ebb dscr arch_2_07
AT_PLATFORM:     power9
AT_BASE_PLATFORM:power9
gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ ./java -XX:+Verbose -version
dscr value was 0x10
Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha darn L1_data_cache_line_size=128

openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9)
OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9, mixed mode, sharing)


It was also checked on POWER8 and no regression was observed:

gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                80
On-line CPU(s) list:   0-79
Thread(s) per core:    8
Core(s) per socket:    10
Socket(s):             1
NUMA node(s):          1
Model:                 2.1 (pvr 004b 0201)
Model name:            POWER8 (architected), altivec supported
Hypervisor vendor:     horizontal
Virtualization type:   full
L1d cache:             64K
L1i cache:             32K
NUMA node0 CPU(s):     0-79
gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ LD_SHOW_AUXV=1 /bin/true | egrep "HWCAP|PLATFORM"
AT_HWCAP:        archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
AT_HWCAP2:       htm-nosc vcrypto tar isel ebb dscr htm arch_2_07
AT_PLATFORM:     power8
AT_BASE_PLATFORM:power8
gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ ./java -XX:+Verbose -version
dscr value was 0x0
Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha rtm L1_data_cache_line_size=128

openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9)
OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9, mixed mode, sharing)


Thank you.

Best regards,
Gustavo


From takiguc at linux.vnet.ibm.com  Fri Oct 19 01:59:38 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 19 Oct 2018 10:59:38 +0900
Subject: Open ppc/s390/aix issues
In-Reply-To: <8c6b8ea2a811401eb7559ab68e821bd4@sap.com>
References: <8c6b8ea2a811401eb7559ab68e821bd4@sap.com>
Message-ID: <d959f885d63695659c9485ca11f95815@linux.vnet.ibm.com>

Hello Goetz.
> 8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation 
> error
> https://bugs.openjdk.java.net/browse/JDK-8211841
I'll handle it on Nov.
But I'd like to confirm one thing.
You may know this compilation error came from jigsaw (modularity 
feature).
I may rewrite the some of the parts by using reflection feature.
Do you think it's acceptable solution ?

Thanks,
Ichiroh Takiguchi

On 2018-10-09 01:58, Lindenmaier, Goetz wrote:
> Hi,
> 
> We are now working on the ppc/s390/aix ports for quite some years.
> With the release of jdk11 we delivered a very comprehensive and well
> maintained port I think. For example, the jdk and hotspot jtreg tests
> can be run quite stable on these platforms.
> 
> I filed bugs for all the remaining issues we see, at least in the
> test setup we run at SAP.
> 
> Everybody is invited to join in and fix these few finally :)
> 
> 8207404: MulticastSocket tests failing on Aix
> https://bugs.openjdk.java.net/browse/JDK-8207404
> 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and
> .getProcessCpuLoad() on AIX
> https://bugs.openjdk.java.net/browse/JDK-8030957
> 8211769: Port Dtrace support to ppc.
> https://bugs.openjdk.java.net/browse/JDK-8211769
> 8211771: Port Dtrace support to s390x.
> https://bugs.openjdk.java.net/browse/JDK-8211771
> 8211767: jtreg: Some SA tests are failing on PPC64
> https://bugs.openjdk.java.net/browse/JDK-8211767
> 8211844: [aix] ProcessBuilder: Piping between created processes does 
> not work.
> https://bugs.openjdk.java.net/browse/JDK-8211844
> 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported
> cputime less than expected"
> https://bugs.openjdk.java.net/browse/JDK-8211847
> 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fais:
> read times out
> https://bugs.openjdk.java.net/browse/JDK-8211854
> 8211851:
> /java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times
> out (aix)
> https://bugs.openjdk.java.net/browse/JDK-8211851
> 8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation 
> error
> https://bugs.openjdk.java.net/browse/JDK-8211841
> 
> Best regards,
>   Goetz.


From martin.doerr at sap.com  Mon Oct 22 10:07:00 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 22 Oct 2018 10:07:00 +0000
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
Message-ID: <a480a54e15354e939d7e6a9397a67747@sap.com>

Hi Gustavo,

thanks for contributing. I have some minor remarks.

I'm not sure if it's good to have L=1 hard coded in the assembler instruction, but I think it's ok for now.
(One could also pass L as parameter with default value 1.)

I think it would be nice to have the capability bit usages in the same order at all places in the source code. We could add a comment line like "rtm is determined by OS" where it was omitted. An empty line before has_mtfprd() would be good because it's just an alias. Having them everywhere as one block in the same order helps avoiding confusion.

Besides this, the change looks good.

Best regards,
Martin


-----Original Message-----
From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On Behalf Of Gustavo Romero
Sent: Dienstag, 16. Oktober 2018 23:10
To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection

Hi,

Could the following small change be reviewed please?

Bug   : https://bugs.openjdk.java.net/browse/JDK-8212481
Webrev: http://cr.openjdk.java.net/~gromero/8212481/v1/

It adds 'darn' instruction introduced with POWER9 CPUs to the Macroassembler and
uses it to set PowerArchitecturePPC64 to POWER9 when the instruction is
available on the CPU so it can be used in the future by any POWER9-specific
JVM code or by any JVM code specifically dependent on the 'darn' instruction,
using VM_Version::has_darn().

It was checked on POWER9 as the following:

gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ lscpu
Architecture:        ppc64le
Byte Order:          Little Endian
CPU(s):              176
On-line CPU(s) list: 0-175
Thread(s) per core:  4
Core(s) per socket:  22
Socket(s):           2
NUMA node(s):        8
Model:               2.2 (pvr 004e 1202)
Model name:          POWER9 (raw), altivec supported
CPU max MHz:         2800.0000
CPU min MHz:         2300.0000
L1d cache:           32K
L1i cache:           32K
L2 cache:            512K
L3 cache:            10240K
NUMA node0 CPU(s):   0-87
NUMA node8 CPU(s):   88-175
NUMA node250 CPU(s):
NUMA node251 CPU(s):
NUMA node252 CPU(s):
NUMA node253 CPU(s):
NUMA node254 CPU(s):
NUMA node255 CPU(s):
gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ LD_SHOW_AUXV=1 /bin/true | egrep "HWCAP|PLATFORM"
AT_HWCAP:        true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
AT_HWCAP2:       darn ieee128 arch_3_00 vcrypto tar isel ebb dscr arch_2_07
AT_PLATFORM:     power9
AT_BASE_PLATFORM:power9
gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ ./java -XX:+Verbose -version
dscr value was 0x10
Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha darn L1_data_cache_line_size=128

openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9)
OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9, mixed mode, sharing)


It was also checked on POWER8 and no regression was observed:

gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                80
On-line CPU(s) list:   0-79
Thread(s) per core:    8
Core(s) per socket:    10
Socket(s):             1
NUMA node(s):          1
Model:                 2.1 (pvr 004b 0201)
Model name:            POWER8 (architected), altivec supported
Hypervisor vendor:     horizontal
Virtualization type:   full
L1d cache:             64K
L1i cache:             32K
NUMA node0 CPU(s):     0-79
gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ LD_SHOW_AUXV=1 /bin/true | egrep "HWCAP|PLATFORM"
AT_HWCAP:        archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
AT_HWCAP2:       htm-nosc vcrypto tar isel ebb dscr htm arch_2_07
AT_PLATFORM:     power8
AT_BASE_PLATFORM:power8
gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ ./java -XX:+Verbose -version
dscr value was 0x0
Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha rtm L1_data_cache_line_size=128

openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9)
OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9, mixed mode, sharing)


Thank you.

Best regards,
Gustavo


From gromero at linux.vnet.ibm.com  Tue Oct 23 14:57:13 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 23 Oct 2018 11:57:13 -0300
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <a480a54e15354e939d7e6a9397a67747@sap.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
Message-ID: <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>

Hi Martin,

On 10/22/2018 07:07 AM, Doerr, Martin wrote:
> Hi Gustavo,
> 
> thanks for contributing. I have some minor remarks.
Thanks a lot for reviewing it.


> I'm not sure if it's good to have L=1 hard coded in the assembler instruction, but I think it's ok for now.
> (One could also pass L as parameter with default value 1.)

I agree. So, if you don't mind, to reduce any future rework on that
I removed the hardcoded L=1 and now it's just a default. I introduced
l14() function that matches two bits in the proper field as I don't
see any collision with any other one bit field at the same position
(bit 14).


> I think it would be nice to have the capability bit usages in the same order at all places in the source code. We could add a comment line like "rtm is determined by OS" where it was omitted. An empty line before has_mtfprd() would be good because it's just an alias. Having them everywhere as one block in the same order helps avoiding confusion.

Sure. I think that the confusion came from the fact that I split
the "CPU instruction support" section in two by adding a new one
called "OS instruction support" when I refactored the TM detection.
Given a second thought tho I think it's not necessary, so I've put
has_tm() back to the block as you instructed, adding an empty line
before has_mtfprd() as it's an alias, and added the "rtm is deter-
mined by OS" comment were it applies.

v2 webrev:

http://cr.openjdk.java.net/~gromero/8212481/v2/


I just have one question regarding the feature-string. I see
instrumentation for "fsqrts" feature but it's not currently
advertised by the feature-string. On the other hand, ISA info
looks to indicate that fsqrt and fsqrts are not aliases, because:

fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00

so I'm wondering if just for completeness the "fsqrts" feature
should be included in the feature-string. Besides that I don't
see instrumentation to support has_mftgpr(), which is commented
out, thus should we remove it? Like the following:

diff -r c860b03741ab src/hotspot/cpu/ppc/vm_version_ppc.cpp
--- a/src/hotspot/cpu/ppc/vm_version_ppc.cpp    Tue Oct 16 16:26:28 2018 -0400
+++ b/src/hotspot/cpu/ppc/vm_version_ppc.cpp    Tue Oct 23 10:51:22 2018 -0400
@@ -134,12 +134,12 @@
    // Create and print feature-string.
    char buf[(num_features+1) * 16]; // Max 16 chars per feature.
    jio_snprintf(buf, sizeof(buf),
-               "ppc64%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s",
+               "ppc64%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s",
                 (has_fsqrt()   ? " fsqrt"   : ""),
+               (has_fsqrts()  ? " fsqrts"  : ""),
                 (has_isel()    ? " isel"    : ""),
                 (has_lxarxeh() ? " lxarxeh" : ""),
                 (has_cmpb()    ? " cmpb"    : ""),
-               //(has_mftgpr()? " mftgpr"  : ""),
                 (has_popcntb() ? " popcntb" : ""),
                 (has_popcntw() ? " popcntw" : ""),
                 (has_fcfids()  ? " fcfids"  : ""),

Thank you.

Best regards,
Gustavo

> Besides this, the change looks good.
> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On Behalf Of Gustavo Romero
> Sent: Dienstag, 16. Oktober 2018 23:10
> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
> 
> Hi,
> 
> Could the following small change be reviewed please?
> 
> Bug   : https://bugs.openjdk.java.net/browse/JDK-8212481
> Webrev: http://cr.openjdk.java.net/~gromero/8212481/v1/
> 
> It adds 'darn' instruction introduced with POWER9 CPUs to the Macroassembler and
> uses it to set PowerArchitecturePPC64 to POWER9 when the instruction is
> available on the CPU so it can be used in the future by any POWER9-specific
> JVM code or by any JVM code specifically dependent on the 'darn' instruction,
> using VM_Version::has_darn().
> 
> It was checked on POWER9 as the following:
> 
> gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ lscpu
> Architecture:        ppc64le
> Byte Order:          Little Endian
> CPU(s):              176
> On-line CPU(s) list: 0-175
> Thread(s) per core:  4
> Core(s) per socket:  22
> Socket(s):           2
> NUMA node(s):        8
> Model:               2.2 (pvr 004e 1202)
> Model name:          POWER9 (raw), altivec supported
> CPU max MHz:         2800.0000
> CPU min MHz:         2300.0000
> L1d cache:           32K
> L1i cache:           32K
> L2 cache:            512K
> L3 cache:            10240K
> NUMA node0 CPU(s):   0-87
> NUMA node8 CPU(s):   88-175
> NUMA node250 CPU(s):
> NUMA node251 CPU(s):
> NUMA node252 CPU(s):
> NUMA node253 CPU(s):
> NUMA node254 CPU(s):
> NUMA node255 CPU(s):
> gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ LD_SHOW_AUXV=1 /bin/true | egrep "HWCAP|PLATFORM"
> AT_HWCAP:        true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
> AT_HWCAP2:       darn ieee128 arch_3_00 vcrypto tar isel ebb dscr arch_2_07
> AT_PLATFORM:     power9
> AT_BASE_PLATFORM:power9
> gromero at ltc-wspoon3:~/POWER9/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ ./java -XX:+Verbose -version
> dscr value was 0x10
> Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha darn L1_data_cache_line_size=128
> 
> openjdk version "12-internal" 2019-03-19
> OpenJDK Runtime Environment (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9)
> OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9, mixed mode, sharing)
> 
> 
> It was also checked on POWER8 and no regression was observed:
> 
> gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ lscpu
> Architecture:          ppc64le
> Byte Order:            Little Endian
> CPU(s):                80
> On-line CPU(s) list:   0-79
> Thread(s) per core:    8
> Core(s) per socket:    10
> Socket(s):             1
> NUMA node(s):          1
> Model:                 2.1 (pvr 004b 0201)
> Model name:            POWER8 (architected), altivec supported
> Hypervisor vendor:     horizontal
> Virtualization type:   full
> L1d cache:             64K
> L1i cache:             32K
> NUMA node0 CPU(s):     0-79
> gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ LD_SHOW_AUXV=1 /bin/true | egrep "HWCAP|PLATFORM"
> AT_HWCAP:        archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
> AT_HWCAP2:       htm-nosc vcrypto tar isel ebb dscr htm arch_2_07
> AT_PLATFORM:     power8
> AT_BASE_PLATFORM:power8
> gromero at gromero16:~/openjdks/jdk12_tip_f53671e05660+/jvm/openjdk-12-internal/bin$ ./java -XX:+Verbose -version
> dscr value was 0x0
> Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha rtm L1_data_cache_line_size=128
> 
> openjdk version "12-internal" 2019-03-19
> OpenJDK Runtime Environment (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9)
> OpenJDK 64-Bit Server VM (fastdebug build 12-internal+0-f53671e05660.dirty.debug.POWER9, mixed mode, sharing)
> 
> 
> Thank you.
> 
> Best regards,
> Gustavo
> 


From martin.doerr at sap.com  Tue Oct 23 16:51:50 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 23 Oct 2018 16:51:50 +0000
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
Message-ID: <bfcc7eebd666463f96e0210811fd947a@sap.com>

Hi Gustavo,

> I agree. So, if you don't mind, to reduce any future rework on that
> I removed the hardcoded L=1 and now it's just a default. I introduced
> l14() function that matches two bits in the proper field as I don't
> see any collision with any other one bit field at the same position
> (bit 14).
I like it, but the default value needs to get specified in the .hpp file.

> Sure. I think that the confusion came from the fact that I split
> the "CPU instruction support" section in two by adding a new one
> called "OS instruction support" when I refactored the TM detection.
> Given a second thought tho I think it's not necessary, so I've put
> has_tm() back to the block as you instructed, adding an empty line
> before has_mtfprd() as it's an alias, and added the "rtm is deter-
> mined by OS" comment were it applies.
Thanks for cleaning it up.

> I just have one question regarding the feature-string. I see
> instrumentation for "fsqrts" feature but it's not currently
> advertised by the feature-string. On the other hand, ISA info
> looks to indicate that fsqrt and fsqrts are not aliases, because:
> 
> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
> 
> so I'm wondering if just for completeness the "fsqrts" feature
> should be included in the feature-string. Besides that I don't
> see instrumentation to support has_mftgpr(), which is commented
> out, thus should we remove it? Like the following:

This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.

Best regards,
Martin


From gromero at linux.vnet.ibm.com  Tue Oct 23 21:46:14 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 23 Oct 2018 18:46:14 -0300
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <bfcc7eebd666463f96e0210811fd947a@sap.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
Message-ID: <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>

Hi Martin,

Thanks for your comments on fsqrt{,s} and mftgpr opcodes.

On 10/23/2018 01:51 PM, Doerr, Martin wrote:
> Hi Gustavo,
> 
>> I agree. So, if you don't mind, to reduce any future rework on that
>> I removed the hardcoded L=1 and now it's just a default. I introduced
>> l14() function that matches two bits in the proper field as I don't
>> see any collision with any other one bit field at the same position
>> (bit 14).
> I like it, but the default value needs to get specified in the .hpp file.

Fixed.


>> I just have one question regarding the feature-string. I see
>> instrumentation for "fsqrts" feature but it's not currently
>> advertised by the feature-string. On the other hand, ISA info
>> looks to indicate that fsqrt and fsqrts are not aliases, because:
>>
>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
>>
>> so I'm wondering if just for completeness the "fsqrts" feature
>> should be included in the feature-string. Besides that I don't
>> see instrumentation to support has_mftgpr(), which is commented
>> out, thus should we remove it? Like the following:
> 
> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.

I'm not sure about it. Maybe somebody is using out there, in the community
for example, so kept it.


> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.

I was not aware of that, thanks for the info.
Just out of curiosity I asked the toolchain folks and they said that mftgpr
is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
which I think it's the extension you mentioned), but not in the architected /
normal mode (power6). So even if it's present in the hardware it's disabled
unless you boot the system up in raw mode.

On that raw mode (power6x) one would see the following in AUXV, for instance:

$ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
AT_PLATFORM:     power6x
AT_BASE_PLATFORM:power6x

But probably theses machines w/ power6x never got out of IBM indeed.

Anyway, they said that power6x is unsupported. So, as you said, I removed the
comment about mftgpr.

v3 webrev:

http://cr.openjdk.java.net/~gromero/8212481/v3/


Thanks!

Best regards,
Gustavo


From thomas.stuefe at gmail.com  Wed Oct 24 06:19:22 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 24 Oct 2018 08:19:22 +0200
Subject: RFR(xxs): 8212896: AIX build breaks after 8212611
Message-ID: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>

Hi all,

may I please have a review (trivial rule) for this tiny build fix:

https://bugs.openjdk.java.net/browse/JDK-8212896
http://cr.openjdk.java.net/~stuefe/webrevs/8212896-aix-build-broken-after-8212611/webrev.00/webrev/

Thank you,

Thomas

From david.holmes at oracle.com  Wed Oct 24 06:23:37 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 Oct 2018 16:23:37 +1000
Subject: RFR(xxs): 8212896: AIX build breaks after 8212611
In-Reply-To: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>
References: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>
Message-ID: <560b9877-e962-a472-31db-f23f4a463fbf@oracle.com>

Looks fine - and consistent with other files affected by 8212611.

Thanks,
David

On 24/10/2018 4:19 PM, Thomas St?fe wrote:
> Hi all,
> 
> may I please have a review (trivial rule) for this tiny build fix:
> 
> https://bugs.openjdk.java.net/browse/JDK-8212896
> http://cr.openjdk.java.net/~stuefe/webrevs/8212896-aix-build-broken-after-8212611/webrev.00/webrev/
> 
> Thank you,
> 
> Thomas
> 

From volker.simonis at gmail.com  Wed Oct 24 06:51:23 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 24 Oct 2018 08:51:23 +0200
Subject: RFR(xxs): 8212896: AIX build breaks after 8212611
In-Reply-To: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>
References: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>
Message-ID: <CA+3eh10gnvbnMRCrGbCSqKXeR_qzOtOBJuGq4rV0x7cC1+BG-g@mail.gmail.com>

Looks good!

However I don't understand why this bug does not also break the
non-PCH build on Linux for example (I've just tried and it still
works)? Do you understand?

Regards,
Volker
On Wed, Oct 24, 2018 at 8:19 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Hi all,
>
> may I please have a review (trivial rule) for this tiny build fix:
>
> https://bugs.openjdk.java.net/browse/JDK-8212896
> http://cr.openjdk.java.net/~stuefe/webrevs/8212896-aix-build-broken-after-8212611/webrev.00/webrev/
>
> Thank you,
>
> Thomas

From thomas.stuefe at gmail.com  Wed Oct 24 07:49:00 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 24 Oct 2018 09:49:00 +0200
Subject: RFR(xxs): 8212896: AIX build breaks after 8212611
In-Reply-To: <CA+3eh10gnvbnMRCrGbCSqKXeR_qzOtOBJuGq4rV0x7cC1+BG-g@mail.gmail.com>
References: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>
 <CA+3eh10gnvbnMRCrGbCSqKXeR_qzOtOBJuGq4rV0x7cC1+BG-g@mail.gmail.com>
Message-ID: <CAA-vtUzEK8CUra8pdZsO=V5bO_SEsbMoubhmkVD9e3-zZxrJ2w@mail.gmail.com>

Yes I wondered about that too.

Turns out this header sneaks in on other platforms via JFR:

471 ........ /shared/projects/openjdk/jdk-jdk/output-fastdebug-nopch/hotspot/variant-server/gensrc/jfrfiles/jfrEventClasses.hpp
472 ......... /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp
477 .......... /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/jfr/writers/jfrNativeEventWriter.hpp
482 ...........
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/jfr/writers/jfrEventWriterHost.inline.hpp
483 ............
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/jfr/writers/jfrEventWriterHost.hpp
484 .............
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp
505 ..............
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/oops/typeArrayOop.inline.hpp
506 ...............
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/oops/access.inline.hpp
507 ................
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp
508 .................
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp
509 ..................
/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/gc/shared/barrierSet.hpp

Since on AIX INCLUDE_JFR is not set, we miss out on those includes.

...Thomas

On Wed, Oct 24, 2018 at 8:51 AM Volker Simonis <volker.simonis at gmail.com> wrote:
>
> Looks good!
>
> However I don't understand why this bug does not also break the
> non-PCH build on Linux for example (I've just tried and it still
> works)? Do you understand?
>
> Regards,
> Volker
> On Wed, Oct 24, 2018 at 8:19 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> >
> > Hi all,
> >
> > may I please have a review (trivial rule) for this tiny build fix:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8212896
> > http://cr.openjdk.java.net/~stuefe/webrevs/8212896-aix-build-broken-after-8212611/webrev.00/webrev/
> >
> > Thank you,
> >
> > Thomas

From martin.doerr at sap.com  Wed Oct 24 08:20:34 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 24 Oct 2018 08:20:34 +0000
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
 <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
Message-ID: <0c176a41bd274bf795382f26e476b59a@sap.com>

Hi Gustavo,

looks good. Thank you for cleaning things up and also for sharing the story about mftgpr. Interesting.
Reviewed.

Best regards,
Martin


-----Original Message-----
From: Gustavo Romero <gromero at linux.vnet.ibm.com> 
Sent: Dienstag, 23. Oktober 2018 23:46
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection

Hi Martin,

Thanks for your comments on fsqrt{,s} and mftgpr opcodes.

On 10/23/2018 01:51 PM, Doerr, Martin wrote:
> Hi Gustavo,
> 
>> I agree. So, if you don't mind, to reduce any future rework on that
>> I removed the hardcoded L=1 and now it's just a default. I introduced
>> l14() function that matches two bits in the proper field as I don't
>> see any collision with any other one bit field at the same position
>> (bit 14).
> I like it, but the default value needs to get specified in the .hpp file.

Fixed.


>> I just have one question regarding the feature-string. I see
>> instrumentation for "fsqrts" feature but it's not currently
>> advertised by the feature-string. On the other hand, ISA info
>> looks to indicate that fsqrt and fsqrts are not aliases, because:
>>
>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
>>
>> so I'm wondering if just for completeness the "fsqrts" feature
>> should be included in the feature-string. Besides that I don't
>> see instrumentation to support has_mftgpr(), which is commented
>> out, thus should we remove it? Like the following:
> 
> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.

I'm not sure about it. Maybe somebody is using out there, in the community
for example, so kept it.


> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.

I was not aware of that, thanks for the info.
Just out of curiosity I asked the toolchain folks and they said that mftgpr
is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
which I think it's the extension you mentioned), but not in the architected /
normal mode (power6). So even if it's present in the hardware it's disabled
unless you boot the system up in raw mode.

On that raw mode (power6x) one would see the following in AUXV, for instance:

$ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
AT_PLATFORM:     power6x
AT_BASE_PLATFORM:power6x

But probably theses machines w/ power6x never got out of IBM indeed.

Anyway, they said that power6x is unsupported. So, as you said, I removed the
comment about mftgpr.

v3 webrev:

http://cr.openjdk.java.net/~gromero/8212481/v3/


Thanks!

Best regards,
Gustavo


From thomas.stuefe at gmail.com  Wed Oct 24 08:36:35 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 24 Oct 2018 10:36:35 +0200
Subject: RFR(xxs): 8212896: AIX build breaks after 8212611
In-Reply-To: <560b9877-e962-a472-31db-f23f4a463fbf@oracle.com>
References: <CAA-vtUxYwvPtxidfx0BBjGGr=M23bvqohJBQ_xeOSBnByEJCwA@mail.gmail.com>
 <560b9877-e962-a472-31db-f23f4a463fbf@oracle.com>
Message-ID: <CAA-vtUzcNVEEB1siKa4zXzipejpM06g1uaZ+JhAE-u5Am3tf_w@mail.gmail.com>

Thanks David!

Submit ran thru, will push now.

..Thomas
On Wed, Oct 24, 2018 at 10:35 AM David Holmes <david.holmes at oracle.com> wrote:
>
> Looks fine - and consistent with other files affected by 8212611.
>
> Thanks,
> David
>
> On 24/10/2018 4:19 PM, Thomas St?fe wrote:
> > Hi all,
> >
> > may I please have a review (trivial rule) for this tiny build fix:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8212896
> > http://cr.openjdk.java.net/~stuefe/webrevs/8212896-aix-build-broken-after-8212611/webrev.00/webrev/
> >
> > Thank you,
> >
> > Thomas
> >

From gromero at linux.vnet.ibm.com  Wed Oct 24 13:35:03 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 24 Oct 2018 10:35:03 -0300
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <0c176a41bd274bf795382f26e476b59a@sap.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
 <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
 <0c176a41bd274bf795382f26e476b59a@sap.com>
Message-ID: <bf9af480-57ed-2a29-7c89-acc5f065216d@linux.vnet.ibm.com>

Hi Martin,

On 10/24/2018 05:20 AM, Doerr, Martin wrote:
> looks good. Thank you for cleaning things up and also for sharing the story about mftgpr. Interesting.
> Reviewed.

Thanks for reviewing!


Best regards,
Gustavo

> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Dienstag, 23. Oktober 2018 23:46
> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
> 
> Hi Martin,
> 
> Thanks for your comments on fsqrt{,s} and mftgpr opcodes.
> 
> On 10/23/2018 01:51 PM, Doerr, Martin wrote:
>> Hi Gustavo,
>>
>>> I agree. So, if you don't mind, to reduce any future rework on that
>>> I removed the hardcoded L=1 and now it's just a default. I introduced
>>> l14() function that matches two bits in the proper field as I don't
>>> see any collision with any other one bit field at the same position
>>> (bit 14).
>> I like it, but the default value needs to get specified in the .hpp file.
> 
> Fixed.
> 
> 
>>> I just have one question regarding the feature-string. I see
>>> instrumentation for "fsqrts" feature but it's not currently
>>> advertised by the feature-string. On the other hand, ISA info
>>> looks to indicate that fsqrt and fsqrts are not aliases, because:
>>>
>>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
>>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
>>>
>>> so I'm wondering if just for completeness the "fsqrts" feature
>>> should be included in the feature-string. Besides that I don't
>>> see instrumentation to support has_mftgpr(), which is commented
>>> out, thus should we remove it? Like the following:
>>
>> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
> 
> I'm not sure about it. Maybe somebody is using out there, in the community
> for example, so kept it.
> 
> 
>> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.
> 
> I was not aware of that, thanks for the info.
> Just out of curiosity I asked the toolchain folks and they said that mftgpr
> is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
> which I think it's the extension you mentioned), but not in the architected /
> normal mode (power6). So even if it's present in the hardware it's disabled
> unless you boot the system up in raw mode.
> 
> On that raw mode (power6x) one would see the following in AUXV, for instance:
> 
> $ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
> AT_PLATFORM:     power6x
> AT_BASE_PLATFORM:power6x
> 
> But probably theses machines w/ power6x never got out of IBM indeed.
> 
> Anyway, they said that power6x is unsupported. So, as you said, I removed the
> comment about mftgpr.
> 
> v3 webrev:
> 
> http://cr.openjdk.java.net/~gromero/8212481/v3/
> 
> 
> Thanks!
> 
> Best regards,
> Gustavo
> 


From takiguc at linux.vnet.ibm.com  Fri Oct 26 13:34:44 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 26 Oct 2018 22:34:44 +0900
Subject: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default
 charset
Message-ID: <42481f6da1e503fecbe621593ed93e43@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/

I'd like to obtain a sponsor for this issue.


IBM964 charset and IBM29626C charset are required for default charset
on AIX zh_TW and ja_JP locale.
OpenJDK already has IBM964, but it could not be configured for default 
charset.
IBM29626C is new one.
(IBM33722 extends IBM29626C class)

I knew IBM charsets would need to move to somewhere.
The discussion was started by "Adding new IBM extended charsets". [1]
But it's related default charset issue.
Please put them inside of OpenJDK.

About IBM964,
Bhaktavatsal started the discussion [2].
Sherman said that [3]
   the new model (open/make/data/charetmapping), instead of hard-coding 
the map
   into the source code.

This fix only has small sized hard-coded mapping,
IBM964/IBM29626C/IBM33722 refer other charsets conversion table
which are using the new model.
And class file is smaller then before.
Still I used SimpleEUCEncoder class because it's stable.
I think we may re-write it by IBM charsets renewal.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
[3] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html


From goetz.lindenmaier at sap.com  Mon Oct 29 10:55:30 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 29 Oct 2018 10:55:30 +0000
Subject: Open ppc/s390/aix issues
In-Reply-To: <d959f885d63695659c9485ca11f95815@linux.vnet.ibm.com>
References: <8c6b8ea2a811401eb7559ab68e821bd4@sap.com>
 <d959f885d63695659c9485ca11f95815@linux.vnet.ibm.com>
Message-ID: <92c003c24bf8466886e3602604650c8c@sap.com>

Hi Ichiroh, 

I did not look into this issue, I just reported the 
bug. So feel free to choose an adequate solution 
to fix this.

Best regards,
  Goetz

> -----Original Message-----
> From: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> Sent: Freitag, 19. Oktober 2018 04:00
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: ppc-aix-port-dev <ppc-aix-port-dev at openjdk.java.net>; s390x-port-
> dev at openjdk.java.net; Gustavo Romero <gromero at linux.vnet.ibm.com>; Tim
> Ellison <Tim_Ellison at uk.ibm.com>; Nasser Ebrahim <enasser at in.ibm.com>;
> Michihiro Horie <HORIE at jp.ibm.com>; Toshio 5 Nakamura
> <TOSHIONA at jp.ibm.com>; Andrew Leonard
> <andrew_m_leonard at uk.ibm.com>
> Subject: Re: Open ppc/s390/aix issues
> 
> Hello Goetz.
> > 8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation
> > error
> > https://bugs.openjdk.java.net/browse/JDK-8211841
> I'll handle it on Nov.
> But I'd like to confirm one thing.
> You may know this compilation error came from jigsaw (modularity
> feature).
> I may rewrite the some of the parts by using reflection feature.
> Do you think it's acceptable solution ?
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2018-10-09 01:58, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > We are now working on the ppc/s390/aix ports for quite some years.
> > With the release of jdk11 we delivered a very comprehensive and well
> > maintained port I think. For example, the jdk and hotspot jtreg tests
> > can be run quite stable on these platforms.
> >
> > I filed bugs for all the remaining issues we see, at least in the
> > test setup we run at SAP.
> >
> > Everybody is invited to join in and fix these few finally :)
> >
> > 8207404: MulticastSocket tests failing on Aix
> > https://bugs.openjdk.java.net/browse/JDK-8207404
> > 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and
> > .getProcessCpuLoad() on AIX
> > https://bugs.openjdk.java.net/browse/JDK-8030957
> > 8211769: Port Dtrace support to ppc.
> > https://bugs.openjdk.java.net/browse/JDK-8211769
> > 8211771: Port Dtrace support to s390x.
> > https://bugs.openjdk.java.net/browse/JDK-8211771
> > 8211767: jtreg: Some SA tests are failing on PPC64
> > https://bugs.openjdk.java.net/browse/JDK-8211767
> > 8211844: [aix] ProcessBuilder: Piping between created processes does
> > not work.
> > https://bugs.openjdk.java.net/browse/JDK-8211844
> > 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported
> > cputime less than expected"
> > https://bugs.openjdk.java.net/browse/JDK-8211847
> > 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fais:
> > read times out
> > https://bugs.openjdk.java.net/browse/JDK-8211854
> > 8211851:
> > /java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times
> > out (aix)
> > https://bugs.openjdk.java.net/browse/JDK-8211851
> > 8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation
> > error
> > https://bugs.openjdk.java.net/browse/JDK-8211841
> >
> > Best regards,
> >   Goetz.


From volker.simonis at gmail.com  Tue Oct 30 17:55:08 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 30 Oct 2018 18:55:08 +0100
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <bf9af480-57ed-2a29-7c89-acc5f065216d@linux.vnet.ibm.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
 <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
 <0c176a41bd274bf795382f26e476b59a@sap.com>
 <bf9af480-57ed-2a29-7c89-acc5f065216d@linux.vnet.ibm.com>
Message-ID: <CA+3eh12sY8JcViRdPjFrjoDuvCxMbJmJrUZOeoUKckx0LG1ZEw@mail.gmail.com>

Hi Gustavo,

thanks for adding Power9 support. Your change looks good!

Just two minor comments (no need to publish a new webrev):

- can you please update the copyright year to 2018 in
assembler_ppc.inline.hpp and vm_version_ppc.hpp
- in assembler_ppc.inline.hpp can you pleas add a comment with the
default value as shown below? I often find that useful when browsing
the code.

+// Deliver A Random Number (introduced with POWER9)
+inline void Assembler::darn(Register d, int l /* = 1 */) {
emit_int32( DARN_OPCODE | rt(d) | l14(l)); }
+

Thank you and best regards,
Volker

On Wed, Oct 24, 2018 at 3:35 PM Gustavo Romero
<gromero at linux.vnet.ibm.com> wrote:
>
> Hi Martin,
>
> On 10/24/2018 05:20 AM, Doerr, Martin wrote:
> > looks good. Thank you for cleaning things up and also for sharing the story about mftgpr. Interesting.
> > Reviewed.
>
> Thanks for reviewing!
>
>
> Best regards,
> Gustavo
>
> > Best regards,
> > Martin
> >
> >
> > -----Original Message-----
> > From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> > Sent: Dienstag, 23. Oktober 2018 23:46
> > To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> > Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
> >
> > Hi Martin,
> >
> > Thanks for your comments on fsqrt{,s} and mftgpr opcodes.
> >
> > On 10/23/2018 01:51 PM, Doerr, Martin wrote:
> >> Hi Gustavo,
> >>
> >>> I agree. So, if you don't mind, to reduce any future rework on that
> >>> I removed the hardcoded L=1 and now it's just a default. I introduced
> >>> l14() function that matches two bits in the proper field as I don't
> >>> see any collision with any other one bit field at the same position
> >>> (bit 14).
> >> I like it, but the default value needs to get specified in the .hpp file.
> >
> > Fixed.
> >
> >
> >>> I just have one question regarding the feature-string. I see
> >>> instrumentation for "fsqrts" feature but it's not currently
> >>> advertised by the feature-string. On the other hand, ISA info
> >>> looks to indicate that fsqrt and fsqrts are not aliases, because:
> >>>
> >>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
> >>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
> >>>
> >>> so I'm wondering if just for completeness the "fsqrts" feature
> >>> should be included in the feature-string. Besides that I don't
> >>> see instrumentation to support has_mftgpr(), which is commented
> >>> out, thus should we remove it? Like the following:
> >>
> >> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
> >
> > I'm not sure about it. Maybe somebody is using out there, in the community
> > for example, so kept it.
> >
> >
> >> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.
> >
> > I was not aware of that, thanks for the info.
> > Just out of curiosity I asked the toolchain folks and they said that mftgpr
> > is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
> > which I think it's the extension you mentioned), but not in the architected /
> > normal mode (power6). So even if it's present in the hardware it's disabled
> > unless you boot the system up in raw mode.
> >
> > On that raw mode (power6x) one would see the following in AUXV, for instance:
> >
> > $ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
> > AT_PLATFORM:     power6x
> > AT_BASE_PLATFORM:power6x
> >
> > But probably theses machines w/ power6x never got out of IBM indeed.
> >
> > Anyway, they said that power6x is unsupported. So, as you said, I removed the
> > comment about mftgpr.
> >
> > v3 webrev:
> >
> > http://cr.openjdk.java.net/~gromero/8212481/v3/
> >
> >
> > Thanks!
> >
> > Best regards,
> > Gustavo
> >
>

From gromero at linux.vnet.ibm.com  Wed Oct 31 12:26:59 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 31 Oct 2018 09:26:59 -0300
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <CA+3eh12sY8JcViRdPjFrjoDuvCxMbJmJrUZOeoUKckx0LG1ZEw@mail.gmail.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
 <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
 <0c176a41bd274bf795382f26e476b59a@sap.com>
 <bf9af480-57ed-2a29-7c89-acc5f065216d@linux.vnet.ibm.com>
 <CA+3eh12sY8JcViRdPjFrjoDuvCxMbJmJrUZOeoUKckx0LG1ZEw@mail.gmail.com>
Message-ID: <71628cc4-fbdb-922d-2993-a72093941d5e@linux.vnet.ibm.com>

Hi Volker!

On 10/30/2018 02:55 PM, Volker Simonis wrote:
> Hi Gustavo,
> 
> thanks for adding Power9 support. Your change looks good!

Thanks a lot for reviewing.


> Just two minor comments (no need to publish a new webrev):
> 
> - can you please update the copyright year to 2018 in
> assembler_ppc.inline.hpp and vm_version_ppc.hpp

I think that the copyright update applies to Oracle and SAP,
like the following, but I would like to confirm if that is
indeed correct as I see some examples "out of sync" in other
files:

diff -r 57a87060bd09 src/hotspot/cpu/ppc/assembler_ppc.inline.hpp
--- a/src/hotspot/cpu/ppc/assembler_ppc.inline.hpp      Tue Oct 16 16:26:28 2018 -0400
+++ b/src/hotspot/cpu/ppc/assembler_ppc.inline.hpp      Wed Oct 31 08:03:21 2018 -0400
@@ -1,6 +1,6 @@
  /*
- * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2012, 2017 SAP SE. All rights reserved.
+ * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2018 SAP SE. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
diff -r 57a87060bd09 src/hotspot/cpu/ppc/vm_version_ppc.hpp
--- a/src/hotspot/cpu/ppc/vm_version_ppc.hpp    Tue Oct 16 16:26:28 2018 -0400
+++ b/src/hotspot/cpu/ppc/vm_version_ppc.hpp    Wed Oct 31 08:03:21 2018 -0400
@@ -1,6 +1,6 @@
  /*
- * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2012, 2017 SAP SE. All rights reserved.
+ * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2018 SAP SE. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it


> - in assembler_ppc.inline.hpp can you pleas add a comment with the
> default value as shown below? I often find that useful when browsing
> the code.
> 
> +// Deliver A Random Number (introduced with POWER9)
> +inline void Assembler::darn(Register d, int l /* = 1 */) {
> emit_int32( DARN_OPCODE | rt(d) | l14(l)); }
> +

Sure, I'll update that before pushing the change.

Thank you.


Best regards,
Gustavo

> Thank you and best regards,
> Volker
> 
> On Wed, Oct 24, 2018 at 3:35 PM Gustavo Romero
> <gromero at linux.vnet.ibm.com> wrote:
>>
>> Hi Martin,
>>
>> On 10/24/2018 05:20 AM, Doerr, Martin wrote:
>>> looks good. Thank you for cleaning things up and also for sharing the story about mftgpr. Interesting.
>>> Reviewed.
>>
>> Thanks for reviewing!
>>
>>
>> Best regards,
>> Gustavo
>>
>>> Best regards,
>>> Martin
>>>
>>>
>>> -----Original Message-----
>>> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
>>> Sent: Dienstag, 23. Oktober 2018 23:46
>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
>>> Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
>>>
>>> Hi Martin,
>>>
>>> Thanks for your comments on fsqrt{,s} and mftgpr opcodes.
>>>
>>> On 10/23/2018 01:51 PM, Doerr, Martin wrote:
>>>> Hi Gustavo,
>>>>
>>>>> I agree. So, if you don't mind, to reduce any future rework on that
>>>>> I removed the hardcoded L=1 and now it's just a default. I introduced
>>>>> l14() function that matches two bits in the proper field as I don't
>>>>> see any collision with any other one bit field at the same position
>>>>> (bit 14).
>>>> I like it, but the default value needs to get specified in the .hpp file.
>>>
>>> Fixed.
>>>
>>>
>>>>> I just have one question regarding the feature-string. I see
>>>>> instrumentation for "fsqrts" feature but it's not currently
>>>>> advertised by the feature-string. On the other hand, ISA info
>>>>> looks to indicate that fsqrt and fsqrts are not aliases, because:
>>>>>
>>>>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
>>>>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
>>>>>
>>>>> so I'm wondering if just for completeness the "fsqrts" feature
>>>>> should be included in the feature-string. Besides that I don't
>>>>> see instrumentation to support has_mftgpr(), which is commented
>>>>> out, thus should we remove it? Like the following:
>>>>
>>>> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
>>>
>>> I'm not sure about it. Maybe somebody is using out there, in the community
>>> for example, so kept it.
>>>
>>>
>>>> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.
>>>
>>> I was not aware of that, thanks for the info.
>>> Just out of curiosity I asked the toolchain folks and they said that mftgpr
>>> is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
>>> which I think it's the extension you mentioned), but not in the architected /
>>> normal mode (power6). So even if it's present in the hardware it's disabled
>>> unless you boot the system up in raw mode.
>>>
>>> On that raw mode (power6x) one would see the following in AUXV, for instance:
>>>
>>> $ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
>>> AT_PLATFORM:     power6x
>>> AT_BASE_PLATFORM:power6x
>>>
>>> But probably theses machines w/ power6x never got out of IBM indeed.
>>>
>>> Anyway, they said that power6x is unsupported. So, as you said, I removed the
>>> comment about mftgpr.
>>>
>>> v3 webrev:
>>>
>>> http://cr.openjdk.java.net/~gromero/8212481/v3/
>>>
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Gustavo
>>>
>>
> 


From martin.doerr at sap.com  Wed Oct 31 14:09:07 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 31 Oct 2018 14:09:07 +0000
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <71628cc4-fbdb-922d-2993-a72093941d5e@linux.vnet.ibm.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
 <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
 <0c176a41bd274bf795382f26e476b59a@sap.com>
 <bf9af480-57ed-2a29-7c89-acc5f065216d@linux.vnet.ibm.com>
 <CA+3eh12sY8JcViRdPjFrjoDuvCxMbJmJrUZOeoUKckx0LG1ZEw@mail.gmail.com>
 <71628cc4-fbdb-922d-2993-a72093941d5e@linux.vnet.ibm.com>
Message-ID: <5cc8fc9a0659404993c94c46ed050356@sap.com>

Hi Gustavo,

your copyright update looks correct. Ideally, both copyright lines should be in sync.
But some people use scripts which only update Oracle's copyright. I believe this is why they sometimes get out of sync.

Best regards,
Martin


-----Original Message-----
From: Gustavo Romero <gromero at linux.vnet.ibm.com> 
Sent: Mittwoch, 31. Oktober 2018 13:27
To: Volker Simonis <volker.simonis at gmail.com>
Cc: Doerr, Martin <martin.doerr at sap.com>; HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection

Hi Volker!

On 10/30/2018 02:55 PM, Volker Simonis wrote:
> Hi Gustavo,
> 
> thanks for adding Power9 support. Your change looks good!

Thanks a lot for reviewing.


> Just two minor comments (no need to publish a new webrev):
> 
> - can you please update the copyright year to 2018 in
> assembler_ppc.inline.hpp and vm_version_ppc.hpp

I think that the copyright update applies to Oracle and SAP,
like the following, but I would like to confirm if that is
indeed correct as I see some examples "out of sync" in other
files:

diff -r 57a87060bd09 src/hotspot/cpu/ppc/assembler_ppc.inline.hpp
--- a/src/hotspot/cpu/ppc/assembler_ppc.inline.hpp      Tue Oct 16 16:26:28 2018 -0400
+++ b/src/hotspot/cpu/ppc/assembler_ppc.inline.hpp      Wed Oct 31 08:03:21 2018 -0400
@@ -1,6 +1,6 @@
  /*
- * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2012, 2017 SAP SE. All rights reserved.
+ * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2018 SAP SE. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
diff -r 57a87060bd09 src/hotspot/cpu/ppc/vm_version_ppc.hpp
--- a/src/hotspot/cpu/ppc/vm_version_ppc.hpp    Tue Oct 16 16:26:28 2018 -0400
+++ b/src/hotspot/cpu/ppc/vm_version_ppc.hpp    Wed Oct 31 08:03:21 2018 -0400
@@ -1,6 +1,6 @@
  /*
- * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
- * Copyright (c) 2012, 2017 SAP SE. All rights reserved.
+ * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2018 SAP SE. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it


> - in assembler_ppc.inline.hpp can you pleas add a comment with the
> default value as shown below? I often find that useful when browsing
> the code.
> 
> +// Deliver A Random Number (introduced with POWER9)
> +inline void Assembler::darn(Register d, int l /* = 1 */) {
> emit_int32( DARN_OPCODE | rt(d) | l14(l)); }
> +

Sure, I'll update that before pushing the change.

Thank you.


Best regards,
Gustavo

> Thank you and best regards,
> Volker
> 
> On Wed, Oct 24, 2018 at 3:35 PM Gustavo Romero
> <gromero at linux.vnet.ibm.com> wrote:
>>
>> Hi Martin,
>>
>> On 10/24/2018 05:20 AM, Doerr, Martin wrote:
>>> looks good. Thank you for cleaning things up and also for sharing the story about mftgpr. Interesting.
>>> Reviewed.
>>
>> Thanks for reviewing!
>>
>>
>> Best regards,
>> Gustavo
>>
>>> Best regards,
>>> Martin
>>>
>>>
>>> -----Original Message-----
>>> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
>>> Sent: Dienstag, 23. Oktober 2018 23:46
>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
>>> Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
>>>
>>> Hi Martin,
>>>
>>> Thanks for your comments on fsqrt{,s} and mftgpr opcodes.
>>>
>>> On 10/23/2018 01:51 PM, Doerr, Martin wrote:
>>>> Hi Gustavo,
>>>>
>>>>> I agree. So, if you don't mind, to reduce any future rework on that
>>>>> I removed the hardcoded L=1 and now it's just a default. I introduced
>>>>> l14() function that matches two bits in the proper field as I don't
>>>>> see any collision with any other one bit field at the same position
>>>>> (bit 14).
>>>> I like it, but the default value needs to get specified in the .hpp file.
>>>
>>> Fixed.
>>>
>>>
>>>>> I just have one question regarding the feature-string. I see
>>>>> instrumentation for "fsqrts" feature but it's not currently
>>>>> advertised by the feature-string. On the other hand, ISA info
>>>>> looks to indicate that fsqrt and fsqrts are not aliases, because:
>>>>>
>>>>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
>>>>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
>>>>>
>>>>> so I'm wondering if just for completeness the "fsqrts" feature
>>>>> should be included in the feature-string. Besides that I don't
>>>>> see instrumentation to support has_mftgpr(), which is commented
>>>>> out, thus should we remove it? Like the following:
>>>>
>>>> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
>>>
>>> I'm not sure about it. Maybe somebody is using out there, in the community
>>> for example, so kept it.
>>>
>>>
>>>> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.
>>>
>>> I was not aware of that, thanks for the info.
>>> Just out of curiosity I asked the toolchain folks and they said that mftgpr
>>> is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
>>> which I think it's the extension you mentioned), but not in the architected /
>>> normal mode (power6). So even if it's present in the hardware it's disabled
>>> unless you boot the system up in raw mode.
>>>
>>> On that raw mode (power6x) one would see the following in AUXV, for instance:
>>>
>>> $ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
>>> AT_PLATFORM:     power6x
>>> AT_BASE_PLATFORM:power6x
>>>
>>> But probably theses machines w/ power6x never got out of IBM indeed.
>>>
>>> Anyway, they said that power6x is unsupported. So, as you said, I removed the
>>> comment about mftgpr.
>>>
>>> v3 webrev:
>>>
>>> http://cr.openjdk.java.net/~gromero/8212481/v3/
>>>
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Gustavo
>>>
>>
> 


From gromero at linux.vnet.ibm.com  Wed Oct 31 14:34:48 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 31 Oct 2018 11:34:48 -0300
Subject: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
In-Reply-To: <5cc8fc9a0659404993c94c46ed050356@sap.com>
References: <7af8967f-cb19-0293-b688-474d82a03895@linux.vnet.ibm.com>
 <a480a54e15354e939d7e6a9397a67747@sap.com>
 <e1c631ba-e3a2-362c-1517-55f02e1f4039@linux.vnet.ibm.com>
 <bfcc7eebd666463f96e0210811fd947a@sap.com>
 <271b6743-1611-4201-cdf6-9fdc5b87086e@linux.vnet.ibm.com>
 <0c176a41bd274bf795382f26e476b59a@sap.com>
 <bf9af480-57ed-2a29-7c89-acc5f065216d@linux.vnet.ibm.com>
 <CA+3eh12sY8JcViRdPjFrjoDuvCxMbJmJrUZOeoUKckx0LG1ZEw@mail.gmail.com>
 <71628cc4-fbdb-922d-2993-a72093941d5e@linux.vnet.ibm.com>
 <5cc8fc9a0659404993c94c46ed050356@sap.com>
Message-ID: <48556ba8-cf41-04e5-95f7-64b06aa76b07@linux.vnet.ibm.com>

Hi Martin,

On 10/31/2018 11:09 AM, Doerr, Martin wrote:
> Hi Gustavo,
> 
> your copyright update looks correct. Ideally, both copyright lines should be in sync.
> But some people use scripts which only update Oracle's copyright. I believe this is why they sometimes get out of sync.

oh I see.

Thanks for clarifying and confirming the copyright update is correct.

I'll push the change with Volker's comments today.


Best regards,
Gustavo

> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Mittwoch, 31. Oktober 2018 13:27
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: Doerr, Martin <martin.doerr at sap.com>; HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
> Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
> 
> Hi Volker!
> 
> On 10/30/2018 02:55 PM, Volker Simonis wrote:
>> Hi Gustavo,
>>
>> thanks for adding Power9 support. Your change looks good!
> 
> Thanks a lot for reviewing.
> 
> 
>> Just two minor comments (no need to publish a new webrev):
>>
>> - can you please update the copyright year to 2018 in
>> assembler_ppc.inline.hpp and vm_version_ppc.hpp
> 
> I think that the copyright update applies to Oracle and SAP,
> like the following, but I would like to confirm if that is
> indeed correct as I see some examples "out of sync" in other
> files:
> 
> diff -r 57a87060bd09 src/hotspot/cpu/ppc/assembler_ppc.inline.hpp
> --- a/src/hotspot/cpu/ppc/assembler_ppc.inline.hpp      Tue Oct 16 16:26:28 2018 -0400
> +++ b/src/hotspot/cpu/ppc/assembler_ppc.inline.hpp      Wed Oct 31 08:03:21 2018 -0400
> @@ -1,6 +1,6 @@
>    /*
> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2012, 2017 SAP SE. All rights reserved.
> + * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2018 SAP SE. All rights reserved.
>     * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>     *
>     * This code is free software; you can redistribute it and/or modify it
> diff -r 57a87060bd09 src/hotspot/cpu/ppc/vm_version_ppc.hpp
> --- a/src/hotspot/cpu/ppc/vm_version_ppc.hpp    Tue Oct 16 16:26:28 2018 -0400
> +++ b/src/hotspot/cpu/ppc/vm_version_ppc.hpp    Wed Oct 31 08:03:21 2018 -0400
> @@ -1,6 +1,6 @@
>    /*
> - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
> - * Copyright (c) 2012, 2017 SAP SE. All rights reserved.
> + * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2018 SAP SE. All rights reserved.
>     * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>     *
>     * This code is free software; you can redistribute it and/or modify it
> 
> 
>> - in assembler_ppc.inline.hpp can you pleas add a comment with the
>> default value as shown below? I often find that useful when browsing
>> the code.
>>
>> +// Deliver A Random Number (introduced with POWER9)
>> +inline void Assembler::darn(Register d, int l /* = 1 */) {
>> emit_int32( DARN_OPCODE | rt(d) | l14(l)); }
>> +
> 
> Sure, I'll update that before pushing the change.
> 
> Thank you.
> 
> 
> Best regards,
> Gustavo
> 
>> Thank you and best regards,
>> Volker
>>
>> On Wed, Oct 24, 2018 at 3:35 PM Gustavo Romero
>> <gromero at linux.vnet.ibm.com> wrote:
>>>
>>> Hi Martin,
>>>
>>> On 10/24/2018 05:20 AM, Doerr, Martin wrote:
>>>> looks good. Thank you for cleaning things up and also for sharing the story about mftgpr. Interesting.
>>>> Reviewed.
>>>
>>> Thanks for reviewing!
>>>
>>>
>>> Best regards,
>>> Gustavo
>>>
>>>> Best regards,
>>>> Martin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
>>>> Sent: Dienstag, 23. Oktober 2018 23:46
>>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
>>>> Subject: Re: RFR(S): 8212481: PPC64: Enable POWER9 CPU detection
>>>>
>>>> Hi Martin,
>>>>
>>>> Thanks for your comments on fsqrt{,s} and mftgpr opcodes.
>>>>
>>>> On 10/23/2018 01:51 PM, Doerr, Martin wrote:
>>>>> Hi Gustavo,
>>>>>
>>>>>> I agree. So, if you don't mind, to reduce any future rework on that
>>>>>> I removed the hardcoded L=1 and now it's just a default. I introduced
>>>>>> l14() function that matches two bits in the proper field as I don't
>>>>>> see any collision with any other one bit field at the same position
>>>>>> (bit 14).
>>>>> I like it, but the default value needs to get specified in the .hpp file.
>>>>
>>>> Fixed.
>>>>
>>>>
>>>>>> I just have one question regarding the feature-string. I see
>>>>>> instrumentation for "fsqrts" feature but it's not currently
>>>>>> advertised by the feature-string. On the other hand, ISA info
>>>>>> looks to indicate that fsqrt and fsqrts are not aliases, because:
>>>>>>
>>>>>> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
>>>>>> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
>>>>>>
>>>>>> so I'm wondering if just for completeness the "fsqrts" feature
>>>>>> should be included in the feature-string. Besides that I don't
>>>>>> see instrumentation to support has_mftgpr(), which is commented
>>>>>> out, thus should we remove it? Like the following:
>>>>>
>>>>> This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
>>>>
>>>> I'm not sure about it. Maybe somebody is using out there, in the community
>>>> for example, so kept it.
>>>>
>>>>
>>>>> The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.
>>>>
>>>> I was not aware of that, thanks for the info.
>>>> Just out of curiosity I asked the toolchain folks and they said that mftgpr
>>>> is present in some POWER6 hardware but on the so-called raw mode (ie power6x,
>>>> which I think it's the extension you mentioned), but not in the architected /
>>>> normal mode (power6). So even if it's present in the hardware it's disabled
>>>> unless you boot the system up in raw mode.
>>>>
>>>> On that raw mode (power6x) one would see the following in AUXV, for instance:
>>>>
>>>> $ LD_SHOW_AUXV=1 /bin/true | grep PLATFORM
>>>> AT_PLATFORM:     power6x
>>>> AT_BASE_PLATFORM:power6x
>>>>
>>>> But probably theses machines w/ power6x never got out of IBM indeed.
>>>>
>>>> Anyway, they said that power6x is unsupported. So, as you said, I removed the
>>>> comment about mftgpr.
>>>>
>>>> v3 webrev:
>>>>
>>>> http://cr.openjdk.java.net/~gromero/8212481/v3/
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Gustavo
>>>>
>>>
>>
>