RE: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking libjvm

[Lindenmaier, Goetz]

Hi Martin,

Trivial adaptions. Looks good.

Best regards
  Goetz.

From: Doerr, Martin 
Sent: Thursday, January 14, 2021 5:50 PM
To: jdk-updates-...@openjdk.java.net; build-dev@openjdk.java.net
Cc: Lindenmaier, Goetz ; Langer, Christoph 

Subject: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when linking 
libjvm

Hi,

JDK-8257633 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly because of an unrelated context change in the 
neighboring code.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8257633

Original change:
https://git.openjdk.java.net/jdk/commit/51d325e6

11u backport:
http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/

Please review.

Best regards,
Martin

RE: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support

[Lindenmaier, Goetz]

HI,

Thanks for the hint!  Sounds good, I'll give it a try.  

... I removed some emails to reduce traffic.

Best regads,
  Goetz.

-Original Message-
From: Ningsheng Jian  
Sent: Montag, 7. September 2020 08:51
To: Lindenmaier, Goetz ; Andrew Dinn 
; hotspot-compiler-...@openjdk.java.net; 
build-dev@openjdk.java.net; Vladimir Ivanov ; 
Erik Österlund 
Cc: aarch64-port-...@openjdk.java.net; Doerr, Martin 
Subject: RE: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend 
support

Hi Goetz,

I am sorry about that and thanks for helping to identify the issue.

As I cannot reproduce this on x86 and AArch64, a quick guess is that I may have 
missed the code like:

diff --git a/src/hotspot/share/opto/type.cpp b/src/hotspot/share/opto/type.cpp
index 2f4047dfa8e..f7d2f5b2320 100644
--- a/src/hotspot/share/opto/type.cpp
+++ b/src/hotspot/share/opto/type.cpp
@@ -62,12 +62,14 @@ const Type::TypeInfo Type::_type_info[Type::lastype] = {
   { Bad, T_ARRAY,  "array:",false, 
Node::NotAMachineReg, relocInfo::none  },  // Array

 #if defined(PPC64)
+  { Bad, T_ILLEGAL,"vectora:",  false, Op_VecA,
  relocInfo::none  },  // VectorA.
   { Bad, T_ILLEGAL,"vectors:",  false, 0,  
  relocInfo::none  },  // VectorS
   { Bad, T_ILLEGAL,"vectord:",  false, Op_RegL,
  relocInfo::none  },  // VectorD
   { Bad, T_ILLEGAL,"vectorx:",  false, Op_VecX,
  relocInfo::none  },  // VectorX
   { Bad, T_ILLEGAL,"vectory:",  false, 0,  
  relocInfo::none  },  // VectorY
   { Bad, T_ILLEGAL,"vectorz:",  false, 0,  
  relocInfo::none  },  // VectorZ
 #elif defined(S390)
+  { Bad, T_ILLEGAL,"vectora:",  false, Op_VecA,
  relocInfo::none  },  // VectorA.
   { Bad, T_ILLEGAL,"vectors:",  false, 0,  
  relocInfo::none  },  // VectorS
   { Bad, T_ILLEGAL,"vectord:",  false, Op_RegL,
  relocInfo::none  },  // VectorD
   { Bad, T_ILLEGAL,"vectorx:",  false, 0,  
  relocInfo::none  },  // VectorX

Could you please help to have a try?

Thanks,
Ningsheng


> -Original Message-
> From: Lindenmaier, Goetz 
> Sent: Monday, September 7, 2020 2:35 PM
> To: Ningsheng Jian ; Andrew Dinn ;
> hotspot-compiler-...@openjdk.java.net; build-dev@openjdk.java.net; Vladimir
> Ivanov ; Erik Österlund 
> 
> Cc: aarch64-port-...@openjdk.java.net; Doerr, Martin 
> Subject: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend 
> support
>
> Hi
>
> Since that change was pushed, the vm crashes in the build:
>
> To suppress the following error report, specify this argument # after -XX: or
> in .hotspotrc:  SuppressErrorAt=/type.cpp:1022 # # A fatal error has been 
> detected by
> the Java Runtime Environment:
> #
> #  Internal Error (/usr/work/... /share/opto/type.cpp:1022), pid=28717, 
> tid=28983 #
> assert(_type_info[base()].dual_type != Bad) failed: implement with v-call # # 
> JRE
> version: OpenJDK Runtime Environment (16.0.0.1) (fastdebug build 16.0.0.1-
> internal+0-adhoc.openjdk.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 16.0.0.1-internal+0-
> adhoc.openjdk.jdk, mixed mode, tiered, compressed oops, g1 gc, linux-ppc64) #
> Problematic frame:
> # V  [libjvm.so+0x1bfe22c]  Type::xdual() const+0xfc # # No core dump will be 
> written.
> Core dumps have been disabled. To enable core dumping, try "ulimit -c 
> unlimited"
> before starting Java again
>
> Do you have an ad-hoc idea of the problem?
>
> I locally backed out the change which fixed the issue.
>
> Best regards,
>   Goetz.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support

[Lindenmaier, Goetz]

Hi

Since that change was pushed, the vm crashes in the build:

To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/type.cpp:1022
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/usr/work/... /share/opto/type.cpp:1022), pid=28717, 
tid=28983
#  assert(_type_info[base()].dual_type != Bad) failed: implement with v-call
#
# JRE version: OpenJDK Runtime Environment (16.0.0.1) (fastdebug build 
16.0.0.1-internal+0-adhoc.openjdk.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 
16.0.0.1-internal+0-adhoc.openjdk.jdk, mixed mode, tiered, compressed oops, g1 
gc, linux-ppc64)
# Problematic frame:
# V  [libjvm.so+0x1bfe22c]  Type::xdual() const+0xfc
#
# No core dump will be written. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting Java again

Do you have an ad-hoc idea of the problem?

I locally backed out the change which fixed the issue.

Best regards,
  Goetz.

Re: RFR [XS]: 8248334: hs build errors on ppc64 and s390x platforms

[Lindenmaier, Goetz]

Hi,

I didn't get the RFR mails.  Probably the known hotspot-dev Mailing List 
Problem?

But I saw the RFR in the pipermail archive. 

I had a look at the change. It looks good, and
I consider it trivial.

Best regards,
  Goetz.

RE: [11u]: RFR 8235686: Add more custom hooks in Bundles.gmk

[Lindenmaier, Goetz]

Hi Christoph,

The change looks good. Reviewed.

I think Volker wants to bring the FindFiles/CacheFind change to 11, 
which is in the problematic contexts. But I think we should not 
wait for that, as this is a oracle parity change.  It's trivial to resolve
anyways.

As Severin I think it's fine to push this to 11.0.8, after all we 
already have tag 7 in jdk11u, i.e. only two weeks to go.

Best regards,
  Goetz


> -Original Message-
> From: jdk-updates-dev  On
> Behalf Of Langer, Christoph
> Sent: Thursday, March 12, 2020 11:52 AM
> To: jdk-updates-dev 
> Cc: build-dev 
> Subject: [CAUTION] [11u]: RFR 8235686: Add more custom hooks in
> Bundles.gmk
> 
> Hi,
> 
> please help to review this Oracle-11.0.7 parity backport for the build system.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8235686
> Original Change: https://hg.openjdk.java.net/jdk/jdk14/rev/91a3f092682f
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235686.11u/
> 
> The patch needed some trivial resolves and is preceded by JDK-8232572
> which was already reviewed and will be pushed before this one.
> 
> Thanks
> Christoph

RE: 11u RFR: 8232569: Use test image from different jib profile for testing

[Lindenmaier, Goetz]

Hi,

+1
I think this is a candidate for the label "openjdk-na" then.

Best regards,
  Goetz.

> -Original Message-
> From: jdk-updates-dev  On
> Behalf Of Langer, Christoph
> Sent: Montag, 9. März 2020 17:29
> To: Erik Joelsson ; jdk-updates-
> d...@openjdk.java.net
> Cc: build-dev 
> Subject: [CAUTION] RE: 11u RFR: 8232569: Use test image from different jib
> profile for testing
>
> Thanks Erik, for this clarification.
>
> We won't backport it then.
>
> Cheers
> Christoph
>
> -Original Message-
> From: Erik Joelsson 
> Sent: Montag, 9. März 2020 16:44
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Cc: build-dev 
> Subject: Re: 11u RFR: 8232569: Use test image from different jib profile for
> testing
>
>
> On 2020-03-09 08:14, Langer, Christoph wrote:
> > Hi,
> >
> > Please help reviewing this Oracle parity backport
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8232569
> > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/559c46cd0e8b
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232569.11u/
> >
> > I had to make several adaptions because some predecessors were missing
> regarding jcov. Will run the change through our nightly tests but I doubt the 
> file
> is used there.
> >
> > Is this file only used in internal Oracle builds or does it have use cases
> outside? (I guess this question unmasks my ignorance in that area )
>
> This file is only used by Oracle. It's used to interact with our
> dependency management and build configuration system ("jib"), which is
> internal. We keep it in the source code since this configuration is very
> highly version specific and frequently changes in lock step with other
> source code changes. While the exact meaning of the contents of the file
> isn't obvious to an external reader, certain things pertaining to how
> Oracle configures builds can still be gleaned from it and may be useful
> to some (current compiler versions, values of some configure options etc).
>
> I would very much recommend against trying to merge changes here for
> OpenJDK update releases.
>
> /Erik
>
> > Thanks
> > Christoph
> >

RE: RFR [XS] jdk11 - 8234809: set relro in linker flags when building with gcc

[Lindenmaier, Goetz]

Hi Matthias,

change looks good. 

The context is different because "8209817: stack is executable when 
building with Clang on Linux" is missing in 11. This is a special build fix 
for google.

Best regards,
  Goetz.

> -Original Message-
> From: jdk-updates-dev  On
> Behalf Of Baesken, Matthias
> Sent: Donnerstag, 19. Dezember 2019 14:58
> To: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>
> Cc: Zeller, Arno 
> Subject: [CAUTION] RFR [XS] jdk11 - 8234809: set relro in linker flags when
> building with gcc
> 
> Hello,  please review  the jdk11 downport of  8234809 .
> 
> The patch form jdk/jdk  did not apply  directly   so  make/autoconf/flags-
> ldflags.m4   had to be adjusted a little bit for jdk11 .
> 
> Original discussion :
> 
> https://mail.openjdk.java.net/pipermail/build-dev/2019-
> November/026347.html
> 
> +
> 
> https://mail.openjdk.java.net/pipermail/build-dev/2019-
> November/026365.html
> 
> 
> 
> Bug/ jdk11 webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8234809
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8234809_jdk11.0/
> 
> Thanks, Matthias

RE: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system

[Lindenmaier, Goetz]

Hi Matthias, 

the change looks good. Thanks for fixing this.

Best regards,
  Goetz.

> -Original Message-
> From: Prasanta Sadhukhan 
> Sent: Dienstag, 26. November 2019 10:26
> To: Baesken, Matthias ; Erik Joelsson
> ; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>
> Cc: 2d-...@openjdk.java.net; Lindenmaier, Goetz
> 
> Subject: Re: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after
> 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with
> backslashes on macOS/JIS keyboard: Java ignores system settings
> 
> I have already raised a similar fix sometime back for JDK-8234786
> 
> Regards
> 
> Prasanta
> 
> On 26-Nov-19 2:49 PM, Baesken, Matthias wrote:
> > Hello,  here is a small adjustment  that uses the typealias  for
> NSTextInputSourceIdentifier .   This fixes the build on macOS  < 10.13 .
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8234795
> >
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/
> >
> >
> > Thanks, Matthias
> >
> >
> >> If there is a simple fix, I would very much like to see it done. I'm not
> >> familiar enough with this area to know what the implications would be
> >> though.
> >>
> >> /Erik
> >>
> >> On 2019-11-25 04:48, Baesken, Matthias wrote:
> >>> Hello,  any comments on the issue ?
> >>>
> >>> Could we maybe switch from using
> >>>
> >>> NSTextInputSourceIdentifier
> >>>
> >>> to
> >>>
> >>> String  (NSString* ?)   , because
> >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden
> >> tifier
> >>> says  NSTextInputSourceIdentifieris a typealias for String  ?
> >>>
> >>> Best regards ,Matthias
> >>>
> >>>
> >>>
> >>>
> >>> Hello, I noticed  that since today our  jdk/jdk  build fails on macOS . 
> >>> We run
> >> it on macOS 10.12 .
> >>> It seems
> >>> https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33
> >>>
> >>> 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java
> >> ignores system settings
> >>> Brought a  dependency on 10.13.  Was that intended ? Could we keep
> 10.12
> >> compatibility ?
> >>> At least  the doc of  NSTextInputSourceIdentifier  :
> >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden
> >> tifier
> >>> mentions  macOS 10.13+  .
> >>>
> >>>
> >>>
> >>> Build errors are :
> >>> 
> >>>
> >>> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5:
> >> error: unknown type name 'NSTextInputSourceIdentifier'
> >>>   NSTextInputSourceIdentifier kbdLayout;
> >>>   ^
> >>>
> >>
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23:
> >> error: assignment to readonly property
> >>>   self.cglLayer = windowLayer;
> >>>   ~ ^ ~~~
> >>>
> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1
> >> 9: error: assignment to readonly property
> >>>   self.cglLayer = nil;
> >>>   ~ ^ ~~~
> >>> 3 errors generated.
> >>>
> >>>
> >>> ...
> >>>
> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45
> >> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL'
> (aka
> >> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion]
> >>>   BOOL mouseIsOver = [[window contentView] mouseIsOver];
> >>>^ ~~
> >>> 2 errors generated.
> >>>
> >>>
> >>>
> >>> Best regards, Matthias

RE: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1)

[Lindenmaier, Goetz]

Hi Martin,

Yesterday I filed 
8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java on more 
platforms
as I found it is excluded on solaris and mac already. 

Thanks for the explanation.  
I will look at what freetype libs are used on the systems where this is failing.
Maybe we should mark the test with @key intermittent if it depends
on the system setup that much?

Best regards,
  Goetz.


> -Original Message-
> From: Martin Balao 
> Sent: Tuesday, May 14, 2019 6:41 PM
> To: Lindenmaier, Goetz ; 'Severin Gehwolf'
> ; Langer, Christoph ;
> jdk-updates-...@openjdk.java.net
> Cc: 2d-dev <2d-...@openjdk.java.net>; build-dev@openjdk.java.net;
> Martin Balao Alonso 
> Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure
> (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1)
> 
> Hi Goetz,
> 
> On 5/13/19 1:38 PM, Lindenmaier, Goetz wrote:
> >
> > Can I somehow verify that it's the font that has the problem?
> > Can I fix the font so that the test passes?
> >
> 
> I cannot say whether or not the static max advance value in each font is
> right or not, but let's assume it is. The underlying problem here is
> that OpenJDK uses a couple of internal FreeType library values to
> calculate the effects of algorithmic bold and italic in the max advance
> value -"algorithmic" means that the font is not italic or bold and is up
> to the rendering engine to generate the desired effect-. These values
> have changed over the years. What we did in 8218854 [1] was updating the
> italic value to the latest version and supporting bold in the
> calculation. Ideally, OpenJDK should not be tight to these values.
> However, that's not easy to get rid of unless we change the API or the
> API semantics. All this means that if you use OpenJDK 11 with an old
> Free Type library, you may have different values and the test may fail.
> 
> Note: this is just an hypothesis, I couldn't reproduce on my own.
> 
> I believe the test assertion is right if we consider API semantics only
> but we can put some constraints given reality.
> 
> Kind regards,
> Martin.-
> 
> --
> [1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7
> 

RE: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1)

[Lindenmaier, Goetz]

Hi Martin, 

Thanks for explaining the issue to me, that sounds reasonable.

Can I somehow verify that it's the font that has the problem?
Can I fix the font so that the test passes?

Best regards,
  Goetz.


> -Original Message-
> From: Martin Balao 
> Sent: Montag, 13. Mai 2019 18:27
> To: Lindenmaier, Goetz ; 'Severin Gehwolf'
> ; Langer, Christoph ; jdk-
> updates-...@openjdk.java.net
> Cc: 2d-dev <2d-...@openjdk.java.net>; build-dev@openjdk.java.net; Martin
> Balao Alonso 
> Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure
> (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1)
> 
> Hi Goetz,
> 
> Thanks for raising this issue.
> 
> I'm not surprised by MaxAdvanceIsMax test failing on some OS. The reason
> is that this test is very OS specific.
> 
> All installed fonts are tested and a static value from each font is used
> for the assertion, after scale calculations. If there is a difference
> between what the font creator set when generating the font file and what
> the OS rendering library returns -considering that different FreeType
> library builds may return different values-, this test will fail.
> 
> The internal test during development phase was more reliable because it
> tested a known-font only. However, shipping a font is not allowed by
> licenses and that's why we changed the test a bit.
> 
> We should probably limit the scope somehow.
> 
> Despite the test failure, I'm still confident that we did the right
> thing in 8218854 [1].
> 
> Kind regards,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8218854

RE: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1)

[Lindenmaier, Goetz]

Hi Severin,

Thanks for looking at the issue!

I can reproduce the issue starting the test stand alone.
So it's not a problem of our test infrastructure.

But I can only reproduce it on a limited set of OSes:

linuxppc64le:
Red Hat Enterprise Linux Server release 7.2 (Maipo)
Red Hat Enterprise Linux Server release 7.3 (Maipo)
SUSE Linux Enterprise Server 15

I cannot reproduce it on these OSes:

linuxppc64le:
Red Hat Enterprise Linux Server VERSION 7.4 (Maipo)
SUSE Linux Enterprise Server 12 (ppc64le) VERSION = 12 PATCHLEVEL = 1
Ubuntu 16.04.3 LTS

Unfortunately, I don't have RHEL 7.2 or 7.3 on a linuxx86_64
box.  But the test is passing on SLES 15 on linuxx86_64.

I didn't yet open a bug for this, but the failure
is still there with jdk-11.0.4+2.

Checking 11.0.3, I see the failure too. So it is not
a regression. I also can reproduce it with jdk/jdk
on RHEL 7.2.
Our nightly tests of 11.0.3 and jdk/jdk are scheduled
on a SLES 12.3, therefor they don't show the problem.

I'll send you a jtr file of the failure off-list.

Best regards,
  Goetz.


> -Original Message-
> From: Severin Gehwolf 
> Sent: Tuesday, May 7, 2019 5:20 PM
> To: Lindenmaier, Goetz ; Langer, Christoph
> ; jdk-updates-...@openjdk.java.net
> Cc: 2d-dev <2d-...@openjdk.java.net>; build-dev@openjdk.java.net;
> Martin Balao Alonso 
> Subject: Re: [11u] java/awt/FontMetrics/MaxAdvanceIsMax.java test failure
> (was: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1)
> 
> On Tue, 2019-05-07 at 14:51 +, Lindenmaier, Goetz wrote:
> > I checked the tests, and the only somewhat related
> > failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java,
> > but that is also failing without your patch.
> 
> How is it failing and has a bug been create for this failure if it's
> not a test setup issue?
> 
> https://bugs.openjdk.java.net/browse/JDK-8218854
> 
> FWIW, I have:
> 
> Passed: java/awt/FontMetrics/MaxAdvanceIsMax.java
> 
> Thanks,
> Severin

RE: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1

[Lindenmaier, Goetz]

Hi Christoph, 

I had a look at this change. 
The integration is good. 

I thought about the adaptions you had to do. 
They look good for the compilers you mention, and I 
would assume they also work with more recent ones.
I guess nobody uses more recent compilers on Solaris.
On AIX I know further adaptions are needed, and as 
they are missing it is ruled out anybody compiles with xlc 16.
So looks good, too.

I checked the tests, and the only somewhat related
failing one is java/awt/FontMetrics/MaxAdvanceIsMax.java,
but that is also failing without your patch.
So testing is fine.

Best regards,
  Goetz.




> -Original Message-
> From: jdk-updates-dev  On
> Behalf Of Langer, Christoph
> Sent: Dienstag, 30. April 2019 11:26
> To: jdk-updates-...@openjdk.java.net
> Cc: 2d-dev <2d-...@openjdk.java.net>; build-dev@openjdk.java.net; Baesken,
> Matthias 
> Subject: [CAUTION] [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1
> 
> Hi,
> 
> please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the
> latest 2.3.1.
> 
> This has been backported to 11.0.4-oracle already. I took the large change
> down to 11u-dev. It applies quite nicely, apart from a little issue in
> make/lib/Awt2dLibraries.gmk:
> 
> --- Awt2dLibraries.gmk
> +++ Awt2dLibraries.gmk
> @@ -613,8 +614,7 @@
>  type-limits missing-field-initializers implicit-fallthrough \
>  strict-aliasing undef unused-function, \
>  DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-
> overflow \
> -maybe-uninitialized \
> -missing-attributes class-memaccess, \
> +maybe-uninitialized class-memaccess, \
>  DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \
>  tautological-constant-out-of-range-compare int-to-pointer-cast \
>  sign-compare undef missing-field-initializers, \
> 
> The original change would remove the disabling of the "missing-attributes"
> warnings, but since this warning type is not disabled in jdk11u-dev 
> currently, I
> would just skip that diff.
> 
> With that change, most platforms did build fine, except for Solaris (where we
> use Oracle Studio 12u4 in jdk11u-dev vs Oracle Studio 12u6 in jdk/jdk) and AIX
> (xlc12 vs. xlc16).
> 
> To keep support for Oracle Studio 12u4 for Solaris, I had to remove the 
> warning
> flag "refmemnoconstr_aggr" from line 622 (as opposed to the original change).
> Seems that it is not yet supported in OS12u4.
> 
> Furthermore, a code tweak had to be done (Thanks, Matthias, for your help
> here):
> 
> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-
> common.hh Fri Mar 01 16:59:19 2019 -0800
> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-
> common.hh Mon Apr 29 16:26:41 2019 +0200
> @@ -280,6 +280,10 @@
> {
>str_buff_t 
>bool  drop_hints;
> +
> +  // Solaris: OS12u4 complains about "A class with a reference member lacks a
> user-defined constructor"
> +  // so provide the constructor
> +  flatten_param_t(str_buff_t& sbt, bool dh) : flatStr(sbt), drop_hints(dh) {}
> };
> 
> template 
> @@ -305,7 +309,9 @@
>  return false;
>cs_interpreter_t interp;
>interp.env.init (str, acc, fd);
> -  flatten_param_t  param = { flat_charstrings[i], drop_hints };
> +  // Solaris: OS12u4 does not like the C++11 style init
> +  // flatten_param_t  param = { flat_charstrings[i], drop_hints };
> +  flatten_param_t  param(flat_charstrings[i], drop_hints);
>if (unlikely (!interp.interpret (param)))
>  return false;
>  }
> 
> For AIX, this tweak had to be added (credit goes to Matthias as well):
> diff -r 2b3dbedfbfb9
> src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh
> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh  Fri
> Mar 01 16:59:19 2019 -0800
> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh
> Mon Apr 29 16:26:41 2019 +0200
> @@ -83,7 +83,9 @@
> 
> template 
> struct _hb_assign
> -{ static inline void value (T , const V v) { o = v; } };
> +// add cast to please AIX xlc12.1
> +//{ static inline void value (T , const V v) { o = v; } };
> +{ static inline void value (T , const V v) { o = (T&) v; } };
> template 
> struct _hb_assign
> >
> { static inline void value (T , const V v) { o.set (v); } };
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210782
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/7c11a7cc7c1d
> Review discussion for jdk/jdk: https://mail.openjdk.java.net/pipermail/2d-
> dev/2019-March/009914.html
> New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8210782.jdk11u/
> 
> Thanks & Best regards
> Christoph

RE: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris

[Lindenmaier, Goetz]

Looks good to me, thanks for downporting.

Best regards,
  Goetz.

> -Original Message-
> From: jdk-updates-dev  On
> Behalf Of Langer, Christoph
> Sent: Freitag, 22. März 2019 10:32
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; jdk-updates-
> d...@openjdk.java.net
> Subject: [CAUTION] RE: RFR [11u] : 8221318: [11u] do not disable c99 on
> Solaris
> 
> Hi Matthias,
> 
> first of all: The change looks good to me, +1.
> I assume you have run it through our build/test infrastructure and see no
> regressions...
> 
> As for the process:
> In your case, you want to backport a change and the original patch does not
> apply cleanly. For that scenario, you don't have to create a new bug (as JDK-
> 8221318 in your case). You should just ask for review under the original bug 
> id
> (JDK-8215710). When you have reviews and push approval, you need to push
> the change with the original patch message, referencing the original bug (JDK-
> 8215710). The hgupdater daemon will then create a new backport bug and
> creates the according links.
> 
> For your case, I've set fix version of JDK-8221318 to 11-pool. Then hgupdater
> will pick it up and resolve it for the right release. Maybe you ping me, when
> you're going to push, then we can check things together 
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: build-dev  On Behalf Of
> > Baesken, Matthias
> > Sent: Freitag, 22. März 2019 09:50
> > To: 'build-dev@openjdk.java.net' ; jdk-
> > updates-...@openjdk.java.net
> > Subject: [CAUTION] RFR [11u] : 8221318: [11u] do not disable c99 on Solaris
> >
> > Hello, please review this change.
> >
> > It is a downport of   jdk13 change
> > https://bugs.openjdk.java.net/browse/JDK-8215710 to  11u .
> >
> > JDK-8215710  removed the disabling of C99 on Solaris in jdk13.
> > Reason was :
> > "Currently we disable C99 in the Solaris build by setting -xc99=%none%.
> > This differs from a lot of other build environments like gcc/Linux or
> > VS2013/2017 on Windows where C99 features work.
> > We should remove this difference on Solaris and remove or replace the
> > setting. "
> >
> >
> > It would be helpful to have this downported to jdk11, because it would make
> > downporting changes easier (brings build settings of the releases closer
> > together) .
> > (I was already  running  into   one issue   because  of the  different build
> > settings )
> >
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8221318
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8221318.0/
> >
> >
> > Thanks, Matthias

RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX

[Lindenmaier, Goetz]

looks good, thanks for the adjustment!

Best regards,
  Goetz.

> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 5. Februar 2019 17:56
> To: Lindenmaier, Goetz ; David Holmes
> ; 'hotspot-...@openjdk.java.net'  d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com'
> 
> Cc: 'build-dev@openjdk.java.net' 
> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from
> xlc16 on AIX
> 
> Hi Götz, new webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/
> 
> 
> > The old xlc stuff is good to be removed.
> > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN
> > altogether and replace its only use by USE_XLC_BUILTINS?
> >
> 
> Done .
> 
> > Also, I think it makes sense to put
> >   #if __IBMCPP__ < 1000
> >   #error "xlc < 10 not supported"
> >   #endif
> > into the file.
> >
> > Probably we should even check for having at least xlc 12.
> 
> I added a check for xlc 12.
> Also  slightly changed the check for AIX  (_AIX macro)  in
> globalDefinitions_xlc.hpp  .
> 
> 
> >
> > The demangle fix is kind of preliminary, but to get the compiler
> > working it is acceptable to skip this code for now.
> >
> 
> There might be a fix for xlc16  in the future  but so far we have to live 
> with it.
> 
> 
> Best regards, Matthias
> 
> 
> 
> > -Original Message-
> > From: Lindenmaier, Goetz
> > Sent: Dienstag, 5. Februar 2019 09:59
> > To: Baesken, Matthias ; David Holmes
> > ; 'hotspot-...@openjdk.java.net'  > d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com'
> > 
> > Cc: 'build-dev@openjdk.java.net' 
> > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from
> > xlc16 on AIX
> >
> > Hi Matthias,
> >
> > The demangle fix is kind of preliminary, but to get the compiler
> > working it is acceptable to skip this code for now.
> >
> > The old xlc stuff is good to be removed.
> > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN
> > altogether and replace its only use by USE_XLC_BUILTINS?
> >
> > Also, I think it makes sense to put
> >   #if __IBMCPP__ < 1000
> >   #error "xlc < 10 not supported"
> >   #endif
> > into the file.
> >
> > Probably we should even check for having at least xlc 12.
> >
> > Best regards,
> >   Goetz.
> >
> > > -Original Message-
> > > From: hotspot-dev  On Behalf
> > Of
> > > Baesken, Matthias
> > > Sent: Montag, 4. Februar 2019 12:36
> > > To: David Holmes ; 'hotspot-
> > > d...@openjdk.java.net' ;
> > > 'magnus.ihse.bur...@oracle.com' 
> > > Cc: 'build-dev@openjdk.java.net' 
> > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from
> > > xlc16 on AIX
> > >
> > > Hi  David,  I  want to follow your suggestion  .
> > > I adjusted the comment , see  globalDefinitions_xlc.hpp  .
> > >
> > > Additionally I removed a  strange ifdef  handling pre-xlc10 versions  
> > > that are
> > > not useful  today any more for OpenJDK
> > > ( we  most likely cannot build jdk/jdk  with xlc versions < 10).
> > >
> > > New webrev :
> > >
> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/
> > >
> > >
> > > Best regards, Matthias
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: David Holmes 
> > > > Sent: Freitag, 1. Februar 2019 13:49
> > > > To: Baesken, Matthias ; 'hotspot-
> > > > d...@openjdk.java.net' ;
> > > > 'magnus.ihse.bur...@oracle.com' 
> > > > Cc: 'build-dev@openjdk.java.net' 
> > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from
> > > > xlc16 on AIX
> > > >
> > > > Hi Matthias,
> > > >
> > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote:
> > > > > New webrev :
> > > > >
> > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/
> > > > >
> > > > > - adjusted  globalDefinitions_xlc.hpp
> > > >
> > > > I don't think it makes sense to keep the comment which was obviously
> > > > copied from the gcc file:
> > > >
> > > >   // On Linux NULL is defined as a special type '__null'. Assigning
> > > > __null to
> > > >// integer variable will cause gcc warning. Use NULL_WORD in places
> > > > where a
> > > >// pointer is stored as integer value.  On some platforms,
> > > > sizeof(intptr_t) >
> > > >// sizeof(void*), so here we want something which is integer type,
> > > > but has the
> > > >// same size as a pointer.
> > > >
> > > > Rather something like:
> > > >
> > > > // Some platform/tool-chain combinations can't assign NULL to an integer
> > > > // type so we define NULL_WORD to use in those contexts. For xlc they
> > > > // are the same.
> > > >
> > > > Thanks,
> > > > David
> > > >
> > > >
> >
> 

RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX

[Lindenmaier, Goetz]

Hi Matthias, 

The demangle fix is kind of preliminary, but to get the compiler
working it is acceptable to skip this code for now.

The old xlc stuff is good to be removed. 
Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN
altogether and replace its only use by USE_XLC_BUILTINS?

Also, I think it makes sense to put 
  #if __IBMCPP__ < 1000
  #error "xlc < 10 not supported"
  #endif
into the file.

Probably we should even check for having at least xlc 12.

Best regards,
  Goetz.

> -Original Message-
> From: hotspot-dev  On Behalf Of
> Baesken, Matthias
> Sent: Montag, 4. Februar 2019 12:36
> To: David Holmes ; 'hotspot-
> d...@openjdk.java.net' ;
> 'magnus.ihse.bur...@oracle.com' 
> Cc: 'build-dev@openjdk.java.net' 
> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from
> xlc16 on AIX
> 
> Hi  David,  I  want to follow your suggestion  .
> I adjusted the comment , see  globalDefinitions_xlc.hpp  .
> 
> Additionally I removed a  strange ifdef  handling pre-xlc10 versions  that are
> not useful  today any more for OpenJDK
> ( we  most likely cannot build jdk/jdk  with xlc versions < 10).
> 
> New webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/
> 
> 
> Best regards, Matthias
> 
> 
> 
> > -Original Message-
> > From: David Holmes 
> > Sent: Freitag, 1. Februar 2019 13:49
> > To: Baesken, Matthias ; 'hotspot-
> > d...@openjdk.java.net' ;
> > 'magnus.ihse.bur...@oracle.com' 
> > Cc: 'build-dev@openjdk.java.net' 
> > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from
> > xlc16 on AIX
> >
> > Hi Matthias,
> >
> > On 1/02/2019 10:36 pm, Baesken, Matthias wrote:
> > > New webrev :
> > >
> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/
> > >
> > > - adjusted  globalDefinitions_xlc.hpp
> >
> > I don't think it makes sense to keep the comment which was obviously
> > copied from the gcc file:
> >
> >   // On Linux NULL is defined as a special type '__null'. Assigning
> > __null to
> >// integer variable will cause gcc warning. Use NULL_WORD in places
> > where a
> >// pointer is stored as integer value.  On some platforms,
> > sizeof(intptr_t) >
> >// sizeof(void*), so here we want something which is integer type,
> > but has the
> >// same size as a pointer.
> >
> > Rather something like:
> >
> > // Some platform/tool-chain combinations can't assign NULL to an integer
> > // type so we define NULL_WORD to use in those contexts. For xlc they
> > // are the same.
> >
> > Thanks,
> > David
> >
> >

RE: JDK-8217880 AIX build issue about JDK-8214533

[Lindenmaier, Goetz]

Pushed.

Best regards,
  Goetz

> -Original Message-
> From: Ichiroh Takiguchi 
> Sent: Dienstag, 29. Januar 2019 11:30
> To: Lindenmaier, Goetz 
> Cc: build-dev ; ppc-aix-port-dev  d...@openjdk.java.net>; core-libs-...@openjdk.java.net; Baesken, Matthias
> 
> Subject: RE: JDK-8217880 AIX build issue about JDK-8214533
> 
> Hello Goetz.
> 
> Thank you for build testing.
> 
> Yes, I need a sponsor.
> If possible, could you handle it ?
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-01-29 19:17, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > this looks good, the build works with this patch.
> > Do you need a sponsor?
> >
> > Best regards,
> >   Goetz.
> >
> >> -----Original Message-
> >> From: Ichiroh Takiguchi 
> >> Sent: Dienstag, 29. Januar 2019 02:21
> >> To: Lindenmaier, Goetz 
> >> Cc: build-dev ; ppc-aix-port-dev
> >>  >> d...@openjdk.java.net>; core-libs-...@openjdk.java.net; Baesken,
> >> Matthias
> >> 
> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533
> >>
> >> Hello.
> >>
> >> Sorry about build issue for JDK-8214533.
> >>
> >> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix.
> >>
> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8217880
> >> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/
> >>
> >> Could you review the fix ?
> >>
> >> Thanks,
> >> Ichiroh Takiguchi
> >> IBM Japan, Ltd.
> >>
> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
> >> > Hello Goetz.
> >> >
> >> > Thank you for your suggestion.
> >> > I just open JDK-8217880 [1].
> >> >
> >> > I just restart clean build.
> >> >
> >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
> >> >
> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880
> >> >
> >> > Thanks,
> >> > Ichiroh Takiguchi
> >> >
> >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
> >> >> Hi Ichiroh,
> >> >>
> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for
> >> >> it.
> >> >> I assume the fix is quite trivial so we can review it quick.
> >> >>
> >> >> Best regards,
> >> >>   Goetz.
> >> >>
> >> >>> -Original Message-
> >> >>> From: ppc-aix-port-dev 
> On
> >> >>> Behalf Of Ichiroh Takiguchi
> >> >>> Sent: Montag, 28. Januar 2019 14:13
> >> >>> To: Baesken, Matthias 
> >> >>> Cc: build-dev ; ppc-aix-port-dev
> >> >>>  >> >>> d...@openjdk.java.net>; core-libs-...@openjdk.java.net; Alan Bateman
> >> >>> 
> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
> >> >>> charset
> >> >>>
> >> >>> Hello.
> >> >>>
> >> >>> I'm very sorry. It's my fault.
> >> >>> EUC_JP class was moved to java.base module.
> >> >>> (sun.nio.cs.EUC_JP).
> >> >>>
> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
> >> >>> EUC_JP_Open.
> >> >>>
> >> >>> Could you suggest me how I should provide new webrev files ?
> >> >>>
> >> >>> Thanks,
> >> >>> Ichiroh Takiguchi
> >> >>>
> >> >>>
> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote:
> >> >>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
> >> >>> > we see build errors on AIX  ,  are they related to  this change ?
> >> >>> >
> >> >>> >
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Decoder extends EUC_JP.Decoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/suppor

RE: JDK-8217880 AIX build issue about JDK-8214533

[Lindenmaier, Goetz]

Hi,

this looks good, the build works with this patch.
Do you need a sponsor?

Best regards,
  Goetz.

> -Original Message-
> From: Ichiroh Takiguchi 
> Sent: Dienstag, 29. Januar 2019 02:21
> To: Lindenmaier, Goetz 
> Cc: build-dev ; ppc-aix-port-dev  d...@openjdk.java.net>; core-libs-...@openjdk.java.net; Baesken, Matthias
> 
> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533
> 
> Hello.
> 
> Sorry about build issue for JDK-8214533.
> 
> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix.
> 
> Bug:https://bugs.openjdk.java.net/browse/JDK-8217880
> Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/
> 
> Could you review the fix ?
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
> > Hello Goetz.
> >
> > Thank you for your suggestion.
> > I just open JDK-8217880 [1].
> >
> > I just restart clean build.
> >
> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880
> >
> > Thanks,
> > Ichiroh Takiguchi
> >
> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
> >> Hi Ichiroh,
> >>
> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for
> >> it.
> >> I assume the fix is quite trivial so we can review it quick.
> >>
> >> Best regards,
> >>   Goetz.
> >>
> >>> -Original Message-
> >>> From: ppc-aix-port-dev  On
> >>> Behalf Of Ichiroh Takiguchi
> >>> Sent: Montag, 28. Januar 2019 14:13
> >>> To: Baesken, Matthias 
> >>> Cc: build-dev ; ppc-aix-port-dev
> >>>  >>> d...@openjdk.java.net>; core-libs-...@openjdk.java.net; Alan Bateman
> >>> 
> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
> >>> charset
> >>>
> >>> Hello.
> >>>
> >>> I'm very sorry. It's my fault.
> >>> EUC_JP class was moved to java.base module.
> >>> (sun.nio.cs.EUC_JP).
> >>>
> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
> >>> EUC_JP_Open.
> >>>
> >>> Could you suggest me how I should provide new webrev files ?
> >>>
> >>> Thanks,
> >>> Ichiroh Takiguchi
> >>>
> >>>
> >>> On 2019-01-28 17:03, Baesken, Matthias wrote:
> >>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
> >>> > we see build errors on AIX  ,  are they related to  this change ?
> >>> >
> >>> >
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Decoder extends EUC_JP.Decoder {
> >>> >^
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Encoder extends EUC_JP.Encoder {
> >>> >^
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Decoder extends EUC_JP.Decoder {
> >>> >^
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Encoder extends EUC_JP.Encoder {
> >>> >
> >>> > Best regards, Matthias
> >>> >
> >>> >
> >>> >
> >>> >> -Original Message-
> >>> >> From: ppc-aix-port-dev 
> On
> >>> >> Behalf Of Ichiroh Takiguchi
> >>> >> Sent: Dienstag, 15. Januar 2019 01:51
> >>> >

RE: RFR: 8214533 IBM-29626C is required for AIX default charset

[Lindenmaier, Goetz]

Hi Ichiroh, 

just open a bug, like "Fix aix build after 8214533" and post a RFR for it. 
I assume the fix is quite trivial so we can review it quick.

Best regards,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev  On
> Behalf Of Ichiroh Takiguchi
> Sent: Montag, 28. Januar 2019 14:13
> To: Baesken, Matthias 
> Cc: build-dev ; ppc-aix-port-dev  d...@openjdk.java.net>; core-libs-...@openjdk.java.net; Alan Bateman
> 
> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default charset
> 
> Hello.
> 
> I'm very sorry. It's my fault.
> EUC_JP class was moved to java.base module.
> (sun.nio.cs.EUC_JP).
> 
> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
> EUC_JP_Open.
> 
> Could you suggest me how I should provide new webrev files ?
> 
> Thanks,
> Ichiroh Takiguchi
> 
> 
> On 2019-01-28 17:03, Baesken, Matthias wrote:
> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
> > we see build errors on AIX  ,  are they related to  this change ?
> >
> >
> > /nb/rs6000_64/nightly/output-jdk-
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
> > error: Decoder is not public in EUC_JP; cannot be accessed from
> > outside package
> > private static class Decoder extends EUC_JP.Decoder {
> >^
> > /nb/rs6000_64/nightly/output-jdk-
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
> > error: Encoder is not public in EUC_JP; cannot be accessed from
> > outside package
> > private static class Encoder extends EUC_JP.Encoder {
> >^
> > /nb/rs6000_64/nightly/output-jdk-
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
> > error: Decoder is not public in EUC_JP; cannot be accessed from
> > outside package
> > private static class Decoder extends EUC_JP.Decoder {
> >^
> > /nb/rs6000_64/nightly/output-jdk-
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
> > error: Encoder is not public in EUC_JP; cannot be accessed from
> > outside package
> > private static class Encoder extends EUC_JP.Encoder {
> >
> > Best regards, Matthias
> >
> >
> >
> >> -Original Message-
> >> From: ppc-aix-port-dev  On
> >> Behalf Of Ichiroh Takiguchi
> >> Sent: Dienstag, 15. Januar 2019 01:51
> >> To: Alan Bateman 
> >> Cc: build-dev ; ppc-aix-port-dev  >> port-...@openjdk.java.net>; core-libs-...@openjdk.java.net
> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default
> >> charset
> >>
> >> Hello Alan.
> >>
> >> Could you review the fix again ?
> >>
> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/
> >>
> >> I added IBM29626C charset as standard way.
> >> Please give any suggestion and question.
> >>
> >> Thanks,
> >> Ichiroh Takiguchi
> >> IBM Japan, Ltd.
> >>
> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote:
> >> > Hello Alan.
> >> >
> >> > I opened JDK-8215333 for Charset filtering issue [1].
> >> > I cannot wait until JDK-8215333 is closed.
> >> > Is it possible to put IBM-29626C charset with standard way ?
> >> >
> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333
> >> >
> >> > Thanks,
> >> > Ichiroh Takiguchi
> >> >
> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote:
> >> >> Hello Roger, Magnus and Alan.
> >> >> I may need to put alias information into charsets file.
> >> >> stdcs-xxx cannot handle this information...
> >> >>
> >> >> Still AIX needs IBM-29626C charset for default encoding...
> >> >>
> >> >> I appreciate if you give me further suggestions.
> >> >>
> >> >> Thanks,
> >> >> Ichiroh Takiguchi
> >> >>
> >> >> On 2018-12-10 20:50, Alan Bateman wrote:
> >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote:
> >>  On 2018-12-07 21:20, Roger Riggs wrote:
> >> > Hi,
> >> >
> >> > It is a nice feature that charsets are selected at build time using
> >> > the stdcs-xxx files.
> >> > This change breaks that pattern and embeds os specific information
> >> > in more than one place.
> >> > That does not seem like an improvement.  Is there any alternative?
> >>  I agree. Why is it not enough just to add it to stdcs-aix?
> >> >>> My reading of the patch is that the "os" key is to avoid generating
> >> >>> it
> >> >>> on non-AIX platforms, it will otherwise end up in jdk.charsets on
> >> >>> non-AIX platforms. The general direction is welcome but I think
> >> >>> further work and discussion will be needed to get the right set of
> >> >>> changes to support filtering in the build. It can probably be
> >> >>> separated from the changes to add IBM-29626C to AIX's java.base.
> >> >>>
> >> >>> -Alan

RE: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

[Lindenmaier, Goetz]

Hi Volker, 

I had a look at your change. It looks good. 
I appreciate a lot you added a check in configure.
Maybe it would be better to pass a WITHOUT_XRANDR
or the like to the build, and check for such a define
in the code.
But I think we should push this change for now to fix the build.
A follow up still can re-enable xrandr on AIX again or 
prettify the code.

Best regards,
  Goetz.


> -Original Message-
> From: 2d-dev <2d-dev-boun...@openjdk.java.net> On Behalf Of Philip Race
> Sent: Thursday, November 15, 2018 6:02 PM
> To: Volker Simonis 
> Cc: 2d-dev <2d-...@openjdk.java.net>; build-dev  d...@openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the
> removal of Xrandr.h and add a configure check for it
> 
> PS I am not sure why xrandr headers would not be available for AIX.
> They are a standard part of the xdistribution.
> 
> If true, think what you are going to have to do is add a
> --with-xrandr-include option
> and provide it that way.
> 
> -phil.
> 
> On 11/15/18, 8:55 AM, Philip Race wrote:
> > Hmm. I don't like the ifdefs.
> >
> > Xrandr is a requirement for the build. If its not there at runtime
> > that's OK.
> >
> > -phil.
> >
> > On 11/15/18, 8:06 AM, Volker Simonis wrote:
> >> Hi,
> >>
> >> can I please have a review for the following small change:
> >>
> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8213944/
> >> https://bugs.openjdk.java.net/browse/JDK-8213944
> >>
> >> Change JDK-8210863 removed the Xrandr.h/randr.h headers from the
> >> OpenJDK sources but forgot to add a configure check for the Xrandr
> >> extension which is now a build dependency.
> >>
> >> The change also broke the AIX build. AIX never supported Xrandr, but
> >> that was only detected at runtime, when the JDK was unable to
> >> dynamically load libXrand.so. Now, without Xrandr.h/randr.h in the
> >> source tree any more, we have to conditionally compile some parts of
> >> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c such
> >> that it doesn't require the definitions and declarations from
> >> Xrandr.h/randr.h any more.
> >>
> >> Thank you and best regards,
> >> Volker

RE: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

[Lindenmaier, Goetz]

Still looks good (now touches much more scenarios, but we should 
get this straight.)

Best regards,
  Goetz.

> -Original Message-
> From: hotspot-runtime-dev  boun...@openjdk.java.net> On Behalf Of Volker Simonis
> Sent: Montag, 8. Oktober 2018 12:11
> To: Doerr, Martin 
> Cc: build-dev ; hotspot-runtime-
> d...@openjdk.java.net runtime 
> Subject: Re: RFR(XS): 8211837: Creation of the default CDS Archive should
> depend on ENABLE_CDS
> 
> Hi Martin, Goetz,
> 
> thanks for reviewing my patch! As Aleksey posted a similar patch for
> fixing the Zero build I've extended my patch to handle
> zero/minimal/core as well.
> 
> In fact the patch now disables CDS on AIX, minimal, core and zero
> unless the user explicitly requests it with the help of
> `--with-jvm-features=cds`. The configuration variant with
> `--with-jvm-features=-cds` should now also be handled correctly (I
> hope caught all possible combinations :)
> 
> If CDS is disabled, the creation of the default class list and default
> archive will now be disabled as well.
> 
> @Aleksey Shipilev : can you please check if this new version of my
> patch also works for you?
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/
> 
> Thank you and best regards,
> Volker
> On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin 
> wrote:
> >
> > Hi Volker,
> >
> > looks good. Thanks for fixing.
> > Of course, it would be great if this could be used to fix minimal/zero 
> > build,
> too.
> >
> > Best regards,
> > Martin
> >
> >
> > -Original Message-
> > From: hotspot-runtime-dev  boun...@openjdk.java.net> On Behalf Of Volker Simonis
> > Sent: Montag, 8. Oktober 2018 10:19
> > To: build-dev ; hotspot-runtime-
> d...@openjdk.java.net runtime 
> > Subject: RFR(XS): 8211837: Creation of the default CDS Archive should
> depend on ENABLE_CDS
> >
> > Hi,
> >
> > can I please have a review for the following trivial build fix:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/
> > https://bugs.openjdk.java.net/browse/JDK-8211837
> >
> > It makes no sense to try to create a default CDS archive on VMs which
> > don't support CDS at all. We already have '--enable_cds' which
> > defaults to 'true' on all platforms except AIX.
> >
> > The check for '--enable_cds_archive' should use the result of
> > '--enable_cds' (which is saved in "ENABLE_CDS") and only enable
> > default archive creation if CDS is enabled.
> >
> > Failure to do so currently breaks the AIX build (after JDK-)8202951 was
> pushed).
> >
> > Thank you and best regards,
> > Volker

RE: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

[Lindenmaier, Goetz]

Hi Volker, Aleksey, 

Voker, your change looks good. 

I also think CDS should be turned off on minimal VM, 
and also the case for zero a few lines below should
be removed in a similar manner.  But I'll leave to you 
whether you want to handle that in a separate fix.

Best regards,
  Goetz.



> -Original Message-
> From: hotspot-runtime-dev  boun...@openjdk.java.net> On Behalf Of Volker Simonis
> Sent: Montag, 8. Oktober 2018 10:19
> To: build-dev ; hotspot-runtime-
> d...@openjdk.java.net runtime 
> Subject: RFR(XS): 8211837: Creation of the default CDS Archive should
> depend on ENABLE_CDS
> 
> Hi,
> 
> can I please have a review for the following trivial build fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/
> https://bugs.openjdk.java.net/browse/JDK-8211837
> 
> It makes no sense to try to create a default CDS archive on VMs which
> don't support CDS at all. We already have '--enable_cds' which
> defaults to 'true' on all platforms except AIX.
> 
> The check for '--enable_cds_archive' should use the result of
> '--enable_cds' (which is saved in "ENABLE_CDS") and only enable
> default archive creation if CDS is enabled.
> 
> Failure to do so currently breaks the AIX build (after JDK-)8202951 was
> pushed).
> 
> Thank you and best regards,
> Volker

RE: JEP JDK-8208089: Implement C++14 Language Features

[Lindenmaier, Goetz]

Hi Kim,

> for XLC 16.  Any information about "some C++14 features"?  I haven't
> found any detail on that.
we will user our internal connections to IBM to find out :)

Best regards,
  Goetz.

> -Original Message-
> From: Kim Barrett 
> Sent: Donnerstag, 4. Oktober 2018 23:01
> To: Lindenmaier, Goetz 
> Cc: hotspot-dev developers ; build-dev
> ; core-libs-...@openjdk.java.net
> Subject: Re: JEP JDK-8208089: Implement C++14 Language Features
> 
> > On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz
>  wrote:
> >
> > Hi,
> >
> > I appreciate this is handled in a JEP and well communicated!
> >
> > XLc, the compiler we use for AIX, might be a bottleneck here.
> >
> > But we currently have no compiler-constraints by products on
> > our aix port of jdk12 (for jdk11 we must stay with the current
> > compiler xlc 12 which does not support C++11, and jdk11 even
> > should be compilable with aCC by HP for which we won't
> > get new versions!)
> >
> > We will update our compiler for jdk/jdk to the most recent Xlc
> > as soon as possible.
> > To my current knowledge, Xlc 14 was dropped, and xlc 16
> > is to be released early 2019.  It is supposed to support
> > C++ 11, and also some C++ 14 features.
> 
> The information I've been able to find mostly discusses Linux support
> for XLC 16.  Any information about "some C++14 features"?  I haven't
> found any detail on that.
> 
> I am working toward being able to target this for JDK 12, but realize
> that might not be reachable.  Windows is already there, because of
> VS2017 support.  There are a couple of minor patches needed for gcc
> and clang based builds; Linux-x64 and MacOSX-x64 have had a fair
> amount of ad hoc testing.  We (Oracle) only switched over the
> Solaris/sparc builds to the necessary compiler version (Oracle Studio
> 12.6) very recently, and there are some issues still to be dealt with
> there.  And the currently used XLC is just not up to the change.

RE: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling

[Lindenmaier, Goetz]

Thanks!

I'm fine for this to go to 8.

Best regards,
  Goetz.

> -Original Message-
> From: Severin Gehwolf 
> Sent: Donnerstag, 4. Oktober 2018 16:40
> To: Lindenmaier, Goetz ; Erik Joelsson
> ; hotspot-dev  d...@openjdk.java.net>; ppc-aix-port-dev  d...@openjdk.java.net>; build-dev 
> 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 +, 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 
> On
> > > Behalf Of Severin Gehwolf
> > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > To: Erik Joelsson ; hotspot-dev  > > d...@openjdk.java.net>; ppc-aix-port-dev  > > d...@openjdk.java.net>; build-dev 
> > > 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
> > > > >
> > > >
> > > >
> >
> >

RE: JEP JDK-8208089: Implement C++14 Language Features

[Lindenmaier, Goetz]

Hi,

I appreciate this is handled in a JEP and well communicated!

XLc, the compiler we use for AIX, might be a bottleneck here.

But we currently have no compiler-constraints by products on 
our aix port of jdk12 (for jdk11 we must stay with the current 
compiler xlc 12 which does not support C++11, and jdk11 even
should be compilable with aCC by HP for which we won't
get new versions!)

We will update our compiler for jdk/jdk to the most recent Xlc
as soon as possible.
To my current knowledge, Xlc 14 was dropped, and xlc 16
is to be released early 2019.  It is supposed to support
C++ 11, and also some C++ 14 features.

Best regards,
  Goetz.



> -Original Message-
> From: core-libs-dev  On Behalf
> Of Kim Barrett
> Sent: Mittwoch, 3. Oktober 2018 21:13
> To: hotspot-dev developers 
> Cc: build-dev ; core-libs-
> d...@openjdk.java.net
> Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features
> 
> 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

RE: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling

[Lindenmaier, Goetz]

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 
> Sent: Dienstag, 2. Oktober 2018 15:00
> To: Lindenmaier, Goetz ; Erik Joelsson
> ; hotspot-dev  d...@openjdk.java.net>; ppc-aix-port-dev  d...@openjdk.java.net>; build-dev 
> 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 +, 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 
> > > Sent: Dienstag, 2. Oktober 2018 13:09
> > > To: Lindenmaier, Goetz ; Erik Joelsson
> > > ; hotspot-dev  > > d...@openjdk.java.net>; ppc-aix-port-dev  > > d...@openjdk.java.net>; build-dev 
> > > 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 +, 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  boun...@openjdk.java.net>
> > >
> > > On
> > > > > Behalf Of Severin Gehwolf
> > > > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > > > To: Erik Joelsson ; hotspot-dev  > > > > d...@openjdk.java.net>; ppc-aix-port-dev  > > > > d...@openjdk.java.net>; build-dev 
> > > > > 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
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >

RE: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling

[Lindenmaier, Goetz]

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 
> Sent: Dienstag, 2. Oktober 2018 13:09
> To: Lindenmaier, Goetz ; Erik Joelsson
> ; hotspot-dev  d...@openjdk.java.net>; ppc-aix-port-dev  d...@openjdk.java.net>; build-dev 
> 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 +, 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 
> On
> > > Behalf Of Severin Gehwolf
> > > Sent: Dienstag, 2. Oktober 2018 12:34
> > > To: Erik Joelsson ; hotspot-dev  > > d...@openjdk.java.net>; ppc-aix-port-dev  > > d...@openjdk.java.net>; build-dev 
> > > 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
> > > > >
> > > >
> > > >
> >
> >

RE: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling

[Lindenmaier, Goetz]

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  On
> Behalf Of Severin Gehwolf
> Sent: Dienstag, 2. Oktober 2018 12:34
> To: Erik Joelsson ; hotspot-dev  d...@openjdk.java.net>; ppc-aix-port-dev  d...@openjdk.java.net>; build-dev 
> 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
> > >
> >
> >

RE: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

[Lindenmaier, Goetz]

Hi,

We are only talking about reducing O3 to O2 for the compilation 
step of fdlibm, right?
As I know, this is being replaced by Java coding, anyways.
Therefore I don't have a strong opinion for any of the 
choices.

Best regards,
  Goetz.

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Gustavo Romero
> Sent: Freitag, 14. September 2018 01:30
> To: Severin Gehwolf ; David Holmes
> ; Erik Joelsson ;
> build-dev ; core-libs-dev  d...@openjdk.java.net>
> Subject: Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-
> optimized compilation
> 
> Hello Severin,
> 
> On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
> > Hi David,
> >
> > On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> >> Hi Severin,
> >>
> >> Sorry I'm a bit confused now.
> >>
> >> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
> >> HIGH. But now it will be LOW due to:
> >>
> >> 45 ifneq ($(FDLIBM_CFLAGS), )
> >> 46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> >>
> >> as those platforms will use gcc/clang with support for -ffp-contract and
> >> so FDLIBM_CFLAGS will not be empty.
> >>
> >> ??
> >
> > Correct. That was done based on Andrew Haley's comment here:
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-
> September/023160.html
> >
> > I've done some measurements with -O2 and -O3. -O2 is sufficient for a
> > 2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
> > the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
> > sin/cos on ppc64le.
> >
> > Since the difference between them were not huge, I've used -O2, a.k.a
> > LOW. See also:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/microbenchmarks_results/
> >
> > To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
> > == -O2 on gcc arches. Does that clear things up?
> >
> > FWIW, I'm happy to change it back to HIGH if there are concerns. See
> > also Gustavo's reply here for some more data points:
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-
> September/023193.html
> 
> I'm wondering why the possible issue of using -O3 on fdlibm would not affect
> other parts of the JVM code (like the Opto code in libjvm.so) that afaics
> are also built using -O3. Also, the gap of 1.05 for sin/cos, for instance,
> still sounds like a regression to me.
> 
> Maybe a better approach to this would be to figure out a way to test -O3 and
> -O2 with the real world case in which -O3 can have a bad impact. I'm not
> sure if SPECjbb would qualify for that.
> 
> 
> Best regards,
> Gustavo
> 
> > Thanks,
> > Severin
> >
> >> David
> >>
> >> On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
> >>> Hi Erik,
> >>>
> >>> Thanks for the review!
> >>>
> >>> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>  Hello Severin,
> 
>  Even if using the macro, I still think you need to add a condition on
>  the compiler types where the switch can be reasonably expected to
> exist.
> >>>
> >>> How about this?
> >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/webrev.05/
> >>>
> >>> Thanks,
> >>> Severin
> >>>
>  On 2018-09-11 05:02, Severin Gehwolf wrote:
> > On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> >> I see. I was not aware of that issue, but we clearly need to file a bug
> >> for it and fix it. In this case I think it's fine to us the macro 
> >> however.
> >
> > OK. Update webrev, which now uses
> FLAGS_COMPILER_CHECK_ARGUMENTS.
> >
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/webrev.04/
> >
> > Micro-benchmark results from running [1] for x86_64 and ppc64le are
> > here (-O2 is sufficient it seems):
> >
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/microbenchmarks_results/
> >
> > More thoughts?
> >
> > Thanks,
> > Severin
> >
> > [1] https://github.com/gromero/strictmath/
> >
> 
> 
> >

RE: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

[Lindenmaier, Goetz]

Yes, that's fine. 

I can sponsor it tomorrow. I'm not in the office today.

Best regards,
  Goetz.

> -Original Message-
> From: Andrew Leonard 
> Sent: Donnerstag, 6. September 2018 12:29
> To: Magnus Ihse Bursie ; Lindenmaier, Goetz
> 
> Cc: 2d-dev <2d-...@openjdk.java.net>; Brian Burkhalter
> ; build-dev ; core-
> libs-dev ; Philip Race
> 
> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
> 
> Thanks Magnus,
> 
> Hi Goetz, we have agreement from both library owners, so I think we're good
> now?
> Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leon...@uk.ibm.com
> 
> 
> 
> 
> From:Magnus Ihse Bursie 
> To:Andrew Leonard 
> Cc:    Brian Burkhalter , 2d-dev <2d-
> d...@openjdk.java.net>, build-dev , core-libs-dev
> , "Lindenmaier, Goetz"
> , Philip Race 
> Date:04/09/2018 16:41
> Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors 
> on
> zLinux
> 
> 
> 
> 
> 
> 
> Looks good to me.
> 
> /Magnus
> 
> 4 sep. 2018 kl. 12:11 skrev Andrew Leonard  <mailto:andrew_m_leon...@uk.ibm.com> >:
> 
> Hi Brian/Goetz,
> Yes, that seems sensible. I have created a new webrev with fdlibm compiler
> option disabled, and mediaLib code fixed:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/
> <http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/>
> I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3.
> 
> Are we good to go?
> Thanks
> Andrew
> 
> hg export:
> # HG changeset patch
> # User aleonard
> # Date 1536055438 -3600
> #  Tue Sep 04 11:03:58 2018 +0100
> # Node ID c2523f285c503e8f82f1212b38de1cb54093255e
> # Parent  3ee91722550680c18b977f0e00b1013323b5c9ef
> 8209786: JDK12 fails to build on s390x with gcc 7.3
> 
> diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk
> --- a/make/lib/CoreLibraries.gmkTue Sep 04 14:47:55 2018 +0800
> +++ b/make/lib/CoreLibraries.gmkTue Sep 04 11:03:58 2018 +0100
> @@ -68,7 +68,7 @@
>   CFLAGS_linux_ppc64le := -ffp-contract=off, \
>   CFLAGS_linux_s390x := -ffp-contract=off, \
>   CFLAGS_linux_aarch64 := -ffp-contract=off, \
> -  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \
> +  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-
> bounds, \
>   DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>   ARFLAGS := $(ARFLAGS), \
>   OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \
> diff -r 3ee917225506 -r c2523f285c50
> src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> Tue Sep 04 14:47:55 2018 +0800
> +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> Tue Sep 04 11:03:58 2018 +0100
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. 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
> @@ -259,18 +259,18 @@
>   }
> 
> #ifdef _LITTLE_ENDIAN
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>   ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask);
> 
> #else /* _NO_LONGLONG */
> 
> #ifdef _LITTLE_ENDIAN
> -  mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
> +  mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
> #else
> -  mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
> +  mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
> 
>   ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) |
> (((mlib_u64*)da)[0] &~ emask);
> @@ -395,9 +395,9 @@
>   }
> 
> #ifdef _LITTLE_ENDIAN
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) &

RE: Configure: Does enabling graal automatically disable cmsgc?

[Lindenmaier, Goetz]

Hi Magnus,

Ok, I understand, isGraalEnabled is a runtime check, not a 
check what was set at compile time of the JVM. And the 
two tier-4 comilers can be there both.
So I understand the check in the test.

Thanks,
  Goetz

> -Original Message-
> From: Magnus Ihse Bursie 
> Sent: Freitag, 31. August 2018 12:07
> To: Lindenmaier, Goetz ; hotspot compiler
> ; build-dev (build-
> d...@openjdk.java.net) 
> Subject: Re: Configure: Does enabling graal automatically disable cmsgc?
> 
> On 2018-08-31 11:39, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I'm just fixing
> jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java
> >
> > It is not checking correctly whether ZGC is enabled.
> >
> > I found this code in the test:
> > if (!Compiler.isGraalEnabled()) { // Graal does not support CMS
> >testExec(8, "-XX:+UseConcMarkSweepGC", "", "", false);
> > }
> >
> > I think this should test for GC.CMS.isSupported(). I would like to
> > fix this, too.
> > But this would require that configuring with graal disables cmsgc.
> > (Which seems to be what is desired given the comment above.)
> > Is this the case?
> 
> Maybe I'm confused here, but are you not mixing up configure options and
> run-time options? Both graal and CMS require run-time options to be
> enabled, right? So it's an error to enable both of them. But that does
> not prohibit you to build a JVM that has support for both Graal and CMS
> (as long as you only enable at most one of them at a time).
> 
> /Magnus

Configure: Does enabling graal automatically disable cmsgc?

[Lindenmaier, Goetz]

Hi,

I'm just fixing jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java

It is not checking correctly whether ZGC is enabled. 

I found this code in the test:
if (!Compiler.isGraalEnabled()) { // Graal does not support CMS
  testExec(8, "-XX:+UseConcMarkSweepGC", "", "", false);
}

I think this should test for GC.CMS.isSupported(). I would like to 
fix this, too.
But this would require that configuring with graal disables cmsgc.
(Which seems to be what is desired given the comment above.)
Is this the case?

Best regards,
  Goetz.

Which build platforms are supported for jdk11 and upcoming jdk12?

[Lindenmaier, Goetz]

Hi,

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
is quite outdated, listing only jdk9.
Is there a different site now listing this information?

(I'll also update our information on this site.)

Because of https://bugs.openjdk.java.net/browse/JDK-8210194
we think about updating our compilers used for jdk12.

Best regards,
  Goetz.

RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

[Lindenmaier, Goetz]

Hi Leonard,

Whom should I add as reviewers?  (Besides me :))

Best regards,
  Goetz.

> -Original Message-
> From: Andrew Leonard 
> Sent: Donnerstag, 30. August 2018 17:02
> To: Lindenmaier, Goetz 
> Cc: Brian Burkhalter ; build-dev (build-
> d...@openjdk.java.net) ; core-libs-
> d...@openjdk.java.net
> Subject: RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> Thanks Goetz,
> I've created an hg export below..
> I've not used jdk-submit, i've tested it locally on xLinux and zLinux.
> Cheers
> Andrew
> 
> # HG changeset patch
> # User aleonard
> # Date 1535641094 -3600
> #  Thu Aug 30 15:58:14 2018 +0100
> # Node ID 592a8ad8d4c16287c316d018a0a402148720718b
> # Parent  1ddd1ec044311512c55643bed641859e78b9d25e
> 8209786: disable gcc warnings for libmlib & libfdlibm to enable gcc 7.3 on
> zLinux
> 
> diff -r 1ddd1ec04431 -r 592a8ad8d4c1 make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk   Thu Aug 30 09:08:23 2018 -0400
> +++ b/make/lib/Awt2dLibraries.gmk   Thu Aug 30 15:58:14 2018 +0100
> @@ -55,6 +55,7 @@
>  OPTIMIZATION := HIGHEST, \
>  CFLAGS := $(CFLAGS_JDKLIB) \
>  $(BUILD_LIBMLIB_CFLAGS), \
> +DISABLED_WARNINGS_gcc := shift-negative-value, \
>  LDFLAGS := $(LDFLAGS_JDKLIB) \
>  $(call SET_SHARED_LIBRARY_ORIGIN), \
>  LIBS := $(JDKLIB_LIBS), \
> diff -r 1ddd1ec04431 -r 592a8ad8d4c1 make/lib/CoreLibraries.gmk
> --- a/make/lib/CoreLibraries.gmkThu Aug 30 09:08:23 2018 -0400
> +++ b/make/lib/CoreLibraries.gmkThu Aug 30 15:58:14 2018 +0100
> @@ -68,7 +68,7 @@
>CFLAGS_linux_ppc64le := -ffp-contract=off, \
>CFLAGS_linux_s390x := -ffp-contract=off, \
>CFLAGS_linux_aarch64 := -ffp-contract=off, \
> -  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \
> +  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation
> array-bounds, \
>DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>ARFLAGS := $(ARFLAGS), \
>OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \
> 
> 
> 
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leon...@uk.ibm.com
> 
> 
> 
> 
> From:"Lindenmaier, Goetz" 
> To:Andrew Leonard , Brian
> Burkhalter 
> Cc:"core-libs-...@openjdk.java.net"  d...@openjdk.java.net>, "build-dev (build-dev@openjdk.java.net)"  d...@openjdk.java.net>
> Date:30/08/2018 15:36
> Subject:RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> 
> 
> 
> 
> 
> Hi Leonard,
> 
> the change looks good to me.
> I'll test it tonight, to make sure it runs with our compilers.
> Did you run it through jdk-submit?
> 
> If you supply a patch with all the changeset information (like
> from hg export) that jchecks fine, I'll sponsor this for you.
> 
> Best regards,
>  Goetz.
> 
> > -Original Message-
> > From: core-libs-dev  On Behalf
> > Of Andrew Leonard
> > Sent: Donnerstag, 30. August 2018 14:19
> > To: Brian Burkhalter 
> > Cc: core-libs-...@openjdk.java.net
> > Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> >
> > Hi Brian,
> > Thanks for taking a look at this, I have just done a rebuild with a new
> > patch with appropriate gcc disable warnings for these libraries:
> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/
> <http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/>
> > This works fine, so if you think this is a more favourable approach for
> > these libraries? i'd like to get this merged please.
> > Thanks
> > Andrew
> >
> > Andrew Leonard
> > Java Runtimes Development
> > IBM Hursley
> > IBM United Kingdom Ltd
> > Phone internal: 245913, external: 01962 815913
> > internet email: andrew_m_leon...@uk.ibm.com
> >
> >
> >
> >
> > From:   Brian Burkhalter 
> > To: Andrew Leonard 
> > Cc: core-libs-...@openjdk.java.net
> > Date:   28/08/2018 15:52
> > Subject:Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> >
> >
> >
> > Hi Andrew,
> >
> > It was suggested that it would be preferable to dial down the compilation
> > settings for the fdlibm code rather than make a source code change. Was
> > this investigated?
> >
> > Thanks,
> >
> > Brian
> >
> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard
> > 
> > wrote:
> >

RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

[Lindenmaier, Goetz]

Hi Leonard, 

the change looks good to me. 
I'll test it tonight, to make sure it runs with our compilers. 
Did you run it through jdk-submit?

If you supply a patch with all the changeset information (like 
from hg export) that jchecks fine, I'll sponsor this for you.

Best regards,
  Goetz.

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Andrew Leonard
> Sent: Donnerstag, 30. August 2018 14:19
> To: Brian Burkhalter 
> Cc: core-libs-...@openjdk.java.net
> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/
> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leon...@uk.ibm.com
> 
> 
> 
> 
> From:   Brian Burkhalter 
> To: Andrew Leonard 
> Cc: core-libs-...@openjdk.java.net
> Date:   28/08/2018 15:52
> Subject:Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> 
> 
> Hi Andrew,
> 
> It was suggested that it would be preferable to dial down the compilation
> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
> 
> Thanks,
> 
> Brian
> 
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard
> 
> wrote:
> 
> We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's
> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>  - validating loop test array bounds
>  - left shifts of negative values
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/
> 
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
> 
> I'd like to request a sponsor for this fix please?
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU

RE: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp)

[Lindenmaier, Goetz]

Hi Matthias,

Aix is a nuisance.  Thanks for fixing this.
Looks good.

As this is a build fix, and only changes tests, I think you don't need
to follow the 24h rule, i.e., you can push it sooner.

Best regards,
  Goetz.

From: Baesken, Matthias
Sent: Donnerstag, 30. August 2018 13:21
To: 'hotspot-...@openjdk.java.net' ; 
'build-dev@openjdk.java.net' 
Cc: Lindenmaier, Goetz ; Doerr, Martin 

Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example 
getstacktr001.cpp)

Hello,  please review this small fix to repair our AIX build .
Recent changes to jdk/jdk broke  the  build .

We  get clashes   with defines from system headers  in a few compilation units, 
for example :


"/openjdk/nb/rs6000_64/nightly/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/getstacktr001.cpp",
 line 69.9: 1540-0848 (S)
The macro name "NUMBER_OF_FRAMES" is already defined with a different 
definition.
"/usr/include/sys/mstsave.h", line 260.9: 1540-0425 (I) "NUMBER_OF_FRAMES" is 
defined on line 260 of "/usr/include/sys/mstsave.h".



Renaming NUMBER_OF_FRAMES  fixes the issue.

Bug :

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


webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8210205/



Thanks, Matthias

RE: 8207830: [aix] disable jfr in build and tests

[Lindenmaier, Goetz]

Thanks Erik!

Best regards,
  Goetz.

> -Original Message-
> From: Erik Joelsson 
> Sent: Donnerstag, 19. Juli 2018 19:33
> To: Vladimir Kozlov ; Lindenmaier, Goetz
> ; hotspot-dev developers  d...@openjdk.java.net>
> Cc: build-dev 
> Subject: Re: 8207830: [aix] disable jfr in build and tests
> 
> Build changes look good.
> 
> /Erik
> 
> 
> On 2018-07-19 10:22, Vladimir Kozlov wrote:
> > Tests changes are good.
> >
> > Thank you for fixing aot check in hotspot.m4
> >
> > In VMProps.java I would suggest to follow code pattern from other
> > features. Add new method vmHasJFR() which returns "true" or "false"
> > instead of:
> >
> > map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
> >
> > We may need such method to add other conditions in future.
> >
> > Thanks,
> > Vladimir
> >
> > On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
> >> Hi,
> >>
> >> We didn't manage to port JFR to aix in the jdk11 time frame.
> >> Thus I would like to disable it in the build.
> >> As well, I would like to introduce @requires vm.hasJFR which
> >> will disable the tests on aix, and also on linuxsparcv9 and zero.
> >>
> >> Two webrevs for better readability:
> >> This contains the functional changes
> >> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
> >> This contains adding @requires.
> >> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
> >
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
> >
> >> The only one not straight forward is
> >> runtime/appcds/sharedStrings/FlagCombo.java
> >>
> >> Best regards,
> >>    Goetz.
> >>

RE: 8207830: [aix] disable jfr in build and tests

[Lindenmaier, Goetz]

Hi Vladimir, 

Thanks for looking at my change. 

> Thank you for fixing aot check in hotspot.m4
I guess this does no harm if aot is enabled, but I saw it on aix.

> Add new method vmHasJFR()
Fixed.

New partial webrev:
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/02/
The other part is unchanged.

Best regards,
  Goetz.


> -Original Message-
> From: Vladimir Kozlov 
> Sent: Thursday, July 19, 2018 7:22 PM
> To: Lindenmaier, Goetz ; hotspot-dev
> developers 
> Cc: build-dev 
> Subject: Re: 8207830: [aix] disable jfr in build and tests
> 
> Tests changes are good.
> 
> Thank you for fixing aot check in hotspot.m4
> 
> In VMProps.java I would suggest to follow code pattern from other
> features. Add new method vmHasJFR() which returns "true" or "false"
> instead of:
> 
> map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
> 
> We may need such method to add other conditions in future.
> 
> Thanks,
> Vladimir
> 
> On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > We didn't manage to port JFR to aix in the jdk11 time frame.
> > Thus I would like to disable it in the build.
> > As well, I would like to introduce @requires vm.hasJFR which
> > will disable the tests on aix, and also on linuxsparcv9 and zero.
> >
> > Two webrevs for better readability:
> > This contains the functional changes
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
> > This contains adding @requires.
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
> 
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
> 
> > The only one not straight forward is
> runtime/appcds/sharedStrings/FlagCombo.java
> >
> > Best regards,
> >Goetz.
> >

RE: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)

[Lindenmaier, Goetz]

Hi Thomas, 

thanks for fixing and doing the cleanup right away. 
Looks good.

Best regards,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> boun...@openjdk.java.net] On Behalf Of Thomas Stüfe
> Sent: Mittwoch, 13. Juni 2018 08:14
> To: build-dev ; ppc-aix-port-
> d...@openjdk.java.net
> Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
> 
> Hi all,
> 
> may I have reviews for this small build fix:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204935
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8204935-aix-toc-
> overflow/webrev.00/webrev/
> 
> We finally have reached the point where even the standard (not gtest)
> release build libjvm.so got too large and blew its TOC. Hurray for
> templates. On the bright side, no need to keep different flags for
> different libjvm variants anymore.
> 
> Kudos to whoever added auto-automake to the build, that makes these
> kind of changes really easier :)
> 
> Thank you,
> 
> Best Regards, Thomas

RE: RFR(xs): 8202325: [aix] disable warnings-as-errors by default

[Lindenmaier, Goetz]

Hi Thomas, 

this looks good and will simplify building on AIX.

Thanks,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> boun...@openjdk.java.net] On Behalf Of Thomas Stüfe
> Sent: Donnerstag, 26. April 2018 16:04
> To: build-dev ; ppc-aix-port-
> d...@openjdk.java.net
> Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
> 
> Hi all,
> 
> may I have reviews please:
> 
> https://bugs.openjdk.java.net/browse/JDK-8202325
> http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-
> as-errors/webrev.00/webrev/
> 
> We decided to disable warnings as errors by default on AIX. This is a
> pragmatic decision - we will never be able to fix all the many xlC
> warnings and the build since long only worked when disabling
> warnings-as-errors.
> 
> So, might as well make this the default.
> 
> Best regards, Thomas

RE: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483

[Lindenmaier, Goetz]

Thanks Magnus and Volker!

Best regards,
  Goetz.

> -Original Message-
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> Sent: Montag, 16. April 2018 14:56
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; build-dev (build-
> d...@openjdk.java.net) <build-dev@openjdk.java.net>
> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
> 
> On 2018-04-16 14:15, Lindenmaier, Goetz wrote:
> > Hi Magnus,
> >
> > yes, that works too:
> > http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/
> > Can I push this right away if I get a second review?
> You don't need a second review for build changes, it's a hotspot team
> rule. You can push it right away now.
> 
> /Magnus
> >
> > Best regards,
> >   Goetz
> >
> >> -Original Message-
> >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> >> Sent: Montag, 16. April 2018 14:00
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; build-dev (build-
> >> d...@openjdk.java.net) <build-dev@openjdk.java.net>
> >> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
> >>
> >> On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> could I please get reviewes for this tiny fix?
> >>> Grep does not grok the syntax of the replacement of space to newline.
> >>> It causes configure failures on SLES 11.
> >>>
> >>> http://cr.openjdk.java.net/~goetz/wr18/8201584-
> fixSLES11configure/01/
> >> Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)
> >>
> >> Goetz, please try this patch instead, which uses the new
> >> BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works
> >> correctly on
> >> SLES 11 as well.
> >>
> >> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> >> --- a/make/autoconf/hotspot.m4
> >> +++ b/make/autoconf/hotspot.m4
> >> @@ -443,7 +443,7 @@
> >>    AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])
> >>
> >>    # Validate features (for configure script errors, not user errors)
> >> -    INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}"
> <<<
> >> "${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
> >> +    BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES,
> >> $JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
> >>    if test "x$INVALID_FEATURES" != x; then
> >>      AC_MSG_ERROR([Internal configure script error. Invalid JVM
> >> feature(s): $INVALID_FEATURES])
> >>    fi
> >>
> >> /Magnus

RE: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483

[Lindenmaier, Goetz]

Hi Magnus, 

yes, that works too:
http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/
Can I push this right away if I get a second review?

Best regards,
 Goetz

> -Original Message-
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> Sent: Montag, 16. April 2018 14:00
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; build-dev (build-
> d...@openjdk.java.net) <build-dev@openjdk.java.net>
> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
> 
> On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > could I please get reviewes for this tiny fix?
> > Grep does not grok the syntax of the replacement of space to newline.
> > It causes configure failures on SLES 11.
> >
> > http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/
> Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)
> 
> Goetz, please try this patch instead, which uses the new
> BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works
> correctly on
> SLES 11 as well.
> 
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -443,7 +443,7 @@
>   AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])
> 
>   # Validate features (for configure script errors, not user errors)
> -    INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}" <<<
> "${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
> +    BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES,
> $JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
>   if test "x$INVALID_FEATURES" != x; then
>     AC_MSG_ERROR([Internal configure script error. Invalid JVM
> feature(s): $INVALID_FEATURES])
>   fi
> 
> /Magnus

RFR(XS): 8201584: Fix configure on SLES 11 after 8201483

[Lindenmaier, Goetz]

Hi, 

could I please get reviewes for this tiny fix? 
Grep does not grok the syntax of the replacement of space to newline.
It causes configure failures on SLES 11.

http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/

Best regards,
  Goetz.

RE: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

[Lindenmaier, Goetz]

HI Thomas, 

looks good, thanks!

Best regards,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> boun...@openjdk.java.net] On Behalf Of Thomas Stüfe
> Sent: Donnerstag, 8. Februar 2018 15:42
> To: ppc-aix-port-...@openjdk.java.net; build-dev  d...@openjdk.java.net>
> Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in
> fastdebug build
> 
> Hi,
> 
> may I please have reviews for this tiny fix:
> 
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-
> overflow-in-fastdebug/webrev.00/webrev/
> 
> Thanks and Kind Regards, Thomas

RE: RFR 8190378: Java EE and CORBA modules removal

[Lindenmaier, Goetz]

Hi Lance, 

Would you mind to add similar change as for 
test/jdk/tools/launcher/VersionCheck.java
also for 
test/jdk/tools/launcher/HelpFlagsTest.java

That test is pretty recent which is why you may have missed it.
It will not fail though, there will just be left over stuff in it.

Best regards,
  Goetz.


-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf 
Of Lance Andersen
Sent: Wednesday, February 7, 2018 5:57 PM
To: core-libs-dev ; build-dev 

Subject: RFR 8190378: Java EE and CORBA modules removal

Hi all,

I think we are at a point where we are ready to start reviewing  the changes to 
remove the Java EE and CORBA modules as JEP 320, JDK-8189188,  has been  
targeted to JDK 11.
The CSR for removing the modules has been approved: 
https://bugs.openjdk.java.net/browse/JDK-8193757 


 The open webrev can be found at:  
http://cr.openjdk.java.net/~lancea/8190378/open_changes/ 


To make the open review easier, I have broken the changes into 5 webrevs:
build changes are: 
http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ 

miscellaneous changes are at:  
http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ 

module changes are at: 
http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ 

rmic changes are at:  
http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ 

test changes are at: 
http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ 


As part of  the removal, the following issues have also been logged:
Removal of the Java EE and CORBA tools from the documentation: 
https://bugs.openjdk.java.net/browse/JDK-8193906 

Updating the RMIC man pages for the removal of the -iiop and -idl options: 
https://bugs.openjdk.java.net/browse/JDK-8196510 

Hotspot tests may require further updating or just removed: 
https://bugs.openjdk.java.net/browse/JDK-8194310 

jdeprescan will need updates due to the removal of the Java EE and CORBA 
modules: https://bugs.openjdk.java.net/browse/JDK-8194308 




Best,
Lance

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

RE: AIX build not generating a jre image

[Lindenmaier, Goetz]

Hi Steve, 

I think this is an error. 
We never decided not to generate a jre image as far as I know.

Best regards,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> boun...@openjdk.java.net] On Behalf Of Steve Groeger
> Sent: Mittwoch, 18. Oktober 2017 14:34
> To: ppc-aix-port-...@openjdk.java.net
> Subject: AIX build not generating a jre image
> 
> Hi all,
> 
> When building OpenJDK9 on AIX should the build generate a JRE image ie
> build/aix-ppc64-normal-server-release/images/jre/bin as well as a JDK image
> ie build/aix-ppc64-normal-server-release/images/jdk/bin?  When I try
> building on my AIX system it is only generating a JDK image. Is this a issue 
> or is
> it working correctly?
> 
> 
> Thanks
> Steve Groeger
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groe...@uk.ibm.com 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU

RE: RFR(xs): 8187228: [aix] make data segment page size 64K by default

[Lindenmaier, Goetz]

Hi Thomas, 

someone from Oracle must push this as they need to regenerate the 
generated_configure.sh file.
So you need a sponsor.

Best regards,
  Goetz.

> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Mittwoch, 18. Oktober 2017 12:01
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Erik Joelsson
> <erik.joels...@oracle.com>
> Cc: ppc-aix-port-...@openjdk.java.net; build-dev  d...@openjdk.java.net>
> Subject: Re: RFR(xs): 8187228: [aix] make data segment page size 64K by
> default
> 
> Hi Goetz, Eric,
> 
> I was unable to commit this patch before the jdk10 repo consolidation and
> would like to do so now.
> 
> Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-
> data-segment-page-size-64K-by-default/webrev.01/webrev/
> 
> Nothing changed, the webrev is just rebased to the new repo.
> 
> I am unclear whether I am allowed to push this on my own? Does the build
> group this?
> 
> Kind Regards, Thomas
> 
> 
> On Thu, Sep 7, 2017 at 2:33 PM, Thomas Stüfe <thomas.stu...@gmail.com
> <mailto:thomas.stu...@gmail.com> > wrote:
> 
> 
>   Thank you Goetz!
> 
>   On Thu, Sep 7, 2017 at 2:18 PM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com <mailto:goetz.lindenma...@sap.com> >
> wrote:
> 
> 
>   Hi Thomas,
> 
>   Looks good.
> 
>   Best regards,
> Goetz.
> 
>   > -Original Message-
>   > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> <mailto:ppc-aix-port-dev->
>   > boun...@openjdk.java.net
> <mailto:boun...@openjdk.java.net> ] On Behalf Of Thomas Stüfe
>   > Sent: Donnerstag, 7. September 2017 12:02
>   > To: ppc-aix-port-...@openjdk.java.net <mailto:ppc-aix-
> port-...@openjdk.java.net> ; build-dev> d...@openjdk.java.net <mailto:d...@openjdk.java.net> >
>   > Subject: RFR(xs): 8187228: [aix] make data segment page
> size 64K by default
>   >
>   > Hi all,
>   >
>   > may I please have a review for the following AIX-only patch.
>   >
>   > Issue:
>   > https://bugs.openjdk.java.net/browse/JDK-8187228
> <https://bugs.openjdk.java.net/browse/JDK-8187228>
>   > <https://bugs.openjdk.java.net/browse/JDK-8187228
> <https://bugs.openjdk.java.net/browse/JDK-8187228> >
>   >
>   >
>   > webrev:
>   > http://cr.openjdk.java.net/~stuefe/webrevs/8187228-
> make-data-segment-
> <http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data-
> segment->
>   > page-size-64K-by-default/webrev.00/webrev/
>   > <http://cr.openjdk.java.net/~stuefe/webrevs/8187228-
> make-data- <http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-
> data->
>   > segment-page-size-64K-by-default/webrev.00/webrev/>
> 
>   >
>   >
>   > It changes the default page size for the data segment (C-
> heap and Posix
>   > Thread Stacks) to 64K.
>   >
>   >
>   > For completeness and simplicity sake, it also changes
> default page size for
>   > text segment and primordial thread stacl to 64K, but that
> does not matter
>   > much.
>   >
>   > For more details, please see the issue description.
>   >
>   > Thank you, Thomas
> 
> 
> 

RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack

[Lindenmaier, Goetz]

Hi David, 

thanks a lot!

Best regards,
  Goetz. 

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Dienstag, 26. September 2017 05:29
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; hotspot-runtime-
> d...@openjdk.java.net; build-dev <build-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8187045: [linux] Not all libraries in the VM are linked
> with -z,noexecstack
> 
> Hi Goetz,
> 
> I'll sponsor this for you.
> 
> David
> 
> On 22/09/2017 11:00 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I updated my webrev to the directory structure:
> > http://cr.openjdk.java.net/~goetz/wr17/8187045-
> execstackLink/webrev.02/
> > I also ran it through our tests again.
> >
> > Could someone please sponsor this change?
> >
> > Thanks,
> >Goetz.
> >
> >
> >> -Original Message-
> >> From: Lindenmaier, Goetz
> >> Sent: Dienstag, 5. September 2017 10:05
> >> To: David Holmes <david.hol...@oracle.com>; hotspot-runtime-
> >> d...@openjdk.java.net; build-dev <build-dev@openjdk.java.net>
> >> Subject: RE: RFR(M): 8187045: [linux] Not all libraries in the VM are 
> >> linked
> >> with -z,noexecstack
> >>
> >> Hi David,
> >>
> >> thanks for looking at my change!
> >>> Hi Goetz,
> >>>
> >>> On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote:
> >>>> Hi,
> >>>>
> >>>> I found that not all libraries are linked with -z,noexecstack.
> >>>> This lead to errors with our linuxppc64 build.  The linker omitted
> >>>> the flag altogether, which is interpreted as a lib with execstack.
> >>>>
> >>>> This change contains a small test that scans all libraries in the tested 
> >>>> VM
> >>>> to have the noexecstack flag set. It utilizes the elf parser in the VM 
> >>>> for
> >> this.
> >>>> Further -z,noexecstack is now passed to all libraries.
> >>>>
> >>>> Please review this change. I please need a sponsor.
> >>>> http://cr.openjdk.java.net/~goetz/wr17/8187045-
> >>> execstackLink/webrev.01/
> >>>
> >>> So IIUC presently we only set noexecstack for gcc on linux when building
> >>> libjvm - via the JVM_LDFLAGS settings.
> >> Yes.
> >>
> >>> With this change we also set it for building JDK libraries via the
> >>> LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited
> >>> to gcc and linux ??
> >> LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on
> linux,
> >> on other platforms its empty.
> >>
> >>> In addition we want to build libjsig with noexecstack, and we do that by
> >>> exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in
> >>> CompileLibjsig.gmk. I don't have an issue with the use of noexecstack
> >>> but I think it could just have been hard-wired for linux just as the
> >>> bulk of the flags set in that file are. Granted you copied what is done
> >>> for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important
> >>> that the same hash style be used throughout. Anyway minor stylistic nit
> >>> which may be moot soon as once we have the consolidated repo I think
> >>> libjsig could be handled the same as others libs?
> >> I had hoped to find a location where flags that should be used in all 
> >> linking
> >> steps are assembled.  Noexecstack should really be set in any lib we build.
> >> But I didn't find that, so I implemented it as with the HASH_STYLE. I don't
> >> really like it this way because if a new lib is added it might be forgotten
> >> to add the noexecstack.
> >> But I assume after the repo consolidation the build will be reshaped,
> >> so now is not the right time to seek for optimal setups.
> >>
> >> Best regards,
> >>Goetz.
> >>
> >>>   >
> >>> http://cr.openjdk.java.net/~goetz/wr17/8187045-
> >> execstackLink/webrev.01-
> >>> hs/
> >>>
> >>> Test changes look okay to me.
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>>> Best regards,
> >>>> Goetz.
> >>>>

RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack

[Lindenmaier, Goetz]

Hi,

I updated my webrev to the directory structure:
http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.02/
I also ran it through our tests again.

Could someone please sponsor this change?

Thanks,
  Goetz.


> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Dienstag, 5. September 2017 10:05
> To: David Holmes <david.hol...@oracle.com>; hotspot-runtime-
> d...@openjdk.java.net; build-dev <build-dev@openjdk.java.net>
> Subject: RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked
> with -z,noexecstack
> 
> Hi David,
> 
> thanks for looking at my change!
> > Hi Goetz,
> >
> > On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote:
> > > Hi,
> > >
> > > I found that not all libraries are linked with -z,noexecstack.
> > > This lead to errors with our linuxppc64 build.  The linker omitted
> > > the flag altogether, which is interpreted as a lib with execstack.
> > >
> > > This change contains a small test that scans all libraries in the tested 
> > > VM
> > > to have the noexecstack flag set. It utilizes the elf parser in the VM for
> this.
> > > Further -z,noexecstack is now passed to all libraries.
> > >
> > > Please review this change. I please need a sponsor.
> > > http://cr.openjdk.java.net/~goetz/wr17/8187045-
> > execstackLink/webrev.01/
> >
> > So IIUC presently we only set noexecstack for gcc on linux when building
> > libjvm - via the JVM_LDFLAGS settings.
> Yes.
> 
> > With this change we also set it for building JDK libraries via the
> > LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited
> > to gcc and linux ??
> LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on linux,
> on other platforms its empty.
> 
> > In addition we want to build libjsig with noexecstack, and we do that by
> > exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in
> > CompileLibjsig.gmk. I don't have an issue with the use of noexecstack
> > but I think it could just have been hard-wired for linux just as the
> > bulk of the flags set in that file are. Granted you copied what is done
> > for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important
> > that the same hash style be used throughout. Anyway minor stylistic nit
> > which may be moot soon as once we have the consolidated repo I think
> > libjsig could be handled the same as others libs?
> I had hoped to find a location where flags that should be used in all linking
> steps are assembled.  Noexecstack should really be set in any lib we build.
> But I didn't find that, so I implemented it as with the HASH_STYLE. I don't
> really like it this way because if a new lib is added it might be forgotten
> to add the noexecstack.
> But I assume after the repo consolidation the build will be reshaped,
> so now is not the right time to seek for optimal setups.
> 
> Best regards,
>   Goetz.
> 
> >  >
> > http://cr.openjdk.java.net/~goetz/wr17/8187045-
> execstackLink/webrev.01-
> > hs/
> >
> > Test changes look okay to me.
> >
> > Thanks,
> > David
> >
> > > Best regards,
> > >Goetz.
> > >

RE: RFR(xs): 8187228: [aix] make data segment page size 64K by default

[Lindenmaier, Goetz]

Hi Thomas,

Looks good.

Best regards,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> boun...@openjdk.java.net] On Behalf Of Thomas Stüfe
> Sent: Donnerstag, 7. September 2017 12:02
> To: ppc-aix-port-...@openjdk.java.net; build-dev  d...@openjdk.java.net>
> Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default
> 
> Hi all,
> 
> may I please have a review for the following AIX-only patch.
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8187228
> 
> 
> 
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data-segment-
> page-size-64K-by-default/webrev.00/webrev/
>  segment-page-size-64K-by-default/webrev.00/webrev/>
> 
> 
> It changes the default page size for the data segment (C-heap and Posix
> Thread Stacks) to 64K.
> 
> 
> For completeness and simplicity sake, it also changes default page size for
> text segment and primordial thread stacl to 64K, but that does not matter
> much.
> 
> For more details, please see the issue description.
> 
> Thank you, Thomas

RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack

[Lindenmaier, Goetz]

Hi David, 

thanks for looking at my change!
> Hi Goetz,
> 
> On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I found that not all libraries are linked with -z,noexecstack.
> > This lead to errors with our linuxppc64 build.  The linker omitted
> > the flag altogether, which is interpreted as a lib with execstack.
> >
> > This change contains a small test that scans all libraries in the tested VM
> > to have the noexecstack flag set. It utilizes the elf parser in the VM for 
> > this.
> > Further -z,noexecstack is now passed to all libraries.
> >
> > Please review this change. I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/wr17/8187045-
> execstackLink/webrev.01/
> 
> So IIUC presently we only set noexecstack for gcc on linux when building
> libjvm - via the JVM_LDFLAGS settings.
Yes.

> With this change we also set it for building JDK libraries via the
> LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited
> to gcc and linux ??
LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on linux, 
on other platforms its empty.

> In addition we want to build libjsig with noexecstack, and we do that by
> exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in
> CompileLibjsig.gmk. I don't have an issue with the use of noexecstack
> but I think it could just have been hard-wired for linux just as the
> bulk of the flags set in that file are. Granted you copied what is done
> for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important
> that the same hash style be used throughout. Anyway minor stylistic nit
> which may be moot soon as once we have the consolidated repo I think
> libjsig could be handled the same as others libs?
I had hoped to find a location where flags that should be used in all linking
steps are assembled.  Noexecstack should really be set in any lib we build.
But I didn't find that, so I implemented it as with the HASH_STYLE. I don't 
really like it this way because if a new lib is added it might be forgotten
to add the noexecstack.
But I assume after the repo consolidation the build will be reshaped, 
so now is not the right time to seek for optimal setups.  

Best regards,
  Goetz.
 
>  >
> http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.01-
> hs/
> 
> Test changes look okay to me.
> 
> Thanks,
> David
> 
> > Best regards,
> >Goetz.
> >

RE: RFR(M): 8186978: Introduce configure argument enable-cds

[Lindenmaier, Goetz]

Hi David, 

thanks for sponsoring the change!

Best regards,
  Goetz.

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Donnerstag, 31. August 2017 23:15
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; 'Magnus Ihse Bursie'
> <magnus.ihse.bur...@oracle.com>; hotspot-runtime-
> d...@openjdk.java.net; build-dev (build-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds
> 
> Hi Goetz,
> 
> I will sponsor this.
> 
> Thanks,
> David
> 
> On 1/09/2017 12:49 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > thanks for reviewing everybody!
> > Yes, works fine without that assignment. New webrev:
> > http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.02/
> >
> > Could someone please sponsor? I think autogen.sh needs to be run
> > before submitting.
> >
> > Best regards,
> >Goetz.
> >
> >> -Original Message-
> >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> >> Sent: Thursday, August 31, 2017 3:35 PM
> >> To: David Holmes <david.hol...@oracle.com>; Lindenmaier, Goetz
> >> <goetz.lindenma...@sap.com>; hotspot-runtime-...@openjdk.java.net;
> >> build-dev (build-dev@openjdk.java.net) <build-dev@openjdk.java.net>
> >> Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds
> >>
> >>
> >>
> >> On 2017-08-31 14:47, David Holmes wrote:
> >>> Hi Goetz,
> >>>
> >>> On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote:
> >>>> Hi,
> >>>>
> >>>> Tests for class data sharing (cds) are enabled if @requires vm.cds is
> >>>> true.
> >>>> The property vm.cds depends on the preprocessor macro
> ENABLE_CDS.
> >> ... but you mean INCLUDE_CDS. :-)
> >>
> >>>> This can not yet be switched by configure. It's only disabled
> >>>> automatically
> >>>> for the minimal build.
> >>>>
> >>>> This change introduces enable-cds with default true, which only takes
> >>>> effect
> >>>> in the non-minimal build. If disabled, generate-classlist is
> >>>> disabled, too.
> >>>>
> >>>> Please review this change. I please need a sponsor.
> >>>> http://cr.openjdk.java.net/~goetz/wr17/8186978-
> >> disableCDS/webrev.01/index.html
> >>>>
> >>>
> >>> I'll let the build guys comment in detail, but the structure for this
> >>> doesn't quite look right to me. I don't understand why you have in
> >>> spec.gmk.in:
> >>>
> >>> + ENABLE_CDS:=@ENABLE_CDS@
> >>>
> >>> when in the hotspot build CDS is controlled via the feature setting:
> >>>
> >>> ifneq ($(call check-jvm-feature, cds), true)
> >>>
> >>> which you are already handling. ??
> >>
> >> Agree, the ENABLE_CDS variable is only used internally in the configure
> >> script and need not/should not be exported in spec.gmk.in. As David
> >> says, the test ($(call check-jvm-feature, cds), true) is enough to
> >> determine if to send the -DINCLUDE_CDS to the compiler.
> >>
> >> Just remove the changes to spec.gmk.in, and I'm ok with the patch.
> >>
> >> /Magnus
> >>
> >>
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>>
> >>>> Best regards,
> >>>> Goetz.
> >>>>
> >

RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack

[Lindenmaier, Goetz]

Hi Magnus, 

thanks for looking at my change.

Thanks for forwarding to the proper list. I'm often not sure what's the right 
one,
and sometimes it's ambiguous anyways. Like this one, which concerns stack 
overflow
handling. The same problem exists with all the categories of the Jira bugs.

Best regards,
 Goetz.

> -Original Message-
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> Sent: Montag, 4. September 2017 10:42
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; hotspot-runtime-
> d...@openjdk.java.net; build-dev <build-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8187045: [linux] Not all libraries in the VM are linked
> with -z,noexecstack
> 
> Hi Goetz,
> 
> Since this is mostly a build change, it need to be reviewed on build-dev.
> 
> However, it looks good to me from a build perspective. I have not
> reviewed the hotspot test files.
> 
> /Magnus
> 
> On 2017-09-01 15:05, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I found that not all libraries are linked with -z,noexecstack.
> > This lead to errors with our linuxppc64 build.  The linker omitted
> > the flag altogether, which is interpreted as a lib with execstack.
> >
> > This change contains a small test that scans all libraries in the tested VM
> > to have the noexecstack flag set. It utilizes the elf parser in the VM for 
> > this.
> > Further -z,noexecstack is now passed to all libraries.
> >
> > Please review this change. I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/wr17/8187045-
> execstackLink/webrev.01/
> > http://cr.openjdk.java.net/~goetz/wr17/8187045-
> execstackLink/webrev.01-hs/
> >
> > Best regards,
> >Goetz.

RE: RFR(M): 8186978: Introduce configure argument enable-cds

[Lindenmaier, Goetz]

Hi,

thanks for reviewing everybody!
Yes, works fine without that assignment. New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.02/

Could someone please sponsor? I think autogen.sh needs to be run
before submitting.

Best regards,
  Goetz.

> -Original Message-
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> Sent: Thursday, August 31, 2017 3:35 PM
> To: David Holmes <david.hol...@oracle.com>; Lindenmaier, Goetz
> <goetz.lindenma...@sap.com>; hotspot-runtime-...@openjdk.java.net;
> build-dev (build-dev@openjdk.java.net) <build-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds
> 
> 
> 
> On 2017-08-31 14:47, David Holmes wrote:
> > Hi Goetz,
> >
> > On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote:
> >> Hi,
> >>
> >> Tests for class data sharing (cds) are enabled if @requires vm.cds is
> >> true.
> >> The property vm.cds depends on the preprocessor macro ENABLE_CDS.
> ... but you mean INCLUDE_CDS. :-)
> 
> >> This can not yet be switched by configure. It's only disabled
> >> automatically
> >> for the minimal build.
> >>
> >> This change introduces enable-cds with default true, which only takes
> >> effect
> >> in the non-minimal build. If disabled, generate-classlist is
> >> disabled, too.
> >>
> >> Please review this change. I please need a sponsor.
> >> http://cr.openjdk.java.net/~goetz/wr17/8186978-
> disableCDS/webrev.01/index.html
> >>
> >
> > I'll let the build guys comment in detail, but the structure for this
> > doesn't quite look right to me. I don't understand why you have in
> > spec.gmk.in:
> >
> > + ENABLE_CDS:=@ENABLE_CDS@
> >
> > when in the hotspot build CDS is controlled via the feature setting:
> >
> > ifneq ($(call check-jvm-feature, cds), true)
> >
> > which you are already handling. ??
> 
> Agree, the ENABLE_CDS variable is only used internally in the configure
> script and need not/should not be exported in spec.gmk.in. As David
> says, the test ($(call check-jvm-feature, cds), true) is enough to
> determine if to send the -DINCLUDE_CDS to the compiler.
> 
> Just remove the changes to spec.gmk.in, and I'm ok with the patch.
> 
> /Magnus
> 
> 
> >
> > Thanks,
> > David
> >
> >
> >> Best regards,
> >>Goetz.
> >>

RFR(M): 8186978: Introduce configure argument enable-cds

[Lindenmaier, Goetz]

Hi,

Tests for class data sharing (cds) are enabled if @requires vm.cds is true. 
The property vm.cds depends on the preprocessor macro ENABLE_CDS. 
This can not yet be switched by configure. It's only disabled automatically 
for the minimal build. 

This change introduces enable-cds with default true, which only takes effect 
in the non-minimal build. If disabled, generate-classlist is disabled, too.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.01/index.html

Best regards,
  Goetz.

RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

[Lindenmaier, Goetz]

Ah, ok, so this is fine.

Best regards,
  Goetz.

> -Original Message-
> From: Erik Joelsson [mailto:erik.joels...@oracle.com]
> Sent: Montag, 21. November 2016 14:27
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Vladimir Kozlov
> <vladimir.koz...@oracle.com>; build-dev <build-dev@openjdk.java.net>;
> core-libs-dev <core-libs-...@openjdk.java.net>; hotspot-dev developers
> <hotspot-...@openjdk.java.net>
> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux
> and Solaris images
> 
> Hello Goetz,
> 
> Thanks for trying this out. Note that the ergo* files were removed in
> JDK-8169001 which is currently in jdk9/dev but not yet in hs.
> 
> /Erik
> 
> 
> On 2016-11-21 14:10, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > linuxx86_64 has the same issue.  I tested it with the jdk9/hs repo:
> >
> > jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function
> ServerClassMachineImpl:
> > jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected )
> before LIBARCHNAME
> >
> > Best regards,
> >Goetz
> >
> >> -Original Message-
> >> From: Lindenmaier, Goetz
> >> Sent: Montag, 21. November 2016 12:35
> >> To: 'Vladimir Kozlov' <vladimir.koz...@oracle.com>; Erik Joelsson
> >> <erik.joels...@oracle.com>; build-dev <build-dev@openjdk.java.net>;
> >> core-libs-dev <core-libs-...@openjdk.java.net>; hotspot-dev
> developers
> >> <hotspot-...@openjdk.java.net>
> >> Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from
> Linux
> >> and Solaris images
> >>
> >> Hi,
> >>
> >> we appreciate this change a lot, and also if /server would go away.
> >>
> >> I built and tested it on linuxppcle, aixppc and linuxs390.
> >>
> >> There is still a place that refers to a removed variables
> >> and breaks the build:
> >> jdk/src/java.base/unix/native/libjli/ergo.c:94  LIBARCHNAME
> >> You can probably just replace LIBARCHNAME by ARCH which is set to
> >> the same value.
> >>
> >> I would propose to remove VM_CPU from hotspot/test/test_env.sh after
> >> you
> >> removed the last place where it is used.  (VM_BITS is dead, too.)
> >>
> >> Best regards,
> >>Goetz.
> >>
> >>> -Original Message-
> >>> From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On
> >>> Behalf Of Vladimir Kozlov
> >>> Sent: Freitag, 18. November 2016 17:41
> >>> To: Erik Joelsson <erik.joels...@oracle.com>; build-dev  >>> d...@openjdk.java.net>; core-libs-dev  d...@openjdk.java.net>;
> >>> hotspot-dev developers <hotspot-...@openjdk.java.net>
> >>> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from
> Linux
> >>> and Solaris images
> >>>
> >>> Finally! :)
> >>>
> >>> Hotspot changes looks fine to me. But you missed
> >>> hotspot/make/hotspot.script file.
> >>>
> >>> Our colleges in RH and SAP should test these changes on their platforms.
> >>>
> >>> Next step would be removal of client/server sub-directories on
> platforms
> >>> where we have only Server JVM (64-bit JDK has only Server JVM).
> >>>
> >>> Thanks,
> >>> Vladimir
> >>>
> >>> On 11/18/16 7:30 AM, Erik Joelsson wrote:
> >>>> Hello,
> >>>>
> >>>> Please review this change which removes the $ARCH sub directory in
> the
> >>>> lib directory of the runtime images, which is an outstanding issue from
> >>>> the new runtime images. Most of the changes are in the build, but
> there
> >>>> are some in hotspot and launcher source. I have verified -testset
> >>>> hotspot and default in JPRT as well as tried to run as many jtreg tests
> >>>> as possible locally. I could only really find two tests that needed to
> >>>> be adjusted.
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066474
> >>>>
> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01
> >>>>
> >>>> /Erik
> >>>>

RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

[Lindenmaier, Goetz]

Hi,

linuxx86_64 has the same issue.  I tested it with the jdk9/hs repo:

jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function 
ServerClassMachineImpl:
jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) 
before LIBARCHNAME

Best regards,
  Goetz

> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Montag, 21. November 2016 12:35
> To: 'Vladimir Kozlov' <vladimir.koz...@oracle.com>; Erik Joelsson
> <erik.joels...@oracle.com>; build-dev <build-dev@openjdk.java.net>;
> core-libs-dev <core-libs-...@openjdk.java.net>; hotspot-dev developers
> <hotspot-...@openjdk.java.net>
> Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux
> and Solaris images
> 
> Hi,
> 
> we appreciate this change a lot, and also if /server would go away.
> 
> I built and tested it on linuxppcle, aixppc and linuxs390.
> 
> There is still a place that refers to a removed variables
> and breaks the build:
> jdk/src/java.base/unix/native/libjli/ergo.c:94  LIBARCHNAME
> You can probably just replace LIBARCHNAME by ARCH which is set to
> the same value.
> 
> I would propose to remove VM_CPU from hotspot/test/test_env.sh after
> you
> removed the last place where it is used.  (VM_BITS is dead, too.)
> 
> Best regards,
>   Goetz.
> 
> > -Original Message-
> > From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On
> > Behalf Of Vladimir Kozlov
> > Sent: Freitag, 18. November 2016 17:41
> > To: Erik Joelsson <erik.joels...@oracle.com>; build-dev  > d...@openjdk.java.net>; core-libs-dev <core-libs-...@openjdk.java.net>;
> > hotspot-dev developers <hotspot-...@openjdk.java.net>
> > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux
> > and Solaris images
> >
> > Finally! :)
> >
> > Hotspot changes looks fine to me. But you missed
> > hotspot/make/hotspot.script file.
> >
> > Our colleges in RH and SAP should test these changes on their platforms.
> >
> > Next step would be removal of client/server sub-directories on platforms
> > where we have only Server JVM (64-bit JDK has only Server JVM).
> >
> > Thanks,
> > Vladimir
> >
> > On 11/18/16 7:30 AM, Erik Joelsson wrote:
> > > Hello,
> > >
> > > Please review this change which removes the $ARCH sub directory in the
> > > lib directory of the runtime images, which is an outstanding issue from
> > > the new runtime images. Most of the changes are in the build, but there
> > > are some in hotspot and launcher source. I have verified -testset
> > > hotspot and default in JPRT as well as tried to run as many jtreg tests
> > > as possible locally. I could only really find two tests that needed to
> > > be adjusted.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474
> > >
> > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01
> > >
> > > /Erik
> > >

RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

[Lindenmaier, Goetz]

Hi,

we appreciate this change a lot, and also if /server would go away.

I built and tested it on linuxppcle, aixppc and linuxs390.

There is still a place that refers to a removed variables
and breaks the build:
jdk/src/java.base/unix/native/libjli/ergo.c:94  LIBARCHNAME
You can probably just replace LIBARCHNAME by ARCH which is set to 
the same value.

I would propose to remove VM_CPU from hotspot/test/test_env.sh after you 
removed the last place where it is used.  (VM_BITS is dead, too.)

Best regards,
  Goetz.

> -Original Message-
> From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On
> Behalf Of Vladimir Kozlov
> Sent: Freitag, 18. November 2016 17:41
> To: Erik Joelsson ; build-dev  d...@openjdk.java.net>; core-libs-dev ;
> hotspot-dev developers 
> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux
> and Solaris images
> 
> Finally! :)
> 
> Hotspot changes looks fine to me. But you missed
> hotspot/make/hotspot.script file.
> 
> Our colleges in RH and SAP should test these changes on their platforms.
> 
> Next step would be removal of client/server sub-directories on platforms
> where we have only Server JVM (64-bit JDK has only Server JVM).
> 
> Thanks,
> Vladimir
> 
> On 11/18/16 7:30 AM, Erik Joelsson wrote:
> > Hello,
> >
> > Please review this change which removes the $ARCH sub directory in the
> > lib directory of the runtime images, which is an outstanding issue from
> > the new runtime images. Most of the changes are in the build, but there
> > are some in hotspot and launcher source. I have verified -testset
> > hotspot and default in JPRT as well as tried to run as many jtreg tests
> > as possible locally. I could only really find two tests that needed to
> > be adjusted.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474
> >
> > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01
> >
> > /Erik
> >

RE: RFR: JEP draft for Linux/s3990x port

[Lindenmaier, Goetz]

Hi Vladimir, 

I made a new webrev containing all outstanding changes merged into one patch
http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-all/hotspot.wr01/

You probably saw my RFR with the s390 files.

Best regards,
  Goetz.

> -Original Message-
> From: Vladimir Kozlov [mailto:vladimir.koz...@oracle.com]
> Sent: Thursday, October 13, 2016 1:09 AM
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Volker Simonis
> <volker.simo...@gmail.com>
> Cc: s390x-port-...@openjdk.java.net; porters-...@openjdk.java.net; build-
> dev <build-dev@openjdk.java.net>; HotSpot Open Source Developers
> <hotspot-...@openjdk.java.net>; Java Core Libs  d...@openjdk.java.net>
> Subject: Re: RFR: JEP draft for Linux/s3990x port
> 
> Hi Goetz and Volker,
> 
> Positive news is that JEP status is moving, changes are reviewed and some
> changes were already pushed.
> 
> But because of our testing issues during past week I was not able to execute
> the testing.
> 
> We hope jdk9/hs will be open soon but we want to sync jdk9/dev and merge
> hs-comp repository first. hs/ repo will be
> opened for other pushes soon after that.
> 
> I added estimated integration date to the JEP (Oct 28). We would like to test
> and integrate this port before JDK 10
> forest is forked. Do you think all s390 changes and new code will be ready by
> that date?
> 
> Do you have all shared changes reviewed and approved for push?
> 
> Goetz, I saw you updated RFEs with latest webrevs. Can you again prepare
> changeset based on hs/ repo for changes which
> are not pushed yet? I will try to submit testing over weekend.
> 
> Regards,
> Vladimir
> 
> On 10/4/16 9:48 AM, Lindenmaier, Goetz wrote:
> > Hi Vladimir,
> >
> > This webrev contains all the changes to hotspot needed for the port:
> > http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-
> all/hotspot.wr01/
> >
> > It includes
> > http://cr.openjdk.java.net/~goetz/wr16/8166560-
> basic_s390/hotspot.wr03/
> > http://cr.openjdk.java.net/~goetz/wr16/8166561-
> basic_C1C2_s390/webrev.01/
> > http://cr.openjdk.java.net/~goetz/wr16/8166562-
> scratch_emit/webrev.01/
> > which are out for review. Further it includes
> > the one change to relocate the pc-relative instructions where we didn't
> open
> > a bug for yet, and the new s390-files.
> >
> > Altogether this passed all our tests that were running on the weekend
> > on linuxs390.
> >
> > The s390-files though are not yet fully in shape, I'm still editing them to 
> > get
> > rid of legacy stuff and SAP JVM specific code.  E.g. all the code guarded by
> > #ifdef SAPJVM  will go away in the end.
> >
> > I hope to have the final versions by end of this week.
> >
> > Best regards,
> >   Goetz.
> >
> >
> >> -Original Message-
> >> From: s390x-port-dev [mailto:s390x-port-dev-boun...@openjdk.java.net]
> >> On Behalf Of Vladimir Kozlov
> >> Sent: Montag, 3. Oktober 2016 23:50
> >> To: Volker Simonis <volker.simo...@gmail.com>
> >> Cc: s390x-port-...@openjdk.java.net; porters-...@openjdk.java.net;
> >> build-dev <build-dev@openjdk.java.net>; HotSpot Open Source
> Developers
> >> <hotspot-...@openjdk.java.net>; Java Core Libs  >> d...@openjdk.java.net>
> >> Subject: Re: RFR: JEP draft for Linux/s3990x port
> >>
> >> Hi Volker,
> >>
> >> Can you prepare combined patch (or set of patches) based on latest
> >> reviews together with s390 code as it will be in final push?
> >>
> >> We want to run it through our pre-integration testing to verify that it
> >> does not have problems.
> >>
> >> Thanks,
> >> Vladimir
> >>
> >> On 9/29/16 11:25 AM, Vladimir Kozlov wrote:
> >>> You need to wait when Mark (OpenJDK Lead) move it to Candidate (or
> >>> other) state:
> >>>
> >>> http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> >>>
> >>> Vladimir
> >>>
> >>> On 9/29/16 9:55 AM, Volker Simonis wrote:
> >>>> Hi Vladimir,
> >>>>
> >>>> thanks a lot for reviewing and endorsing the JEP.
> >>>>
> >>>> I've linked all the relevant issues to the JEP  (they all have a link
> >>>> to a webrev) and change the state to "Submitted".
> >>>>
> >>>> There's just one more small shared change we need for the port for
> >>>> which we haven't opened a bug now because we are still working on
>

RE: RFR: JEP draft for Linux/s3990x port

[Lindenmaier, Goetz]

Hi Vladimir, 

I'm about to post the final change with the s390 files.
All the others are reviewed.  I'll then also send a 
complete webrev for testing. 

Best regards,
  Goetz

> -Original Message-
> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> Sent: Thursday, October 13, 2016 8:32 AM
> To: Vladimir Kozlov <vladimir.koz...@oracle.com>
> Cc: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; s390x-port-
> d...@openjdk.java.net; porters-...@openjdk.java.net; build-dev  d...@openjdk.java.net>; HotSpot Open Source Developers  d...@openjdk.java.net>; Java Core Libs <core-libs-...@openjdk.java.net>
> Subject: Re: RFR: JEP draft for Linux/s3990x port
> 
> Hi Vladimir,
> 
> thanks for keeping us updated and hanks for setting the integrations
> date on the JEP. We think it is reasonable to do it before the JDK 10
> forest will be forked as this will obviously save us a lot of work.
> 
> The remaining shared changes are
> 
> "8166561: [s390] Adaptions needed for s390 port in C1 and C2."
> "8166560: [s390] Basic enablement of s390 port."
> "8167184: [s390] Extend relocations for pc-relative instructions."
> "8166837: [TESTBUG] Fix tests on Linux/s390x"
> 
> 
> Except the TESTBUG, they are all reviewed but I think the testbug is
> not so important and could be done later if we don't get it reviewd
> until the integration date.
> 
> I'm currently traveling, but I'm sure Goetz can provide a new hs/based
> changeset for testing, right Goetz :)
> 
> Regards,
> Volker
> 
> 
> On Thu, Oct 13, 2016 at 1:09 AM, Vladimir Kozlov
> <vladimir.koz...@oracle.com> wrote:
> > Hi Goetz and Volker,
> >
> > Positive news is that JEP status is moving, changes are reviewed and some
> > changes were already pushed.
> >
> > But because of our testing issues during past week I was not able to
> execute
> > the testing.
> >
> > We hope jdk9/hs will be open soon but we want to sync jdk9/dev and
> merge
> > hs-comp repository first. hs/ repo will be opened for other pushes soon
> > after that.
> >
> > I added estimated integration date to the JEP (Oct 28). We would like to
> > test and integrate this port before JDK 10 forest is forked. Do you think
> > all s390 changes and new code will be ready by that date?
> >
> > Do you have all shared changes reviewed and approved for push?
> >
> > Goetz, I saw you updated RFEs with latest webrevs. Can you again prepare
> > changeset based on hs/ repo for changes which are not pushed yet? I will
> try
> > to submit testing over weekend.
> >
> > Regards,
> > Vladimir
> >
> >
> > On 10/4/16 9:48 AM, Lindenmaier, Goetz wrote:
> >>
> >> Hi Vladimir,
> >>
> >> This webrev contains all the changes to hotspot needed for the port:
> >> http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-
> all/hotspot.wr01/
> >>
> >> It includes
> >> http://cr.openjdk.java.net/~goetz/wr16/8166560-
> basic_s390/hotspot.wr03/
> >> http://cr.openjdk.java.net/~goetz/wr16/8166561-
> basic_C1C2_s390/webrev.01/
> >> http://cr.openjdk.java.net/~goetz/wr16/8166562-
> scratch_emit/webrev.01/
> >> which are out for review. Further it includes
> >> the one change to relocate the pc-relative instructions where we didn't
> >> open
> >> a bug for yet, and the new s390-files.
> >>
> >> Altogether this passed all our tests that were running on the weekend
> >> on linuxs390.
> >>
> >> The s390-files though are not yet fully in shape, I'm still editing them
> >> to get
> >> rid of legacy stuff and SAP JVM specific code.  E.g. all the code guarded
> >> by
> >> #ifdef SAPJVM  will go away in the end.
> >>
> >> I hope to have the final versions by end of this week.
> >>
> >> Best regards,
> >>   Goetz.
> >>
> >>
> >>> -Original Message-
> >>> From: s390x-port-dev [mailto:s390x-port-dev-
> boun...@openjdk.java.net]
> >>> On Behalf Of Vladimir Kozlov
> >>> Sent: Montag, 3. Oktober 2016 23:50
> >>> To: Volker Simonis <volker.simo...@gmail.com>
> >>> Cc: s390x-port-...@openjdk.java.net; porters-...@openjdk.java.net;
> >>> build-dev <build-dev@openjdk.java.net>; HotSpot Open Source
> Developers
> >>> <hotspot-...@openjdk.java.net>; Java Core Libs  >>> d...@openjdk.java.net>
> >>> Subject: Re: RFR: JEP draft for Linux/s3990x port
> >>>
> >&

RE: RFR: JEP draft for Linux/s3990x port

[Lindenmaier, Goetz]

Hi Vladimir, 

This webrev contains all the changes to hotspot needed for the port:
http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-all/hotspot.wr01/

It includes 
http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr03/
http://cr.openjdk.java.net/~goetz/wr16/8166561-basic_C1C2_s390/webrev.01/
http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/
which are out for review. Further it includes
the one change to relocate the pc-relative instructions where we didn't open
a bug for yet, and the new s390-files.

Altogether this passed all our tests that were running on the weekend
on linuxs390.

The s390-files though are not yet fully in shape, I'm still editing them to get
rid of legacy stuff and SAP JVM specific code.  E.g. all the code guarded by 
#ifdef SAPJVM  will go away in the end.

I hope to have the final versions by end of this week.

Best regards,
  Goetz.


> -Original Message-
> From: s390x-port-dev [mailto:s390x-port-dev-boun...@openjdk.java.net]
> On Behalf Of Vladimir Kozlov
> Sent: Montag, 3. Oktober 2016 23:50
> To: Volker Simonis 
> Cc: s390x-port-...@openjdk.java.net; porters-...@openjdk.java.net;
> build-dev ; HotSpot Open Source Developers
> ; Java Core Libs  d...@openjdk.java.net>
> Subject: Re: RFR: JEP draft for Linux/s3990x port
> 
> Hi Volker,
> 
> Can you prepare combined patch (or set of patches) based on latest
> reviews together with s390 code as it will be in final push?
> 
> We want to run it through our pre-integration testing to verify that it
> does not have problems.
> 
> Thanks,
> Vladimir
> 
> On 9/29/16 11:25 AM, Vladimir Kozlov wrote:
> > You need to wait when Mark (OpenJDK Lead) move it to Candidate (or
> > other) state:
> >
> > http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> >
> > Vladimir
> >
> > On 9/29/16 9:55 AM, Volker Simonis wrote:
> >> Hi Vladimir,
> >>
> >> thanks a lot for reviewing and endorsing the JEP.
> >>
> >> I've linked all the relevant issues to the JEP  (they all have a link
> >> to a webrev) and change the state to "Submitted".
> >>
> >> There's just one more small shared change we need for the port for
> >> which we haven't opened a bug now because we are still working on
> >> simplifying it. The current version looks as follows:
> >>
> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/916-
> constant_table_offset.patch
> >>
> >>
> >> What are the next steps? Should I add a "jdk9-fc-request" label to t
> >> he JEP and add a corresponding "FC Extension Request" comment to it?
> >> Or will this be done automatically once I move it to "Candidate"?
> >>
> >> Is there anything left to do before I can move it to "Candidate" state?
> >>
> >> Thanks a lot and best regards,
> >> Volker
> >>
> >>
> >>
> >>
> >> On Tue, Sep 27, 2016 at 8:15 PM, Vladimir Kozlov
> >>  wrote:
> >>> On 9/27/16 10:49 AM, Volker Simonis wrote:
> 
>  Hi,
> 
>  can you please review and endorse the following draft JEP for the
>  integration of the Linux/s390x port into the jkd9 master repository:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8166730
> >>>
> >>>
> >>> Good.
> >>> Add links to webrevs in a comment. It will help to get umbrella FC
> >>> extension
> >>> approval.
> >>>
> 
>  As detailed in the JEP, the Linux/s390x requires very few shared
>  changes and we therefore don't foresee any impact on the existing
>  platforms at all. Following you can find a short description of the
>  planned changes:
> 
>  hotspot:
>  ===
> 
>  Out for review:
>  8166560: [s390] Basic enablement of s390 port.
>  http://cr.openjdk.java.net/~goetz/wr16/8166560-
> basic_s390/hotspot.wr01/
> 
>  Reviewed:
>  8166562: C2: Suppress relocations in scratch emit.
>  http://cr.openjdk.java.net/~goetz/wr16/8166562-
> scratch_emit/webrev.01/
> 
>  Will send RFR soon (depends on 8166560):
>  8166561: [s390] Adaptions needed for s390 port in C1 and C2.
>  http://cr.openjdk.java.net/~goetz/wr16/8166562-
> scratch_emit/webrev.01
> >>>
> >>>
> >>> Wrong link.
> >>>
> >>> Thanks,
> >>> Vladimir
> >>>
> >>>
> 
>  We are still investigating the need of these shared changes:
> 
> 
> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000
> 011-pass_PC_to_retAddrOffset.patch
> 
> 
> 
> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000
> 016-constant_table_offset.patch
> 
> 
>  And finally the patch with the s390x-only platform files. We are still
>  editing these to get them into OpenJdk style and shape.
>  Hotspot passes most jck, jtreg and spec tests with these.
> 
> 
> http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000
> 101-zFiles.patch
> 
> 
>  top-level repository:
>  ===
> 
>  

RE: RFR(S): 8154087: Fix AIX and Linux/ppc64le after the integration of the new hotspot build

[Lindenmaier, Goetz]

Hi Volker, 

I had a look at your changes. Good that 'warning as errors' already
lead to a fix :)

Note that your changes might break the old build, as you remove the 
endianess check in flags.m4 etc.. I think this is ok, though, as else dead code
will remain in the file.

Looks good, reviewed.

Best regards,
 Goetz.




> -Original Message-
> From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On
> Behalf Of Erik Joelsson
> Sent: Dienstag, 12. April 2016 18:18
> To: Volker Simonis ; HotSpot Open Source
> Developers ; build-dev  d...@openjdk.java.net>
> Subject: Re: RFR(S): 8154087: Fix AIX and Linux/ppc64le after the integration
> of the new hotspot build
> 
> Hello Volker,
> 
> This looks good to me. I will sponsor the change into hs-rt once someone
> reviews the source code changes.
> 
> /Erik
> 
> On 2016-04-12 18:03, Volker Simonis wrote:
> > Hi,
> >
> > can I please have a review for the following trivial changes to make
> > the build work again on AIX and Linux/ppc64le after the integration of
> > the new hotspot build system. The changes are all AIX and/or ppc64
> > specific and shouldn't change the behavior on any other platform.
> >
> > Because the top-level changes require the rebuild of
> > generated-configure.sh and the hotspot changes are in shared code, I
> > also need a sponsor. It would be best if the changes could be pushed
> > in sync to the hs-rt repository:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2016/8154087.top
> > http://cr.openjdk.java.net/~simonis/webrevs/2016/8154087.hs
> > http://cr.openjdk.java.net/~simonis/webrevs/2016/8154087.jdk
> >
> > https://bugs.openjdk.java.net/browse/JDK-8154087
> >
> > The hotspot change contains a trivial source code change in an AIX
> > file to fix a warning which would otherwise break the build with
> > "warnings as errors".
> >
> > The jdk change disables "warnings as errors" for AIX for several libs
> > such that we can build the complete jdk with "warnings as errors" on
> > AIX as well now. Fixing the actual warnings will be done in a later
> > change.
> >
> > Thanks a lot and best regards,
> > Volker

RE: Silence warnings with new GCC

[Lindenmaier, Goetz]

Hi Andrew,

I know about this problem ... I guess a change of mine causes these warnings.
While I found a row of good fixes, these with ShouldNotReachHere are annoying.

What you propose has been discussed in April: 8065585: Change 
ShouldNotReachHere() to never return.
I didn't follow the discussion all to the end, but it wasn't done for some 
reason.
Also, I think, one can overrule ShoudlNotReachHere() with -XX:SuppressError=...

Best regards,
  Goetz.

-Original Message-
From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
Andrew Haley
Sent: Thursday, November 26, 2015 6:24 PM
To: build-dev ; hotspot-dev Source Developers 

Subject: Silence warnings with new GCC

I've been getting a lot of warnings such as

warning: 'size' may be used uninitialized in this function 
[-Wmaybe-uninitialized]

which error out with -Werror.  Almost all of them are bogus.  They are
typically of the form

unsigned size;

if (i->get(26, 26)) { // float
  switch(i->get(31, 30)) {
  case 0b10:
size = 2; break;
  case 0b01:
size = 1; break;
  case 0b00:
size = 0; break;
  default:
ShouldNotReachHere();
  }
} else {
  size = i->get(31, 31);
}

The problem here is that GCC does not know that ShouldNotReachHere()
should be treated as an unreachable statement.

The patch here fixes it.  I'd rather do this than add pointless assignments
all over the place.  Thoughts?  Opinions?

Thanks,

Andrew.



diff --git a/src/share/vm/utilities/debug.hpp b/src/share/vm/utilities/debug.hpp
--- a/src/share/vm/utilities/debug.hpp
+++ b/src/share/vm/utilities/debug.hpp
@@ -172,16 +172,24 @@
   BREAKPOINT;  
   \
 } while (0)

+#ifdef __GNUC__
+#  define UNREACHABLE __builtin_unreachable()
+#else
+#  define UNREACHABLE do { } while (0)
+#endif
+
 #define ShouldNotReachHere()   
   \
 do {   
   \
   report_should_not_reach_here(__FILE__, __LINE__);
   \
   BREAKPOINT;  
   \
+  UNREACHABLE; 
   \
 } while (0)

 #define Unimplemented()
   \
 do {   
   \
   report_unimplemented(__FILE__, __LINE__);
   \
   BREAKPOINT;  
   \
+  UNREACHABLE; 
   \
 } while (0)

 #define Untested(msg)

RE: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base

[Lindenmaier, Goetz]

Hi David,

this change is good, I appreciate it a lot!

Best regards,
  Goetz.

-Original Message-
From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
David Holmes
Sent: Montag, 6. Juli 2015 11:11
To: hotspot-dev developers; build-dev
Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing 
dependencies in the source base

webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/

In response to the discussions in:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html

I'm now in a position to add No-PCH builds to the set of JPRT builds. 
I've simply disabled PCH for fastdebug builds. This isn't complete in 
terms of coverage but is a reasonable compromise I think. Disabling PCH 
had no adverse affects on the build times in JPRT.

Thanks,
David

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

Hi,

builds and runs on ppc linux be / aix.

Best regards,
  Goetz.

-Original Message-
From: Alexander Smundak [mailto:asmun...@google.com] 
Sent: Monday, March 24, 2014 9:10 PM
To: David Holmes
Cc: Lindenmaier, Goetz; build-dev; HotSpot Open Source Developers
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

Done. Uploaded
http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05

On Sun, Mar 23, 2014 at 8:37 PM, David Holmes david.hol...@oracle.com wrote:
 On 22/03/2014 10:47 AM, Alexander Smundak wrote:

 On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz
 goetz.lindenma...@sap.com wrote:

 My build ran into the 'little' case below, as I understand because ' big'
 was compared
 with 'big'.  Make is strange ...


 Removed the spaces, please take a look at
 http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04


 Stylistically the hotspot makefiles test a variable/expression against a
 value/constant not the other way around. So:

  ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN))

 becomes

  ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined)

 and the same for all the other comparisons you have added.


 Sorry.

 David

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

Hi Sasha, 

I tried to test your change (02), but it does not work.
On linux ppc be;) I get 

make[4]: Leaving directory 
`/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug'
make[4]: Entering directory 
`/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug'
/sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: 
*** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile.  Stop.

which is just what you discussed with David.

On Aix I get
/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp, 
line 277.10: 1540-0836 (S) The #include file bytes_linux_ppc.inline.hpp is 
not found.

I think we fixed this before, you  need to add 
#ifdef TARGET_OS_ARCH_linux_ppc
around the include.

Also, you need to fix os_linux.cpp: remove 
+  #if defined(PPC64)
else other platforms will not build (linux x86_64):
/sapmnt/home/d045726/oJ/8036767-hs-comp/src/os/linux/vm/os_linux.cpp:1972: 
error: ‘PPC64_ELFDATA2XSB’ was not declared in this scope

Thanks for undoing the change in make/linux/Makefile!

Best regards,
  Goetz.


-Original Message-
From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
Alexander Smundak
Sent: Friday, March 21, 2014 7:15 AM
To: David Holmes
Cc: build-dev; HotSpot Open Source Developers
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new
version is at:
http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02

On Thu, Mar 20, 2014 at 8:57 PM, David Holmes david.hol...@oracle.com wrote:
 On 21/03/2014 1:42 PM, Alexander Smundak wrote:

 On Thu, Mar 20, 2014 at 7:39 PM, David Holmes david.hol...@oracle.com
 wrote:

 The build changes look much cleaner to me - thanks.

 It's at the expense of platform directory being ppc64/ instead of the
 conventional ppc64le/, and having rather ugly check in the ppc64.make
 file.


 Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it
 doesn't reach down into the arch.make files. ZERO_ENDIANNESS does but
 seems inappropriate if this is not Zero specific. (I'm also not seeing
 how
 ZERO_ENDIANNESS reaches down that far either ??).

 configure script writes hotspot-spec.gmk file to the top-level build
 directory,
 and it contains
 ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN)


 Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make?
 The answer to which is that the generated flags.make file has an explicit
 include of hotspot-spec.gmk. In which case you don't need to use
 ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly.
 (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps
 it predates the integration with the new build.)

 David
 -


 The patch contains the fuse in ppc64.make, the build will fail unless
 ZERO_ENDIANNESS is set.

 jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01



 This change:

 -  LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \
 +  LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava
 -ljvm, \

 seems unrelated to endianness. Why is it needed, and why is it being
 applied
 to all platforms?

 Sorry, this is not needed, it's the problem with the toolchain I am using.

 Please ignore this patch.

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

 Hi David, 

yes, it's the hotspot only build. 

But that's no good If I have to set something that can be 
easily derived from information already available!

I at least would add another  $(shell uname -m) test
in the condition in the ppc64.make file.

ifeq (,$(filter $(OPENJDK_TARGET_CPU_ENDIAN),big little))
 OPENJDK_TARGET_CPU_ENDIAN=big
ifeq($(shell uname -m), ppc64le)
 OPENJDK_TARGET_CPU_ENDIAN =little
endif
endif

Also, I don't see how defs.make deals with the outcome ppc64le of uname.
Sasha, is there missing something from your change?
If there needs to be a section 
# PPC64le
ifeq ($(ARCH), ppc64le)
  ARCH_DATA_MODEL  = 64
  MAKE_ARGS+= LP64=1
  PLATFORM = linux-ppc64
  VM_PLATFORM  = linux_ppc64
  HS_ARCH  = ppc
endif
setting OPENJDK_TARGET_CPU_ENDIAN should be added there I think.

Best regards,
  Goetz

-Original Message-
From: David Holmes [mailto:david.hol...@oracle.com] 
Sent: Friday, March 21, 2014 12:08 PM
To: Lindenmaier, Goetz; 'Alexander Smundak'
Cc: 'build-dev'; 'HotSpot Open Source Developers'
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

On 21/03/2014 7:06 PM, Lindenmaier, Goetz wrote:
 Hi Sasha,

 I tried to test your change (02), but it does not work.
 On linux ppc be;) I get

 make[4]: Leaving directory 
 `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug'
 make[4]: Entering directory 
 `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug'
 /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: 
 *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile.  Stop.

 which is just what you discussed with David.

Was that a full configure build or a hotspot-only build? For 
hotspot-only you would need to set this explicitly.

David


 On Aix I get
 /sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp, 
 line 277.10: 1540-0836 (S) The #include file bytes_linux_ppc.inline.hpp is 
 not found.

 I think we fixed this before, you  need to add
 #ifdef TARGET_OS_ARCH_linux_ppc
 around the include.

 Also, you need to fix os_linux.cpp: remove
 +  #if defined(PPC64)
 else other platforms will not build (linux x86_64):
 /sapmnt/home/d045726/oJ/8036767-hs-comp/src/os/linux/vm/os_linux.cpp:1972: 
 error: ‘PPC64_ELFDATA2XSB’ was not declared in this scope

 Thanks for undoing the change in make/linux/Makefile!

 Best regards,
Goetz.


 -Original Message-
 From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
 Alexander Smundak
 Sent: Friday, March 21, 2014 7:15 AM
 To: David Holmes
 Cc: build-dev; HotSpot Open Source Developers
 Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

 Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new
 version is at:
 http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02

 On Thu, Mar 20, 2014 at 8:57 PM, David Holmes david.hol...@oracle.com wrote:
 On 21/03/2014 1:42 PM, Alexander Smundak wrote:

 On Thu, Mar 20, 2014 at 7:39 PM, David Holmes david.hol...@oracle.com
 wrote:

 The build changes look much cleaner to me - thanks.

 It's at the expense of platform directory being ppc64/ instead of the
 conventional ppc64le/, and having rather ugly check in the ppc64.make
 file.


 Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it
 doesn't reach down into the arch.make files. ZERO_ENDIANNESS does but
 seems inappropriate if this is not Zero specific. (I'm also not seeing
 how
 ZERO_ENDIANNESS reaches down that far either ??).

 configure script writes hotspot-spec.gmk file to the top-level build
 directory,
 and it contains
 ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN)


 Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make?
 The answer to which is that the generated flags.make file has an explicit
 include of hotspot-spec.gmk. In which case you don't need to use
 ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly.
 (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps
 it predates the integration with the new build.)

 David
 -


 The patch contains the fuse in ppc64.make, the build will fail unless
 ZERO_ENDIANNESS is set.

 jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01



 This change:

 -  LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \
 +  LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava
 -ljvm, \

 seems unrelated to endianness. Why is it needed, and why is it being
 applied
 to all platforms?

 Sorry, this is not needed, it's the problem with the toolchain I am using.

 Please ignore this patch.

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

Hi Sasha, 

I still get a small problem in ppc64.make.  You need to remove the space 
before big and little in the assignment:
  OPENJDK_TARGET_CPU_ENDIAN := $(if $(filter ppc64le,$(shell uname 
-m)),little,big)
My build ran into the 'little' case below, as I understand because ' big' was 
compared 
with 'big'.  Make is strange ...

After fixing that, tested linuxppc64, aix and linuxx86_64, they all work.

Best regards,
  Goetz.

-Original Message-
From: Alexander Smundak [mailto:asmun...@google.com] 
Sent: Friday, March 21, 2014 10:02 PM
To: Lindenmaier, Goetz
Cc: David Holmes; build-dev; HotSpot Open Source Developers
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

On Fri, Mar 21, 2014 at 2:06 AM, Lindenmaier, Goetz
goetz.lindenma...@sap.com wrote:
 /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: 
 *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile.  Stop.
I've fixed make/linux/makefile/defs.make to remap ARCH
from ppc64le to ppc64.
I have fixed make/linux/makefiles/ppc64.make to set
OPENJDK_TARGET_CPU_ENDIAN if it hasn't been set by the caller.

 On Aix I get
 /sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp, 
 line 277.10: 1540-0836 (S) The #include file bytes_linux_ppc.inline.hpp is 
 not found.

 I think we fixed this before [...]
Sorry, I forgot to resync with another repository. Done.

The new patch is:
http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.03

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

Hi,

 it could be done with PPC64_ENDIANNESS check
Yes, that's fine.  I would further propose to choose a neutral name ENDIANESS
and set it for all architectures.  Platform specific variables should be 
avoided in 
shared files.  And it's used in ppc64.make, so that should be fine.
Also -DLITTLE_ENDIAN could be set in a shared makefile once for all if there is 
a 
variable ENDIANESS.

But I don't see how you want to fix the build path with this.  It's used in a 
lot of
places, in linux/Makefile for setting the subdirs
   SUBDIRS_C1= $(addprefix $(OSNAME)_$(BUILDARCH)_compiler1/,$(TARGETS))
and also when doing the install.
Further it's used in buildtree.make to set up these directories.

One would have to change all these locations to 
   SUBDIRS_C1= $(addprefix 
$(OSNAME)_$(BUILDARCH)$(PPC64_ENDIANESS)_compiler1/,$(TARGETS))

But I don’t want to insist on the setting of a different build path.

Best regards,
  Goetz.

-Original Message-
From: Vladimir Kozlov [mailto:vladimir.koz...@oracle.com] 
Sent: Tuesday, March 18, 2014 2:36 AM
To: Lindenmaier, Goetz; Magnus Ihse Bursie; David Holmes
Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

On 3/17/14 6:36 AM, Lindenmaier, Goetz wrote:
 Hi Magnus,

 The change keeps target cpu and target cpu arch as is.  The C-code uses
 -DLITTLE_ENDIAN to distinguish implementation differences.

 As I understand, we discuss the setting of BUILDARCH in the makefiles.
 Indirectly it is set from uname, which returns ppc64le on these machines.

 This affects the following namings:
1. the build path:linux_ppc64le-compiler2

I am fine with it (your case is reasonable) but it could be done with 
PPC64_ENDIANNESS check for PLATFORM and VM_PLATFORM definition.

2. which makefiles used:  platform_ppc64le and ppc64le.make

These causes the main resistance to these changes.


 1.) would allow to build ppc64 and ppc64le from the same repo without setting 
 ALT_OUTPUTDIR
 2.) BUILDARCH=ppc64le means two new files, where platform_ppc64 and 
 platform_ppc64le
are the same.
   BUILDARCH=ppc64  means no new files, but lots of platform checks in 
 ppc64.make,
   which is uncommon.  So far these files are just settings.

It is only one check as Volker showed.


 I don't think setting
LIBARCH=ppc64le  ==  jre/lib/ppc64le/server/libjvm.so

It is questionable. Why you need jre/lib/ppc64le and not the same 
jre/lib/ppc64? It does not make sense to me to deploy JDK which have 
both of them in one jre/lib.

Thanks,
Vladimir

 and the settings in os_linux.cpp are questioned.

 Best regards,
Goetz.

 http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/





 -Original Message-
 From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
 Magnus Ihse Bursie
 Sent: Montag, 17. März 2014 12:36
 To: David Holmes
 Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak
 Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

 On 2014-03-17 05:13, David Holmes wrote:
 On 15/03/2014 7:11 AM, Alexander Smundak wrote:
 Ping.

 My position hasn't changed. I don't think this needs to be, or should
 be, a distinct architecture.

 I've added build-dev to cc list to see what our build experts think.

 I'm not sure I've completely understood the discussion (it has jumped
 around a bit between mailing lists), but I think I agree with David
 here. Architecture is a term that implies general common features, not
 specific differences.

 While hotspot and the rest of the jdk build is not currently in sync
 with this terminology, in the common configure and makefiles we use the
 terminology target cpu (which can be for instance x86_64 or
 sparcv9 and target cpu arch (which can be for instance x86 or
 sparc).

 Regarding ppc, we currently define the target cpu arch ppc and two
 target cpus, ppc and ppc64.

 Perhaps it would be more approriate to consider this a separate target
 cpu (ppc64le), but not a separate target cpu architecture? But that
 would be on the top-level -- I'm not sure how that would map properly to
 the current hotspot build system.

 /Magnus

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

Hi Magnus,

The change keeps target cpu and target cpu arch as is.  The C-code uses
-DLITTLE_ENDIAN to distinguish implementation differences.

As I understand, we discuss the setting of BUILDARCH in the makefiles.
Indirectly it is set from uname, which returns ppc64le on these machines.

This affects the following namings:
  1. the build path:linux_ppc64le-compiler2 
  2. which makefiles used:  platform_ppc64le and ppc64le.make

1.) would allow to build ppc64 and ppc64le from the same repo without setting 
ALT_OUTPUTDIR
2.) BUILDARCH=ppc64le means two new files, where platform_ppc64 and 
platform_ppc64le
  are the same.
 BUILDARCH=ppc64  means no new files, but lots of platform checks in 
ppc64.make, 
 which is uncommon.  So far these files are just settings.

I don't think setting 
  LIBARCH=ppc64le  ==  jre/lib/ppc64le/server/libjvm.so
and the settings in os_linux.cpp are questioned.

Best regards,
  Goetz.

http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/





-Original Message-
From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
Magnus Ihse Bursie
Sent: Montag, 17. März 2014 12:36
To: David Holmes
Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

On 2014-03-17 05:13, David Holmes wrote:
 On 15/03/2014 7:11 AM, Alexander Smundak wrote:
 Ping.

 My position hasn't changed. I don't think this needs to be, or should 
 be, a distinct architecture.

 I've added build-dev to cc list to see what our build experts think.

I'm not sure I've completely understood the discussion (it has jumped 
around a bit between mailing lists), but I think I agree with David 
here. Architecture is a term that implies general common features, not 
specific differences.

While hotspot and the rest of the jdk build is not currently in sync 
with this terminology, in the common configure and makefiles we use the 
terminology target cpu (which can be for instance x86_64 or 
sparcv9 and target cpu arch (which can be for instance x86 or 
sparc).

Regarding ppc, we currently define the target cpu arch ppc and two 
target cpus, ppc and ppc64.

Perhaps it would be more approriate to consider this a separate target 
cpu (ppc64le), but not a separate target cpu architecture? But that 
would be on the top-level -- I'm not sure how that would map properly to 
the current hotspot build system.

/Magnus

RE: RFR (M): 8036767 PPC64: Support for little endian execution model

[Lindenmaier, Goetz]

Hi,

having said what I wanted to say about the build output directory path, 
I'm fine with both solutions.  In the end it affects only a few line
in shared make files.

Best regards,
  Goetz

-Original Message-
From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of 
David Holmes
Sent: Montag, 17. März 2014 05:14
To: Alexander Smundak; HotSpot Open Source Developers; build-dev
Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model

On 15/03/2014 7:11 AM, Alexander Smundak wrote:
 Ping.

My position hasn't changed. I don't think this needs to be, or should 
be, a distinct architecture.

I've added build-dev to cc list to see what our build experts think.

David
-

 On Wed, Mar 12, 2014 at 4:59 PM, Alexander Smundak asmun...@google.com 
 wrote:
 I was concerned by the term 'variant', which might suggest that the 
 applications
 built for PPC64 and PPC64LE are binary compatible. They are not.

 On Wed, Mar 12, 2014 at 3:55 PM, David Holmes david.hol...@oracle.com 
 wrote:
 On 12/03/2014 9:19 AM, Alexander Smundak wrote:

 On Tue, Mar 11, 2014 at 3:51 PM, Vladimir Kozlov
 vladimir.koz...@oracle.com wrote:

 It would only help if you could do cross compilation to have both build
 variants at the same place. Currently you can only build le variant on
 ppc64le machine and vice versa. That is why, I think, David asked if we
 can
 control what variant to build.

 Just to clarify the situation a bit: ppc64le is not a variant of ppc64.
 That is,
 an application compiled for the little-endian PowerPC64 does not just
 run on
 the big-endian PowerPC64 (albeit OS can have such feature, similar to the
 ability of the Linux running on x86_64 CPU to run 32-bit x86
 applications).
 So ppc64le is a different architecture from ppc64.


 I disagree with that classification for architecture and it seems at odds
 with the literature which describes the endian-ness selection as a mode.

 David
 -


 I would like to see the changes based on Volker suggestion. We can
 compare
 them and decide which way to go.

 Volker has the detailed suggestion here:

 http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html
 and it involves additional Make variable and if statements in the
 platform makefile
where they are not supposed to be present.