Re: RFR: JDK-8200132: Remove jre images and bundles

[Martin Buchholz]

JREs are a very long tradition.  I suggest deferring disruptive changes
like this to some release past jdk11.

On Fri, Jun 1, 2018 at 3:02 PM, Erik Joelsson 
wrote:

> Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing
> much value. The idea is rather that you link together an image with the
> modules and settings you actually need, either with or without your
> application. For this reason oracle will no longer ship JRE images that
> differ content wise to the JDK image in JDK 11 and we would like to remove
> them from the OpenJDK build to reduce complexity.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200132
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/
>
> /Erik
>
>

Re: RFR: JDK-8200132: Remove jre images and bundles

[mandy chung]

Looks good.  The build is much simplified.

Modules.gmk
  include_in_jdk can be removed since it should always be true.
  In fact build.properties support can be removed some day.

Mandy

On 6/1/18 3:02 PM, Erik Joelsson wrote:
Since JDK 9 and modules, the idea of a prebuilt JRE is no longer 
providing much value. The idea is rather that you link together an image 
with the modules and settings you actually need, either with or without 
your application. For this reason oracle will no longer ship JRE images 
that differ content wise to the JDK image in JDK 11 and we would like to 
remove them from the OpenJDK build to reduce complexity.


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

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/

/Erik

RFR: JDK-8200132: Remove jre images and bundles

[Erik Joelsson]

Since JDK 9 and modules, the idea of a prebuilt JRE is no longer 
providing much value. The idea is rather that you link together an image 
with the modules and settings you actually need, either with or without 
your application. For this reason oracle will no longer ship JRE images 
that differ content wise to the JDK image in JDK 11 and we would like to 
remove them from the OpenJDK build to reduce complexity.


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

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/

/Erik

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Aleksey Shipilev]

On 06/01/2018 10:53 PM, Erik Joelsson wrote:
> This patch defines flags for disabling speculative execution for GCC and 
> Visual Studio and applies
> them to all binaries except libjvm when available in the compiler. It defines 
> a new jvm feature
> no-speculative-cti, which is used to control whether to use the flags for 
> libjvm. It also defines a
> new jvm variant "altserver" which is the same as server, but with this new 
> feature added.

I think the classic name for such product configuration is "hardened", no?

-Aleksey

RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

We need to add compilation flags for disabling speculative execution to 
our native libraries and executables. In order to allow for users not 
affected by problems with speculative execution to run a JVM at full 
speed, we need to be able to ship two JVM libraries - one that is 
compiled with speculative execution enabled, and one that is compiled 
without. Note that this applies to the build time C++ flags, not the 
compiler in the JVM itself. Luckily adding these flags to the rest of 
the native libraries did not have a significant performance impact so 
there is no need for making it optional there.


This patch defines flags for disabling speculative execution for GCC and 
Visual Studio and applies them to all binaries except libjvm when 
available in the compiler. It defines a new jvm feature 
no-speculative-cti, which is used to control whether to use the flags 
for libjvm. It also defines a new jvm variant "altserver" which is the 
same as server, but with this new feature added.


For Oracle builds, we are changing the default for linux-x64 and 
windows-x64 to build both server and altserver, giving the choice to the 
user which JVM they want to use. If others would prefer this default, we 
could make it default in configure as well.


The change in GensrcJFR.gmk fixes a newly introduced race that appears 
when building multiple jvm variants.


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

Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01

/Erik

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Baesken, Matthias]

Hi ,  my change  8202322   just  handled  the fact   that  the  visibility - 
flags   are not supported  with  xlc 12.1  ,  so  setting them generated a TON 
of compile - time  warnings .

The introduction of   the  "-qvisibility=hidden"came with the  mapfile 
removal changes :

8200358: Remove mapfiles for JDK executables
http://hg.openjdk.java.net/jdk/jdk/rev/210cf224b690

8200178: Remove mapfiles for JDK native libraries
http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5

I guess it  might  need further  testing+adjustments  to make  the  "visibility 
hiding" work nicely   with XLC13  ,  but currently  we build only with XLC12 .  

As a workaround  you might want to  remove  the  "-qvisibility=hidden"  setting 
for XLC 13 as well  ,  like I did  for XLC12 with  the change   8202322   .


Best regards, Matthias




> -Original Message-
> From: Langer, Christoph
> Sent: Freitag, 1. Juni 2018 10:57
> To: Ichiroh Takiguchi 
> Cc: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-...@openjdk.java.net; Lindenmaier,
> Goetz 
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hi Ichiroh,
> 
> we do not use the XLC 13 compiler on AIX yet here at SAP and I believe
> nobody of my colleagues has played with it yet. So you are on a new
> playground here 
> 
> However, I believe the idea in OpenJDK with the abolition of map files is that
> symbols should be invisible externally unless they are declared exported,
> e.g. JNIEXPORT. So I would think "-qvisibility=hidden" should be the correct
> default and whatever JNIEXPORT expands to should contain the right
> attributes to get that symbol visible.
> 
> Can you check if either my assumption is completely wrong, JNIEXPORT does
> not expand to the right thing, XLC 13 has a bug or maybe just sume specific
> required symbols are not declared correctly?
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: Ichiroh Takiguchi [mailto:taki...@linux.vnet.ibm.com]
> > Sent: Donnerstag, 31. Mai 2018 09:55
> > To: Langer, Christoph 
> > Cc: Baesken, Matthias ; 'build-
> > d...@openjdk.java.net' ; ppc-aix-port-
> > d...@openjdk.java.net; core-libs-...@openjdk.java.net; Lindenmaier,
> > Goetz 
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> > 12.1
> >
> > Hello.
> > 8202322 was integrated into jdk-11+15.
> > I'm using XLC 13.1.3 on AIX 7.1.4.
> > Build was failed because of "-qvisibility=hidden" on
> > make/lib/LibCommon.gmk.
> > According to "XL C/C++ for AIX 13.1.3" documentation [1],
> > "-qvisibility=hidden" cannot create shared libraries entry points.
> > For example, libverify.so was there, but entry points were not resolved
> > by "-lverify" option.
> > I think it should be "-qvisibility=default" (I tried, it worked)
> > or "-qvisibility=protected" (I had not tried) ?
> > I'm not familiar with -qvisibility option, but I'd like to find out
> > right way.
> >
> > [1]
> >
> https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.
> > xlcpp1313.aix.doc/compiler_ref/opt_visibility.html
> >
> > On 2018-05-16 16:08, Langer, Christoph wrote:
> > > Hi Matthias,
> > >
> > > yes, reviewed.
> > >
> > > Best regards
> > > Christoph
> > >
> > > From: Baesken, Matthias
> > > Sent: Mittwoch, 16. Mai 2018 09:06
> > > To: Langer, Christoph ;
> > > 'build-dev@openjdk.java.net' ;
> > > ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net
> > > Cc: Lindenmaier, Goetz 
> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > > xlc 12.1
> > >
> > > Hi  Christoph can I add you as second reviewer  (other reviewer was
> > > Erik Joelsson) can push the change ?
> > >
> > > Best regards, Matthias
> > >
> > >
> > >
> > > From: Langer, Christoph
> > > Sent: Donnerstag, 26. April 2018 16:38
> > > To: Baesken, Matthias
> > > mailto:matthias.baes...@sap.com>>;
> > > 'build-dev@openjdk.java.net'
> > > mailto:build-dev@openjdk.java.net>>;
> > > ppc-aix-port-...@openjdk.java.net > d...@openjdk.java.net>;
> > > core-libs-...@openjdk.java.net d...@openjdk.java.net>
> > > Cc: Simonis, Volker
> > > mailto:volker.simo...@sap.com>>
> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > > xlc 12.1
> > >
> > > Hi Matthias,
> > >
> > > to me the change in principal looks good.
> > >
> > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g.
> > > extract major number before the first dot, then compare numerically) -
> > > but maybe it is too complicated and the current single version compare
> > > suits our needs ?
> > >
> > > Best regards
> > > Christoph
> > >
> > > From: Baesken, Matthias
> > > Sent: Donnerstag, 26. April 2018 16:14
> > > To: 'build-dev@openjdk.java.net'
> > > mailto:build-dev@openjdk.java.net>>;
> > > ppc-aix-port-...@openjdk.java.net > d...@openjdk.java.net>;
> > > 

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Langer, Christoph]

Hi Ichiroh,

we do not use the XLC 13 compiler on AIX yet here at SAP and I believe nobody 
of my colleagues has played with it yet. So you are on a new playground here 

However, I believe the idea in OpenJDK with the abolition of map files is that 
symbols should be invisible externally unless they are declared exported, e.g. 
JNIEXPORT. So I would think "-qvisibility=hidden" should be the correct default 
and whatever JNIEXPORT expands to should contain the right attributes to get 
that symbol visible.

Can you check if either my assumption is completely wrong, JNIEXPORT does not 
expand to the right thing, XLC 13 has a bug or maybe just sume specific 
required symbols are not declared correctly?

Best regards
Christoph

> -Original Message-
> From: Ichiroh Takiguchi [mailto:taki...@linux.vnet.ibm.com]
> Sent: Donnerstag, 31. Mai 2018 09:55
> To: Langer, Christoph 
> Cc: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-...@openjdk.java.net; Lindenmaier,
> Goetz 
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hello.
> 8202322 was integrated into jdk-11+15.
> I'm using XLC 13.1.3 on AIX 7.1.4.
> Build was failed because of "-qvisibility=hidden" on
> make/lib/LibCommon.gmk.
> According to "XL C/C++ for AIX 13.1.3" documentation [1],
> "-qvisibility=hidden" cannot create shared libraries entry points.
> For example, libverify.so was there, but entry points were not resolved
> by "-lverify" option.
> I think it should be "-qvisibility=default" (I tried, it worked)
> or "-qvisibility=protected" (I had not tried) ?
> I'm not familiar with -qvisibility option, but I'd like to find out
> right way.
> 
> [1]
> https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.
> xlcpp1313.aix.doc/compiler_ref/opt_visibility.html
> 
> On 2018-05-16 16:08, Langer, Christoph wrote:
> > Hi Matthias,
> >
> > yes, reviewed.
> >
> > Best regards
> > Christoph
> >
> > From: Baesken, Matthias
> > Sent: Mittwoch, 16. Mai 2018 09:06
> > To: Langer, Christoph ;
> > 'build-dev@openjdk.java.net' ;
> > ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net
> > Cc: Lindenmaier, Goetz 
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > xlc 12.1
> >
> > Hi  Christoph can I add you as second reviewer  (other reviewer was
> > Erik Joelsson) can push the change ?
> >
> > Best regards, Matthias
> >
> >
> >
> > From: Langer, Christoph
> > Sent: Donnerstag, 26. April 2018 16:38
> > To: Baesken, Matthias
> > mailto:matthias.baes...@sap.com>>;
> > 'build-dev@openjdk.java.net'
> > mailto:build-dev@openjdk.java.net>>;
> > ppc-aix-port-...@openjdk.java.net d...@openjdk.java.net>;
> > core-libs-...@openjdk.java.net
> > Cc: Simonis, Volker
> > mailto:volker.simo...@sap.com>>
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > xlc 12.1
> >
> > Hi Matthias,
> >
> > to me the change in principal looks good.
> >
> > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g.
> > extract major number before the first dot, then compare numerically) -
> > but maybe it is too complicated and the current single version compare
> > suits our needs ?
> >
> > Best regards
> > Christoph
> >
> > From: Baesken, Matthias
> > Sent: Donnerstag, 26. April 2018 16:14
> > To: 'build-dev@openjdk.java.net'
> > mailto:build-dev@openjdk.java.net>>;
> > ppc-aix-port-...@openjdk.java.net d...@openjdk.java.net>;
> > core-libs-...@openjdk.java.net
> > Cc: Langer, Christoph
> > mailto:christoph.lan...@sap.com>>; Simonis,
> > Volker mailto:volker.simo...@sap.com>>
> > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> > 12.1
> >
> > Hello  ,  could you please review this small adjustment to  the symbol
> > visibility compilation settings on AIX ?
> > Currently  we use  XLC 12.1  to compile  JDK on AIX .
> >
> > However XLC 12.1   does not support  the "-qvisibility=hidden"
> > setting currently set on AIX.
> > It was introduced with  XLC 13.1 . Christoph found some info about it
> > here :
> >
> > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> visibility-part2/index.html
> >
> > Setting it  only generates  hundreds  of warnings  in the build log ,
> > warnings look like this :
> > XlC12.1
> >
> > bash-4.4$ xlC -qversion
> > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
> > Version: 12.01..0019
> >
> > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list
> > of valid options.
> >
> > Compare to XLC13.1
> >
> > bash-3.00$ xlC -qversion
> > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
> > Version: 13.01..0008
> > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc

Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c

[Adam Farley8]

Sounds OK to me. :)

Best Regards

Adam Farley 

Philip Race  wrote on 01/06/2018 03:04:12:

> From: Philip Race 
> To: Adam Farley8 
> Cc: 2d-dev <2d-...@openjdk.java.net>, build-dev  d...@openjdk.java.net>, Andrew Leonard ,
> "Stuefe, Thomas" 
> Date: 01/06/2018 03:04
> Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix 
> compile warning in jchuff.c
> 
> > It looks fine to me but I am a bit hazy about who to give 
> attribution for the fix .. 
> 
> I pondered this for a little while and decided it should be
> joint between Adam who identified the issue and championed
> it and Thomas who I think first suggested the code change, modified only
> slightly at Guido's suggestion.
> 
> I'll push it tomorrow if every one is OK with that.
> 
> -phil.
> 
> On 5/31/18, 10:33 AM, Phil Race wrote: 
> 
> I've grabbed the bug from Thomas and re-opened it
> 
> https://bugs.openjdk.java.net/browse/
> 
> Your webrev was stripped so I've uploaded here :
> 
> http://cr.openjdk.java.net/~prr/8200052/
> 
> It looks fine to me but I am a bit hazy about who to give 
> attribution for the fix .. 
> It is small enough to not require an OCA so there's no issue there 
> if we attribute
> it to the IJG guy.
> 
> -phil.

> On 05/31/2018 06:31 AM, Adam Farley8 wrote:
> An attachment in the email has been found to contain executable code
> and has been removed.
> 
> File removed : webrev.zip, zip,html,js
> Hi Phil, 
> 
> As requested: 
> 
> 
> 
> FYI: I've also contacted Guido, confirmed that the fix worked, and asked 

> him to go ahead with merging the fix into his code base.
> 
> Best Regards
> 
> Adam Farley 
> 
> 
> Phil Race  wrote on 30/05/2018 18:06:19:
> 
> > From: Phil Race  
> > To: Adam Farley8  
> > Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard 
> > , build-dev  > d...@openjdk.java.net>, Magnus Ihse Bursie 
> > , "Thomas Stüfe" 
 
> > Date: 30/05/2018 18:07 
> > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix 
> > compile warning in jchuff.c 
> > 
> > Thank you for persevering with this. Please submit a webrev with this
> > change .. I think you can leave out the change to jerror.h in the 
> jpeg6b case.
> > 
> > -phil.
> 
> > On 05/30/2018 09:08 AM, Adam Farley8 wrote: 
> > Hi Phil, 
> > 
> > I spoke with the jpegclub rep "Guido", and he was very helpful. 
> > 
> > He agreed to accept a code change, but recommended an error instead 
> > of a while check. 
> > 
> > -- Line 808: 
> > <   while (bits[j] == 0) 
> > < j--; 
> > --- 
> > >   while (bits[j] == 0) { 
> > > if (j == 0) 
> > >   ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); 
> > > j--; 
> > >   } 
> > -- 
> > 
> > This makes sense to me, and I verified that it prevents the error. 
> > 
> > He says: 
> >  
> > For the release version I would replace the specific 
> > JERR_HUFF_CLEN_OVERFLOW by the more general 
> > JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this 
> > requires a change in jerror.h:
> > 
> > -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow")
> > +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out
> of bounds")
> > 
> > The next version (9d) is planned for release in January 2020.
> > A pre-release package will be provided in 2019 on http://
> > jpegclub.org/reference/reference-sources/, I will send you a 
notification.
> >  
> > 
> > While we *could* make the jerror.h change, I suggest we don't for 
> > now. If we merge from upstream in January 2020, we'll get that 
> > change anyway when the time comes. 
> > 
> > So what do you say to including the dashed change referenced above 
> > to fix our problem now, safe in the knowledge that upstream will be 
> > similarly modified (except with the new error type). 
> > 
> > Best Regards
> > 
> > Adam Farley 
> > 
> > P.S. I'm holding off on giving Guido the green light until after 
> > people say if they're happy with the error-enabled version of the fix. 

> > 
> > Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28:
> > 
> > > From: Adam Farley8/UK/IBM 
> > > To: Phil Race  
> > > Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard 
> > > , build-dev  > > d...@openjdk.java.net>, Magnus Ihse Bursie 
> > > , "Thomas Stüfe" 

> > > Date: 14/05/2018 11:06 
> > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix 
> > > compile warning in jchuff.c 
> > > 
> > > Hi Phil, 
> > > 
> > > Would an acceptable compromise be to deliver the source code change 
> > > and send the code to the upstream community, allowing them to 
include 
> > > the fix if/when they are able? 
> > > 
> > > I believe Magnus was advocating this idea as well. See below. 
> > > 
> > > Best Regards 
> > > 
> > > Adam Farley 
> > > 
> > > > Same here. I would like to have this fix in, but do not want to go 

> > > > over Phils head. 
> > > > 
> > > > I think Phil was the main objector, maybe he could reconsider?` 
> > > >