From philip.race at oracle.com  Fri Jun  1 02:04:12 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 31 May 2018 19:04:12 -0700
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <64b546b2-c33a-dafd-f284-a2aedac8d730@oracle.com>
References: <OFE7A4729A.3751A252-ON0025829D.00577F9E-8025829D.0058A338@notes.na.collabserv.com>
 <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com>
 <OF6FCCD2DF.B4AE4E55-ON0025829E.003F6F80-8025829E.004A5648@notes.na.collabserv.com>
 <64b546b2-c33a-dafd-f284-a2aedac8d730@oracle.com>
Message-ID: <5B10A99C.1000104@oracle.com>

 > 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 <philip.race at oracle.com> wrote on 30/05/2018 18:06:19:
>>
>> > From: Phil Race <philip.race at oracle.com>
>> > To: Adam Farley8 <adam.farley at uk.ibm.com>
>> > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard
>> > <andrew_m_leonard at uk.ibm.com>, build-dev <build-
>> > dev at openjdk.java.net>, Magnus Ihse Bursie
>> > <magnus.ihse.bursie at oracle.com>, "Thomas St?fe" 
>> <thomas.stuefe at gmail.com>
>> > 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 <philip.race at oracle.com>
>> > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard
>> > > <andrew_m_leonard at uk.ibm.com>, build-dev <build-
>> > > dev at openjdk.java.net>, Magnus Ihse Bursie
>> > > <magnus.ihse.bursie at oracle.com>, "Thomas St?fe" 
>> <thomas.stuefe at gmail.com>
>> > > 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?`
>> > > >
>> > > > Thanks, Thomas
>> > > >
>> > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie
>> > > > <magnus.ihse.bursie at oracle.com> wrote:
>> > > > > I don't object, but it's not build code so I don't have the 
>> final say.
>> > > > >
>> > > > > /Magnus
>> > > > >
>> > > > >
>> > > > > On 2018-04-25 17:43, Adam Farley8 wrote:
>> > > > >
>> > > > > Hi All,
>> > > > >
>> > > > > Does anyone have an objection to pushing this tiny change in?
>> > > > >
>> > > > > It doesn't break anything, it fixes a build break on two 
>> supported
>> > > > > platforms, and it seems
>> > > > > like we never refresh the code from upstream.
>> > > > >
>> > > > > - Adam
>> > > > >
>> > > > >> I also advocate the source code fix, as Make isn't meant to
>> > use the sort
>> > > > >> of logic required
>> > > > >> to properly analyse the toolchain version string.
>> > > > >>
>> > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is
>> > using 4.8.6,
>> > > > >> and Make doesn't
>> > > > >> seem to do substring stuff unless you mess around with shells.
>> > > > >>
>> > > > >> Plus, as people have said, it's better to solve problem x (or
>> > work around
>> > > > >> a specific
>> > > > >> instance of x) than to ignore the exception, even if the
>> > ignoring code is
>> > > > >> toolchain-
>> > > > >> specific.
>> > > > >>
>> > > > >> - Adam Farley
>> > > > >>
>> > > > >> > On 2018-03-27 18:44, Phil Race wrote:
>> > > > >> >
>> > > > >> >> As I said I prefer the make file change, since this is a
>> > change to an
>> > > > >> >> upstream library.
>> > > > >> >
>> > > > >> > Newtons fourth law: For every reviewer, there's an equal 
>> and opposite
>> > > > >> > reviewer. :)
>> > > > >> >
>> > > > >> > Here I am, advocating a source code fix. As Thomas says, 
>> the compiler
>> > > > >> > complaint seems reasonable, and disabling it might cause us
>> > > to miss other
>> > > > >> > future errors.
>> > > > >> >
>> > > > >> > Why can't we push the source code fix, and also submit it 
>> upstream?
>> > > > >> >
>> > > > >> > /Magnus
>> > > > >> >
>> > > > >> >
>> > > > >> > I've looked at jpeg-9c and it still looks identical to 
>> whatwe have in
>> > > > >> > 6b, so this code
>> > > > >> > seems to have stood the test of time. I'm also unclear why
>> > the compiler
>> > > > >> > would
>> > > > >> > complain about that and not the one a few lines later
>> > > > >> >
>> > > > >> >
>> > > > >> >  819   while (bits[i] == 0)          /* find largest
>> > > codelength still in
>> > > > >> > use */
>> > > > >> >  820     i--;
>> > > > >> >
>> > > > >> > A push to jchuff.c will get blown away if/when we upgrade.
>> > > > >> > A tool-chain specific fix in the makefile with an
>> > appropriatecomment is
>> > > > >> > more targeted.
>> > > > >>
>> > > > >> Phil,
>> > > > >>
>> > > > >> Returning to this.
>> > > > >>
>> > > > >> While I understand your reluctance to patch upstream code, 
>> let me point
>> > > > >> out that we have not updated libjpeg a single time since the
>> > JDK was open
>> > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the
>> > > Wikipedia page
>> > > > >> on libjpeg, and this is the latest "uncontroversial" version of
>> > > the source.
>> > > > >> Versions 7 and up have proprietary extensions, which in turn
>> > > has resulted in
>> > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that
>> > > we will ever
>> > > > >> replace libjpeg 6b with a simple upgrade from upstream.
>> > > > >>
>> > > > >> I therefore maintain my position that a source code fix would
>> > be the best
>> > > > >> way forward here.
>> > > > >>
>> > > > >> /Magnus
>> > > > >>
>> > > > >> >
>> > > > >> >
>> > > > >> > -phil.
>> > > > >> >
>> > > > >> >
>> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote:
>> > > > >> >
>> > > > >> > Hi all,
>> > > > >> >
>> > > > >> >
>> > > > >> > just a friendly reminder. I would like to push this tiny 
>> fix because
>> > > > >> > tripping over this on our linux s390x builds is annoying 
>> (yes, we can
>> > > > >> > maintain patch queues, but this is a constant error source).
>> > > > >> >
>> > > > >> >
>> > > > >> > I will wait for 24 more hours until a reaction. If no
>> > seriousobjections
>> > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and
>> > > me and Christoph
>> > > > >> > langer are both Reviewers).
>> > > > >> >
>> > > > >> >
>> > > > >> > Thanks! Thomas
>> > > > >> >
>> > > > >> >
>> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe
>> > <thomas.stuefe at gmail.com>
>> > > > >> > wrote:
>> > > > >> >
>> > > > >> > Hi all,
>> > > > >> >
>> > > > >> >
>> > > > >> > may I please have another review for this really trivial 
>> change. It
>> > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a
>> > > good idea to fix
>> > > > >> > this.
>> > > > >> >
>> > > > >> >
>> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052
>> > > > >> > webrev:
>> > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- 
>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8200052-fix->
>> > > warning-in-jchuff.c/webrev.00/webrev/
>> > > > >> >
>> > > > >> >
>> > > > >> > This was contributed by Adam Farley at IBM.
>> > > > >> >
>> > > > >> >
>> > > > >> > I already reviewed this. I also test-built on zlinux and it 
>> works.
>> > > > >> >
>> > > > >> >
>> > > > >> > Thanks, Thomas
>> > > > >> >
>> > > > >>
>> > > > >> 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
>> > > > >
>> > > > >
>> > >
>> > > 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
>> 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
>


From adam.farley at uk.ibm.com  Fri Jun  1 08:10:09 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 1 Jun 2018 09:10:09 +0100
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <5B10A99C.1000104@oracle.com>
References: <OFE7A4729A.3751A252-ON0025829D.00577F9E-8025829D.0058A338@notes.na.collabserv.com>
 <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com>
 <OF6FCCD2DF.B4AE4E55-ON0025829E.003F6F80-8025829E.004A5648@notes.na.collabserv.com>
 <64b546b2-c33a-dafd-f284-a2aedac8d730@oracle.com>
 <5B10A99C.1000104@oracle.com>
Message-ID: <OF37428FD7.1B318A84-ON0025829F.002CD2C8-8025829F.002CE101@notes.na.collabserv.com>

Sounds OK to me. :)

Best Regards

Adam Farley 

Philip Race <philip.race at oracle.com> wrote on 01/06/2018 03:04:12:

> From: Philip Race <philip.race at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: 2d-dev <2d-dev at openjdk.java.net>, build-dev <build-
> dev at openjdk.java.net>, Andrew Leonard <andrew_m_leonard at uk.ibm.com>,
> "Stuefe, Thomas" <thomas.stuefe at sap.com>
> 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 <philip.race at oracle.com> wrote on 30/05/2018 18:06:19:
> 
> > From: Phil Race <philip.race at oracle.com> 
> > To: Adam Farley8 <adam.farley at uk.ibm.com> 
> > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard 
> > <andrew_m_leonard at uk.ibm.com>, build-dev <build-
> > dev at openjdk.java.net>, Magnus Ihse Bursie 
> > <magnus.ihse.bursie at oracle.com>, "Thomas St?fe" 
<thomas.stuefe at gmail.com> 
> > 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 <philip.race at oracle.com> 
> > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard 
> > > <andrew_m_leonard at uk.ibm.com>, build-dev <build-
> > > dev at openjdk.java.net>, Magnus Ihse Bursie 
> > > <magnus.ihse.bursie at oracle.com>, "Thomas St?fe" 
<thomas.stuefe at gmail.com>
> > > 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?` 
> > > > 
> > > > Thanks, Thomas 
> > > > 
> > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie 
> > > > <magnus.ihse.bursie at oracle.com> wrote: 
> > > > > I don't object, but it's not build code so I don't have the 
> final say. 
> > > > > 
> > > > > /Magnus 
> > > > > 
> > > > > 
> > > > > On 2018-04-25 17:43, Adam Farley8 wrote: 
> > > > > 
> > > > > Hi All, 
> > > > > 
> > > > > Does anyone have an objection to pushing this tiny change in? 
> > > > > 
> > > > > It doesn't break anything, it fixes a build break on two 
supported 
> > > > > platforms, and it seems 
> > > > > like we never refresh the code from upstream. 
> > > > > 
> > > > > - Adam 
> > > > > 
> > > > >> I also advocate the source code fix, as Make isn't meant to 
> > use the sort 
> > > > >> of logic required 
> > > > >> to properly analyse the toolchain version string. 
> > > > >> 
> > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is 
> > using 4.8.6, 
> > > > >> and Make doesn't 
> > > > >> seem to do substring stuff unless you mess around with shells. 
> > > > >> 
> > > > >> Plus, as people have said, it's better to solve problem x (or
> > work around 
> > > > >> a specific 
> > > > >> instance of x) than to ignore the exception, even if the 
> > ignoring code is 
> > > > >> toolchain- 
> > > > >> specific. 
> > > > >> 
> > > > >> - Adam Farley 
> > > > >> 
> > > > >> > On 2018-03-27 18:44, Phil Race wrote: 
> > > > >> > 
> > > > >> >> As I said I prefer the make file change, since this is a 
> > change to an 
> > > > >> >> upstream library. 
> > > > >> > 
> > > > >> > Newtons fourth law: For every reviewer, there's an equal 
> and opposite
> > > > >> > reviewer. :) 
> > > > >> > 
> > > > >> > Here I am, advocating a source code fix. As Thomas says, 
> the compiler
> > > > >> > complaint seems reasonable, and disabling it might cause us 
> > > to miss other 
> > > > >> > future errors. 
> > > > >> > 
> > > > >> > Why can't we push the source code fix, and also submit 
itupstream? 
> > > > >> > 
> > > > >> > /Magnus 
> > > > >> > 
> > > > >> > 
> > > > >> > I've looked at jpeg-9c and it still looks identical to 
> whatwe have in
> > > > >> > 6b, so this code 
> > > > >> > seems to have stood the test of time. I'm also unclear why 
> > the compiler 
> > > > >> > would 
> > > > >> > complain about that and not the one a few lines later 
> > > > >> > 
> > > > >> > 
> > > > >> >  819   while (bits[i] == 0)          /* find largest 
> > > codelength still in 
> > > > >> > use */ 
> > > > >> >  820     i--; 
> > > > >> > 
> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. 
> > > > >> > A tool-chain specific fix in the makefile with an 
> > appropriatecomment is 
> > > > >> > more targeted. 
> > > > >> 
> > > > >> Phil, 
> > > > >> 
> > > > >> Returning to this. 
> > > > >> 
> > > > >> While I understand your reluctance to patch upstream code, 
> let me point
> > > > >> out that we have not updated libjpeg a single time since the 
> > JDK was open 
> > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the 
> > > Wikipedia page 
> > > > >> on libjpeg, and this is the latest "uncontroversial" version of
> > > the source. 
> > > > >> Versions 7 and up have proprietary extensions, which in turn 
> > > has resulted in 
> > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that
> > > we will ever 
> > > > >> replace libjpeg 6b with a simple upgrade from upstream. 
> > > > >> 
> > > > >> I therefore maintain my position that a source code fix would
> > be the best 
> > > > >> way forward here. 
> > > > >> 
> > > > >> /Magnus 
> > > > >> 
> > > > >> > 
> > > > >> > 
> > > > >> > -phil. 
> > > > >> > 
> > > > >> > 
> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: 
> > > > >> > 
> > > > >> > Hi all, 
> > > > >> > 
> > > > >> > 
> > > > >> > just a friendly reminder. I would like to push this tiny 
> fix because
> > > > >> > tripping over this on our linux s390x builds is annoying 
> (yes, we can
> > > > >> > maintain patch queues, but this is a constant error source). 
> > > > >> > 
> > > > >> > 
> > > > >> > I will wait for 24 more hours until a reaction. If no 
> > seriousobjections 
> > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and 
> > > me and Christoph 
> > > > >> > langer are both Reviewers). 
> > > > >> > 
> > > > >> > 
> > > > >> > Thanks! Thomas 
> > > > >> > 
> > > > >> > 
> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe 
> > <thomas.stuefe at gmail.com> 
> > > > >> > wrote: 
> > > > >> > 
> > > > >> > Hi all, 
> > > > >> > 
> > > > >> > 
> > > > >> > may I please have another review for this really trivial 
> change. It 
> > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a 
> > > good idea to fix 
> > > > >> > this. 
> > > > >> > 
> > > > >> > 
> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 
> > > > >> > webrev: 
> > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-
> > > warning-in-jchuff.c/webrev.00/webrev/ 
> > > > >> > 
> > > > >> > 
> > > > >> > This was contributed by Adam Farley at IBM. 
> > > > >> > 
> > > > >> > 
> > > > >> > I already reviewed this. I also test-built on zlinux and it 
works. 
> > > > >> > 
> > > > >> > 
> > > > >> > Thanks, Thomas 
> > > > >> > 
> > > > >> 
> > > > >> 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 
> > > > > 
> > > > > 
> > > 
> > > 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
> 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


From christoph.langer at sap.com  Fri Jun  1 08:56:34 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 1 Jun 2018 08:56:34 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <0c73caec8810b9844a463343bdaec064@linux.vnet.ibm.com>
References: <0c73caec8810b9844a463343bdaec064@linux.vnet.ibm.com>
Message-ID: <ad8328a48b824282b40bf5293e7fade0@sap.com>

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:takiguc at linux.vnet.ibm.com]
> Sent: Donnerstag, 31. Mai 2018 09:55
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> Goetz <goetz.lindenmaier at sap.com>
> 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 <christoph.langer at sap.com>;
> > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
> > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > 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
> > <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
> > 'build-dev at openjdk.java.net'
> > <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>;
> > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> dev at openjdk.java.net>;
> > core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
> > Cc: Simonis, Volker
> > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
> > <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>;
> > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> dev at openjdk.java.net>;
> > core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
> > Cc: Langer, Christoph
> > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Simonis,
> > Volker <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
> > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> >
> >
> > So it is better to avoid  setting these flags when using xlc12.1   .
> > Please review :
> >
> > Bug :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8202322
> >
> > Change :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
> >
> >
> > Best regards, Matthias


From matthias.baesken at sap.com  Fri Jun  1 12:12:38 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 1 Jun 2018 12:12:38 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <ad8328a48b824282b40bf5293e7fade0@sap.com>
References: <0c73caec8810b9844a463343bdaec064@linux.vnet.ibm.com>
 <ad8328a48b824282b40bf5293e7fade0@sap.com>
Message-ID: <81453d0cbe05477ea558917de263ada2@sap.com>

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 <takiguc at linux.vnet.ibm.com>
> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> Goetz <goetz.lindenmaier at sap.com>
> 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:takiguc at linux.vnet.ibm.com]
> > Sent: Donnerstag, 31. Mai 2018 09:55
> > To: Langer, Christoph <christoph.langer at sap.com>
> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> > Goetz <goetz.lindenmaier at sap.com>
> > 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 <christoph.langer at sap.com>;
> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
> > > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > > 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
> > > <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
> > > 'build-dev at openjdk.java.net'
> > > <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>;
> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> > dev at openjdk.java.net>;
> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> dev at openjdk.java.net>
> > > Cc: Simonis, Volker
> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
> > > <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>;
> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> > dev at openjdk.java.net>;
> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> dev at openjdk.java.net>
> > > Cc: Langer, Christoph
> > > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
> Simonis,
> > > Volker <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> > >
> > >
> > > So it is better to avoid  setting these flags when using xlc12.1   .
> > > Please review :
> > >
> > > Bug :
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8202322
> > >
> > > Change :
> > >
> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
> > >
> > >
> > > Best regards, Matthias


From erik.joelsson at oracle.com  Fri Jun  1 20:53:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 1 Jun 2018 13:53:52 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with speculative
 execution disabled
Message-ID: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>

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



From shade at redhat.com  Fri Jun  1 21:00:48 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 1 Jun 2018 23:00:48 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
Message-ID: <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>

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



From erik.joelsson at oracle.com  Fri Jun  1 22:02:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 1 Jun 2018 15:02:33 -0700
Subject: RFR: JDK-8200132: Remove jre images and bundles
Message-ID: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>

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



From mandy.chung at oracle.com  Fri Jun  1 22:33:23 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 1 Jun 2018 15:33:23 -0700
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
Message-ID: <ec45fb1c-1332-2cb9-83bb-9cd7b2fab117@oracle.com>

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
> 


From martinrb at google.com  Fri Jun  1 22:37:51 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 1 Jun 2018 15:37:51 -0700
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
Message-ID: <CA+kOe09+NGsrxKD0PhOCB7MtUGpK7q57SMXrT9a8kixNoH_P6Q@mail.gmail.com>

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 <erik.joelsson at oracle.com>
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
>
>


From magnus.ihse.bursie at oracle.com  Sat Jun  2 06:36:54 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sat, 2 Jun 2018 09:36:54 +0300
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
Message-ID: <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>

The actual changes look good to me. 

As a follow up, I think we should check if we could remove some of the JDK prefixes that was in place just to differentiate from the JRE. The term JDK is so overloaded, so it would be good to get rid of it where possible (as in "JDK image", which should be only "image" now). 

I also hear Martin's fear about this being a too large change. I don't think that is a problem per se, but you should probably get some input from our downstream distributors so that they are able to provide the packages they feel are needed. 

/Magnus

> 2 juni 2018 kl. 01:02 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> 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
> 



From magnus.ihse.bursie at oracle.com  Sat Jun  2 06:45:50 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sat, 2 Jun 2018 09:45:50 +0300
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
Message-ID: <B84A93F2-D43D-4A82-8054-0724A4DA453D@oracle.com>



/Magnus

> 1 juni 2018 kl. 23:53 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> 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
> 



From magnus.ihse.bursie at oracle.com  Sat Jun  2 06:47:24 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sat, 2 Jun 2018 09:47:24 +0300
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
Message-ID: <082B6E27-E5A4-4B5C-9ACF-081B9C79472E@oracle.com>


> 1 juni 2018 kl. 23:53 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> 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.

I think we should keep the praxis of only having server as default. 

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

Thanks for fixing this!

> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202384
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01

Looks good to me. 

/Magnus

> 
> /Erik
> 



From shade at redhat.com  Sat Jun  2 07:05:23 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Sat, 2 Jun 2018 09:05:23 +0200
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
Message-ID: <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>

On 06/02/2018 08:36 AM, Magnus Ihse Bursie wrote:
> The actual changes look good to me.
> 
> As a follow up, I think we should check if we could remove some of the JDK prefixes that was in
> place just to differentiate from the JRE. The term JDK is so overloaded, so it would be good to
> get rid of it where possible (as in "JDK image", which should be only "image" now).
> 
> I also hear Martin's fear about this being a too large change. I don't think that is a problem
> per se, but you should probably get some input from our downstream distributors so that they are
> able to provide the packages they feel are needed.

Unfortunately, in the age of containers, distribution size matters. It makes the whole sense to ship
JRE in Docker containers to provide the execution environment for the upper layers. Remember, hardly
any application is fully modularized and/or uses jlink/jimage way of distribution.

Also, products that ship with their own OpenJDK distribution (e.g. JetBrains IDEs) do ship with
jres, which cuts down their distribution sizes.

Cost savings for having JRE only are significant, as can be observed with current bundles:

 178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
  38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz

Therefore, I believe removing jre is too disruptive, at least for 11, at least until we see that the
whole jlink/jimage thing really works out in the wider Java ecosystem and JREs are really abandoned.

Thanks,
-Aleksey



From Alan.Bateman at oracle.com  Sat Jun  2 07:05:56 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 2 Jun 2018 08:05:56 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
Message-ID: <938bb8e7-6abe-a4d6-29ff-38f561525c8a@oracle.com>

On 01/06/2018 23:02, 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/
You are right that moving to modules has blurred the historical 
distinction between what we used to know as the JDK and JRE and I 
completely agree that the JRE is now a relic and just not interesting 
since JDK 9. However, dropping the ability to build the "jre" image is a 
significant change and I think will need to be socialized more widely as 
it will likely impact downstream installers and other consumers of the 
build. It may even need a JEP.

-Alan


From Alan.Bateman at oracle.com  Sat Jun  2 07:20:34 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 2 Jun 2018 08:20:34 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
Message-ID: <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>

On 02/06/2018 08:05, Aleksey Shipilev wrote:
> :
> Unfortunately, in the age of containers, distribution size matters. It makes the whole sense to ship
> JRE in Docker containers to provide the execution environment for the upper layers. Remember, hardly
> any application is fully modularized and/or uses jlink/jimage way of distribution.
>
> Also, products that ship with their own OpenJDK distribution (e.g. JetBrains IDEs) do ship with
> jres, which cuts down their distribution sizes.
>
> Cost savings for having JRE only are significant, as can be observed with current bundles:
>
>   178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>    38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>
> Therefore, I believe removing jre is too disruptive, at least for 11, at least until we see that the
> whole jlink/jimage thing really works out in the wider Java ecosystem and JREs are really abandoned.
I don't disagree with the significance of what has been proposed here. 
However, just to point out that creating what used to know as the JRE is 
one `jlink` command. There is no requirement for the application or 
libraries using that run-time be developed as modules. Also incorporate 
generating of JDK run-time images into the build when working with 
containers is very useful as you get fine control on which modules to 
include.

-Alan



From magnus.ihse.bursie at oracle.com  Sat Jun  2 14:07:25 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sat, 2 Jun 2018 17:07:25 +0300
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
Message-ID: <48DDB994-52ED-4483-A43C-AB63C578AF28@oracle.com>

It is probably relatively trivial to add a configure option to select just the "JRE modules" when building, rather than all modules. If we add such an option, it would still be possible to build a traditional JRE, not just at the same time as building the full JDK. Doing Erik's change as suggested here, combined with such additional functionality would allow us to remove a lot of old cruft from the build system, while still allowing distributors to build a JRE. I'd recommend doing something like this, rather than to delay this patch to post-JDK11. 

/Magnus

> 2 juni 2018 kl. 10:20 skrev Alan Bateman <Alan.Bateman at oracle.com>:
> 
>> On 02/06/2018 08:05, Aleksey Shipilev wrote:
>> :
>> Unfortunately, in the age of containers, distribution size matters. It makes the whole sense to ship
>> JRE in Docker containers to provide the execution environment for the upper layers. Remember, hardly
>> any application is fully modularized and/or uses jlink/jimage way of distribution.
>> 
>> Also, products that ship with their own OpenJDK distribution (e.g. JetBrains IDEs) do ship with
>> jres, which cuts down their distribution sizes.
>> 
>> Cost savings for having JRE only are significant, as can be observed with current bundles:
>> 
>>  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>>   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>> 
>> Therefore, I believe removing jre is too disruptive, at least for 11, at least until we see that the
>> whole jlink/jimage thing really works out in the wider Java ecosystem and JREs are really abandoned.
> I don't disagree with the significance of what has been proposed here. However, just to point out that creating what used to know as the JRE is one `jlink` command. There is no requirement for the application or libraries using that run-time be developed as modules. Also incorporate generating of JDK run-time images into the build when working with containers is very useful as you get fine control on which modules to include.
> 
> -Alan
> 



From swpalmer at gmail.com  Sat Jun  2 14:23:42 2018
From: swpalmer at gmail.com (Scott Palmer)
Date: Sat, 2 Jun 2018 10:23:42 -0400
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
Message-ID: <1C4D5CAC-55DC-49FC-85DC-9A1C26B61F6B@gmail.com>


I work on a product that is built from a collection of plugins. Many of the plugins are distributed after the main framework is installed. That product will always need a full JRE because there is no way to know in advance which modules will be needed.

A full JRE ?image? is a requirement for me.

Also, jlink apparently only works with 100% modular applications. That will be impossible in the near term as all dependencies are not yet modularized and they may never be.

Modularization has been very disruptive. We have yet to move past Java 8 because code doesn?t ?just work? when transitioning from Java 8 to anything beyond. With previous upgrades we only had to deal with minor issues, if any.

Scott

> On Jun 2, 2018, at 3:05 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Therefore, I believe removing jre is too disruptive, at least for 11, at least until we see that the
> whole jlink/jimage thing really works out in the wider Java ecosystem and JREs are really abandoned.
> 
> Thanks,
> -Aleksey
> 


From Alan.Bateman at oracle.com  Sat Jun  2 17:01:06 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 2 Jun 2018 18:01:06 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <48DDB994-52ED-4483-A43C-AB63C578AF28@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
 <48DDB994-52ED-4483-A43C-AB63C578AF28@oracle.com>
Message-ID: <a878ee8f-8d73-bf3e-b0a5-2cc4b7141a81@oracle.com>

On 02/06/2018 15:07, Magnus Ihse Bursie wrote:
> It is probably relatively trivial to add a configure option to select just the "JRE modules" when building, rather than all modules. If we add such an option, it would still be possible to build a traditional JRE, not just at the same time as building the full JDK. Doing Erik's change as suggested here, combined with such additional functionality would allow us to remove a lot of old cruft from the build system, while still allowing distributors to build a JRE. I'd recommend doing something like this, rather than to delay this patch to post-JDK11.
>
Removing old cruft is good. Also not building the jre image by default 
might reduce build times a little bit, a boon for those doing "make 
images" but never using the jre image (as the tests are run on the jdk 
image, not the jre image).

I don't have an opinion on whether configure option or a make target is 
the right approach. It might be that those consuming the jre image today 
are using the bundles target, a target that I wouldn't expect most 
developers will use when working on OpenJDK. Part of the socializing of 
this topic might be to get a better handle on what downstream projects 
and packagers are doing with the jre image (beyond creating install 
bundles for specific distros).

-Alan


From david.buck at oracle.com  Sat Jun  2 23:17:27 2018
From: david.buck at oracle.com (David Buck)
Date: Sun, 3 Jun 2018 08:17:27 +0900
Subject: [8] RFR (XS) 8204053 : libsaproc.so not linked with -z,noexecstack
Message-ID: <163c2da5-25e1-37b7-d250-7689f21963fc@oracle.com>

Hi!

Please review this very small fix. It only applies to JDK 8.

bug report:
https://bugs.openjdk.java.net/browse/JDK-8204053

webrev:
http://cr.openjdk.java.net/~dbuck/8204053.0/

JPRT hotspot testset run and passed. Efficacy of fix manually confirmed.

Cheers,
-Buck


From magnus.ihse.bursie at oracle.com  Mon Jun  4 11:20:09 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 4 Jun 2018 13:20:09 +0200
Subject: RFR: 8204210: Implementation: JEP 333: ZGC: A Scalable
 Low-Latency Garbage Collector (Experimental)
In-Reply-To: <69590d4c-d675-9910-035d-eabe8be9fdfc@oracle.com>
References: <69590d4c-d675-9910-035d-eabe8be9fdfc@oracle.com>
Message-ID: <960f8433-4a25-4ed7-e5a3-645324840116@oracle.com>

Hi Per,

Please always include build-dev when proposing build changes.

The changes in make/autoconf/hotspot.m4 looks a bit suspect. Since you 
are adding zgc to disabled jvm features, which always override enabled 
features, it will never be possible to enable zgc on any other platform. 
Is this intentional? Otherwise, I suggest instead adding zgc to the 
baseline set NON_MINIMAL_FEATURES for linux-x64.

/Magnus



On 2018-06-01 23:41, Per Liden wrote:
> Hi,
>
> Please review the implementation of JEP 333: ZGC: A Scalable 
> Low-Latency Garbage Collector (Experimental)
>
> Please see the JEP for more information about the project. The JEP is 
> currently in state "Proposed to Target" for JDK 11.
>
> https://bugs.openjdk.java.net/browse/JDK-8197831
>
> Additional information in can also be found on the ZGC project wiki.
>
> https://wiki.openjdk.java.net/display/zgc/Main
>
>
> Webrevs
> -------
>
> To make this easier to review, we've divided the change into two webrevs.
>
> * ZGC Master: http://cr.openjdk.java.net/~pliden/8204210/webrev.0-master
>
>   This patch contains the actual ZGC implementation, the new unit 
> tests and other changes needed in HotSpot.
>
> * ZGC Testing: 
> http://cr.openjdk.java.net/~pliden/8204210/webrev.0-testing
>
>   This patch contains changes to existing tests needed by ZGC.
>
>
> Overview of Changes
> -------------------
>
> Below follows a list of the files we add/modify in the master patch, 
> with a short summary describing each group.
>
> * Build support - Making ZGC an optional feature.
>
>   make/autoconf/hotspot.m4
>   make/hotspot/lib/JvmFeatures.gmk
>   src/hotspot/share/utilities/macros.hpp
>
> * C2 AD file - Additions needed to generate ZGC load barriers (adlc 
> does not currently offer a way to easily break this out).
>
>   src/hotspot/cpu/x86/x86.ad
>   src/hotspot/cpu/x86/x86_64.ad
>
> * C2 - Things that can't be easily abstracted out into ZGC specific 
> code, most of which is guarded behind a #if INCLUDE_ZGC and/or if 
> (UseZGC) condition. There should only be two logic changes (one in 
> idealKit.cpp and one in node.cpp) that are still active when ZGC is 
> disabled. We believe these are low risk changes and should not 
> introduce any real change i behavior when using other GCs.
>
>   src/hotspot/share/adlc/formssel.cpp
>   src/hotspot/share/opto/*
>   src/hotspot/share/compiler/compilerDirectives.hpp
>
> * General GC+Runtime - Registering ZGC as a collector.
>
>   src/hotspot/share/gc/shared/*
>   src/hotspot/share/runtime/vmStructs.cpp
>   src/hotspot/share/runtime/vm_operations.hpp
>   src/hotspot/share/prims/whitebox.cpp
>
> * GC thread local data - Increasing the size of data area by 32 bytes.
>
>   src/hotspot/share/gc/shared/gcThreadLocalData.hpp
>
> * ZGC - The collector itself.
>
>   src/hotspot/share/gc/z/*
>   src/hotspot/cpu/x86/gc/z/*
>   src/hotspot/os_cpu/linux_x86/gc/z/*
>   test/hotspot/gtest/gc/z/*
>
> * JFR - Adding new event types.
>
>   src/hotspot/share/jfr/*
>   src/jdk.jfr/share/conf/jfr/*
>
> * Logging - Adding new log tags.
>
>   src/hotspot/share/logging/*
>
> * Metaspace - Adding a friend declaration.
>
>   src/hotspot/share/memory/metaspace.hpp
>
> * InstanceRefKlass - Adjustments for concurrent reference processing.
>
>   src/hotspot/share/oops/instanceRefKlass.inline.hpp
>
> * vmSymbol - Disabled clone intrinsic for ZGC.
>
>   src/hotspot/share/classfile/vmSymbols.cpp
>
> * Oop Verification - In four cases we disabled oop verification 
> because it do not makes sense or is not applicable to a GC using load 
> barriers.
>
>   src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
>   src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
>   src/hotspot/share/compiler/oopMap.cpp
>   src/hotspot/share/runtime/jniHandles.cpp
>
> * StackValue - Apply a load barrier in case of OSR. This is a bit of a 
> hack. However, this will go away in the future, when we have the next 
> iteration of C2's load barriers in place (aka "C2 late barrier 
> insertion").
>
>   src/hotspot/share/runtime/stackValue.cpp
>
> * JVMTI - Adding an assert() to catch problems if the tagmap hashing 
> is changed in the future.
>
>   src/hotspot/share/prims/jvmtiTagMap.cpp
>
> * Legal - Adding copyright/license for 3rd party hash function used in 
> ZHash.
>
>   src/java.base/share/legal/c-libutl.md
>
> * SA - Adding basic ZGC support.
>
>   src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/*
>
>
> Testing
> -------
>
> * Unit testing
>
>   A number of new ZGC specific gtests have been added, in 
> test/hotspot/gtest/gc/z/
>
> * Regression testing
>
>   No new failures in Mach5, with ZGC enabled, tier{1,2,3,4,5,6}
>   No new failures in Mach5, with ZGC disabled, tier{1,2,3}
>
> * Stress testing
>
>   We have been continuously been running a number stress tests 
> throughout the development, these include:
>
>     specjbb2000
>     specjbb2005
>     specjbb2015
>     specjvm98
>     specjvm2008
>     dacapo2009
>     test/hotspot/jtreg/gc/stress/gcold
>     test/hotspot/jtreg/gc/stress/systemgc
>     test/hotspot/jtreg/gc/stress/gclocker
>     test/hotspot/jtreg/gc/stress/gcbasher
>     test/hotspot/jtreg/gc/stress/finalizer
>     Kitchensink
>
>
> Thanks!
>
> /Per, Stefan & the ZGC team



From per.liden at oracle.com  Mon Jun  4 12:05:47 2018
From: per.liden at oracle.com (Per Liden)
Date: Mon, 4 Jun 2018 14:05:47 +0200
Subject: RFR: 8204210: Implementation: JEP 333: ZGC: A Scalable
 Low-Latency Garbage Collector (Experimental)
In-Reply-To: <960f8433-4a25-4ed7-e5a3-645324840116@oracle.com>
References: <69590d4c-d675-9910-035d-eabe8be9fdfc@oracle.com>
 <960f8433-4a25-4ed7-e5a3-645324840116@oracle.com>
Message-ID: <de78a354-2103-366d-551f-e723d06f65a0@oracle.com>

Hi Magnus,

Thanks for reviewing.

On 06/04/2018 01:20 PM, Magnus Ihse Bursie wrote:
> Hi Per,
> 
> Please always include build-dev when proposing build changes.
> 
> The changes in make/autoconf/hotspot.m4 looks a bit suspect. Since you 
> are adding zgc to disabled jvm features, which always override enabled 
> features, it will never be possible to enable zgc on any other platform.
> Is this intentional? Otherwise, I suggest instead adding zgc to the 
> baseline set NON_MINIMAL_FEATURES for linux-x64.
> 

Yes, that's intentional, since ZGC is only supported on linux-x64 and 
enabling ZGC on other platforms wouldn't build. When additional 
platforms gets supported, this check would of course also be updated to 
reflect that.

cheers,
Per

> /Magnus
> 
> 
> 
> On 2018-06-01 23:41, Per Liden wrote:
>> Hi,
>>
>> Please review the implementation of JEP 333: ZGC: A Scalable 
>> Low-Latency Garbage Collector (Experimental)
>>
>> Please see the JEP for more information about the project. The JEP is 
>> currently in state "Proposed to Target" for JDK 11.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8197831
>>
>> Additional information in can also be found on the ZGC project wiki.
>>
>> https://wiki.openjdk.java.net/display/zgc/Main
>>
>>
>> Webrevs
>> -------
>>
>> To make this easier to review, we've divided the change into two webrevs.
>>
>> * ZGC Master: http://cr.openjdk.java.net/~pliden/8204210/webrev.0-master
>>
>> ? This patch contains the actual ZGC implementation, the new unit 
>> tests and other changes needed in HotSpot.
>>
>> * ZGC Testing: 
>> http://cr.openjdk.java.net/~pliden/8204210/webrev.0-testing
>>
>> ? This patch contains changes to existing tests needed by ZGC.
>>
>>
>> Overview of Changes
>> -------------------
>>
>> Below follows a list of the files we add/modify in the master patch, 
>> with a short summary describing each group.
>>
>> * Build support - Making ZGC an optional feature.
>>
>> ? make/autoconf/hotspot.m4
>> ? make/hotspot/lib/JvmFeatures.gmk
>> ? src/hotspot/share/utilities/macros.hpp
>>
>> * C2 AD file - Additions needed to generate ZGC load barriers (adlc 
>> does not currently offer a way to easily break this out).
>>
>> ? src/hotspot/cpu/x86/x86.ad
>> ? src/hotspot/cpu/x86/x86_64.ad
>>
>> * C2 - Things that can't be easily abstracted out into ZGC specific 
>> code, most of which is guarded behind a #if INCLUDE_ZGC and/or if 
>> (UseZGC) condition. There should only be two logic changes (one in 
>> idealKit.cpp and one in node.cpp) that are still active when ZGC is 
>> disabled. We believe these are low risk changes and should not 
>> introduce any real change i behavior when using other GCs.
>>
>> ? src/hotspot/share/adlc/formssel.cpp
>> ? src/hotspot/share/opto/*
>> ? src/hotspot/share/compiler/compilerDirectives.hpp
>>
>> * General GC+Runtime - Registering ZGC as a collector.
>>
>> ? src/hotspot/share/gc/shared/*
>> ? src/hotspot/share/runtime/vmStructs.cpp
>> ? src/hotspot/share/runtime/vm_operations.hpp
>> ? src/hotspot/share/prims/whitebox.cpp
>>
>> * GC thread local data - Increasing the size of data area by 32 bytes.
>>
>> ? src/hotspot/share/gc/shared/gcThreadLocalData.hpp
>>
>> * ZGC - The collector itself.
>>
>> ? src/hotspot/share/gc/z/*
>> ? src/hotspot/cpu/x86/gc/z/*
>> ? src/hotspot/os_cpu/linux_x86/gc/z/*
>> ? test/hotspot/gtest/gc/z/*
>>
>> * JFR - Adding new event types.
>>
>> ? src/hotspot/share/jfr/*
>> ? src/jdk.jfr/share/conf/jfr/*
>>
>> * Logging - Adding new log tags.
>>
>> ? src/hotspot/share/logging/*
>>
>> * Metaspace - Adding a friend declaration.
>>
>> ? src/hotspot/share/memory/metaspace.hpp
>>
>> * InstanceRefKlass - Adjustments for concurrent reference processing.
>>
>> ? src/hotspot/share/oops/instanceRefKlass.inline.hpp
>>
>> * vmSymbol - Disabled clone intrinsic for ZGC.
>>
>> ? src/hotspot/share/classfile/vmSymbols.cpp
>>
>> * Oop Verification - In four cases we disabled oop verification 
>> because it do not makes sense or is not applicable to a GC using load 
>> barriers.
>>
>> ? src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
>> ? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
>> ? src/hotspot/share/compiler/oopMap.cpp
>> ? src/hotspot/share/runtime/jniHandles.cpp
>>
>> * StackValue - Apply a load barrier in case of OSR. This is a bit of a 
>> hack. However, this will go away in the future, when we have the next 
>> iteration of C2's load barriers in place (aka "C2 late barrier 
>> insertion").
>>
>> ? src/hotspot/share/runtime/stackValue.cpp
>>
>> * JVMTI - Adding an assert() to catch problems if the tagmap hashing 
>> is changed in the future.
>>
>> ? src/hotspot/share/prims/jvmtiTagMap.cpp
>>
>> * Legal - Adding copyright/license for 3rd party hash function used in 
>> ZHash.
>>
>> ? src/java.base/share/legal/c-libutl.md
>>
>> * SA - Adding basic ZGC support.
>>
>> ? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/*
>>
>>
>> Testing
>> -------
>>
>> * Unit testing
>>
>> ? A number of new ZGC specific gtests have been added, in 
>> test/hotspot/gtest/gc/z/
>>
>> * Regression testing
>>
>> ? No new failures in Mach5, with ZGC enabled, tier{1,2,3,4,5,6}
>> ? No new failures in Mach5, with ZGC disabled, tier{1,2,3}
>>
>> * Stress testing
>>
>> ? We have been continuously been running a number stress tests 
>> throughout the development, these include:
>>
>> ??? specjbb2000
>> ??? specjbb2005
>> ??? specjbb2015
>> ??? specjvm98
>> ??? specjvm2008
>> ??? dacapo2009
>> ??? test/hotspot/jtreg/gc/stress/gcold
>> ??? test/hotspot/jtreg/gc/stress/systemgc
>> ??? test/hotspot/jtreg/gc/stress/gclocker
>> ??? test/hotspot/jtreg/gc/stress/gcbasher
>> ??? test/hotspot/jtreg/gc/stress/finalizer
>> ??? Kitchensink
>>
>>
>> Thanks!
>>
>> /Per, Stefan & the ZGC team
> 


From matthias.baesken at sap.com  Mon Jun  4 14:19:48 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 4 Jun 2018 14:19:48 +0000
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
Message-ID: <77009f7c379c4dfd817841a5d31067c2@sap.com>

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by Thomas 
- reenabled the cl warning  showing the exception issues  in   make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues  after reenabling the warnings 

Please review :

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

(cc-ing  build-dev   because of  the makefile change,  and     src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp   because of the awt change )


Thanks, Matthias



> -----Original Message-----
> From: Baesken, Matthias
> Sent: Montag, 4. Juni 2018 09:24
> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> 
> A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
> exception handling is missing. After fixing both places I can reenable
> warning 4297  in
> Awt2dLibraries.gmk      which has been  disabled before , probably because of
> the warnings generated when the exceptions where not handled .
> Should I update the change with the other file + makefile change ?
> 
> Best regards, Matthias
> 
> 
> >hg diff
> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 +0800
> +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 +0200
> @@ -213,6 +213,7 @@
>    LIBAWT_CFLAGS += -fgcse-after-reload
>  endif
> 
> 
>  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>      NAME := awt, \
>      SRC := $(LIBAWT_DIRS), \
> @@ -224,7 +225,7 @@
>          format-nonliteral parentheses, \
>      DISABLED_WARNINGS_clang := logical-op-parentheses extern-initializer, \
>      DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
> -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
> +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>      ASFLAGS := $(LIBAWT_ASFLAGS), \
>      LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN), \
>      LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
> diff -r 12fe57c319e1
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> ---
> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> pp    Tue Apr 10 11:02:09 2018 +0800
> +++
> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> pp    Mon Jun 04 09:18:03 2018 +0200
> @@ -85,7 +85,13 @@
>          *pNpoints = outpoints;
>      }
>      if (outpoints > POLYTEMPSIZE) {
> -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> sizeof(POINT), outpoints);
> +        try {
> +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> sizeof(POINT), outpoints);
> +        } catch (const std::bad_alloc&) {
> +            return NULL;
> +        }
>      }
>      BOOL isempty = fixend;
>      for (int i = 0; i < npoints; i++) {
> diff -r 12fe57c319e1
> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> --- a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> Tue Apr 10 11:02:09 2018 +0800
> +++ b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> Mon Jun 04 09:18:03 2018 +0200
> @@ -873,7 +873,12 @@
>        int numSizes = ::DeviceCapabilities(printerName, printerPort,
>                                            DC_PAPERS, NULL, NULL);
>        if (numSizes > 0) {
> -          LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> numSizes, sizeof(WORD));
> +          LPTSTR papers;
> +          try {
> +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc, numSizes,
> sizeof(WORD));
> +          } catch (const std::bad_alloc&) {
> +              papers = NULL;
> +          }
>            if (papers != NULL &&
>                ::DeviceCapabilities(printerName, printerPort,
>                                     DC_PAPERS, papers, NULL) != -1) {
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Baesken, Matthias
> > Sent: Freitag, 1. Juni 2018 14:18
> > To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > <christoph.langer at sap.com>
> > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >
> > Hi  Thomas ,  using the  const-reference  sounds like a good idea  ( I just
> > copied from  other locations in  the source code where  (almost?)  always
> > std::bad_alloc&     (non-const)  is caught .
> >
> > For example :
> >
> >
> > alloc.h 170 } catch (std::bad_alloc&) { \
> > 177 } catch (std::bad_alloc&) { \
> > 200 } catch (std::bad_alloc&) { \
> > 206 } catch (std::bad_alloc&) { \
> >
> >  awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
> > 247 } catch (std::bad_alloc&) {
> > 317 } catch (std::bad_alloc&) {
> > 372 } catch (std::bad_alloc&) {
> > 407 } catch (std::bad_alloc&) {
> >
> >  awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
> > 264 } catch (std::bad_alloc&) {
> > 305 } catch (std::bad_alloc&) {
> > 366 } catch (std::bad_alloc&) {
> > 582 } catch (std::bad_alloc&) {
> > 635 } catch (std::bad_alloc&) {
> > 653 } catch (std::bad_alloc&) {
> > 698 } catch (std::bad_alloc&) {
> > 739 } catch (std::bad_alloc&) {
> >
> >  awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
> >
> > WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
> > 345 } catch (std::bad_alloc&) {
> > 425 } catch (std::bad_alloc&) {
> > 488 } catch (std::bad_alloc&) {
> > 631 } catch (std::bad_alloc&) {
> > 709 } catch (std::bad_alloc&) {
> >
> >  awt_ole.h 158 } catch (std::bad_alloc&) {\
> >
> >  awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
> > 269 catch (std::bad_alloc&) {
> > 647 catch (std::bad_alloc&) {
> > 664 catch (std::bad_alloc&) {
> > 689 catch (std::bad_alloc&) {
> >
> >  awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
> >
> >  awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
> > 724 } catch (std::bad_alloc &) {
> > 792 } catch (std::bad_alloc &) {
> >
> >  awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
> > 348 } catch (std::bad_alloc&) {
> > 524 } catch (std::bad_alloc&) {
> >
> >  ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
> > 1435 } catch (std::bad_alloc&) {
> >
> > ...
> >
> > Best regards, Matthias
> >
> >
> > > -----Original Message-----
> > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> > > Sent: Freitag, 1. Juni 2018 12:02
> > > To: Baesken, Matthias <matthias.baesken at sap.com>
> > > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > > <christoph.langer at sap.com>
> > > Subject: Re: RFR: JDK-8204211: windows : handle potential C++ exception
> in
> > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > >
> > > Hi Matthias,
> > >
> > > Please consider catching all exceptions, not just std::alloc:
> > >
> > > } catch (...) { return NULL; }
> > >
> > > and doing it at the exit extern "C" function, not somewhere
> > > internally. Regardless of which exceptions get thrown around below you
> > > and by whom, you are safe that way.
> > >
> > > However, if you want to keep your patch as it is, please catch at
> > > least as const reference:
> > >
> > > } catch (const std::bad_alloc&) {}
> > >
> > > Fine otherwise. I do not need another webrev.
> > >
> > > Best Regards, Thomas
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
> > > <matthias.baesken at sap.com> wrote:
> > > > Hi Thomas , thanks for the feedback.
> > > > I created a bug and change for the excpetion handling in
> > GDIRenderer.cpp
> > > .
> > > > Please review .
> > > >
> > > > Thanks,  Matthias
> > > >
> > > > Bug:
> > > >
> > > > https://bugs.openjdk.java.net/browse/JDK-8204211
> > > >
> > > > JDK-8204211: windows : handle potential C++ exception in GDIRenderer
> > > >
> > > >
> > > > Change :
> > > >
> > > >
> > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
> > > >
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> > > >> Sent: Mittwoch, 30. Mai 2018 17:37
> > > >> To: Baesken, Matthias <matthias.baesken at sap.com>
> > > >> Cc: 2d-dev <2d-dev at openjdk.java.net>
> > > >> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
> > > >> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > > >>
> > > >> Letting c++ exceptions escape from extern "C" functions is UB and
> may
> > > >> (and probably will) crash the process. This should be fixed. Approach
> > > >> taken by JDK-8039394 is fine (I would probably catch every C++
> > > >> exception with catch(...), not just bad_alloc, just to be safe).
> > > >>
> > > >> Best Regards, Thomas
> > > >>
> > > >> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
> > > >> <matthias.baesken at sap.com> wrote:
> > > >> > Hello ,  there is still some  java2d coding  where
> > > SAFE_SIZE_ARRAY_ALLOC /
> > > >> > safe_Malloc    is used  and  the  (potentially occurring) exception is
> not
> > > >> > handled .
> > > >> >
> > > >> >
> > > >> >
> > > >> > This leads to  CL warnings  (when enabled  ) like
> > > >> >
> > > >> >
> > > >> >
> > > >> > " function assumed not to throw an exception but does ; The
> function
> > is
> > > >> > extern "C" and /EHc was specified"
> > > >> >
> > > >> >
> > > >> >
> > > >> > Example :
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> > > >> >
> > > >> >
> > > >> >
> > > >> > static POINT *TransformPoly()
> > > >> >
> > > >> >   ?..
> > > >> >
> > > >> >     if (outpoints > POLYTEMPSIZE) {
> > > >> >
> > > >> >         pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > >> > sizeof(POINT), outpoints);
> > > >> >
> > > >> >     }
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > Should  we add exception handling   here ?
> > > >> >
> > > >> >
> > > >> >
> > > >> > Similar fixes were done  in the change  8039394: Compiler warnings
> > > about
> > > >> C++
> > > >> > exceptions in windows printing code
> > > >> >
> > > >> >
> > > >> >
> > > >> > https://bugs.openjdk.java.net/browse/JDK-8039394
> > > >> >
> > > >> > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > Best regards, Matthias
> > > >> >
> > > >> >
> > > >> >
> > > >> >

From christoph.langer at sap.com  Mon Jun  4 14:48:59 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 4 Jun 2018 14:48:59 +0000
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <77009f7c379c4dfd817841a5d31067c2@sap.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
Message-ID: <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Montag, 4. Juni 2018 16:20
> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
> dev at openjdk.java.net
> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> 
> Hello,  I prepared a second webrev.
> 
> - use now  const-reference  in the catch-statements as suggested by Thomas
> - reenabled the cl warning  showing the exception issues  in
> make/lib/Awt2dLibraries.gmk
> - found a second place  in  WPrinterJob.cpp   with similar issues  after
> reenabling the warnings
> 
> Please review :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
> 
> (cc-ing  build-dev   because of  the makefile change,  and
> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> because of the awt change )
> 
> 
> Thanks, Matthias
> 
> 
> 
> > -----Original Message-----
> > From: Baesken, Matthias
> > Sent: Montag, 4. Juni 2018 09:24
> > To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> > Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
> > <christoph.langer at sap.com>
> > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >
> > A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
> > exception handling is missing. After fixing both places I can reenable
> > warning 4297  in
> > Awt2dLibraries.gmk      which has been  disabled before , probably because
> of
> > the warnings generated when the exceptions where not handled .
> > Should I update the change with the other file + makefile change ?
> >
> > Best regards, Matthias
> >
> >
> > >hg diff
> > diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
> > --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 +0800
> > +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 +0200
> > @@ -213,6 +213,7 @@
> >    LIBAWT_CFLAGS += -fgcse-after-reload
> >  endif
> >
> >
> >  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
> >      NAME := awt, \
> >      SRC := $(LIBAWT_DIRS), \
> > @@ -224,7 +225,7 @@
> >          format-nonliteral parentheses, \
> >      DISABLED_WARNINGS_clang := logical-op-parentheses extern-initializer,
> \
> >      DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
> > -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
> > +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
> >      ASFLAGS := $(LIBAWT_ASFLAGS), \
> >      LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN), \
> >      LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
> > diff -r 12fe57c319e1
> >
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> > ---
> >
> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> > pp    Tue Apr 10 11:02:09 2018 +0800
> > +++
> >
> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> > pp    Mon Jun 04 09:18:03 2018 +0200
> > @@ -85,7 +85,13 @@
> >          *pNpoints = outpoints;
> >      }
> >      if (outpoints > POLYTEMPSIZE) {
> > -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > sizeof(POINT), outpoints);
> > +        try {
> > +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > sizeof(POINT), outpoints);
> > +        } catch (const std::bad_alloc&) {
> > +            return NULL;
> > +        }
> >      }
> >      BOOL isempty = fixend;
> >      for (int i = 0; i < npoints; i++) {
> > diff -r 12fe57c319e1
> > src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > --- a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > Tue Apr 10 11:02:09 2018 +0800
> > +++
> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > Mon Jun 04 09:18:03 2018 +0200
> > @@ -873,7 +873,12 @@
> >        int numSizes = ::DeviceCapabilities(printerName, printerPort,
> >                                            DC_PAPERS, NULL, NULL);
> >        if (numSizes > 0) {
> > -          LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > numSizes, sizeof(WORD));
> > +          LPTSTR papers;
> > +          try {
> > +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> numSizes,
> > sizeof(WORD));
> > +          } catch (const std::bad_alloc&) {
> > +              papers = NULL;
> > +          }
> >            if (papers != NULL &&
> >                ::DeviceCapabilities(printerName, printerPort,
> >                                     DC_PAPERS, papers, NULL) != -1) {
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Baesken, Matthias
> > > Sent: Freitag, 1. Juni 2018 14:18
> > > To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> > > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > > <christoph.langer at sap.com>
> > > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception
> in
> > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > >
> > > Hi  Thomas ,  using the  const-reference  sounds like a good idea  ( I just
> > > copied from  other locations in  the source code where  (almost?)  always
> > > std::bad_alloc&     (non-const)  is caught .
> > >
> > > For example :
> > >
> > >
> > > alloc.h 170 } catch (std::bad_alloc&) { \
> > > 177 } catch (std::bad_alloc&) { \
> > > 200 } catch (std::bad_alloc&) { \
> > > 206 } catch (std::bad_alloc&) { \
> > >
> > >  awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
> > > 247 } catch (std::bad_alloc&) {
> > > 317 } catch (std::bad_alloc&) {
> > > 372 } catch (std::bad_alloc&) {
> > > 407 } catch (std::bad_alloc&) {
> > >
> > >  awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
> > > 264 } catch (std::bad_alloc&) {
> > > 305 } catch (std::bad_alloc&) {
> > > 366 } catch (std::bad_alloc&) {
> > > 582 } catch (std::bad_alloc&) {
> > > 635 } catch (std::bad_alloc&) {
> > > 653 } catch (std::bad_alloc&) {
> > > 698 } catch (std::bad_alloc&) {
> > > 739 } catch (std::bad_alloc&) {
> > >
> > >  awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
> > >
> > > WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
> > > 345 } catch (std::bad_alloc&) {
> > > 425 } catch (std::bad_alloc&) {
> > > 488 } catch (std::bad_alloc&) {
> > > 631 } catch (std::bad_alloc&) {
> > > 709 } catch (std::bad_alloc&) {
> > >
> > >  awt_ole.h 158 } catch (std::bad_alloc&) {\
> > >
> > >  awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
> > > 269 catch (std::bad_alloc&) {
> > > 647 catch (std::bad_alloc&) {
> > > 664 catch (std::bad_alloc&) {
> > > 689 catch (std::bad_alloc&) {
> > >
> > >  awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
> > >
> > >  awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
> > > 724 } catch (std::bad_alloc &) {
> > > 792 } catch (std::bad_alloc &) {
> > >
> > >  awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
> > > 348 } catch (std::bad_alloc&) {
> > > 524 } catch (std::bad_alloc&) {
> > >
> > >  ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
> > > 1435 } catch (std::bad_alloc&) {
> > >
> > > ...
> > >
> > > Best regards, Matthias
> > >
> > >
> > > > -----Original Message-----
> > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> > > > Sent: Freitag, 1. Juni 2018 12:02
> > > > To: Baesken, Matthias <matthias.baesken at sap.com>
> > > > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > > > <christoph.langer at sap.com>
> > > > Subject: Re: RFR: JDK-8204211: windows : handle potential C++
> exception
> > in
> > > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > > >
> > > > Hi Matthias,
> > > >
> > > > Please consider catching all exceptions, not just std::alloc:
> > > >
> > > > } catch (...) { return NULL; }
> > > >
> > > > and doing it at the exit extern "C" function, not somewhere
> > > > internally. Regardless of which exceptions get thrown around below
> you
> > > > and by whom, you are safe that way.
> > > >
> > > > However, if you want to keep your patch as it is, please catch at
> > > > least as const reference:
> > > >
> > > > } catch (const std::bad_alloc&) {}
> > > >
> > > > Fine otherwise. I do not need another webrev.
> > > >
> > > > Best Regards, Thomas
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
> > > > <matthias.baesken at sap.com> wrote:
> > > > > Hi Thomas , thanks for the feedback.
> > > > > I created a bug and change for the excpetion handling in
> > > GDIRenderer.cpp
> > > > .
> > > > > Please review .
> > > > >
> > > > > Thanks,  Matthias
> > > > >
> > > > > Bug:
> > > > >
> > > > > https://bugs.openjdk.java.net/browse/JDK-8204211
> > > > >
> > > > > JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer
> > > > >
> > > > >
> > > > > Change :
> > > > >
> > > > >
> > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> > > > >> Sent: Mittwoch, 30. Mai 2018 17:37
> > > > >> To: Baesken, Matthias <matthias.baesken at sap.com>
> > > > >> Cc: 2d-dev <2d-dev at openjdk.java.net>
> > > > >> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
> > > > >> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > > > >>
> > > > >> Letting c++ exceptions escape from extern "C" functions is UB and
> > may
> > > > >> (and probably will) crash the process. This should be fixed. Approach
> > > > >> taken by JDK-8039394 is fine (I would probably catch every C++
> > > > >> exception with catch(...), not just bad_alloc, just to be safe).
> > > > >>
> > > > >> Best Regards, Thomas
> > > > >>
> > > > >> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
> > > > >> <matthias.baesken at sap.com> wrote:
> > > > >> > Hello ,  there is still some  java2d coding  where
> > > > SAFE_SIZE_ARRAY_ALLOC /
> > > > >> > safe_Malloc    is used  and  the  (potentially occurring) exception is
> > not
> > > > >> > handled .
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > This leads to  CL warnings  (when enabled  ) like
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > " function assumed not to throw an exception but does ; The
> > function
> > > is
> > > > >> > extern "C" and /EHc was specified"
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Example :
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > >
> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > static POINT *TransformPoly()
> > > > >> >
> > > > >> >   ?..
> > > > >> >
> > > > >> >     if (outpoints > POLYTEMPSIZE) {
> > > > >> >
> > > > >> >         pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > > >> > sizeof(POINT), outpoints);
> > > > >> >
> > > > >> >     }
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Should  we add exception handling   here ?
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Similar fixes were done  in the change  8039394: Compiler warnings
> > > > about
> > > > >> C++
> > > > >> > exceptions in windows printing code
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > https://bugs.openjdk.java.net/browse/JDK-8039394
> > > > >> >
> > > > >> > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Best regards, Matthias
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >

From erik.joelsson at oracle.com  Mon Jun  4 15:52:15 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 4 Jun 2018 08:52:15 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
Message-ID: <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:
> 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?
I don't know. I'm open to suggestions on naming.

/Erik
> -Aleksey
>



From jesper.wilhelmsson at oracle.com  Mon Jun  4 16:54:24 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Mon, 4 Jun 2018 18:54:24 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
Message-ID: <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>

> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>> 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?
> I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper

> 
> /Erik
>> -Aleksey
>> 
> 



From erik.joelsson at oracle.com  Mon Jun  4 18:51:05 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 4 Jun 2018 11:51:05 -0700
Subject: [8] RFR (XS) 8204053 : libsaproc.so not linked with -z,noexecstack
In-Reply-To: <163c2da5-25e1-37b7-d250-7689f21963fc@oracle.com>
References: <163c2da5-25e1-37b7-d250-7689f21963fc@oracle.com>
Message-ID: <b9f7f319-b138-6311-a009-21d7e7817eec@oracle.com>

Looks ok.

/Erik


On 2018-06-02 16:17, David Buck wrote:
> Hi!
>
> Please review this very small fix. It only applies to JDK 8.
>
> bug report:
> https://bugs.openjdk.java.net/browse/JDK-8204053
>
> webrev:
> http://cr.openjdk.java.net/~dbuck/8204053.0/
>
> JPRT hotspot testset run and passed. Efficacy of fix manually confirmed.
>
> Cheers,
> -Buck



From bob.vandette at oracle.com  Mon Jun  4 19:45:45 2018
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 4 Jun 2018 15:45:45 -0400
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <a878ee8f-8d73-bf3e-b0a5-2cc4b7141a81@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
 <48DDB994-52ED-4483-A43C-AB63C578AF28@oracle.com>
 <a878ee8f-8d73-bf3e-b0a5-2cc4b7141a81@oracle.com>
Message-ID: <D566740A-0A30-4F48-B151-F223A33FFB80@oracle.com>

If we do this, shouldn?t we provide an aggregator module to allow developers to
easily create a Java runtime with the same list of modules?  AFAIK, this doesn?t exists.
The java.se <http://java.se/> module is not the same.  It?s missing many modules.

Bob.


> On Jun 2, 2018, at 1:01 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 02/06/2018 15:07, Magnus Ihse Bursie wrote:
>> It is probably relatively trivial to add a configure option to select just the "JRE modules" when building, rather than all modules. If we add such an option, it would still be possible to build a traditional JRE, not just at the same time as building the full JDK. Doing Erik's change as suggested here, combined with such additional functionality would allow us to remove a lot of old cruft from the build system, while still allowing distributors to build a JRE. I'd recommend doing something like this, rather than to delay this patch to post-JDK11.
>> 
> Removing old cruft is good. Also not building the jre image by default might reduce build times a little bit, a boon for those doing "make images" but never using the jre image (as the tests are run on the jdk image, not the jre image).
> 
> I don't have an opinion on whether configure option or a make target is the right approach. It might be that those consuming the jre image today are using the bundles target, a target that I wouldn't expect most developers will use when working on OpenJDK. Part of the socializing of this topic might be to get a better handle on what downstream projects and packagers are doing with the jre image (beyond creating install bundles for specific distros).
> 
> -Alan



From Alan.Bateman at oracle.com  Mon Jun  4 20:05:58 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 4 Jun 2018 21:05:58 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <D566740A-0A30-4F48-B151-F223A33FFB80@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
 <48DDB994-52ED-4483-A43C-AB63C578AF28@oracle.com>
 <a878ee8f-8d73-bf3e-b0a5-2cc4b7141a81@oracle.com>
 <D566740A-0A30-4F48-B151-F223A33FFB80@oracle.com>
Message-ID: <d72d66d7-712c-a779-fd9f-97a200f28286@oracle.com>

On 04/06/2018 20:45, Bob Vandette wrote:
> If we do this, shouldn?t we provide an aggregator module to allow 
> developers to
> easily create a Java runtime with the same list of modules? ?AFAIK, 
> this doesn?t exists.
> The java.se <http://java.se>?module is not the same. ?It?s missing 
> many modules.
>
That creates an attractive nuisance in that developers would end 
requiring it (with `requires) and it's not a "platform" or a module that 
someone should be depending on.? As I recall, that was part of the 
reason why the proposed "jdk.jre" aggregator was dropped during the JDK 
9 development. It may be something for the Packaging Tool (draft JEP 
JDK-8200758). I could imagine the build for the packaging tool 
generating a list of modules that the tool uses when creating packages 
for end-user applications.

-Alan


From erik.joelsson at oracle.com  Mon Jun  4 20:10:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 4 Jun 2018 13:10:09 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
Message-ID: <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".

/Erik


On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Hello,
>>
>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>> 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?
>> I don't know. I'm open to suggestions on naming.
> "hardened" sounds good to me.
>
> The change looks good as well.
> /Jesper
>
>> /Erik
>>> -Aleksey
>>>



From jonathan.gibbons at oracle.com  Mon Jun  4 20:32:58 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 04 Jun 2018 13:32:58 -0700
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
Message-ID: <5B15A1FA.8060905@oracle.com>



On 06/02/2018 12:20 AM, Alan Bateman wrote:
> On 02/06/2018 08:05, Aleksey Shipilev wrote:
>> :
>> Unfortunately, in the age of containers, distribution size matters. 
>> It makes the whole sense to ship
>> JRE in Docker containers to provide the execution environment for the 
>> upper layers. Remember, hardly
>> any application is fully modularized and/or uses jlink/jimage way of 
>> distribution.
>>
>> Also, products that ship with their own OpenJDK distribution (e.g. 
>> JetBrains IDEs) do ship with
>> jres, which cuts down their distribution sizes.
>>
>> Cost savings for having JRE only are significant, as can be observed 
>> with current bundles:
>>
>>   178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>>    38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>>
>> Therefore, I believe removing jre is too disruptive, at least for 11, 
>> at least until we see that the
>> whole jlink/jimage thing really works out in the wider Java ecosystem 
>> and JREs are really abandoned.
> I don't disagree with the significance of what has been proposed here. 
> However, just to point out that creating what used to know as the JRE 
> is one `jlink` command. There is no requirement for the application or 
> libraries using that run-time be developed as modules. Also 
> incorporate generating of JDK run-time images into the build when 
> working with containers is very useful as you get fine control on 
> which modules to include.
>
> -Alan
>

If it is that easy to generate a JRE image, why not provide a target to 
create such an image, that invokes that one command?  The target need 
not be part of the default build, but would be available for those that 
want to build it.

-- Jon


From bob.vandette at oracle.com  Mon Jun  4 20:40:06 2018
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 4 Jun 2018 16:40:06 -0400
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <5B15A1FA.8060905@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
 <5B15A1FA.8060905@oracle.com>
Message-ID: <925596CA-6A95-4A2F-BE8F-C4CC8DBA7FA3@oracle.com>


> On Jun 4, 2018, at 4:32 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> 
> 
> On 06/02/2018 12:20 AM, Alan Bateman wrote:
>> On 02/06/2018 08:05, Aleksey Shipilev wrote:
>>> :
>>> Unfortunately, in the age of containers, distribution size matters. It makes the whole sense to ship
>>> JRE in Docker containers to provide the execution environment for the upper layers. Remember, hardly
>>> any application is fully modularized and/or uses jlink/jimage way of distribution.
>>> 
>>> Also, products that ship with their own OpenJDK distribution (e.g. JetBrains IDEs) do ship with
>>> jres, which cuts down their distribution sizes.
>>> 
>>> Cost savings for having JRE only are significant, as can be observed with current bundles:
>>> 
>>>  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>>>   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>>> 
>>> Therefore, I believe removing jre is too disruptive, at least for 11, at least until we see that the
>>> whole jlink/jimage thing really works out in the wider Java ecosystem and JREs are really abandoned.
>> I don't disagree with the significance of what has been proposed here. However, just to point out that creating what used to know as the JRE is one `jlink` command. There is no requirement for the application or libraries using that run-time be developed as modules. Also incorporate generating of JDK run-time images into the build when working with containers is very useful as you get fine control on which modules to include.
>> 
>> -Alan
>> 
> 
> If it is that easy to generate a JRE image, why not provide a target to create such an image, that invokes that one command?  The target need not be part of the default build, but would be available for those that want to build it.

I could live with a jlink option to create a JRE.  The problem is that the list of modules required to produce a
compatible JRE is not documented anywhere.  I tried fishing the list out of the build makefile but it?s not trivial.  I ended
up running ?jimage list module | grep Module: on a JDK 10 JRE to get the list.

Bob.


> 
> -- Jon



From erik.joelsson at oracle.com  Mon Jun  4 21:22:41 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 4 Jun 2018 14:22:41 -0700
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
Message-ID: <3c180467-6e8b-fc2e-0c0f-6d12d7b98cc3@oracle.com>

Given the feedback, I have revised the patch to restore the ability to 
produce a legacy jre image, but it is still removed from the default 
"product-images" and "images" targets. To build it you need to specify 
it explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the 
macosx specific image layout). I still removed the bundle targets for 
the jre image as I very much doubt anyone except Oracle was using them 
anyway. In addition to this, I also updated the help text a bit to 
reflect these changes.

Will this be good enough for those that still need a JRE image?

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html

/Erik


On 2018-06-01 15:02, 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
>



From jesper.wilhelmsson at oracle.com  Tue Jun  5 00:05:11 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 5 Jun 2018 02:05:11 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
Message-ID: <111720CA-EFD3-4404-853B-C0219F2CCA18@oracle.com>

Looks good to me.
/Jesper

> On 4 Jun 2018, at 22:10, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
> 
> Renamed the new jvm variant to "hardened".
> 
> /Erik
> 
> 
> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>> 
>>> Hello,
>>> 
>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>> 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?
>>> I don't know. I'm open to suggestions on naming.
>> "hardened" sounds good to me.
>> 
>> The change looks good as well.
>> /Jesper
>> 
>>> /Erik
>>>> -Aleksey
>>>> 
> 



From david.holmes at oracle.com  Tue Jun  5 06:10:35 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Jun 2018 16:10:35 +1000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
Message-ID: <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:
> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
> 
> Renamed the new jvm variant to "hardened".

As it is a hardened server build I'd prefer if that were somehow 
reflected in the name. Though really I don't see why this should be 
restricted this way ... to be honest I don't see hardened as a variant 
of server vs. client vs. zero etc at all, you should be able to harden 
any of those.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
- only build hotspot "hardened" if requested; and in that case
   - jvm.cfg will list -server and -hardened with server as default

Is that right? I can see that we may choose to always build Oracle JDK 
this way but it isn't clear to me that its suitable for OpenJDK. Nor why 
hotspot is selectable but JDK is not. ??

Sorry.

David
-----

> /Erik
> 
> 
> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>> 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?
>>> I don't know. I'm open to suggestions on naming.
>> "hardened" sounds good to me.
>>
>> The change looks good as well.
>> /Jesper
>>
>>> /Erik
>>>> -Aleksey
>>>>
> 


From takiguc at linux.vnet.ibm.com  Tue Jun  5 06:59:01 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 05 Jun 2018 15:59:01 +0900
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <81453d0cbe05477ea558917de263ada2@sap.com>
References: <0c73caec8810b9844a463343bdaec064@linux.vnet.ibm.com>
 <ad8328a48b824282b40bf5293e7fade0@sap.com>
 <81453d0cbe05477ea558917de263ada2@sap.com>
Message-ID: <df157ca405572a36ba591d21275e2752@linux.vnet.ibm.com>

Hello Matthias and Christoph.
Thank you for your explanations.

I did not have enough knowledge about "visibility".

I created following patches.

================================
diff -r 02934b0d661b 
src/java.base/share/native/libjimage/NativeImageBuffer.cpp
--- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Wed May 
30 14:46:28 2018 +0200
+++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Tue Jun 
05 12:10:41 2018 +0900
@@ -39,7 +39,9 @@
  #include "imageFile.hpp"
  #include "inttypes.hpp"
  #include "jimage.hpp"
+#if !defined(_AIX)
  #include "osSupport.hpp"
+#endif

  #include "jdk_internal_jimage_NativeImageBuffer.h"

diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
--- a/src/java.base/unix/native/include/jni_md.h	Wed May 30 14:46:28 
2018 +0200
+++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05 12:10:41 
2018 +0900
@@ -29,7 +29,8 @@
  #ifndef __has_attribute
    #define __has_attribute(x) 0
  #endif
-#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && 
(__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
+#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && 
(__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \
+    || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
    #ifdef ARM
      #define JNIEXPORT     
__attribute__((externally_visible,visibility("default")))
      #define JNIIMPORT     
__attribute__((externally_visible,visibility("default")))
================================

If "osSupport.hpp" was included, XLC++ compiler complained.
I could not understand, which part was invalid...
I'm not sure, "osSupport.hpp" is really required on 
NativeImageBuffer.cpp or not...

I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h. [1]
0xD01 means 13.1 by hexadecimal.

I checked symbol table by "dump -Tv -X64". [2]
It seemed it was fine, some symbols were hidden.

Does someone review my code?

[1] 
https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.ibm.xlc1313.aix.doc/compiler_ref/xlmacros.html
[2] 
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html

On 2018-06-01 21:12, Baesken, Matthias wrote:
> 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 <takiguc at linux.vnet.ibm.com>
>> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
>> Goetz <goetz.lindenmaier at sap.com>
>> 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:takiguc at linux.vnet.ibm.com]
>> > Sent: Donnerstag, 31. Mai 2018 09:55
>> > To: Langer, Christoph <christoph.langer at sap.com>
>> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
>> > Goetz <goetz.lindenmaier at sap.com>
>> > 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 <christoph.langer at sap.com>;
>> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
>> > > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> > > 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
>> > > <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
>> > > 'build-dev at openjdk.java.net'
>> > > <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>;
>> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
>> > dev at openjdk.java.net>;
>> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
>> dev at openjdk.java.net>
>> > > Cc: Simonis, Volker
>> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
>> > > <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>;
>> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
>> > dev at openjdk.java.net>;
>> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
>> dev at openjdk.java.net>
>> > > Cc: Langer, Christoph
>> > > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
>> Simonis,
>> > > Volker <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
>> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
>> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>> > >
>> > >
>> > > So it is better to avoid  setting these flags when using xlc12.1   .
>> > > Please review :
>> > >
>> > > Bug :
>> > >
>> > > https://bugs.openjdk.java.net/browse/JDK-8202322
>> > >
>> > > Change :
>> > >
>> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
>> > >
>> > >
>> > > Best regards, Matthias



From matthias.baesken at sap.com  Tue Jun  5 07:47:21 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 5 Jun 2018 07:47:21 +0000
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
Message-ID: <a0cad0530b284cb1929a728e2e0a84b8@sap.com>

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev  reviewers ?

Best Regards, Matthias


> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 4. Juni 2018 16:49
> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
> dev at openjdk.java.net>; awt-dev at openjdk.java.net
> Cc: 2d-dev <2d-dev at openjdk.java.net>
> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> 
> Hi Matthias,
> 
> looks good to me.
> 
> Don't forget the Copyright years.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Baesken, Matthias
> > Sent: Montag, 4. Juni 2018 16:20
> > To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
> > dev at openjdk.java.net
> > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > <christoph.langer at sap.com>
> > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >
> > Hello,  I prepared a second webrev.
> >
> > - use now  const-reference  in the catch-statements as suggested by
> Thomas
> > - reenabled the cl warning  showing the exception issues  in
> > make/lib/Awt2dLibraries.gmk
> > - found a second place  in  WPrinterJob.cpp   with similar issues  after
> > reenabling the warnings
> >
> > Please review :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
> >
> > (cc-ing  build-dev   because of  the makefile change,  and
> > src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > because of the awt change )
> >
> >
> > Thanks, Matthias
> >
> >
> >
> > > -----Original Message-----
> > > From: Baesken, Matthias
> > > Sent: Montag, 4. Juni 2018 09:24
> > > To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> > > Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
> > > <christoph.langer at sap.com>
> > > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception
> in
> > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > >
> > > A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
> > > exception handling is missing. After fixing both places I can reenable
> > > warning 4297  in
> > > Awt2dLibraries.gmk      which has been  disabled before , probably
> because
> > of
> > > the warnings generated when the exceptions where not handled .
> > > Should I update the change with the other file + makefile change ?
> > >
> > > Best regards, Matthias
> > >
> > >
> > > >hg diff
> > > diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
> > > --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 +0800
> > > +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 +0200
> > > @@ -213,6 +213,7 @@
> > >    LIBAWT_CFLAGS += -fgcse-after-reload
> > >  endif
> > >
> > >
> > >  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
> > >      NAME := awt, \
> > >      SRC := $(LIBAWT_DIRS), \
> > > @@ -224,7 +225,7 @@
> > >          format-nonliteral parentheses, \
> > >      DISABLED_WARNINGS_clang := logical-op-parentheses extern-
> initializer,
> > \
> > >      DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
> > > -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
> > > +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
> > >      ASFLAGS := $(LIBAWT_ASFLAGS), \
> > >      LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
> \
> > >      LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
> > > diff -r 12fe57c319e1
> > >
> >
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> > > ---
> > >
> >
> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> > > pp    Tue Apr 10 11:02:09 2018 +0800
> > > +++
> > >
> >
> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> > > pp    Mon Jun 04 09:18:03 2018 +0200
> > > @@ -85,7 +85,13 @@
> > >          *pNpoints = outpoints;
> > >      }
> > >      if (outpoints > POLYTEMPSIZE) {
> > > -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > sizeof(POINT), outpoints);
> > > +        try {
> > > +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > sizeof(POINT), outpoints);
> > > +        } catch (const std::bad_alloc&) {
> > > +            return NULL;
> > > +        }
> > >      }
> > >      BOOL isempty = fixend;
> > >      for (int i = 0; i < npoints; i++) {
> > > diff -r 12fe57c319e1
> > > src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > > ---
> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > > Tue Apr 10 11:02:09 2018 +0800
> > > +++
> > b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > > Mon Jun 04 09:18:03 2018 +0200
> > > @@ -873,7 +873,12 @@
> > >        int numSizes = ::DeviceCapabilities(printerName, printerPort,
> > >                                            DC_PAPERS, NULL, NULL);
> > >        if (numSizes > 0) {
> > > -          LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > numSizes, sizeof(WORD));
> > > +          LPTSTR papers;
> > > +          try {
> > > +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > numSizes,
> > > sizeof(WORD));
> > > +          } catch (const std::bad_alloc&) {
> > > +              papers = NULL;
> > > +          }
> > >            if (papers != NULL &&
> > >                ::DeviceCapabilities(printerName, printerPort,
> > >                                     DC_PAPERS, papers, NULL) != -1) {
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Baesken, Matthias
> > > > Sent: Freitag, 1. Juni 2018 14:18
> > > > To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> > > > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > > > <christoph.langer at sap.com>
> > > > Subject: RE: RFR: JDK-8204211: windows : handle potential C++
> exception
> > in
> > > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > > >
> > > > Hi  Thomas ,  using the  const-reference  sounds like a good idea  ( I just
> > > > copied from  other locations in  the source code where  (almost?)
> always
> > > > std::bad_alloc&     (non-const)  is caught .
> > > >
> > > > For example :
> > > >
> > > >
> > > > alloc.h 170 } catch (std::bad_alloc&) { \
> > > > 177 } catch (std::bad_alloc&) { \
> > > > 200 } catch (std::bad_alloc&) { \
> > > > 206 } catch (std::bad_alloc&) { \
> > > >
> > > >  awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
> > > > 247 } catch (std::bad_alloc&) {
> > > > 317 } catch (std::bad_alloc&) {
> > > > 372 } catch (std::bad_alloc&) {
> > > > 407 } catch (std::bad_alloc&) {
> > > >
> > > >  awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
> > > > 264 } catch (std::bad_alloc&) {
> > > > 305 } catch (std::bad_alloc&) {
> > > > 366 } catch (std::bad_alloc&) {
> > > > 582 } catch (std::bad_alloc&) {
> > > > 635 } catch (std::bad_alloc&) {
> > > > 653 } catch (std::bad_alloc&) {
> > > > 698 } catch (std::bad_alloc&) {
> > > > 739 } catch (std::bad_alloc&) {
> > > >
> > > >  awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
> > > >
> > > > WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
> > > > 345 } catch (std::bad_alloc&) {
> > > > 425 } catch (std::bad_alloc&) {
> > > > 488 } catch (std::bad_alloc&) {
> > > > 631 } catch (std::bad_alloc&) {
> > > > 709 } catch (std::bad_alloc&) {
> > > >
> > > >  awt_ole.h 158 } catch (std::bad_alloc&) {\
> > > >
> > > >  awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
> > > > 269 catch (std::bad_alloc&) {
> > > > 647 catch (std::bad_alloc&) {
> > > > 664 catch (std::bad_alloc&) {
> > > > 689 catch (std::bad_alloc&) {
> > > >
> > > >  awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
> > > >
> > > >  awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
> > > > 724 } catch (std::bad_alloc &) {
> > > > 792 } catch (std::bad_alloc &) {
> > > >
> > > >  awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
> > > > 348 } catch (std::bad_alloc&) {
> > > > 524 } catch (std::bad_alloc&) {
> > > >
> > > >  ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
> > > > 1435 } catch (std::bad_alloc&) {
> > > >
> > > > ...
> > > >
> > > > Best regards, Matthias
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> > > > > Sent: Freitag, 1. Juni 2018 12:02
> > > > > To: Baesken, Matthias <matthias.baesken at sap.com>
> > > > > Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> > > > > <christoph.langer at sap.com>
> > > > > Subject: Re: RFR: JDK-8204211: windows : handle potential C++
> > exception
> > > in
> > > > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > > > >
> > > > > Hi Matthias,
> > > > >
> > > > > Please consider catching all exceptions, not just std::alloc:
> > > > >
> > > > > } catch (...) { return NULL; }
> > > > >
> > > > > and doing it at the exit extern "C" function, not somewhere
> > > > > internally. Regardless of which exceptions get thrown around below
> > you
> > > > > and by whom, you are safe that way.
> > > > >
> > > > > However, if you want to keep your patch as it is, please catch at
> > > > > least as const reference:
> > > > >
> > > > > } catch (const std::bad_alloc&) {}
> > > > >
> > > > > Fine otherwise. I do not need another webrev.
> > > > >
> > > > > Best Regards, Thomas
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
> > > > > <matthias.baesken at sap.com> wrote:
> > > > > > Hi Thomas , thanks for the feedback.
> > > > > > I created a bug and change for the excpetion handling in
> > > > GDIRenderer.cpp
> > > > > .
> > > > > > Please review .
> > > > > >
> > > > > > Thanks,  Matthias
> > > > > >
> > > > > > Bug:
> > > > > >
> > > > > > https://bugs.openjdk.java.net/browse/JDK-8204211
> > > > > >
> > > > > > JDK-8204211: windows : handle potential C++ exception in
> > GDIRenderer
> > > > > >
> > > > > >
> > > > > > Change :
> > > > > >
> > > > > >
> > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> > > > > >> Sent: Mittwoch, 30. Mai 2018 17:37
> > > > > >> To: Baesken, Matthias <matthias.baesken at sap.com>
> > > > > >> Cc: 2d-dev <2d-dev at openjdk.java.net>
> > > > > >> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
> > > > > >> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > > > > >>
> > > > > >> Letting c++ exceptions escape from extern "C" functions is UB and
> > > may
> > > > > >> (and probably will) crash the process. This should be fixed.
> Approach
> > > > > >> taken by JDK-8039394 is fine (I would probably catch every C++
> > > > > >> exception with catch(...), not just bad_alloc, just to be safe).
> > > > > >>
> > > > > >> Best Regards, Thomas
> > > > > >>
> > > > > >> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
> > > > > >> <matthias.baesken at sap.com> wrote:
> > > > > >> > Hello ,  there is still some  java2d coding  where
> > > > > SAFE_SIZE_ARRAY_ALLOC /
> > > > > >> > safe_Malloc    is used  and  the  (potentially occurring) exception
> is
> > > not
> > > > > >> > handled .
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > This leads to  CL warnings  (when enabled  ) like
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > " function assumed not to throw an exception but does ; The
> > > function
> > > > is
> > > > > >> > extern "C" and /EHc was specified"
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > Example :
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > >
> > java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > static POINT *TransformPoly()
> > > > > >> >
> > > > > >> >   ?..
> > > > > >> >
> > > > > >> >     if (outpoints > POLYTEMPSIZE) {
> > > > > >> >
> > > > > >> >         pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > > > >> > sizeof(POINT), outpoints);
> > > > > >> >
> > > > > >> >     }
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > Should  we add exception handling   here ?
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > Similar fixes were done  in the change  8039394: Compiler
> warnings
> > > > > about
> > > > > >> C++
> > > > > >> > exceptions in windows printing code
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > https://bugs.openjdk.java.net/browse/JDK-8039394
> > > > > >> >
> > > > > >> > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > Best regards, Matthias
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >

From matthias.baesken at sap.com  Tue Jun  5 08:30:07 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 5 Jun 2018 08:30:07 +0000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
Message-ID: <3f7c0b36458a467b85c41ed467b41614@sap.com>

Hi Erik , is there  some info available about  the performance impact when  disabling  disabling speculative execution  ?



And which compiler versions are needed for this ?



Best regards, Matthias





>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





From Alan.Bateman at oracle.com  Tue Jun  5 08:38:48 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Jun 2018 09:38:48 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <925596CA-6A95-4A2F-BE8F-C4CC8DBA7FA3@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <163789D2-5AF7-42F6-83E2-BDE41F320D7F@oracle.com>
 <01950f33-943a-9f31-2d4d-4dcf58b7afd3@redhat.com>
 <e87c0905-b6f6-ced2-da40-ae16962b8697@oracle.com>
 <5B15A1FA.8060905@oracle.com>
 <925596CA-6A95-4A2F-BE8F-C4CC8DBA7FA3@oracle.com>
Message-ID: <3ecf874a-680e-bbc3-fcae-c5b3ed70afe6@oracle.com>

On 04/06/2018 21:40, Bob Vandette wrote:
> :
> I could live with a jlink option to create a JRE.  The problem is that the list of modules required to produce a
> compatible JRE is not documented anywhere.  I tried fishing the list out of the build makefile but it?s not trivial.  I ended
> up running ?jimage list module | grep Module: on a JDK 10 JRE to get the list.
>
The `release` file in the top-level directory has a `MODULES` key with 
the complete list. Alternatively, `java --list-modules`.

In addition, there are other options used and it might that we should 
have the build invoke `jlink` with `--save-opts` so that the options are 
saved. Part of the original motive for `--save-opts` was to support a 
way to "relink" to re-run the link with the same options but pick up 
newer versions of the modules.

-Alan




From Alan.Bateman at oracle.com  Tue Jun  5 08:41:46 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Jun 2018 09:41:46 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <3c180467-6e8b-fc2e-0c0f-6d12d7b98cc3@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <3c180467-6e8b-fc2e-0c0f-6d12d7b98cc3@oracle.com>
Message-ID: <e8ddf8ab-101f-dc90-9440-ea6fbe7a9080@oracle.com>

On 04/06/2018 22:22, Erik Joelsson wrote:
> Given the feedback, I have revised the patch to restore the ability to 
> produce a legacy jre image, but it is still removed from the default 
> "product-images" and "images" targets. To build it you need to specify 
> it explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the 
> macosx specific image layout). I still removed the bundle targets for 
> the jre image as I very much doubt anyone except Oracle was using them 
> anyway. In addition to this, I also updated the help text a bit to 
> reflect these changes.
>
> Will this be good enough for those that still need a JRE image?
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
This looks okay to me, and seems better than the configure option 
mentioned in one of the mails.

I think you will still need to do some communication about this change, 
maybe to jdk-dev so that folks that may be relying on the jre image know 
that they need to build the legacy-jre-image target.

I suspect this area of the build will be re-visited again if the Java 
Packager JEP goes ahead as that will need a similar list of modules and 
maybe options.

-Alan.


From martijnverburg at gmail.com  Tue Jun  5 09:08:12 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 5 Jun 2018 10:08:12 +0100
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <e8ddf8ab-101f-dc90-9440-ea6fbe7a9080@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <3c180467-6e8b-fc2e-0c0f-6d12d7b98cc3@oracle.com>
 <e8ddf8ab-101f-dc90-9440-ea6fbe7a9080@oracle.com>
Message-ID: <CAP7YuAS4qDUTNrrHD8VDVoFcou75r66TiJ4Uz5FMW6gvEdh84Q@mail.gmail.com>

Thanks Erik,

We do have quite a few requests to build that jRE for AdoptOpenJDK
binaries, and this should let us continue doing that.

Cheers,
Martijn

On 5 June 2018 at 09:41, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 04/06/2018 22:22, Erik Joelsson wrote:
>
>> Given the feedback, I have revised the patch to restore the ability to
>> produce a legacy jre image, but it is still removed from the default
>> "product-images" and "images" targets. To build it you need to specify it
>> explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx
>> specific image layout). I still removed the bundle targets for the jre
>> image as I very much doubt anyone except Oracle was using them anyway. In
>> addition to this, I also updated the help text a bit to reflect these
>> changes.
>>
>> Will this be good enough for those that still need a JRE image?
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
>>
> This looks okay to me, and seems better than the configure option
> mentioned in one of the mails.
>
> I think you will still need to do some communication about this change,
> maybe to jdk-dev so that folks that may be relying on the jre image know
> that they need to build the legacy-jre-image target.
>
> I suspect this area of the build will be re-visited again if the Java
> Packager JEP goes ahead as that will need a similar list of modules and
> maybe options.
>
> -Alan.
>


From magnus.ihse.bursie at oracle.com  Tue Jun  5 09:09:21 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Jun 2018 11:09:21 +0200
Subject: RFR: JDK-8200132: Remove jre images and bundles
In-Reply-To: <3c180467-6e8b-fc2e-0c0f-6d12d7b98cc3@oracle.com>
References: <d3a09ce5-524d-e1e0-1461-adbddbf65270@oracle.com>
 <3c180467-6e8b-fc2e-0c0f-6d12d7b98cc3@oracle.com>
Message-ID: <7665CB84-2828-4C7A-8B53-3C32840B9BA7@oracle.com>

Build change itself looks good to me. I think this solves the problem for the time being, even if the cleanup is not as complete. 

For JDK 12, we should see if we can go further. 

/Magnus

> 4 juni 2018 kl. 23:22 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Given the feedback, I have revised the patch to restore the ability to produce a legacy jre image, but it is still removed from the default "product-images" and "images" targets. To build it you need to specify it explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx specific image layout). I still removed the bundle targets for the jre image as I very much doubt anyone except Oracle was using them anyway. In addition to this, I also updated the help text a bit to reflect these changes.
> 
> Will this be good enough for those that still need a JRE image?
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
> 
> /Erik
> 
> 
>> On 2018-06-01 15:02, 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
> 



From david.holmes at oracle.com  Tue Jun  5 12:20:45 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Jun 2018 22:20:45 +1000
Subject: [8] RFR (XS) 8204053 : libsaproc.so not linked with -z,noexecstack
In-Reply-To: <163c2da5-25e1-37b7-d250-7689f21963fc@oracle.com>
References: <163c2da5-25e1-37b7-d250-7689f21963fc@oracle.com>
Message-ID: <03ec00a7-2449-3db7-1b90-b288293eae9c@oracle.com>

Looks fine to me.

Thanks,
David

> Hi!
> 
> Please review this very small fix. It only applies to JDK 8.
> 
> bug report:
> https://bugs.openjdk.java.net/browse/JDK-8204053
> 
> webrev:
> http://cr.openjdk.java.net/~dbuck/8204053.0/
> 
> JPRT hotspot testset run and passed. Efficacy of fix manually confirmed.
> 
> Cheers,
> -Buck



From erik.joelsson at oracle.com  Tue Jun  5 15:47:12 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Jun 2018 08:47:12 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
Message-ID: <03efde10-d6a7-962d-54d5-339565d1d133@oracle.com>

Hello,

On 2018-06-04 23:10, David Holmes wrote:
> Sorry to be late to this party ...
>
> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>
>> Renamed the new jvm variant to "hardened".
>
> As it is a hardened server build I'd prefer if that were somehow 
> reflected in the name. Though really I don't see why this should be 
> restricted this way ... to be honest I don't see hardened as a variant 
> of server vs. client vs. zero etc at all, you should be able to harden 
> any of those.
>
I agree, and you sort of can. By adding the jvm feature 
"no-speculative-cti" to any jvm variant, you get the flags. The name of 
the predefined variant can be discussed. I initially suggested altserver 
because I, as you, thought it should include server in the name. But 
ultimately, I don't care that much about a name. There is also little 
point in defining a whole set of predefined variants that nobody has 
requested. If we ever need more specialized variants in the same image, 
we will add them.
> So IIUC with this change we will:
> - always build JDK native code "hardened" (if toolchain supports it)
Yes, this is correct. The reason being that no significant performance 
impact was detected, so there is no cost.
> - only build hotspot "hardened" if requested; and in that case
> ? - jvm.cfg will list -server and -hardened with server as default
Correct.
>
> Is that right? I can see that we may choose to always build Oracle JDK 
> this way but it isn't clear to me that its suitable for OpenJDK. Nor 
> why hotspot is selectable but JDK is not. ??
>
We would prefer to always build with security features enabled, but the 
performance impact on the JVM is so high that we want to leave it to the 
user to decide, both at bulid time and at runtime. With these changes, 
Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but 
any other person or entity just building the OpenJDK source will just 
get the server variant for now (as has been the default for a long 
time), unless they specifically ask for "hardened" or activate the new 
jvm feature (--with-jvm-feature=no-speculative-cti).

We don't see the point in giving the choice on the JDK libraries simply 
because there is no drawback to enabling the flags.

/Erik
> Sorry.
>
> David
> -----
>
>> /Erik
>>
>>
>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> 
>>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>> 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?
>>>> I don't know. I'm open to suggestions on naming.
>>> "hardened" sounds good to me.
>>>
>>> The change looks good as well.
>>> /Jesper
>>>
>>>> /Erik
>>>>> -Aleksey
>>>>>
>>



From erik.joelsson at oracle.com  Tue Jun  5 15:50:37 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Jun 2018 08:50:37 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
In-Reply-To: <3f7c0b36458a467b85c41ed467b41614@sap.com>
References: <3f7c0b36458a467b85c41ed467b41614@sap.com>
Message-ID: <f198098a-4c7f-da88-5824-444eeeee86d7@oracle.com>

Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I 
think some minimal update version (the option is called -Qspectre), we 
use 15.5.5.

I was not involved in the benchmarking so I don't know any details 
there, only the conclusion.

/Erik


On 2018-06-05 01:30, Baesken, Matthias wrote:
>
> Hi Erik , is there ?some info available about ?the performance impact 
> when ?disabling ?disabling speculative execution? ?
>
> And which compiler versions are needed for this ?
>
> Best regards, Matthias
>
> >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 
> <http://cr.openjdk.java.net/%7Eerikj/8202384/webrev.01>
>



From erik.joelsson at oracle.com  Tue Jun  5 16:05:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Jun 2018 09:05:33 -0700
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
Message-ID: <d1d38d50-03d4-50d0-c9a1-f58d1e359959@oracle.com>

Build change looks ok, but the validity of disabling the warning needs 
review from someone else.

/Erik


On 2018-06-05 00:47, Baesken, Matthias wrote:
> Hi Christoph, thank's for the  review .
> Could I have a second one  for example from the  awt or build-dev  reviewers ?
>
> Best Regards, Matthias
>
>
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Montag, 4. Juni 2018 16:49
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>
>> Hi Matthias,
>>
>> looks good to me.
>>
>> Don't forget the Copyright years.
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: Baesken, Matthias
>>> Sent: Montag, 4. Juni 2018 16:20
>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
>>> dev at openjdk.java.net
>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>> <christoph.langer at sap.com>
>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>
>>> Hello,  I prepared a second webrev.
>>>
>>> - use now  const-reference  in the catch-statements as suggested by
>> Thomas
>>> - reenabled the cl warning  showing the exception issues  in
>>> make/lib/Awt2dLibraries.gmk
>>> - found a second place  in  WPrinterJob.cpp   with similar issues  after
>>> reenabling the warnings
>>>
>>> Please review :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
>>>
>>> (cc-ing  build-dev   because of  the makefile change,  and
>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>> because of the awt change )
>>>
>>>
>>> Thanks, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Baesken, Matthias
>>>> Sent: Montag, 4. Juni 2018 09:24
>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
>>>> <christoph.langer at sap.com>
>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception
>> in
>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>
>>>> A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
>>>> exception handling is missing. After fixing both places I can reenable
>>>> warning 4297  in
>>>> Awt2dLibraries.gmk      which has been  disabled before , probably
>> because
>>> of
>>>> the warnings generated when the exceptions where not handled .
>>>> Should I update the change with the other file + makefile change ?
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> hg diff
>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
>>>> --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 +0800
>>>> +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 +0200
>>>> @@ -213,6 +213,7 @@
>>>>     LIBAWT_CFLAGS += -fgcse-after-reload
>>>>   endif
>>>>
>>>>
>>>>   $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>>>>       NAME := awt, \
>>>>       SRC := $(LIBAWT_DIRS), \
>>>> @@ -224,7 +225,7 @@
>>>>           format-nonliteral parentheses, \
>>>>       DISABLED_WARNINGS_clang := logical-op-parentheses extern-
>> initializer,
>>> \
>>>>       DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
>>>> -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
>>>> +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>>>>       ASFLAGS := $(LIBAWT_ASFLAGS), \
>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
>> \
>>>>       LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
>>>> diff -r 12fe57c319e1
>>>>
>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>> ---
>>>>
>> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>> pp    Tue Apr 10 11:02:09 2018 +0800
>>>> +++
>>>>
>> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>> pp    Mon Jun 04 09:18:03 2018 +0200
>>>> @@ -85,7 +85,13 @@
>>>>           *pNpoints = outpoints;
>>>>       }
>>>>       if (outpoints > POLYTEMPSIZE) {
>>>> -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> sizeof(POINT), outpoints);
>>>> +        try {
>>>> +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> sizeof(POINT), outpoints);
>>>> +        } catch (const std::bad_alloc&) {
>>>> +            return NULL;
>>>> +        }
>>>>       }
>>>>       BOOL isempty = fixend;
>>>>       for (int i = 0; i < npoints; i++) {
>>>> diff -r 12fe57c319e1
>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> ---
>> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> Tue Apr 10 11:02:09 2018 +0800
>>>> +++
>>> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> Mon Jun 04 09:18:03 2018 +0200
>>>> @@ -873,7 +873,12 @@
>>>>         int numSizes = ::DeviceCapabilities(printerName, printerPort,
>>>>                                             DC_PAPERS, NULL, NULL);
>>>>         if (numSizes > 0) {
>>>> -          LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> numSizes, sizeof(WORD));
>>>> +          LPTSTR papers;
>>>> +          try {
>>>> +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>> numSizes,
>>>> sizeof(WORD));
>>>> +          } catch (const std::bad_alloc&) {
>>>> +              papers = NULL;
>>>> +          }
>>>>             if (papers != NULL &&
>>>>                 ::DeviceCapabilities(printerName, printerPort,
>>>>                                      DC_PAPERS, papers, NULL) != -1) {
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Baesken, Matthias
>>>>> Sent: Freitag, 1. Juni 2018 14:18
>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
>> exception
>>> in
>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>
>>>>> Hi  Thomas ,  using the  const-reference  sounds like a good idea  ( I just
>>>>> copied from  other locations in  the source code where  (almost?)
>> always
>>>>> std::bad_alloc&     (non-const)  is caught .
>>>>>
>>>>> For example :
>>>>>
>>>>>
>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
>>>>> 177 } catch (std::bad_alloc&) { \
>>>>> 200 } catch (std::bad_alloc&) { \
>>>>> 206 } catch (std::bad_alloc&) { \
>>>>>
>>>>>   awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
>>>>> 247 } catch (std::bad_alloc&) {
>>>>> 317 } catch (std::bad_alloc&) {
>>>>> 372 } catch (std::bad_alloc&) {
>>>>> 407 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
>>>>> 264 } catch (std::bad_alloc&) {
>>>>> 305 } catch (std::bad_alloc&) {
>>>>> 366 } catch (std::bad_alloc&) {
>>>>> 582 } catch (std::bad_alloc&) {
>>>>> 635 } catch (std::bad_alloc&) {
>>>>> 653 } catch (std::bad_alloc&) {
>>>>> 698 } catch (std::bad_alloc&) {
>>>>> 739 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
>>>>>
>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
>>>>> 345 } catch (std::bad_alloc&) {
>>>>> 425 } catch (std::bad_alloc&) {
>>>>> 488 } catch (std::bad_alloc&) {
>>>>> 631 } catch (std::bad_alloc&) {
>>>>> 709 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_ole.h 158 } catch (std::bad_alloc&) {\
>>>>>
>>>>>   awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
>>>>> 269 catch (std::bad_alloc&) {
>>>>> 647 catch (std::bad_alloc&) {
>>>>> 664 catch (std::bad_alloc&) {
>>>>> 689 catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
>>>>> 724 } catch (std::bad_alloc &) {
>>>>> 792 } catch (std::bad_alloc &) {
>>>>>
>>>>>   awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
>>>>> 348 } catch (std::bad_alloc&) {
>>>>> 524 } catch (std::bad_alloc&) {
>>>>>
>>>>>   ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
>>>>> 1435 } catch (std::bad_alloc&) {
>>>>>
>>>>> ...
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>> Sent: Freitag, 1. Juni 2018 12:02
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>> <christoph.langer at sap.com>
>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
>>> exception
>>>> in
>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> Please consider catching all exceptions, not just std::alloc:
>>>>>>
>>>>>> } catch (...) { return NULL; }
>>>>>>
>>>>>> and doing it at the exit extern "C" function, not somewhere
>>>>>> internally. Regardless of which exceptions get thrown around below
>>> you
>>>>>> and by whom, you are safe that way.
>>>>>>
>>>>>> However, if you want to keep your patch as it is, please catch at
>>>>>> least as const reference:
>>>>>>
>>>>>> } catch (const std::bad_alloc&) {}
>>>>>>
>>>>>> Fine otherwise. I do not need another webrev.
>>>>>>
>>>>>> Best Regards, Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>> Hi Thomas , thanks for the feedback.
>>>>>>> I created a bug and change for the excpetion handling in
>>>>> GDIRenderer.cpp
>>>>>> .
>>>>>>> Please review .
>>>>>>>
>>>>>>> Thanks,  Matthias
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
>>>>>>>
>>>>>>> JDK-8204211: windows : handle potential C++ exception in
>>> GDIRenderer
>>>>>>>
>>>>>>> Change :
>>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>
>>>>>>>> Letting c++ exceptions escape from extern "C" functions is UB and
>>>> may
>>>>>>>> (and probably will) crash the process. This should be fixed.
>> Approach
>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every C++
>>>>>>>> exception with catch(...), not just bad_alloc, just to be safe).
>>>>>>>>
>>>>>>>> Best Regards, Thomas
>>>>>>>>
>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>> Hello ,  there is still some  java2d coding  where
>>>>>> SAFE_SIZE_ARRAY_ALLOC /
>>>>>>>>> safe_Malloc    is used  and  the  (potentially occurring) exception
>> is
>>>> not
>>>>>>>>> handled .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This leads to  CL warnings  (when enabled  ) like
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> " function assumed not to throw an exception but does ; The
>>>> function
>>>>> is
>>>>>>>>> extern "C" and /EHc was specified"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Example :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> static POINT *TransformPoly()
>>>>>>>>>
>>>>>>>>>    ?..
>>>>>>>>>
>>>>>>>>>      if (outpoints > POLYTEMPSIZE) {
>>>>>>>>>
>>>>>>>>>          pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>>>> sizeof(POINT), outpoints);
>>>>>>>>>
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Should  we add exception handling   here ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Similar fixes were done  in the change  8039394: Compiler
>> warnings
>>>>>> about
>>>>>>>> C++
>>>>>>>>> exceptions in windows printing code
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
>>>>>>>>>
>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards, Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>



From volker.simonis at gmail.com  Tue Jun  5 16:35:44 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 5 Jun 2018 18:35:44 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <03efde10-d6a7-962d-54d5-339565d1d133@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <03efde10-d6a7-962d-54d5-339565d1d133@oracle.com>
Message-ID: <CA+3eh10PVcdHNGJOeaFKR=X5t2X99xw3pTyqZwOW3GJv=dDrcA@mail.gmail.com>

Hi Erik,

you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if not, I don't see the point in hardening the HotSpot code
itself if the VM still generates potentially "insecure" code.

And I still don't fully understand how things work if you build both
variants by default (as you intend to do it for Oracle builds). Will
you end up with two subdirectories (lib/server/ and lib/altserver)
where both contain a libjvm.so and the user can use "java -altserver"
on the command line to choose the hardened version?

Thank you and best regards,
Volker


On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello,
>
> On 2018-06-04 23:10, David Holmes wrote:
>>
>> Sorry to be late to this party ...
>>
>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>>
>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>>
>>> Renamed the new jvm variant to "hardened".
>>
>>
>> As it is a hardened server build I'd prefer if that were somehow reflected
>> in the name. Though really I don't see why this should be restricted this
>> way ... to be honest I don't see hardened as a variant of server vs. client
>> vs. zero etc at all, you should be able to harden any of those.
>>
> I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
> to any jvm variant, you get the flags. The name of the predefined variant
> can be discussed. I initially suggested altserver because I, as you, thought
> it should include server in the name. But ultimately, I don't care that much
> about a name. There is also little point in defining a whole set of
> predefined variants that nobody has requested. If we ever need more
> specialized variants in the same image, we will add them.
>>
>> So IIUC with this change we will:
>> - always build JDK native code "hardened" (if toolchain supports it)
>
> Yes, this is correct. The reason being that no significant performance
> impact was detected, so there is no cost.
>>
>> - only build hotspot "hardened" if requested; and in that case
>>   - jvm.cfg will list -server and -hardened with server as default
>
> Correct.
>>
>>
>> Is that right? I can see that we may choose to always build Oracle JDK
>> this way but it isn't clear to me that its suitable for OpenJDK. Nor why
>> hotspot is selectable but JDK is not. ??
>>
> We would prefer to always build with security features enabled, but the
> performance impact on the JVM is so high that we want to leave it to the
> user to decide, both at bulid time and at runtime. With these changes,
> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
> other person or entity just building the OpenJDK source will just get the
> server variant for now (as has been the default for a long time), unless
> they specifically ask for "hardened" or activate the new jvm feature
> (--with-jvm-feature=no-speculative-cti).
>
> We don't see the point in giving the choice on the JDK libraries simply
> because there is no drawback to enabling the flags.
>
> /Erik
>
>> Sorry.
>>
>> David
>> -----
>>
>>> /Erik
>>>
>>>
>>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>>>
>>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>>>
>>>>>> 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?
>>>>>
>>>>> I don't know. I'm open to suggestions on naming.
>>>>
>>>> "hardened" sounds good to me.
>>>>
>>>> The change looks good as well.
>>>> /Jesper
>>>>
>>>>> /Erik
>>>>>>
>>>>>> -Aleksey
>>>>>>
>>>
>


From erik.joelsson at oracle.com  Tue Jun  5 16:47:26 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Jun 2018 09:47:26 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <CA+3eh10PVcdHNGJOeaFKR=X5t2X99xw3pTyqZwOW3GJv=dDrcA@mail.gmail.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <03efde10-d6a7-962d-54d5-339565d1d133@oracle.com>
 <CA+3eh10PVcdHNGJOeaFKR=X5t2X99xw3pTyqZwOW3GJv=dDrcA@mail.gmail.com>
Message-ID: <3981fa4d-2265-4559-eabd-98ba32f27fc7@oracle.com>

Hello Volker,

On 2018-06-05 09:35, Volker Simonis wrote:
> Hi Erik,
>
> you wrote: "Note that this applies to the build time C++ flags, not
> the compiler in the JVM itself." So what about the code generated by
> the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
> code already "hardened" against speculative execution? If yes, that's
> fine, if not, I don't see the point in hardening the HotSpot code
> itself if the VM still generates potentially "insecure" code.
Correct. These are just the build changes for the build time compiler 
options. Further work will be done by Hotspot engineers.
> And I still don't fully understand how things work if you build both
> variants by default (as you intend to do it for Oracle builds). Will
> you end up with two subdirectories (lib/server/ and lib/altserver)
> where both contain a libjvm.so and the user can use "java -altserver"
> on the command line to choose the hardened version?
Correct, we use the old jvm variant mechanism, so this will work just 
like -server/-client used to work, two completely separate libjvm.so in 
separate sub directories.

/Erik
> Thank you and best regards,
> Volker
>
>
> On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Hello,
>>
>> On 2018-06-04 23:10, David Holmes wrote:
>>> Sorry to be late to this party ...
>>>
>>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>>>
>>>> Renamed the new jvm variant to "hardened".
>>>
>>> As it is a hardened server build I'd prefer if that were somehow reflected
>>> in the name. Though really I don't see why this should be restricted this
>>> way ... to be honest I don't see hardened as a variant of server vs. client
>>> vs. zero etc at all, you should be able to harden any of those.
>>>
>> I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
>> to any jvm variant, you get the flags. The name of the predefined variant
>> can be discussed. I initially suggested altserver because I, as you, thought
>> it should include server in the name. But ultimately, I don't care that much
>> about a name. There is also little point in defining a whole set of
>> predefined variants that nobody has requested. If we ever need more
>> specialized variants in the same image, we will add them.
>>> So IIUC with this change we will:
>>> - always build JDK native code "hardened" (if toolchain supports it)
>> Yes, this is correct. The reason being that no significant performance
>> impact was detected, so there is no cost.
>>> - only build hotspot "hardened" if requested; and in that case
>>>    - jvm.cfg will list -server and -hardened with server as default
>> Correct.
>>>
>>> Is that right? I can see that we may choose to always build Oracle JDK
>>> this way but it isn't clear to me that its suitable for OpenJDK. Nor why
>>> hotspot is selectable but JDK is not. ??
>>>
>> We would prefer to always build with security features enabled, but the
>> performance impact on the JVM is so high that we want to leave it to the
>> user to decide, both at bulid time and at runtime. With these changes,
>> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
>> other person or entity just building the OpenJDK source will just get the
>> server variant for now (as has been the default for a long time), unless
>> they specifically ask for "hardened" or activate the new jvm feature
>> (--with-jvm-feature=no-speculative-cti).
>>
>> We don't see the point in giving the choice on the JDK libraries simply
>> because there is no drawback to enabling the flags.
>>
>> /Erik
>>
>>> Sorry.
>>>
>>> David
>>> -----
>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>>>> 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?
>>>>>> I don't know. I'm open to suggestions on naming.
>>>>> "hardened" sounds good to me.
>>>>>
>>>>> The change looks good as well.
>>>>> /Jesper
>>>>>
>>>>>> /Erik
>>>>>>> -Aleksey
>>>>>>>



From erik.joelsson at oracle.com  Tue Jun  5 16:48:23 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Jun 2018 09:48:23 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
In-Reply-To: <f198098a-4c7f-da88-5824-444eeeee86d7@oracle.com>
References: <3f7c0b36458a467b85c41ed467b41614@sap.com>
 <f198098a-4c7f-da88-5824-444eeeee86d7@oracle.com>
Message-ID: <f9d82b99-ba6a-4e3a-d659-2d960c70086b@oracle.com>

Hello again,

Looks like Jesper updated the bug description with more info.

/Erik


On 2018-06-05 08:50, Erik Joelsson wrote:
> Hello Matthias,
>
> For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I 
> think some minimal update version (the option is called -Qspectre), we 
> use 15.5.5.
>
> I was not involved in the benchmarking so I don't know any details 
> there, only the conclusion.
>
> /Erik
>
>
> On 2018-06-05 01:30, Baesken, Matthias wrote:
>>
>> Hi Erik , is there ?some info available about ?the performance impact 
>> when ?disabling ?disabling speculative execution? ?
>>
>> And which compiler versions are needed for this ?
>>
>> Best regards, Matthias
>>
>> >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 
>> <http://cr.openjdk.java.net/%7Eerikj/8202384/webrev.01>
>>
>



From volker.simonis at gmail.com  Tue Jun  5 16:54:27 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 5 Jun 2018 18:54:27 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <3981fa4d-2265-4559-eabd-98ba32f27fc7@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <03efde10-d6a7-962d-54d5-339565d1d133@oracle.com>
 <CA+3eh10PVcdHNGJOeaFKR=X5t2X99xw3pTyqZwOW3GJv=dDrcA@mail.gmail.com>
 <3981fa4d-2265-4559-eabd-98ba32f27fc7@oracle.com>
Message-ID: <CA+3eh13kc7nZwS1vMP9NEV5oxEsuKC7Dg=FNR+hGfFM7d_fq5Q@mail.gmail.com>

On Tue, Jun 5, 2018 at 6:47 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello Volker,
>
> On 2018-06-05 09:35, Volker Simonis wrote:
>>
>> Hi Erik,
>>
>> you wrote: "Note that this applies to the build time C++ flags, not
>> the compiler in the JVM itself." So what about the code generated by
>> the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
>> code already "hardened" against speculative execution? If yes, that's
>> fine, if not, I don't see the point in hardening the HotSpot code
>> itself if the VM still generates potentially "insecure" code.
>
> Correct. These are just the build changes for the build time compiler
> options. Further work will be done by Hotspot engineers.
>>
>> And I still don't fully understand how things work if you build both
>> variants by default (as you intend to do it for Oracle builds). Will
>> you end up with two subdirectories (lib/server/ and lib/altserver)
>> where both contain a libjvm.so and the user can use "java -altserver"
>> on the command line to choose the hardened version?
>
> Correct, we use the old jvm variant mechanism, so this will work just like
> -server/-client used to work, two completely separate libjvm.so in separate
> sub directories.
>

OK. Thanks for the quick confirmation.

> /Erik
>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson <erik.joelsson at oracle.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> On 2018-06-04 23:10, David Holmes wrote:
>>>>
>>>> Sorry to be late to this party ...
>>>>
>>>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>>>>
>>>>> Renamed the new jvm variant to "hardened".
>>>>
>>>>
>>>> As it is a hardened server build I'd prefer if that were somehow
>>>> reflected
>>>> in the name. Though really I don't see why this should be restricted
>>>> this
>>>> way ... to be honest I don't see hardened as a variant of server vs.
>>>> client
>>>> vs. zero etc at all, you should be able to harden any of those.
>>>>
>>> I agree, and you sort of can. By adding the jvm feature
>>> "no-speculative-cti"
>>> to any jvm variant, you get the flags. The name of the predefined variant
>>> can be discussed. I initially suggested altserver because I, as you,
>>> thought
>>> it should include server in the name. But ultimately, I don't care that
>>> much
>>> about a name. There is also little point in defining a whole set of
>>> predefined variants that nobody has requested. If we ever need more
>>> specialized variants in the same image, we will add them.
>>>>
>>>> So IIUC with this change we will:
>>>> - always build JDK native code "hardened" (if toolchain supports it)
>>>
>>> Yes, this is correct. The reason being that no significant performance
>>> impact was detected, so there is no cost.
>>>>
>>>> - only build hotspot "hardened" if requested; and in that case
>>>>    - jvm.cfg will list -server and -hardened with server as default
>>>
>>> Correct.
>>>>
>>>>
>>>> Is that right? I can see that we may choose to always build Oracle JDK
>>>> this way but it isn't clear to me that its suitable for OpenJDK. Nor why
>>>> hotspot is selectable but JDK is not. ??
>>>>
>>> We would prefer to always build with security features enabled, but the
>>> performance impact on the JVM is so high that we want to leave it to the
>>> user to decide, both at bulid time and at runtime. With these changes,
>>> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but
>>> any
>>> other person or entity just building the OpenJDK source will just get the
>>> server variant for now (as has been the default for a long time), unless
>>> they specifically ask for "hardened" or activate the new jvm feature
>>> (--with-jvm-feature=no-speculative-cti).
>>>
>>> We don't see the point in giving the choice on the JDK libraries simply
>>> because there is no drawback to enabling the flags.
>>>
>>> /Erik
>>>
>>>> Sorry.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>>>>>
>>>>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>>>>>
>>>>>>>> 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?
>>>>>>>
>>>>>>> I don't know. I'm open to suggestions on naming.
>>>>>>
>>>>>> "hardened" sounds good to me.
>>>>>>
>>>>>> The change looks good as well.
>>>>>> /Jesper
>>>>>>
>>>>>>> /Erik
>>>>>>>>
>>>>>>>> -Aleksey
>>>>>>>>
>


From jesper.wilhelmsson at oracle.com  Tue Jun  5 16:59:20 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 5 Jun 2018 18:59:20 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
Message-ID: <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>

> On 5 Jun 2018, at 08:10, David Holmes <david.holmes at oracle.com> wrote:
> 
> Sorry to be late to this party ...
> 
> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>> Renamed the new jvm variant to "hardened".
> 
> As it is a hardened server build I'd prefer if that were somehow reflected in the name. Though really I don't see why this should be restricted this way ... to be honest I don't see hardened as a variant of server vs. client vs. zero etc at all, you should be able to harden any of those.
> 
> So IIUC with this change we will:
> - always build JDK native code "hardened" (if toolchain supports it)
> - only build hotspot "hardened" if requested; and in that case
>  - jvm.cfg will list -server and -hardened with server as default
> 
> Is that right? I can see that we may choose to always build Oracle JDK this way but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot is selectable but JDK is not. ??

Sorry for the lack of information here. There has been a lot of off-list discussions behind this change, I've added the background to the bug now.

The short version is that we see a ~25% regression in startup times if the JVM is compiled with the gcc flags to avoid speculative execution. We have not observed any performance regressions due to compiling the rest of the native libraries with these gcc flags, so there doesn't seem to be any reason to have different versions of other libraries.

/Jesper

> Sorry.
> 
> David
> -----
> 
>> /Erik
>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>> 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?
>>>> I don't know. I'm open to suggestions on naming.
>>> "hardened" sounds good to me.
>>> 
>>> The change looks good as well.
>>> /Jesper
>>> 
>>>> /Erik
>>>>> -Aleksey
>>>>> 



From philip.race at oracle.com  Tue Jun  5 19:43:36 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 5 Jun 2018 12:43:36 -0700
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
Message-ID: <30d8ab01-e3bf-6b39-d9d5-d8cd4cedb7dc@oracle.com>

This looks good to me except for what looks like in my browser like 
missing indentation in
http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows
/GDIRenderer.cpp.udiff.html

You can fix that with or without an updated webrev.

Good to clear a class of warnings.

-phil.

On 06/05/2018 12:47 AM, Baesken, Matthias wrote:
> Hi Christoph, thank's for the  review .
> Could I have a second one  for example from the  awt or build-dev  reviewers ?
>
> Best Regards, Matthias
>
>
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Montag, 4. Juni 2018 16:49
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>
>> Hi Matthias,
>>
>> looks good to me.
>>
>> Don't forget the Copyright years.
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: Baesken, Matthias
>>> Sent: Montag, 4. Juni 2018 16:20
>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
>>> dev at openjdk.java.net
>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>> <christoph.langer at sap.com>
>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>
>>> Hello,  I prepared a second webrev.
>>>
>>> - use now  const-reference  in the catch-statements as suggested by
>> Thomas
>>> - reenabled the cl warning  showing the exception issues  in
>>> make/lib/Awt2dLibraries.gmk
>>> - found a second place  in  WPrinterJob.cpp   with similar issues  after
>>> reenabling the warnings
>>>
>>> Please review :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
>>>
>>> (cc-ing  build-dev   because of  the makefile change,  and
>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>> because of the awt change )
>>>
>>>
>>> Thanks, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Baesken, Matthias
>>>> Sent: Montag, 4. Juni 2018 09:24
>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
>>>> <christoph.langer at sap.com>
>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception
>> in
>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>
>>>> A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
>>>> exception handling is missing. After fixing both places I can reenable
>>>> warning 4297  in
>>>> Awt2dLibraries.gmk      which has been  disabled before , probably
>> because
>>> of
>>>> the warnings generated when the exceptions where not handled .
>>>> Should I update the change with the other file + makefile change ?
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> hg diff
>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
>>>> --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 +0800
>>>> +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 +0200
>>>> @@ -213,6 +213,7 @@
>>>>     LIBAWT_CFLAGS += -fgcse-after-reload
>>>>   endif
>>>>
>>>>
>>>>   $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>>>>       NAME := awt, \
>>>>       SRC := $(LIBAWT_DIRS), \
>>>> @@ -224,7 +225,7 @@
>>>>           format-nonliteral parentheses, \
>>>>       DISABLED_WARNINGS_clang := logical-op-parentheses extern-
>> initializer,
>>> \
>>>>       DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
>>>> -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
>>>> +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>>>>       ASFLAGS := $(LIBAWT_ASFLAGS), \
>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
>> \
>>>>       LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
>>>> diff -r 12fe57c319e1
>>>>
>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>> ---
>>>>
>> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>> pp    Tue Apr 10 11:02:09 2018 +0800
>>>> +++
>>>>
>> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>> pp    Mon Jun 04 09:18:03 2018 +0200
>>>> @@ -85,7 +85,13 @@
>>>>           *pNpoints = outpoints;
>>>>       }
>>>>       if (outpoints > POLYTEMPSIZE) {
>>>> -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> sizeof(POINT), outpoints);
>>>> +        try {
>>>> +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> sizeof(POINT), outpoints);
>>>> +        } catch (const std::bad_alloc&) {
>>>> +            return NULL;
>>>> +        }
>>>>       }
>>>>       BOOL isempty = fixend;
>>>>       for (int i = 0; i < npoints; i++) {
>>>> diff -r 12fe57c319e1
>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> ---
>> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> Tue Apr 10 11:02:09 2018 +0800
>>>> +++
>>> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> Mon Jun 04 09:18:03 2018 +0200
>>>> @@ -873,7 +873,12 @@
>>>>         int numSizes = ::DeviceCapabilities(printerName, printerPort,
>>>>                                             DC_PAPERS, NULL, NULL);
>>>>         if (numSizes > 0) {
>>>> -          LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> numSizes, sizeof(WORD));
>>>> +          LPTSTR papers;
>>>> +          try {
>>>> +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>> numSizes,
>>>> sizeof(WORD));
>>>> +          } catch (const std::bad_alloc&) {
>>>> +              papers = NULL;
>>>> +          }
>>>>             if (papers != NULL &&
>>>>                 ::DeviceCapabilities(printerName, printerPort,
>>>>                                      DC_PAPERS, papers, NULL) != -1) {
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Baesken, Matthias
>>>>> Sent: Freitag, 1. Juni 2018 14:18
>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
>> exception
>>> in
>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>
>>>>> Hi  Thomas ,  using the  const-reference  sounds like a good idea  ( I just
>>>>> copied from  other locations in  the source code where  (almost?)
>> always
>>>>> std::bad_alloc&     (non-const)  is caught .
>>>>>
>>>>> For example :
>>>>>
>>>>>
>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
>>>>> 177 } catch (std::bad_alloc&) { \
>>>>> 200 } catch (std::bad_alloc&) { \
>>>>> 206 } catch (std::bad_alloc&) { \
>>>>>
>>>>>   awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
>>>>> 247 } catch (std::bad_alloc&) {
>>>>> 317 } catch (std::bad_alloc&) {
>>>>> 372 } catch (std::bad_alloc&) {
>>>>> 407 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
>>>>> 264 } catch (std::bad_alloc&) {
>>>>> 305 } catch (std::bad_alloc&) {
>>>>> 366 } catch (std::bad_alloc&) {
>>>>> 582 } catch (std::bad_alloc&) {
>>>>> 635 } catch (std::bad_alloc&) {
>>>>> 653 } catch (std::bad_alloc&) {
>>>>> 698 } catch (std::bad_alloc&) {
>>>>> 739 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
>>>>>
>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
>>>>> 345 } catch (std::bad_alloc&) {
>>>>> 425 } catch (std::bad_alloc&) {
>>>>> 488 } catch (std::bad_alloc&) {
>>>>> 631 } catch (std::bad_alloc&) {
>>>>> 709 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_ole.h 158 } catch (std::bad_alloc&) {\
>>>>>
>>>>>   awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
>>>>> 269 catch (std::bad_alloc&) {
>>>>> 647 catch (std::bad_alloc&) {
>>>>> 664 catch (std::bad_alloc&) {
>>>>> 689 catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
>>>>>
>>>>>   awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
>>>>> 724 } catch (std::bad_alloc &) {
>>>>> 792 } catch (std::bad_alloc &) {
>>>>>
>>>>>   awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
>>>>> 348 } catch (std::bad_alloc&) {
>>>>> 524 } catch (std::bad_alloc&) {
>>>>>
>>>>>   ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
>>>>> 1435 } catch (std::bad_alloc&) {
>>>>>
>>>>> ...
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>> Sent: Freitag, 1. Juni 2018 12:02
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>> <christoph.langer at sap.com>
>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
>>> exception
>>>> in
>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> Please consider catching all exceptions, not just std::alloc:
>>>>>>
>>>>>> } catch (...) { return NULL; }
>>>>>>
>>>>>> and doing it at the exit extern "C" function, not somewhere
>>>>>> internally. Regardless of which exceptions get thrown around below
>>> you
>>>>>> and by whom, you are safe that way.
>>>>>>
>>>>>> However, if you want to keep your patch as it is, please catch at
>>>>>> least as const reference:
>>>>>>
>>>>>> } catch (const std::bad_alloc&) {}
>>>>>>
>>>>>> Fine otherwise. I do not need another webrev.
>>>>>>
>>>>>> Best Regards, Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>> Hi Thomas , thanks for the feedback.
>>>>>>> I created a bug and change for the excpetion handling in
>>>>> GDIRenderer.cpp
>>>>>> .
>>>>>>> Please review .
>>>>>>>
>>>>>>> Thanks,  Matthias
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
>>>>>>>
>>>>>>> JDK-8204211: windows : handle potential C++ exception in
>>> GDIRenderer
>>>>>>>
>>>>>>> Change :
>>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>
>>>>>>>> Letting c++ exceptions escape from extern "C" functions is UB and
>>>> may
>>>>>>>> (and probably will) crash the process. This should be fixed.
>> Approach
>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every C++
>>>>>>>> exception with catch(...), not just bad_alloc, just to be safe).
>>>>>>>>
>>>>>>>> Best Regards, Thomas
>>>>>>>>
>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>> Hello ,  there is still some  java2d coding  where
>>>>>> SAFE_SIZE_ARRAY_ALLOC /
>>>>>>>>> safe_Malloc    is used  and  the  (potentially occurring) exception
>> is
>>>> not
>>>>>>>>> handled .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This leads to  CL warnings  (when enabled  ) like
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> " function assumed not to throw an exception but does ; The
>>>> function
>>>>> is
>>>>>>>>> extern "C" and /EHc was specified"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Example :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> static POINT *TransformPoly()
>>>>>>>>>
>>>>>>>>>    ?..
>>>>>>>>>
>>>>>>>>>      if (outpoints > POLYTEMPSIZE) {
>>>>>>>>>
>>>>>>>>>          pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>>>> sizeof(POINT), outpoints);
>>>>>>>>>
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Should  we add exception handling   here ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Similar fixes were done  in the change  8039394: Compiler
>> warnings
>>>>>> about
>>>>>>>> C++
>>>>>>>>> exceptions in windows printing code
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
>>>>>>>>>
>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards, Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>



From philip.race at oracle.com  Tue Jun  5 19:45:50 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 5 Jun 2018 12:45:50 -0700
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <30d8ab01-e3bf-6b39-d9d5-d8cd4cedb7dc@oracle.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
 <30d8ab01-e3bf-6b39-d9d5-d8cd4cedb7dc@oracle.com>
Message-ID: <445929ef-400d-586b-bc4d-3692598b0329@oracle.com>

Oh .. can I please ask that you make sure that VS2017 is OK with the 
re-enabled
warning ? I seriously doubt that it has anything new to add over VS2013, 
but a jdk-submit
will tell you if it has ..

VS2017 is now the default so a jdk-submit will use that.

-phil.

On 06/05/2018 12:43 PM, Phil Race wrote:
> This looks good to me except for what looks like in my browser like 
> missing indentation in
> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows 
>
> /GDIRenderer.cpp.udiff.html
>
> You can fix that with or without an updated webrev.
>
> Good to clear a class of warnings.
>
> -phil.
>
> On 06/05/2018 12:47 AM, Baesken, Matthias wrote:
>> Hi Christoph, thank's for the  review .
>> Could I have a second one  for example from the  awt or build-dev  
>> reviewers ?
>>
>> Best Regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Langer, Christoph
>>> Sent: Montag, 4. Juni 2018 16:49
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
>>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
>>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>> exception in
>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>
>>> Hi Matthias,
>>>
>>> looks good to me.
>>>
>>> Don't forget the Copyright years.
>>>
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: Baesken, Matthias
>>>> Sent: Montag, 4. Juni 2018 16:20
>>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
>>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
>>>> dev at openjdk.java.net
>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>> <christoph.langer at sap.com>
>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>> exception in
>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>
>>>> Hello,  I prepared a second webrev.
>>>>
>>>> - use now  const-reference  in the catch-statements as suggested by
>>> Thomas
>>>> - reenabled the cl warning  showing the exception issues  in
>>>> make/lib/Awt2dLibraries.gmk
>>>> - found a second place  in  WPrinterJob.cpp   with similar issues  
>>>> after
>>>> reenabling the warnings
>>>>
>>>> Please review :
>>>>
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
>>>>
>>>> (cc-ing  build-dev   because of  the makefile change,  and
>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> because of the awt change )
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Baesken, Matthias
>>>>> Sent: Montag, 4. Juni 2018 09:24
>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>> exception
>>> in
>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>
>>>>> A small update  -  I found a second  place  in WPrinterJob.cpp   
>>>>> where  the
>>>>> exception handling is missing. After fixing both places I can 
>>>>> reenable
>>>>> warning 4297  in
>>>>> Awt2dLibraries.gmk      which has been  disabled before , probably
>>> because
>>>> of
>>>>> the warnings generated when the exceptions where not handled .
>>>>> Should I update the change with the other file + makefile change ?
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>> hg diff
>>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
>>>>> --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 +0800
>>>>> +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 +0200
>>>>> @@ -213,6 +213,7 @@
>>>>>     LIBAWT_CFLAGS += -fgcse-after-reload
>>>>>   endif
>>>>>
>>>>>
>>>>>   $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>>>>>       NAME := awt, \
>>>>>       SRC := $(LIBAWT_DIRS), \
>>>>> @@ -224,7 +225,7 @@
>>>>>           format-nonliteral parentheses, \
>>>>>       DISABLED_WARNINGS_clang := logical-op-parentheses extern-
>>> initializer,
>>>> \
>>>>>       DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
>>>>> -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
>>>>> +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>>>>>       ASFLAGS := $(LIBAWT_ASFLAGS), \
>>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
>>> \
>>>>>       LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
>>>>> diff -r 12fe57c319e1
>>>>>
>>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>> ---
>>>>>
>>> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>> pp    Tue Apr 10 11:02:09 2018 +0800
>>>>> +++
>>>>>
>>> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>> pp    Mon Jun 04 09:18:03 2018 +0200
>>>>> @@ -85,7 +85,13 @@
>>>>>           *pNpoints = outpoints;
>>>>>       }
>>>>>       if (outpoints > POLYTEMPSIZE) {
>>>>> -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> sizeof(POINT), outpoints);
>>>>> +        try {
>>>>> +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> sizeof(POINT), outpoints);
>>>>> +        } catch (const std::bad_alloc&) {
>>>>> +            return NULL;
>>>>> +        }
>>>>>       }
>>>>>       BOOL isempty = fixend;
>>>>>       for (int i = 0; i < npoints; i++) {
>>>>> diff -r 12fe57c319e1
>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> ---
>>> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> Tue Apr 10 11:02:09 2018 +0800
>>>>> +++
>>>> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> Mon Jun 04 09:18:03 2018 +0200
>>>>> @@ -873,7 +873,12 @@
>>>>>         int numSizes = ::DeviceCapabilities(printerName, printerPort,
>>>>>                                             DC_PAPERS, NULL, NULL);
>>>>>         if (numSizes > 0) {
>>>>> -          LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> numSizes, sizeof(WORD));
>>>>> +          LPTSTR papers;
>>>>> +          try {
>>>>> +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> numSizes,
>>>>> sizeof(WORD));
>>>>> +          } catch (const std::bad_alloc&) {
>>>>> +              papers = NULL;
>>>>> +          }
>>>>>             if (papers != NULL &&
>>>>>                 ::DeviceCapabilities(printerName, printerPort,
>>>>>                                      DC_PAPERS, papers, NULL) != 
>>>>> -1) {
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Baesken, Matthias
>>>>>> Sent: Freitag, 1. Juni 2018 14:18
>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>> <christoph.langer at sap.com>
>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
>>> exception
>>>> in
>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>
>>>>>> Hi  Thomas ,  using the  const-reference  sounds like a good 
>>>>>> idea  ( I just
>>>>>> copied from  other locations in  the source code where (almost?)
>>> always
>>>>>> std::bad_alloc& (non-const)  is caught .
>>>>>>
>>>>>> For example :
>>>>>>
>>>>>>
>>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
>>>>>> 177 } catch (std::bad_alloc&) { \
>>>>>> 200 } catch (std::bad_alloc&) { \
>>>>>> 206 } catch (std::bad_alloc&) { \
>>>>>>
>>>>>>   awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
>>>>>> 247 } catch (std::bad_alloc&) {
>>>>>> 317 } catch (std::bad_alloc&) {
>>>>>> 372 } catch (std::bad_alloc&) {
>>>>>> 407 } catch (std::bad_alloc&) {
>>>>>>
>>>>>>   awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
>>>>>> 264 } catch (std::bad_alloc&) {
>>>>>> 305 } catch (std::bad_alloc&) {
>>>>>> 366 } catch (std::bad_alloc&) {
>>>>>> 582 } catch (std::bad_alloc&) {
>>>>>> 635 } catch (std::bad_alloc&) {
>>>>>> 653 } catch (std::bad_alloc&) {
>>>>>> 698 } catch (std::bad_alloc&) {
>>>>>> 739 } catch (std::bad_alloc&) {
>>>>>>
>>>>>>   awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
>>>>>> 345 } catch (std::bad_alloc&) {
>>>>>> 425 } catch (std::bad_alloc&) {
>>>>>> 488 } catch (std::bad_alloc&) {
>>>>>> 631 } catch (std::bad_alloc&) {
>>>>>> 709 } catch (std::bad_alloc&) {
>>>>>>
>>>>>>   awt_ole.h 158 } catch (std::bad_alloc&) {\
>>>>>>
>>>>>>   awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
>>>>>> 269 catch (std::bad_alloc&) {
>>>>>> 647 catch (std::bad_alloc&) {
>>>>>> 664 catch (std::bad_alloc&) {
>>>>>> 689 catch (std::bad_alloc&) {
>>>>>>
>>>>>>   awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
>>>>>>
>>>>>>   awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
>>>>>> 724 } catch (std::bad_alloc &) {
>>>>>> 792 } catch (std::bad_alloc &) {
>>>>>>
>>>>>>   awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
>>>>>> 348 } catch (std::bad_alloc&) {
>>>>>> 524 } catch (std::bad_alloc&) {
>>>>>>
>>>>>>   ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
>>>>>> 1435 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>> Sent: Freitag, 1. Juni 2018 12:02
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>> <christoph.langer at sap.com>
>>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
>>>> exception
>>>>> in
>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> Please consider catching all exceptions, not just std::alloc:
>>>>>>>
>>>>>>> } catch (...) { return NULL; }
>>>>>>>
>>>>>>> and doing it at the exit extern "C" function, not somewhere
>>>>>>> internally. Regardless of which exceptions get thrown around below
>>>> you
>>>>>>> and by whom, you are safe that way.
>>>>>>>
>>>>>>> However, if you want to keep your patch as it is, please catch at
>>>>>>> least as const reference:
>>>>>>>
>>>>>>> } catch (const std::bad_alloc&) {}
>>>>>>>
>>>>>>> Fine otherwise. I do not need another webrev.
>>>>>>>
>>>>>>> Best Regards, Thomas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>> Hi Thomas , thanks for the feedback.
>>>>>>>> I created a bug and change for the excpetion handling in
>>>>>> GDIRenderer.cpp
>>>>>>> .
>>>>>>>> Please review .
>>>>>>>>
>>>>>>>> Thanks,  Matthias
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
>>>>>>>>
>>>>>>>> JDK-8204211: windows : handle potential C++ exception in
>>>> GDIRenderer
>>>>>>>>
>>>>>>>> Change :
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>>
>>>>>>>>> Letting c++ exceptions escape from extern "C" functions is UB and
>>>>> may
>>>>>>>>> (and probably will) crash the process. This should be fixed.
>>> Approach
>>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every C++
>>>>>>>>> exception with catch(...), not just bad_alloc, just to be safe).
>>>>>>>>>
>>>>>>>>> Best Regards, Thomas
>>>>>>>>>
>>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
>>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>>> Hello ,  there is still some  java2d coding  where
>>>>>>> SAFE_SIZE_ARRAY_ALLOC /
>>>>>>>>>> safe_Malloc    is used and  the  (potentially occurring) 
>>>>>>>>>> exception
>>> is
>>>>> not
>>>>>>>>>> handled .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This leads to  CL warnings  (when enabled  ) like
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> " function assumed not to throw an exception but does ; The
>>>>> function
>>>>>> is
>>>>>>>>>> extern "C" and /EHc was specified"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Example :
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> static POINT *TransformPoly()
>>>>>>>>>>
>>>>>>>>>>    ?..
>>>>>>>>>>
>>>>>>>>>>      if (outpoints > POLYTEMPSIZE) {
>>>>>>>>>>
>>>>>>>>>>          pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>>>>> sizeof(POINT), outpoints);
>>>>>>>>>>
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Should  we add exception handling   here ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Similar fixes were done  in the change  8039394: Compiler
>>> warnings
>>>>>>> about
>>>>>>>>> C++
>>>>>>>>>> exceptions in windows printing code
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
>>>>>>>>>>
>>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards, Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>



From Sergey.Bylokhov at oracle.com  Tue Jun  5 19:56:11 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Jun 2018 12:56:11 -0700
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <d1d38d50-03d4-50d0-c9a1-f58d1e359959@oracle.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
 <d1d38d50-03d4-50d0-c9a1-f58d1e359959@oracle.com>
Message-ID: <9aaa4b1e-4d6b-3f1a-128c-fd721e76fb56@oracle.com>

Looks fine.

On 05/06/2018 09:05, Erik Joelsson wrote:
> Build change looks ok, but the validity of disabling the warning needs 
> review from someone else.
> 
> /Erik
> 
> 
> On 2018-06-05 00:47, Baesken, Matthias wrote:
>> Hi Christoph, thank's for the? review .
>> Could I have a second one? for example from the? awt or build-dev  
>> reviewers ?
>>
>> Best Regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Langer, Christoph
>>> Sent: Montag, 4. Juni 2018 16:49
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
>>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
>>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>> exception in
>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>
>>> Hi Matthias,
>>>
>>> looks good to me.
>>>
>>> Don't forget the Copyright years.
>>>
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: Baesken, Matthias
>>>> Sent: Montag, 4. Juni 2018 16:20
>>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
>>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
>>>> dev at openjdk.java.net
>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>> <christoph.langer at sap.com>
>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>> exception in
>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>
>>>> Hello,? I prepared a second webrev.
>>>>
>>>> - use now? const-reference? in the catch-statements as suggested by
>>> Thomas
>>>> - reenabled the cl warning? showing the exception issues? in
>>>> make/lib/Awt2dLibraries.gmk
>>>> - found a second place? in? WPrinterJob.cpp?? with similar issues  
>>>> after
>>>> reenabling the warnings
>>>>
>>>> Please review :
>>>>
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
>>>>
>>>> (cc-ing? build-dev?? because of? the makefile change,? and
>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>> because of the awt change )
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Baesken, Matthias
>>>>> Sent: Montag, 4. Juni 2018 09:24
>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>> exception
>>> in
>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>
>>>>> A small update? -? I found a second? place? in WPrinterJob.cpp   
>>>>> where? the
>>>>> exception handling is missing. After fixing both places I can reenable
>>>>> warning 4297? in
>>>>> Awt2dLibraries.gmk????? which has been? disabled before , probably
>>> because
>>>> of
>>>>> the warnings generated when the exceptions where not handled .
>>>>> Should I update the change with the other file + makefile change ?
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>> hg diff
>>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
>>>>> --- a/make/lib/Awt2dLibraries.gmk????? Tue Apr 10 11:02:09 2018 +0800
>>>>> +++ b/make/lib/Awt2dLibraries.gmk????? Mon Jun 04 09:18:03 2018 +0200
>>>>> @@ -213,6 +213,7 @@
>>>>> ??? LIBAWT_CFLAGS += -fgcse-after-reload
>>>>> ? endif
>>>>>
>>>>>
>>>>> ? $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>>>>> ????? NAME := awt, \
>>>>> ????? SRC := $(LIBAWT_DIRS), \
>>>>> @@ -224,7 +225,7 @@
>>>>> ????????? format-nonliteral parentheses, \
>>>>> ????? DISABLED_WARNINGS_clang := logical-op-parentheses extern-
>>> initializer,
>>>> \
>>>>> ????? DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
>>>>> -??? DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
>>>>> +??? DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>>>>> ????? ASFLAGS := $(LIBAWT_ASFLAGS), \
>>>>> ????? LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
>>> \
>>>>> ????? LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
>>>>> diff -r 12fe57c319e1
>>>>>
>>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>> ---
>>>>>
>>> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>> pp??? Tue Apr 10 11:02:09 2018 +0800
>>>>> +++
>>>>>
>>> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>> pp??? Mon Jun 04 09:18:03 2018 +0200
>>>>> @@ -85,7 +85,13 @@
>>>>> ????????? *pNpoints = outpoints;
>>>>> ????? }
>>>>> ????? if (outpoints > POLYTEMPSIZE) {
>>>>> -??????? pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> sizeof(POINT), outpoints);
>>>>> +??????? try {
>>>>> +??????????? pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> sizeof(POINT), outpoints);
>>>>> +??????? } catch (const std::bad_alloc&) {
>>>>> +??????????? return NULL;
>>>>> +??????? }
>>>>> ????? }
>>>>> ????? BOOL isempty = fixend;
>>>>> ????? for (int i = 0; i < npoints; i++) {
>>>>> diff -r 12fe57c319e1
>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> ---
>>> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> Tue Apr 10 11:02:09 2018 +0800
>>>>> +++
>>>> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> Mon Jun 04 09:18:03 2018 +0200
>>>>> @@ -873,7 +873,12 @@
>>>>> ??????? int numSizes = ::DeviceCapabilities(printerName, printerPort,
>>>>> ??????????????????????????????????????????? DC_PAPERS, NULL, NULL);
>>>>> ??????? if (numSizes > 0) {
>>>>> -????????? LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> numSizes, sizeof(WORD));
>>>>> +????????? LPTSTR papers;
>>>>> +????????? try {
>>>>> +????????????? papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>> numSizes,
>>>>> sizeof(WORD));
>>>>> +????????? } catch (const std::bad_alloc&) {
>>>>> +????????????? papers = NULL;
>>>>> +????????? }
>>>>> ??????????? if (papers != NULL &&
>>>>> ??????????????? ::DeviceCapabilities(printerName, printerPort,
>>>>> ???????????????????????????????????? DC_PAPERS, papers, NULL) != -1) {
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Baesken, Matthias
>>>>>> Sent: Freitag, 1. Juni 2018 14:18
>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>> <christoph.langer at sap.com>
>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
>>> exception
>>>> in
>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>
>>>>>> Hi? Thomas ,? using the? const-reference? sounds like a good idea  
>>>>>> ( I just
>>>>>> copied from? other locations in? the source code where? (almost?)
>>> always
>>>>>> std::bad_alloc&???? (non-const)? is caught .
>>>>>>
>>>>>> For example :
>>>>>>
>>>>>>
>>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
>>>>>> 177 } catch (std::bad_alloc&) { \
>>>>>> 200 } catch (std::bad_alloc&) { \
>>>>>> 206 } catch (std::bad_alloc&) { \
>>>>>>
>>>>>> ? awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
>>>>>> 247 } catch (std::bad_alloc&) {
>>>>>> 317 } catch (std::bad_alloc&) {
>>>>>> 372 } catch (std::bad_alloc&) {
>>>>>> 407 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ? awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
>>>>>> 264 } catch (std::bad_alloc&) {
>>>>>> 305 } catch (std::bad_alloc&) {
>>>>>> 366 } catch (std::bad_alloc&) {
>>>>>> 582 } catch (std::bad_alloc&) {
>>>>>> 635 } catch (std::bad_alloc&) {
>>>>>> 653 } catch (std::bad_alloc&) {
>>>>>> 698 } catch (std::bad_alloc&) {
>>>>>> 739 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ? awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
>>>>>> 345 } catch (std::bad_alloc&) {
>>>>>> 425 } catch (std::bad_alloc&) {
>>>>>> 488 } catch (std::bad_alloc&) {
>>>>>> 631 } catch (std::bad_alloc&) {
>>>>>> 709 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ? awt_ole.h 158 } catch (std::bad_alloc&) {\
>>>>>>
>>>>>> ? awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
>>>>>> 269 catch (std::bad_alloc&) {
>>>>>> 647 catch (std::bad_alloc&) {
>>>>>> 664 catch (std::bad_alloc&) {
>>>>>> 689 catch (std::bad_alloc&) {
>>>>>>
>>>>>> ? awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ? awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
>>>>>> 724 } catch (std::bad_alloc &) {
>>>>>> 792 } catch (std::bad_alloc &) {
>>>>>>
>>>>>> ? awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
>>>>>> 348 } catch (std::bad_alloc&) {
>>>>>> 524 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ? ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
>>>>>> 1435 } catch (std::bad_alloc&) {
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>> Sent: Freitag, 1. Juni 2018 12:02
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>> <christoph.langer at sap.com>
>>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
>>>> exception
>>>>> in
>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> Please consider catching all exceptions, not just std::alloc:
>>>>>>>
>>>>>>> } catch (...) { return NULL; }
>>>>>>>
>>>>>>> and doing it at the exit extern "C" function, not somewhere
>>>>>>> internally. Regardless of which exceptions get thrown around below
>>>> you
>>>>>>> and by whom, you are safe that way.
>>>>>>>
>>>>>>> However, if you want to keep your patch as it is, please catch at
>>>>>>> least as const reference:
>>>>>>>
>>>>>>> } catch (const std::bad_alloc&) {}
>>>>>>>
>>>>>>> Fine otherwise. I do not need another webrev.
>>>>>>>
>>>>>>> Best Regards, Thomas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>> Hi Thomas , thanks for the feedback.
>>>>>>>> I created a bug and change for the excpetion handling in
>>>>>> GDIRenderer.cpp
>>>>>>> .
>>>>>>>> Please review .
>>>>>>>>
>>>>>>>> Thanks,? Matthias
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
>>>>>>>>
>>>>>>>> JDK-8204211: windows : handle potential C++ exception in
>>>> GDIRenderer
>>>>>>>>
>>>>>>>> Change :
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>>
>>>>>>>>> Letting c++ exceptions escape from extern "C" functions is UB and
>>>>> may
>>>>>>>>> (and probably will) crash the process. This should be fixed.
>>> Approach
>>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every C++
>>>>>>>>> exception with catch(...), not just bad_alloc, just to be safe).
>>>>>>>>>
>>>>>>>>> Best Regards, Thomas
>>>>>>>>>
>>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
>>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>>> Hello ,? there is still some? java2d coding? where
>>>>>>> SAFE_SIZE_ARRAY_ALLOC /
>>>>>>>>>> safe_Malloc??? is used? and? the? (potentially occurring) 
>>>>>>>>>> exception
>>> is
>>>>> not
>>>>>>>>>> handled .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This leads to? CL warnings? (when enabled? ) like
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> " function assumed not to throw an exception but does ; The
>>>>> function
>>>>>> is
>>>>>>>>>> extern "C" and /EHc was specified"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Example :
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> static POINT *TransformPoly()
>>>>>>>>>>
>>>>>>>>>> ?? ?..
>>>>>>>>>>
>>>>>>>>>> ???? if (outpoints > POLYTEMPSIZE) {
>>>>>>>>>>
>>>>>>>>>> ???????? pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>>>>> sizeof(POINT), outpoints);
>>>>>>>>>>
>>>>>>>>>> ???? }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Should? we add exception handling?? here ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Similar fixes were done? in the change? 8039394: Compiler
>>> warnings
>>>>>>> about
>>>>>>>>> C++
>>>>>>>>>> exceptions in windows printing code
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
>>>>>>>>>>
>>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards, Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Jun  5 20:37:43 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Jun 2018 13:37:43 -0700
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <445929ef-400d-586b-bc4d-3692598b0329@oracle.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
 <30d8ab01-e3bf-6b39-d9d5-d8cd4cedb7dc@oracle.com>
 <445929ef-400d-586b-bc4d-3692598b0329@oracle.com>
Message-ID: <6f56e1de-a3e6-279e-702b-72484ef533ca@oracle.com>

I have checked the fix using mach5.

On 05/06/2018 12:45, Phil Race wrote:
> Oh .. can I please ask that you make sure that VS2017 is OK with the 
> re-enabled
> warning ? I seriously doubt that it has anything new to add over VS2013, 
> but a jdk-submit
> will tell you if it has ..
> 
> VS2017 is now the default so a jdk-submit will use that.
> 
> -phil.
> 
> On 06/05/2018 12:43 PM, Phil Race wrote:
>> This looks good to me except for what looks like in my browser like 
>> missing indentation in
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows 
>>
>> /GDIRenderer.cpp.udiff.html
>>
>> You can fix that with or without an updated webrev.
>>
>> Good to clear a class of warnings.
>>
>> -phil.
>>
>> On 06/05/2018 12:47 AM, Baesken, Matthias wrote:
>>> Hi Christoph, thank's for the? review .
>>> Could I have a second one? for example from the? awt or build-dev 
>>> reviewers ?
>>>
>>> Best Regards, Matthias
>>>
>>>
>>>> -----Original Message-----
>>>> From: Langer, Christoph
>>>> Sent: Montag, 4. Juni 2018 16:49
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
>>>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
>>>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>> exception in
>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>
>>>> Hi Matthias,
>>>>
>>>> looks good to me.
>>>>
>>>> Don't forget the Copyright years.
>>>>
>>>> Best regards
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Baesken, Matthias
>>>>> Sent: Montag, 4. Juni 2018 16:20
>>>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
>>>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
>>>>> dev at openjdk.java.net
>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>> exception in
>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>
>>>>> Hello,? I prepared a second webrev.
>>>>>
>>>>> - use now? const-reference? in the catch-statements as suggested by
>>>> Thomas
>>>>> - reenabled the cl warning? showing the exception issues? in
>>>>> make/lib/Awt2dLibraries.gmk
>>>>> - found a second place? in? WPrinterJob.cpp?? with similar issues 
>>>>> after
>>>>> reenabling the warnings
>>>>>
>>>>> Please review :
>>>>>
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
>>>>>
>>>>> (cc-ing? build-dev?? because of? the makefile change,? and
>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>> because of the awt change )
>>>>>
>>>>>
>>>>> Thanks, Matthias
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Baesken, Matthias
>>>>>> Sent: Montag, 4. Juni 2018 09:24
>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>> <christoph.langer at sap.com>
>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>>> exception
>>>> in
>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>
>>>>>> A small update? -? I found a second? place? in WPrinterJob.cpp 
>>>>>> where? the
>>>>>> exception handling is missing. After fixing both places I can 
>>>>>> reenable
>>>>>> warning 4297? in
>>>>>> Awt2dLibraries.gmk????? which has been? disabled before , probably
>>>> because
>>>>> of
>>>>>> the warnings generated when the exceptions where not handled .
>>>>>> Should I update the change with the other file + makefile change ?
>>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>> hg diff
>>>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
>>>>>> --- a/make/lib/Awt2dLibraries.gmk????? Tue Apr 10 11:02:09 2018 +0800
>>>>>> +++ b/make/lib/Awt2dLibraries.gmk????? Mon Jun 04 09:18:03 2018 +0200
>>>>>> @@ -213,6 +213,7 @@
>>>>>> ??? LIBAWT_CFLAGS += -fgcse-after-reload
>>>>>> ? endif
>>>>>>
>>>>>>
>>>>>> ? $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>>>>>> ????? NAME := awt, \
>>>>>> ????? SRC := $(LIBAWT_DIRS), \
>>>>>> @@ -224,7 +225,7 @@
>>>>>> ????????? format-nonliteral parentheses, \
>>>>>> ????? DISABLED_WARNINGS_clang := logical-op-parentheses extern-
>>>> initializer,
>>>>> \
>>>>>> ????? DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
>>>>>> -??? DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
>>>>>> +??? DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>>>>>> ????? ASFLAGS := $(LIBAWT_ASFLAGS), \
>>>>>> ????? LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
>>>> \
>>>>>> ????? LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
>>>>>> diff -r 12fe57c319e1
>>>>>>
>>>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>> ---
>>>>>>
>>>> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>>> pp??? Tue Apr 10 11:02:09 2018 +0800
>>>>>> +++
>>>>>>
>>>> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>>> pp??? Mon Jun 04 09:18:03 2018 +0200
>>>>>> @@ -85,7 +85,13 @@
>>>>>> ????????? *pNpoints = outpoints;
>>>>>> ????? }
>>>>>> ????? if (outpoints > POLYTEMPSIZE) {
>>>>>> -??????? pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>> sizeof(POINT), outpoints);
>>>>>> +??????? try {
>>>>>> +??????????? pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>> sizeof(POINT), outpoints);
>>>>>> +??????? } catch (const std::bad_alloc&) {
>>>>>> +??????????? return NULL;
>>>>>> +??????? }
>>>>>> ????? }
>>>>>> ????? BOOL isempty = fixend;
>>>>>> ????? for (int i = 0; i < npoints; i++) {
>>>>>> diff -r 12fe57c319e1
>>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>> ---
>>>> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>> Tue Apr 10 11:02:09 2018 +0800
>>>>>> +++
>>>>> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>> Mon Jun 04 09:18:03 2018 +0200
>>>>>> @@ -873,7 +873,12 @@
>>>>>> ??????? int numSizes = ::DeviceCapabilities(printerName, printerPort,
>>>>>> ??????????????????????????????????????????? DC_PAPERS, NULL, NULL);
>>>>>> ??????? if (numSizes > 0) {
>>>>>> -????????? LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>> numSizes, sizeof(WORD));
>>>>>> +????????? LPTSTR papers;
>>>>>> +????????? try {
>>>>>> +????????????? papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>> numSizes,
>>>>>> sizeof(WORD));
>>>>>> +????????? } catch (const std::bad_alloc&) {
>>>>>> +????????????? papers = NULL;
>>>>>> +????????? }
>>>>>> ??????????? if (papers != NULL &&
>>>>>> ??????????????? ::DeviceCapabilities(printerName, printerPort,
>>>>>> ???????????????????????????????????? DC_PAPERS, papers, NULL) != 
>>>>>> -1) {
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Baesken, Matthias
>>>>>>> Sent: Freitag, 1. Juni 2018 14:18
>>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>> <christoph.langer at sap.com>
>>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
>>>> exception
>>>>> in
>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>
>>>>>>> Hi? Thomas ,? using the? const-reference? sounds like a good 
>>>>>>> idea? ( I just
>>>>>>> copied from? other locations in? the source code where (almost?)
>>>> always
>>>>>>> std::bad_alloc& (non-const)? is caught .
>>>>>>>
>>>>>>> For example :
>>>>>>>
>>>>>>>
>>>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
>>>>>>> 177 } catch (std::bad_alloc&) { \
>>>>>>> 200 } catch (std::bad_alloc&) { \
>>>>>>> 206 } catch (std::bad_alloc&) { \
>>>>>>>
>>>>>>> ? awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
>>>>>>> 247 } catch (std::bad_alloc&) {
>>>>>>> 317 } catch (std::bad_alloc&) {
>>>>>>> 372 } catch (std::bad_alloc&) {
>>>>>>> 407 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ? awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
>>>>>>> 264 } catch (std::bad_alloc&) {
>>>>>>> 305 } catch (std::bad_alloc&) {
>>>>>>> 366 } catch (std::bad_alloc&) {
>>>>>>> 582 } catch (std::bad_alloc&) {
>>>>>>> 635 } catch (std::bad_alloc&) {
>>>>>>> 653 } catch (std::bad_alloc&) {
>>>>>>> 698 } catch (std::bad_alloc&) {
>>>>>>> 739 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ? awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
>>>>>>> 345 } catch (std::bad_alloc&) {
>>>>>>> 425 } catch (std::bad_alloc&) {
>>>>>>> 488 } catch (std::bad_alloc&) {
>>>>>>> 631 } catch (std::bad_alloc&) {
>>>>>>> 709 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ? awt_ole.h 158 } catch (std::bad_alloc&) {\
>>>>>>>
>>>>>>> ? awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
>>>>>>> 269 catch (std::bad_alloc&) {
>>>>>>> 647 catch (std::bad_alloc&) {
>>>>>>> 664 catch (std::bad_alloc&) {
>>>>>>> 689 catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ? awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ? awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
>>>>>>> 724 } catch (std::bad_alloc &) {
>>>>>>> 792 } catch (std::bad_alloc &) {
>>>>>>>
>>>>>>> ? awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
>>>>>>> 348 } catch (std::bad_alloc&) {
>>>>>>> 524 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ? ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
>>>>>>> 1435 } catch (std::bad_alloc&) {
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> Best regards, Matthias
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>> Sent: Freitag, 1. Juni 2018 12:02
>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>>> <christoph.langer at sap.com>
>>>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
>>>>> exception
>>>>>> in
>>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>
>>>>>>>> Hi Matthias,
>>>>>>>>
>>>>>>>> Please consider catching all exceptions, not just std::alloc:
>>>>>>>>
>>>>>>>> } catch (...) { return NULL; }
>>>>>>>>
>>>>>>>> and doing it at the exit extern "C" function, not somewhere
>>>>>>>> internally. Regardless of which exceptions get thrown around below
>>>>> you
>>>>>>>> and by whom, you are safe that way.
>>>>>>>>
>>>>>>>> However, if you want to keep your patch as it is, please catch at
>>>>>>>> least as const reference:
>>>>>>>>
>>>>>>>> } catch (const std::bad_alloc&) {}
>>>>>>>>
>>>>>>>> Fine otherwise. I do not need another webrev.
>>>>>>>>
>>>>>>>> Best Regards, Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>> Hi Thomas , thanks for the feedback.
>>>>>>>>> I created a bug and change for the excpetion handling in
>>>>>>> GDIRenderer.cpp
>>>>>>>> .
>>>>>>>>> Please review .
>>>>>>>>>
>>>>>>>>> Thanks,? Matthias
>>>>>>>>>
>>>>>>>>> Bug:
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
>>>>>>>>>
>>>>>>>>> JDK-8204211: windows : handle potential C++ exception in
>>>>> GDIRenderer
>>>>>>>>>
>>>>>>>>> Change :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
>>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>>>
>>>>>>>>>> Letting c++ exceptions escape from extern "C" functions is UB and
>>>>>> may
>>>>>>>>>> (and probably will) crash the process. This should be fixed.
>>>> Approach
>>>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every C++
>>>>>>>>>> exception with catch(...), not just bad_alloc, just to be safe).
>>>>>>>>>>
>>>>>>>>>> Best Regards, Thomas
>>>>>>>>>>
>>>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
>>>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>>>> Hello ,? there is still some? java2d coding? where
>>>>>>>> SAFE_SIZE_ARRAY_ALLOC /
>>>>>>>>>>> safe_Malloc??? is used and? the? (potentially occurring) 
>>>>>>>>>>> exception
>>>> is
>>>>>> not
>>>>>>>>>>> handled .
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This leads to? CL warnings? (when enabled? ) like
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> " function assumed not to throw an exception but does ; The
>>>>>> function
>>>>>>> is
>>>>>>>>>>> extern "C" and /EHc was specified"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Example :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> static POINT *TransformPoly()
>>>>>>>>>>>
>>>>>>>>>>> ?? ?..
>>>>>>>>>>>
>>>>>>>>>>> ???? if (outpoints > POLYTEMPSIZE) {
>>>>>>>>>>>
>>>>>>>>>>> ???????? pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>>>>>> sizeof(POINT), outpoints);
>>>>>>>>>>>
>>>>>>>>>>> ???? }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Should? we add exception handling?? here ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Similar fixes were done? in the change? 8039394: Compiler
>>>> warnings
>>>>>>>> about
>>>>>>>>>> C++
>>>>>>>>>>> exceptions in windows printing code
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
>>>>>>>>>>>
>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards, Matthias
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue Jun  5 21:41:22 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 5 Jun 2018 14:41:22 -0700
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <6f56e1de-a3e6-279e-702b-72484ef533ca@oracle.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
 <30d8ab01-e3bf-6b39-d9d5-d8cd4cedb7dc@oracle.com>
 <445929ef-400d-586b-bc4d-3692598b0329@oracle.com>
 <6f56e1de-a3e6-279e-702b-72484ef533ca@oracle.com>
Message-ID: <55be10c7-6667-11b2-73b9-f71e5564cb1f@oracle.com>


In that case Matthias is good to go after fixing the indentation.

-phil.

On 06/05/2018 01:37 PM, Sergey Bylokhov wrote:
> I have checked the fix using mach5.
>
> On 05/06/2018 12:45, Phil Race wrote:
>> Oh .. can I please ask that you make sure that VS2017 is OK with the 
>> re-enabled
>> warning ? I seriously doubt that it has anything new to add over 
>> VS2013, but a jdk-submit
>> will tell you if it has ..
>>
>> VS2017 is now the default so a jdk-submit will use that.
>>
>> -phil.
>>
>> On 06/05/2018 12:43 PM, Phil Race wrote:
>>> This looks good to me except for what looks like in my browser like 
>>> missing indentation in
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows 
>>>
>>> /GDIRenderer.cpp.udiff.html
>>>
>>> You can fix that with or without an updated webrev.
>>>
>>> Good to clear a class of warnings.
>>>
>>> -phil.
>>>
>>> On 06/05/2018 12:47 AM, Baesken, Matthias wrote:
>>>> Hi Christoph, thank's for the  review .
>>>> Could I have a second one  for example from the  awt or build-dev 
>>>> reviewers ?
>>>>
>>>> Best Regards, Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Langer, Christoph
>>>>> Sent: Montag, 4. Juni 2018 16:49
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
>>>>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
>>>>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>> exception in
>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> looks good to me.
>>>>>
>>>>> Don't forget the Copyright years.
>>>>>
>>>>> Best regards
>>>>> Christoph
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Baesken, Matthias
>>>>>> Sent: Montag, 4. Juni 2018 16:20
>>>>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
>>>>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
>>>>>> dev at openjdk.java.net
>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>> <christoph.langer at sap.com>
>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>>> exception in
>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>
>>>>>> Hello,  I prepared a second webrev.
>>>>>>
>>>>>> - use now  const-reference  in the catch-statements as suggested by
>>>>> Thomas
>>>>>> - reenabled the cl warning showing the exception issues  in
>>>>>> make/lib/Awt2dLibraries.gmk
>>>>>> - found a second place  in  WPrinterJob.cpp   with similar issues 
>>>>>> after
>>>>>> reenabling the warnings
>>>>>>
>>>>>> Please review :
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
>>>>>>
>>>>>> (cc-ing  build-dev   because of  the makefile change, and
>>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>> because of the awt change )
>>>>>>
>>>>>>
>>>>>> Thanks, Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Baesken, Matthias
>>>>>>> Sent: Montag, 4. Juni 2018 09:24
>>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>> <christoph.langer at sap.com>
>>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
>>>>>>> exception
>>>>> in
>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>
>>>>>>> A small update  -  I found a second  place  in WPrinterJob.cpp 
>>>>>>> where  the
>>>>>>> exception handling is missing. After fixing both places I can 
>>>>>>> reenable
>>>>>>> warning 4297  in
>>>>>>> Awt2dLibraries.gmk      which has been  disabled before , probably
>>>>> because
>>>>>> of
>>>>>>> the warnings generated when the exceptions where not handled .
>>>>>>> Should I update the change with the other file + makefile change ?
>>>>>>>
>>>>>>> Best regards, Matthias
>>>>>>>
>>>>>>>
>>>>>>>> hg diff
>>>>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
>>>>>>> --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018 
>>>>>>> +0800
>>>>>>> +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018 
>>>>>>> +0200
>>>>>>> @@ -213,6 +213,7 @@
>>>>>>>     LIBAWT_CFLAGS += -fgcse-after-reload
>>>>>>>   endif
>>>>>>>
>>>>>>>
>>>>>>>   $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
>>>>>>>       NAME := awt, \
>>>>>>>       SRC := $(LIBAWT_DIRS), \
>>>>>>> @@ -224,7 +225,7 @@
>>>>>>>           format-nonliteral parentheses, \
>>>>>>>       DISABLED_WARNINGS_clang := logical-op-parentheses extern-
>>>>> initializer,
>>>>>> \
>>>>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
>>>>>>> -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
>>>>>>> +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
>>>>>>>       ASFLAGS := $(LIBAWT_ASFLAGS), \
>>>>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) $(call 
>>>>>>> SET_SHARED_LIBRARY_ORIGIN),
>>>>> \
>>>>>>>       LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
>>>>>>> diff -r 12fe57c319e1
>>>>>>>
>>>>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>> ---
>>>>>>>
>>>>> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>>>> pp    Tue Apr 10 11:02:09 2018 +0800
>>>>>>> +++
>>>>>>>
>>>>> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
>>>>>>> pp    Mon Jun 04 09:18:03 2018 +0200
>>>>>>> @@ -85,7 +85,13 @@
>>>>>>>           *pNpoints = outpoints;
>>>>>>>       }
>>>>>>>       if (outpoints > POLYTEMPSIZE) {
>>>>>>> -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>> sizeof(POINT), outpoints);
>>>>>>> +        try {
>>>>>>> +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>> sizeof(POINT), outpoints);
>>>>>>> +        } catch (const std::bad_alloc&) {
>>>>>>> +            return NULL;
>>>>>>> +        }
>>>>>>>       }
>>>>>>>       BOOL isempty = fixend;
>>>>>>>       for (int i = 0; i < npoints; i++) {
>>>>>>> diff -r 12fe57c319e1
>>>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>>> ---
>>>>> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>>> Tue Apr 10 11:02:09 2018 +0800
>>>>>>> +++
>>>>>> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
>>>>>>> Mon Jun 04 09:18:03 2018 +0200
>>>>>>> @@ -873,7 +873,12 @@
>>>>>>>         int numSizes = ::DeviceCapabilities(printerName, 
>>>>>>> printerPort,
>>>>>>>                                             DC_PAPERS, NULL, NULL);
>>>>>>>         if (numSizes > 0) {
>>>>>>> -          LPTSTR papers = 
>>>>>>> (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>> numSizes, sizeof(WORD));
>>>>>>> +          LPTSTR papers;
>>>>>>> +          try {
>>>>>>> +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>> numSizes,
>>>>>>> sizeof(WORD));
>>>>>>> +          } catch (const std::bad_alloc&) {
>>>>>>> +              papers = NULL;
>>>>>>> +          }
>>>>>>>             if (papers != NULL &&
>>>>>>>                 ::DeviceCapabilities(printerName, printerPort,
>>>>>>>                                      DC_PAPERS, papers, NULL) != 
>>>>>>> -1) {
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Baesken, Matthias
>>>>>>>> Sent: Freitag, 1. Juni 2018 14:18
>>>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>>> <christoph.langer at sap.com>
>>>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
>>>>> exception
>>>>>> in
>>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>
>>>>>>>> Hi  Thomas ,  using the  const-reference  sounds like a good 
>>>>>>>> idea  ( I just
>>>>>>>> copied from  other locations in  the source code where (almost?)
>>>>> always
>>>>>>>> std::bad_alloc& (non-const)  is caught .
>>>>>>>>
>>>>>>>> For example :
>>>>>>>>
>>>>>>>>
>>>>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
>>>>>>>> 177 } catch (std::bad_alloc&) { \
>>>>>>>> 200 } catch (std::bad_alloc&) { \
>>>>>>>> 206 } catch (std::bad_alloc&) { \
>>>>>>>>
>>>>>>>>   awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
>>>>>>>> 247 } catch (std::bad_alloc&) {
>>>>>>>> 317 } catch (std::bad_alloc&) {
>>>>>>>> 372 } catch (std::bad_alloc&) {
>>>>>>>> 407 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>>   awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
>>>>>>>> 264 } catch (std::bad_alloc&) {
>>>>>>>> 305 } catch (std::bad_alloc&) {
>>>>>>>> 366 } catch (std::bad_alloc&) {
>>>>>>>> 582 } catch (std::bad_alloc&) {
>>>>>>>> 635 } catch (std::bad_alloc&) {
>>>>>>>> 653 } catch (std::bad_alloc&) {
>>>>>>>> 698 } catch (std::bad_alloc&) {
>>>>>>>> 739 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>>   awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
>>>>>>>> 345 } catch (std::bad_alloc&) {
>>>>>>>> 425 } catch (std::bad_alloc&) {
>>>>>>>> 488 } catch (std::bad_alloc&) {
>>>>>>>> 631 } catch (std::bad_alloc&) {
>>>>>>>> 709 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>>   awt_ole.h 158 } catch (std::bad_alloc&) {\
>>>>>>>>
>>>>>>>>   awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
>>>>>>>> 269 catch (std::bad_alloc&) {
>>>>>>>> 647 catch (std::bad_alloc&) {
>>>>>>>> 664 catch (std::bad_alloc&) {
>>>>>>>> 689 catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>>   awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>>   awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
>>>>>>>> 724 } catch (std::bad_alloc &) {
>>>>>>>> 792 } catch (std::bad_alloc &) {
>>>>>>>>
>>>>>>>>   awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
>>>>>>>> 348 } catch (std::bad_alloc&) {
>>>>>>>> 524 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>>   ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
>>>>>>>> 1435 } catch (std::bad_alloc&) {
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> Best regards, Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>>> Sent: Freitag, 1. Juni 2018 12:02
>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
>>>>>>>>> <christoph.langer at sap.com>
>>>>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
>>>>>> exception
>>>>>>> in
>>>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>>
>>>>>>>>> Hi Matthias,
>>>>>>>>>
>>>>>>>>> Please consider catching all exceptions, not just std::alloc:
>>>>>>>>>
>>>>>>>>> } catch (...) { return NULL; }
>>>>>>>>>
>>>>>>>>> and doing it at the exit extern "C" function, not somewhere
>>>>>>>>> internally. Regardless of which exceptions get thrown around 
>>>>>>>>> below
>>>>>> you
>>>>>>>>> and by whom, you are safe that way.
>>>>>>>>>
>>>>>>>>> However, if you want to keep your patch as it is, please catch at
>>>>>>>>> least as const reference:
>>>>>>>>>
>>>>>>>>> } catch (const std::bad_alloc&) {}
>>>>>>>>>
>>>>>>>>> Fine otherwise. I do not need another webrev.
>>>>>>>>>
>>>>>>>>> Best Regards, Thomas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
>>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>>> Hi Thomas , thanks for the feedback.
>>>>>>>>>> I created a bug and change for the excpetion handling in
>>>>>>>> GDIRenderer.cpp
>>>>>>>>> .
>>>>>>>>>> Please review .
>>>>>>>>>>
>>>>>>>>>> Thanks,  Matthias
>>>>>>>>>>
>>>>>>>>>> Bug:
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
>>>>>>>>>>
>>>>>>>>>> JDK-8204211: windows : handle potential C++ exception in
>>>>>> GDIRenderer
>>>>>>>>>>
>>>>>>>>>> Change :
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>>>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
>>>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
>>>>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
>>>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>>>>>>>>>>>
>>>>>>>>>>> Letting c++ exceptions escape from extern "C" functions is 
>>>>>>>>>>> UB and
>>>>>>> may
>>>>>>>>>>> (and probably will) crash the process. This should be fixed.
>>>>> Approach
>>>>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every C++
>>>>>>>>>>> exception with catch(...), not just bad_alloc, just to be 
>>>>>>>>>>> safe).
>>>>>>>>>>>
>>>>>>>>>>> Best Regards, Thomas
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
>>>>>>>>>>> <matthias.baesken at sap.com> wrote:
>>>>>>>>>>>> Hello ,  there is still some  java2d coding  where
>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC /
>>>>>>>>>>>> safe_Malloc    is used and  the  (potentially occurring) 
>>>>>>>>>>>> exception
>>>>> is
>>>>>>> not
>>>>>>>>>>>> handled .
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This leads to  CL warnings  (when enabled  ) like
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> " function assumed not to throw an exception but does ; The
>>>>>>> function
>>>>>>>> is
>>>>>>>>>>>> extern "C" and /EHc was specified"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Example :
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> static POINT *TransformPoly()
>>>>>>>>>>>>
>>>>>>>>>>>>    ?..
>>>>>>>>>>>>
>>>>>>>>>>>>      if (outpoints > POLYTEMPSIZE) {
>>>>>>>>>>>>
>>>>>>>>>>>>          pPoints = (POINT *) 
>>>>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
>>>>>>>>>>>> sizeof(POINT), outpoints);
>>>>>>>>>>>>
>>>>>>>>>>>>      }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Should  we add exception handling   here ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Similar fixes were done  in the change 8039394: Compiler
>>>>> warnings
>>>>>>>>> about
>>>>>>>>>>> C++
>>>>>>>>>>>> exceptions in windows printing code
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
>>>>>>>>>>>>
>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards, Matthias
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>
>
>



From david.holmes at oracle.com  Wed Jun  6 04:17:49 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Jun 2018 14:17:49 +1000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
Message-ID: <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>

Hi Erik, Jesper,

On 6/06/2018 2:59 AM, jesper.wilhelmsson at oracle.com wrote:
>> On 5 Jun 2018, at 08:10, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Sorry to be late to this party ...
>>
>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>> Renamed the new jvm variant to "hardened".
>>
>> As it is a hardened server build I'd prefer if that were somehow reflected in the name. Though really I don't see why this should be restricted this way ... to be honest I don't see hardened as a variant of server vs. client vs. zero etc at all, you should be able to harden any of those.
>>
>> So IIUC with this change we will:
>> - always build JDK native code "hardened" (if toolchain supports it)
>> - only build hotspot "hardened" if requested; and in that case
>>   - jvm.cfg will list -server and -hardened with server as default
>>
>> Is that right? I can see that we may choose to always build Oracle JDK this way but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot is selectable but JDK is not. ??
> 
> Sorry for the lack of information here. There has been a lot of off-list discussions behind this change, I've added the background to the bug now.
> 
> The short version is that we see a ~25% regression in startup times if the JVM is compiled with the gcc flags to avoid speculative execution. We have not observed any performance regressions due to compiling the rest of the native libraries with these gcc flags, so there doesn't seem to be any reason to have different versions of other libraries.

So "benevolent dictatorship"?  ;-)

My main concern is that the updated toolchains that support this have 
all been produced in a mad rush and quite frankly I expect them to be 
buggy. I don't think it is hard to enable the builder of OpenJDK to have 
full choice and control here.

Cheers,
David

> /Jesper
> 
>> Sorry.
>>
>> David
>> -----
>>
>>> /Erik
>>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>>> 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?
>>>>> I don't know. I'm open to suggestions on naming.
>>>> "hardened" sounds good to me.
>>>>
>>>> The change looks good as well.
>>>> /Jesper
>>>>
>>>>> /Erik
>>>>>> -Aleksey
>>>>>>
> 


From matthias.baesken at sap.com  Wed Jun  6 07:59:56 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 6 Jun 2018 07:59:56 +0000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
In-Reply-To: <f198098a-4c7f-da88-5824-444eeeee86d7@oracle.com>
References: <3f7c0b36458a467b85c41ed467b41614@sap.com>
 <f198098a-4c7f-da88-5824-444eeeee86d7@oracle.com>
Message-ID: <524eaa757f934d25a3f42d97daa5216b@sap.com>

Thanks for the clarification !

From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Dienstag, 5. Juni 2018 17:51
To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>
Cc: Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: JDK-8202384: Introduce altserver jvm variant with


Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I think some minimal update version (the option is called -Qspectre), we use 15.5.5.

I was not involved in the benchmarking so I don't know any details there, only the conclusion.

/Erik

On 2018-06-05 01:30, Baesken, Matthias wrote:

Hi Erik , is there  some info available about  the performance impact when  disabling  disabling speculative execution  ?



And which compiler versions are needed for this ?



Best regards, Matthias





>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<http://cr.openjdk.java.net/%7Eerikj/8202384/webrev.01>






From matthias.baesken at sap.com  Wed Jun  6 11:45:51 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 6 Jun 2018 11:45:51 +0000
Subject: RFR: JDK-8204211: windows : handle potential C++ exception in
 GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
 SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
In-Reply-To: <55be10c7-6667-11b2-73b9-f71e5564cb1f@oracle.com>
References: <9eb40f5290284b54ac52ebfcb4aeb841@sap.com>
 <CAA-vtUxvtdKW66aMwvpj0CrF7nidiibUnq1fYgfWaWz_nyKh0A@mail.gmail.com>
 <c4a80bd68c9442aaa8d4ac3f5d698be9@sap.com>
 <d116e6752ca44a03a3b6bcd1a9bb30d6@sap.com>
 <77009f7c379c4dfd817841a5d31067c2@sap.com>
 <ebc8cb65aa7445269ad2086b0fcced2a@sap.com>
 <a0cad0530b284cb1929a728e2e0a84b8@sap.com>
 <30d8ab01-e3bf-6b39-d9d5-d8cd4cedb7dc@oracle.com>
 <445929ef-400d-586b-bc4d-3692598b0329@oracle.com>
 <6f56e1de-a3e6-279e-702b-72484ef533ca@oracle.com>
 <55be10c7-6667-11b2-73b9-f71e5564cb1f@oracle.com>
Message-ID: <dafd455344c2484aa541a523975181e6@sap.com>

Hi  Sergey, thanks for checking .
@Christoph : copyright years updated in the cpp files .
@Phil , I checked the indentation it looked indeed strange  in the udiff  however in the cpp file itself it looks ok to me .

Thanks for the reviews and best regards, Matthias


> -----Original Message-----
> From: Phil Race [mailto:philip.race at oracle.com]
> Sent: Dienstag, 5. Juni 2018 23:41
> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; Thomas St?fe <thomas.stuefe at gmail.com>;
> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
> dev at openjdk.java.net
> Cc: 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> 
> 
> In that case Matthias is good to go after fixing the indentation.
> 
> -phil.
> 
> On 06/05/2018 01:37 PM, Sergey Bylokhov wrote:
> > I have checked the fix using mach5.
> >
> > On 05/06/2018 12:45, Phil Race wrote:
> >> Oh .. can I please ask that you make sure that VS2017 is OK with the
> >> re-enabled
> >> warning ? I seriously doubt that it has anything new to add over
> >> VS2013, but a jdk-submit
> >> will tell you if it has ..
> >>
> >> VS2017 is now the default so a jdk-submit will use that.
> >>
> >> -phil.
> >>
> >> On 06/05/2018 12:43 PM, Phil Race wrote:
> >>> This looks good to me except for what looks like in my browser like
> >>> missing indentation in
> >>>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.deskto
> p/windows/native/libawt/java2d/windows
> >>>
> >>> /GDIRenderer.cpp.udiff.html
> >>>
> >>> You can fix that with or without an updated webrev.
> >>>
> >>> Good to clear a class of warnings.
> >>>
> >>> -phil.
> >>>
> >>> On 06/05/2018 12:47 AM, Baesken, Matthias wrote:
> >>>> Hi Christoph, thank's for the  review .
> >>>> Could I have a second one  for example from the  awt or build-dev
> >>>> reviewers ?
> >>>>
> >>>> Best Regards, Matthias
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Langer, Christoph
> >>>>> Sent: Montag, 4. Juni 2018 16:49
> >>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Thomas St?fe
> >>>>> <thomas.stuefe at gmail.com>; 'build-dev at openjdk.java.net' <build-
> >>>>> dev at openjdk.java.net>; awt-dev at openjdk.java.net
> >>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
> >>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
> >>>>> exception in
> >>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> >>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >>>>>
> >>>>> Hi Matthias,
> >>>>>
> >>>>> looks good to me.
> >>>>>
> >>>>> Don't forget the Copyright years.
> >>>>>
> >>>>> Best regards
> >>>>> Christoph
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Baesken, Matthias
> >>>>>> Sent: Montag, 4. Juni 2018 16:20
> >>>>>> To: Thomas St?fe <thomas.stuefe at gmail.com>; 'build-
> >>>>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt-
> >>>>>> dev at openjdk.java.net
> >>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> >>>>>> <christoph.langer at sap.com>
> >>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
> >>>>>> exception in
> >>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> >>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >>>>>>
> >>>>>> Hello,  I prepared a second webrev.
> >>>>>>
> >>>>>> - use now  const-reference  in the catch-statements as suggested by
> >>>>> Thomas
> >>>>>> - reenabled the cl warning showing the exception issues  in
> >>>>>> make/lib/Awt2dLibraries.gmk
> >>>>>> - found a second place  in  WPrinterJob.cpp   with similar issues
> >>>>>> after
> >>>>>> reenabling the warnings
> >>>>>>
> >>>>>> Please review :
> >>>>>>
> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
> >>>>>>
> >>>>>> (cc-ing  build-dev   because of  the makefile change, and
> >>>>>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> >>>>>> because of the awt change )
> >>>>>>
> >>>>>>
> >>>>>> Thanks, Matthias
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Baesken, Matthias
> >>>>>>> Sent: Montag, 4. Juni 2018 09:24
> >>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> >>>>>>> Cc: '2d-dev' <2d-dev at openjdk.java.net>; Langer, Christoph
> >>>>>>> <christoph.langer at sap.com>
> >>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
> >>>>>>> exception
> >>>>> in
> >>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> >>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >>>>>>>
> >>>>>>> A small update  -  I found a second  place  in WPrinterJob.cpp
> >>>>>>> where  the
> >>>>>>> exception handling is missing. After fixing both places I can
> >>>>>>> reenable
> >>>>>>> warning 4297  in
> >>>>>>> Awt2dLibraries.gmk      which has been  disabled before , probably
> >>>>> because
> >>>>>> of
> >>>>>>> the warnings generated when the exceptions where not handled .
> >>>>>>> Should I update the change with the other file + makefile change ?
> >>>>>>>
> >>>>>>> Best regards, Matthias
> >>>>>>>
> >>>>>>>
> >>>>>>>> hg diff
> >>>>>>> diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
> >>>>>>> --- a/make/lib/Awt2dLibraries.gmk      Tue Apr 10 11:02:09 2018
> >>>>>>> +0800
> >>>>>>> +++ b/make/lib/Awt2dLibraries.gmk      Mon Jun 04 09:18:03 2018
> >>>>>>> +0200
> >>>>>>> @@ -213,6 +213,7 @@
> >>>>>>>     LIBAWT_CFLAGS += -fgcse-after-reload
> >>>>>>>   endif
> >>>>>>>
> >>>>>>>
> >>>>>>>   $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
> >>>>>>>       NAME := awt, \
> >>>>>>>       SRC := $(LIBAWT_DIRS), \
> >>>>>>> @@ -224,7 +225,7 @@
> >>>>>>>           format-nonliteral parentheses, \
> >>>>>>>       DISABLED_WARNINGS_clang := logical-op-parentheses extern-
> >>>>> initializer,
> >>>>>> \
> >>>>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
> >>>>>>> -    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
> >>>>>>> +    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
> >>>>>>>       ASFLAGS := $(LIBAWT_ASFLAGS), \
> >>>>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) $(call
> >>>>>>> SET_SHARED_LIBRARY_ORIGIN),
> >>>>> \
> >>>>>>>       LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
> >>>>>>> diff -r 12fe57c319e1
> >>>>>>>
> >>>>>
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> >>>>>>> ---
> >>>>>>>
> >>>>>
> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> >>>>>>> pp    Tue Apr 10 11:02:09 2018 +0800
> >>>>>>> +++
> >>>>>>>
> >>>>>
> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> >>>>>>> pp    Mon Jun 04 09:18:03 2018 +0200
> >>>>>>> @@ -85,7 +85,13 @@
> >>>>>>>           *pNpoints = outpoints;
> >>>>>>>       }
> >>>>>>>       if (outpoints > POLYTEMPSIZE) {
> >>>>>>> -        pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> >>>>>>> sizeof(POINT), outpoints);
> >>>>>>> +        try {
> >>>>>>> +            pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> >>>>>>> sizeof(POINT), outpoints);
> >>>>>>> +        } catch (const std::bad_alloc&) {
> >>>>>>> +            return NULL;
> >>>>>>> +        }
> >>>>>>>       }
> >>>>>>>       BOOL isempty = fixend;
> >>>>>>>       for (int i = 0; i < npoints; i++) {
> >>>>>>> diff -r 12fe57c319e1
> >>>>>>>
> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> >>>>>>> ---
> >>>>>
> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> >>>>>>> Tue Apr 10 11:02:09 2018 +0800
> >>>>>>> +++
> >>>>>>
> b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> >>>>>>> Mon Jun 04 09:18:03 2018 +0200
> >>>>>>> @@ -873,7 +873,12 @@
> >>>>>>>         int numSizes = ::DeviceCapabilities(printerName,
> >>>>>>> printerPort,
> >>>>>>>                                             DC_PAPERS, NULL, NULL);
> >>>>>>>         if (numSizes > 0) {
> >>>>>>> -          LPTSTR papers =
> >>>>>>> (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> >>>>>>> numSizes, sizeof(WORD));
> >>>>>>> +          LPTSTR papers;
> >>>>>>> +          try {
> >>>>>>> +              papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> >>>>>> numSizes,
> >>>>>>> sizeof(WORD));
> >>>>>>> +          } catch (const std::bad_alloc&) {
> >>>>>>> +              papers = NULL;
> >>>>>>> +          }
> >>>>>>>             if (papers != NULL &&
> >>>>>>>                 ::DeviceCapabilities(printerName, printerPort,
> >>>>>>>                                      DC_PAPERS, papers, NULL) !=
> >>>>>>> -1) {
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Baesken, Matthias
> >>>>>>>> Sent: Freitag, 1. Juni 2018 14:18
> >>>>>>>> To: 'Thomas St?fe' <thomas.stuefe at gmail.com>
> >>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> >>>>>>>> <christoph.langer at sap.com>
> >>>>>>>> Subject: RE: RFR: JDK-8204211: windows : handle potential C++
> >>>>> exception
> >>>>>> in
> >>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> >>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >>>>>>>>
> >>>>>>>> Hi  Thomas ,  using the  const-reference  sounds like a good
> >>>>>>>> idea  ( I just
> >>>>>>>> copied from  other locations in  the source code where (almost?)
> >>>>> always
> >>>>>>>> std::bad_alloc& (non-const)  is caught .
> >>>>>>>>
> >>>>>>>> For example :
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> alloc.h 170 } catch (std::bad_alloc&) { \
> >>>>>>>> 177 } catch (std::bad_alloc&) { \
> >>>>>>>> 200 } catch (std::bad_alloc&) { \
> >>>>>>>> 206 } catch (std::bad_alloc&) { \
> >>>>>>>>
> >>>>>>>>   awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
> >>>>>>>> 247 } catch (std::bad_alloc&) {
> >>>>>>>> 317 } catch (std::bad_alloc&) {
> >>>>>>>> 372 } catch (std::bad_alloc&) {
> >>>>>>>> 407 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>>   awt_DnDDT.cpp 203 } catch (std::bad_alloc&) {
> >>>>>>>> 264 } catch (std::bad_alloc&) {
> >>>>>>>> 305 } catch (std::bad_alloc&) {
> >>>>>>>> 366 } catch (std::bad_alloc&) {
> >>>>>>>> 582 } catch (std::bad_alloc&) {
> >>>>>>>> 635 } catch (std::bad_alloc&) {
> >>>>>>>> 653 } catch (std::bad_alloc&) {
> >>>>>>>> 698 } catch (std::bad_alloc&) {
> >>>>>>>> 739 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>>   awt_Desktop.cpp 148 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>> WPrinterJob.cpp 166 } catch (std::bad_alloc&) {
> >>>>>>>> 345 } catch (std::bad_alloc&) {
> >>>>>>>> 425 } catch (std::bad_alloc&) {
> >>>>>>>> 488 } catch (std::bad_alloc&) {
> >>>>>>>> 631 } catch (std::bad_alloc&) {
> >>>>>>>> 709 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>>   awt_ole.h 158 } catch (std::bad_alloc&) {\
> >>>>>>>>
> >>>>>>>>   awt_DesktopProperties.cpp 125 catch (std::bad_alloc&) {
> >>>>>>>> 269 catch (std::bad_alloc&) {
> >>>>>>>> 647 catch (std::bad_alloc&) {
> >>>>>>>> 664 catch (std::bad_alloc&) {
> >>>>>>>> 689 catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>>   awt_PrintDialog.cpp 225 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>>   awt_DataTransferer.cpp 310 } catch (std::bad_alloc&) {
> >>>>>>>> 724 } catch (std::bad_alloc &) {
> >>>>>>>> 792 } catch (std::bad_alloc &) {
> >>>>>>>>
> >>>>>>>>   awt_MenuItem.cpp 328 } catch (std::bad_alloc&) {
> >>>>>>>> 348 } catch (std::bad_alloc&) {
> >>>>>>>> 524 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>>   ShellFolder2.cpp 1410 } catch (std::bad_alloc&) {
> >>>>>>>> 1435 } catch (std::bad_alloc&) {
> >>>>>>>>
> >>>>>>>> ...
> >>>>>>>>
> >>>>>>>> Best regards, Matthias
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> >>>>>>>>> Sent: Freitag, 1. Juni 2018 12:02
> >>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>; Langer, Christoph
> >>>>>>>>> <christoph.langer at sap.com>
> >>>>>>>>> Subject: Re: RFR: JDK-8204211: windows : handle potential C++
> >>>>>> exception
> >>>>>>> in
> >>>>>>>>> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> >>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >>>>>>>>>
> >>>>>>>>> Hi Matthias,
> >>>>>>>>>
> >>>>>>>>> Please consider catching all exceptions, not just std::alloc:
> >>>>>>>>>
> >>>>>>>>> } catch (...) { return NULL; }
> >>>>>>>>>
> >>>>>>>>> and doing it at the exit extern "C" function, not somewhere
> >>>>>>>>> internally. Regardless of which exceptions get thrown around
> >>>>>>>>> below
> >>>>>> you
> >>>>>>>>> and by whom, you are safe that way.
> >>>>>>>>>
> >>>>>>>>> However, if you want to keep your patch as it is, please catch at
> >>>>>>>>> least as const reference:
> >>>>>>>>>
> >>>>>>>>> } catch (const std::bad_alloc&) {}
> >>>>>>>>>
> >>>>>>>>> Fine otherwise. I do not need another webrev.
> >>>>>>>>>
> >>>>>>>>> Best Regards, Thomas
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Jun 1, 2018 at 10:39 AM, Baesken, Matthias
> >>>>>>>>> <matthias.baesken at sap.com> wrote:
> >>>>>>>>>> Hi Thomas , thanks for the feedback.
> >>>>>>>>>> I created a bug and change for the excpetion handling in
> >>>>>>>> GDIRenderer.cpp
> >>>>>>>>> .
> >>>>>>>>>> Please review .
> >>>>>>>>>>
> >>>>>>>>>> Thanks,  Matthias
> >>>>>>>>>>
> >>>>>>>>>> Bug:
> >>>>>>>>>>
> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204211
> >>>>>>>>>>
> >>>>>>>>>> JDK-8204211: windows : handle potential C++ exception in
> >>>>>> GDIRenderer
> >>>>>>>>>>
> >>>>>>>>>> Change :
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8204211/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> >>>>>>>>>>> Sent: Mittwoch, 30. Mai 2018 17:37
> >>>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>>>>>>>>>> Cc: 2d-dev <2d-dev at openjdk.java.net>
> >>>>>>>>>>> Subject: Re: [OpenJDK 2D-Dev] java2d coding using
> >>>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >>>>>>>>>>>
> >>>>>>>>>>> Letting c++ exceptions escape from extern "C" functions is
> >>>>>>>>>>> UB and
> >>>>>>> may
> >>>>>>>>>>> (and probably will) crash the process. This should be fixed.
> >>>>> Approach
> >>>>>>>>>>> taken by JDK-8039394 is fine (I would probably catch every
> C++
> >>>>>>>>>>> exception with catch(...), not just bad_alloc, just to be
> >>>>>>>>>>> safe).
> >>>>>>>>>>>
> >>>>>>>>>>> Best Regards, Thomas
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias
> >>>>>>>>>>> <matthias.baesken at sap.com> wrote:
> >>>>>>>>>>>> Hello ,  there is still some  java2d coding  where
> >>>>>>>>> SAFE_SIZE_ARRAY_ALLOC /
> >>>>>>>>>>>> safe_Malloc    is used and  the  (potentially occurring)
> >>>>>>>>>>>> exception
> >>>>> is
> >>>>>>> not
> >>>>>>>>>>>> handled .
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> This leads to  CL warnings  (when enabled  ) like
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> " function assumed not to throw an exception but does ; The
> >>>>>>> function
> >>>>>>>> is
> >>>>>>>>>>>> extern "C" and /EHc was specified"
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Example :
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> static POINT *TransformPoly()
> >>>>>>>>>>>>
> >>>>>>>>>>>>    ?..
> >>>>>>>>>>>>
> >>>>>>>>>>>>      if (outpoints > POLYTEMPSIZE) {
> >>>>>>>>>>>>
> >>>>>>>>>>>>          pPoints = (POINT *)
> >>>>>>>>>>>> SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> >>>>>>>>>>>> sizeof(POINT), outpoints);
> >>>>>>>>>>>>
> >>>>>>>>>>>>      }
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Should  we add exception handling   here ?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Similar fixes were done  in the change 8039394: Compiler
> >>>>> warnings
> >>>>>>>>> about
> >>>>>>>>>>> C++
> >>>>>>>>>>>> exceptions in windows printing code
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039394
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best regards, Matthias
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>
> >>
> >
> >


From christoph.langer at sap.com  Thu Jun  7 11:43:54 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Jun 2018 11:43:54 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <df157ca405572a36ba591d21275e2752@linux.vnet.ibm.com>
References: <0c73caec8810b9844a463343bdaec064@linux.vnet.ibm.com>
 <ad8328a48b824282b40bf5293e7fade0@sap.com>
 <81453d0cbe05477ea558917de263ada2@sap.com>
 <df157ca405572a36ba591d21275e2752@linux.vnet.ibm.com>
Message-ID: <91ad0c1765a44b90bed87ae0fb61ae09@sap.com>

Hi Ichiroh,

your proposal seems to make sense. I have created a bug for this: https://bugs.openjdk.java.net/browse/JDK-8204541

Can you please generate a webrev (referencing this bug, -c option of webrev.ksh) and mail it over to me. Then I'll upload it and you can post an official RFR mail.

Best regards
Christoph

> -----Original Message-----
> From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> Sent: Dienstag, 5. Juni 2018 08:59
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> Goetz <goetz.lindenmaier at sap.com>
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
> 
> Hello Matthias and Christoph.
> Thank you for your explanations.
> 
> I did not have enough knowledge about "visibility".
> 
> I created following patches.
> 
> ================================
> diff -r 02934b0d661b
> src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Wed
> May
> 30 14:46:28 2018 +0200
> +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Tue Jun
> 05 12:10:41 2018 +0900
> @@ -39,7 +39,9 @@
>   #include "imageFile.hpp"
>   #include "inttypes.hpp"
>   #include "jimage.hpp"
> +#if !defined(_AIX)
>   #include "osSupport.hpp"
> +#endif
> 
>   #include "jdk_internal_jimage_NativeImageBuffer.h"
> 
> diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
> --- a/src/java.base/unix/native/include/jni_md.h	Wed May 30 14:46:28
> 2018 +0200
> +++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05 12:10:41
> 2018 +0900
> @@ -29,7 +29,8 @@
>   #ifndef __has_attribute
>     #define __has_attribute(x) 0
>   #endif
> -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
> (__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
> +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
> (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \
> +    || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
>     #ifdef ARM
>       #define JNIEXPORT
> __attribute__((externally_visible,visibility("default")))
>       #define JNIIMPORT
> __attribute__((externally_visible,visibility("default")))
> ================================
> 
> If "osSupport.hpp" was included, XLC++ compiler complained.
> I could not understand, which part was invalid...
> I'm not sure, "osSupport.hpp" is really required on
> NativeImageBuffer.cpp or not...
> 
> I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h. [1]
> 0xD01 means 13.1 by hexadecimal.
> 
> I checked symbol table by "dump -Tv -X64". [2]
> It seemed it was fine, some symbols were hidden.
> 
> Does someone review my code?
> 
> [1]
> https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i
> bm.xlc1313.aix.doc/compiler_ref/xlmacros.html
> [2]
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> visibility/index.html
> 
> On 2018-06-01 21:12, Baesken, Matthias wrote:
> > 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 <takiguc at linux.vnet.ibm.com>
> >> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> >> Goetz <goetz.lindenmaier at sap.com>
> >> 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:takiguc at linux.vnet.ibm.com]
> >> > Sent: Donnerstag, 31. Mai 2018 09:55
> >> > To: Langer, Christoph <christoph.langer at sap.com>
> >> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> >> > Goetz <goetz.lindenmaier at sap.com>
> >> > 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 <christoph.langer at sap.com>;
> >> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
> >> > > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> > > 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
> >> > > <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
> >> > > 'build-dev at openjdk.java.net'
> >> > > <build-dev at openjdk.java.net<mailto:build-
> dev at openjdk.java.net>>;
> >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> >> > dev at openjdk.java.net>;
> >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> >> dev at openjdk.java.net>
> >> > > Cc: Simonis, Volker
> >> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
> >> > > <build-dev at openjdk.java.net<mailto:build-
> dev at openjdk.java.net>>;
> >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> >> > dev at openjdk.java.net>;
> >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> >> dev at openjdk.java.net>
> >> > > Cc: Langer, Christoph
> >> > > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
> >> Simonis,
> >> > > Volker <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
> >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> >> > >
> >> > >
> >> > > So it is better to avoid  setting these flags when using xlc12.1   .
> >> > > Please review :
> >> > >
> >> > > Bug :
> >> > >
> >> > > https://bugs.openjdk.java.net/browse/JDK-8202322
> >> > >
> >> > > Change :
> >> > >
> >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
> >> > >
> >> > >
> >> > > Best regards, Matthias


From takiguc at linux.vnet.ibm.com  Thu Jun  7 12:53:06 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 07 Jun 2018 21:53:06 +0900
Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags
Message-ID: <5928b735dc946ef140d3ccdf3852dc1f@linux.vnet.ibm.com>

Hello.

Could you review it ?
Bug:    https://bugs.openjdk.java.net/browse/JDK-8204541
Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

-------- Original Message --------
Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on 
xlc 12.1
Date: 2018-06-07 20:43
 From: "Langer, Christoph" <christoph.langer at sap.com>
To: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
Cc: "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>, 
"ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, 
"core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>, 
"Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Baesken, Matthias" 
<matthias.baesken at sap.com>

Hi Ichiroh,

your proposal seems to make sense. I have created a bug for this: 
https://bugs.openjdk.java.net/browse/JDK-8204541

Can you please generate a webrev (referencing this bug, -c option of 
webrev.ksh) and mail it over to me. Then I'll upload it and you can post 
an official RFR mail.

Best regards
Christoph

> -----Original Message-----
> From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> Sent: Dienstag, 5. Juni 2018 08:59
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> Goetz <goetz.lindenmaier at sap.com>
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on 
> xlc 12.1
> 
> Hello Matthias and Christoph.
> Thank you for your explanations.
> 
> I did not have enough knowledge about "visibility".
> 
> I created following patches.
> 
> ================================
> diff -r 02934b0d661b
> src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Wed
> May
> 30 14:46:28 2018 +0200
> +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Tue 
> Jun
> 05 12:10:41 2018 +0900
> @@ -39,7 +39,9 @@
>   #include "imageFile.hpp"
>   #include "inttypes.hpp"
>   #include "jimage.hpp"
> +#if !defined(_AIX)
>   #include "osSupport.hpp"
> +#endif
> 
>   #include "jdk_internal_jimage_NativeImageBuffer.h"
> 
> diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
> --- a/src/java.base/unix/native/include/jni_md.h	Wed May 30 14:46:28
> 2018 +0200
> +++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05 12:10:41
> 2018 +0900
> @@ -29,7 +29,8 @@
>   #ifndef __has_attribute
>     #define __has_attribute(x) 0
>   #endif
> -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
> (__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
> +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
> (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \
> +    || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
>     #ifdef ARM
>       #define JNIEXPORT
> __attribute__((externally_visible,visibility("default")))
>       #define JNIIMPORT
> __attribute__((externally_visible,visibility("default")))
> ================================
> 
> If "osSupport.hpp" was included, XLC++ compiler complained.
> I could not understand, which part was invalid...
> I'm not sure, "osSupport.hpp" is really required on
> NativeImageBuffer.cpp or not...
> 
> I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h. 
> [1]
> 0xD01 means 13.1 by hexadecimal.
> 
> I checked symbol table by "dump -Tv -X64". [2]
> It seemed it was fine, some symbols were hidden.
> 
> Does someone review my code?
> 
> [1]
> https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i
> bm.xlc1313.aix.doc/compiler_ref/xlmacros.html
> [2]
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> visibility/index.html
> 
> On 2018-06-01 21:12, Baesken, Matthias wrote:
> > 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 <takiguc at linux.vnet.ibm.com>
> >> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> >> Goetz <goetz.lindenmaier at sap.com>
> >> 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:takiguc at linux.vnet.ibm.com]
> >> > Sent: Donnerstag, 31. Mai 2018 09:55
> >> > To: Langer, Christoph <christoph.langer at sap.com>
> >> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> >> > Goetz <goetz.lindenmaier at sap.com>
> >> > 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 <christoph.langer at sap.com>;
> >> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
> >> > > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> > > 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
> >> > > <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
> >> > > 'build-dev at openjdk.java.net'
> >> > > <build-dev at openjdk.java.net<mailto:build-
> dev at openjdk.java.net>>;
> >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> >> > dev at openjdk.java.net>;
> >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> >> dev at openjdk.java.net>
> >> > > Cc: Simonis, Volker
> >> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
> >> > > <build-dev at openjdk.java.net<mailto:build-
> dev at openjdk.java.net>>;
> >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> >> > dev at openjdk.java.net>;
> >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> >> dev at openjdk.java.net>
> >> > > Cc: Langer, Christoph
> >> > > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
> >> Simonis,
> >> > > Volker <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
> >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> >> > >
> >> > >
> >> > > So it is better to avoid  setting these flags when using xlc12.1   .
> >> > > Please review :
> >> > >
> >> > > Bug :
> >> > >
> >> > > https://bugs.openjdk.java.net/browse/JDK-8202322
> >> > >
> >> > > Change :
> >> > >
> >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
> >> > >
> >> > >
> >> > > Best regards, Matthias



From christoph.langer at sap.com  Thu Jun  7 13:06:42 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Jun 2018 13:06:42 +0000
Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility
 flags
In-Reply-To: <5928b735dc946ef140d3ccdf3852dc1f@linux.vnet.ibm.com>
References: <5928b735dc946ef140d3ccdf3852dc1f@linux.vnet.ibm.com>
Message-ID: <dcad5762ed86454b863fce72eea59aa7@sap.com>

Hi Ichiroh,

what's the exact error message if you  #include "osSupport.hpp"? (I have no xlC 13 at hand to try myself...)

Best regards
Christoph

> -----Original Message-----
> From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> Sent: Donnerstag, 7. Juni 2018 14:53
> To: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; core-
> libs-dev at openjdk.java.net
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags
> 
> Hello.
> 
> Could you review it ?
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8204541
> Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> -------- Original Message --------
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> xlc 12.1
> Date: 2018-06-07 20:43
>  From: "Langer, Christoph" <christoph.langer at sap.com>
> To: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> Cc: "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>,
> "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> dev at openjdk.java.net>,
> "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>,
> "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Baesken, Matthias"
> <matthias.baesken at sap.com>
> 
> Hi Ichiroh,
> 
> your proposal seems to make sense. I have created a bug for this:
> https://bugs.openjdk.java.net/browse/JDK-8204541
> 
> Can you please generate a webrev (referencing this bug, -c option of
> webrev.ksh) and mail it over to me. Then I'll upload it and you can post
> an official RFR mail.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> > Sent: Dienstag, 5. Juni 2018 08:59
> > To: Baesken, Matthias <matthias.baesken at sap.com>
> > Cc: Langer, Christoph <christoph.langer at sap.com>; 'build-
> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> > Goetz <goetz.lindenmaier at sap.com>
> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> > xlc 12.1
> >
> > Hello Matthias and Christoph.
> > Thank you for your explanations.
> >
> > I did not have enough knowledge about "visibility".
> >
> > I created following patches.
> >
> > ================================
> > diff -r 02934b0d661b
> > src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> > --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Wed
> > May
> > 30 14:46:28 2018 +0200
> > +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> 	Tue
> > Jun
> > 05 12:10:41 2018 +0900
> > @@ -39,7 +39,9 @@
> >   #include "imageFile.hpp"
> >   #include "inttypes.hpp"
> >   #include "jimage.hpp"
> > +#if !defined(_AIX)
> >   #include "osSupport.hpp"
> > +#endif
> >
> >   #include "jdk_internal_jimage_NativeImageBuffer.h"
> >
> > diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
> > --- a/src/java.base/unix/native/include/jni_md.h	Wed May 30 14:46:28
> > 2018 +0200
> > +++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05 12:10:41
> > 2018 +0900
> > @@ -29,7 +29,8 @@
> >   #ifndef __has_attribute
> >     #define __has_attribute(x) 0
> >   #endif
> > -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
> > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
> > +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
> > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \
> > +    || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
> >     #ifdef ARM
> >       #define JNIEXPORT
> > __attribute__((externally_visible,visibility("default")))
> >       #define JNIIMPORT
> > __attribute__((externally_visible,visibility("default")))
> > ================================
> >
> > If "osSupport.hpp" was included, XLC++ compiler complained.
> > I could not understand, which part was invalid...
> > I'm not sure, "osSupport.hpp" is really required on
> > NativeImageBuffer.cpp or not...
> >
> > I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h.
> > [1]
> > 0xD01 means 13.1 by hexadecimal.
> >
> > I checked symbol table by "dump -Tv -X64". [2]
> > It seemed it was fine, some symbols were hidden.
> >
> > Does someone review my code?
> >
> > [1]
> >
> https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i
> > bm.xlc1313.aix.doc/compiler_ref/xlmacros.html
> > [2]
> > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> > visibility/index.html
> >
> > On 2018-06-01 21:12, Baesken, Matthias wrote:
> > > 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 <takiguc at linux.vnet.ibm.com>
> > >> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> > >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> > >> Goetz <goetz.lindenmaier at sap.com>
> > >> 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:takiguc at linux.vnet.ibm.com]
> > >> > Sent: Donnerstag, 31. Mai 2018 09:55
> > >> > To: Langer, Christoph <christoph.langer at sap.com>
> > >> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> > >> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> > >> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
> Lindenmaier,
> > >> > Goetz <goetz.lindenmaier at sap.com>
> > >> > 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 <christoph.langer at sap.com>;
> > >> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
> > >> > > ppc-aix-port-dev at openjdk.java.net; core-libs-
> dev at openjdk.java.net
> > >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > >> > > 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
> > >> > >
> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
> > >> > > 'build-dev at openjdk.java.net'
> > >> > > <build-dev at openjdk.java.net<mailto:build-
> > dev at openjdk.java.net>>;
> > >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> > >> > dev at openjdk.java.net>;
> > >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> > >> dev at openjdk.java.net>
> > >> > > Cc: Simonis, Volker
> > >> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
> > >> > > <build-dev at openjdk.java.net<mailto:build-
> > dev at openjdk.java.net>>;
> > >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> > >> > dev at openjdk.java.net>;
> > >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> > >> dev at openjdk.java.net>
> > >> > > Cc: Langer, Christoph
> > >> > > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
> > >> Simonis,
> > >> > > Volker
> <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
> > >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> > >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> > >> > >
> > >> > >
> > >> > > So it is better to avoid  setting these flags when using xlc12.1   .
> > >> > > Please review :
> > >> > >
> > >> > > Bug :
> > >> > >
> > >> > > https://bugs.openjdk.java.net/browse/JDK-8202322
> > >> > >
> > >> > > Change :
> > >> > >
> > >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
> > >> > >
> > >> > >
> > >> > > Best regards, Matthias


From takiguc at linux.vnet.ibm.com  Thu Jun  7 16:29:09 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 08 Jun 2018 01:29:09 +0900
Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility
 flags
In-Reply-To: <dcad5762ed86454b863fce72eea59aa7@sap.com>
References: <5928b735dc946ef140d3ccdf3852dc1f@linux.vnet.ibm.com>
 <dcad5762ed86454b863fce72eea59aa7@sap.com>
Message-ID: <29f9a3494ea8ebb6f5db05e4fb06fa30@linux.vnet.ibm.com>

Hello Christoph

According to build log, if <#include "osSupport.hpp"> was there:
"/home/jdktest/sandbox/jdk/build/aix-ppc64-normal-server-release/support/headers/java.base/jdk_internal_jimage_NativeImageBuffer.h", 
line 15.27: 1540-0040 (S) The text
  "Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap" is 
unexpected.  "visibility" may be undeclared or ambiguous.
make[3]: *** 
[/home/jdktest/sandbox/jdk/build/aix-ppc64-normal-server-release/support/native/java.base/libjimage/NativeImageBuffer.o] 
Error 1
make[3]: Leaving directory `/home/jdktest/sandbox/jdk/make'
make[2]: *** [java.base-libs] Error 2
make[2]: *** Waiting for unfinished jobs....

On 2018-06-07 22:06, Langer, Christoph wrote:
> Hi Ichiroh,
> 
> what's the exact error message if you  #include "osSupport.hpp"? (I
> have no xlC 13 at hand to try myself...)
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
>> Sent: Donnerstag, 7. Juni 2018 14:53
>> To: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 
>> core-
>> libs-dev at openjdk.java.net
>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>; Langer, Christoph
>> <christoph.langer at sap.com>
>> Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol 
>> visibility flags
>> 
>> Hello.
>> 
>> Could you review it ?
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8204541
>> Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> -------- Original Message --------
>> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support 
>> on
>> xlc 12.1
>> Date: 2018-06-07 20:43
>>  From: "Langer, Christoph" <christoph.langer at sap.com>
>> To: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
>> Cc: "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>,
>> "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
>> dev at openjdk.java.net>,
>> "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>,
>> "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Baesken, Matthias"
>> <matthias.baesken at sap.com>
>> 
>> Hi Ichiroh,
>> 
>> your proposal seems to make sense. I have created a bug for this:
>> https://bugs.openjdk.java.net/browse/JDK-8204541
>> 
>> Can you please generate a webrev (referencing this bug, -c option of
>> webrev.ksh) and mail it over to me. Then I'll upload it and you can 
>> post
>> an official RFR mail.
>> 
>> Best regards
>> Christoph
>> 
>> > -----Original Message-----
>> > From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
>> > Sent: Dienstag, 5. Juni 2018 08:59
>> > To: Baesken, Matthias <matthias.baesken at sap.com>
>> > Cc: Langer, Christoph <christoph.langer at sap.com>; 'build-
>> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
>> > Goetz <goetz.lindenmaier at sap.com>
>> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
>> > xlc 12.1
>> >
>> > Hello Matthias and Christoph.
>> > Thank you for your explanations.
>> >
>> > I did not have enough knowledge about "visibility".
>> >
>> > I created following patches.
>> >
>> > ================================
>> > diff -r 02934b0d661b
>> > src/java.base/share/native/libjimage/NativeImageBuffer.cpp
>> > --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Wed
>> > May
>> > 30 14:46:28 2018 +0200
>> > +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp
>> 	Tue
>> > Jun
>> > 05 12:10:41 2018 +0900
>> > @@ -39,7 +39,9 @@
>> >   #include "imageFile.hpp"
>> >   #include "inttypes.hpp"
>> >   #include "jimage.hpp"
>> > +#if !defined(_AIX)
>> >   #include "osSupport.hpp"
>> > +#endif
>> >
>> >   #include "jdk_internal_jimage_NativeImageBuffer.h"
>> >
>> > diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
>> > --- a/src/java.base/unix/native/include/jni_md.h	Wed May 30 14:46:28
>> > 2018 +0200
>> > +++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05 12:10:41
>> > 2018 +0900
>> > @@ -29,7 +29,8 @@
>> >   #ifndef __has_attribute
>> >     #define __has_attribute(x) 0
>> >   #endif
>> > -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
>> > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
>> > +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
>> > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \
>> > +    || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
>> >     #ifdef ARM
>> >       #define JNIEXPORT
>> > __attribute__((externally_visible,visibility("default")))
>> >       #define JNIIMPORT
>> > __attribute__((externally_visible,visibility("default")))
>> > ================================
>> >
>> > If "osSupport.hpp" was included, XLC++ compiler complained.
>> > I could not understand, which part was invalid...
>> > I'm not sure, "osSupport.hpp" is really required on
>> > NativeImageBuffer.cpp or not...
>> >
>> > I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h.
>> > [1]
>> > 0xD01 means 13.1 by hexadecimal.
>> >
>> > I checked symbol table by "dump -Tv -X64". [2]
>> > It seemed it was fine, some symbols were hidden.
>> >
>> > Does someone review my code?
>> >
>> > [1]
>> >
>> https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i
>> > bm.xlc1313.aix.doc/compiler_ref/xlmacros.html
>> > [2]
>> > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
>> > visibility/index.html
>> >
>> > On 2018-06-01 21:12, Baesken, Matthias wrote:
>> > > 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 <takiguc at linux.vnet.ibm.com>
>> > >> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> > >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
>> > >> Goetz <goetz.lindenmaier at sap.com>
>> > >> 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:takiguc at linux.vnet.ibm.com]
>> > >> > Sent: Donnerstag, 31. Mai 2018 09:55
>> > >> > To: Langer, Christoph <christoph.langer at sap.com>
>> > >> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> > >> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> > >> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
>> Lindenmaier,
>> > >> > Goetz <goetz.lindenmaier at sap.com>
>> > >> > 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 <christoph.langer at sap.com>;
>> > >> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
>> > >> > > ppc-aix-port-dev at openjdk.java.net; core-libs-
>> dev at openjdk.java.net
>> > >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> > >> > > 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
>> > >> > >
>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
>> > >> > > 'build-dev at openjdk.java.net'
>> > >> > > <build-dev at openjdk.java.net<mailto:build-
>> > dev at openjdk.java.net>>;
>> > >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
>> > >> > dev at openjdk.java.net>;
>> > >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
>> > >> dev at openjdk.java.net>
>> > >> > > Cc: Simonis, Volker
>> > >> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
>> > >> > > <build-dev at openjdk.java.net<mailto:build-
>> > dev at openjdk.java.net>>;
>> > >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
>> > >> > dev at openjdk.java.net>;
>> > >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
>> > >> dev at openjdk.java.net>
>> > >> > > Cc: Langer, Christoph
>> > >> > > <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
>> > >> Simonis,
>> > >> > > Volker
>> <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
>> > >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
>> > >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>> > >> > >
>> > >> > >
>> > >> > > So it is better to avoid  setting these flags when using xlc12.1   .
>> > >> > > Please review :
>> > >> > >
>> > >> > > Bug :
>> > >> > >
>> > >> > > https://bugs.openjdk.java.net/browse/JDK-8202322
>> > >> > >
>> > >> > > Change :
>> > >> > >
>> > >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
>> > >> > >
>> > >> > >
>> > >> > > Best regards, Matthias



From jesper.wilhelmsson at oracle.com  Thu Jun  7 18:56:13 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 7 Jun 2018 20:56:13 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
Message-ID: <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>

> On 6 Jun 2018, at 06:17, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Erik, Jesper,
> 
> On 6/06/2018 2:59 AM, jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com> wrote:
>>> On 5 Jun 2018, at 08:10, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Sorry to be late to this party ...
>>> 
>>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>>> Renamed the new jvm variant to "hardened".
>>> 
>>> As it is a hardened server build I'd prefer if that were somehow reflected in the name. Though really I don't see why this should be restricted this way ... to be honest I don't see hardened as a variant of server vs. client vs. zero etc at all, you should be able to harden any of those.
>>> 
>>> So IIUC with this change we will:
>>> - always build JDK native code "hardened" (if toolchain supports it)
>>> - only build hotspot "hardened" if requested; and in that case
>>>  - jvm.cfg will list -server and -hardened with server as default
>>> 
>>> Is that right? I can see that we may choose to always build Oracle JDK this way but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot is selectable but JDK is not. ??
>> Sorry for the lack of information here. There has been a lot of off-list discussions behind this change, I've added the background to the bug now.
>> The short version is that we see a ~25% regression in startup times if the JVM is compiled with the gcc flags to avoid speculative execution. We have not observed any performance regressions due to compiling the rest of the native libraries with these gcc flags, so there doesn't seem to be any reason to have different versions of other libraries.
> 
> So "benevolent dictatorship"?  ;-)
> 
> My main concern is that the updated toolchains that support this have all been produced in a mad rush and quite frankly I expect them to be buggy. I don't think it is hard to enable the builder of OpenJDK to have full choice and control here.

My assumption has been, and still is, that we're not the only ones that will use gcc 7.3.0 with these flags. If there were bugs in the new code they would most likely have been found already. The experience from our own work in this area is that the bugs are unlikely to be crashes due to the new code, but rather weird corner cases where the new code is not inserted where it was needed, leaving speculative execution unblocked in that single case.

That said, I have no strong opinions on what is possible to configure in the build, as long as the Oracle OpenJDK builds comes with two JVM libraries and one copy of all other libraries. But that is of course a slightly different issue as long as it is possible to do.

Thanks,
/Jesper

> 
> Cheers,
> David
> 
>> /Jesper
>>> Sorry.
>>> 
>>> David
>>> -----
>>> 
>>>> /Erik
>>>> On 2018-06-04 09:54, jesper.wilhelmsson at oracle.com wrote:
>>>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>>>>>> 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?
>>>>>> I don't know. I'm open to suggestions on naming.
>>>>> "hardened" sounds good to me.
>>>>> 
>>>>> The change looks good as well.
>>>>> /Jesper
>>>>> 
>>>>>> /Erik
>>>>>>> -Aleksey



From erik.joelsson at oracle.com  Thu Jun  7 20:11:55 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 7 Jun 2018 13:11:55 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
Message-ID: <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>



On 2018-06-07 11:56, jesper.wilhelmsson at oracle.com wrote:
>> On 6 Jun 2018, at 06:17, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Hi Erik, Jesper,
>>
>>
>> So "benevolent dictatorship"? ?;-)
>>
>> My main concern is that the updated toolchains that support this have 
>> all been produced in a mad rush and quite frankly I expect them to be 
>> buggy. I don't think it is hard to enable the builder of OpenJDK to 
>> have full choice and control here.
>
> My assumption has been, and still is, that we're not the only ones 
> that will use gcc 7.3.0 with these flags. If there were bugs in the 
> new code they would most likely have been found already. The 
> experience from our own work in this area is that the bugs are 
> unlikely to be crashes due to the new code, but rather weird corner 
> cases where the new code is not inserted where it was needed, leaving 
> speculative execution unblocked in that single case.
>
> That said, I have no strong opinions on what is possible to configure 
> in the build, as long as the Oracle OpenJDK builds comes with two JVM 
> libraries and one copy of all other libraries. But that is of course a 
> slightly different issue as long as it is possible to do.
>
I just don't think the extra work is warranted or should be prioritized 
at this point. I also cannot think of a combination of options required 
for what you are suggesting that wouldn't be confusing to the user. If 
someone truly feels like these flags are forced on them and can't live 
with them, we or preferably that person can fix it then. I don't think 
that's dictatorship. OpenJDK is still open source and anyone can contribute.

/Erik



From magnus.ihse.bursie at oracle.com  Thu Jun  7 20:22:48 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 7 Jun 2018 22:22:48 +0200
Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags
 automatically
Message-ID: <e6fd26e9-ff40-4e4c-ba0b-97afd4279822@oracle.com>

This change needs some background information.

I've been working on simplifying and streamlining the compilation of 
native libraries of the JDK. Previously, I introduced the 
SetupJdkLibrary function, and started to get a better control of 
compiler flags. This patch continues on both paths.

The original intent of this change, which I naively thought was going to 
be much simpler than it turned out :-) was to separate the -I flags 
(location of header files) from other flags, and to generate these 
automatically, wherever possible. Since we have a standard way of 
locating native code, and most libraries just want to have an -I path to 
their own source base and the generated Java header, we should be able 
to provide this in SetupJdkLibrary.

This turned out to be closely related to SetupJdkLibrary being able to 
discover the location of the SRC directories itself, using "convention 
over configuration" and assuming that the library "libfoo" for 
"java.module" would be located in java.module/*/native/libfoo.

While this sounds simple in theory, when actually trying to implement 
this I of course ran into all the places where some special handling was 
indeed needed. So even if like 90% of all libraries were simple to get 
to build using automated discovery of source and header directories, the 
10% that did not caused me much more headaches than I had anticipated. 
On the other hand, now that I've sorted out all those places, the few 
remaining odd solutions is clearly documented and not just something 
that "just happens" due to strange configurations.

One file deserves mentioning specifically: Awt2dLibraries.gmk. The 
java.desktop libraries are unfortunately quite entangled with each 
other, and do not readily follow the patterns that are used elsewhere in 
the code base. So it might just look like the file has just gone from 
one state of messiness, to another, which would hardly be an 
improvement. :-( I would still argue that the new messiness is better: 
It is now much clearer in what ways the libraries diverge from our 
standard assumption, and what course of action needs to be taken to 
minimize these differences. (Which is something I believe should be done 
-- these issues are not just cosmetic but is the root of most of the 
issues we always see for these libraries, when upgrading compilers, etc.)

During this change, I noticed that not all native libraries include the 
proper generated header file. This is a dangerous coding practice, since 
a change in the Java part of the interface might not get picked up 
properly in the native part. I've added the missing includes that I've 
detected, and due to these changes, I'm also including the component 
teams in what is really only a build change. As can be seen for 
jdk.crypto.mscapi; there had indeed been changes that needed correcting.

Since this is (basically) a pure build change, my gold standard here has 
been the build compare script. In essence, the build output prior to my 
change and with this change are 100% identical. In truth, this is a bit 
too strong a claim. A few changes has occurred, but none of them should 
matter. Here's a breakdown of the compare.sh results:

* Windows-x64:

No differences at all.

* Solaris:

Two libraries are reported to differ: libsaproc.so and 
libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing 
this, I found that the object files used to link these two libraries has 
no disass differences. They have a slight binary difference and a 
difference in size, due to the include paths being different (and this 
is stored in the .o file, which makes it different). Somehow this 
apparently triggers the linker to generate a slightly different code in 
a few places, using a different register or so. (Weird...)

* MacOS:

Two libraries are reported to differ: libjava.dylib and 
libmlib_image.dylib, both of them just reported as a binary diff (no 
symbol, disass or fulldump differences). This is not really unsuspected, 
but I analyzed it anyway.

I found that for libjava.dylib, a single .o file was different. This one 
was actually picked up from closed sources, and are not really relevant 
for OpenJDK. Anyway, the reason for the difference was the same as for 
the Solaris libs; the include paths had changes, which caused a binary diff.

For libmlib_image.dylib, the link order had changed causing the noted 
binary difference.

* Linux:

On linux, the compare script noted differences for libextnet, libjava, 
libmlib_image, libprefs, libsaproc, libsplashscreen and libsunec.

The differences for libextnet, libprefs, libsplashscreen and libsunec 
turned out to be caused by the added #include of the generated Java 
headers. This caused binary differences (reasonably), and for some odd 
reason also a symbol difference in java_awt_SplashScreen.o (clazz.10057 
and mid.10058 were replaced by clazz.10015 and mid.10016). I can't claim 
to understand this, but I'm assuming it's some kind of generated code.

libsaproc and libjava changes was caused by closed source changes, and 
is therefore not relevant to OpenJDK.

For libmlib_image.dylib, the link order had changed causing the noted 
binary difference, as on MacOS.

Bug: https://bugs.openjdk.java.net/browse/JDK-8204572
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01

/Magnus



From erik.joelsson at oracle.com  Thu Jun  7 21:20:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 7 Jun 2018 14:20:52 -0700
Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I
 flags automatically
In-Reply-To: <e6fd26e9-ff40-4e4c-ba0b-97afd4279822@oracle.com>
References: <e6fd26e9-ff40-4e4c-ba0b-97afd4279822@oracle.com>
Message-ID: <eea6cb0b-dc41-7fd3-eb32-45740982b847@oracle.com>

Hello Magnus,

Very nice refactoring!

JdkNativeCompilation.gmk
line 126-127 looks a bit long. There is an extra space on 126. Also, why 
not addprefix for adding -I instead of clunky foreach? Not that I care 
greatly, but I usually prefer that construct.

Otherwise looks good.

/Erik


On 2018-06-07 13:22, Magnus Ihse Bursie wrote:
> This change needs some background information.
>
> I've been working on simplifying and streamlining the compilation of 
> native libraries of the JDK. Previously, I introduced the 
> SetupJdkLibrary function, and started to get a better control of 
> compiler flags. This patch continues on both paths.
>
> The original intent of this change, which I naively thought was going 
> to be much simpler than it turned out :-) was to separate the -I flags 
> (location of header files) from other flags, and to generate these 
> automatically, wherever possible. Since we have a standard way of 
> locating native code, and most libraries just want to have an -I path 
> to their own source base and the generated Java header, we should be 
> able to provide this in SetupJdkLibrary.
>
> This turned out to be closely related to SetupJdkLibrary being able to 
> discover the location of the SRC directories itself, using "convention 
> over configuration" and assuming that the library "libfoo" for 
> "java.module" would be located in java.module/*/native/libfoo.
>
> While this sounds simple in theory, when actually trying to implement 
> this I of course ran into all the places where some special handling 
> was indeed needed. So even if like 90% of all libraries were simple to 
> get to build using automated discovery of source and header 
> directories, the 10% that did not caused me much more headaches than I 
> had anticipated. On the other hand, now that I've sorted out all those 
> places, the few remaining odd solutions is clearly documented and not 
> just something that "just happens" due to strange configurations.
>
> One file deserves mentioning specifically: Awt2dLibraries.gmk. The 
> java.desktop libraries are unfortunately quite entangled with each 
> other, and do not readily follow the patterns that are used elsewhere 
> in the code base. So it might just look like the file has just gone 
> from one state of messiness, to another, which would hardly be an 
> improvement. :-( I would still argue that the new messiness is better: 
> It is now much clearer in what ways the libraries diverge from our 
> standard assumption, and what course of action needs to be taken to 
> minimize these differences. (Which is something I believe should be 
> done -- these issues are not just cosmetic but is the root of most of 
> the issues we always see for these libraries, when upgrading 
> compilers, etc.)
>
> During this change, I noticed that not all native libraries include 
> the proper generated header file. This is a dangerous coding practice, 
> since a change in the Java part of the interface might not get picked 
> up properly in the native part. I've added the missing includes that 
> I've detected, and due to these changes, I'm also including the 
> component teams in what is really only a build change. As can be seen 
> for jdk.crypto.mscapi; there had indeed been changes that needed 
> correcting.
>
> Since this is (basically) a pure build change, my gold standard here 
> has been the build compare script. In essence, the build output prior 
> to my change and with this change are 100% identical. In truth, this 
> is a bit too strong a claim. A few changes has occurred, but none of 
> them should matter. Here's a breakdown of the compare.sh results:
>
> * Windows-x64:
>
> No differences at all.
>
> * Solaris:
>
> Two libraries are reported to differ: libsaproc.so and 
> libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing 
> this, I found that the object files used to link these two libraries 
> has no disass differences. They have a slight binary difference and a 
> difference in size, due to the include paths being different (and this 
> is stored in the .o file, which makes it different). Somehow this 
> apparently triggers the linker to generate a slightly different code 
> in a few places, using a different register or so. (Weird...)
>
> * MacOS:
>
> Two libraries are reported to differ: libjava.dylib and 
> libmlib_image.dylib, both of them just reported as a binary diff (no 
> symbol, disass or fulldump differences). This is not really 
> unsuspected, but I analyzed it anyway.
>
> I found that for libjava.dylib, a single .o file was different. This 
> one was actually picked up from closed sources, and are not really 
> relevant for OpenJDK. Anyway, the reason for the difference was the 
> same as for the Solaris libs; the include paths had changes, which 
> caused a binary diff.
>
> For libmlib_image.dylib, the link order had changed causing the noted 
> binary difference.
>
> * Linux:
>
> On linux, the compare script noted differences for libextnet, libjava, 
> libmlib_image, libprefs, libsaproc, libsplashscreen and libsunec.
>
> The differences for libextnet, libprefs, libsplashscreen and libsunec 
> turned out to be caused by the added #include of the generated Java 
> headers. This caused binary differences (reasonably), and for some odd 
> reason also a symbol difference in java_awt_SplashScreen.o 
> (clazz.10057 and mid.10058 were replaced by clazz.10015 and 
> mid.10016). I can't claim to understand this, but I'm assuming it's 
> some kind of generated code.
>
> libsaproc and libjava changes was caused by closed source changes, and 
> is therefore not relevant to OpenJDK.
>
> For libmlib_image.dylib, the link order had changed causing the noted 
> binary difference, as on MacOS.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204572
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01
>
> /Magnus
>



From david.holmes at oracle.com  Fri Jun  8 00:30:20 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 8 Jun 2018 10:30:20 +1000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
Message-ID: <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>

On 8/06/2018 6:11 AM, Erik Joelsson wrote:
> On 2018-06-07 11:56, jesper.wilhelmsson at oracle.com wrote:
>>> On 6 Jun 2018, at 06:17, David Holmes <david.holmes at oracle.com 
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> Hi Erik, Jesper,
>>>
>>>
>>> So "benevolent dictatorship"? ?;-)
>>>
>>> My main concern is that the updated toolchains that support this have 
>>> all been produced in a mad rush and quite frankly I expect them to be 
>>> buggy. I don't think it is hard to enable the builder of OpenJDK to 
>>> have full choice and control here.
>>
>> My assumption has been, and still is, that we're not the only ones 
>> that will use gcc 7.3.0 with these flags. If there were bugs in the 
>> new code they would most likely have been found already. The 
>> experience from our own work in this area is that the bugs are 
>> unlikely to be crashes due to the new code, but rather weird corner 
>> cases where the new code is not inserted where it was needed, leaving 
>> speculative execution unblocked in that single case.
>>
>> That said, I have no strong opinions on what is possible to configure 
>> in the build, as long as the Oracle OpenJDK builds comes with two JVM 
>> libraries and one copy of all other libraries. But that is of course a 
>> slightly different issue as long as it is possible to do.
>>
> I just don't think the extra work is warranted or should be prioritized 
> at this point. I also cannot think of a combination of options required 
> for what you are suggesting that wouldn't be confusing to the user. If 
> someone truly feels like these flags are forced on them and can't live 
> with them, we or preferably that person can fix it then. I don't think 
> that's dictatorship. OpenJDK is still open source and anyone can contribute.

I don't see why --enable-hardened-jdk and --enable-hardened-hotspot to 
add to the right flags would be either complicated or confusing.

David

> /Erik
> 


From christoph.langer at sap.com  Fri Jun  8 07:35:48 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 8 Jun 2018 07:35:48 +0000
Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility
 flags
In-Reply-To: <29f9a3494ea8ebb6f5db05e4fb06fa30@linux.vnet.ibm.com>
References: <5928b735dc946ef140d3ccdf3852dc1f@linux.vnet.ibm.com>
 <dcad5762ed86454b863fce72eea59aa7@sap.com>
 <29f9a3494ea8ebb6f5db05e4fb06fa30@linux.vnet.ibm.com>
Message-ID: <a7ab27ce4f6944b3bf51fd993536f2d5@sap.com>

Hi Ichiroh,

Ok, so as per the output, via the include of osSupport.hpp, something must happen which undeclares "visibility" or makes it ambiguous. Looking at osSupport.hpp, I can't see anything special. It would just include pthread.h and declare some c++ classes.

You could try to get and analyze the preprocessed output of xlC by specifying the option -P or -E to the compile call. You will get the original xlC command line by calling 'cat support/native/java.base/libjimage/NativeImageBuffer.o.cmdline' in your build directory.

I think we should really understand what's happening there and fix it correctly instead of just excluding osSupport.hpp.

Best regards
Christoph

> -----Original Message-----
> From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> Sent: Donnerstag, 7. Juni 2018 18:29
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; core-
> libs-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>
> Subject: RE: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags
> 
> Hello Christoph
> 
> According to build log, if <#include "osSupport.hpp"> was there:
> "/home/jdktest/sandbox/jdk/build/aix-ppc64-normal-server-
> release/support/headers/java.base/jdk_internal_jimage_NativeImageBuffe
> r.h",
> line 15.27: 1540-0040 (S) The text
>   "Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap" is
> unexpected.  "visibility" may be undeclared or ambiguous.
> make[3]: ***
> [/home/jdktest/sandbox/jdk/build/aix-ppc64-normal-server-
> release/support/native/java.base/libjimage/NativeImageBuffer.o]
> Error 1
> make[3]: Leaving directory `/home/jdktest/sandbox/jdk/make'
> make[2]: *** [java.base-libs] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> On 2018-06-07 22:06, Langer, Christoph wrote:
> > Hi Ichiroh,
> >
> > what's the exact error message if you  #include "osSupport.hpp"? (I
> > have no xlC 13 at hand to try myself...)
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> >> Sent: Donnerstag, 7. Juni 2018 14:53
> >> To: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net;
> >> core-
> >> libs-dev at openjdk.java.net
> >> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken,
> Matthias
> >> <matthias.baesken at sap.com>; Langer, Christoph
> >> <christoph.langer at sap.com>
> >> Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol
> >> visibility flags
> >>
> >> Hello.
> >>
> >> Could you review it ?
> >> Bug:    https://bugs.openjdk.java.net/browse/JDK-8204541
> >> Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/
> >>
> >> Thanks,
> >> Ichiroh Takiguchi
> >> IBM Japan, Ltd.
> >>
> >> -------- Original Message --------
> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support
> >> on
> >> xlc 12.1
> >> Date: 2018-06-07 20:43
> >>  From: "Langer, Christoph" <christoph.langer at sap.com>
> >> To: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> >> Cc: "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>,
> >> "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> >> dev at openjdk.java.net>,
> >> "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>,
> >> "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Baesken,
> Matthias"
> >> <matthias.baesken at sap.com>
> >>
> >> Hi Ichiroh,
> >>
> >> your proposal seems to make sense. I have created a bug for this:
> >> https://bugs.openjdk.java.net/browse/JDK-8204541
> >>
> >> Can you please generate a webrev (referencing this bug, -c option of
> >> webrev.ksh) and mail it over to me. Then I'll upload it and you can
> >> post
> >> an official RFR mail.
> >>
> >> Best regards
> >> Christoph
> >>
> >> > -----Original Message-----
> >> > From: Ichiroh Takiguchi [mailto:takiguc at linux.vnet.ibm.com]
> >> > Sent: Dienstag, 5. Juni 2018 08:59
> >> > To: Baesken, Matthias <matthias.baesken at sap.com>
> >> > Cc: Langer, Christoph <christoph.langer at sap.com>; 'build-
> >> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Lindenmaier,
> >> > Goetz <goetz.lindenmaier at sap.com>
> >> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> >> > xlc 12.1
> >> >
> >> > Hello Matthias and Christoph.
> >> > Thank you for your explanations.
> >> >
> >> > I did not have enough knowledge about "visibility".
> >> >
> >> > I created following patches.
> >> >
> >> > ================================
> >> > diff -r 02934b0d661b
> >> > src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> >> > --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> 	Wed
> >> > May
> >> > 30 14:46:28 2018 +0200
> >> > +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp
> >> 	Tue
> >> > Jun
> >> > 05 12:10:41 2018 +0900
> >> > @@ -39,7 +39,9 @@
> >> >   #include "imageFile.hpp"
> >> >   #include "inttypes.hpp"
> >> >   #include "jimage.hpp"
> >> > +#if !defined(_AIX)
> >> >   #include "osSupport.hpp"
> >> > +#endif
> >> >
> >> >   #include "jdk_internal_jimage_NativeImageBuffer.h"
> >> >
> >> > diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
> >> > --- a/src/java.base/unix/native/include/jni_md.h	Wed May 30
> 14:46:28
> >> > 2018 +0200
> >> > +++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05
> 12:10:41
> >> > 2018 +0900
> >> > @@ -29,7 +29,8 @@
> >> >   #ifndef __has_attribute
> >> >     #define __has_attribute(x) 0
> >> >   #endif
> >> > -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4)
> &&
> >> > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
> >> > +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4)
> &&
> >> > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \
> >> > +    || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
> >> >     #ifdef ARM
> >> >       #define JNIEXPORT
> >> > __attribute__((externally_visible,visibility("default")))
> >> >       #define JNIIMPORT
> >> > __attribute__((externally_visible,visibility("default")))
> >> > ================================
> >> >
> >> > If "osSupport.hpp" was included, XLC++ compiler complained.
> >> > I could not understand, which part was invalid...
> >> > I'm not sure, "osSupport.hpp" is really required on
> >> > NativeImageBuffer.cpp or not...
> >> >
> >> > I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h.
> >> > [1]
> >> > 0xD01 means 13.1 by hexadecimal.
> >> >
> >> > I checked symbol table by "dump -Tv -X64". [2]
> >> > It seemed it was fine, some symbols were hidden.
> >> >
> >> > Does someone review my code?
> >> >
> >> > [1]
> >> >
> >>
> https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i
> >> > bm.xlc1313.aix.doc/compiler_ref/xlmacros.html
> >> > [2]
> >> > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> >> > visibility/index.html
> >> >
> >> > On 2018-06-01 21:12, Baesken, Matthias wrote:
> >> > > 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 <takiguc at linux.vnet.ibm.com>
> >> > >> Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> > >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-
> port-
> >> > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
> Lindenmaier,
> >> > >> Goetz <goetz.lindenmaier at sap.com>
> >> > >> 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:takiguc at linux.vnet.ibm.com]
> >> > >> > Sent: Donnerstag, 31. Mai 2018 09:55
> >> > >> > To: Langer, Christoph <christoph.langer at sap.com>
> >> > >> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> > >> > dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-
> port-
> >> > >> > dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
> >> Lindenmaier,
> >> > >> > Goetz <goetz.lindenmaier at sap.com>
> >> > >> > 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 <christoph.langer at sap.com>;
> >> > >> > > 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>;
> >> > >> > > ppc-aix-port-dev at openjdk.java.net; core-libs-
> >> dev at openjdk.java.net
> >> > >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> > >> > > 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
> >> > >> > >
> >> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>;
> >> > >> > > 'build-dev at openjdk.java.net'
> >> > >> > > <build-dev at openjdk.java.net<mailto:build-
> >> > dev at openjdk.java.net>>;
> >> > >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> >> > >> > dev at openjdk.java.net>;
> >> > >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> >> > >> dev at openjdk.java.net>
> >> > >> > > Cc: Simonis, Volker
> >> > >> > > <volker.simonis at sap.com<mailto:volker.simonis at 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 at openjdk.java.net'
> >> > >> > > <build-dev at openjdk.java.net<mailto:build-
> >> > dev at openjdk.java.net>>;
> >> > >> > > ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-
> >> > >> > dev at openjdk.java.net>;
> >> > >> > > core-libs-dev at openjdk.java.net<mailto:core-libs-
> >> > >> dev at openjdk.java.net>
> >> > >> > > Cc: Langer, Christoph
> >> > >> > >
> <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>;
> >> > >> Simonis,
> >> > >> > > Volker
> >> <volker.simonis at sap.com<mailto:volker.simonis at 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.0000.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.0000.0008
> >> > >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> >> > >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> >> > >> > >
> >> > >> > >
> >> > >> > > So it is better to avoid  setting these flags when using xlc12.1   .
> >> > >> > > Please review :
> >> > >> > >
> >> > >> > > Bug :
> >> > >> > >
> >> > >> > > https://bugs.openjdk.java.net/browse/JDK-8202322
> >> > >> > >
> >> > >> > > Change :
> >> > >> > >
> >> > >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
> >> > >> > >
> >> > >> > >
> >> > >> > > Best regards, Matthias


From magnus.ihse.bursie at oracle.com  Fri Jun  8 08:38:44 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 8 Jun 2018 10:38:44 +0200
Subject: RFR: JDK-8204602 Add devkit for linux-arm32
Message-ID: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>

With some simple changes, our devkit scripts can be made to generate 
devkits for cross-compiling on linux-x64 to linux-arm (32-bit). Also add 
a jib profile to use this new linux-arm devkit, as opposed to the legacy 
devkits used by the traditional linux-arm profiles.

Note that this change does not imply any change in Oracle's support of 
the linux-arm platform.

Bug: https://bugs.openjdk.java.net/browse/JDK-8204602
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8204602-add-linux-arm-32-devkit/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Jun  8 08:50:37 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 8 Jun 2018 10:50:37 +0200
Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I
 flags automatically
In-Reply-To: <eea6cb0b-dc41-7fd3-eb32-45740982b847@oracle.com>
References: <e6fd26e9-ff40-4e4c-ba0b-97afd4279822@oracle.com>
 <eea6cb0b-dc41-7fd3-eb32-45740982b847@oracle.com>
Message-ID: <4ff74b09-ec9f-0a80-31d5-49039d5e1e8c@oracle.com>

On 2018-06-07 23:20, Erik Joelsson wrote:
> Hello Magnus,
>
> Very nice refactoring!
Thanks!

>
> JdkNativeCompilation.gmk
> line 126-127 looks a bit long. There is an extra space on 126. Also, 
> why not addprefix for adding -I instead of clunky foreach? Not that I 
> care greatly, but I usually prefer that construct.

Yeah, I agree, addprefix is better. I just forgot about it; foreach is a 
nice allround tool.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.02/
(Only changes is in JdkNativeCompilation.gmk, as per above comments).

/Magnus

>
> Otherwise looks good.
>
> /Erik
>
>
> On 2018-06-07 13:22, Magnus Ihse Bursie wrote:
>> This change needs some background information.
>>
>> I've been working on simplifying and streamlining the compilation of 
>> native libraries of the JDK. Previously, I introduced the 
>> SetupJdkLibrary function, and started to get a better control of 
>> compiler flags. This patch continues on both paths.
>>
>> The original intent of this change, which I naively thought was going 
>> to be much simpler than it turned out :-) was to separate the -I 
>> flags (location of header files) from other flags, and to generate 
>> these automatically, wherever possible. Since we have a standard way 
>> of locating native code, and most libraries just want to have an -I 
>> path to their own source base and the generated Java header, we 
>> should be able to provide this in SetupJdkLibrary.
>>
>> This turned out to be closely related to SetupJdkLibrary being able 
>> to discover the location of the SRC directories itself, using 
>> "convention over configuration" and assuming that the library 
>> "libfoo" for "java.module" would be located in 
>> java.module/*/native/libfoo.
>>
>> While this sounds simple in theory, when actually trying to implement 
>> this I of course ran into all the places where some special handling 
>> was indeed needed. So even if like 90% of all libraries were simple 
>> to get to build using automated discovery of source and header 
>> directories, the 10% that did not caused me much more headaches than 
>> I had anticipated. On the other hand, now that I've sorted out all 
>> those places, the few remaining odd solutions is clearly documented 
>> and not just something that "just happens" due to strange 
>> configurations.
>>
>> One file deserves mentioning specifically: Awt2dLibraries.gmk. The 
>> java.desktop libraries are unfortunately quite entangled with each 
>> other, and do not readily follow the patterns that are used elsewhere 
>> in the code base. So it might just look like the file has just gone 
>> from one state of messiness, to another, which would hardly be an 
>> improvement. :-( I would still argue that the new messiness is 
>> better: It is now much clearer in what ways the libraries diverge 
>> from our standard assumption, and what course of action needs to be 
>> taken to minimize these differences. (Which is something I believe 
>> should be done -- these issues are not just cosmetic but is the root 
>> of most of the issues we always see for these libraries, when 
>> upgrading compilers, etc.)
>>
>> During this change, I noticed that not all native libraries include 
>> the proper generated header file. This is a dangerous coding 
>> practice, since a change in the Java part of the interface might not 
>> get picked up properly in the native part. I've added the missing 
>> includes that I've detected, and due to these changes, I'm also 
>> including the component teams in what is really only a build change. 
>> As can be seen for jdk.crypto.mscapi; there had indeed been changes 
>> that needed correcting.
>>
>> Since this is (basically) a pure build change, my gold standard here 
>> has been the build compare script. In essence, the build output prior 
>> to my change and with this change are 100% identical. In truth, this 
>> is a bit too strong a claim. A few changes has occurred, but none of 
>> them should matter. Here's a breakdown of the compare.sh results:
>>
>> * Windows-x64:
>>
>> No differences at all.
>>
>> * Solaris:
>>
>> Two libraries are reported to differ: libsaproc.so and 
>> libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing 
>> this, I found that the object files used to link these two libraries 
>> has no disass differences. They have a slight binary difference and a 
>> difference in size, due to the include paths being different (and 
>> this is stored in the .o file, which makes it different). Somehow 
>> this apparently triggers the linker to generate a slightly different 
>> code in a few places, using a different register or so. (Weird...)
>>
>> * MacOS:
>>
>> Two libraries are reported to differ: libjava.dylib and 
>> libmlib_image.dylib, both of them just reported as a binary diff (no 
>> symbol, disass or fulldump differences). This is not really 
>> unsuspected, but I analyzed it anyway.
>>
>> I found that for libjava.dylib, a single .o file was different. This 
>> one was actually picked up from closed sources, and are not really 
>> relevant for OpenJDK. Anyway, the reason for the difference was the 
>> same as for the Solaris libs; the include paths had changes, which 
>> caused a binary diff.
>>
>> For libmlib_image.dylib, the link order had changed causing the noted 
>> binary difference.
>>
>> * Linux:
>>
>> On linux, the compare script noted differences for libextnet, 
>> libjava, libmlib_image, libprefs, libsaproc, libsplashscreen and 
>> libsunec.
>>
>> The differences for libextnet, libprefs, libsplashscreen and libsunec 
>> turned out to be caused by the added #include of the generated Java 
>> headers. This caused binary differences (reasonably), and for some 
>> odd reason also a symbol difference in java_awt_SplashScreen.o 
>> (clazz.10057 and mid.10058 were replaced by clazz.10015 and 
>> mid.10016). I can't claim to understand this, but I'm assuming it's 
>> some kind of generated code.
>>
>> libsaproc and libjava changes was caused by closed source changes, 
>> and is therefore not relevant to OpenJDK.
>>
>> For libmlib_image.dylib, the link order had changed causing the noted 
>> binary difference, as on MacOS.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204572
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01
>>
>> /Magnus
>>
>



From kevin.walls at oracle.com  Fri Jun  8 09:27:05 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 8 Jun 2018 10:27:05 +0100
Subject: [8u] RFR: 8196108: Add build support for VS 2015/2017
Message-ID: <b6c1c71e-ac5a-ccc5-5d1d-f57fe4f61f61@oracle.com>

Hi,

I'd like to get a review of a backport to jdk8u of:

8196108: Add build support for VS 2015/2017
https://bugs.openjdk.java.net/browse/JDK-8196108

JDK 11 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/bcce1fa183e7

Original review thread: 
http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020719.html

jdk8u webrev: http://cr.openjdk.java.net/~kevinw/8196108/webrev.00/

Imports partly automatically, partly needs manual intervention.

I haven't included the devkit creation scripts.? They aren't in 8 
already, we haven't backported: 8087208: Add devkit creation script for 
windows
The scripts are available in the later repos, and the devkits created 
are the same...? So it appears unnecessary.? I can start a build using 
VS2017 installed, or from a devkit.

Testing locally and with JPRT, using the existing default VS2010 
compiler, so the standard build is unaffected.

This change is not in 10 or 9, but this is a backport to 8.

This of course does not change anything about what compilers are known 
to work or be supported to build jdk8u, and in toolchain_windows.m4, for 
the ordering of compiler versions I kept VALID_VS_VERSIONS starting with 
2010, so no change in the default compiler we use.? Will be further 
changes to get the VS2017 build actually working...

Many thanks
Kevin



From magnus.ihse.bursie at oracle.com  Fri Jun  8 15:18:58 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 8 Jun 2018 17:18:58 +0200
Subject: [8u] RFR: 8196108: Add build support for VS 2015/2017
In-Reply-To: <b6c1c71e-ac5a-ccc5-5d1d-f57fe4f61f61@oracle.com>
References: <b6c1c71e-ac5a-ccc5-5d1d-f57fe4f61f61@oracle.com>
Message-ID: <9c8d5d0d-41e4-b2a6-9c43-a90dbfe3b938@oracle.com>

On 2018-06-08 11:27, Kevin Walls wrote:
> Hi,
>
> I'd like to get a review of a backport to jdk8u of:
>
> 8196108: Add build support for VS 2015/2017
> https://bugs.openjdk.java.net/browse/JDK-8196108
>
> JDK 11 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/bcce1fa183e7
>
> Original review thread: 
> http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020719.html
>
> jdk8u webrev: http://cr.openjdk.java.net/~kevinw/8196108/webrev.00/
Looks good to me.

/Magnus
>
> Imports partly automatically, partly needs manual intervention.
>
> I haven't included the devkit creation scripts.? They aren't in 8 
> already, we haven't backported: 8087208: Add devkit creation script 
> for windows
> The scripts are available in the later repos, and the devkits created 
> are the same...? So it appears unnecessary.? I can start a build using 
> VS2017 installed, or from a devkit.
>
> Testing locally and with JPRT, using the existing default VS2010 
> compiler, so the standard build is unaffected.
>
> This change is not in 10 or 9, but this is a backport to 8.
>
> This of course does not change anything about what compilers are known 
> to work or be supported to build jdk8u, and in toolchain_windows.m4, 
> for the ordering of compiler versions I kept VALID_VS_VERSIONS 
> starting with 2010, so no change in the default compiler we use.? Will 
> be further changes to get the VS2017 build actually working...
>
> Many thanks
> Kevin
>



From erik.joelsson at oracle.com  Fri Jun  8 15:33:17 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 8 Jun 2018 08:33:17 -0700
Subject: RFR: JDK-8204602 Add devkit for linux-arm32
In-Reply-To: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
References: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
Message-ID: <536a0533-eb28-0738-9fde-0a8be0012ec1@oracle.com>

Looks ok to me.

/Erik


On 2018-06-08 01:38, Magnus Ihse Bursie wrote:
> With some simple changes, our devkit scripts can be made to generate 
> devkits for cross-compiling on linux-x64 to linux-arm (32-bit). Also 
> add a jib profile to use this new linux-arm devkit, as opposed to the 
> legacy devkits used by the traditional linux-arm profiles.
>
> Note that this change does not imply any change in Oracle's support of 
> the linux-arm platform.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204602
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8204602-add-linux-arm-32-devkit/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Fri Jun  8 15:37:10 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 8 Jun 2018 08:37:10 -0700
Subject: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I
 flags automatically
In-Reply-To: <4ff74b09-ec9f-0a80-31d5-49039d5e1e8c@oracle.com>
References: <e6fd26e9-ff40-4e4c-ba0b-97afd4279822@oracle.com>
 <eea6cb0b-dc41-7fd3-eb32-45740982b847@oracle.com>
 <4ff74b09-ec9f-0a80-31d5-49039d5e1e8c@oracle.com>
Message-ID: <04d6b9dc-e091-4d63-1816-15846a7b34d3@oracle.com>

Looks good.

/Erik


On 2018-06-08 01:50, Magnus Ihse Bursie wrote:
> On 2018-06-07 23:20, Erik Joelsson wrote:
>> Hello Magnus,
>>
>> Very nice refactoring!
> Thanks!
>
>>
>> JdkNativeCompilation.gmk
>> line 126-127 looks a bit long. There is an extra space on 126. Also, 
>> why not addprefix for adding -I instead of clunky foreach? Not that I 
>> care greatly, but I usually prefer that construct.
>
> Yeah, I agree, addprefix is better. I just forgot about it; foreach is 
> a nice allround tool.
>
> Updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.02/
> (Only changes is in JdkNativeCompilation.gmk, as per above comments).
>
> /Magnus
>
>>
>> Otherwise looks good.
>>
>> /Erik
>>
>>
>> On 2018-06-07 13:22, Magnus Ihse Bursie wrote:
>>> This change needs some background information.
>>>
>>> I've been working on simplifying and streamlining the compilation of 
>>> native libraries of the JDK. Previously, I introduced the 
>>> SetupJdkLibrary function, and started to get a better control of 
>>> compiler flags. This patch continues on both paths.
>>>
>>> The original intent of this change, which I naively thought was 
>>> going to be much simpler than it turned out :-) was to separate the 
>>> -I flags (location of header files) from other flags, and to 
>>> generate these automatically, wherever possible. Since we have a 
>>> standard way of locating native code, and most libraries just want 
>>> to have an -I path to their own source base and the generated Java 
>>> header, we should be able to provide this in SetupJdkLibrary.
>>>
>>> This turned out to be closely related to SetupJdkLibrary being able 
>>> to discover the location of the SRC directories itself, using 
>>> "convention over configuration" and assuming that the library 
>>> "libfoo" for "java.module" would be located in 
>>> java.module/*/native/libfoo.
>>>
>>> While this sounds simple in theory, when actually trying to 
>>> implement this I of course ran into all the places where some 
>>> special handling was indeed needed. So even if like 90% of all 
>>> libraries were simple to get to build using automated discovery of 
>>> source and header directories, the 10% that did not caused me much 
>>> more headaches than I had anticipated. On the other hand, now that 
>>> I've sorted out all those places, the few remaining odd solutions is 
>>> clearly documented and not just something that "just happens" due to 
>>> strange configurations.
>>>
>>> One file deserves mentioning specifically: Awt2dLibraries.gmk. The 
>>> java.desktop libraries are unfortunately quite entangled with each 
>>> other, and do not readily follow the patterns that are used 
>>> elsewhere in the code base. So it might just look like the file has 
>>> just gone from one state of messiness, to another, which would 
>>> hardly be an improvement. :-( I would still argue that the new 
>>> messiness is better: It is now much clearer in what ways the 
>>> libraries diverge from our standard assumption, and what course of 
>>> action needs to be taken to minimize these differences. (Which is 
>>> something I believe should be done -- these issues are not just 
>>> cosmetic but is the root of most of the issues we always see for 
>>> these libraries, when upgrading compilers, etc.)
>>>
>>> During this change, I noticed that not all native libraries include 
>>> the proper generated header file. This is a dangerous coding 
>>> practice, since a change in the Java part of the interface might not 
>>> get picked up properly in the native part. I've added the missing 
>>> includes that I've detected, and due to these changes, I'm also 
>>> including the component teams in what is really only a build change. 
>>> As can be seen for jdk.crypto.mscapi; there had indeed been changes 
>>> that needed correcting.
>>>
>>> Since this is (basically) a pure build change, my gold standard here 
>>> has been the build compare script. In essence, the build output 
>>> prior to my change and with this change are 100% identical. In 
>>> truth, this is a bit too strong a claim. A few changes has occurred, 
>>> but none of them should matter. Here's a breakdown of the compare.sh 
>>> results:
>>>
>>> * Windows-x64:
>>>
>>> No differences at all.
>>>
>>> * Solaris:
>>>
>>> Two libraries are reported to differ: libsaproc.so and 
>>> libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing 
>>> this, I found that the object files used to link these two libraries 
>>> has no disass differences. They have a slight binary difference and 
>>> a difference in size, due to the include paths being different (and 
>>> this is stored in the .o file, which makes it different). Somehow 
>>> this apparently triggers the linker to generate a slightly different 
>>> code in a few places, using a different register or so. (Weird...)
>>>
>>> * MacOS:
>>>
>>> Two libraries are reported to differ: libjava.dylib and 
>>> libmlib_image.dylib, both of them just reported as a binary diff (no 
>>> symbol, disass or fulldump differences). This is not really 
>>> unsuspected, but I analyzed it anyway.
>>>
>>> I found that for libjava.dylib, a single .o file was different. This 
>>> one was actually picked up from closed sources, and are not really 
>>> relevant for OpenJDK. Anyway, the reason for the difference was the 
>>> same as for the Solaris libs; the include paths had changes, which 
>>> caused a binary diff.
>>>
>>> For libmlib_image.dylib, the link order had changed causing the 
>>> noted binary difference.
>>>
>>> * Linux:
>>>
>>> On linux, the compare script noted differences for libextnet, 
>>> libjava, libmlib_image, libprefs, libsaproc, libsplashscreen and 
>>> libsunec.
>>>
>>> The differences for libextnet, libprefs, libsplashscreen and 
>>> libsunec turned out to be caused by the added #include of the 
>>> generated Java headers. This caused binary differences (reasonably), 
>>> and for some odd reason also a symbol difference in 
>>> java_awt_SplashScreen.o (clazz.10057 and mid.10058 were replaced by 
>>> clazz.10015 and mid.10016). I can't claim to understand this, but 
>>> I'm assuming it's some kind of generated code.
>>>
>>> libsaproc and libjava changes was caused by closed source changes, 
>>> and is therefore not relevant to OpenJDK.
>>>
>>> For libmlib_image.dylib, the link order had changed causing the 
>>> noted binary difference, as on MacOS.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204572
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dirs/webrev.01
>>>
>>> /Magnus
>>>
>>
>



From erik.joelsson at oracle.com  Fri Jun  8 21:50:31 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 8 Jun 2018 14:50:31 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
Message-ID: <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>

On 2018-06-07 17:30, David Holmes wrote:
> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>> I just don't think the extra work is warranted or should be 
>> prioritized at this point. I also cannot think of a combination of 
>> options required for what you are suggesting that wouldn't be 
>> confusing to the user. If someone truly feels like these flags are 
>> forced on them and can't live with them, we or preferably that person 
>> can fix it then. I don't think that's dictatorship. OpenJDK is still 
>> open source and anyone can contribute.
>
> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot to 
> add to the right flags would be either complicated or confusing.
>
For me the confusion surrounds the difference between 
--enable-hardened-hotspot and --with-jvm-variants=server, hardened and 
making the user understand it. But sure, it is doable. Here is a new 
webrev with those two options as I interpret them. Here is the help text:

 ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
 ????????????????????????? libraries (except the JVM), typically disabling
 ????????????????????????? speculative cti. [disabled]
 ?--enable-hardened-hotspot
 ????????????????????????? enable hardenening compiler flags for hotspot 
(all
 ????????????????????????? jvm variants), typically disabling 
speculative cti.
 ????????????????????????? To make hardening of hotspot a runtime choice,
 ????????????????????????? consider the "hardened" jvm variant instead 
of this
 ????????????????????????? option. [disabled]

Note that this changes the default for jdk libraries to not enable 
hardening unless the user requests it.

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

/Erik


From daniel.daugherty at oracle.com  Fri Jun  8 21:53:19 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 8 Jun 2018 17:53:19 -0400
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
Message-ID: <6b0ae785-fa7c-56d6-35c4-de7dde391ef3@oracle.com>

On 6/8/18 5:50 PM, Erik Joelsson wrote:
> On 2018-06-07 17:30, David Holmes wrote:
>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>> I just don't think the extra work is warranted or should be 
>>> prioritized at this point. I also cannot think of a combination of 
>>> options required for what you are suggesting that wouldn't be 
>>> confusing to the user. If someone truly feels like these flags are 
>>> forced on them and can't live with them, we or preferably that 
>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>> is still open source and anyone can contribute.
>>
>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>> to add to the right flags would be either complicated or confusing.
>>
> For me the confusion surrounds the difference between 
> --enable-hardened-hotspot and --with-jvm-variants=server, hardened and 
> making the user understand it. But sure, it is doable. Here is a new 
> webrev with those two options as I interpret them. Here is the help text:
>
> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk

Typo: 'hardenening' -> 'hardening'


> libraries (except the JVM), typically disabling
> ????????????????????????? speculative cti. [disabled]
> ?--enable-hardened-hotspot
> ????????????????????????? enable hardenening compiler flags for 
> hotspot (all

Typo: 'hardenening' -> 'hardening'


> jvm variants), typically disabling speculative cti.
> ????????????????????????? To make hardening of hotspot a runtime choice,
> ????????????????????????? consider the "hardened" jvm variant instead 
> of this
> ????????????????????????? option. [disabled]
>
> Note that this changes the default for jdk libraries to not enable 
> hardening unless the user requests it.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>
> /Erik

Dan



From erik.joelsson at oracle.com  Fri Jun  8 21:55:44 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 8 Jun 2018 14:55:44 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <6b0ae785-fa7c-56d6-35c4-de7dde391ef3@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <6b0ae785-fa7c-56d6-35c4-de7dde391ef3@oracle.com>
Message-ID: <33a3a9e0-3e48-a2f3-9ce2-1fc5aaeeb8c0@oracle.com>

Doh, thanks, updated in place.

/Erik


On 2018-06-08 14:53, Daniel D. Daugherty wrote:
> On 6/8/18 5:50 PM, Erik Joelsson wrote:
>> On 2018-06-07 17:30, David Holmes wrote:
>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>> I just don't think the extra work is warranted or should be 
>>>> prioritized at this point. I also cannot think of a combination of 
>>>> options required for what you are suggesting that wouldn't be 
>>>> confusing to the user. If someone truly feels like these flags are 
>>>> forced on them and can't live with them, we or preferably that 
>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>> is still open source and anyone can contribute.
>>>
>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>> to add to the right flags would be either complicated or confusing.
>>>
>> For me the confusion surrounds the difference between 
>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened 
>> and making the user understand it. But sure, it is doable. Here is a 
>> new webrev with those two options as I interpret them. Here is the 
>> help text:
>>
>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>
> Typo: 'hardenening' -> 'hardening'
>
>
>> libraries (except the JVM), typically disabling
>> ????????????????????????? speculative cti. [disabled]
>> ?--enable-hardened-hotspot
>> ????????????????????????? enable hardenening compiler flags for 
>> hotspot (all
>
> Typo: 'hardenening' -> 'hardening'
>
>
>> jvm variants), typically disabling speculative cti.
>> ????????????????????????? To make hardening of hotspot a runtime choice,
>> ????????????????????????? consider the "hardened" jvm variant instead 
>> of this
>> ????????????????????????? option. [disabled]
>>
>> Note that this changes the default for jdk libraries to not enable 
>> hardening unless the user requests it.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>
>> /Erik
>
> Dan
>



From erik.joelsson at oracle.com  Sat Jun  9 00:05:24 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 8 Jun 2018 17:05:24 -0700
Subject: RFR: JDK-8204127: Change bundle format on Windows to zip
Message-ID: <7e9bd4c6-679d-388e-fbe8-9a7189b72e76@oracle.com>

The compressed archive bundles we create are all tar.gz format. On 
Windows that's not a very common format, requiring third party 
applications to handle, while the zip format can be natively extracted. 
This patch changes the bundle format for the JDK on Windows to zip.

This only applies to the actual product distributions. I think we prefer 
tar.gz for all the internal bundles, like symbols and tests.

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

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

/Erik



From david.holmes at oracle.com  Sun Jun 10 13:28:26 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 10 Jun 2018 23:28:26 +1000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
Message-ID: <66d3c352-01fc-a06c-c9e3-a5ccf317166b@oracle.com>

On 9/06/2018 7:50 AM, Erik Joelsson wrote:
> On 2018-06-07 17:30, David Holmes wrote:
>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>> I just don't think the extra work is warranted or should be 
>>> prioritized at this point. I also cannot think of a combination of 
>>> options required for what you are suggesting that wouldn't be 
>>> confusing to the user. If someone truly feels like these flags are 
>>> forced on them and can't live with them, we or preferably that person 
>>> can fix it then. I don't think that's dictatorship. OpenJDK is still 
>>> open source and anyone can contribute.
>>
>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot to 
>> add to the right flags would be either complicated or confusing.
>>
> For me the confusion surrounds the difference between 
> --enable-hardened-hotspot and --with-jvm-variants=server, hardened and 

That's the problem: "hardened" is not a jvm-variant as we have always 
defined that! "hardened" is a variation in the same way as product vs 
fastdebug versus slow-debug versus (the old) optimized. It is _not_ at 
all the same kind of thing as server versus client versus zero etc. The 
desire to ship "hardened" in the same image as non-hardened is what is 
causing the semantic conflict here. It is like shipping a product and 
debug VM together. Sure you can do it, but that's not how we've 
categorised things in the past.

I understand the need to make things work this way, so in that sense 
selecting jvm-variant=hardened should be seen as specifying 
"--enable-hardened-hotspot --enable-hardened-jdk". But 
jvm-variant=hardened is really jvm-variant=hardened-server.

> making the user understand it. But sure, it is doable. Here is a new 
> webrev with those two options as I interpret them. Here is the help text:
> 
>  ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>  ????????????????????????? libraries (except the JVM), typically disabling
>  ????????????????????????? speculative cti. [disabled]
>  ?--enable-hardened-hotspot
>  ????????????????????????? enable hardenening compiler flags for hotspot 
> (all
>  ????????????????????????? jvm variants), typically disabling 
> speculative cti.
>  ????????????????????????? To make hardening of hotspot a runtime choice,
>  ????????????????????????? consider the "hardened" jvm variant instead 
> of this
>  ????????????????????????? option. [disabled]
> 
> Note that this changes the default for jdk libraries to not enable 
> hardening unless the user requests it.

That's your call. I don't care what the default is as long as the 
developer has control over it.

Thanks,
David

> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
> 
> /Erik


From david.holmes at oracle.com  Sun Jun 10 13:35:13 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 10 Jun 2018 23:35:13 +1000
Subject: RFR: JDK-8204602 Add devkit for linux-arm32
In-Reply-To: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
References: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
Message-ID: <298ff9c4-c716-c28d-43c4-0c3029e98de8@oracle.com>

On 8/06/2018 6:38 PM, Magnus Ihse Bursie wrote:
> With some simple changes, our devkit scripts can be made to generate 
> devkits for cross-compiling on linux-x64 to linux-arm (32-bit). Also add 
> a jib profile to use this new linux-arm devkit, as opposed to the legacy 
> devkits used by the traditional linux-arm profiles.

I'm not at all clear what this is providing or for whom. The legacy 
linux-arm-vfp-hflt requires pointers to the X11R6 installation to build. 
The linux-arm32 jib-profile has none, but instead lists freetype as 
being bundled. ??

David

> Note that this change does not imply any change in Oracle's support of 
> the linux-arm platform.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204602
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8204602-add-linux-arm-32-devkit/webrev.01 
> 
> 
> /Magnus


From magnus.ihse.bursie at oracle.com  Mon Jun 11 06:46:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 08:46:14 +0200
Subject: RFR: JDK-8204602 Add devkit for linux-arm32
In-Reply-To: <298ff9c4-c716-c28d-43c4-0c3029e98de8@oracle.com>
References: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
 <298ff9c4-c716-c28d-43c4-0c3029e98de8@oracle.com>
Message-ID: <60cefd2e-5e11-c967-2287-b1860d92f397@oracle.com>


On 2018-06-10 15:35, David Holmes wrote:
> On 8/06/2018 6:38 PM, Magnus Ihse Bursie wrote:
>> With some simple changes, our devkit scripts can be made to generate 
>> devkits for cross-compiling on linux-x64 to linux-arm (32-bit). Also 
>> add a jib profile to use this new linux-arm devkit, as opposed to the 
>> legacy devkits used by the traditional linux-arm profiles.
>
> I'm not at all clear what this is providing or for whom. The legacy 
> linux-arm-vfp-hflt requires pointers to the X11R6 installation to 
> build. The linux-arm32 jib-profile has none, but instead lists 
> freetype as being bundled. ??

The target audience here is mainly Erik and me (and the Hotspot 
engineers who have requested a simple way to build the arm port). This 
provides us with an up-to-date, standard configured, devkit for building 
arm-32.

In contrast to the legacy jib profile, we now have a devkit that is 
build according to our standard, so configure need a minimal amount of 
flags (hence no X11 flags). The bundled freetype is to simplify things; 
we now have a version of freetype included in the OpenJDK source, and 
it's by far the easiest to use it, rather than to include it in the 
devkit, but this is not enabled by default on linux-arm.

I hope that answers your questions!

/Magnus

>
> David
>
>> Note that this change does not imply any change in Oracle's support 
>> of the linux-arm platform.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204602
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8204602-add-linux-arm-32-devkit/webrev.01 
>>
>>
>> /Magnus



From magnus.ihse.bursie at oracle.com  Mon Jun 11 07:10:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 09:10:23 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
Message-ID: <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>

On 2018-06-08 23:50, Erik Joelsson wrote:
> On 2018-06-07 17:30, David Holmes wrote:
>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>> I just don't think the extra work is warranted or should be 
>>> prioritized at this point. I also cannot think of a combination of 
>>> options required for what you are suggesting that wouldn't be 
>>> confusing to the user. If someone truly feels like these flags are 
>>> forced on them and can't live with them, we or preferably that 
>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>> is still open source and anyone can contribute.
>>
>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>> to add to the right flags would be either complicated or confusing.
>>
> For me the confusion surrounds the difference between 
> --enable-hardened-hotspot and --with-jvm-variants=server, hardened and 
> making the user understand it. But sure, it is doable. Here is a new 
> webrev with those two options as I interpret them. Here is the help text:
>
> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
> ????????????????????????? libraries (except the JVM), typically disabling
> ????????????????????????? speculative cti. [disabled]
> ?--enable-hardened-hotspot
> ????????????????????????? enable hardenening compiler flags for 
> hotspot (all
> ????????????????????????? jvm variants), typically disabling 
> speculative cti.
> ????????????????????????? To make hardening of hotspot a runtime choice,
> ????????????????????????? consider the "hardened" jvm variant instead 
> of this
> ????????????????????????? option. [disabled]
>
> Note that this changes the default for jdk libraries to not enable 
> hardening unless the user requests it.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/

Hold it, hold it! I'm not sure how we ended up here, but I don't like it 
at all. :-(

I think Eriks initial patch is much better than this. Some arguments in 
random order to defend this position:

1) Why should we have a configure option to disable security relevant 
flags for the JDK, if there has been no measured negative effect? We 
don't do this for any other compiler flags, especially not security 
relevant ones!

I've re-read the entire thread to see if I could understand what could 
possibly motivate this, but the only thing I can find is David Holmes 
vague fear that these flags would not be well-tested enough. Let me 
counter with my own vague guesses: I believe the spectre mitigation 
methods to have been fully and properly tested, since they are 
rolled-out massively on all products. And let me complement with my own 
fear: the PR catastrophe if OpenJDK were *not* built with spectre 
mitigations, and someone were to exploit that!

In fact, I could even argue that "server" should be hardened *by 
default*, and that we should instead introduce a non-hardened JVM named 
something akin to "quick-but-dangerous-server" instead. But I realize 
that a 25% performance hit is hard to swallow, so I won't push this agenda.

2) It is by no means clear that "--enable-hardened-jdk" does not harden 
all aspects of the JDK! If we should keep the option (which I definitely 
do not think we should!) it should be renamed to 
"--enable-hardened-libraries", or something like that. And it should be 
on by default, so it should be a "--disabled-hardened-jdk-libraries".

Also, the general-sounding name "hardened" sounds like it might 
encompass more things than it does. What if I disabled a hardened jdk 
build, should I still get stack banging protection? If so, you need to 
move a lot more security-related flags to this option. (And, just to be 
absolutely clear: I don't think you should do that.)

3) Having two completely different ways of turning on Spectre protection 
for hotspot is just utterly confusing! This was a perfect example of how 
to use the JVM features, just as in the original patch.

If you want to have spectre mitigation enabled for both server and 
client, by default, you would just need to run "configure 
--with-jvm-variants=server,client 
--with-jvm-features=no-speculative-cti", which will enable that feature 
for all variants. That's not really hard *at all* for anyone building 
OpenJDK. And it's way clearer what will happen, than a 
--enable-hardened-hotspot.

4) If you are a downstream provider building OpenJDK and you are dead 
set on not including Spectre mitigations in the JDK libraries, despite 
being shown to have no negative effects, then you can do just as any 
other downstream user with highly specialized requirements, and patch 
the source. I have no sympathies for this; I can't stop it but I don't 
think there's any reason for us to complicate the code to support this 
unlikely case.

So, to recap, I think the webrev as published in 
http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with "altserver" 
renamed to "hardened") is the way to go.

/Magnus



>
> /Erik



From magnus.ihse.bursie at oracle.com  Mon Jun 11 07:21:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 09:21:23 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <66d3c352-01fc-a06c-c9e3-a5ccf317166b@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <66d3c352-01fc-a06c-c9e3-a5ccf317166b@oracle.com>
Message-ID: <4c7694f3-6b65-270b-86a7-6464d43d1986@oracle.com>



On 2018-06-10 15:28, David Holmes wrote:
> On 9/06/2018 7:50 AM, Erik Joelsson wrote:
>> On 2018-06-07 17:30, David Holmes wrote:
>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>> I just don't think the extra work is warranted or should be 
>>>> prioritized at this point. I also cannot think of a combination of 
>>>> options required for what you are suggesting that wouldn't be 
>>>> confusing to the user. If someone truly feels like these flags are 
>>>> forced on them and can't live with them, we or preferably that 
>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>> is still open source and anyone can contribute.
>>>
>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>> to add to the right flags would be either complicated or confusing.
>>>
>> For me the confusion surrounds the difference between 
>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened and 
>
> That's the problem: "hardened" is not a jvm-variant as we have always 
> defined that! "hardened" is a variation in the same way as product vs 
> fastdebug versus slow-debug versus (the old) optimized. It is _not_ at 
> all the same kind of thing as server versus client versus zero etc. 
> The desire to ship "hardened" in the same image as non-hardened is 
> what is causing the semantic conflict here. It is like shipping a 
> product and debug VM together. Sure you can do it, but that's not how 
> we've categorised things in the past.
I disagree. The "no-speculative-cti" is a perfectly fine JVM feature, 
which can be applied to any JVM variant. It is not a JVM feature as a 
separate software component (like cmsgc or compiler1) that could be left 
in or kept out and that affects the functionality of hotspot. Instead, 
it is a JVM feature very much like the existing link-time-opt, in that 
it affects all aspects of the JVM; not the functionality, but the 
performance (and security).

The way we bundle a certain set of JVM features as a named JVM variant 
has always been a bit, well, semantically odd, but it has served us okay 
in the past and serve us just as well for this fix.

>
> I understand the need to make things work this way, so in that sense 
> selecting jvm-variant=hardened should be seen as specifying 
> "--enable-hardened-hotspot --enable-hardened-jdk". But 
> jvm-variant=hardened is really jvm-variant=hardened-server.
Yes, jvm-variant=hardened is actually hardned-server. Despite the longer 
name, it might be more clear to use that name. It ties in into a bit 
into Erik's original "altserver" proposal.

I think the reason just "hardened" sounds like a reasonable alternative 
to the more proper but longer "hardened-server" is due to how "server" 
has become the mainstream variant, even for clients, and "client" feels 
like it's being put on death row. Nobody really believes that it will 
survive in the long term, and nowadays Oracle don't even build it 
anymore (we stopped doing that when we stopped doing 32-bit builds). So 
"server" is increasingly incorrectly named, and should really just be 
considered a legacy name for what should perhaps be "default" or so.

/Magnus

>
>> making the user understand it. But sure, it is doable. Here is a new 
>> webrev with those two options as I interpret them. Here is the help 
>> text:
>>
>> ??--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>> ?????????????????????????? libraries (except the JVM), typically 
>> disabling
>> ?????????????????????????? speculative cti. [disabled]
>> ??--enable-hardened-hotspot
>> ?????????????????????????? enable hardenening compiler flags for 
>> hotspot (all
>> ?????????????????????????? jvm variants), typically disabling 
>> speculative cti.
>> ?????????????????????????? To make hardening of hotspot a runtime 
>> choice,
>> ?????????????????????????? consider the "hardened" jvm variant 
>> instead of this
>> ?????????????????????????? option. [disabled]
>>
>> Note that this changes the default for jdk libraries to not enable 
>> hardening unless the user requests it.
>
> That's your call. I don't care what the default is as long as the 
> developer has control over it.
>
> Thanks,
> David
>
>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>
>> /Erik



From david.holmes at oracle.com  Mon Jun 11 07:38:14 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Jun 2018 17:38:14 +1000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
Message-ID: <28729cf3-2951-6557-fb00-28ddf52fd110@oracle.com>

Hi Magnus,

On 11/06/2018 5:10 PM, Magnus Ihse Bursie wrote:
> On 2018-06-08 23:50, Erik Joelsson wrote:
>> On 2018-06-07 17:30, David Holmes wrote:
>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>> I just don't think the extra work is warranted or should be 
>>>> prioritized at this point. I also cannot think of a combination of 
>>>> options required for what you are suggesting that wouldn't be 
>>>> confusing to the user. If someone truly feels like these flags are 
>>>> forced on them and can't live with them, we or preferably that 
>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>> is still open source and anyone can contribute.
>>>
>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>> to add to the right flags would be either complicated or confusing.
>>>
>> For me the confusion surrounds the difference between 
>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened and 
>> making the user understand it. But sure, it is doable. Here is a new 
>> webrev with those two options as I interpret them. Here is the help text:
>>
>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>> ????????????????????????? libraries (except the JVM), typically disabling
>> ????????????????????????? speculative cti. [disabled]
>> ?--enable-hardened-hotspot
>> ????????????????????????? enable hardenening compiler flags for 
>> hotspot (all
>> ????????????????????????? jvm variants), typically disabling 
>> speculative cti.
>> ????????????????????????? To make hardening of hotspot a runtime choice,
>> ????????????????????????? consider the "hardened" jvm variant instead 
>> of this
>> ????????????????????????? option. [disabled]
>>
>> Note that this changes the default for jdk libraries to not enable 
>> hardening unless the user requests it.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
> 
> Hold it, hold it! I'm not sure how we ended up here, but I don't like it 
> at all. :-(
> 
> I think Eriks initial patch is much better than this. Some arguments in 
> random order to defend this position:
> 
> 1) Why should we have a configure option to disable security relevant 
> flags for the JDK, if there has been no measured negative effect? We 
> don't do this for any other compiler flags, especially not security 
> relevant ones!
> 
> I've re-read the entire thread to see if I could understand what could 
> possibly motivate this, but the only thing I can find is David Holmes 
> vague fear that these flags would not be well-tested enough. Let me 
> counter with my own vague guesses: I believe the spectre mitigation 
> methods to have been fully and properly tested, since they are 
> rolled-out massively on all products. And let me complement with my own 
> fear: the PR catastrophe if OpenJDK were *not* built with spectre 
> mitigations, and someone were to exploit that!

All I'm looking for is the ability to select whether you can build with 
or without this "hardening". The default OpenJDK build can of course 
churn out a "hardened" implementation. Anyone who opts out of that is on 
their own.

I don't share your faith or confidence in the quality of any software 
rushed out in a fairly short space of time. Prudence, if nothing else, 
says you should be able to not build this way IMHO.

> In fact, I could even argue that "server" should be hardened *by 
> default*, and that we should instead introduce a non-hardened JVM named 
> something akin to "quick-but-dangerous-server" instead. But I realize 
> that a 25% performance hit is hard to swallow, so I won't push this agenda.
> 
> 2) It is by no means clear that "--enable-hardened-jdk" does not harden 
> all aspects of the JDK! If we should keep the option (which I definitely 
> do not think we should!) it should be renamed to 
> "--enable-hardened-libraries", or something like that. And it should be 
> on by default, so it should be a "--disabled-hardened-jdk-libraries".
> 
> Also, the general-sounding name "hardened" sounds like it might 
> encompass more things than it does. What if I disabled a hardened jdk 
> build, should I still get stack banging protection? If so, you need to 
> move a lot more security-related flags to this option. (And, just to be 
> absolutely clear: I don't think you should do that.)
> 
> 3) Having two completely different ways of turning on Spectre protection 
> for hotspot is just utterly confusing! This was a perfect example of how 
> to use the JVM features, just as in the original patch.

Okay. I have had some confusion over "features" versus "variants" based 
on Eriks earlier comments. Erik's email from June 6 first states:

"I agree, and you sort of can. By adding the jvm feature 
"no-speculative-cti" to any jvm variant, you get the flags."

but then later said:

"We don't see the point in giving the choice on the JDK libraries ..."

by which I now think he meant not giving the choice at the VM variant 
level, but I mistook it for meaning at the "feature" level. Hence I came 
back with the two flags suggestion. If we can already select features 
arbitrarily at configure time then this is all addressed already.

Apologies for the confusion.

David
-----

> If you want to have spectre mitigation enabled for both server and 
> client, by default, you would just need to run "configure 
> --with-jvm-variants=server,client 
> --with-jvm-features=no-speculative-cti", which will enable that feature 
> for all variants. That's not really hard *at all* for anyone building 
> OpenJDK. And it's way clearer what will happen, than a 
> --enable-hardened-hotspot.
> 
> 4) If you are a downstream provider building OpenJDK and you are dead 
> set on not including Spectre mitigations in the JDK libraries, despite 
> being shown to have no negative effects, then you can do just as any 
> other downstream user with highly specialized requirements, and patch 
> the source. I have no sympathies for this; I can't stop it but I don't 
> think there's any reason for us to complicate the code to support this 
> unlikely case.
> 
> So, to recap, I think the webrev as published in 
> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with "altserver" 
> renamed to "hardened") is the way to go.
> 
> /Magnus
> 
> 
> 
>>
>> /Erik
> 


From magnus.ihse.bursie at oracle.com  Mon Jun 11 08:19:24 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 10:19:24 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <28729cf3-2951-6557-fb00-28ddf52fd110@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
 <28729cf3-2951-6557-fb00-28ddf52fd110@oracle.com>
Message-ID: <37e8bd6d-b906-b9d1-6e41-2229236c9c8c@oracle.com>


On 2018-06-11 09:38, David Holmes wrote:
> Hi Magnus,
>
> On 11/06/2018 5:10 PM, Magnus Ihse Bursie wrote:
>> On 2018-06-08 23:50, Erik Joelsson wrote:
>>> On 2018-06-07 17:30, David Holmes wrote:
>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>>> I just don't think the extra work is warranted or should be 
>>>>> prioritized at this point. I also cannot think of a combination of 
>>>>> options required for what you are suggesting that wouldn't be 
>>>>> confusing to the user. If someone truly feels like these flags are 
>>>>> forced on them and can't live with them, we or preferably that 
>>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>>> is still open source and anyone can contribute.
>>>>
>>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>>> to add to the right flags would be either complicated or confusing.
>>>>
>>> For me the confusion surrounds the difference between 
>>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened 
>>> and making the user understand it. But sure, it is doable. Here is a 
>>> new webrev with those two options as I interpret them. Here is the 
>>> help text:
>>>
>>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>>> ????????????????????????? libraries (except the JVM), typically 
>>> disabling
>>> ????????????????????????? speculative cti. [disabled]
>>> ?--enable-hardened-hotspot
>>> ????????????????????????? enable hardenening compiler flags for 
>>> hotspot (all
>>> ????????????????????????? jvm variants), typically disabling 
>>> speculative cti.
>>> ????????????????????????? To make hardening of hotspot a runtime 
>>> choice,
>>> ????????????????????????? consider the "hardened" jvm variant 
>>> instead of this
>>> ????????????????????????? option. [disabled]
>>>
>>> Note that this changes the default for jdk libraries to not enable 
>>> hardening unless the user requests it.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>
>> Hold it, hold it! I'm not sure how we ended up here, but I don't like 
>> it at all. :-(
>>
>> I think Eriks initial patch is much better than this. Some arguments 
>> in random order to defend this position:
>>
>> 1) Why should we have a configure option to disable security relevant 
>> flags for the JDK, if there has been no measured negative effect? We 
>> don't do this for any other compiler flags, especially not security 
>> relevant ones!
>>
>> I've re-read the entire thread to see if I could understand what 
>> could possibly motivate this, but the only thing I can find is David 
>> Holmes vague fear that these flags would not be well-tested enough. 
>> Let me counter with my own vague guesses: I believe the spectre 
>> mitigation methods to have been fully and properly tested, since they 
>> are rolled-out massively on all products. And let me complement with 
>> my own fear: the PR catastrophe if OpenJDK were *not* built with 
>> spectre mitigations, and someone were to exploit that!
>
> All I'm looking for is the ability to select whether you can build 
> with or without this "hardening". The default OpenJDK build can of 
> course churn out a "hardened" implementation. Anyone who opts out of 
> that is on their own.

With Erik's original proposal (webrev.02), you will, by default, get a 
hotspot "server" JVM variant that is identical to what you got without 
the patch. This should definitely cover your case.

You will also get all the non-hotspot libraries built as hardened. You 
*can* get the JDK libraries built non-hardened, by removing the 
${$2NO_SPECULATIVE_CTI_CFLAGS} from the line 
$1_CFLAGS_JDK="${$1_DEFINES_CPU_JDK} ${$1_CFLAGS_CPU} 
${$1_CFLAGS_CPU_JDK} ${$1_TOOLCHAIN_CFLAGS} ${$2NO_SPECULATIVE_CTI_CFLAGS}".

As I said, I believe this is enough to support that case.

>
> I don't share your faith or confidence in the quality of any software 
> rushed out in a fairly short space of time. Prudence, if nothing else, 
> says you should be able to not build this way IMHO.
AFAIU, these compiler flags has received extensive testing inside 
Oracle. It is also part of a global, high-visibility project, where key 
players have had time to prepare for handling the issues ahead of the 
public awareness of the exploits. *And* it's been almost half a year 
since the Spectre exploit was made public.

I have much more faith in enabling these flags than I'd have for e.g. 
upgrading to a newer version of Solaris Studio. :-)


>
>> In fact, I could even argue that "server" should be hardened *by 
>> default*, and that we should instead introduce a non-hardened JVM 
>> named something akin to "quick-but-dangerous-server" instead. But I 
>> realize that a 25% performance hit is hard to swallow, so I won't 
>> push this agenda.
>>
>> 2) It is by no means clear that "--enable-hardened-jdk" does not 
>> harden all aspects of the JDK! If we should keep the option (which I 
>> definitely do not think we should!) it should be renamed to 
>> "--enable-hardened-libraries", or something like that. And it should 
>> be on by default, so it should be a "--disabled-hardened-jdk-libraries".
>>
>> Also, the general-sounding name "hardened" sounds like it might 
>> encompass more things than it does. What if I disabled a hardened jdk 
>> build, should I still get stack banging protection? If so, you need 
>> to move a lot more security-related flags to this option. (And, just 
>> to be absolutely clear: I don't think you should do that.)
>>
>> 3) Having two completely different ways of turning on Spectre 
>> protection for hotspot is just utterly confusing! This was a perfect 
>> example of how to use the JVM features, just as in the original patch.
>
> Okay. I have had some confusion over "features" versus "variants" 
> based on Eriks earlier comments. Erik's email from June 6 first states:
>
> "I agree, and you sort of can. By adding the jvm feature 
> "no-speculative-cti" to any jvm variant, you get the flags."
>
> but then later said:
>
> "We don't see the point in giving the choice on the JDK libraries ..."
>
> by which I now think he meant not giving the choice at the VM variant 
> level, but I mistook it for meaning at the "feature" level. Hence I 
> came back with the two flags suggestion. If we can already select 
> features arbitrarily at configure time then this is all addressed 
> already.
>
> Apologies for the confusion.

Well, now *I* am confused. ;-)

Let's separarate two components: hotspot, and the rest of the native 
code (the "JDK libraries").

For hotspot, the following holds:
* You can enable or disable no-speculative-cti as a feature on the 
configure command line, by "--with-jvm-features=no-speculative-cti" (to 
enable) or "--with-jvm-features=-no-speculative-cti" (to disable). This 
change applies to *all* JVM variants that are built; there is currently 
no command-line support for enabling or disabling features on a 
per-JVM-variant level. (There's no real hinderance to doing so; it's 
just not yet implemented).
* Erik defines a new JVM variant, which is identical to server, but has 
also no-speculative-cti enabled. This is not built by default, but can 
be enabled by --with-jvm-variants=server,hardened. Oracle will build 
OpenJDK this way.

If you do not want hardening, you just do not build the "hardened" 
variant, and you do not add the no-speculative-cti feature.

If you want hardening all over the line (and no runtime user choice), 
you add --with-jvm-feature=no-speculative-cti.

Alright?

Erik's second comment "We don't see the point in giving the choice on 
the JDK libraries ..." applies not to Hotspot, but to the rest of the 
native libraries (the "JDK libraries"). Here, we will just add the 
Spectre mitigation flags, without a user runtime choice of using 
hardened or non-hardened libraries. The reason for this is that the 
hardening did not have a measurable performance impact.

The builder of the JDK still has the ability to build the JDK libraries 
without the hardening flags, but that will require modifying the 
configure script, just as the case is today if the builder should wish 
to disable any other of all the flags we enable by default.

/Magnus



>
> David
> -----
>
>> If you want to have spectre mitigation enabled for both server and 
>> client, by default, you would just need to run "configure 
>> --with-jvm-variants=server,client 
>> --with-jvm-features=no-speculative-cti", which will enable that 
>> feature for all variants. That's not really hard *at all* for anyone 
>> building OpenJDK. And it's way clearer what will happen, than a 
>> --enable-hardened-hotspot.
>>
>> 4) If you are a downstream provider building OpenJDK and you are dead 
>> set on not including Spectre mitigations in the JDK libraries, 
>> despite being shown to have no negative effects, then you can do just 
>> as any other downstream user with highly specialized requirements, 
>> and patch the source. I have no sympathies for this; I can't stop it 
>> but I don't think there's any reason for us to complicate the code to 
>> support this unlikely case.
>>
>> So, to recap, I think the webrev as published in 
>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with 
>> "altserver" renamed to "hardened") is the way to go.
>>
>> /Magnus
>>
>>
>>
>>>
>>> /Erik
>>



From david.holmes at oracle.com  Mon Jun 11 08:24:11 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Jun 2018 18:24:11 +1000
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <37e8bd6d-b906-b9d1-6e41-2229236c9c8c@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
 <28729cf3-2951-6557-fb00-28ddf52fd110@oracle.com>
 <37e8bd6d-b906-b9d1-6e41-2229236c9c8c@oracle.com>
Message-ID: <dd41d1ed-834b-3e5a-efac-daf6df677f7e@oracle.com>

Sorry this is making my head spin.

Doh! jvm-features only apply to the JVM.

So I retract my last email - sorry.

And with that I'm going to just bow out. You and Erik can figure it out.

Thanks,
David

On 11/06/2018 6:19 PM, Magnus Ihse Bursie wrote:
> 
> On 2018-06-11 09:38, David Holmes wrote:
>> Hi Magnus,
>>
>> On 11/06/2018 5:10 PM, Magnus Ihse Bursie wrote:
>>> On 2018-06-08 23:50, Erik Joelsson wrote:
>>>> On 2018-06-07 17:30, David Holmes wrote:
>>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>>>> I just don't think the extra work is warranted or should be 
>>>>>> prioritized at this point. I also cannot think of a combination of 
>>>>>> options required for what you are suggesting that wouldn't be 
>>>>>> confusing to the user. If someone truly feels like these flags are 
>>>>>> forced on them and can't live with them, we or preferably that 
>>>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>>>> is still open source and anyone can contribute.
>>>>>
>>>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>>>> to add to the right flags would be either complicated or confusing.
>>>>>
>>>> For me the confusion surrounds the difference between 
>>>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened 
>>>> and making the user understand it. But sure, it is doable. Here is a 
>>>> new webrev with those two options as I interpret them. Here is the 
>>>> help text:
>>>>
>>>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>>>> ????????????????????????? libraries (except the JVM), typically 
>>>> disabling
>>>> ????????????????????????? speculative cti. [disabled]
>>>> ?--enable-hardened-hotspot
>>>> ????????????????????????? enable hardenening compiler flags for 
>>>> hotspot (all
>>>> ????????????????????????? jvm variants), typically disabling 
>>>> speculative cti.
>>>> ????????????????????????? To make hardening of hotspot a runtime 
>>>> choice,
>>>> ????????????????????????? consider the "hardened" jvm variant 
>>>> instead of this
>>>> ????????????????????????? option. [disabled]
>>>>
>>>> Note that this changes the default for jdk libraries to not enable 
>>>> hardening unless the user requests it.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>>
>>> Hold it, hold it! I'm not sure how we ended up here, but I don't like 
>>> it at all. :-(
>>>
>>> I think Eriks initial patch is much better than this. Some arguments 
>>> in random order to defend this position:
>>>
>>> 1) Why should we have a configure option to disable security relevant 
>>> flags for the JDK, if there has been no measured negative effect? We 
>>> don't do this for any other compiler flags, especially not security 
>>> relevant ones!
>>>
>>> I've re-read the entire thread to see if I could understand what 
>>> could possibly motivate this, but the only thing I can find is David 
>>> Holmes vague fear that these flags would not be well-tested enough. 
>>> Let me counter with my own vague guesses: I believe the spectre 
>>> mitigation methods to have been fully and properly tested, since they 
>>> are rolled-out massively on all products. And let me complement with 
>>> my own fear: the PR catastrophe if OpenJDK were *not* built with 
>>> spectre mitigations, and someone were to exploit that!
>>
>> All I'm looking for is the ability to select whether you can build 
>> with or without this "hardening". The default OpenJDK build can of 
>> course churn out a "hardened" implementation. Anyone who opts out of 
>> that is on their own.
> 
> With Erik's original proposal (webrev.02), you will, by default, get a 
> hotspot "server" JVM variant that is identical to what you got without 
> the patch. This should definitely cover your case.
> 
> You will also get all the non-hotspot libraries built as hardened. You 
> *can* get the JDK libraries built non-hardened, by removing the 
> ${$2NO_SPECULATIVE_CTI_CFLAGS} from the line 
> $1_CFLAGS_JDK="${$1_DEFINES_CPU_JDK} ${$1_CFLAGS_CPU} 
> ${$1_CFLAGS_CPU_JDK} ${$1_TOOLCHAIN_CFLAGS} 
> ${$2NO_SPECULATIVE_CTI_CFLAGS}".
> 
> As I said, I believe this is enough to support that case.
> 
>>
>> I don't share your faith or confidence in the quality of any software 
>> rushed out in a fairly short space of time. Prudence, if nothing else, 
>> says you should be able to not build this way IMHO.
> AFAIU, these compiler flags has received extensive testing inside 
> Oracle. It is also part of a global, high-visibility project, where key 
> players have had time to prepare for handling the issues ahead of the 
> public awareness of the exploits. *And* it's been almost half a year 
> since the Spectre exploit was made public.
> 
> I have much more faith in enabling these flags than I'd have for e.g. 
> upgrading to a newer version of Solaris Studio. :-)
> 
> 
>>
>>> In fact, I could even argue that "server" should be hardened *by 
>>> default*, and that we should instead introduce a non-hardened JVM 
>>> named something akin to "quick-but-dangerous-server" instead. But I 
>>> realize that a 25% performance hit is hard to swallow, so I won't 
>>> push this agenda.
>>>
>>> 2) It is by no means clear that "--enable-hardened-jdk" does not 
>>> harden all aspects of the JDK! If we should keep the option (which I 
>>> definitely do not think we should!) it should be renamed to 
>>> "--enable-hardened-libraries", or something like that. And it should 
>>> be on by default, so it should be a "--disabled-hardened-jdk-libraries".
>>>
>>> Also, the general-sounding name "hardened" sounds like it might 
>>> encompass more things than it does. What if I disabled a hardened jdk 
>>> build, should I still get stack banging protection? If so, you need 
>>> to move a lot more security-related flags to this option. (And, just 
>>> to be absolutely clear: I don't think you should do that.)
>>>
>>> 3) Having two completely different ways of turning on Spectre 
>>> protection for hotspot is just utterly confusing! This was a perfect 
>>> example of how to use the JVM features, just as in the original patch.
>>
>> Okay. I have had some confusion over "features" versus "variants" 
>> based on Eriks earlier comments. Erik's email from June 6 first states:
>>
>> "I agree, and you sort of can. By adding the jvm feature 
>> "no-speculative-cti" to any jvm variant, you get the flags."
>>
>> but then later said:
>>
>> "We don't see the point in giving the choice on the JDK libraries ..."
>>
>> by which I now think he meant not giving the choice at the VM variant 
>> level, but I mistook it for meaning at the "feature" level. Hence I 
>> came back with the two flags suggestion. If we can already select 
>> features arbitrarily at configure time then this is all addressed 
>> already.
>>
>> Apologies for the confusion.
> 
> Well, now *I* am confused. ;-)
> 
> Let's separarate two components: hotspot, and the rest of the native 
> code (the "JDK libraries").
> 
> For hotspot, the following holds:
> * You can enable or disable no-speculative-cti as a feature on the 
> configure command line, by "--with-jvm-features=no-speculative-cti" (to 
> enable) or "--with-jvm-features=-no-speculative-cti" (to disable). This 
> change applies to *all* JVM variants that are built; there is currently 
> no command-line support for enabling or disabling features on a 
> per-JVM-variant level. (There's no real hinderance to doing so; it's 
> just not yet implemented).
> * Erik defines a new JVM variant, which is identical to server, but has 
> also no-speculative-cti enabled. This is not built by default, but can 
> be enabled by --with-jvm-variants=server,hardened. Oracle will build 
> OpenJDK this way.
> 
> If you do not want hardening, you just do not build the "hardened" 
> variant, and you do not add the no-speculative-cti feature.
> 
> If you want hardening all over the line (and no runtime user choice), 
> you add --with-jvm-feature=no-speculative-cti.
> 
> Alright?
> 
> Erik's second comment "We don't see the point in giving the choice on 
> the JDK libraries ..." applies not to Hotspot, but to the rest of the 
> native libraries (the "JDK libraries"). Here, we will just add the 
> Spectre mitigation flags, without a user runtime choice of using 
> hardened or non-hardened libraries. The reason for this is that the 
> hardening did not have a measurable performance impact.
> 
> The builder of the JDK still has the ability to build the JDK libraries 
> without the hardening flags, but that will require modifying the 
> configure script, just as the case is today if the builder should wish 
> to disable any other of all the flags we enable by default.
> 
> /Magnus
> 
> 
> 
>>
>> David
>> -----
>>
>>> If you want to have spectre mitigation enabled for both server and 
>>> client, by default, you would just need to run "configure 
>>> --with-jvm-variants=server,client 
>>> --with-jvm-features=no-speculative-cti", which will enable that 
>>> feature for all variants. That's not really hard *at all* for anyone 
>>> building OpenJDK. And it's way clearer what will happen, than a 
>>> --enable-hardened-hotspot.
>>>
>>> 4) If you are a downstream provider building OpenJDK and you are dead 
>>> set on not including Spectre mitigations in the JDK libraries, 
>>> despite being shown to have no negative effects, then you can do just 
>>> as any other downstream user with highly specialized requirements, 
>>> and patch the source. I have no sympathies for this; I can't stop it 
>>> but I don't think there's any reason for us to complicate the code to 
>>> support this unlikely case.
>>>
>>> So, to recap, I think the webrev as published in 
>>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with 
>>> "altserver" renamed to "hardened") is the way to go.
>>>
>>> /Magnus
>>>
>>>
>>>
>>>>
>>>> /Erik
>>>
> 


From magnus at ihse.net  Mon Jun 11 08:50:35 2018
From: magnus at ihse.net (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 10:50:35 +0200
Subject: RFR: JDK-8204664 PrepareFailureLogs should be done after sequential
 make targets
Message-ID: <cc4c0af3-aea4-fe5d-083d-af6a0d8304c4@ihse.net>

When running a compound make line such as "make reconfigure clean 
jdk-image test-image", make will first single out the "sequential" 
targets reconfigure and clean, and execute them single-threaded, in 
sequence, and then it will build the remaining targets in parallel. 
However, the macro PrepareFailureLogs was called before this sequential 
calling, meaning that the directories created by it will be destroyed 
moments after by the clean target. The result is that if there is a 
compile error, the build will exit with something along these lines:

/bin/cp: cannot create regular file 
`/export/users/dh198349/jdk-dev2/build/linux-x64-debug/make-support/failure-logs/hotspot_variant-server_libjvm_objs_thread.o.log': 
No such file or directory
lib/CompileJvm.gmk:149: recipe for target 
'/export/users/dh198349/jdk-dev2/build/linux-x64-debug/hotspot/variant-server/libjvm/objs/thread.o' 
failed

Bug: https://bugs.openjdk.java.net/browse/JDK-8204664
Patch inline:
diff --git a/make/Init.gmk b/make/Init.gmk
--- a/make/Init.gmk
+++ b/make/Init.gmk
@@ -298,7 +298,6 @@
 ?? main: $(INIT_TARGETS)
 ???????? ifneq ($(SEQUENTIAL_TARGETS)$(PARALLEL_TARGETS), )
 ????????? $(call RotateLogFiles)
-???????? $(call PrepareFailureLogs)
 ????????? $(PRINTF) "Building $(TARGET_DESCRIPTION)\n" $(BUILD_LOG_PIPE)
 ?????????? ifneq ($(SEQUENTIAL_TARGETS), )
 ???????????? # Don't touch build output dir since we might be cleaning. 
That
@@ -308,6 +307,7 @@
 ??????????????? $(SEQUENTIAL_TARGETS) )
 ?????????? endif
 ?????????? ifneq ($(PARALLEL_TARGETS), )
+?????????? $(call PrepareFailureLogs)
 ??????????? $(call StartGlobalTimer)
 ??????????? $(call PrepareSmartJavac)
 ???????????? # JOBS will only be empty for a bootcycle-images recursive 
call

/Magnus


From magnus.ihse.bursie at oracle.com  Mon Jun 11 08:55:34 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 10:55:34 +0200
Subject: RFR: JDK-8204127: Change bundle format on Windows to zip
In-Reply-To: <7e9bd4c6-679d-388e-fbe8-9a7189b72e76@oracle.com>
References: <7e9bd4c6-679d-388e-fbe8-9a7189b72e76@oracle.com>
Message-ID: <7d0749ab-a29b-e82a-a431-075c66a8a49c@oracle.com>

On 2018-06-09 02:05, Erik Joelsson wrote:
> The compressed archive bundles we create are all tar.gz format. On 
> Windows that's not a very common format, requiring third party 
> applications to handle, while the zip format can be natively 
> extracted. This patch changes the bundle format for the JDK on Windows 
> to zip.
>
> This only applies to the actual product distributions. I think we 
> prefer tar.gz for all the internal bundles, like symbols and tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204127
>
> Webrev: http://cr.openjdk.java.net/~erikj/8204127/webrev.01
It's okay, but I think it would be nicer to do it like this:

ifeq ($(OPENJDK_TARGET_OS), windows) JDK_BUNDLE_EXTENSION := zip else 
JDK_BUNDLE_EXTENSION := tar.gz endif JDK_BUNDLE_NAME := 
jdk-$(BASE_NAME)_bin$(DEBUG_PART).$(JDK_BUNDLE_EXTENSION)


If you accept, you don't need to redo the review. If you disagree, push 
your version. :-)

/Magnus


>
> /Erik
>



From magnus.ihse.bursie at oracle.com  Mon Jun 11 13:29:47 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 15:29:47 +0200
Subject: RFR: JDK-8204682 Parsing for LOG=report=none is broken when combined
 with other keywords
Message-ID: <fbcab7d7-4366-b2b3-911d-4e2ecd30f723@oracle.com>

Parsing for LOG=report=none is broken when combined with other keywords, 
e.g. "LOG=info,report=none".

Bug: https://bugs.openjdk.java.net/browse/JDK-8204682
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8204682-LOG-report-parsing-broken/webrev.01

/Magnus


From volker.simonis at gmail.com  Mon Jun 11 14:48:58 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 11 Jun 2018 16:48:58 +0200
Subject: RFR(XS): 8204684: [AIX] Build of libjli_static broken after change
 8204572 (SetupJdkLibrary)
Message-ID: <CA+3eh11kCwqDS-Y_1wJ5RJ3ypUvb2x8vCOKLP1MRiN4KaGwb9w@mail.gmail.com>

Hi,

can I please have a review for the following trivial build change
which fixes a build problem on AIX when building libjli_static:

http://cr.openjdk.java.net/~simonis/webrevs/2018/8204684/
https://bugs.openjdk.java.net/browse/JDK-8204684

The reason is that change 8204572 forgot to add LIBJLI_SRC_DIRS as
include path for the libjli_static build.

Thank you and best regards,
Volker


From erik.joelsson at oracle.com  Mon Jun 11 15:42:26 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 08:42:26 -0700
Subject: RFR: JDK-8204664 PrepareFailureLogs should be done after
 sequential make targets
In-Reply-To: <cc4c0af3-aea4-fe5d-083d-af6a0d8304c4@ihse.net>
References: <cc4c0af3-aea4-fe5d-083d-af6a0d8304c4@ihse.net>
Message-ID: <84b35776-62ad-a4e1-f739-8624fde3665a@oracle.com>

Hello,

Looks ok. Perhaps this warrants a comment somewhere about the failure 
logs only working in parallel targets?

/Erik


On 2018-06-11 01:50, Magnus Ihse Bursie wrote:
> When running a compound make line such as "make reconfigure clean 
> jdk-image test-image", make will first single out the "sequential" 
> targets reconfigure and clean, and execute them single-threaded, in 
> sequence, and then it will build the remaining targets in parallel. 
> However, the macro PrepareFailureLogs was called before this 
> sequential calling, meaning that the directories created by it will be 
> destroyed moments after by the clean target. The result is that if 
> there is a compile error, the build will exit with something along 
> these lines:
>
> /bin/cp: cannot create regular file 
> `/export/users/dh198349/jdk-dev2/build/linux-x64-debug/make-support/failure-logs/hotspot_variant-server_libjvm_objs_thread.o.log': 
> No such file or directory
> lib/CompileJvm.gmk:149: recipe for target 
> '/export/users/dh198349/jdk-dev2/build/linux-x64-debug/hotspot/variant-server/libjvm/objs/thread.o' 
> failed
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204664
> Patch inline:
> diff --git a/make/Init.gmk b/make/Init.gmk
> --- a/make/Init.gmk
> +++ b/make/Init.gmk
> @@ -298,7 +298,6 @@
> ?? main: $(INIT_TARGETS)
> ???????? ifneq ($(SEQUENTIAL_TARGETS)$(PARALLEL_TARGETS), )
> ????????? $(call RotateLogFiles)
> -???????? $(call PrepareFailureLogs)
> ????????? $(PRINTF) "Building $(TARGET_DESCRIPTION)\n" $(BUILD_LOG_PIPE)
> ?????????? ifneq ($(SEQUENTIAL_TARGETS), )
> ???????????? # Don't touch build output dir since we might be 
> cleaning. That
> @@ -308,6 +307,7 @@
> ??????????????? $(SEQUENTIAL_TARGETS) )
> ?????????? endif
> ?????????? ifneq ($(PARALLEL_TARGETS), )
> +?????????? $(call PrepareFailureLogs)
> ??????????? $(call StartGlobalTimer)
> ??????????? $(call PrepareSmartJavac)
> ???????????? # JOBS will only be empty for a bootcycle-images 
> recursive call
>
> /Magnus


From erik.joelsson at oracle.com  Mon Jun 11 15:43:12 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 08:43:12 -0700
Subject: RFR: JDK-8204127: Change bundle format on Windows to zip
In-Reply-To: <7d0749ab-a29b-e82a-a431-075c66a8a49c@oracle.com>
References: <7e9bd4c6-679d-388e-fbe8-9a7189b72e76@oracle.com>
 <7d0749ab-a29b-e82a-a431-075c66a8a49c@oracle.com>
Message-ID: <590affbc-bf62-d76e-3936-5152d3115610@oracle.com>

I agree, will change.

/Erik


On 2018-06-11 01:55, Magnus Ihse Bursie wrote:
> On 2018-06-09 02:05, Erik Joelsson wrote:
>> The compressed archive bundles we create are all tar.gz format. On 
>> Windows that's not a very common format, requiring third party 
>> applications to handle, while the zip format can be natively 
>> extracted. This patch changes the bundle format for the JDK on 
>> Windows to zip.
>>
>> This only applies to the actual product distributions. I think we 
>> prefer tar.gz for all the internal bundles, like symbols and tests.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204127
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8204127/webrev.01
> It's okay, but I think it would be nicer to do it like this:
> ifeq ($(OPENJDK_TARGET_OS), windows) JDK_BUNDLE_EXTENSION := zip else 
> JDK_BUNDLE_EXTENSION := tar.gz endif JDK_BUNDLE_NAME := 
> jdk-$(BASE_NAME)_bin$(DEBUG_PART).$(JDK_BUNDLE_EXTENSION)
>
> If you accept, you don't need to redo the review. If you disagree, 
> push your version. :-)
>
> /Magnus
>
>
>>
>> /Erik
>>
>



From erik.joelsson at oracle.com  Mon Jun 11 15:44:01 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 08:44:01 -0700
Subject: RFR: JDK-8204682 Parsing for LOG=report=none is broken when
 combined with other keywords
In-Reply-To: <fbcab7d7-4366-b2b3-911d-4e2ecd30f723@oracle.com>
References: <fbcab7d7-4366-b2b3-911d-4e2ecd30f723@oracle.com>
Message-ID: <e49e023b-3a3d-387e-0956-3de3768dc9d8@oracle.com>

Looks good. Sneaky problem!

/Erik


On 2018-06-11 06:29, Magnus Ihse Bursie wrote:
> Parsing for LOG=report=none is broken when combined with other 
> keywords, e.g. "LOG=info,report=none".
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204682
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8204682-LOG-report-parsing-broken/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Mon Jun 11 15:45:12 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 08:45:12 -0700
Subject: RFR(XS): 8204684: [AIX] Build of libjli_static broken after
 change 8204572 (SetupJdkLibrary)
In-Reply-To: <CA+3eh11kCwqDS-Y_1wJ5RJ3ypUvb2x8vCOKLP1MRiN4KaGwb9w@mail.gmail.com>
References: <CA+3eh11kCwqDS-Y_1wJ5RJ3ypUvb2x8vCOKLP1MRiN4KaGwb9w@mail.gmail.com>
Message-ID: <da900442-c3c9-57f6-c1d4-6a235a934826@oracle.com>

Looks ok.

/Erik


On 2018-06-11 07:48, Volker Simonis wrote:
> Hi,
>
> can I please have a review for the following trivial build change
> which fixes a build problem on AIX when building libjli_static:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204684/
> https://bugs.openjdk.java.net/browse/JDK-8204684
>
> The reason is that change 8204572 forgot to add LIBJLI_SRC_DIRS as
> include path for the libjli_static build.
>
> Thank you and best regards,
> Volker



From thomas.stuefe at gmail.com  Mon Jun 11 15:59:30 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 11 Jun 2018 17:59:30 +0200
Subject: RFR(XS): 8204684: [AIX] Build of libjli_static broken after
 change 8204572 (SetupJdkLibrary)
In-Reply-To: <CA+3eh11kCwqDS-Y_1wJ5RJ3ypUvb2x8vCOKLP1MRiN4KaGwb9w@mail.gmail.com>
References: <CA+3eh11kCwqDS-Y_1wJ5RJ3ypUvb2x8vCOKLP1MRiN4KaGwb9w@mail.gmail.com>
Message-ID: <CAA-vtUw2eU10jpPaFKYqYKRBvfdAX6yFRbKL0LYJEySwerY2hw@mail.gmail.com>

This looks good and I can confirm fixes our AIX build,

Thanks for fixing!


..Thomas


On Mon, Jun 11, 2018 at 4:48 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> can I please have a review for the following trivial build change
> which fixes a build problem on AIX when building libjli_static:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204684/
> https://bugs.openjdk.java.net/browse/JDK-8204684
>
> The reason is that change 8204572 forgot to add LIBJLI_SRC_DIRS as
> include path for the libjli_static build.
>
> Thank you and best regards,
> Volker


From volker.simonis at gmail.com  Mon Jun 11 17:04:04 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 11 Jun 2018 19:04:04 +0200
Subject: RFR(XS): 8204684: [AIX] Build of libjli_static broken after
 change 8204572 (SetupJdkLibrary)
In-Reply-To: <CAA-vtUw2eU10jpPaFKYqYKRBvfdAX6yFRbKL0LYJEySwerY2hw@mail.gmail.com>
References: <CA+3eh11kCwqDS-Y_1wJ5RJ3ypUvb2x8vCOKLP1MRiN4KaGwb9w@mail.gmail.com>
 <CAA-vtUw2eU10jpPaFKYqYKRBvfdAX6yFRbKL0LYJEySwerY2hw@mail.gmail.com>
Message-ID: <CA+3eh104ByQ1KQyhgXET8v-EEMUu34yZppazgaU9=8PochVTpA@mail.gmail.com>

Hi Erik, Thomas,

thanks for the quick review!

Regards,
Volker

On Mon, Jun 11, 2018 at 5:59 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> This looks good and I can confirm fixes our AIX build,
>
> Thanks for fixing!
>
>
> ..Thomas
>
>
> On Mon, Jun 11, 2018 at 4:48 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> can I please have a review for the following trivial build change
>> which fixes a build problem on AIX when building libjli_static:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204684/
>> https://bugs.openjdk.java.net/browse/JDK-8204684
>>
>> The reason is that change 8204572 forgot to add LIBJLI_SRC_DIRS as
>> include path for the libjli_static build.
>>
>> Thank you and best regards,
>> Volker


From jbvernee at xs4all.nl  Mon Jun 11 14:38:40 2018
From: jbvernee at xs4all.nl (jbvernee)
Date: Mon, 11 Jun 2018 16:38:40 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
Message-ID: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>

Hello,

I've been trying to build the JDK using an msys2 toolchain, which seems 
to be possible according to this thread: 
http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019862.html 
(although I'm not trying to use gcc, I'm using VS 15). I know it's 
advised to use cygwin, but I can't get that to work at all on my machine 
(some error about base heap offset after a fresh install. I might try 
troubleshooting that next...)

I'm running into the error mentioned in the subject line while running 
`bash configure`, namely:

     LINK : fatal error LNK1104: cannot open file 
'J:J:/msys64/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'

I have also created a gist of the full configure log: 
https://gist.github.com/JornVernee/6b579e6d13d1fce306d0d370a381d1b3

Looking at this, it seems like the path is getting mangled. The correct 
path is 
'J:/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe' 
But as you can see there is an extra `J:/msys64` in there, which happens 
to be the root of my msys2 installation (though I'm running configure in 
PowerShell, and not in the included msys2 environment. Switching between 
them doesn't fix the problem either though).

I thought I had traced the value of this path to the `OUTPUTDIR` 
variable in `\make\autoconf\basics.m4`, where it is created inside this 
if-else block:

```
     if test "x$CUSTOM_ROOT" != x; then
       OUTPUTDIR="${CUSTOM_ROOT}/build/${CONF_NAME}"
     else
       OUTPUTDIR="${TOPDIR}/build/${CONF_NAME}"
     fi
```

Where it is then used to create the `CONFIGURESUPPORT_OUTPUTDIR` path 
like: `CONFIGURESUPPORT_OUTPUTDIR="$OUTPUTDIR/configure-support"`, and 
finally the output path for fixpath.exe is constructed from that in 
`\make\autoconf\basics_windows.m4`:

```
     FIXPATH_BIN="$CONFIGURESUPPORT_OUTPUTDIR/bin/fixpath.exe"
     FIXPATH_DIR="$CONFIGURESUPPORT_OUTPUTDIR/fixpath"
```

I have tried setting the `CUSTOM_ROOT` variable, but the error remained 
the same. As a sanity check I rewrote the if-statement to: 
`OUTPUTDIR="J:/Projects/openjdk/amber/build/${CONF_NAME}", but the error 
message still remains the same.

I have also tried manually compiling fixpath.c into fixpath.exe and 
placing that file into 
`/build/windows-x86_64-normal-server-release/configure-support/bin/`, 
but the file is just ignored by the configuration script.

At this point I don't know what else I could try. So I'm wondering if 
anyone here has any suggestions?

Best regards,
Jorn Vernee


From erik.joelsson at oracle.com  Mon Jun 11 17:51:37 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 10:51:37 -0700
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
Message-ID: <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>

Hello Jorn,

I don't have access to an msys2 environment to try this myself and as we 
don't regularly build there, it's unfortunately not expected to work. 
Msys has a habit of trying to outsmart the user when treating paths, by 
automatically converting path formats from unix style to windows style 
by trying to detect what kind of process is receiving it. In my 
experience, this automatic behavior trips you up more often than it 
helps you and it looks like that is what's happening here.

The tool fixpath.exe is our internal solution to the path troubles. We 
build it in configure and then use it to convert paths to windows style 
for any process that we know need it. Unfortunately for you, your setup 
is failing before managing to create the tool itself.

I would try to supply the value for the variable in Unix style 
(/j/msys/...) and see if msys converts it correctly then.

/Erik


On 2018-06-11 07:38, jbvernee wrote:
> Hello,
>
> I've been trying to build the JDK using an msys2 toolchain, which 
> seems to be possible according to this thread: 
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019862.html 
> (although I'm not trying to use gcc, I'm using VS 15). I know it's 
> advised to use cygwin, but I can't get that to work at all on my 
> machine (some error about base heap offset after a fresh install. I 
> might try troubleshooting that next...)
>
> I'm running into the error mentioned in the subject line while running 
> `bash configure`, namely:
>
> ??? LINK : fatal error LNK1104: cannot open file 
> 'J:J:/msys64/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>
> I have also created a gist of the full configure log: 
> https://gist.github.com/JornVernee/6b579e6d13d1fce306d0d370a381d1b3
>
> Looking at this, it seems like the path is getting mangled. The 
> correct path is 
> 'J:/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe' 
> But as you can see there is an extra `J:/msys64` in there, which 
> happens to be the root of my msys2 installation (though I'm running 
> configure in PowerShell, and not in the included msys2 environment. 
> Switching between them doesn't fix the problem either though).
>
> I thought I had traced the value of this path to the `OUTPUTDIR` 
> variable in `\make\autoconf\basics.m4`, where it is created inside 
> this if-else block:
>
> ```
> ??? if test "x$CUSTOM_ROOT" != x; then
> ????? OUTPUTDIR="${CUSTOM_ROOT}/build/${CONF_NAME}"
> ??? else
> ????? OUTPUTDIR="${TOPDIR}/build/${CONF_NAME}"
> ??? fi
> ```
>
> Where it is then used to create the `CONFIGURESUPPORT_OUTPUTDIR` path 
> like: `CONFIGURESUPPORT_OUTPUTDIR="$OUTPUTDIR/configure-support"`, and 
> finally the output path for fixpath.exe is constructed from that in 
> `\make\autoconf\basics_windows.m4`:
>
> ```
> ??? FIXPATH_BIN="$CONFIGURESUPPORT_OUTPUTDIR/bin/fixpath.exe"
> ??? FIXPATH_DIR="$CONFIGURESUPPORT_OUTPUTDIR/fixpath"
> ```
>
> I have tried setting the `CUSTOM_ROOT` variable, but the error 
> remained the same. As a sanity check I rewrote the if-statement to: 
> `OUTPUTDIR="J:/Projects/openjdk/amber/build/${CONF_NAME}", but the 
> error message still remains the same.
>
> I have also tried manually compiling fixpath.c into fixpath.exe and 
> placing that file into 
> `/build/windows-x86_64-normal-server-release/configure-support/bin/`, 
> but the file is just ignored by the configuration script.
>
> At this point I don't know what else I could try. So I'm wondering if 
> anyone here has any suggestions?
>
> Best regards,
> Jorn Vernee



From magnus.ihse.bursie at oracle.com  Mon Jun 11 18:09:12 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Jun 2018 20:09:12 +0200
Subject: RFR: JDK-8204664 PrepareFailureLogs should be done after
 sequential make targets
In-Reply-To: <84b35776-62ad-a4e1-f739-8624fde3665a@oracle.com>
References: <cc4c0af3-aea4-fe5d-083d-af6a0d8304c4@ihse.net>
 <84b35776-62ad-a4e1-f739-8624fde3665a@oracle.com>
Message-ID: <aa5c99a2-9797-6d20-2605-9653b82e6f12@oracle.com>



On 2018-06-11 17:42, Erik Joelsson wrote:
> Hello,
>
> Looks ok. Perhaps this warrants a comment somewhere about the failure 
> logs only working in parallel targets?

Do you mean a comment in the code, or in the build documentation?

/Magnus

>
> /Erik
>
>
> On 2018-06-11 01:50, Magnus Ihse Bursie wrote:
>> When running a compound make line such as "make reconfigure clean 
>> jdk-image test-image", make will first single out the "sequential" 
>> targets reconfigure and clean, and execute them single-threaded, in 
>> sequence, and then it will build the remaining targets in parallel. 
>> However, the macro PrepareFailureLogs was called before this 
>> sequential calling, meaning that the directories created by it will 
>> be destroyed moments after by the clean target. The result is that if 
>> there is a compile error, the build will exit with something along 
>> these lines:
>>
>> /bin/cp: cannot create regular file 
>> `/export/users/dh198349/jdk-dev2/build/linux-x64-debug/make-support/failure-logs/hotspot_variant-server_libjvm_objs_thread.o.log': 
>> No such file or directory
>> lib/CompileJvm.gmk:149: recipe for target 
>> '/export/users/dh198349/jdk-dev2/build/linux-x64-debug/hotspot/variant-server/libjvm/objs/thread.o' 
>> failed
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204664
>> Patch inline:
>> diff --git a/make/Init.gmk b/make/Init.gmk
>> --- a/make/Init.gmk
>> +++ b/make/Init.gmk
>> @@ -298,7 +298,6 @@
>> ?? main: $(INIT_TARGETS)
>> ???????? ifneq ($(SEQUENTIAL_TARGETS)$(PARALLEL_TARGETS), )
>> ????????? $(call RotateLogFiles)
>> -???????? $(call PrepareFailureLogs)
>> ????????? $(PRINTF) "Building $(TARGET_DESCRIPTION)\n" $(BUILD_LOG_PIPE)
>> ?????????? ifneq ($(SEQUENTIAL_TARGETS), )
>> ???????????? # Don't touch build output dir since we might be 
>> cleaning. That
>> @@ -308,6 +307,7 @@
>> ??????????????? $(SEQUENTIAL_TARGETS) )
>> ?????????? endif
>> ?????????? ifneq ($(PARALLEL_TARGETS), )
>> +?????????? $(call PrepareFailureLogs)
>> ??????????? $(call StartGlobalTimer)
>> ??????????? $(call PrepareSmartJavac)
>> ???????????? # JOBS will only be empty for a bootcycle-images 
>> recursive call
>>
>> /Magnus
>



From erik.joelsson at oracle.com  Mon Jun 11 19:07:56 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 12:07:56 -0700
Subject: RFR: JDK-8204664 PrepareFailureLogs should be done after
 sequential make targets
In-Reply-To: <aa5c99a2-9797-6d20-2605-9653b82e6f12@oracle.com>
References: <cc4c0af3-aea4-fe5d-083d-af6a0d8304c4@ihse.net>
 <84b35776-62ad-a4e1-f739-8624fde3665a@oracle.com>
 <aa5c99a2-9797-6d20-2605-9653b82e6f12@oracle.com>
Message-ID: <9dce8b13-7568-edde-df0a-b398ecef8ceb@oracle.com>

On 2018-06-11 11:09, Magnus Ihse Bursie wrote:
>
>
> On 2018-06-11 17:42, Erik Joelsson wrote:
>> Hello,
>>
>> Looks ok. Perhaps this warrants a comment somewhere about the failure 
>> logs only working in parallel targets?
>
> Do you mean a comment in the code, or in the build documentation?
>
I'm thinking in the code, to remind us in the future when we edit in 
these areas.

/Erik
> /Magnus
>
>>
>> /Erik
>>
>>
>> On 2018-06-11 01:50, Magnus Ihse Bursie wrote:
>>> When running a compound make line such as "make reconfigure clean 
>>> jdk-image test-image", make will first single out the "sequential" 
>>> targets reconfigure and clean, and execute them single-threaded, in 
>>> sequence, and then it will build the remaining targets in parallel. 
>>> However, the macro PrepareFailureLogs was called before this 
>>> sequential calling, meaning that the directories created by it will 
>>> be destroyed moments after by the clean target. The result is that 
>>> if there is a compile error, the build will exit with something 
>>> along these lines:
>>>
>>> /bin/cp: cannot create regular file 
>>> `/export/users/dh198349/jdk-dev2/build/linux-x64-debug/make-support/failure-logs/hotspot_variant-server_libjvm_objs_thread.o.log': 
>>> No such file or directory
>>> lib/CompileJvm.gmk:149: recipe for target 
>>> '/export/users/dh198349/jdk-dev2/build/linux-x64-debug/hotspot/variant-server/libjvm/objs/thread.o' 
>>> failed
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204664
>>> Patch inline:
>>> diff --git a/make/Init.gmk b/make/Init.gmk
>>> --- a/make/Init.gmk
>>> +++ b/make/Init.gmk
>>> @@ -298,7 +298,6 @@
>>> ?? main: $(INIT_TARGETS)
>>> ???????? ifneq ($(SEQUENTIAL_TARGETS)$(PARALLEL_TARGETS), )
>>> ????????? $(call RotateLogFiles)
>>> -???????? $(call PrepareFailureLogs)
>>> ????????? $(PRINTF) "Building $(TARGET_DESCRIPTION)\n" 
>>> $(BUILD_LOG_PIPE)
>>> ?????????? ifneq ($(SEQUENTIAL_TARGETS), )
>>> ???????????? # Don't touch build output dir since we might be 
>>> cleaning. That
>>> @@ -308,6 +307,7 @@
>>> ??????????????? $(SEQUENTIAL_TARGETS) )
>>> ?????????? endif
>>> ?????????? ifneq ($(PARALLEL_TARGETS), )
>>> +?????????? $(call PrepareFailureLogs)
>>> ??????????? $(call StartGlobalTimer)
>>> ??????????? $(call PrepareSmartJavac)
>>> ???????????? # JOBS will only be empty for a bootcycle-images 
>>> recursive call
>>>
>>> /Magnus
>>
>



From jbvernee at xs4all.nl  Mon Jun 11 20:00:02 2018
From: jbvernee at xs4all.nl (jbvernee)
Date: Mon, 11 Jun 2018 22:00:02 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
Message-ID: <67183278662bad531e2e89439bb98658@xs4all.nl>

Hello Erik,

Thank you for the suggestion. Unfortunately it didn't help. TBH, I've 
been banging my head against trying to build the JDK on my machine on 
and off for a few months. So at this point I really appreciate any help 
that gets me even an inch further, thanks.

After your suggestion, I have tracked down the call site of the compile 
command and checked the paths that are being used in basics_windows.m4 
(line 406) to compile fixpath.exe:

```
     cd $FIXPATH_DIR
     $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
2>&1
     cd $CURDIR
```
They are:
$CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
$FIXPATH_BIN_W = 
J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
$FIXPATH_DIR = 
/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath

Note that the second one is a windows style path. I can change that to 
use the unix style path, and that does affect the error message, I now 
see: 
`'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'` 
as the path in the linker error. But of course the Visual Studios linker 
can't do anything with a unix style path.

What's weird is that either path is working for the C compiler (cl), but 
it is being mangled before being passed to the linker, and I can't find 
where the linker command is actually being fired off. It seems to be 
done by that same line. I was hoping you could tell me more about that?

One other idea I had, but haven't been able to implement, is to check 
whether the fixpath tool exists before trying to compile it. That way I 
could just compile it manually. I have tried this snippet in 
basics_windows.m4 at line 404:
```
     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
     cd $CURDIR
     if test ! -x $FIXPATH_BIN; then
       cd $FIXPATH_DIR
       $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
2>&1
       cd $CURDIR
     fi
```

i.e. check if fixpath.exe exists, otherwise compile it (I don't know the 
source language though, so I just copied that from somewhere else). That 
didn't work, the check seems to be failing and it's still trying to 
compile (and I don't know why, I hope it's not a tabs vs. spaces 
issue?). I also tried just commenting that part out completely, but it's 
STILL trying to compile. I have no idea why that is happening a this 
point. It's also immediately spitting out 'no' after printing 'checking 
if fixpath can be created...', even before all the output from the 
compiler, so it almost seems like the command is being fired off from 
somewhere else? Or maybe it's just a race condition, idk.

If you have any more suggestions I really appreciate it, but if it's too 
much trouble for an unsupported build system I understand.

Best regards,
Jorn Vernee

Erik Joelsson schreef op 2018-06-11 19:51:
> Hello Jorn,
> 
> I don't have access to an msys2 environment to try this myself and as
> we don't regularly build there, it's unfortunately not expected to
> work. Msys has a habit of trying to outsmart the user when treating
> paths, by automatically converting path formats from unix style to
> windows style by trying to detect what kind of process is receiving
> it. In my experience, this automatic behavior trips you up more often
> than it helps you and it looks like that is what's happening here.
> 
> The tool fixpath.exe is our internal solution to the path troubles. We
> build it in configure and then use it to convert paths to windows
> style for any process that we know need it. Unfortunately for you,
> your setup is failing before managing to create the tool itself.
> 
> I would try to supply the value for the variable in Unix style
> (/j/msys/...) and see if msys converts it correctly then.
> 
> /Erik
> 
> 
> On 2018-06-11 07:38, jbvernee wrote:
>> Hello,
>> 
>> I've been trying to build the JDK using an msys2 toolchain, which 
>> seems to be possible according to this thread: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019862.html 
>> (although I'm not trying to use gcc, I'm using VS 15). I know it's 
>> advised to use cygwin, but I can't get that to work at all on my 
>> machine (some error about base heap offset after a fresh install. I 
>> might try troubleshooting that next...)
>> 
>> I'm running into the error mentioned in the subject line while running 
>> `bash configure`, namely:
>> 
>> ??? LINK : fatal error LNK1104: cannot open file 
>> 'J:J:/msys64/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>> 
>> I have also created a gist of the full configure log: 
>> https://gist.github.com/JornVernee/6b579e6d13d1fce306d0d370a381d1b3
>> 
>> Looking at this, it seems like the path is getting mangled. The 
>> correct path is 
>> 'J:/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe' 
>> But as you can see there is an extra `J:/msys64` in there, which 
>> happens to be the root of my msys2 installation (though I'm running 
>> configure in PowerShell, and not in the included msys2 environment. 
>> Switching between them doesn't fix the problem either though).
>> 
>> I thought I had traced the value of this path to the `OUTPUTDIR` 
>> variable in `\make\autoconf\basics.m4`, where it is created inside 
>> this if-else block:
>> 
>> ```
>> ??? if test "x$CUSTOM_ROOT" != x; then
>> ????? OUTPUTDIR="${CUSTOM_ROOT}/build/${CONF_NAME}"
>> ??? else
>> ????? OUTPUTDIR="${TOPDIR}/build/${CONF_NAME}"
>> ??? fi
>> ```
>> 
>> Where it is then used to create the `CONFIGURESUPPORT_OUTPUTDIR` path 
>> like: `CONFIGURESUPPORT_OUTPUTDIR="$OUTPUTDIR/configure-support"`, and 
>> finally the output path for fixpath.exe is constructed from that in 
>> `\make\autoconf\basics_windows.m4`:
>> 
>> ```
>> ??? FIXPATH_BIN="$CONFIGURESUPPORT_OUTPUTDIR/bin/fixpath.exe"
>> ??? FIXPATH_DIR="$CONFIGURESUPPORT_OUTPUTDIR/fixpath"
>> ```
>> 
>> I have tried setting the `CUSTOM_ROOT` variable, but the error 
>> remained the same. As a sanity check I rewrote the if-statement to: 
>> `OUTPUTDIR="J:/Projects/openjdk/amber/build/${CONF_NAME}", but the 
>> error message still remains the same.
>> 
>> I have also tried manually compiling fixpath.c into fixpath.exe and 
>> placing that file into 
>> `/build/windows-x86_64-normal-server-release/configure-support/bin/`, 
>> but the file is just ignored by the configuration script.
>> 
>> At this point I don't know what else I could try. So I'm wondering if 
>> anyone here has any suggestions?
>> 
>> Best regards,
>> Jorn Vernee


From erik.joelsson at oracle.com  Mon Jun 11 20:19:25 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 13:19:25 -0700
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <67183278662bad531e2e89439bb98658@xs4all.nl>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
Message-ID: <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>

Hello,

On 2018-06-11 13:00, jbvernee wrote:
> Hello Erik,
>
> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've 
> been banging my head against trying to build the JDK on my machine on 
> and off for a few months. So at this point I really appreciate any 
> help that gets me even an inch further, thanks.
>
> After your suggestion, I have tracked down the call site of the 
> compile command and checked the paths that are being used in 
> basics_windows.m4 (line 406) to compile fixpath.exe:
>
> ```
> ??? cd $FIXPATH_DIR
> ??? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 2>&1
> ??? cd $CURDIR
> ```
> They are:
> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
> $FIXPATH_BIN_W = 
> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> $FIXPATH_DIR = 
> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
>
> Note that the second one is a windows style path. I can change that to 
> use the unix style path, and that does affect the error message, I now 
> see: 
> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'` 
> as the path in the linker error. But of course the Visual Studios 
> linker can't do anything with a unix style path.
>
> What's weird is that either path is working for the C compiler (cl), 
> but it is being mangled before being passed to the linker, and I can't 
> find where the linker command is actually being fired off. It seems to 
> be done by that same line. I was hoping you could tell me more about 
> that?
>
AFAIK, we compile fixpath from a single source file directly into an 
executable, so it's cl that calls link. Somewhere along the way, msys 
decides to mangle your path argument incorrectly. You could try using 
MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly 
how it works but I know you can affect the mangling using this env variable.
> One other idea I had, but haven't been able to implement, is to check 
> whether the fixpath tool exists before trying to compile it. That way 
> I could just compile it manually. I have tried this snippet in 
> basics_windows.m4 at line 404:
> ```
> ??? #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
> ??? #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
> ??? cd $CURDIR
> ??? if test ! -x $FIXPATH_BIN; then
> ????? cd $FIXPATH_DIR
> ????? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
> 2>&1
> ????? cd $CURDIR
> ??? fi
> ```
>
> i.e. check if fixpath.exe exists, otherwise compile it (I don't know 
> the source language though, so I just copied that from somewhere 
> else). That didn't work, the check seems to be failing and it's still 
> trying to compile (and I don't know why, I hope it's not a tabs vs. 
> spaces issue?). I also tried just commenting that part out completely, 
> but it's STILL trying to compile. I have no idea why that is happening 
> a this point. It's also immediately spitting out 'no' after printing 
> 'checking if fixpath can be created...', even before all the output 
> from the compiler, so it almost seems like the command is being fired 
> off from somewhere else? Or maybe it's just a race condition, idk.
>
What version of OpenJDK are you trying to build? As in which repository 
did you clone. Depending on which, you may need to explicitly regenerate 
the configure script after making changes to .m4 files. There is a 
script, autogen.sh, in the same directory as the .m4 files to do it 
correctly. This requires autoconf 2.69 to be available.

The language in .m4 is autoconf, which (in our case) is bash shell with 
m4 macros on top. Most of the source, including your snippet above is 
just bash. So your change above looks correct, you just need to get it 
to be used. You could try changing the -x to -e in case execute 
permissions aren't translated properly between msys and windows.

/Erik
> If you have any more suggestions I really appreciate it, but if it's 
> too much trouble for an unsupported build system I understand.
>
> Best regards,
> Jorn Vernee
>
> Erik Joelsson schreef op 2018-06-11 19:51:
>> Hello Jorn,
>>
>> I don't have access to an msys2 environment to try this myself and as
>> we don't regularly build there, it's unfortunately not expected to
>> work. Msys has a habit of trying to outsmart the user when treating
>> paths, by automatically converting path formats from unix style to
>> windows style by trying to detect what kind of process is receiving
>> it. In my experience, this automatic behavior trips you up more often
>> than it helps you and it looks like that is what's happening here.
>>
>> The tool fixpath.exe is our internal solution to the path troubles. We
>> build it in configure and then use it to convert paths to windows
>> style for any process that we know need it. Unfortunately for you,
>> your setup is failing before managing to create the tool itself.
>>
>> I would try to supply the value for the variable in Unix style
>> (/j/msys/...) and see if msys converts it correctly then.
>>
>> /Erik
>>
>>
>> On 2018-06-11 07:38, jbvernee wrote:
>>> Hello,
>>>
>>> I've been trying to build the JDK using an msys2 toolchain, which 
>>> seems to be possible according to this thread: 
>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019862.html 
>>> (although I'm not trying to use gcc, I'm using VS 15). I know it's 
>>> advised to use cygwin, but I can't get that to work at all on my 
>>> machine (some error about base heap offset after a fresh install. I 
>>> might try troubleshooting that next...)
>>>
>>> I'm running into the error mentioned in the subject line while 
>>> running `bash configure`, namely:
>>>
>>> ??? LINK : fatal error LNK1104: cannot open file 
>>> 'J:J:/msys64/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>>>
>>> I have also created a gist of the full configure log: 
>>> https://gist.github.com/JornVernee/6b579e6d13d1fce306d0d370a381d1b3
>>>
>>> Looking at this, it seems like the path is getting mangled. The 
>>> correct path is 
>>> 'J:/Projects/openjdk/amber/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe' 
>>> But as you can see there is an extra `J:/msys64` in there, which 
>>> happens to be the root of my msys2 installation (though I'm running 
>>> configure in PowerShell, and not in the included msys2 environment. 
>>> Switching between them doesn't fix the problem either though).
>>>
>>> I thought I had traced the value of this path to the `OUTPUTDIR` 
>>> variable in `\make\autoconf\basics.m4`, where it is created inside 
>>> this if-else block:
>>>
>>> ```
>>> ??? if test "x$CUSTOM_ROOT" != x; then
>>> ????? OUTPUTDIR="${CUSTOM_ROOT}/build/${CONF_NAME}"
>>> ??? else
>>> ????? OUTPUTDIR="${TOPDIR}/build/${CONF_NAME}"
>>> ??? fi
>>> ```
>>>
>>> Where it is then used to create the `CONFIGURESUPPORT_OUTPUTDIR` 
>>> path like: 
>>> `CONFIGURESUPPORT_OUTPUTDIR="$OUTPUTDIR/configure-support"`, and 
>>> finally the output path for fixpath.exe is constructed from that in 
>>> `\make\autoconf\basics_windows.m4`:
>>>
>>> ```
>>> ??? FIXPATH_BIN="$CONFIGURESUPPORT_OUTPUTDIR/bin/fixpath.exe"
>>> ??? FIXPATH_DIR="$CONFIGURESUPPORT_OUTPUTDIR/fixpath"
>>> ```
>>>
>>> I have tried setting the `CUSTOM_ROOT` variable, but the error 
>>> remained the same. As a sanity check I rewrote the if-statement to: 
>>> `OUTPUTDIR="J:/Projects/openjdk/amber/build/${CONF_NAME}", but the 
>>> error message still remains the same.
>>>
>>> I have also tried manually compiling fixpath.c into fixpath.exe and 
>>> placing that file into 
>>> `/build/windows-x86_64-normal-server-release/configure-support/bin/`, 
>>> but the file is just ignored by the configuration script.
>>>
>>> At this point I don't know what else I could try. So I'm wondering 
>>> if anyone here has any suggestions?
>>>
>>> Best regards,
>>> Jorn Vernee



From erik.joelsson at oracle.com  Mon Jun 11 20:42:49 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Jun 2018 13:42:49 -0700
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
Message-ID: <fce1411e-8ec9-d2e4-8e63-8662867634a7@oracle.com>

Hello,

Based on the discussion here, I have reverted back to something more 
similar to webrev.02, but with a few changes. Mainly fixing a bug that 
caused JVM_FEATURES_hardened to not actually be the same as for server 
(if you have custom additions in configure). I also added a check so 
that configure fails if you try to enable either variant hardened or 
feature no-speculative-cti and the flags aren't available.

Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html

/Erik

On 2018-06-11 00:10, Magnus Ihse Bursie wrote:
> On 2018-06-08 23:50, Erik Joelsson wrote:
>> On 2018-06-07 17:30, David Holmes wrote:
>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>> I just don't think the extra work is warranted or should be 
>>>> prioritized at this point. I also cannot think of a combination of 
>>>> options required for what you are suggesting that wouldn't be 
>>>> confusing to the user. If someone truly feels like these flags are 
>>>> forced on them and can't live with them, we or preferably that 
>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>> is still open source and anyone can contribute.
>>>
>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>> to add to the right flags would be either complicated or confusing.
>>>
>> For me the confusion surrounds the difference between 
>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened 
>> and making the user understand it. But sure, it is doable. Here is a 
>> new webrev with those two options as I interpret them. Here is the 
>> help text:
>>
>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>> ????????????????????????? libraries (except the JVM), typically 
>> disabling
>> ????????????????????????? speculative cti. [disabled]
>> ?--enable-hardened-hotspot
>> ????????????????????????? enable hardenening compiler flags for 
>> hotspot (all
>> ????????????????????????? jvm variants), typically disabling 
>> speculative cti.
>> ????????????????????????? To make hardening of hotspot a runtime choice,
>> ????????????????????????? consider the "hardened" jvm variant instead 
>> of this
>> ????????????????????????? option. [disabled]
>>
>> Note that this changes the default for jdk libraries to not enable 
>> hardening unless the user requests it.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>
> Hold it, hold it! I'm not sure how we ended up here, but I don't like 
> it at all. :-(
>
> I think Eriks initial patch is much better than this. Some arguments 
> in random order to defend this position:
>
> 1) Why should we have a configure option to disable security relevant 
> flags for the JDK, if there has been no measured negative effect? We 
> don't do this for any other compiler flags, especially not security 
> relevant ones!
>
> I've re-read the entire thread to see if I could understand what could 
> possibly motivate this, but the only thing I can find is David Holmes 
> vague fear that these flags would not be well-tested enough. Let me 
> counter with my own vague guesses: I believe the spectre mitigation 
> methods to have been fully and properly tested, since they are 
> rolled-out massively on all products. And let me complement with my 
> own fear: the PR catastrophe if OpenJDK were *not* built with spectre 
> mitigations, and someone were to exploit that!
>
> In fact, I could even argue that "server" should be hardened *by 
> default*, and that we should instead introduce a non-hardened JVM 
> named something akin to "quick-but-dangerous-server" instead. But I 
> realize that a 25% performance hit is hard to swallow, so I won't push 
> this agenda.
>
> 2) It is by no means clear that "--enable-hardened-jdk" does not 
> harden all aspects of the JDK! If we should keep the option (which I 
> definitely do not think we should!) it should be renamed to 
> "--enable-hardened-libraries", or something like that. And it should 
> be on by default, so it should be a "--disabled-hardened-jdk-libraries".
>
> Also, the general-sounding name "hardened" sounds like it might 
> encompass more things than it does. What if I disabled a hardened jdk 
> build, should I still get stack banging protection? If so, you need to 
> move a lot more security-related flags to this option. (And, just to 
> be absolutely clear: I don't think you should do that.)
>
> 3) Having two completely different ways of turning on Spectre 
> protection for hotspot is just utterly confusing! This was a perfect 
> example of how to use the JVM features, just as in the original patch.
>
> If you want to have spectre mitigation enabled for both server and 
> client, by default, you would just need to run "configure 
> --with-jvm-variants=server,client 
> --with-jvm-features=no-speculative-cti", which will enable that 
> feature for all variants. That's not really hard *at all* for anyone 
> building OpenJDK. And it's way clearer what will happen, than a 
> --enable-hardened-hotspot.
>
> 4) If you are a downstream provider building OpenJDK and you are dead 
> set on not including Spectre mitigations in the JDK libraries, despite 
> being shown to have no negative effects, then you can do just as any 
> other downstream user with highly specialized requirements, and patch 
> the source. I have no sympathies for this; I can't stop it but I don't 
> think there's any reason for us to complicate the code to support this 
> unlikely case.
>
> So, to recap, I think the webrev as published in 
> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with "altserver" 
> renamed to "hardened") is the way to go.
>
> /Magnus
>
>
>
>>
>> /Erik
>



From jbvernee at xs4all.nl  Mon Jun 11 21:26:32 2018
From: jbvernee at xs4all.nl (jbvernee)
Date: Mon, 11 Jun 2018 23:26:32 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
Message-ID: <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>

Hello,

I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks for 
the suggestion. It's supposed to be a semi-colon separated list of 
argument prefixes (they have some examples like 
`/switch;/sdcard;--root=`), so I tried setting it to `/out:`, `-Fe` 
(from the .m4 file) and `/out`, and also just the entire path that is 
being mangled. But none of them worked :( (still the same error).

I'm trying to build the amber repo, which I think is parallel with 
jdk/jdk tip? Any ways, there is no autogen.sh in /make/autoconf and 
anytime I make changes to the .m4 file it mentions something about 
having to regenerate the configure file. I can also see the changes I 
make in `/build/.configure-support/generated-configure.sh`, which 
currently looks like this (the part I mentioned):

```
     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
     cd $CURDIR
     echo "#####################" here
     #if test ! -x $FIXPATH_BIN; then
     #  cd $FIXPATH_DIR
     #  $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
2>&1
     #  cd $CURDIR
     #fi
     echo "#####################" there

     if test ! -x $FIXPATH_BIN; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }
       cat $FIXPATH_DIR/fixpath1.log
       as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5
     fi
```

Which gives me this output (the last few lines):

```
checking if fixpath can be created...
##################### here
##################### there
no
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
configure: error: Could not create 
/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe
J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning C4477: 
'fprintf' : format string '%s' requires an argument of type 'char *', 
but variadic argument 3 has type 'LPVOID'
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
fixpath.obj
LINK : fatal error LNK1104: cannot open file 
'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
configure exiting with result code 1
```

So the changes I'm making seem to be going through... well... at least 
as far as the echo statements go. I also tried using -e on the check 
that is not comment out, but with no different results (I'm also using 
autoconf 2.69 btw). This is kind of a head scratcher ?h. I'm calling it 
a night, I think I'll also try taking this up with the msys guys, some 
other time.

Thanks for the help so far,
Jorn Vernee

Erik Joelsson schreef op 2018-06-11 22:19:
> Hello,
> 
> On 2018-06-11 13:00, jbvernee wrote:
>> Hello Erik,
>> 
>> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've 
>> been banging my head against trying to build the JDK on my machine on 
>> and off for a few months. So at this point I really appreciate any 
>> help that gets me even an inch further, thanks.
>> 
>> After your suggestion, I have tracked down the call site of the 
>> compile command and checked the paths that are being used in 
>> basics_windows.m4 (line 406) to compile fixpath.exe:
>> 
>> ```
>> ??? cd $FIXPATH_DIR
>> ??? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
>> 2>&1
>> ??? cd $CURDIR
>> ```
>> They are:
>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
>> $FIXPATH_BIN_W = 
>> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>> $FIXPATH_DIR = 
>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
>> 
>> Note that the second one is a windows style path. I can change that to 
>> use the unix style path, and that does affect the error message, I now 
>> see: 
>> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'` 
>> as the path in the linker error. But of course the Visual Studios 
>> linker can't do anything with a unix style path.
>> 
>> What's weird is that either path is working for the C compiler (cl), 
>> but it is being mangled before being passed to the linker, and I can't 
>> find where the linker command is actually being fired off. It seems to 
>> be done by that same line. I was hoping you could tell me more about 
>> that?
>> 
> AFAIK, we compile fixpath from a single source file directly into an
> executable, so it's cl that calls link. Somewhere along the way, msys
> decides to mangle your path argument incorrectly. You could try using
> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly
> how it works but I know you can affect the mangling using this env
> variable.
>> One other idea I had, but haven't been able to implement, is to check 
>> whether the fixpath tool exists before trying to compile it. That way 
>> I could just compile it manually. I have tried this snippet in 
>> basics_windows.m4 at line 404:
>> ```
>> ??? #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>> ??? #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>> ??? cd $CURDIR
>> ??? if test ! -x $FIXPATH_BIN; then
>> ????? cd $FIXPATH_DIR
>> ????? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
>> 2>&1
>> ????? cd $CURDIR
>> ??? fi
>> ```
>> 
>> i.e. check if fixpath.exe exists, otherwise compile it (I don't know 
>> the source language though, so I just copied that from somewhere 
>> else). That didn't work, the check seems to be failing and it's still 
>> trying to compile (and I don't know why, I hope it's not a tabs vs. 
>> spaces issue?). I also tried just commenting that part out completely, 
>> but it's STILL trying to compile. I have no idea why that is happening 
>> a this point. It's also immediately spitting out 'no' after printing 
>> 'checking if fixpath can be created...', even before all the output 
>> from the compiler, so it almost seems like the command is being fired 
>> off from somewhere else? Or maybe it's just a race condition, idk.
>> 
> What version of OpenJDK are you trying to build? As in which
> repository did you clone. Depending on which, you may need to
> explicitly regenerate the configure script after making changes to .m4
> files. There is a script, autogen.sh, in the same directory as the .m4
> files to do it correctly. This requires autoconf 2.69 to be available.
> 
> The language in .m4 is autoconf, which (in our case) is bash shell
> with m4 macros on top. Most of the source, including your snippet
> above is just bash. So your change above looks correct, you just need
> to get it to be used. You could try changing the -x to -e in case
> execute permissions aren't translated properly between msys and
> windows.
> 
> /Erik
>> If you have any more suggestions I really appreciate it, but if it's 
>> too much trouble for an unsupported build system I understand.
>> 
>> Best regards,
>> Jorn Vernee
>> 


From jesper.wilhelmsson at oracle.com  Mon Jun 11 21:31:43 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Mon, 11 Jun 2018 23:31:43 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <fce1411e-8ec9-d2e4-8e63-8662867634a7@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
 <fce1411e-8ec9-d2e4-8e63-8662867634a7@oracle.com>
Message-ID: <59120A4F-7DD8-412B-9E4B-8898071A30D7@oracle.com>

Looks good to me.
/Jesper

> On 11 Jun 2018, at 22:42, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> Based on the discussion here, I have reverted back to something more similar to webrev.02, but with a few changes. Mainly fixing a bug that caused JVM_FEATURES_hardened to not actually be the same as for server (if you have custom additions in configure). I also added a check so that configure fails if you try to enable either variant hardened or feature no-speculative-cti and the flags aren't available.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html
> 
> /Erik
> 
> On 2018-06-11 00:10, Magnus Ihse Bursie wrote:
>> On 2018-06-08 23:50, Erik Joelsson wrote:
>>> On 2018-06-07 17:30, David Holmes wrote:
>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>>> I just don't think the extra work is warranted or should be prioritized at this point. I also cannot think of a combination of options required for what you are suggesting that wouldn't be confusing to the user. If someone truly feels like these flags are forced on them and can't live with them, we or preferably that person can fix it then. I don't think that's dictatorship. OpenJDK is still open source and anyone can contribute.
>>>> 
>>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot to add to the right flags would be either complicated or confusing.
>>>> 
>>> For me the confusion surrounds the difference between --enable-hardened-hotspot and --with-jvm-variants=server, hardened and making the user understand it. But sure, it is doable. Here is a new webrev with those two options as I interpret them. Here is the help text:
>>> 
>>>  --enable-hardened-jdk   enable hardenening compiler flags for all jdk
>>>                           libraries (except the JVM), typically disabling
>>>                           speculative cti. [disabled]
>>>  --enable-hardened-hotspot
>>>                           enable hardenening compiler flags for hotspot (all
>>>                           jvm variants), typically disabling speculative cti.
>>>                           To make hardening of hotspot a runtime choice,
>>>                           consider the "hardened" jvm variant instead of this
>>>                           option. [disabled]
>>> 
>>> Note that this changes the default for jdk libraries to not enable hardening unless the user requests it.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>> 
>> Hold it, hold it! I'm not sure how we ended up here, but I don't like it at all. :-(
>> 
>> I think Eriks initial patch is much better than this. Some arguments in random order to defend this position:
>> 
>> 1) Why should we have a configure option to disable security relevant flags for the JDK, if there has been no measured negative effect? We don't do this for any other compiler flags, especially not security relevant ones!
>> 
>> I've re-read the entire thread to see if I could understand what could possibly motivate this, but the only thing I can find is David Holmes vague fear that these flags would not be well-tested enough. Let me counter with my own vague guesses: I believe the spectre mitigation methods to have been fully and properly tested, since they are rolled-out massively on all products. And let me complement with my own fear: the PR catastrophe if OpenJDK were *not* built with spectre mitigations, and someone were to exploit that!
>> 
>> In fact, I could even argue that "server" should be hardened *by default*, and that we should instead introduce a non-hardened JVM named something akin to "quick-but-dangerous-server" instead. But I realize that a 25% performance hit is hard to swallow, so I won't push this agenda.
>> 
>> 2) It is by no means clear that "--enable-hardened-jdk" does not harden all aspects of the JDK! If we should keep the option (which I definitely do not think we should!) it should be renamed to "--enable-hardened-libraries", or something like that. And it should be on by default, so it should be a "--disabled-hardened-jdk-libraries".
>> 
>> Also, the general-sounding name "hardened" sounds like it might encompass more things than it does. What if I disabled a hardened jdk build, should I still get stack banging protection? If so, you need to move a lot more security-related flags to this option. (And, just to be absolutely clear: I don't think you should do that.)
>> 
>> 3) Having two completely different ways of turning on Spectre protection for hotspot is just utterly confusing! This was a perfect example of how to use the JVM features, just as in the original patch.
>> 
>> If you want to have spectre mitigation enabled for both server and client, by default, you would just need to run "configure --with-jvm-variants=server,client --with-jvm-features=no-speculative-cti", which will enable that feature for all variants. That's not really hard *at all* for anyone building OpenJDK. And it's way clearer what will happen, than a --enable-hardened-hotspot.
>> 
>> 4) If you are a downstream provider building OpenJDK and you are dead set on not including Spectre mitigations in the JDK libraries, despite being shown to have no negative effects, then you can do just as any other downstream user with highly specialized requirements, and patch the source. I have no sympathies for this; I can't stop it but I don't think there's any reason for us to complicate the code to support this unlikely case.
>> 
>> So, to recap, I think the webrev as published in http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with "altserver" renamed to "hardened") is the way to go.
>> 
>> /Magnus
>> 
>> 
>> 
>>> 
>>> /Erik
>> 
> 



From vladimir.kozlov at oracle.com  Tue Jun 12 01:15:15 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 11 Jun 2018 18:15:15 -0700
Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same
 version as build toolchain
Message-ID: <e29d70f8-8205-35c4-e03a-ea89a7296539@oracle.com>

http://cr.openjdk.java.net/~kvn/8204113/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8204113

AOT tests need a local linker to generate AOT libraries. They load 
devkits from our infrastructure when there is no local linker on testing 
machine. The names of devkits are hardcoded in AotCompiler.java (java 
wrapper which launches 'jaotc' tool).

We recently updated compilers for JDK 11. As result devkit names in 
AotCompiler.java should be updated too.

Tested by running AOT tests on all our supported platforms.

-- 
Thanks,
Vladimir


From igor.ignatyev at oracle.com  Tue Jun 12 01:21:16 2018
From: igor.ignatyev at oracle.com (Igor Ignatev)
Date: Mon, 11 Jun 2018 18:21:16 -0700
Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same
 version as build toolchain
In-Reply-To: <e29d70f8-8205-35c4-e03a-ea89a7296539@oracle.com>
References: <e29d70f8-8205-35c4-e03a-ea89a7296539@oracle.com>
Message-ID: <C2E8EAD2-F052-498D-95A9-50FDBE93F3AA@oracle.com>

Hi Vladimir,

The fix looks good to me. 

? Igor

> On Jun 11, 2018, at 6:15 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~kvn/8204113/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8204113
> 
> AOT tests need a local linker to generate AOT libraries. They load devkits from our infrastructure when there is no local linker on testing machine. The names of devkits are hardcoded in AotCompiler.java (java wrapper which launches 'jaotc' tool).
> 
> We recently updated compilers for JDK 11. As result devkit names in AotCompiler.java should be updated too.
> 
> Tested by running AOT tests on all our supported platforms.
> 
> -- 
> Thanks,
> Vladimir



From david.holmes at oracle.com  Tue Jun 12 06:06:32 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jun 2018 16:06:32 +1000
Subject: RFR: JDK-8204602 Add devkit for linux-arm32
In-Reply-To: <60cefd2e-5e11-c967-2287-b1860d92f397@oracle.com>
References: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
 <298ff9c4-c716-c28d-43c4-0c3029e98de8@oracle.com>
 <60cefd2e-5e11-c967-2287-b1860d92f397@oracle.com>
Message-ID: <8da35d05-4f68-e52a-f35f-40c20e75b267@oracle.com>

On 11/06/2018 4:46 PM, Magnus Ihse Bursie wrote:
> On 2018-06-10 15:35, David Holmes wrote:
>> On 8/06/2018 6:38 PM, Magnus Ihse Bursie wrote:
>>> With some simple changes, our devkit scripts can be made to generate 
>>> devkits for cross-compiling on linux-x64 to linux-arm (32-bit). Also 
>>> add a jib profile to use this new linux-arm devkit, as opposed to the 
>>> legacy devkits used by the traditional linux-arm profiles.
>>
>> I'm not at all clear what this is providing or for whom. The legacy 
>> linux-arm-vfp-hflt requires pointers to the X11R6 installation to 
>> build. The linux-arm32 jib-profile has none, but instead lists 
>> freetype as being bundled. ??
> 
> The target audience here is mainly Erik and me (and the Hotspot 
> engineers who have requested a simple way to build the arm port). This 
> provides us with an up-to-date, standard configured, devkit for building 
> arm-32.
> 
> In contrast to the legacy jib profile, we now have a devkit that is 
> build according to our standard, so configure need a minimal amount of 
> flags (hence no X11 flags). The bundled freetype is to simplify things; 
> we now have a version of freetype included in the OpenJDK source, and 
> it's by far the easiest to use it, rather than to include it in the 
> devkit, but this is not enabled by default on linux-arm.
> 
> I hope that answers your questions!

Yes - thanks. I'm not sure the legacy jib profile serves any purpose now 
- or even if it still builds.

David

> /Magnus
> 
>>
>> David
>>
>>> Note that this change does not imply any change in Oracle's support 
>>> of the linux-arm platform.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204602
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8204602-add-linux-arm-32-devkit/webrev.01 
>>>
>>>
>>> /Magnus
> 


From magnus.ihse.bursie at oracle.com  Tue Jun 12 06:25:47 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 12 Jun 2018 08:25:47 +0200
Subject: RFR: JDK-8204602 Add devkit for linux-arm32
In-Reply-To: <8da35d05-4f68-e52a-f35f-40c20e75b267@oracle.com>
References: <a29d6d32-6de8-6734-9ad8-acc6805e7041@oracle.com>
 <298ff9c4-c716-c28d-43c4-0c3029e98de8@oracle.com>
 <60cefd2e-5e11-c967-2287-b1860d92f397@oracle.com>
 <8da35d05-4f68-e52a-f35f-40c20e75b267@oracle.com>
Message-ID: <fd166ad7-97b7-691e-5dee-1e7b8f4e01ca@oracle.com>



On 2018-06-12 08:06, David Holmes wrote:
> On 11/06/2018 4:46 PM, Magnus Ihse Bursie wrote:
>> On 2018-06-10 15:35, David Holmes wrote:
>>> On 8/06/2018 6:38 PM, Magnus Ihse Bursie wrote:
>>>> With some simple changes, our devkit scripts can be made to 
>>>> generate devkits for cross-compiling on linux-x64 to linux-arm 
>>>> (32-bit). Also add a jib profile to use this new linux-arm devkit, 
>>>> as opposed to the legacy devkits used by the traditional linux-arm 
>>>> profiles.
>>>
>>> I'm not at all clear what this is providing or for whom. The legacy 
>>> linux-arm-vfp-hflt requires pointers to the X11R6 installation to 
>>> build. The linux-arm32 jib-profile has none, but instead lists 
>>> freetype as being bundled. ??
>>
>> The target audience here is mainly Erik and me (and the Hotspot 
>> engineers who have requested a simple way to build the arm port). 
>> This provides us with an up-to-date, standard configured, devkit for 
>> building arm-32.
>>
>> In contrast to the legacy jib profile, we now have a devkit that is 
>> build according to our standard, so configure need a minimal amount 
>> of flags (hence no X11 flags). The bundled freetype is to simplify 
>> things; we now have a version of freetype included in the OpenJDK 
>> source, and it's by far the easiest to use it, rather than to include 
>> it in the devkit, but this is not enabled by default on linux-arm.
>>
>> I hope that answers your questions!
>
> Yes - thanks. I'm not sure the legacy jib profile serves any purpose 
> now - or even if it still builds.
I'm not sure either if it serves any purpose, but I dared not remove it 
at this point. :) (Oh no, am I getting old and conservative? ;-))

/Magnus

>
> David
>
>> /Magnus
>>
>>>
>>> David
>>>
>>>> Note that this change does not imply any change in Oracle's support 
>>>> of the linux-arm platform.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204602
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8204602-add-linux-arm-32-devkit/webrev.01 
>>>>
>>>>
>>>> /Magnus
>>



From magnus.ihse.bursie at oracle.com  Tue Jun 12 06:29:03 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 12 Jun 2018 08:29:03 +0200
Subject: RFR: JDK-8202384: Introduce altserver jvm variant with
 speculative execution disabled
In-Reply-To: <fce1411e-8ec9-d2e4-8e63-8662867634a7@oracle.com>
References: <feac73f4-0b8f-6084-d90e-f533f14e94af@oracle.com>
 <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com>
 <a5ae73f1-211f-b5a6-4f92-c080107d9603@oracle.com>
 <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com>
 <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com>
 <80471236-7511-45fa-86d4-05a2500c5752@oracle.com>
 <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com>
 <d3010683-7410-7e1a-4041-94cd1bcf7b3d@oracle.com>
 <CD7E5125-8BE2-4153-A5FA-83BE41A2EDBA@oracle.com>
 <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com>
 <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com>
 <a2e2649c-f0be-e154-21a7-65ca442c6222@oracle.com>
 <f8566e8a-46f1-8253-70d9-9bf0472bb428@oracle.com>
 <fce1411e-8ec9-d2e4-8e63-8662867634a7@oracle.com>
Message-ID: <53309106-f59d-f086-e20a-a3d6eb544dda@oracle.com>



On 2018-06-11 22:42, Erik Joelsson wrote:
> Hello,
>
> Based on the discussion here, I have reverted back to something more 
> similar to webrev.02, but with a few changes. Mainly fixing a bug that 
> caused JVM_FEATURES_hardened to not actually be the same as for server 
> (if you have custom additions in configure). I also added a check so 
> that configure fails if you try to enable either variant hardened or 
> feature no-speculative-cti and the flags aren't available.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html
 ?Looks good to me. Thanks for all the effort!

/Magnus

>
> /Erik
>
> On 2018-06-11 00:10, Magnus Ihse Bursie wrote:
>> On 2018-06-08 23:50, Erik Joelsson wrote:
>>> On 2018-06-07 17:30, David Holmes wrote:
>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>>> I just don't think the extra work is warranted or should be 
>>>>> prioritized at this point. I also cannot think of a combination of 
>>>>> options required for what you are suggesting that wouldn't be 
>>>>> confusing to the user. If someone truly feels like these flags are 
>>>>> forced on them and can't live with them, we or preferably that 
>>>>> person can fix it then. I don't think that's dictatorship. OpenJDK 
>>>>> is still open source and anyone can contribute.
>>>>
>>>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot 
>>>> to add to the right flags would be either complicated or confusing.
>>>>
>>> For me the confusion surrounds the difference between 
>>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened 
>>> and making the user understand it. But sure, it is doable. Here is a 
>>> new webrev with those two options as I interpret them. Here is the 
>>> help text:
>>>
>>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk
>>> ????????????????????????? libraries (except the JVM), typically 
>>> disabling
>>> ????????????????????????? speculative cti. [disabled]
>>> ?--enable-hardened-hotspot
>>> ????????????????????????? enable hardenening compiler flags for 
>>> hotspot (all
>>> ????????????????????????? jvm variants), typically disabling 
>>> speculative cti.
>>> ????????????????????????? To make hardening of hotspot a runtime 
>>> choice,
>>> ????????????????????????? consider the "hardened" jvm variant 
>>> instead of this
>>> ????????????????????????? option. [disabled]
>>>
>>> Note that this changes the default for jdk libraries to not enable 
>>> hardening unless the user requests it.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>
>> Hold it, hold it! I'm not sure how we ended up here, but I don't like 
>> it at all. :-(
>>
>> I think Eriks initial patch is much better than this. Some arguments 
>> in random order to defend this position:
>>
>> 1) Why should we have a configure option to disable security relevant 
>> flags for the JDK, if there has been no measured negative effect? We 
>> don't do this for any other compiler flags, especially not security 
>> relevant ones!
>>
>> I've re-read the entire thread to see if I could understand what 
>> could possibly motivate this, but the only thing I can find is David 
>> Holmes vague fear that these flags would not be well-tested enough. 
>> Let me counter with my own vague guesses: I believe the spectre 
>> mitigation methods to have been fully and properly tested, since they 
>> are rolled-out massively on all products. And let me complement with 
>> my own fear: the PR catastrophe if OpenJDK were *not* built with 
>> spectre mitigations, and someone were to exploit that!
>>
>> In fact, I could even argue that "server" should be hardened *by 
>> default*, and that we should instead introduce a non-hardened JVM 
>> named something akin to "quick-but-dangerous-server" instead. But I 
>> realize that a 25% performance hit is hard to swallow, so I won't 
>> push this agenda.
>>
>> 2) It is by no means clear that "--enable-hardened-jdk" does not 
>> harden all aspects of the JDK! If we should keep the option (which I 
>> definitely do not think we should!) it should be renamed to 
>> "--enable-hardened-libraries", or something like that. And it should 
>> be on by default, so it should be a "--disabled-hardened-jdk-libraries".
>>
>> Also, the general-sounding name "hardened" sounds like it might 
>> encompass more things than it does. What if I disabled a hardened jdk 
>> build, should I still get stack banging protection? If so, you need 
>> to move a lot more security-related flags to this option. (And, just 
>> to be absolutely clear: I don't think you should do that.)
>>
>> 3) Having two completely different ways of turning on Spectre 
>> protection for hotspot is just utterly confusing! This was a perfect 
>> example of how to use the JVM features, just as in the original patch.
>>
>> If you want to have spectre mitigation enabled for both server and 
>> client, by default, you would just need to run "configure 
>> --with-jvm-variants=server,client 
>> --with-jvm-features=no-speculative-cti", which will enable that 
>> feature for all variants. That's not really hard *at all* for anyone 
>> building OpenJDK. And it's way clearer what will happen, than a 
>> --enable-hardened-hotspot.
>>
>> 4) If you are a downstream provider building OpenJDK and you are dead 
>> set on not including Spectre mitigations in the JDK libraries, 
>> despite being shown to have no negative effects, then you can do just 
>> as any other downstream user with highly specialized requirements, 
>> and patch the source. I have no sympathies for this; I can't stop it 
>> but I don't think there's any reason for us to complicate the code to 
>> support this unlikely case.
>>
>> So, to recap, I think the webrev as published in 
>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with 
>> "altserver" renamed to "hardened") is the way to go.
>>
>> /Magnus
>>
>>
>>
>>>
>>> /Erik
>>
>



From magnus.ihse.bursie at oracle.com  Tue Jun 12 06:53:15 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 12 Jun 2018 08:53:15 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
Message-ID: <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>

Hi Jorn,

As you probably have understood by now, porting OpenJDK to msys2 is not 
just a simple quick fix. If all you want is to build OpenJDK on your 
Windows computer, you are probably better off by trying to fix your 
Cygwin installation. From your description, it sounds like you'll need 
to rebase it: http://cygwin.wikia.com/wiki/Rebaseall.

If you want to pursue the msys2 path (and I'd appreciate it; it would be 
good to get OpenJDK working on msys again), I suggest you start by 
looking at the work that had been done before (but never merged into 
mainline). See this conversation:

http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html

Peter Budai got the msys part working, but he had more ambitious goals 
of getting gcc to build on Windows, which is magnitudes more work, so 
his patch was never finished. Nevertheless, he published a patch in [1] 
which got stripped by the mailing list. I've put it up here:

http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch

It is for jdk9 so it's not possibly to apply out of the box, but you can 
probably see what's been done and trying to reimplement it. I think the 
"magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which 
disables msys2 path mangling.

Good luck!

/Magnus

[1] 
http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html


On 2018-06-11 23:26, jbvernee wrote:
> Hello,
>
> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks for 
> the suggestion. It's supposed to be a semi-colon separated list of 
> argument prefixes (they have some examples like 
> `/switch;/sdcard;--root=`), so I tried setting it to `/out:`, `-Fe` 
> (from the .m4 file) and `/out`, and also just the entire path that is 
> being mangled. But none of them worked :( (still the same error).
>
> I'm trying to build the amber repo, which I think is parallel with 
> jdk/jdk tip? Any ways, there is no autogen.sh in /make/autoconf and 
> anytime I make changes to the .m4 file it mentions something about 
> having to regenerate the configure file. I can also see the changes I 
> make in `/build/.configure-support/generated-configure.sh`, which 
> currently looks like this (the part I mentioned):
>
> ```
> ??? #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
> ??? #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
> ??? cd $CURDIR
> ??? echo "#####################" here
> ??? #if test ! -x $FIXPATH_BIN; then
> ??? #? cd $FIXPATH_DIR
> ??? #? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > 
> $FIXPATH_DIR/fixpath1.log 2>&1
> ??? #? cd $CURDIR
> ??? #fi
> ??? echo "#####################" there
>
> ??? if test ! -x $FIXPATH_BIN; then
> ????? { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> $as_echo "no" >&6; }
> ????? cat $FIXPATH_DIR/fixpath1.log
> ????? as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5
> ??? fi
> ```
>
> Which gives me this output (the last few lines):
>
> ```
> checking if fixpath can be created...
> ##################### here
> ##################### there
> no
> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
> Copyright (C) Microsoft Corporation.? All rights reserved.
> configure: error: Could not create 
> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe
> J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning 
> C4477: 'fprintf' : format string '%s' requires an argument of type 
> 'char *', but variadic argument 3 has type 'LPVOID'
> Microsoft (R) Incremental Linker Version 14.00.24215.1
> Copyright (C) Microsoft Corporation.? All rights reserved.
>
> /out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe 
>
> fixpath.obj
> LINK : fatal error LNK1104: cannot open file 
> 'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
> configure exiting with result code 1
> ```
>
> So the changes I'm making seem to be going through... well... at least 
> as far as the echo statements go. I also tried using -e on the check 
> that is not comment out, but with no different results (I'm also using 
> autoconf 2.69 btw). This is kind of a head scratcher ?h. I'm calling 
> it a night, I think I'll also try taking this up with the msys guys, 
> some other time.
>
> Thanks for the help so far,
> Jorn Vernee
>
> Erik Joelsson schreef op 2018-06-11 22:19:
>> Hello,
>>
>> On 2018-06-11 13:00, jbvernee wrote:
>>> Hello Erik,
>>>
>>> Thank you for the suggestion. Unfortunately it didn't help. TBH, 
>>> I've been banging my head against trying to build the JDK on my 
>>> machine on and off for a few months. So at this point I really 
>>> appreciate any help that gets me even an inch further, thanks.
>>>
>>> After your suggestion, I have tracked down the call site of the 
>>> compile command and checked the paths that are being used in 
>>> basics_windows.m4 (line 406) to compile fixpath.exe:
>>>
>>> ```
>>> ??? cd $FIXPATH_DIR
>>> ??? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log 
>>> 2>&1
>>> ??? cd $CURDIR
>>> ```
>>> They are:
>>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
>>> $FIXPATH_BIN_W = 
>>> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>>> $FIXPATH_DIR = 
>>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
>>>
>>> Note that the second one is a windows style path. I can change that 
>>> to use the unix style path, and that does affect the error message, 
>>> I now see: 
>>> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'` 
>>> as the path in the linker error. But of course the Visual Studios 
>>> linker can't do anything with a unix style path.
>>>
>>> What's weird is that either path is working for the C compiler (cl), 
>>> but it is being mangled before being passed to the linker, and I 
>>> can't find where the linker command is actually being fired off. It 
>>> seems to be done by that same line. I was hoping you could tell me 
>>> more about that?
>>>
>> AFAIK, we compile fixpath from a single source file directly into an
>> executable, so it's cl that calls link. Somewhere along the way, msys
>> decides to mangle your path argument incorrectly. You could try using
>> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly
>> how it works but I know you can affect the mangling using this env
>> variable.
>>> One other idea I had, but haven't been able to implement, is to 
>>> check whether the fixpath tool exists before trying to compile it. 
>>> That way I could just compile it manually. I have tried this snippet 
>>> in basics_windows.m4 at line 404:
>>> ```
>>> ??? #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>> ??? #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>> ??? cd $CURDIR
>>> ??? if test ! -x $FIXPATH_BIN; then
>>> ????? cd $FIXPATH_DIR
>>> ????? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > 
>>> $FIXPATH_DIR/fixpath1.log 2>&1
>>> ????? cd $CURDIR
>>> ??? fi
>>> ```
>>>
>>> i.e. check if fixpath.exe exists, otherwise compile it (I don't know 
>>> the source language though, so I just copied that from somewhere 
>>> else). That didn't work, the check seems to be failing and it's 
>>> still trying to compile (and I don't know why, I hope it's not a 
>>> tabs vs. spaces issue?). I also tried just commenting that part out 
>>> completely, but it's STILL trying to compile. I have no idea why 
>>> that is happening a this point. It's also immediately spitting out 
>>> 'no' after printing 'checking if fixpath can be created...', even 
>>> before all the output from the compiler, so it almost seems like the 
>>> command is being fired off from somewhere else? Or maybe it's just a 
>>> race condition, idk.
>>>
>> What version of OpenJDK are you trying to build? As in which
>> repository did you clone. Depending on which, you may need to
>> explicitly regenerate the configure script after making changes to .m4
>> files. There is a script, autogen.sh, in the same directory as the .m4
>> files to do it correctly. This requires autoconf 2.69 to be available.
>>
>> The language in .m4 is autoconf, which (in our case) is bash shell
>> with m4 macros on top. Most of the source, including your snippet
>> above is just bash. So your change above looks correct, you just need
>> to get it to be used. You could try changing the -x to -e in case
>> execute permissions aren't translated properly between msys and
>> windows.
>>
>> /Erik
>>> If you have any more suggestions I really appreciate it, but if it's 
>>> too much trouble for an unsupported build system I understand.
>>>
>>> Best regards,
>>> Jorn Vernee
>>>



From thomas.stuefe at gmail.com  Tue Jun 12 09:49:00 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 12 Jun 2018 11:49:00 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
Message-ID: <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>

I second the advice to get cygwin up and running. Cygwin is the
canonical way to build on windows. Unless you have really pressing
reasons to use something else, I would use what (almost) everyone else
uses.

I have my windows build env up and running on a fresh windows machine
usually in ~30 minutes. It should not be rocket science. I use both
windows 7 and 10 for my work.

Some more points, in additions to what the others wrote:

- 64bit seems to be the standard: 64bit windows, building 64bit ojdk
with a 64bit cygwin. Other configurations may work but are less well
tested. Just something to keep in mind.

- If you do not trust your windows machine and suspect its software
stack may be messed up somehow, there is always the option of
installing a fresh copy of windows in a virtual machine, e.g.
VirtualBox, and install the tool chain from scratch (cygwin + vistual
studio).

Best Regards & good luck,

Thomas




On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> Hi Jorn,
>
> As you probably have understood by now, porting OpenJDK to msys2 is not just
> a simple quick fix. If all you want is to build OpenJDK on your Windows
> computer, you are probably better off by trying to fix your Cygwin
> installation. From your description, it sounds like you'll need to rebase
> it: http://cygwin.wikia.com/wiki/Rebaseall.
>
> If you want to pursue the msys2 path (and I'd appreciate it; it would be
> good to get OpenJDK working on msys again), I suggest you start by looking
> at the work that had been done before (but never merged into mainline). See
> this conversation:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html
>
> Peter Budai got the msys part working, but he had more ambitious goals of
> getting gcc to build on Windows, which is magnitudes more work, so his patch
> was never finished. Nevertheless, he published a patch in [1] which got
> stripped by the mailing list. I've put it up here:
>
> http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch
>
> It is for jdk9 so it's not possibly to apply out of the box, but you can
> probably see what's been done and trying to reimplement it. I think the
> "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
> disables msys2 path mangling.
>
> Good luck!
>
> /Magnus
>
> [1]
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html
>
>
>
> On 2018-06-11 23:26, jbvernee wrote:
>>
>> Hello,
>>
>> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks for the
>> suggestion. It's supposed to be a semi-colon separated list of argument
>> prefixes (they have some examples like `/switch;/sdcard;--root=`), so I
>> tried setting it to `/out:`, `-Fe` (from the .m4 file) and `/out`, and also
>> just the entire path that is being mangled. But none of them worked :(
>> (still the same error).
>>
>> I'm trying to build the amber repo, which I think is parallel with jdk/jdk
>> tip? Any ways, there is no autogen.sh in /make/autoconf and anytime I make
>> changes to the .m4 file it mentions something about having to regenerate the
>> configure file. I can also see the changes I make in
>> `/build/.configure-support/generated-configure.sh`, which currently looks
>> like this (the part I mentioned):
>>
>> ```
>>     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>     cd $CURDIR
>>     echo "#####################" here
>>     #if test ! -x $FIXPATH_BIN; then
>>     #  cd $FIXPATH_DIR
>>     #  $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>> 2>&1
>>     #  cd $CURDIR
>>     #fi
>>     echo "#####################" there
>>
>>     if test ! -x $FIXPATH_BIN; then
>>       { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
>> $as_echo "no" >&6; }
>>       cat $FIXPATH_DIR/fixpath1.log
>>       as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5
>>     fi
>> ```
>>
>> Which gives me this output (the last few lines):
>>
>> ```
>> checking if fixpath can be created...
>> ##################### here
>> ##################### there
>> no
>> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>> configure: error: Could not create
>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe
>> J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning C4477:
>> 'fprintf' : format string '%s' requires an argument of type 'char *', but
>> variadic argument 3 has type 'LPVOID'
>> Microsoft (R) Incremental Linker Version 14.00.24215.1
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>>
>> /out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>> fixpath.obj
>> LINK : fatal error LNK1104: cannot open file
>> 'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>> configure exiting with result code 1
>> ```
>>
>> So the changes I'm making seem to be going through... well... at least as
>> far as the echo statements go. I also tried using -e on the check that is
>> not comment out, but with no different results (I'm also using autoconf 2.69
>> btw). This is kind of a head scratcher ?h. I'm calling it a night, I think
>> I'll also try taking this up with the msys guys, some other time.
>>
>> Thanks for the help so far,
>> Jorn Vernee
>>
>> Erik Joelsson schreef op 2018-06-11 22:19:
>>>
>>> Hello,
>>>
>>> On 2018-06-11 13:00, jbvernee wrote:
>>>>
>>>> Hello Erik,
>>>>
>>>> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've
>>>> been banging my head against trying to build the JDK on my machine on and
>>>> off for a few months. So at this point I really appreciate any help that
>>>> gets me even an inch further, thanks.
>>>>
>>>> After your suggestion, I have tracked down the call site of the compile
>>>> command and checked the paths that are being used in basics_windows.m4 (line
>>>> 406) to compile fixpath.exe:
>>>>
>>>> ```
>>>>     cd $FIXPATH_DIR
>>>>     $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>>>> 2>&1
>>>>     cd $CURDIR
>>>> ```
>>>> They are:
>>>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
>>>> $FIXPATH_BIN_W =
>>>> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>>>> $FIXPATH_DIR =
>>>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
>>>>
>>>> Note that the second one is a windows style path. I can change that to
>>>> use the unix style path, and that does affect the error message, I now see:
>>>> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'`
>>>> as the path in the linker error. But of course the Visual Studios linker
>>>> can't do anything with a unix style path.
>>>>
>>>> What's weird is that either path is working for the C compiler (cl), but
>>>> it is being mangled before being passed to the linker, and I can't find
>>>> where the linker command is actually being fired off. It seems to be done by
>>>> that same line. I was hoping you could tell me more about that?
>>>>
>>> AFAIK, we compile fixpath from a single source file directly into an
>>> executable, so it's cl that calls link. Somewhere along the way, msys
>>> decides to mangle your path argument incorrectly. You could try using
>>> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly
>>> how it works but I know you can affect the mangling using this env
>>> variable.
>>>>
>>>> One other idea I had, but haven't been able to implement, is to check
>>>> whether the fixpath tool exists before trying to compile it. That way I
>>>> could just compile it manually. I have tried this snippet in
>>>> basics_windows.m4 at line 404:
>>>> ```
>>>>     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>>>     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>>>     cd $CURDIR
>>>>     if test ! -x $FIXPATH_BIN; then
>>>>       cd $FIXPATH_DIR
>>>>       $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>>>> 2>&1
>>>>       cd $CURDIR
>>>>     fi
>>>> ```
>>>>
>>>> i.e. check if fixpath.exe exists, otherwise compile it (I don't know the
>>>> source language though, so I just copied that from somewhere else). That
>>>> didn't work, the check seems to be failing and it's still trying to compile
>>>> (and I don't know why, I hope it's not a tabs vs. spaces issue?). I also
>>>> tried just commenting that part out completely, but it's STILL trying to
>>>> compile. I have no idea why that is happening a this point. It's also
>>>> immediately spitting out 'no' after printing 'checking if fixpath can be
>>>> created...', even before all the output from the compiler, so it almost
>>>> seems like the command is being fired off from somewhere else? Or maybe it's
>>>> just a race condition, idk.
>>>>
>>> What version of OpenJDK are you trying to build? As in which
>>> repository did you clone. Depending on which, you may need to
>>> explicitly regenerate the configure script after making changes to .m4
>>> files. There is a script, autogen.sh, in the same directory as the .m4
>>> files to do it correctly. This requires autoconf 2.69 to be available.
>>>
>>> The language in .m4 is autoconf, which (in our case) is bash shell
>>> with m4 macros on top. Most of the source, including your snippet
>>> above is just bash. So your change above looks correct, you just need
>>> to get it to be used. You could try changing the -x to -e in case
>>> execute permissions aren't translated properly between msys and
>>> windows.
>>>
>>> /Erik
>>>>
>>>> If you have any more suggestions I really appreciate it, but if it's too
>>>> much trouble for an unsupported build system I understand.
>>>>
>>>> Best regards,
>>>> Jorn Vernee
>>>>
>


From jbvernee at xs4all.nl  Tue Jun 12 12:40:24 2018
From: jbvernee at xs4all.nl (jbvernee)
Date: Tue, 12 Jun 2018 14:40:24 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
 <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
Message-ID: <775b1da27fb0be3b9a0e44c6218c7000@xs4all.nl>

Hello guys,

I tried the rebaseall and it worked. Tbh, I hadn't really looked into 
cygwin that much since I wanted to avoid having PATH conflicts between 3 
different versions of tools (one windows, one msys, and one cygwin). I 
should have done that right away though since it was really easy to get 
working, and also runs 'configure' about 10x faster (although having to 
use the installer to install packages is somewhat annoying).

I think I'll just shelf msys2 for now, since it's not that important to 
me, and building openjdk is more of a hobby thing any ways. Btw, the 
patch that you linked, Magnus, is private, i.e. it returns a '403 - 
Forbidden'.

I have thought about using virtualbox to emulate linux to build in 
there, but it requires me to enable virtualization in my BIOS and doing 
that makes my machine boot up significantly slower. Fast startup is more 
important to me (like I said, building ojdk is more of a hobby thing). I 
also have a decade old PC that runs Ubuntu, but I'm sharing the monitor 
with someone else, so I can't always use it. That's why I've settled on 
getting the build to work natively.

Any ways, I ran configure and ended up with the following (I'm trying to 
build the amber repo btw):
```
====================================================
The existing configuration has been successfully updated in
/cygdrive/j/cygwin64/home/Jorn/cygwin-projects/amber/build/windows-x86_64-normal-server-release
using default settings.

Configuration summary:
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'aot cds cmsgc compiler1 compiler2 g1gc graal 
jfr jni-check jvmci jvmti management nmt parallelgc serialgc services 
vm-structs'
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 64
* Version string: 11-internal+0-adhoc.Jorn.amber (11-internal)

Tools summary:
* Environment:    cygwin version 2.10.0(0.325/5/3) (root at 
/cygdrive/j/cygwin64)
* Boot JDK:       java version "10.0.1" 2018-04-17  Java(TM) SE Runtime 
Environment 18.3 (build 10.0.1+10)  Java HotSpot(TM) 64-Bit Server VM 
18.3 (build 10.0.1+10, mixed mode)   (at 
/cygdrive/c/progra~1/java/jdk-10)
* Toolchain:      microsoft (Microsoft Visual Studio 2012)
* C Compiler:     Version 17.00.61030 (at 
/cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl)
* C++ Compiler:   Version 17.00.61030 (at 
/cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl)

Build performance summary:
* Cores to use:   7
* Memory limit:   8124 MB

WARNING: The result of this configuration has overridden an older
configuration. You *should* run 'make clean' to make sure you get a
proper build. Failure to do so might result in strange build problems.
```

I tried with VS 2015 community, but it was warning about not being 
supported? I guess that change hasn't propagated to the amber repo yet, 
so I'm using VS 2012 express. (I have also tried installing VS 2010 
express, which I believe is recommended, but it doesn't seem to include 
a compiler? There's a service pack which I think includes the compiler, 
but it requires windows SDK 7.1 which 'encountered some problems during 
installation' *sigh*).

Then running `make clean images` I had an error about inttypes.h 
missing, which I downloaded to fix that error, but now it's also 
complaining about other stuff like:
```
j:\cygwin64\home\Jorn\cygwin-projects\amber\test\fmw\gtest\include\gtest/gtest-printers.h(550) 
: error C2977: 'std::tuple' : too many template arguments
         j:\progra~2\micros~3.0\vc\include\utility(73) : see declaration 
of 'std::tuple'
```

And many more such errors after that. So I suppose VS 2012 express isn't 
supported either (even though it doesn't give a warning)? Maybe I'm 
missing something, I only installed VS 2012 express from here: 
https://www.visualstudio.com/vs/older-downloads/ . Or does the amber 
repo require some tricks to get working?

Close yet so far. Thanks,
Jorn Vernee

Thomas St?fe schreef op 2018-06-12 11:49:
> I second the advice to get cygwin up and running. Cygwin is the
> canonical way to build on windows. Unless you have really pressing
> reasons to use something else, I would use what (almost) everyone else
> uses.
> 
> I have my windows build env up and running on a fresh windows machine
> usually in ~30 minutes. It should not be rocket science. I use both
> windows 7 and 10 for my work.
> 
> Some more points, in additions to what the others wrote:
> 
> - 64bit seems to be the standard: 64bit windows, building 64bit ojdk
> with a 64bit cygwin. Other configurations may work but are less well
> tested. Just something to keep in mind.
> 
> - If you do not trust your windows machine and suspect its software
> stack may be messed up somehow, there is always the option of
> installing a fresh copy of windows in a virtual machine, e.g.
> VirtualBox, and install the tool chain from scratch (cygwin + vistual
> studio).
> 
> Best Regards & good luck,
> 
> Thomas
> 
> 
> 
> 
> On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> Hi Jorn,
>> 
>> As you probably have understood by now, porting OpenJDK to msys2 is 
>> not just
>> a simple quick fix. If all you want is to build OpenJDK on your 
>> Windows
>> computer, you are probably better off by trying to fix your Cygwin
>> installation. From your description, it sounds like you'll need to 
>> rebase
>> it: http://cygwin.wikia.com/wiki/Rebaseall.
>> 
>> If you want to pursue the msys2 path (and I'd appreciate it; it would 
>> be
>> good to get OpenJDK working on msys again), I suggest you start by 
>> looking
>> at the work that had been done before (but never merged into 
>> mainline). See
>> this conversation:
>> 
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html
>> 
>> Peter Budai got the msys part working, but he had more ambitious goals 
>> of
>> getting gcc to build on Windows, which is magnitudes more work, so his 
>> patch
>> was never finished. Nevertheless, he published a patch in [1] which 
>> got
>> stripped by the mailing list. I've put it up here:
>> 
>> http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch
>> 
>> It is for jdk9 so it's not possibly to apply out of the box, but you 
>> can
>> probably see what's been done and trying to reimplement it. I think 
>> the
>> "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
>> disables msys2 path mangling.
>> 
>> Good luck!
>> 
>> /Magnus
>> 
>> [1]
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html
>> 


From erik.joelsson at oracle.com  Tue Jun 12 13:41:00 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 12 Jun 2018 06:41:00 -0700
Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same
 version as build toolchain
In-Reply-To: <e29d70f8-8205-35c4-e03a-ea89a7296539@oracle.com>
References: <e29d70f8-8205-35c4-e03a-ea89a7296539@oracle.com>
Message-ID: <8e132944-f7df-708d-1b84-8bd68385217e@oracle.com>

Looks good.

/Erik


On 2018-06-11 18:15, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8204113/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8204113
>
> AOT tests need a local linker to generate AOT libraries. They load 
> devkits from our infrastructure when there is no local linker on 
> testing machine. The names of devkits are hardcoded in 
> AotCompiler.java (java wrapper which launches 'jaotc' tool).
>
> We recently updated compilers for JDK 11. As result devkit names in 
> AotCompiler.java should be updated too.
>
> Tested by running AOT tests on all our supported platforms.
>



From erik.joelsson at oracle.com  Tue Jun 12 13:56:23 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 12 Jun 2018 06:56:23 -0700
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <775b1da27fb0be3b9a0e44c6218c7000@xs4all.nl>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
 <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
 <775b1da27fb0be3b9a0e44c6218c7000@xs4all.nl>
Message-ID: <017e2a3c-6ccd-1ef4-e084-bf9bddd93ae7@oracle.com>

Hello,

Glad to hear you got Cygwin in order!

The officially supported toolchain for jdk/jdk (current mainline for JDK 
11) is VS 2017. We recently upgraded from 2013. Amber seems to be pretty 
much up to date with that from looking at the repo changes. You can 
check at the top of toolchain_windows.m4 for the list of VS versions. 
The order of that list shows our preference. I do not think 2010 works 
well since we upgraded from that to 2013 a long time ago in JDK 9. I do 
believe 2015 should work, but last I tried, I needed to add 
--disable-warnings-as-errors to get through. For 2017, you only need the 
"BuildTools" edition if you want to minimize the install. If you want 
the Visual Studio IDE, then community edition works just as well.

If you are running Windows 10, you can also try installing the Windows 
Subsystem for Linux. In my experience, OpenJDK builds pretty much out of 
the box in Ubuntu under WSL as long as you provide a bootjdk of the 
correct version (for Linux). You get a Linux binary that works in WSL 
(or native Linux).

/Erik

On 2018-06-12 05:40, jbvernee wrote:
> Hello guys,
>
> I tried the rebaseall and it worked. Tbh, I hadn't really looked into 
> cygwin that much since I wanted to avoid having PATH conflicts between 
> 3 different versions of tools (one windows, one msys, and one cygwin). 
> I should have done that right away though since it was really easy to 
> get working, and also runs 'configure' about 10x faster (although 
> having to use the installer to install packages is somewhat annoying).
>
> I think I'll just shelf msys2 for now, since it's not that important 
> to me, and building openjdk is more of a hobby thing any ways. Btw, 
> the patch that you linked, Magnus, is private, i.e. it returns a '403 
> - Forbidden'.
>
> I have thought about using virtualbox to emulate linux to build in 
> there, but it requires me to enable virtualization in my BIOS and 
> doing that makes my machine boot up significantly slower. Fast startup 
> is more important to me (like I said, building ojdk is more of a hobby 
> thing). I also have a decade old PC that runs Ubuntu, but I'm sharing 
> the monitor with someone else, so I can't always use it. That's why 
> I've settled on getting the build to work natively.
>
> Any ways, I ran configure and ended up with the following (I'm trying 
> to build the amber repo btw):
> ```
> ====================================================
> The existing configuration has been successfully updated in
> /cygdrive/j/cygwin64/home/Jorn/cygwin-projects/amber/build/windows-x86_64-normal-server-release 
>
> using default settings.
>
> Configuration summary:
> * Debug level:??? release
> * HS debug level: product
> * JVM variants:?? server
> * JVM features:?? server: 'aot cds cmsgc compiler1 compiler2 g1gc 
> graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc 
> services vm-structs'
> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64
> * Version string: 11-internal+0-adhoc.Jorn.amber (11-internal)
>
> Tools summary:
> * Environment:??? cygwin version 2.10.0(0.325/5/3) (root at 
> /cygdrive/j/cygwin64)
> * Boot JDK:?????? java version "10.0.1" 2018-04-17? Java(TM) SE 
> Runtime Environment 18.3 (build 10.0.1+10)? Java HotSpot(TM) 64-Bit 
> Server VM 18.3 (build 10.0.1+10, mixed mode)?? (at 
> /cygdrive/c/progra~1/java/jdk-10)
> * Toolchain:????? microsoft (Microsoft Visual Studio 2012)
> * C Compiler:???? Version 17.00.61030 (at 
> /cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl)
> * C++ Compiler:?? Version 17.00.61030 (at 
> /cygdrive/j/progra~2/micros~3.0/vc/bin/x86_am~1/cl)
>
> Build performance summary:
> * Cores to use:?? 7
> * Memory limit:?? 8124 MB
>
> WARNING: The result of this configuration has overridden an older
> configuration. You *should* run 'make clean' to make sure you get a
> proper build. Failure to do so might result in strange build problems.
> ```
>
> I tried with VS 2015 community, but it was warning about not being 
> supported? I guess that change hasn't propagated to the amber repo 
> yet, so I'm using VS 2012 express. (I have also tried installing VS 
> 2010 express, which I believe is recommended, but it doesn't seem to 
> include a compiler? There's a service pack which I think includes the 
> compiler, but it requires windows SDK 7.1 which 'encountered some 
> problems during installation' *sigh*).
>
> Then running `make clean images` I had an error about inttypes.h 
> missing, which I downloaded to fix that error, but now it's also 
> complaining about other stuff like:
> ```
> j:\cygwin64\home\Jorn\cygwin-projects\amber\test\fmw\gtest\include\gtest/gtest-printers.h(550) 
> : error C2977: 'std::tuple' : too many template arguments
> ??????? j:\progra~2\micros~3.0\vc\include\utility(73) : see 
> declaration of 'std::tuple'
> ```
>
> And many more such errors after that. So I suppose VS 2012 express 
> isn't supported either (even though it doesn't give a warning)? Maybe 
> I'm missing something, I only installed VS 2012 express from here: 
> https://www.visualstudio.com/vs/older-downloads/ . Or does the amber 
> repo require some tricks to get working?
>
> Close yet so far. Thanks,
> Jorn Vernee
>
> Thomas St?fe schreef op 2018-06-12 11:49:
>> I second the advice to get cygwin up and running. Cygwin is the
>> canonical way to build on windows. Unless you have really pressing
>> reasons to use something else, I would use what (almost) everyone else
>> uses.
>>
>> I have my windows build env up and running on a fresh windows machine
>> usually in ~30 minutes. It should not be rocket science. I use both
>> windows 7 and 10 for my work.
>>
>> Some more points, in additions to what the others wrote:
>>
>> - 64bit seems to be the standard: 64bit windows, building 64bit ojdk
>> with a 64bit cygwin. Other configurations may work but are less well
>> tested. Just something to keep in mind.
>>
>> - If you do not trust your windows machine and suspect its software
>> stack may be messed up somehow, there is always the option of
>> installing a fresh copy of windows in a virtual machine, e.g.
>> VirtualBox, and install the tool chain from scratch (cygwin + vistual
>> studio).
>>
>> Best Regards & good luck,
>>
>> Thomas
>>
>>
>>
>>
>> On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>> Hi Jorn,
>>>
>>> As you probably have understood by now, porting OpenJDK to msys2 is 
>>> not just
>>> a simple quick fix. If all you want is to build OpenJDK on your Windows
>>> computer, you are probably better off by trying to fix your Cygwin
>>> installation. From your description, it sounds like you'll need to 
>>> rebase
>>> it: http://cygwin.wikia.com/wiki/Rebaseall.
>>>
>>> If you want to pursue the msys2 path (and I'd appreciate it; it 
>>> would be
>>> good to get OpenJDK working on msys again), I suggest you start by 
>>> looking
>>> at the work that had been done before (but never merged into 
>>> mainline). See
>>> this conversation:
>>>
>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html 
>>>
>>>
>>> Peter Budai got the msys part working, but he had more ambitious 
>>> goals of
>>> getting gcc to build on Windows, which is magnitudes more work, so 
>>> his patch
>>> was never finished. Nevertheless, he published a patch in [1] which got
>>> stripped by the mailing list. I've put it up here:
>>>
>>> http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch
>>>
>>> It is for jdk9 so it's not possibly to apply out of the box, but you 
>>> can
>>> probably see what's been done and trying to reimplement it. I think the
>>> "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
>>> disables msys2 path mangling.
>>>
>>> Good luck!
>>>
>>> /Magnus
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html 
>>>
>>>



From vladimir.kozlov at oracle.com  Tue Jun 12 14:26:48 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 12 Jun 2018 07:26:48 -0700
Subject: [11] RFR(S) 8204113: Upgrade linker used in AOT tests to be same
 version as build toolchain
In-Reply-To: <8e132944-f7df-708d-1b84-8bd68385217e@oracle.com>
References: <e29d70f8-8205-35c4-e03a-ea89a7296539@oracle.com>
 <8e132944-f7df-708d-1b84-8bd68385217e@oracle.com>
Message-ID: <128f99fd-cdc2-fc0d-56d6-2eac213a7ae2@oracle.com>

Thank you, Erik

Vladimir

On 6/12/18 6:41 AM, Erik Joelsson wrote:
> Looks good.
> 
> /Erik
> 
> 
> On 2018-06-11 18:15, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8204113/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8204113
>>
>> AOT tests need a local linker to generate AOT libraries. They load 
>> devkits from our infrastructure when there is no local linker on 
>> testing machine. The names of devkits are hardcoded in 
>> AotCompiler.java (java wrapper which launches 'jaotc' tool).
>>
>> We recently updated compilers for JDK 11. As result devkit names in 
>> AotCompiler.java should be updated too.
>>
>> Tested by running AOT tests on all our supported platforms.
>>
> 


From peterbudai at hotmail.com  Tue Jun 12 15:26:58 2018
From: peterbudai at hotmail.com (Peter Budai)
Date: Tue, 12 Jun 2018 15:26:58 +0000
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>,
 <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
Message-ID: <AM5P189MB02917504EAB0FB70BA4585E8C27F0@AM5P189MB0291.EURP189.PROD.OUTLOOK.COM>

Hi,



You can find the patches here:

https://github.com/peterbud/MINGW-packages/tree/openjdk/mingw-w64-openjdk



I have managed to build OpenJDK on MSYS2 with gcc, both 32 and 64 bit, but that was obviously the beginning. Around 10% of the test cases were failing so more work would have been needed. However since December I have not worked on that, as (don?t take it personal pls) I have not received feedback on what is the best way to work towards reviewing (and ultimately merging) these changes.



Good luck on your journey.



Peter



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



________________________________
From: Thomas St?fe <thomas.stuefe at gmail.com>
Sent: Tuesday, June 12, 2018 11:49:00 AM
To: Magnus Ihse Bursie; jbvernee
Cc: build-dev; Peter Budai
Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe

I second the advice to get cygwin up and running. Cygwin is the
canonical way to build on windows. Unless you have really pressing
reasons to use something else, I would use what (almost) everyone else
uses.

I have my windows build env up and running on a fresh windows machine
usually in ~30 minutes. It should not be rocket science. I use both
windows 7 and 10 for my work.

Some more points, in additions to what the others wrote:

- 64bit seems to be the standard: 64bit windows, building 64bit ojdk
with a 64bit cygwin. Other configurations may work but are less well
tested. Just something to keep in mind.

- If you do not trust your windows machine and suspect its software
stack may be messed up somehow, there is always the option of
installing a fresh copy of windows in a virtual machine, e.g.
VirtualBox, and install the tool chain from scratch (cygwin + vistual
studio).

Best Regards & good luck,

Thomas




On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> Hi Jorn,
>
> As you probably have understood by now, porting OpenJDK to msys2 is not just
> a simple quick fix. If all you want is to build OpenJDK on your Windows
> computer, you are probably better off by trying to fix your Cygwin
> installation. From your description, it sounds like you'll need to rebase
> it: http://cygwin.wikia.com/wiki/Rebaseall.
>
> If you want to pursue the msys2 path (and I'd appreciate it; it would be
> good to get OpenJDK working on msys again), I suggest you start by looking
> at the work that had been done before (but never merged into mainline). See
> this conversation:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html
>
> Peter Budai got the msys part working, but he had more ambitious goals of
> getting gcc to build on Windows, which is magnitudes more work, so his patch
> was never finished. Nevertheless, he published a patch in [1] which got
> stripped by the mailing list. I've put it up here:
>
> http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch
>
> It is for jdk9 so it's not possibly to apply out of the box, but you can
> probably see what's been done and trying to reimplement it. I think the
> "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
> disables msys2 path mangling.
>
> Good luck!
>
> /Magnus
>
> [1]
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html
>
>
>
> On 2018-06-11 23:26, jbvernee wrote:
>>
>> Hello,
>>
>> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks for the
>> suggestion. It's supposed to be a semi-colon separated list of argument
>> prefixes (they have some examples like `/switch;/sdcard;--root=`), so I
>> tried setting it to `/out:`, `-Fe` (from the .m4 file) and `/out`, and also
>> just the entire path that is being mangled. But none of them worked :(
>> (still the same error).
>>
>> I'm trying to build the amber repo, which I think is parallel with jdk/jdk
>> tip? Any ways, there is no autogen.sh in /make/autoconf and anytime I make
>> changes to the .m4 file it mentions something about having to regenerate the
>> configure file. I can also see the changes I make in
>> `/build/.configure-support/generated-configure.sh`, which currently looks
>> like this (the part I mentioned):
>>
>> ```
>>     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>     cd $CURDIR
>>     echo "#####################" here
>>     #if test ! -x $FIXPATH_BIN; then
>>     #  cd $FIXPATH_DIR
>>     #  $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>> 2>&1
>>     #  cd $CURDIR
>>     #fi
>>     echo "#####################" there
>>
>>     if test ! -x $FIXPATH_BIN; then
>>       { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
>> $as_echo "no" >&6; }
>>       cat $FIXPATH_DIR/fixpath1.log
>>       as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5
>>     fi
>> ```
>>
>> Which gives me this output (the last few lines):
>>
>> ```
>> checking if fixpath can be created...
>> ##################### here
>> ##################### there
>> no
>> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>> configure: error: Could not create
>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe
>> J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning C4477:
>> 'fprintf' : format string '%s' requires an argument of type 'char *', but
>> variadic argument 3 has type 'LPVOID'
>> Microsoft (R) Incremental Linker Version 14.00.24215.1
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>>
>> /out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>> fixpath.obj
>> LINK : fatal error LNK1104: cannot open file
>> 'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>> configure exiting with result code 1
>> ```
>>
>> So the changes I'm making seem to be going through... well... at least as
>> far as the echo statements go. I also tried using -e on the check that is
>> not comment out, but with no different results (I'm also using autoconf 2.69
>> btw). This is kind of a head scratcher ?h. I'm calling it a night, I think
>> I'll also try taking this up with the msys guys, some other time.
>>
>> Thanks for the help so far,
>> Jorn Vernee
>>
>> Erik Joelsson schreef op 2018-06-11 22:19:
>>>
>>> Hello,
>>>
>>> On 2018-06-11 13:00, jbvernee wrote:
>>>>
>>>> Hello Erik,
>>>>
>>>> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've
>>>> been banging my head against trying to build the JDK on my machine on and
>>>> off for a few months. So at this point I really appreciate any help that
>>>> gets me even an inch further, thanks.
>>>>
>>>> After your suggestion, I have tracked down the call site of the compile
>>>> command and checked the paths that are being used in basics_windows.m4 (line
>>>> 406) to compile fixpath.exe:
>>>>
>>>> ```
>>>>     cd $FIXPATH_DIR
>>>>     $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>>>> 2>&1
>>>>     cd $CURDIR
>>>> ```
>>>> They are:
>>>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
>>>> $FIXPATH_BIN_W =
>>>> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>>>> $FIXPATH_DIR =
>>>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
>>>>
>>>> Note that the second one is a windows style path. I can change that to
>>>> use the unix style path, and that does affect the error message, I now see:
>>>> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'`
>>>> as the path in the linker error. But of course the Visual Studios linker
>>>> can't do anything with a unix style path.
>>>>
>>>> What's weird is that either path is working for the C compiler (cl), but
>>>> it is being mangled before being passed to the linker, and I can't find
>>>> where the linker command is actually being fired off. It seems to be done by
>>>> that same line. I was hoping you could tell me more about that?
>>>>
>>> AFAIK, we compile fixpath from a single source file directly into an
>>> executable, so it's cl that calls link. Somewhere along the way, msys
>>> decides to mangle your path argument incorrectly. You could try using
>>> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly
>>> how it works but I know you can affect the mangling using this env
>>> variable.
>>>>
>>>> One other idea I had, but haven't been able to implement, is to check
>>>> whether the fixpath tool exists before trying to compile it. That way I
>>>> could just compile it manually. I have tried this snippet in
>>>> basics_windows.m4 at line 404:
>>>> ```
>>>>     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>>>     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>>>     cd $CURDIR
>>>>     if test ! -x $FIXPATH_BIN; then
>>>>       cd $FIXPATH_DIR
>>>>       $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>>>> 2>&1
>>>>       cd $CURDIR
>>>>     fi
>>>> ```
>>>>
>>>> i.e. check if fixpath.exe exists, otherwise compile it (I don't know the
>>>> source language though, so I just copied that from somewhere else). That
>>>> didn't work, the check seems to be failing and it's still trying to compile
>>>> (and I don't know why, I hope it's not a tabs vs. spaces issue?). I also
>>>> tried just commenting that part out completely, but it's STILL trying to
>>>> compile. I have no idea why that is happening a this point. It's also
>>>> immediately spitting out 'no' after printing 'checking if fixpath can be
>>>> created...', even before all the output from the compiler, so it almost
>>>> seems like the command is being fired off from somewhere else? Or maybe it's
>>>> just a race condition, idk.
>>>>
>>> What version of OpenJDK are you trying to build? As in which
>>> repository did you clone. Depending on which, you may need to
>>> explicitly regenerate the configure script after making changes to .m4
>>> files. There is a script, autogen.sh, in the same directory as the .m4
>>> files to do it correctly. This requires autoconf 2.69 to be available.
>>>
>>> The language in .m4 is autoconf, which (in our case) is bash shell
>>> with m4 macros on top. Most of the source, including your snippet
>>> above is just bash. So your change above looks correct, you just need
>>> to get it to be used. You could try changing the -x to -e in case
>>> execute permissions aren't translated properly between msys and
>>> windows.
>>>
>>> /Erik
>>>>
>>>> If you have any more suggestions I really appreciate it, but if it's too
>>>> much trouble for an unsupported build system I understand.
>>>>
>>>> Best regards,
>>>> Jorn Vernee
>>>>
>


From jbvernee at xs4all.nl  Tue Jun 12 15:34:42 2018
From: jbvernee at xs4all.nl (jbvernee)
Date: Tue, 12 Jun 2018 17:34:42 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <017e2a3c-6ccd-1ef4-e084-bf9bddd93ae7@oracle.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
 <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
 <775b1da27fb0be3b9a0e44c6218c7000@xs4all.nl>
 <017e2a3c-6ccd-1ef4-e084-bf9bddd93ae7@oracle.com>
Message-ID: <af2fe4bad610f41d67505b69bf3849ed@xs4all.nl>

Hey Erik,

I was running into warnings in the standard library being treated as 
errors with VS 2015, so --disable-warnings-as-errors did the trick :D

The information I remembered turned out to be outdated. I went and 
looked at doc/building.html again and found that amber required at least 
VS 2013 update 4. I should have RTFM (oops). The toolchain_windows.m4 
tip was a good one, it looks like the repo also supports VS 2017, so I'm 
now building using the BuildTools version of 2017 successfully (thanks 
for the tip). Tbh, it feels really great to finally get this working :) 
The support for newer versions of VS is really appreciated.

Thanks for all the help,
Jorn Vernee

Erik Joelsson schreef op 2018-06-12 15:56:
> Hello,
> 
> Glad to hear you got Cygwin in order!
> 
> The officially supported toolchain for jdk/jdk (current mainline for
> JDK 11) is VS 2017. We recently upgraded from 2013. Amber seems to be
> pretty much up to date with that from looking at the repo changes. You
> can check at the top of toolchain_windows.m4 for the list of VS
> versions. The order of that list shows our preference. I do not think
> 2010 works well since we upgraded from that to 2013 a long time ago in
> JDK 9. I do believe 2015 should work, but last I tried, I needed to
> add --disable-warnings-as-errors to get through. For 2017, you only
> need the "BuildTools" edition if you want to minimize the install. If
> you want the Visual Studio IDE, then community edition works just as
> well.
> 
> If you are running Windows 10, you can also try installing the Windows
> Subsystem for Linux. In my experience, OpenJDK builds pretty much out
> of the box in Ubuntu under WSL as long as you provide a bootjdk of the
> correct version (for Linux). You get a Linux binary that works in WSL
> (or native Linux).
> 
> /Erik


From alexey.ivanov at oracle.com  Tue Jun 12 18:06:03 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 12 Jun 2018 19:06:03 +0100
Subject: [8u-dev] RFR for 8179675: Build with error on windows with new Cygwin
 grep
Message-ID: <6d4d3cdc-5a3b-1d77-1739-7528ddac6c3f@oracle.com>

Hi,

Could you please review the following fix for 8u-dev?

JBS: https://bugs.openjdk.java.net/browse/JDK-8179675
webrev: cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/

The problem is that newer grep v3.0 does not match the end-of-line if 
the input uses Windows line endings.

The fix removes CR, '\r', from the input before processing with grep.


Thank you in advance.

Regards,
Alexey


From alexey.ivanov at oracle.com  Tue Jun 12 18:08:51 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 12 Jun 2018 19:08:51 +0100
Subject: [8u-dev] RFR for 8179675: Build with error on windows with new
 Cygwin grep
In-Reply-To: <6d4d3cdc-5a3b-1d77-1739-7528ddac6c3f@oracle.com>
References: <6d4d3cdc-5a3b-1d77-1739-7528ddac6c3f@oracle.com>
Message-ID: <d9fe3d49-1996-47c7-3af1-dc66bf0e090c@oracle.com>

Resending with clickable link to the webrev:
http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/

--
Alexey

On 12/06/2018 19:06, Alexey Ivanov wrote:
> Hi,
>
> Could you please review the following fix for 8u-dev?
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179675
> webrev: http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/
>
> The problem is that newer grep v3.0 does not match the end-of-line if 
> the input uses Windows line endings.
>
> The fix removes CR, '\r', from the input before processing with grep.
>
>
> Thank you in advance.
>
> Regards,
> Alexey



From erik.joelsson at oracle.com  Tue Jun 12 20:05:20 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 12 Jun 2018 13:05:20 -0700
Subject: [8u-dev] RFR for 8179675: Build with error on windows with new
 Cygwin grep
In-Reply-To: <d9fe3d49-1996-47c7-3af1-dc66bf0e090c@oracle.com>
References: <6d4d3cdc-5a3b-1d77-1739-7528ddac6c3f@oracle.com>
 <d9fe3d49-1996-47c7-3af1-dc66bf0e090c@oracle.com>
Message-ID: <c1e1bef8-9c92-4bc8-8471-cc9b33f89c11@oracle.com>

Looks good.

/Erik


On 2018-06-12 11:08, Alexey Ivanov wrote:
> Resending with clickable link to the webrev:
> http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/
>
> -- 
> Alexey
>
> On 12/06/2018 19:06, Alexey Ivanov wrote:
>> Hi,
>>
>> Could you please review the following fix for 8u-dev?
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179675
>> webrev: http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/
>>
>> The problem is that newer grep v3.0 does not match the end-of-line if 
>> the input uses Windows line endings.
>>
>> The fix removes CR, '\r', from the input before processing with grep.
>>
>>
>> Thank you in advance.
>>
>> Regards,
>> Alexey
>



From erik.joelsson at oracle.com  Wed Jun 13 00:34:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 12 Jun 2018 17:34:33 -0700
Subject: RFR: JDK-8204922: Create bootcycle jib profiles
Message-ID: <be5f6c97-312b-4d7c-1743-ac17130a34ca@oracle.com>

In order to test bootcycle builds more easily at Oracle, we need 
specific jib profiles for them. This patch adds that. I also make the 
linux-aarch64 profile explicitly build the aarch64 port instead of the 
arm64 port as well as disable warnings-as-errors since we currently have 
the readdir warning in that configuration.

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

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

/Erik



From tim.bell at oracle.com  Wed Jun 13 02:11:01 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 12 Jun 2018 19:11:01 -0700
Subject: RFR: JDK-8204922: Create bootcycle jib profiles
In-Reply-To: <be5f6c97-312b-4d7c-1743-ac17130a34ca@oracle.com>
References: <be5f6c97-312b-4d7c-1743-ac17130a34ca@oracle.com>
Message-ID: <5B207D35.5090508@oracle.com>

Erik:

> In order to test bootcycle builds more easily at Oracle, we need
> specific jib profiles for them. This patch adds that. I also make the
> linux-aarch64 profile explicitly build the aarch64 port instead of the
> arm64 port as well as disable warnings-as-errors since we currently have
> the readdir warning in that configuration.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204922
>
> Webrev: http://cr.openjdk.java.net/~erikj/8204093/webrev.01/

Looks good.

/Tim




From magnus.ihse.bursie at oracle.com  Wed Jun 13 06:02:22 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 13 Jun 2018 08:02:22 +0200
Subject: RFR: JDK-8204922: Create bootcycle jib profiles
In-Reply-To: <be5f6c97-312b-4d7c-1743-ac17130a34ca@oracle.com>
References: <be5f6c97-312b-4d7c-1743-ac17130a34ca@oracle.com>
Message-ID: <4DF802A7-E0A3-4D7E-BA2D-EDFC8A954D37@oracle.com>

Looks good to me. 

/Magnus

> 13 juni 2018 kl. 02:34 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> In order to test bootcycle builds more easily at Oracle, we need specific jib profiles for them. This patch adds that. I also make the linux-aarch64 profile explicitly build the aarch64 port instead of the arm64 port as well as disable warnings-as-errors since we currently have the readdir warning in that configuration.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204922
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8204093/webrev.01/
> 
> /Erik
> 



From thomas.stuefe at gmail.com  Wed Jun 13 06:14:08 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jun 2018 08:14:08 +0200
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
Message-ID: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>

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


From goetz.lindenmaier at sap.com  Wed Jun 13 06:54:29 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 13 Jun 2018 06:54:29 +0000
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
In-Reply-To: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
References: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
Message-ID: <64656d53176642f8854625073f360248@sap.com>

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-
> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> Sent: Mittwoch, 13. Juni 2018 08:14
> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at 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

From matthias.baesken at sap.com  Wed Jun 13 07:43:26 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 13 Jun 2018 07:43:26 +0000
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
In-Reply-To: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
References: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
Message-ID: <f9a7f27420dd4f2ba6f9e9def4331fc4@sap.com>

Hi Thomas , thanks for fixing it, looks good  ( not a Reviewer however) .

Best regards, Matthias



> -----Original Message-----
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> Sent: Mittwoch, 13. Juni 2018 08:14
> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at 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

From thomas.stuefe at gmail.com  Wed Jun 13 08:28:08 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jun 2018 10:28:08 +0200
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
In-Reply-To: <64656d53176642f8854625073f360248@sap.com>
References: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
 <64656d53176642f8854625073f360248@sap.com>
Message-ID: <CAA-vtUxshN-pM_F-rAnshfoQyre7axS5T3tSMQt3z7MwcKogbw@mail.gmail.com>

Thank you Goetz!

On Wed, Jun 13, 2018 at 8:54 AM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> 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-
>> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
>> Sent: Mittwoch, 13. Juni 2018 08:14
>> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
>> dev at 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


From thomas.stuefe at gmail.com  Wed Jun 13 08:28:33 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jun 2018 10:28:33 +0200
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
In-Reply-To: <f9a7f27420dd4f2ba6f9e9def4331fc4@sap.com>
References: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
 <f9a7f27420dd4f2ba6f9e9def4331fc4@sap.com>
Message-ID: <CAA-vtUy-FWhxO3SHyCcjnyF6qQScO4vrTBim4xtXUWhK09UvEw@mail.gmail.com>

Thank you Matthias!

I'll wait for someone from the Oracle Build Group to have a say.

..Thomas

On Wed, Jun 13, 2018 at 9:43 AM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> Hi Thomas , thanks for fixing it, looks good  ( not a Reviewer however) .
>
> Best regards, Matthias
>
>
>
>> -----Original Message-----
>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
>> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
>> Sent: Mittwoch, 13. Juni 2018 08:14
>> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
>> dev at 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


From magnus.ihse.bursie at oracle.com  Wed Jun 13 13:40:32 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 13 Jun 2018 15:40:32 +0200
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
In-Reply-To: <CAA-vtUy-FWhxO3SHyCcjnyF6qQScO4vrTBim4xtXUWhK09UvEw@mail.gmail.com>
References: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
 <f9a7f27420dd4f2ba6f9e9def4331fc4@sap.com>
 <CAA-vtUy-FWhxO3SHyCcjnyF6qQScO4vrTBim4xtXUWhK09UvEw@mail.gmail.com>
Message-ID: <28EBF580-8599-48BE-8205-B5920B3A3AD9@oracle.com>

Looks good to me. 

/Magnus

> 13 juni 2018 kl. 10:28 skrev Thomas St?fe <thomas.stuefe at gmail.com>:
> 
> Thank you Matthias!
> 
> I'll wait for someone from the Oracle Build Group to have a say.
> 
> ..Thomas
> 
> On Wed, Jun 13, 2018 at 9:43 AM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
>> Hi Thomas , thanks for fixing it, looks good  ( not a Reviewer however) .
>> 
>> Best regards, Matthias
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
>>> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
>>> Sent: Mittwoch, 13. Juni 2018 08:14
>>> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
>>> dev at 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



From thomas.stuefe at gmail.com  Wed Jun 13 13:42:01 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jun 2018 15:42:01 +0200
Subject: RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
In-Reply-To: <28EBF580-8599-48BE-8205-B5920B3A3AD9@oracle.com>
References: <CAA-vtUyEpZdqga2npeqcxynDrdpUTJGsdDz4FPgLed2X9_0jeg@mail.gmail.com>
 <f9a7f27420dd4f2ba6f9e9def4331fc4@sap.com>
 <CAA-vtUy-FWhxO3SHyCcjnyF6qQScO4vrTBim4xtXUWhK09UvEw@mail.gmail.com>
 <28EBF580-8599-48BE-8205-B5920B3A3AD9@oracle.com>
Message-ID: <CAA-vtUz_vwUe6fVSUjP0Nj-PqPzpZKgi6VMrB97Ww=b8sQQKiw@mail.gmail.com>

Thank you Magnus.

On Wed, Jun 13, 2018 at 3:40 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> Looks good to me.
>
> /Magnus
>
>> 13 juni 2018 kl. 10:28 skrev Thomas St?fe <thomas.stuefe at gmail.com>:
>>
>> Thank you Matthias!
>>
>> I'll wait for someone from the Oracle Build Group to have a say.
>>
>> ..Thomas
>>
>> On Wed, Jun 13, 2018 at 9:43 AM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> Hi Thomas , thanks for fixing it, looks good  ( not a Reviewer however) .
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
>>>> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
>>>> Sent: Mittwoch, 13. Juni 2018 08:14
>>>> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
>>>> dev at 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
>


From erik.joelsson at oracle.com  Wed Jun 13 19:47:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 13 Jun 2018 12:47:52 -0700
Subject: RFR: JDK-8204973: Add build support for filtering translations
Message-ID: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>

Hello,

Oracle will reduce the number of languages that it maintains 
translations of JDK resources for. The current translations will remain 
in the source for now, but we need a way to filter out a set of 
translations at build time so that we only include the ones we support. 
This patch adds such a configuration option. It also changes how Oracle 
builds by using the option to exclude all translations except English, 
Japanese, Simplified Chinese and Traditional Chinese. Anyone else 
building OpenJDK will by default include all translations present in the 
source, just as before.

I added a test that verifies this for builds with the "IMPLEMENTOR" 
field in the release file set to "Oracle Corporation". The test will not 
be run for other OpenJDK builds.

I had to modify an existing test for java.logging which used various 
translations to verify localized log messages to only use translations 
that Oracle chooses to include.

Since this is the second test that specifically verifies build behavior, 
I moved the previous such test together with this new test into a common 
top level test directory "build", under the jdk test root. I put these 
tests in the jdk tier3 test group.

I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically 
looked for tests that use the java.util.Locale class and ran them locally.

Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html

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

/Erik



From daniel.fuchs at oracle.com  Wed Jun 13 19:58:28 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Jun 2018 20:58:28 +0100
Subject: RFR: JDK-8204973: Add build support for filtering translations
In-Reply-To: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
References: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
Message-ID: <8eab54d8-d225-18d3-7472-aa663faba527@oracle.com>

Hi Erik,

The modifications to the logging test look good to me.
Caveat: I don't speak chinese nor japanese ;-)

cheers,

-- daniel

On 13/06/18 20:47, Erik Joelsson wrote:
> Hello,
> 
> Oracle will reduce the number of languages that it maintains 
> translations of JDK resources for. The current translations will remain 
> in the source for now, but we need a way to filter out a set of 
> translations at build time so that we only include the ones we support. 
> This patch adds such a configuration option. It also changes how Oracle 
> builds by using the option to exclude all translations except English, 
> Japanese, Simplified Chinese and Traditional Chinese. Anyone else 
> building OpenJDK will by default include all translations present in the 
> source, just as before.
> 
> I added a test that verifies this for builds with the "IMPLEMENTOR" 
> field in the release file set to "Oracle Corporation". The test will not 
> be run for other OpenJDK builds.
> 
> I had to modify an existing test for java.logging which used various 
> translations to verify localized log messages to only use translations 
> that Oracle chooses to include.
> 
> Since this is the second test that specifically verifies build behavior, 
> I moved the previous such test together with this new test into a common 
> top level test directory "build", under the jdk test root. I put these 
> tests in the jdk tier3 test group.
> 
> I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically 
> looked for tests that use the java.util.Locale class and ran them locally.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204973
> 
> /Erik
> 



From volker.simonis at gmail.com  Thu Jun 14 14:26:00 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 14 Jun 2018 16:26:00 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default
Message-ID: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>

Hi,

can I please have a review for the following fix:

http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
https://bugs.openjdk.java.net/browse/JDK-8204965

CDS does currently not work on AIX because of the way how we
reserve/commit memory on AIX. The problem is that we're using a
combination of shmat/mmap depending on the page size and the size of
the memory chunk to reserve. This makes it impossible to reliably
reserve the memory for the CDS archive and later on map the various
parts of the archive into these regions.

In order to fix this we would have to completely rework the memory
reserve/commit/uncommit logic on AIX which is currently out of our
scope because of resource limitations.

Unfortunately, I could not simply disable CDS in the configure step
because some of the shared code apparently relies on parts of the CDS
code which gets excluded from the build when CDS is disabled. So I
also fixed the offending parts in hotspot and cleaned up the configure
logic for CDS.

Thank you and best regards,
Volker

PS: I did run the job through the submit forest
(mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
weren't really useful because they mention build failures on linux-x64
which I can't reproduce locally.


From erik.joelsson at oracle.com  Thu Jun 14 16:04:19 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Jun 2018 09:04:19 -0700
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
Message-ID: <f4d98fdf-2663-258a-05a9-8afe6be27095@oracle.com>

Build changes look ok.

/Erik


On 2018-06-14 07:26, Volker Simonis wrote:
> Hi,
>
> can I please have a review for the following fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
> https://bugs.openjdk.java.net/browse/JDK-8204965
>
> CDS does currently not work on AIX because of the way how we
> reserve/commit memory on AIX. The problem is that we're using a
> combination of shmat/mmap depending on the page size and the size of
> the memory chunk to reserve. This makes it impossible to reliably
> reserve the memory for the CDS archive and later on map the various
> parts of the archive into these regions.
>
> In order to fix this we would have to completely rework the memory
> reserve/commit/uncommit logic on AIX which is currently out of our
> scope because of resource limitations.
>
> Unfortunately, I could not simply disable CDS in the configure step
> because some of the shared code apparently relies on parts of the CDS
> code which gets excluded from the build when CDS is disabled. So I
> also fixed the offending parts in hotspot and cleaned up the configure
> logic for CDS.
>
> Thank you and best regards,
> Volker
>
> PS: I did run the job through the submit forest
> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
> weren't really useful because they mention build failures on linux-x64
> which I can't reproduce locally.



From jiangli.zhou at Oracle.COM  Thu Jun 14 16:42:00 2018
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Thu, 14 Jun 2018 09:42:00 -0700
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
Message-ID: <14702170-8CA5-4033-B3EE-CE12C906BDE7@oracle.com>

Hi Volker,

The changes look good to me overall. I?ll refer to the JVMTI experts for jvmtiEnv.cpp change. I have a question for the change in vmStructs.cpp. Any reason why only _current_info needs CDS_ONLY?

   /********************************************/                                                                                     \
   /* FileMapInfo fields (CDS archive related) */                                                                                     \
   /********************************************/                                                                                     \
                                                                                                                                      \
   nonstatic_field(FileMapInfo,                 _header,                                       FileMapInfo::FileMapHeader*)           \
-     static_field(FileMapInfo,                 _current_info,                                 FileMapInfo*)                          \
+     CDS_ONLY(static_field(FileMapInfo,        _current_info,                                 FileMapInfo*))                         \
   nonstatic_field(FileMapInfo::FileMapHeader,  _space[0],                                     FileMapInfo::FileMapHeader::space_info)\
   nonstatic_field(FileMapInfo::FileMapHeader::space_info, _addr._base,                        char*)                                 \
   nonstatic_field(FileMapInfo::FileMapHeader::space_info, _used,                              size_t)                                \
                                                                                                                                      \
Thanks,
Jiangli

> On Jun 14, 2018, at 7:26 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> can I please have a review for the following fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
> https://bugs.openjdk.java.net/browse/JDK-8204965
> 
> CDS does currently not work on AIX because of the way how we
> reserve/commit memory on AIX. The problem is that we're using a
> combination of shmat/mmap depending on the page size and the size of
> the memory chunk to reserve. This makes it impossible to reliably
> reserve the memory for the CDS archive and later on map the various
> parts of the archive into these regions.
> 
> In order to fix this we would have to completely rework the memory
> reserve/commit/uncommit logic on AIX which is currently out of our
> scope because of resource limitations.
> 
> Unfortunately, I could not simply disable CDS in the configure step
> because some of the shared code apparently relies on parts of the CDS
> code which gets excluded from the build when CDS is disabled. So I
> also fixed the offending parts in hotspot and cleaned up the configure
> logic for CDS.
> 
> Thank you and best regards,
> Volker
> 
> PS: I did run the job through the submit forest
> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
> weren't really useful because they mention build failures on linux-x64
> which I can't reproduce locally.



From erik.joelsson at oracle.com  Thu Jun 14 18:52:02 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Jun 2018 11:52:02 -0700
Subject: RFR: JDK-8204973: Add build support for filtering translations
In-Reply-To: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
References: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
Message-ID: <33cc25be-838d-bb88-1332-b8f9178fc742@oracle.com>

Hello,

Here is a new version of the patch:

http://cr.openjdk.java.net/~erikj/8204973/webrev.02/

Changes from last time:

* Made the regexp for finding locales more correct. It still does not 
try to match 3 letter language strings because doing so triggers a large 
amount of false positives in our souce tree.

* Added another accepted locale (en_US_POSIX) that is now matched by the 
improved regexp.

* Added more locales to the exclude list as they were now discovered by 
the improved regexp.

/Erik


On 2018-06-13 12:47, Erik Joelsson wrote:
> Hello,
>
> Oracle will reduce the number of languages that it maintains 
> translations of JDK resources for. The current translations will 
> remain in the source for now, but we need a way to filter out a set of 
> translations at build time so that we only include the ones we 
> support. This patch adds such a configuration option. It also changes 
> how Oracle builds by using the option to exclude all translations 
> except English, Japanese, Simplified Chinese and Traditional Chinese. 
> Anyone else building OpenJDK will by default include all translations 
> present in the source, just as before.
>
> I added a test that verifies this for builds with the "IMPLEMENTOR" 
> field in the release file set to "Oracle Corporation". The test will 
> not be run for other OpenJDK builds.
>
> I had to modify an existing test for java.logging which used various 
> translations to verify localized log messages to only use translations 
> that Oracle chooses to include.
>
> Since this is the second test that specifically verifies build 
> behavior, I moved the previous such test together with this new test 
> into a common top level test directory "build", under the jdk test 
> root. I put these tests in the jdk tier3 test group.
>
> I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically 
> looked for tests that use the java.util.Locale class and ran them 
> locally.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204973
>
> /Erik
>



From thomas.stuefe at gmail.com  Thu Jun 14 19:04:31 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 14 Jun 2018 21:04:31 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
Message-ID: <CAA-vtUzHaprVv=6FUt9C6h+kgPZE9Bv=9FNx4g9gaRQ5o48GSg@mail.gmail.com>

Hi Volker,

http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html

Seems like a roundabout way to have a platform specific default value.

Why not determine a default value beforehand:

if test "x$OPENJDK_TARGET_OS" = "xaix"; then
  ENABLE_CDS_DEFAULT="false"
else
  ENABLE_CDS_DEFAULT=true"
fi

AC_ARG_ENABLE([cds], [AS_HELP_STRING([--enable-cds@<:@=yes/no/auto@:>@],
 [enable class data sharing feature in non-minimal VM. Default is
${ENABLE_CDS_DEFAULT}.])])

and so on?

See also what we did for "8202325: [aix] disable warnings-as-errors by default".

--

http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/src/hotspot/share/classfile/javaClasses.cpp.udiff.html

Here, do we really need to exclude this from compiling,
DumpSharedSpaces = false is not enough?


Best Regards, Thomas

On Thu, Jun 14, 2018 at 4:26 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> can I please have a review for the following fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
> https://bugs.openjdk.java.net/browse/JDK-8204965
>
> CDS does currently not work on AIX because of the way how we
> reserve/commit memory on AIX. The problem is that we're using a
> combination of shmat/mmap depending on the page size and the size of
> the memory chunk to reserve. This makes it impossible to reliably
> reserve the memory for the CDS archive and later on map the various
> parts of the archive into these regions.
>
> In order to fix this we would have to completely rework the memory
> reserve/commit/uncommit logic on AIX which is currently out of our
> scope because of resource limitations.
>
> Unfortunately, I could not simply disable CDS in the configure step
> because some of the shared code apparently relies on parts of the CDS
> code which gets excluded from the build when CDS is disabled. So I
> also fixed the offending parts in hotspot and cleaned up the configure
> logic for CDS.
>
> Thank you and best regards,
> Volker
>
> PS: I did run the job through the submit forest
> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
> weren't really useful because they mention build failures on linux-x64
> which I can't reproduce locally.


From magnus.ihse.bursie at oracle.com  Thu Jun 14 19:49:07 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 14 Jun 2018 21:49:07 +0200
Subject: RFR: JDK-8204973: Add build support for filtering translations
In-Reply-To: <33cc25be-838d-bb88-1332-b8f9178fc742@oracle.com>
References: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
 <33cc25be-838d-bb88-1332-b8f9178fc742@oracle.com>
Message-ID: <d6a195a2-dfd8-c778-ed89-34fafa5bc3da@oracle.com>

Would it have been to problematic to reverse the the logic, i.e. having 
a "include translation" rather than an exclude? Feels more brittle; if 
someone adds a translation the exclude list needs to be updated. Also, a 
include mechanism could possibly be used, much simpler, by someone who 
only wants to build e.g. a chinese jdk.

But I realize the contraints by the somewhat odd request from the bug 
report, to deliver just a subset of the available translations. So I'm 
okay with the patch.

/Magnus

On 2018-06-14 20:52, Erik Joelsson wrote:
> Hello,
>
> Here is a new version of the patch:
>
> http://cr.openjdk.java.net/~erikj/8204973/webrev.02/
>
> Changes from last time:
>
> * Made the regexp for finding locales more correct. It still does not 
> try to match 3 letter language strings because doing so triggers a 
> large amount of false positives in our souce tree.
>
> * Added another accepted locale (en_US_POSIX) that is now matched by 
> the improved regexp.
>
> * Added more locales to the exclude list as they were now discovered 
> by the improved regexp.
>
> /Erik
>
>
> On 2018-06-13 12:47, Erik Joelsson wrote:
>> Hello,
>>
>> Oracle will reduce the number of languages that it maintains 
>> translations of JDK resources for. The current translations will 
>> remain in the source for now, but we need a way to filter out a set 
>> of translations at build time so that we only include the ones we 
>> support. This patch adds such a configuration option. It also changes 
>> how Oracle builds by using the option to exclude all translations 
>> except English, Japanese, Simplified Chinese and Traditional Chinese. 
>> Anyone else building OpenJDK will by default include all translations 
>> present in the source, just as before.
>>
>> I added a test that verifies this for builds with the "IMPLEMENTOR" 
>> field in the release file set to "Oracle Corporation". The test will 
>> not be run for other OpenJDK builds.
>>
>> I had to modify an existing test for java.logging which used various 
>> translations to verify localized log messages to only use 
>> translations that Oracle chooses to include.
>>
>> Since this is the second test that specifically verifies build 
>> behavior, I moved the previous such test together with this new test 
>> into a common top level test directory "build", under the jdk test 
>> root. I put these tests in the jdk tier3 test group.
>>
>> I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically 
>> looked for tests that use the java.util.Locale class and ran them 
>> locally.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204973
>>
>> /Erik
>>
>



From naoto.sato at oracle.com  Thu Jun 14 20:05:15 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 14 Jun 2018 13:05:15 -0700
Subject: RFR: JDK-8204973: Add build support for filtering translations
In-Reply-To: <33cc25be-838d-bb88-1332-b8f9178fc742@oracle.com>
References: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
 <33cc25be-838d-bb88-1332-b8f9178fc742@oracle.com>
Message-ID: <a1c89a61-9ca6-090f-db94-141c7218b041@oracle.com>

Looks good to me.

Naoto

On 6/14/18 11:52 AM, Erik Joelsson wrote:
> Hello,
> 
> Here is a new version of the patch:
> 
> http://cr.openjdk.java.net/~erikj/8204973/webrev.02/
> 
> Changes from last time:
> 
> * Made the regexp for finding locales more correct. It still does not 
> try to match 3 letter language strings because doing so triggers a large 
> amount of false positives in our souce tree.
> 
> * Added another accepted locale (en_US_POSIX) that is now matched by the 
> improved regexp.
> 
> * Added more locales to the exclude list as they were now discovered by 
> the improved regexp.
> 
> /Erik
> 
> 
> On 2018-06-13 12:47, Erik Joelsson wrote:
>> Hello,
>>
>> Oracle will reduce the number of languages that it maintains 
>> translations of JDK resources for. The current translations will 
>> remain in the source for now, but we need a way to filter out a set of 
>> translations at build time so that we only include the ones we 
>> support. This patch adds such a configuration option. It also changes 
>> how Oracle builds by using the option to exclude all translations 
>> except English, Japanese, Simplified Chinese and Traditional Chinese. 
>> Anyone else building OpenJDK will by default include all translations 
>> present in the source, just as before.
>>
>> I added a test that verifies this for builds with the "IMPLEMENTOR" 
>> field in the release file set to "Oracle Corporation". The test will 
>> not be run for other OpenJDK builds.
>>
>> I had to modify an existing test for java.logging which used various 
>> translations to verify localized log messages to only use translations 
>> that Oracle chooses to include.
>>
>> Since this is the second test that specifically verifies build 
>> behavior, I moved the previous such test together with this new test 
>> into a common top level test directory "build", under the jdk test 
>> root. I put these tests in the jdk tier3 test group.
>>
>> I have run all tier1, 2 and 3 tests in Mach 5 as well as specifically 
>> looked for tests that use the java.util.Locale class and ran them 
>> locally.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204973
>>
>> /Erik
>>
> 


From erik.joelsson at oracle.com  Thu Jun 14 20:08:55 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Jun 2018 13:08:55 -0700
Subject: RFR: JDK-8204973: Add build support for filtering translations
In-Reply-To: <d6a195a2-dfd8-c778-ed89-34fafa5bc3da@oracle.com>
References: <b9b643a0-2eff-383c-a1fa-ac6090436b7d@oracle.com>
 <33cc25be-838d-bb88-1332-b8f9178fc742@oracle.com>
 <d6a195a2-dfd8-c778-ed89-34fafa5bc3da@oracle.com>
Message-ID: <84ffd038-6c14-ef39-6103-686d1e8bb538@oracle.com>


On 2018-06-14 12:49, Magnus Ihse Bursie wrote:
> Would it have been to problematic to reverse the the logic, i.e. 
> having a "include translation" rather than an exclude? Feels more 
> brittle; if someone adds a translation the exclude list needs to be 
> updated. Also, a include mechanism could possibly be used, much 
> simpler, by someone who only wants to build e.g. a chinese jdk.
>
I agree that include would have been easier to use, and I was initially 
trying to implement it that way, but couldn't come up with an effective 
solution in make. You need to identify all source files that have locale 
suffixes and only filter among them. With the exclude, at least the 
build logic is reasonably straight forward since the user defines the 
locale strings that define a translation that warrants action.

This is why I added a test that uses include logic, hoping that the 
combination would prove resilient enough to catch such changes. The test 
is still a bit brittle since it can easily catch false positives.
> But I realize the contraints by the somewhat odd request from the bug 
> report, to deliver just a subset of the available translations. So I'm 
> okay with the patch.
>
Thanks!

/Erik
> /Magnus
>
> On 2018-06-14 20:52, Erik Joelsson wrote:
>> Hello,
>>
>> Here is a new version of the patch:
>>
>> http://cr.openjdk.java.net/~erikj/8204973/webrev.02/
>>
>> Changes from last time:
>>
>> * Made the regexp for finding locales more correct. It still does not 
>> try to match 3 letter language strings because doing so triggers a 
>> large amount of false positives in our souce tree.
>>
>> * Added another accepted locale (en_US_POSIX) that is now matched by 
>> the improved regexp.
>>
>> * Added more locales to the exclude list as they were now discovered 
>> by the improved regexp.
>>
>> /Erik
>>
>>
>> On 2018-06-13 12:47, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Oracle will reduce the number of languages that it maintains 
>>> translations of JDK resources for. The current translations will 
>>> remain in the source for now, but we need a way to filter out a set 
>>> of translations at build time so that we only include the ones we 
>>> support. This patch adds such a configuration option. It also 
>>> changes how Oracle builds by using the option to exclude all 
>>> translations except English, Japanese, Simplified Chinese and 
>>> Traditional Chinese. Anyone else building OpenJDK will by default 
>>> include all translations present in the source, just as before.
>>>
>>> I added a test that verifies this for builds with the "IMPLEMENTOR" 
>>> field in the release file set to "Oracle Corporation". The test will 
>>> not be run for other OpenJDK builds.
>>>
>>> I had to modify an existing test for java.logging which used various 
>>> translations to verify localized log messages to only use 
>>> translations that Oracle chooses to include.
>>>
>>> Since this is the second test that specifically verifies build 
>>> behavior, I moved the previous such test together with this new test 
>>> into a common top level test directory "build", under the jdk test 
>>> root. I put these tests in the jdk tier3 test group.
>>>
>>> I have run all tier1, 2 and 3 tests in Mach 5 as well as 
>>> specifically looked for tests that use the java.util.Locale class 
>>> and ran them locally.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8204973/webrev.01/index.html
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204973
>>>
>>> /Erik
>>>
>>
>



From gary.adams at oracle.com  Thu Jun 14 23:26:48 2018
From: gary.adams at oracle.com (gary.adams at oracle.com)
Date: Thu, 14 Jun 2018 19:26:48 -0400
Subject: RFR: JDK-8205055: Fix compilation optimization errors with new
 Solaris toolchain
Message-ID: <cdc7ea23-cd77-e51c-5304-becebcbec503@oracle.com>

Locally tested the fix below and via mach5 jobs.
The ~50 failed tests all completed successfully.
It'd be good for Erik to repeat his full testing with
this patch included in case it blocked other issues
from being observed.

This fix can be integrated after the sync from jdk/client.

 ?Issue: https://bugs.openjdk.java.net/browse/JDK-8205055

Proposed fix:

diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk 
b/make/hotspot/lib/JvmOverrideFiles.gmk
--- a/make/hotspot/lib/JvmOverrideFiles.gmk
+++ b/make/hotspot/lib/JvmOverrideFiles.gmk
@@ -74,6 +74,8 @@

 ?else ifeq ($(OPENJDK_TARGET_OS), solaris)
 ???ifneq ($(DEBUG_LEVEL), slowdebug)
+ # dev studio 12.6 workaround
+ BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW



From volker.simonis at gmail.com  Fri Jun 15 07:43:14 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 15 Jun 2018 09:43:14 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <14702170-8CA5-4033-B3EE-CE12C906BDE7@oracle.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <14702170-8CA5-4033-B3EE-CE12C906BDE7@oracle.com>
Message-ID: <CA+3eh11hyFxxBCso7c+xKgBJ=FV-gQ9rmf1pOquC=y3zxjbU9w@mail.gmail.com>

Hi Jiangli,

thanks for looking at the change.

'CDS_only' is only required for static fields because the
VMStructEntry for them contains a reference to the actual static field
which isn't present if we disable CDS, because the corresponding
compilations units (i.e. filemap.cpp) won't be part of libjvm.so. For
non-static fields, the VMStructEntry structure only contains the
offset of the corresponding field with regards to an object of that
type which is harmless.

Regards,
Volker


On Thu, Jun 14, 2018 at 6:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
> Hi Volker,
>
> The changes look good to me overall. I?ll refer to the JVMTI experts for
> jvmtiEnv.cpp change. I have a question for the change in vmStructs.cpp. Any
> reason why only _current_info needs CDS_ONLY?
>
>    /********************************************/
> \
>    /* FileMapInfo fields (CDS archive related) */
> \
>    /********************************************/
> \
>
> \
>    nonstatic_field(FileMapInfo,                 _header,
> FileMapInfo::FileMapHeader*)           \
> -     static_field(FileMapInfo,                 _current_info,
> FileMapInfo*)                          \
> +     CDS_ONLY(static_field(FileMapInfo,        _current_info,
> FileMapInfo*))                         \
>    nonstatic_field(FileMapInfo::FileMapHeader,  _space[0],
> FileMapInfo::FileMapHeader::space_info)\
>    nonstatic_field(FileMapInfo::FileMapHeader::space_info, _addr._base,
> char*)                                 \
>    nonstatic_field(FileMapInfo::FileMapHeader::space_info, _used,
> size_t)                                \
>
> \
>
> Thanks,
> Jiangli
>
> On Jun 14, 2018, at 7:26 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
> Hi,
>
> can I please have a review for the following fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
> https://bugs.openjdk.java.net/browse/JDK-8204965
>
> CDS does currently not work on AIX because of the way how we
> reserve/commit memory on AIX. The problem is that we're using a
> combination of shmat/mmap depending on the page size and the size of
> the memory chunk to reserve. This makes it impossible to reliably
> reserve the memory for the CDS archive and later on map the various
> parts of the archive into these regions.
>
> In order to fix this we would have to completely rework the memory
> reserve/commit/uncommit logic on AIX which is currently out of our
> scope because of resource limitations.
>
> Unfortunately, I could not simply disable CDS in the configure step
> because some of the shared code apparently relies on parts of the CDS
> code which gets excluded from the build when CDS is disabled. So I
> also fixed the offending parts in hotspot and cleaned up the configure
> logic for CDS.
>
> Thank you and best regards,
> Volker
>
> PS: I did run the job through the submit forest
> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
> weren't really useful because they mention build failures on linux-x64
> which I can't reproduce locally.
>
>


From matthias.baesken at sap.com  Fri Jun 15 07:47:45 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 15 Jun 2018 07:47:45 +0000
Subject: RFR:  8205091: AIX: build errors in hotspot after 8203641: Refactor
 String Deduplication into shared
Message-ID: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>

Please review  this small  change  that fixes the AIX build after  "8203641: Refactor String Deduplication into shared"    .

We are getting this  compilation error  :
/build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp", line 107.38: 1540-0063 (S) The text "1" is unexpected.


Looks like the name of the second template parameter (STAT)

    template <typename QUEUE, typename STAT>
    static void initialize_impl();

is clashing with defines from the AIX system headers  (where I find  #define STAT  1 ) .
Renaming  STAT  to something else fixes the build on AIX .

Webrev :

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

Bug :

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


Thanks, Matthias


From volker.simonis at gmail.com  Fri Jun 15 08:05:01 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 15 Jun 2018 10:05:01 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CAA-vtUzHaprVv=6FUt9C6h+kgPZE9Bv=9FNx4g9gaRQ5o48GSg@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <CAA-vtUzHaprVv=6FUt9C6h+kgPZE9Bv=9FNx4g9gaRQ5o48GSg@mail.gmail.com>
Message-ID: <CA+3eh13b7BiQtLzXzX1qPeUdEwy1+YmAToc=BF_E9+ObepuvQQ@mail.gmail.com>

On Thu, Jun 14, 2018 at 9:04 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi Volker,
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html
>
> Seems like a roundabout way to have a platform specific default value.
>
> Why not determine a default value beforehand:
>
> if test "x$OPENJDK_TARGET_OS" = "xaix"; then
>   ENABLE_CDS_DEFAULT="false"
> else
>   ENABLE_CDS_DEFAULT=true"
> fi
>
> AC_ARG_ENABLE([cds], [AS_HELP_STRING([--enable-cds@<:@=yes/no/auto@:>@],
>  [enable class data sharing feature in non-minimal VM. Default is
> ${ENABLE_CDS_DEFAULT}.])])
>
> and so on?
>

I've just followed the pattern used for '--enable-aot' right above the
code I changed.

Moreover, I don't think that we would save any code because we would
still have to check for AIX in the '--enable-cds=yes' case. Also, the
new reporting added later in the file (see "AC_MSG_CHECKING([if cds
should be enabled])" seems easier to me without the extra default
value. So if you don't mind I'd prefer to leave it as is.

> See also what we did for "8202325: [aix] disable warnings-as-errors by default".
>
> --
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/src/hotspot/share/classfile/javaClasses.cpp.udiff.html
>
> Here, do we really need to exclude this from compiling,
> DumpSharedSpaces = false is not enough?
>

Yes, we need it because the excluded code references methods (e.g.
'StringTable::create_archived_string()') which are not compiled into
libjvm.so if we disable CDS.

>
> Best Regards, Thomas
>
> On Thu, Jun 14, 2018 at 4:26 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> can I please have a review for the following fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>
>> CDS does currently not work on AIX because of the way how we
>> reserve/commit memory on AIX. The problem is that we're using a
>> combination of shmat/mmap depending on the page size and the size of
>> the memory chunk to reserve. This makes it impossible to reliably
>> reserve the memory for the CDS archive and later on map the various
>> parts of the archive into these regions.
>>
>> In order to fix this we would have to completely rework the memory
>> reserve/commit/uncommit logic on AIX which is currently out of our
>> scope because of resource limitations.
>>
>> Unfortunately, I could not simply disable CDS in the configure step
>> because some of the shared code apparently relies on parts of the CDS
>> code which gets excluded from the build when CDS is disabled. So I
>> also fixed the offending parts in hotspot and cleaned up the configure
>> logic for CDS.
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: I did run the job through the submit forest
>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>> weren't really useful because they mention build failures on linux-x64
>> which I can't reproduce locally.


From sgehwolf at redhat.com  Fri Jun 15 08:27:39 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 15 Jun 2018 10:27:39 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
Message-ID: <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>

Forwarding to build-dev.
-------------- next part --------------
An embedded message was scrubbed...
From: Fridrich Strba <fridrich.strba at suse.com>
Subject: Re: Build breakage with system jpeg and lcms and jdk-11+18
Date: Fri, 15 Jun 2018 09:35:55 +0200
Size: 9540
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20180615/efde01a6/attachment.eml>

From glaubitz at physik.fu-berlin.de  Fri Jun 15 08:57:15 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 15 Jun 2018 10:57:15 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
Message-ID: <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>

Hi Fridrich!

I can help you getting this issue fixed. If I remember correctly, you said
that SUSE has signed Oracle's OCA, so I it should be fine if I submit the
patch with you as the author.

Let me have a look at the problem first though.

Adrian

On 06/15/2018 10:27 AM, Severin Gehwolf wrote:
> Just for the completeness, this is a normal openSUSE package build with
> --with-system-jpeg and --with-system-lcms. Maybe the
> LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
> able to build jdk-11+18 with bundled jpeg and lcms without problems.
> 
> Cheers
> 
> Fridrich
> 
> On 15/06/18 09:31, Fridrich Strba wrote:
>> Hello, good people,
>>
>> Since I cannot submit anything to bugzilla, I spam this list with this
>> patch that I needed to be able to build jdk-11+18.
>>
>> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
>> the way the headers are included, but in my analysis, the generated
>> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
>> the new way of doing. The patch makes it build for me. Do what you want
>> with it :)
>>
>> Fridrich
>>
> 

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From volker.simonis at gmail.com  Fri Jun 15 09:01:08 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 15 Jun 2018 11:01:08 +0200
Subject: RFR: 8205091: AIX: build errors in hotspot after 8203641:
 Refactor String Deduplication into shared
In-Reply-To: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
References: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
Message-ID: <CA+3eh11Ykp55jHGRmUyRcrnAve8Qf-L-=LY9x0tHEpubTiNT-w@mail.gmail.com>

Hi Mattias,

the change looks good. Could you please also update the comment in the
line above which still reads "STAT".

Also, maybe "STATI" would be a better name choice (longer is better :)
because the probability of a clash is lower (and it would nicely align
with QUEUE in the comments :) But I leave that up to you...

Regards,
Volker


On Fri, Jun 15, 2018 at 9:47 AM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> Please review  this small  change  that fixes the AIX build after  "8203641: Refactor String Deduplication into shared"    .
>
> We are getting this  compilation error  :
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp", line 107.38: 1540-0063 (S) The text "1" is unexpected.
>
>
> Looks like the name of the second template parameter (STAT)
>
>     template <typename QUEUE, typename STAT>
>     static void initialize_impl();
>
> is clashing with defines from the AIX system headers  (where I find  #define STAT  1 ) .
> Renaming  STAT  to something else fixes the build on AIX .
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8205091
>
>
> Thanks, Matthias


From matthias.baesken at sap.com  Fri Jun 15 09:09:43 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 15 Jun 2018 09:09:43 +0000
Subject: RFR: 8205091: AIX: build errors in hotspot after 8203641:
 Refactor String Deduplication into shared
In-Reply-To: <CAL26=jO0Bmw6VbMhO-uyXD0w3m=8iFcYnqjK=DRf23EUj4in8Q@mail.gmail.com>
References: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
 <CAL26=jO0Bmw6VbMhO-uyXD0w3m=8iFcYnqjK=DRf23EUj4in8Q@mail.gmail.com>
Message-ID: <53a0c1b692a64c22aa65db4db7576f51@sap.com>

Hi  , thanks for looking into it.
I think I  will use  STAT_IMPL  .

Best regards, Matthias


> -----Original Message-----
> From: Ren? Sch?nemann [mailto:rene.schuenemann at gmail.com]
> Sent: Freitag, 15. Juni 2018 11:08
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
> Subject: Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor
> String Deduplication into shared
> 
> Hi Matthias,
> 
> the name SI seems also quite "common" and may result in other naming
> clashes in the future.
> Maybe something more readable like STAT_IMPL?
> 
> Please also change the name in the comment:
> 
> // STAT:  String Dedup Stat implementation
> 
> Regards,
> Rene
> 
> On Fri, Jun 15, 2018 at 9:47 AM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> > Please review  this small  change  that fixes the AIX build after  "8203641:
> Refactor String Deduplication into shared"    .
> >
> > We are getting this  compilation error  :
> >
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stri
> ngDedup.hpp", line 107.38: 1540-0063 (S) The text "1" is unexpected.
> >
> >
> > Looks like the name of the second template parameter (STAT)
> >
> >     template <typename QUEUE, typename STAT>
> >     static void initialize_impl();
> >
> > is clashing with defines from the AIX system headers  (where I find  #define
> STAT  1 ) .
> > Renaming  STAT  to something else fixes the build on AIX .
> >
> > Webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
> >
> > Bug :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8205091
> >
> >
> > Thanks, Matthias

From thomas.stuefe at gmail.com  Fri Jun 15 10:36:48 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 15 Jun 2018 12:36:48 +0200
Subject: RFR: 8205091: AIX: build errors in hotspot after 8203641:
 Refactor String Deduplication into shared
In-Reply-To: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
References: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
Message-ID: <CAA-vtUzmNyb22g7juHQNWL81QRYgE279TVd--vopOiw5NNb6YQ@mail.gmail.com>

Hi Matthias,

Good catch. Patch for me is good if you guys agree on a good uncommon name.

Gru? Thomas

On Fri, Jun 15, 2018, 09:48 Baesken, Matthias <matthias.baesken at sap.com>
wrote:

> Please review  this small  change  that fixes the AIX build after
> "8203641: Refactor String Deduplication into shared"    .
>
> We are getting this  compilation error  :
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
> line 107.38: 1540-0063 (S) The text "1" is unexpected.
>
>
> Looks like the name of the second template parameter (STAT)
>
>     template <typename QUEUE, typename STAT>
>     static void initialize_impl();
>
> is clashing with defines from the AIX system headers  (where I find
> #define STAT  1 ) .
> Renaming  STAT  to something else fixes the build on AIX .
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8205091
>
>
> Thanks, Matthias
>


From magnus.ihse.bursie at oracle.com  Fri Jun 15 11:10:29 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 13:10:29 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
Message-ID: <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>

On 2018-06-15 10:57, John Paul Adrian Glaubitz wrote:
> Hi Fridrich!
>
> I can help you getting this issue fixed. If I remember correctly, you said
> that SUSE has signed Oracle's OCA, so I it should be fine if I submit the
> patch with you as the author.
>
> Let me have a look at the problem first though.

I think I understand the underlying issue but I'm not sure how to try 
reproduce a build problem from it.

Here's a better patch. Please try and see if it solves your problems. 
Unfortunately, I'm leaving on vacation for today and will be gone most 
of the summer, so I can't help sponsor this patch. But if it works, I'm 
sure someone else can take over it.

If it does not work, the original patch should at the very least be 
changed so that EXTRA_HEADER_DIRS gets an additional "$(call 
GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying 
hard to eradicate from the CFLAGS).

diff --git a/make/common/JdkNativeCompilation.gmk 
b/make/common/JdkNativeCompilation.gmk
--- a/make/common/JdkNativeCompilation.gmk
+++ b/make/common/JdkNativeCompilation.gmk
@@ -119,9 +119,11 @@
 ?? endif

 ?? ifneq ($$($1_HEADERS_FROM_SRC), false)
-??? $1_SRC_HEADER_FLAGS := $$(foreach dir, $$(wildcard $$($1_SRC) \
-??????? $$(call GetJavaHeaderDir, $$(MODULE))), -I$$(dir))
+??? $1_SRC_HEADER_FLAGS := $$(addprefix -I, $$(wildcard $$($1_SRC)))
 ?? endif
+? # Always add the java header dir
+? $1_SRC_HEADER_FLAGS := $$(addprefix -I, $$(call GetJavaHeaderDir, 
$$(MODULE)))
+
 ?? ifneq ($$($1_EXTRA_HEADER_DIRS), )
 ???? $1_PROCESSED_EXTRA_HEADER_DIRS := $$(foreach dir, 
$$($1_EXTRA_HEADER_DIRS), \
 ???????? $$(call ProcessDir, $$(dir)))


/Magnus



>
> Adrian
>
> On 06/15/2018 10:27 AM, Severin Gehwolf wrote:
>> Just for the completeness, this is a normal openSUSE package build with
>> --with-system-jpeg and --with-system-lcms. Maybe the
>> LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
>> able to build jdk-11+18 with bundled jpeg and lcms without problems.
>>
>> Cheers
>>
>> Fridrich
>>
>> On 15/06/18 09:31, Fridrich Strba wrote:
>>> Hello, good people,
>>>
>>> Since I cannot submit anything to bugzilla, I spam this list with this
>>> patch that I needed to be able to build jdk-11+18.
>>>
>>> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
>>> the way the headers are included, but in my analysis, the generated
>>> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
>>> the new way of doing. The patch makes it build for me. Do what you want
>>> with it :)
>>>
>>> Fridrich
>>>



From glaubitz at physik.fu-berlin.de  Fri Jun 15 11:12:36 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 15 Jun 2018 13:12:36 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
Message-ID: <fc7290a9-ffa5-396b-f6c3-8d3b99184061@physik.fu-berlin.de>

On 06/15/2018 01:10 PM, Magnus Ihse Bursie wrote:
> I think I understand the underlying issue but I'm not sure how to try reproduce a build problem from it.

I have an openSUSE box here, so I should be able to reproduce it :).

> Here's a better patch. Please try and see if it solves your problems. Unfortunately, I'm leaving on vacation for today and will be gone most of the summer, so I can't help sponsor this patch. But if it works, I'm sure someone else can take over it.

Don't worry. I will help Fridrich to sort this issue out.

> If it does not work, the original patch should at the very least be changed so that EXTRA_HEADER_DIRS gets an additional "$(call GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying hard to eradicate from the CFLAGS).
Thanks for the heads-up! I will test your patch in any case.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From doko at ubuntu.com  Fri Jun 15 12:04:30 2018
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 15 Jun 2018 14:04:30 +0200
Subject: client VM build doesn't build in parallel anymore
Message-ID: <0a60faf6-6241-50b9-1c3c-d8028dd5aeff@ubuntu.com>

Since b14 or b15, the client VM on x86 doesn't build anymore when building with

   --with-jvm-variants=client,server --with-num-cores=4

building with one to three cores seems to work however. The server and zero VMs 
build without issues and parallel builds.  Any idea which dependencies got dropped?

javac: file not found: 
/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
make[4]: *** 
[/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch] 
Error 3
make[4]: *** Deleting file 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch'
gensrc/GensrcJfr.gmk:40: recipe for target 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch' 
failed
make[4]: Leaving directory '/home/packages/openjdk/11/openjdk-11-11~18/make/hotspot'
make[3]: *** [hotspot-client-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs....
make/Main.gmk:249: recipe for target 'hotspot-client-gensrc' failed



From magnus.ihse.bursie at oracle.com  Fri Jun 15 12:44:05 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 14:44:05 +0200
Subject: client VM build doesn't build in parallel anymore
In-Reply-To: <0a60faf6-6241-50b9-1c3c-d8028dd5aeff@ubuntu.com>
References: <0a60faf6-6241-50b9-1c3c-d8028dd5aeff@ubuntu.com>
Message-ID: <9dd2f785-4ebc-750c-d183-cbf011f033db@oracle.com>

There was a race with the JFR build tools when building multiple JVMs. 
:-( Erik produced a fix for this as part of? JDK-8202384), unfortunately 
this has not yet been pushed.

You can find the JFR fix part here: 
http://cr.openjdk.java.net/~erikj/8202384/webrev.05/make/hotspot/gensrc/GensrcJfr.gmk.udiff.html

If you apply it locally, it should resolve your issue.

If JDK-8202384 takes much longer to push, hopefully Erik can separate 
out this trivial part (which is already reviewed by me as part of 
JDK-8202384) and push it separately.

/Magnus



On 2018-06-15 14:04, Matthias Klose wrote:
> Since b14 or b15, the client VM on x86 doesn't build anymore when 
> building with
>
> ? --with-jvm-variants=client,server --with-num-cores=4
>
> building with one to three cores seems to work however. The server and 
> zero VMs build without issues and parallel builds.? Any idea which 
> dependencies got dropped?
>
> javac: file not found: 
> /home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
> make[4]: *** 
> [/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch] 
> Error 3
> make[4]: *** Deleting file 
> '/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch'
> gensrc/GensrcJfr.gmk:40: recipe for target 
> '/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch' 
> failed
> make[4]: Leaving directory 
> '/home/packages/openjdk/11/openjdk-11-11~18/make/hotspot'
> make[3]: *** [hotspot-client-gensrc] Error 2
> make[3]: *** Waiting for unfinished jobs....
> make/Main.gmk:249: recipe for target 'hotspot-client-gensrc' failed
>



From magnus.ihse.bursie at oracle.com  Fri Jun 15 12:44:46 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 14:44:46 +0200
Subject: RFR: JDK-8205055: Fix compilation optimization errors with new
 Solaris toolchain
In-Reply-To: <cdc7ea23-cd77-e51c-5304-becebcbec503@oracle.com>
References: <cdc7ea23-cd77-e51c-5304-becebcbec503@oracle.com>
Message-ID: <9dd27bd6-36ab-7616-8069-f7a9dbdc080d@oracle.com>

On 2018-06-15 01:26, gary.adams at oracle.com wrote:
> Locally tested the fix below and via mach5 jobs.
> The ~50 failed tests all completed successfully.
> It'd be good for Erik to repeat his full testing with
> this patch included in case it blocked other issues
> from being observed.
>
> This fix can be integrated after the sync from jdk/client.
>
> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8205055
>
> Proposed fix:
>
> diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk 
> b/make/hotspot/lib/JvmOverrideFiles.gmk
> --- a/make/hotspot/lib/JvmOverrideFiles.gmk
> +++ b/make/hotspot/lib/JvmOverrideFiles.gmk
> @@ -74,6 +74,8 @@
>
> ?else ifeq ($(OPENJDK_TARGET_OS), solaris)
> ???ifneq ($(DEBUG_LEVEL), slowdebug)
> + # dev studio 12.6 workaround
> + BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW

The if should test
ifeq ($(TOOLCHAIN_TYPE), solstudio)
since this is a compiler issue, not an OS issue.

Ideally, it should also test if using version 12.6, but unfortunately 
there's currently no elegant way of expressing that in the makefiles, so 
I'm OK with the workaround of just having a comment. I assume, from the 
name and a quick glance at the file, that the contents makes it unlikely 
that a lowevered optimization level wouldprovoke a performance 
regression in pre-12.6 solstudio compilations.

Still, it would be nice if you are able to drill down the issue to 
figure out exactly why a higher optimization level causes this file to 
be incorrectly compiled. It might be code in hotspot with undefined 
behavior, or it might be bugs in solstudio. In any case, it should be 
addressed. As an initial fix to allow compilation to proceed, this is 
fine, though.

/Magnus


From sgehwolf at redhat.com  Fri Jun 15 12:59:56 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 15 Jun 2018 14:59:56 +0200
Subject: [8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used
Message-ID: <b70c37dca70132962be5b0dfa919cda2f8251d0c.camel@redhat.com>

Hi,

This is a JDK 8u specific problem. It's not applicable to 10/11 since
the build system has changed. Make files in JDK 8 live in the hotspot
tree, hence, I'm also including hotspot-dev. The issue at hand is that
linker flags are not consistently passed down to individual library
builds. Specifically libjvm.so, libjsig.so and libsaproc.so. This
prevents downstream users from producing hardened builds. We have been
using this patch in downstream Fedora for a while now without issues.

Please review!

Bug: https://bugs.openjdk.java.net/browse/JDK-8205104
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/

Testing:

Before:
$ for i in build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so \
         build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so \
         build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so; do \
   echo $i; readelf -d $i | grep NOW
  done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so

After:
$ for i in build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so \
         build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so \
         build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so; do \
   echo $i; readelf -d $i | grep NOW
  done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW

Thanks,
Severin


From magnus.ihse.bursie at oracle.com  Fri Jun 15 13:09:30 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 15:09:30 +0200
Subject: RFR: JDK-8200867 Remove references to "jdk 9" in build system
In-Reply-To: <cf0a4bac-2177-3e86-8135-2098174c5e01@oracle.com>
References: <eba92106-c193-3091-dab9-6321e82f010d@oracle.com>
 <46ac1e52-687a-b8b4-4f98-c0b3c140a46b@oracle.com>
 <5B08152B.9050008@oracle.com>
 <cf0a4bac-2177-3e86-8135-2098174c5e01@oracle.com>
Message-ID: <09162b87-75ea-35ee-a4da-56aa3ef8b372@oracle.com>

(reviving an old review thread)

On 2018-05-25 18:17, Erik Joelsson wrote:
>
> On 2018-05-25 06:52, Tim Bell wrote:
>> Magnus-
>>
>> On 05/25/18 04:23, Claes Redestad wrote:
>>> On 2018-05-25 12:06, Magnus Ihse Bursie wrote:
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01 
>>>>
>>>>
>>>
>>> Looks good to me!
>>>
>>> /Claes
>>
> Looks good!
>> doc/building.md
>> doc/building.html
>>
>> These files also have changes to minimum gcc versions 
>> (4.7/4.8/4.9.2/7.3.0) - is that for a different bug number?
>>
> I believe he is just updating outdated numbers in the doc that he 
> stumbled on. The changes are all correct.
You are correct.

However, when all dust has settled with the new compiler upgrades (and 
possibly removal of support for older configurations) we should make 
sure that the build documentation is correct and up to date. I'm passing 
that ball on to you, Erik. :-)

/Magnus

>
> /Erik
>> Looks good to me otherwise.
>>
>> /Tim
>>
>>
>



From magnus.ihse.bursie at oracle.com  Fri Jun 15 13:24:07 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 15:24:07 +0200
Subject: [8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used
In-Reply-To: <b70c37dca70132962be5b0dfa919cda2f8251d0c.camel@redhat.com>
References: <b70c37dca70132962be5b0dfa919cda2f8251d0c.camel@redhat.com>
Message-ID: <09b9a36c-7a3a-1c2a-a72c-88a4b4d26be3@oracle.com>

On 2018-06-15 14:59, Severin Gehwolf wrote:
> Hi,
>
> This is a JDK 8u specific problem. It's not applicable to 10/11 since
> the build system has changed. Make files in JDK 8 live in the hotspot
> tree, hence, I'm also including hotspot-dev. The issue at hand is that
> linker flags are not consistently passed down to individual library
> builds. Specifically libjvm.so, libjsig.so and libsaproc.so. This
> prevents downstream users from producing hardened builds. We have been
> using this patch in downstream Fedora for a while now without issues.
Looks good to me.

Seeing this makes me realize I'm *soo* happy to not have to live with 
the old hotspot build system anymore. :-)

/Magnus

>
> Please review!
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205104
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/
>
> Testing:
>
> Before:
> $ for i in build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so; do \
>     echo $i; readelf -d $i | grep NOW
>    done
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
>
> After:
> $ for i in build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so; do \
>     echo $i; readelf -d $i | grep NOW
>    done
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
>   0x0000000000000018 (BIND_NOW)
>   0x000000006ffffffb (FLAGS_1)            Flags: NOW
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
>   0x0000000000000018 (BIND_NOW)
>   0x000000006ffffffb (FLAGS_1)            Flags: NOW
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
>   0x0000000000000018 (BIND_NOW)
>   0x000000006ffffffb (FLAGS_1)            Flags: NOW
>
> Thanks,
> Severin



From magnus.ihse.bursie at oracle.com  Fri Jun 15 13:38:08 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 15:38:08 +0200
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <AM5P189MB02917504EAB0FB70BA4585E8C27F0@AM5P189MB0291.EURP189.PROD.OUTLOOK.COM>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
 <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
 <AM5P189MB02917504EAB0FB70BA4585E8C27F0@AM5P189MB0291.EURP189.PROD.OUTLOOK.COM>
Message-ID: <fd9e4dd1-7331-8c7e-b64e-9901dd679b2e@oracle.com>

On 2018-06-12 17:26, Peter Budai wrote:
>
> Hi,
>
> You can find the patches here:
>
> https://github.com/peterbud/MINGW-packages/tree/openjdk/mingw-w64-openjdk
>
> I have managed to build OpenJDK on MSYS2 with gcc, both 32 and 64 bit, 
> but that was obviously the beginning. Around 10% of the test cases 
> were failing so more work would have been needed. However since 
> December I have not worked on that, as (don?t take it personal pls) I 
> have not received feedback on what is the best way to work towards 
> reviewing (and ultimately merging) these changes.
>
Hi Peter,

I think you should split up your work in two parts. The first would be 
to just build OpenJDK on msys2. Since we have been supporting msys in 
the past, this should be trivial to just get pushed.

The next step would probably involve me (or possibly Erik) cleaning up 
some of the logic in the shared build code, were we have incorrectly 
tested if the OS is Windows, when we *really* should have tested if 
we've using the Microsoft toolchain. It's been on my mental todo list 
for quite some time, but since we have up until now had a 1-1 
relationship between OS and toolchain, this has not been prioritized.

With that in place, your patches can probably be easily adapted. Then 
comes the hard part of figuring out what is causing the failures (if 
you're lucky it's all the symptoms of a very short list of real issues, 
most likely incorrectly compiled code in Hotspot).

We have traditionally have had quite a high bar for allow new ports, but 
a much lower bar for accepting a new compiler for an existing platform, 
so I assume that you will not get as much resistance from that point.

Have you signed the OCA (Oracle Contributor's Agreement)? [1] That's a 
prerequisite for any patches to be accepted.

/Magnus

[1] http://openjdk.java.net/contribute/

> Good luck on your journey.
>
> Peter
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> ------------------------------------------------------------------------
> *From:* Thomas St?fe <thomas.stuefe at gmail.com>
> *Sent:* Tuesday, June 12, 2018 11:49:00 AM
> *To:* Magnus Ihse Bursie; jbvernee
> *Cc:* build-dev; Peter Budai
> *Subject:* Re: bash configure - LINK : fatal error LNK1104: cannot 
> open file ...fixpath.exe
> I second the advice to get cygwin up and running. Cygwin is the
> canonical way to build on windows. Unless you have really pressing
> reasons to use something else, I would use what (almost) everyone else
> uses.
>
> I have my windows build env up and running on a fresh windows machine
> usually in ~30 minutes. It should not be rocket science. I use both
> windows 7 and 10 for my work.
>
> Some more points, in additions to what the others wrote:
>
> - 64bit seems to be the standard: 64bit windows, building 64bit ojdk
> with a 64bit cygwin. Other configurations may work but are less well
> tested. Just something to keep in mind.
>
> - If you do not trust your windows machine and suspect its software
> stack may be messed up somehow, there is always the option of
> installing a fresh copy of windows in a virtual machine, e.g.
> VirtualBox, and install the tool chain from scratch (cygwin + vistual
> studio).
>
> Best Regards & good luck,
>
> Thomas
>
>
>
>
> On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
> > Hi Jorn,
> >
> > As you probably have understood by now, porting OpenJDK to msys2 is 
> not just
> > a simple quick fix. If all you want is to build OpenJDK on your Windows
> > computer, you are probably better off by trying to fix your Cygwin
> > installation. From your description, it sounds like you'll need to 
> rebase
> > it: http://cygwin.wikia.com/wiki/Rebaseall.
> >
> > If you want to pursue the msys2 path (and I'd appreciate it; it would be
> > good to get OpenJDK working on msys again), I suggest you start by 
> looking
> > at the work that had been done before (but never merged into 
> mainline). See
> > this conversation:
> >
> > 
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html
> >
> > Peter Budai got the msys part working, but he had more ambitious 
> goals of
> > getting gcc to build on Windows, which is magnitudes more work, so 
> his patch
> > was never finished. Nevertheless, he published a patch in [1] which got
> > stripped by the mailing list. I've put it up here:
> >
> > http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch 
> <http://cr.openjdk.java.net/%7Eihse/msys2/jdk9-mingw.patch>
> >
> > It is for jdk9 so it's not possibly to apply out of the box, but you can
> > probably see what's been done and trying to reimplement it. I think the
> > "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
> > disables msys2 path mangling.
> >
> > Good luck!
> >
> > /Magnus
> >
> > [1]
> > 
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html
> >
> >
> >
> > On 2018-06-11 23:26, jbvernee wrote:
> >>
> >> Hello,
> >>
> >> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks 
> for the
> >> suggestion. It's supposed to be a semi-colon separated list of argument
> >> prefixes (they have some examples like `/switch;/sdcard;--root=`), so I
> >> tried setting it to `/out:`, `-Fe` (from the .m4 file) and `/out`, 
> and also
> >> just the entire path that is being mangled. But none of them worked :(
> >> (still the same error).
> >>
> >> I'm trying to build the amber repo, which I think is parallel with 
> jdk/jdk
> >> tip? Any ways, there is no autogen.sh in /make/autoconf and anytime 
> I make
> >> changes to the .m4 file it mentions something about having to 
> regenerate the
> >> configure file. I can also see the changes I make in
> >> `/build/.configure-support/generated-configure.sh`, which currently 
> looks
> >> like this (the part I mentioned):
> >>
> >> ```
> >>???? #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
> >>???? #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
> >>???? cd $CURDIR
> >>???? echo "#####################" here
> >>???? #if test ! -x $FIXPATH_BIN; then
> >>???? #? cd $FIXPATH_DIR
> >>???? #? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
> >> 2>&1
> >>???? #? cd $CURDIR
> >>???? #fi
> >>???? echo "#####################" there
> >>
> >>???? if test ! -x $FIXPATH_BIN; then
> >>?????? { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> >> $as_echo "no" >&6; }
> >>?????? cat $FIXPATH_DIR/fixpath1.log
> >>?????? as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5
> >>???? fi
> >> ```
> >>
> >> Which gives me this output (the last few lines):
> >>
> >> ```
> >> checking if fixpath can be created...
> >> ##################### here
> >> ##################### there
> >> no
> >> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
> >> Copyright (C) Microsoft Corporation.? All rights reserved.
> >> configure: error: Could not create
> >> 
> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe
> >> J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning C4477:
> >> 'fprintf' : format string '%s' requires an argument of type 'char 
> *', but
> >> variadic argument 3 has type 'LPVOID'
> >> Microsoft (R) Incremental Linker Version 14.00.24215.1
> >> Copyright (C) Microsoft Corporation.? All rights reserved.
> >>
> >>
> >> 
> /out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> >> fixpath.obj
> >> LINK : fatal error LNK1104: cannot open file
> >> 
> 'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
> >> configure exiting with result code 1
> >> ```
> >>
> >> So the changes I'm making seem to be going through... well... at 
> least as
> >> far as the echo statements go. I also tried using -e on the check 
> that is
> >> not comment out, but with no different results (I'm also using 
> autoconf 2.69
> >> btw). This is kind of a head scratcher ?h. I'm calling it a night, 
> I think
> >> I'll also try taking this up with the msys guys, some other time.
> >>
> >> Thanks for the help so far,
> >> Jorn Vernee
> >>
> >> Erik Joelsson schreef op 2018-06-11 22:19:
> >>>
> >>> Hello,
> >>>
> >>> On 2018-06-11 13:00, jbvernee wrote:
> >>>>
> >>>> Hello Erik,
> >>>>
> >>>> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've
> >>>> been banging my head against trying to build the JDK on my 
> machine on and
> >>>> off for a few months. So at this point I really appreciate any 
> help that
> >>>> gets me even an inch further, thanks.
> >>>>
> >>>> After your suggestion, I have tracked down the call site of the 
> compile
> >>>> command and checked the paths that are being used in 
> basics_windows.m4 (line
> >>>> 406) to compile fixpath.exe:
> >>>>
> >>>> ```
> >>>>???? cd $FIXPATH_DIR
> >>>>???? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
> >>>> 2>&1
> >>>>???? cd $CURDIR
> >>>> ```
> >>>> They are:
> >>>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
> >>>> $FIXPATH_BIN_W =
> >>>> 
> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> >>>> $FIXPATH_DIR =
> >>>> 
> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
> >>>>
> >>>> Note that the second one is a windows style path. I can change 
> that to
> >>>> use the unix style path, and that does affect the error message, 
> I now see:
> >>>> 
> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'`
> >>>> as the path in the linker error. But of course the Visual Studios 
> linker
> >>>> can't do anything with a unix style path.
> >>>>
> >>>> What's weird is that either path is working for the C compiler 
> (cl), but
> >>>> it is being mangled before being passed to the linker, and I 
> can't find
> >>>> where the linker command is actually being fired off. It seems to 
> be done by
> >>>> that same line. I was hoping you could tell me more about that?
> >>>>
> >>> AFAIK, we compile fixpath from a single source file directly into an
> >>> executable, so it's cl that calls link. Somewhere along the way, msys
> >>> decides to mangle your path argument incorrectly. You could try using
> >>> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly
> >>> how it works but I know you can affect the mangling using this env
> >>> variable.
> >>>>
> >>>> One other idea I had, but haven't been able to implement, is to check
> >>>> whether the fixpath tool exists before trying to compile it. That 
> way I
> >>>> could just compile it manually. I have tried this snippet in
> >>>> basics_windows.m4 at line 404:
> >>>> ```
> >>>>???? #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
> >>>>???? #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
> >>>>???? cd $CURDIR
> >>>>???? if test ! -x $FIXPATH_BIN; then
> >>>>?????? cd $FIXPATH_DIR
> >>>>?????? $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > 
> $FIXPATH_DIR/fixpath1.log
> >>>> 2>&1
> >>>>?????? cd $CURDIR
> >>>>???? fi
> >>>> ```
> >>>>
> >>>> i.e. check if fixpath.exe exists, otherwise compile it (I don't 
> know the
> >>>> source language though, so I just copied that from somewhere 
> else). That
> >>>> didn't work, the check seems to be failing and it's still trying 
> to compile
> >>>> (and I don't know why, I hope it's not a tabs vs. spaces issue?). 
> I also
> >>>> tried just commenting that part out completely, but it's STILL 
> trying to
> >>>> compile. I have no idea why that is happening a this point. It's also
> >>>> immediately spitting out 'no' after printing 'checking if fixpath 
> can be
> >>>> created...', even before all the output from the compiler, so it 
> almost
> >>>> seems like the command is being fired off from somewhere else? Or 
> maybe it's
> >>>> just a race condition, idk.
> >>>>
> >>> What version of OpenJDK are you trying to build? As in which
> >>> repository did you clone. Depending on which, you may need to
> >>> explicitly regenerate the configure script after making changes to .m4
> >>> files. There is a script, autogen.sh, in the same directory as the .m4
> >>> files to do it correctly. This requires autoconf 2.69 to be available.
> >>>
> >>> The language in .m4 is autoconf, which (in our case) is bash shell
> >>> with m4 macros on top. Most of the source, including your snippet
> >>> above is just bash. So your change above looks correct, you just need
> >>> to get it to be used. You could try changing the -x to -e in case
> >>> execute permissions aren't translated properly between msys and
> >>> windows.
> >>>
> >>> /Erik
> >>>>
> >>>> If you have any more suggestions I really appreciate it, but if 
> it's too
> >>>> much trouble for an unsupported build system I understand.
> >>>>
> >>>> Best regards,
> >>>> Jorn Vernee
> >>>>
> >



From peterbudai at hotmail.com  Fri Jun 15 15:39:44 2018
From: peterbudai at hotmail.com (Peter Budai)
Date: Fri, 15 Jun 2018 15:39:44 +0000
Subject: bash configure - LINK : fatal error LNK1104: cannot open file
 ...fixpath.exe
In-Reply-To: <fd9e4dd1-7331-8c7e-b64e-9901dd679b2e@oracle.com>
References: <9e2cfc114e8ad369e816b177263ae307@xs4all.nl>
 <174f3a81-f944-2d16-276e-b0521c050e99@oracle.com>
 <67183278662bad531e2e89439bb98658@xs4all.nl>
 <3518aaef-fa88-3449-3eb5-3a06aec75a9a@oracle.com>
 <9eabe81c112549aac7dbb3f0f90b4eb6@xs4all.nl>
 <190e7f3c-845f-30b2-9453-4255c1ba94cc@oracle.com>
 <CAA-vtUzjOcbN-XpOrxRPXg3_BUjyywxXUqxJMkdKtmsKF3SbYw@mail.gmail.com>
 <AM5P189MB02917504EAB0FB70BA4585E8C27F0@AM5P189MB0291.EURP189.PROD.OUTLOOK.COM>,
 <fd9e4dd1-7331-8c7e-b64e-9901dd679b2e@oracle.com>
Message-ID: <AM5P189MB0291B5363E602759775152F4C27C0@AM5P189MB0291.EURP189.PROD.OUTLOOK.COM>

Hi Magnus,

Yes, I have signed OCA last October, and Dalibor Topic has processed it.

I?m happy to work on the msys2 build part with you and Erik.

As far as I recall, the hotspot tests were really close, the number of failed test cases seemed to be manageable:
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:hotspot/test:hotspot_all                     1428  1364    33    31 <<
==============================


Peter

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

________________________________
From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Friday, June 15, 2018 3:38:08 PM
To: Peter Budai
Cc: build-dev
Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe

On 2018-06-12 17:26, Peter Budai wrote:

Hi,



You can find the patches here:

https://github.com/peterbud/MINGW-packages/tree/openjdk/mingw-w64-openjdk



I have managed to build OpenJDK on MSYS2 with gcc, both 32 and 64 bit, but that was obviously the beginning. Around 10% of the test cases were failing so more work would have been needed. However since December I have not worked on that, as (don?t take it personal pls) I have not received feedback on what is the best way to work towards reviewing (and ultimately merging) these changes.

Hi Peter,

I think you should split up your work in two parts. The first would be to just build OpenJDK on msys2. Since we have been supporting msys in the past, this should be trivial to just get pushed.

The next step would probably involve me (or possibly Erik) cleaning up some of the logic in the shared build code, were we have incorrectly tested if the OS is Windows, when we *really* should have tested if we've using the Microsoft toolchain. It's been on my mental todo list for quite some time, but since we have up until now had a 1-1 relationship between OS and toolchain, this has not been prioritized.

With that in place, your patches can probably be easily adapted. Then comes the hard part of figuring out what is causing the failures (if you're lucky it's all the symptoms of a very short list of real issues, most likely incorrectly compiled code in Hotspot).

We have traditionally have had quite a high bar for allow new ports, but a much lower bar for accepting a new compiler for an existing platform, so I assume that you will not get as much resistance from that point.

Have you signed the OCA (Oracle Contributor's Agreement)? [1] That's a prerequisite for any patches to be accepted.

/Magnus

[1] http://openjdk.java.net/contribute/




Good luck on your journey.



Peter



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



________________________________
From: Thomas St?fe <thomas.stuefe at gmail.com><mailto:thomas.stuefe at gmail.com>
Sent: Tuesday, June 12, 2018 11:49:00 AM
To: Magnus Ihse Bursie; jbvernee
Cc: build-dev; Peter Budai
Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe

I second the advice to get cygwin up and running. Cygwin is the
canonical way to build on windows. Unless you have really pressing
reasons to use something else, I would use what (almost) everyone else
uses.

I have my windows build env up and running on a fresh windows machine
usually in ~30 minutes. It should not be rocket science. I use both
windows 7 and 10 for my work.

Some more points, in additions to what the others wrote:

- 64bit seems to be the standard: 64bit windows, building 64bit ojdk
with a 64bit cygwin. Other configurations may work but are less well
tested. Just something to keep in mind.

- If you do not trust your windows machine and suspect its software
stack may be messed up somehow, there is always the option of
installing a fresh copy of windows in a virtual machine, e.g.
VirtualBox, and install the tool chain from scratch (cygwin + vistual
studio).

Best Regards & good luck,

Thomas




On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com><mailto:magnus.ihse.bursie at oracle.com> wrote:
> Hi Jorn,
>
> As you probably have understood by now, porting OpenJDK to msys2 is not just
> a simple quick fix. If all you want is to build OpenJDK on your Windows
> computer, you are probably better off by trying to fix your Cygwin
> installation. From your description, it sounds like you'll need to rebase
> it: http://cygwin.wikia.com/wiki/Rebaseall.
>
> If you want to pursue the msys2 path (and I'd appreciate it; it would be
> good to get OpenJDK working on msys again), I suggest you start by looking
> at the work that had been done before (but never merged into mainline). See
> this conversation:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html
>
> Peter Budai got the msys part working, but he had more ambitious goals of
> getting gcc to build on Windows, which is magnitudes more work, so his patch
> was never finished. Nevertheless, he published a patch in [1] which got
> stripped by the mailing list. I've put it up here:
>
> http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch<http://cr.openjdk.java.net/%7Eihse/msys2/jdk9-mingw.patch>
>
> It is for jdk9 so it's not possibly to apply out of the box, but you can
> probably see what's been done and trying to reimplement it. I think the
> "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
> disables msys2 path mangling.
>
> Good luck!
>
> /Magnus
>
> [1]
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html
>
>
>
> On 2018-06-11 23:26, jbvernee wrote:
>>
>> Hello,
>>
>> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks for the
>> suggestion. It's supposed to be a semi-colon separated list of argument
>> prefixes (they have some examples like `/switch;/sdcard;--root=`), so I
>> tried setting it to `/out:`, `-Fe` (from the .m4 file) and `/out`, and also
>> just the entire path that is being mangled. But none of them worked :(
>> (still the same error).
>>
>> I'm trying to build the amber repo, which I think is parallel with jdk/jdk
>> tip? Any ways, there is no autogen.sh in /make/autoconf and anytime I make
>> changes to the .m4 file it mentions something about having to regenerate the
>> configure file. I can also see the changes I make in
>> `/build/.configure-support/generated-configure.sh`, which currently looks
>> like this (the part I mentioned):
>>
>> ```
>>     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>     cd $CURDIR
>>     echo "#####################" here
>>     #if test ! -x $FIXPATH_BIN; then
>>     #  cd $FIXPATH_DIR
>>     #  $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>> 2>&1
>>     #  cd $CURDIR
>>     #fi
>>     echo "#####################" there
>>
>>     if test ! -x $FIXPATH_BIN; then
>>       { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
>> $as_echo "no" >&6; }
>>       cat $FIXPATH_DIR/fixpath1.log
>>       as_fn_error $? "Could not create $FIXPATH_BIN" "$LINENO" 5
>>     fi
>> ```
>>
>> Which gives me this output (the last few lines):
>>
>> ```
>> checking if fixpath can be created...
>> ##################### here
>> ##################### there
>> no
>> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>> configure: error: Could not create
>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/cofixpath.cupport/bin/fixpath.exe
>> J:/Projects/openjdk/amber/make/src/native/fixpath.c(49): warning C4477:
>> 'fprintf' : format string '%s' requires an argument of type 'char *', but
>> variadic argument 3 has type 'LPVOID'
>> Microsoft (R) Incremental Linker Version 14.00.24215.1
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>>
>> /out:J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>> fixpath.obj
>> LINK : fatal error LNK1104: cannot open file
>> 'J:J:/msys64/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
>> configure exiting with result code 1
>> ```
>>
>> So the changes I'm making seem to be going through... well... at least as
>> far as the echo statements go. I also tried using -e on the check that is
>> not comment out, but with no different results (I'm also using autoconf 2.69
>> btw). This is kind of a head scratcher ?h. I'm calling it a night, I think
>> I'll also try taking this up with the msys guys, some other time.
>>
>> Thanks for the help so far,
>> Jorn Vernee
>>
>> Erik Joelsson schreef op 2018-06-11 22:19:
>>>
>>> Hello,
>>>
>>> On 2018-06-11 13:00, jbvernee wrote:
>>>>
>>>> Hello Erik,
>>>>
>>>> Thank you for the suggestion. Unfortunately it didn't help. TBH, I've
>>>> been banging my head against trying to build the JDK on my machine on and
>>>> off for a few months. So at this point I really appreciate any help that
>>>> gets me even an inch further, thanks.
>>>>
>>>> After your suggestion, I have tracked down the call site of the compile
>>>> command and checked the paths that are being used in basics_windows.m4 (line
>>>> 406) to compile fixpath.exe:
>>>>
>>>> ```
>>>>     cd $FIXPATH_DIR
>>>>     $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>>>> 2>&1
>>>>     cd $CURDIR
>>>> ```
>>>> They are:
>>>> $CC = /j/progra~2/micros~2.0/vc/bin/amd64/cl
>>>> $FIXPATH_BIN_W =
>>>> J:/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>>>> $FIXPATH_DIR =
>>>> /J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/fixpath
>>>>
>>>> Note that the second one is a windows style path. I can change that to
>>>> use the unix style path, and that does affect the error message, I now see:
>>>> `'/J/Projects/openjdk/amber/make/autoconf/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'`
>>>> as the path in the linker error. But of course the Visual Studios linker
>>>> can't do anything with a unix style path.
>>>>
>>>> What's weird is that either path is working for the C compiler (cl), but
>>>> it is being mangled before being passed to the linker, and I can't find
>>>> where the linker command is actually being fired off. It seems to be done by
>>>> that same line. I was hoping you could tell me more about that?
>>>>
>>> AFAIK, we compile fixpath from a single source file directly into an
>>> executable, so it's cl that calls link. Somewhere along the way, msys
>>> decides to mangle your path argument incorrectly. You could try using
>>> MSYS2_ARG_CONV_EXCL to disable the mangling. I don't remember exactly
>>> how it works but I know you can affect the mangling using this env
>>> variable.
>>>>
>>>> One other idea I had, but haven't been able to implement, is to check
>>>> whether the fixpath tool exists before trying to compile it. That way I
>>>> could just compile it manually. I have tried this snippet in
>>>> basics_windows.m4 at line 404:
>>>> ```
>>>>     #$RM -rf $FIXPATH_BIN $FIXPATH_DIR
>>>>     #$MKDIR -p $FIXPATH_DIR $CONFIGURESUPPORT_OUTPUTDIR/bin
>>>>     cd $CURDIR
>>>>     if test ! -x $FIXPATH_BIN; then
>>>>       cd $FIXPATH_DIR
>>>>       $CC $FIXPATH_SRC_W -Fe$FIXPATH_BIN_W > $FIXPATH_DIR/fixpath1.log
>>>> 2>&1
>>>>       cd $CURDIR
>>>>     fi
>>>> ```
>>>>
>>>> i.e. check if fixpath.exe exists, otherwise compile it (I don't know the
>>>> source language though, so I just copied that from somewhere else). That
>>>> didn't work, the check seems to be failing and it's still trying to compile
>>>> (and I don't know why, I hope it's not a tabs vs. spaces issue?). I also
>>>> tried just commenting that part out completely, but it's STILL trying to
>>>> compile. I have no idea why that is happening a this point. It's also
>>>> immediately spitting out 'no' after printing 'checking if fixpath can be
>>>> created...', even before all the output from the compiler, so it almost
>>>> seems like the command is being fired off from somewhere else? Or maybe it's
>>>> just a race condition, idk.
>>>>
>>> What version of OpenJDK are you trying to build? As in which
>>> repository did you clone. Depending on which, you may need to
>>> explicitly regenerate the configure script after making changes to .m4
>>> files. There is a script, autogen.sh, in the same directory as the .m4
>>> files to do it correctly. This requires autoconf 2.69 to be available.
>>>
>>> The language in .m4 is autoconf, which (in our case) is bash shell
>>> with m4 macros on top. Most of the source, including your snippet
>>> above is just bash. So your change above looks correct, you just need
>>> to get it to be used. You could try changing the -x to -e in case
>>> execute permissions aren't translated properly between msys and
>>> windows.
>>>
>>> /Erik
>>>>
>>>> If you have any more suggestions I really appreciate it, but if it's too
>>>> much trouble for an unsupported build system I understand.
>>>>
>>>> Best regards,
>>>> Jorn Vernee
>>>>
>



From erik.joelsson at oracle.com  Fri Jun 15 15:50:05 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 15 Jun 2018 08:50:05 -0700
Subject: client VM build doesn't build in parallel anymore
In-Reply-To: <0a60faf6-6241-50b9-1c3c-d8028dd5aeff@ubuntu.com>
References: <0a60faf6-6241-50b9-1c3c-d8028dd5aeff@ubuntu.com>
Message-ID: <dfec2883-99d9-b139-c770-2d9eb2c14fa8@oracle.com>

Hello Matthias,

I believe I know the problem. I fixed it in my patch currently under 
review here (see GensrcJfr.gmk):

http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html

That patch will take a while before it gets in though because it needs 
to go through the JEP process first. Please take just the GensrcJfr.gmk 
patch and try it. That part could be separated out into its own fix.

/Erik


On 2018-06-15 05:04, Matthias Klose wrote:
> Since b14 or b15, the client VM on x86 doesn't build anymore when 
> building with
>
> ? --with-jvm-variants=client,server --with-num-cores=4
>
> building with one to three cores seems to work however. The server and 
> zero VMs build without issues and parallel builds.? Any idea which 
> dependencies got dropped?
>
> javac: file not found: 
> /home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
> make[4]: *** 
> [/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch] 
> Error 3
> make[4]: *** Deleting file 
> '/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch'
> gensrc/GensrcJfr.gmk:40: recipe for target 
> '/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch' 
> failed
> make[4]: Leaving directory 
> '/home/packages/openjdk/11/openjdk-11-11~18/make/hotspot'
> make[3]: *** [hotspot-client-gensrc] Error 2
> make[3]: *** Waiting for unfinished jobs....
> make/Main.gmk:249: recipe for target 'hotspot-client-gensrc' failed
>



From erik.joelsson at oracle.com  Fri Jun 15 15:53:48 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 15 Jun 2018 08:53:48 -0700
Subject: [8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used
In-Reply-To: <b70c37dca70132962be5b0dfa919cda2f8251d0c.camel@redhat.com>
References: <b70c37dca70132962be5b0dfa919cda2f8251d0c.camel@redhat.com>
Message-ID: <1a1feba3-4ff4-7701-7f94-54a5cdd9b7c5@oracle.com>

Looks good.

/Erik


On 2018-06-15 05:59, Severin Gehwolf wrote:
> Hi,
>
> This is a JDK 8u specific problem. It's not applicable to 10/11 since
> the build system has changed. Make files in JDK 8 live in the hotspot
> tree, hence, I'm also including hotspot-dev. The issue at hand is that
> linker flags are not consistently passed down to individual library
> builds. Specifically libjvm.so, libjsig.so and libsaproc.so. This
> prevents downstream users from producing hardened builds. We have been
> using this patch in downstream Fedora for a while now without issues.
>
> Please review!
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205104
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/
>
> Testing:
>
> Before:
> $ for i in build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so; do \
>     echo $i; readelf -d $i | grep NOW
>    done
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
>
> After:
> $ for i in build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so \
>           build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so; do \
>     echo $i; readelf -d $i | grep NOW
>    done
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
>   0x0000000000000018 (BIND_NOW)
>   0x000000006ffffffb (FLAGS_1)            Flags: NOW
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
>   0x0000000000000018 (BIND_NOW)
>   0x000000006ffffffb (FLAGS_1)            Flags: NOW
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
>   0x0000000000000018 (BIND_NOW)
>   0x000000006ffffffb (FLAGS_1)            Flags: NOW
>
> Thanks,
> Severin



From rene.schuenemann at gmail.com  Fri Jun 15 09:08:06 2018
From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=)
Date: Fri, 15 Jun 2018 11:08:06 +0200
Subject: RFR: 8205091: AIX: build errors in hotspot after 8203641:
 Refactor String Deduplication into shared
In-Reply-To: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
References: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
Message-ID: <CAL26=jO0Bmw6VbMhO-uyXD0w3m=8iFcYnqjK=DRf23EUj4in8Q@mail.gmail.com>

Hi Matthias,

the name SI seems also quite "common" and may result in other naming
clashes in the future.
Maybe something more readable like STAT_IMPL?

Please also change the name in the comment:

// STAT:  String Dedup Stat implementation

Regards,
Rene

On Fri, Jun 15, 2018 at 9:47 AM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> Please review  this small  change  that fixes the AIX build after  "8203641: Refactor String Deduplication into shared"    .
>
> We are getting this  compilation error  :
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp", line 107.38: 1540-0063 (S) The text "1" is unexpected.
>
>
> Looks like the name of the second template parameter (STAT)
>
>     template <typename QUEUE, typename STAT>
>     static void initialize_impl();
>
> is clashing with defines from the AIX system headers  (where I find  #define STAT  1 ) .
> Renaming  STAT  to something else fixes the build on AIX .
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8205091
>
>
> Thanks, Matthias


From zgu at redhat.com  Fri Jun 15 12:30:40 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 15 Jun 2018 08:30:40 -0400
Subject: RFR: 8205091: AIX: build errors in hotspot after 8203641:
 Refactor String Deduplication into shared
In-Reply-To: <CAA-vtUzmNyb22g7juHQNWL81QRYgE279TVd--vopOiw5NNb6YQ@mail.gmail.com>
References: <1a62b7b4123c45f1a0e57774d72ee683@sap.com>
 <CAA-vtUzmNyb22g7juHQNWL81QRYgE279TVd--vopOiw5NNb6YQ@mail.gmail.com>
Message-ID: <67e9c38c-48e4-26ad-116b-81568d2deee7@redhat.com>

Hi,

Whatever the name you come up, could you please also update 
stringDedup.inline.hpp to use the same names?

Thomas Schatzl pointed out the inconsistent, I made change to use S and 
Q, but apparently, I messed up in final patch.

Otherwise, looks good to me too.

-Zhengyu



On 06/15/2018 06:36 AM, Thomas St?fe wrote:
> Hi Matthias,
> 
> Good catch. Patch for me is good if you guys agree on a good uncommon name.
> 
> Gru? Thomas
> 
> On Fri, Jun 15, 2018, 09:48 Baesken, Matthias <matthias.baesken at sap.com>
> wrote:
> 
>> Please review  this small  change  that fixes the AIX build after
>> "8203641: Refactor String Deduplication into shared"    .
>>
>> We are getting this  compilation error  :
>> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
>> line 107.38: 1540-0063 (S) The text "1" is unexpected.
>>
>>
>> Looks like the name of the second template parameter (STAT)
>>
>>      template <typename QUEUE, typename STAT>
>>      static void initialize_impl();
>>
>> is clashing with defines from the AIX system headers  (where I find
>> #define STAT  1 ) .
>> Renaming  STAT  to something else fixes the build on AIX .
>>
>> Webrev :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>>
>> Bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8205091
>>
>>
>> Thanks, Matthias
>>


From fridrich.strba at suse.com  Fri Jun 15 16:02:45 2018
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Fri, 15 Jun 2018 18:02:45 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
Message-ID: <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>

Hello, Magnus,

Your original patch had a problem, since the second statement overwrote
the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
like osSupport.hpp, jawt_md.h and so on could not be found in build of
tests. So, I modified your patch to read as attached and the build
finished. It is basically a 2-liner.

Cheers

Fridrich

On 15/06/18 13:10, Magnus Ihse Bursie wrote:
> Here's a better patch. Please try and see if it solves your problems.
> Unfortunately, I'm leaving on vacation for today and will be gone most
> of the summer, so I can't help sponsor this patch. But if it works, I'm
> sure someone else can take over it.
> 
> If it does not work, the original patch should at the very least be
> changed so that EXTRA_HEADER_DIRS gets an additional "$(call
> GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
> hard to eradicate from the CFLAGS).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generated-headers.patch
Type: text/x-patch
Size: 589 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20180615/e3dc5649/generated-headers.patch>

From 2020sebastian at gmail.com  Mon Jun 11 19:49:06 2018
From: 2020sebastian at gmail.com (Sebastian Demian)
Date: Mon, 11 Jun 2018 14:49:06 -0500
Subject: build fail
Message-ID: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>

Hello,

I am trying to setup project panama on my local mac, and I am not able to
build the project.

Configuration summary:
* Debug level:    release
* HS debug level: product
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.sd.panama (9-internal)

Tools summary:
* Boot JDK:       java version "1.8.0_171" Java(TM) SE Runtime Environment
(build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM)
* C Compiler:     Version 9.1.0 (at /usr/bin/clang)
* C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB




I have attached the full log output from running make. I have read the
building.html and troubleshooting section and did not find anything
relevant to this error:

/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
    ^
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
                                     ^
In file included from
/Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
In file included from
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
    ^


Any help would be appreciated.

Thanks,
Sebastian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log
Type: application/octet-stream
Size: 4811 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20180611/3ae2ab61/make.log>

From jiangli.zhou at oracle.com  Fri Jun 15 16:47:29 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 15 Jun 2018 09:47:29 -0700
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh11hyFxxBCso7c+xKgBJ=FV-gQ9rmf1pOquC=y3zxjbU9w@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <14702170-8CA5-4033-B3EE-CE12C906BDE7@oracle.com>
 <CA+3eh11hyFxxBCso7c+xKgBJ=FV-gQ9rmf1pOquC=y3zxjbU9w@mail.gmail.com>
Message-ID: <97125D19-9C38-4953-A3DB-1D18892F3925@oracle.com>

Hi Volker,

> On Jun 15, 2018, at 12:43 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Jiangli,
> 
> thanks for looking at the change.
> 
> 'CDS_only' is only required for static fields because the
> VMStructEntry for them contains a reference to the actual static field
> which isn't present if we disable CDS, because the corresponding
> compilations units (i.e. filemap.cpp) won't be part of libjvm.so. For
> non-static fields, the VMStructEntry structure only contains the
> offset of the corresponding field with regards to an object of that
> type which is harmless.

Thanks for the explanation. For consistency, would it be worth to add CDS_ONLY for the non-static fields in FileMapInfo also?

Thanks,
Jiangli

> 
> Regards,
> Volker
> 
> 
> On Thu, Jun 14, 2018 at 6:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>> Hi Volker,
>> 
>> The changes look good to me overall. I?ll refer to the JVMTI experts for
>> jvmtiEnv.cpp change. I have a question for the change in vmStructs.cpp. Any
>> reason why only _current_info needs CDS_ONLY?
>> 
>>   /********************************************/
>> \
>>   /* FileMapInfo fields (CDS archive related) */
>> \
>>   /********************************************/
>> \
>> 
>> \
>>   nonstatic_field(FileMapInfo,                 _header,
>> FileMapInfo::FileMapHeader*)           \
>> -     static_field(FileMapInfo,                 _current_info,
>> FileMapInfo*)                          \
>> +     CDS_ONLY(static_field(FileMapInfo,        _current_info,
>> FileMapInfo*))                         \
>>   nonstatic_field(FileMapInfo::FileMapHeader,  _space[0],
>> FileMapInfo::FileMapHeader::space_info)\
>>   nonstatic_field(FileMapInfo::FileMapHeader::space_info, _addr._base,
>> char*)                                 \
>>   nonstatic_field(FileMapInfo::FileMapHeader::space_info, _used,
>> size_t)                                \
>> 
>> \
>> 
>> Thanks,
>> Jiangli
>> 
>> On Jun 14, 2018, at 7:26 AM, Volker Simonis <volker.simonis at gmail.com>
>> wrote:
>> 
>> Hi,
>> 
>> can I please have a review for the following fix:
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>> https://bugs.openjdk.java.net/browse/JDK-8204965
>> 
>> CDS does currently not work on AIX because of the way how we
>> reserve/commit memory on AIX. The problem is that we're using a
>> combination of shmat/mmap depending on the page size and the size of
>> the memory chunk to reserve. This makes it impossible to reliably
>> reserve the memory for the CDS archive and later on map the various
>> parts of the archive into these regions.
>> 
>> In order to fix this we would have to completely rework the memory
>> reserve/commit/uncommit logic on AIX which is currently out of our
>> scope because of resource limitations.
>> 
>> Unfortunately, I could not simply disable CDS in the configure step
>> because some of the shared code apparently relies on parts of the CDS
>> code which gets excluded from the build when CDS is disabled. So I
>> also fixed the offending parts in hotspot and cleaned up the configure
>> logic for CDS.
>> 
>> Thank you and best regards,
>> Volker
>> 
>> PS: I did run the job through the submit forest
>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>> weren't really useful because they mention build failures on linux-x64
>> which I can't reproduce locally.
>> 
>> 



From thomas.stuefe at gmail.com  Fri Jun 15 16:52:39 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 15 Jun 2018 18:52:39 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh13b7BiQtLzXzX1qPeUdEwy1+YmAToc=BF_E9+ObepuvQQ@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <CAA-vtUzHaprVv=6FUt9C6h+kgPZE9Bv=9FNx4g9gaRQ5o48GSg@mail.gmail.com>
 <CA+3eh13b7BiQtLzXzX1qPeUdEwy1+YmAToc=BF_E9+ObepuvQQ@mail.gmail.com>
Message-ID: <CAA-vtUzcznOczkP1sxMKRRQ47+Xf8uRDHq7GtnzU6etB381mHw@mail.gmail.com>

Hi Volker,



On Fri, Jun 15, 2018 at 10:05 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Thu, Jun 14, 2018 at 9:04 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Hi Volker,
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html
>>
>> Seems like a roundabout way to have a platform specific default value.
>>
>> Why not determine a default value beforehand:
>>
>> if test "x$OPENJDK_TARGET_OS" = "xaix"; then
>>   ENABLE_CDS_DEFAULT="false"
>> else
>>   ENABLE_CDS_DEFAULT=true"
>> fi
>>
>> AC_ARG_ENABLE([cds], [AS_HELP_STRING([--enable-cds@<:@=yes/no/auto@:>@],
>>  [enable class data sharing feature in non-minimal VM. Default is
>> ${ENABLE_CDS_DEFAULT}.])])
>>
>> and so on?
>>
>
> I've just followed the pattern used for '--enable-aot' right above the
> code I changed.
>
> Moreover, I don't think that we would save any code because we would
> still have to check for AIX in the '--enable-cds=yes' case. Also, the
> new reporting added later in the file (see "AC_MSG_CHECKING([if cds
> should be enabled])" seems easier to me without the extra default
> value. So if you don't mind I'd prefer to leave it as is.
>

I just think that having three options (on/off/auto) is confusing.
Okay, I still think a platform dependent default value would be
cleaner, but I can live with auto="yes, if possible".

>> See also what we did for "8202325: [aix] disable warnings-as-errors by default".
>>
>> --
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/src/hotspot/share/classfile/javaClasses.cpp.udiff.html
>>
>> Here, do we really need to exclude this from compiling,
>> DumpSharedSpaces = false is not enough?
>>
>
> Yes, we need it because the excluded code references methods (e.g.
> 'StringTable::create_archived_string()') which are not compiled into
> libjvm.so if we disable CDS.
>

Are you really sure?

Both MetaspaceShared::is_archive_object() and
StringTable::create_archived_string() are available outside CDS, the
latter explicitly returns NULL if CDS is not enabled at build time:
NOT_CDS_JAVA_HEAP_RETURN_(NULL);

I also just built a Linux vm without CDS, and it compiles without
problems without the #ifdef. But maybe AIX is different.

---

But all this is idle nitpicking, so I leave it up to you if you change
anything. The change is good in its current form to me and I do not
need another webrev.

Best Regards, Thomas

>>
>> Best Regards, Thomas
>>
>> On Thu, Jun 14, 2018 at 4:26 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>> Hi,
>>>
>>> can I please have a review for the following fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>
>>> CDS does currently not work on AIX because of the way how we
>>> reserve/commit memory on AIX. The problem is that we're using a
>>> combination of shmat/mmap depending on the page size and the size of
>>> the memory chunk to reserve. This makes it impossible to reliably
>>> reserve the memory for the CDS archive and later on map the various
>>> parts of the archive into these regions.
>>>
>>> In order to fix this we would have to completely rework the memory
>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>> scope because of resource limitations.
>>>
>>> Unfortunately, I could not simply disable CDS in the configure step
>>> because some of the shared code apparently relies on parts of the CDS
>>> code which gets excluded from the build when CDS is disabled. So I
>>> also fixed the offending parts in hotspot and cleaned up the configure
>>> logic for CDS.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: I did run the job through the submit forest
>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>> weren't really useful because they mention build failures on linux-x64
>>> which I can't reproduce locally.


From erik.joelsson at oracle.com  Fri Jun 15 17:03:30 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 15 Jun 2018 10:03:30 -0700
Subject: build fail
In-Reply-To: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>
References: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>
Message-ID: <481dc7b8-3c81-0102-473e-b32e1991afe7@oracle.com>

Hello Sebastian,

Please try running configure with --disable-warnings-as-errors.

When using compiler versions (or OS versions) other than the ones listed 
in doc/building.md it's common to have warnings triggered and we run 
with warnings treated as errors by default.

/Erik


On 2018-06-11 12:49, Sebastian Demian wrote:
> Hello,
>
> I am trying to setup project panama on my local mac, and I am not able to
> build the project.
>
> Configuration summary:
> * Debug level:    release
> * HS debug level: product
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
> * Version string: 9-internal+0-adhoc.sd.panama (9-internal)
>
> Tools summary:
> * Boot JDK:       java version "1.8.0_171" Java(TM) SE Runtime Environment
> (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11,
> mixed mode)  (at
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM)
> * C Compiler:     Version 9.1.0 (at /usr/bin/clang)
> * C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)
>
> Build performance summary:
> * Cores to use:   4
> * Memory limit:   16384 MB
>
>
>
>
> I have attached the full log output from running make. I have read the
> building.html and troubleshooting section and did not find anything
> relevant to this error:
>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
> error: macro expansion producing 'defined' has undefined behavior
> [-Werror,-Wexpansion-to-defined]
> #if HEAP_REGION_SET_FORCE_VERIFY
>      ^
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
> note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>                                       ^
> In file included from
> /Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
> In file included from
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
> In file included from
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
> error: macro expansion producing 'defined' has undefined behavior
> [-Werror,-Wexpansion-to-defined]
> #if HEAP_REGION_SET_FORCE_VERIFY
>      ^
>
>
> Any help would be appreciated.
>
> Thanks,
> Sebastian.



From erik.joelsson at oracle.com  Fri Jun 15 18:12:29 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 15 Jun 2018 11:12:29 -0700
Subject: RFR: JDK-8203667: Platform specific include files in jdk image in
 wrong sub directory
Message-ID: <f3edc5da-63da-6b8d-8cea-1856d03832fb@oracle.com>

Due to a typo in spec.gmk.in, the platform specific include files have 
lost their platform sub directory in the jdk image include dir.

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

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

/Erik



From mandy.chung at oracle.com  Fri Jun 15 18:20:31 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 15 Jun 2018 11:20:31 -0700
Subject: RFR: JDK-8203667: Platform specific include files in jdk image in
 wrong sub directory
In-Reply-To: <f3edc5da-63da-6b8d-8cea-1856d03832fb@oracle.com>
References: <f3edc5da-63da-6b8d-8cea-1856d03832fb@oracle.com>
Message-ID: <4f49db01-55cd-6b97-5015-b7eaf481bae3@oracle.com>

+1

Mandy

On 6/15/18 11:12 AM, Erik Joelsson wrote:
> Due to a typo in spec.gmk.in, the platform specific include files have 
> lost their platform sub directory in the jdk image include dir.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203667
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8203667/webrev.01/
> 
> /Erik
> 


From tim.bell at oracle.com  Fri Jun 15 18:26:42 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 15 Jun 2018 11:26:42 -0700
Subject: RFR: JDK-8203667: Platform specific include files in jdk image
 in wrong sub directory
In-Reply-To: <4f49db01-55cd-6b97-5015-b7eaf481bae3@oracle.com>
References: <f3edc5da-63da-6b8d-8cea-1856d03832fb@oracle.com>
 <4f49db01-55cd-6b97-5015-b7eaf481bae3@oracle.com>
Message-ID: <5B2404E2.2070009@oracle.com>

Erik:

Looks good to me as well.

/Tim

On 06/15/18 11:20, mandy chung wrote:
> +1
>
> Mandy
>
> On 6/15/18 11:12 AM, Erik Joelsson wrote:
>> Due to a typo in spec.gmk.in, the platform specific include files have
>> lost their platform sub directory in the jdk image include dir.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203667
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8203667/webrev.01/
>>
>> /Erik
>>



From 2020sebastian at gmail.com  Fri Jun 15 19:18:47 2018
From: 2020sebastian at gmail.com (Sebastian Demian)
Date: Fri, 15 Jun 2018 14:18:47 -0500
Subject: build fail
In-Reply-To: <CAFfAmy88fDUoe16YqOG0FtS92fSCf30u4xj0c2PL3_DJ_wh54g@mail.gmail.com>
References: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>
 <481dc7b8-3c81-0102-473e-b32e1991afe7@oracle.com>
 <CAFfAmy88fDUoe16YqOG0FtS92fSCf30u4xj0c2PL3_DJ_wh54g@mail.gmail.com>
Message-ID: <CAFfAmy_dWhs03ZYxKi7ARcvJGHF8He-8o2EX=nVR7WU23LG4mg@mail.gmail.com>

+ build-dev

On Fri, Jun 15, 2018 at 2:17 PM Sebastian Demian <2020sebastian at gmail.com>
wrote:

> Thanks for the reply Erik.
>
> running with --disable-warnings-as-errors helped.
>
> I also ran make dist-clean before building again.
>
> The build failed at a later stage now.
>
>
>
> Here is the new output:
>
> Note: Recompile with -Xlint:removal for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> */Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
> ordered comparison between pointer and zero ('address' (aka 'unsigned char
> *') and 'int')*
> *  if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.*
> *      ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~*
> 1 error generated.
> make[3]: ***
> [/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/lcm.o]
> Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [hotspot-server-libs] Error 2
> make[2]: *** Waiting for unfinished jobs....
>
> ERROR: Build failed for target 'all' in configuration
> 'macosx-x86_64-normal-server-release' (exit code 2)
> Stopping sjavac server
>
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-server_libjvm_objs_lcm.o:
> /Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
> ordered comparison between pointer and zero ('address' (aka 'unsigned char
> *') and 'int')
>   if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
> 1 error generated.
>
> * All command lines available in
> /Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
> === End of repeated output ===
>
> No indication of failed target found.
> Hint: Try searching the build log for '] Error'.
> Hint: See common/doc/building.html#troubleshooting for assistance.
>
> make[1]: *** [main] Error 2
> make: *** [all] Error 2
>
>
>
> Thank you,
> Sebastian.
>
>
>
> On Fri, Jun 15, 2018 at 12:03 PM Erik Joelsson <erik.joelsson at oracle.com>
> wrote:
>
>> Hello Sebastian,
>>
>> Please try running configure with --disable-warnings-as-errors.
>>
>> When using compiler versions (or OS versions) other than the ones listed
>> in doc/building.md it's common to have warnings triggered and we run
>> with warnings treated as errors by default.
>>
>> /Erik
>>
>>
>> On 2018-06-11 12:49, Sebastian Demian wrote:
>> > Hello,
>> >
>> > I am trying to setup project panama on my local mac, and I am not able
>> to
>> > build the project.
>> >
>> > Configuration summary:
>> > * Debug level:    release
>> > * HS debug level: product
>> > * JDK variant:    normal
>> > * JVM variants:   server
>> > * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>> > * Version string: 9-internal+0-adhoc.sd.panama (9-internal)
>> >
>> > Tools summary:
>> > * Boot JDK:       java version "1.8.0_171" Java(TM) SE Runtime
>> Environment
>> > (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
>> 25.171-b11,
>> > mixed mode)  (at
>> > /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
>> > * Toolchain:      clang (clang/LLVM)
>> > * C Compiler:     Version 9.1.0 (at /usr/bin/clang)
>> > * C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)
>> >
>> > Build performance summary:
>> > * Cores to use:   4
>> > * Memory limit:   16384 MB
>> >
>> >
>> >
>> >
>> > I have attached the full log output from running make. I have read the
>> > building.html and troubleshooting section and did not find anything
>> > relevant to this error:
>> >
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
>> > error: macro expansion producing 'defined' has undefined behavior
>> > [-Werror,-Wexpansion-to-defined]
>> > #if HEAP_REGION_SET_FORCE_VERIFY
>> >      ^
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
>> > note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>> > #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>> >                                       ^
>> > In file included from
>> >
>> /Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>> > In file included from
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>> > In file included from
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
>> > error: macro expansion producing 'defined' has undefined behavior
>> > [-Werror,-Wexpansion-to-defined]
>> > #if HEAP_REGION_SET_FORCE_VERIFY
>> >      ^
>> >
>> >
>> > Any help would be appreciated.
>> >
>> > Thanks,
>> > Sebastian.
>>
>>


From magnus.ihse.bursie at oracle.com  Fri Jun 15 20:10:36 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 22:10:36 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
Message-ID: <da1b2d6c-7a52-7b7f-1659-084bbaf64c96@oracle.com>



On 2018-06-15 18:02, Fridrich Strba wrote:
> Hello, Magnus,
>
> Your original patch had a problem, since the second statement overwrote
> the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
> like osSupport.hpp, jawt_md.h and so on could not be found in build of
> tests. So, I modified your patch to read as attached and the build
> finished. It is basically a 2-liner.
Sorry, it was untested and made in a bit of a hurry. A better solution 
would be to change it to read:

+? # Always add the java header dir
+? $1_SRC_HEADER_FLAGS += $$(addprefix -I, $$(call GetJavaHeaderDir, 
$$(MODULE)))

(the += will append to the existing variable, instead of replacing it).

/Magnus

>
> Cheers
>
> Fridrich
>
> On 15/06/18 13:10, Magnus Ihse Bursie wrote:
>> Here's a better patch. Please try and see if it solves your problems.
>> Unfortunately, I'm leaving on vacation for today and will be gone most
>> of the summer, so I can't help sponsor this patch. But if it works, I'm
>> sure someone else can take over it.
>>
>> If it does not work, the original patch should at the very least be
>> changed so that EXTRA_HEADER_DIRS gets an additional "$(call
>> GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
>> hard to eradicate from the CFLAGS).



From magnus.ihse.bursie at oracle.com  Fri Jun 15 20:16:54 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 15 Jun 2018 22:16:54 +0200
Subject: build fail
In-Reply-To: <CAFfAmy_dWhs03ZYxKi7ARcvJGHF8He-8o2EX=nVR7WU23LG4mg@mail.gmail.com>
References: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>
 <481dc7b8-3c81-0102-473e-b32e1991afe7@oracle.com>
 <CAFfAmy88fDUoe16YqOG0FtS92fSCf30u4xj0c2PL3_DJ_wh54g@mail.gmail.com>
 <CAFfAmy_dWhs03ZYxKi7ARcvJGHF8He-8o2EX=nVR7WU23LG4mg@mail.gmail.com>
Message-ID: <6628532d-be7a-350e-5d60-1c77983f9ca0@oracle.com>



On 2018-06-15 21:18, Sebastian Demian wrote:
> + build-dev
>
> On Fri, Jun 15, 2018 at 2:17 PM Sebastian Demian <2020sebastian at gmail.com>
> wrote:
>
>> Thanks for the reply Erik.
>>
>> running with --disable-warnings-as-errors helped.
>>
>> I also ran make dist-clean before building again.
>>
>> The build failed at a later stage now.
>>
>>
>>
>> Here is the new output:
>>
>> Note: Recompile with -Xlint:removal for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> */Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
>> ordered comparison between pointer and zero ('address' (aka 'unsigned char
>> *') and 'int')*
>> *  if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.*
>> *      ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~*
>> 1 error generated.
>> make[3]: ***
>> [/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/lcm.o]
>> Error 1

Apparently clang believe this is an error, and not just a warning, so 
this is a source code issue, and not a build issue per se.

If this only happens in panama, you need to raise it with the Panama 
developers (cc:ed). If you can also reproduce it on the main jdk/jdk 
repo, then you can discuss it on hotspot-dev at oopenjdk.java.net.

/Magnus

>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [hotspot-server-libs] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>>
>> ERROR: Build failed for target 'all' in configuration
>> 'macosx-x86_64-normal-server-release' (exit code 2)
>> Stopping sjavac server
>>
>> === Output from failing command(s) repeated here ===
>> * For target hotspot_variant-server_libjvm_objs_lcm.o:
>> /Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
>> ordered comparison between pointer and zero ('address' (aka 'unsigned char
>> *') and 'int')
>>    if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.
>>        ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
>> 1 error generated.
>>
>> * All command lines available in
>> /Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
>> === End of repeated output ===
>>
>> No indication of failed target found.
>> Hint: Try searching the build log for '] Error'.
>> Hint: See common/doc/building.html#troubleshooting for assistance.
>>
>> make[1]: *** [main] Error 2
>> make: *** [all] Error 2
>>
>>
>>
>> Thank you,
>> Sebastian.
>>
>>
>>
>> On Fri, Jun 15, 2018 at 12:03 PM Erik Joelsson <erik.joelsson at oracle.com>
>> wrote:
>>
>>> Hello Sebastian,
>>>
>>> Please try running configure with --disable-warnings-as-errors.
>>>
>>> When using compiler versions (or OS versions) other than the ones listed
>>> in doc/building.md it's common to have warnings triggered and we run
>>> with warnings treated as errors by default.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-06-11 12:49, Sebastian Demian wrote:
>>>> Hello,
>>>>
>>>> I am trying to setup project panama on my local mac, and I am not able
>>> to
>>>> build the project.
>>>>
>>>> Configuration summary:
>>>> * Debug level:    release
>>>> * HS debug level: product
>>>> * JDK variant:    normal
>>>> * JVM variants:   server
>>>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>>>> * Version string: 9-internal+0-adhoc.sd.panama (9-internal)
>>>>
>>>> Tools summary:
>>>> * Boot JDK:       java version "1.8.0_171" Java(TM) SE Runtime
>>> Environment
>>>> (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
>>> 25.171-b11,
>>>> mixed mode)  (at
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
>>>> * Toolchain:      clang (clang/LLVM)
>>>> * C Compiler:     Version 9.1.0 (at /usr/bin/clang)
>>>> * C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)
>>>>
>>>> Build performance summary:
>>>> * Cores to use:   4
>>>> * Memory limit:   16384 MB
>>>>
>>>>
>>>>
>>>>
>>>> I have attached the full log output from running make. I have read the
>>>> building.html and troubleshooting section and did not find anything
>>>> relevant to this error:
>>>>
>>>>
>>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
>>>> error: macro expansion producing 'defined' has undefined behavior
>>>> [-Werror,-Wexpansion-to-defined]
>>>> #if HEAP_REGION_SET_FORCE_VERIFY
>>>>       ^
>>>>
>>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
>>>> note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>>>> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>>>>                                        ^
>>>> In file included from
>>>>
>>> /Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>>>> In file included from
>>>>
>>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>>>> In file included from
>>>>
>>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
>>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
>>>> error: macro expansion producing 'defined' has undefined behavior
>>>> [-Werror,-Wexpansion-to-defined]
>>>> #if HEAP_REGION_SET_FORCE_VERIFY
>>>>       ^
>>>>
>>>>
>>>> Any help would be appreciated.
>>>>
>>>> Thanks,
>>>> Sebastian.
>>>



From martinrb at google.com  Fri Jun 15 22:10:44 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 15 Jun 2018 15:10:44 -0700
Subject: build fail
In-Reply-To: <6628532d-be7a-350e-5d60-1c77983f9ca0@oracle.com>
References: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>
 <481dc7b8-3c81-0102-473e-b32e1991afe7@oracle.com>
 <CAFfAmy88fDUoe16YqOG0FtS92fSCf30u4xj0c2PL3_DJ_wh54g@mail.gmail.com>
 <CAFfAmy_dWhs03ZYxKi7ARcvJGHF8He-8o2EX=nVR7WU23LG4mg@mail.gmail.com>
 <6628532d-be7a-350e-5d60-1c77983f9ca0@oracle.com>
Message-ID: <CA+kOe0-NBZKtzek2LNxAbNKqpez4iScaftKoDQxSkUT=WQ9FEg@mail.gmail.com>

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


From 2020sebastian at gmail.com  Fri Jun 15 22:17:37 2018
From: 2020sebastian at gmail.com (Sebastian Demian)
Date: Fri, 15 Jun 2018 17:17:37 -0500
Subject: build fail
In-Reply-To: <6628532d-be7a-350e-5d60-1c77983f9ca0@oracle.com>
References: <CAFfAmy-zFAm6ocpW_rk5tqBrC+Rk9LoEci44gjXC=CTyRTn1RA@mail.gmail.com>
 <481dc7b8-3c81-0102-473e-b32e1991afe7@oracle.com>
 <CAFfAmy88fDUoe16YqOG0FtS92fSCf30u4xj0c2PL3_DJ_wh54g@mail.gmail.com>
 <CAFfAmy_dWhs03ZYxKi7ARcvJGHF8He-8o2EX=nVR7WU23LG4mg@mail.gmail.com>
 <6628532d-be7a-350e-5d60-1c77983f9ca0@oracle.com>
Message-ID: <CAFfAmy9FRcd7cNvjj24fsfso0FPLZ9KOin=qK__bQyda67YY_Q@mail.gmail.com>

I switched from panama/panama to panama/dev instead and was able to build
it successfully.

Thank you for your help,
Sebastian.

On Fri, Jun 15, 2018 at 3:16 PM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

>
>
> On 2018-06-15 21:18, Sebastian Demian wrote:
> > + build-dev
> >
> > On Fri, Jun 15, 2018 at 2:17 PM Sebastian Demian <
> 2020sebastian at gmail.com>
> > wrote:
> >
> >> Thanks for the reply Erik.
> >>
> >> running with --disable-warnings-as-errors helped.
> >>
> >> I also ran make dist-clean before building again.
> >>
> >> The build failed at a later stage now.
> >>
> >>
> >>
> >> Here is the new output:
> >>
> >> Note: Recompile with -Xlint:removal for details.
> >> Note: Some input files use unchecked or unsafe operations.
> >> Note: Recompile with -Xlint:unchecked for details.
> >> */Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35:
> error:
> >> ordered comparison between pointer and zero ('address' (aka 'unsigned
> char
> >> *') and 'int')*
> >> *  if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.*
> >> *      ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~*
> >> 1 error generated.
> >> make[3]: ***
> >>
> [/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/lcm.o]
> >> Error 1
>
> Apparently clang believe this is an error, and not just a warning, so
> this is a source code issue, and not a build issue per se.
>
> If this only happens in panama, you need to raise it with the Panama
> developers (cc:ed). If you can also reproduce it on the main jdk/jdk
> repo, then you can discuss it on hotspot-dev at oopenjdk.java.net.
>
> /Magnus
>
> >> make[3]: *** Waiting for unfinished jobs....
> >> make[2]: *** [hotspot-server-libs] Error 2
> >> make[2]: *** Waiting for unfinished jobs....
> >>
> >> ERROR: Build failed for target 'all' in configuration
> >> 'macosx-x86_64-normal-server-release' (exit code 2)
> >> Stopping sjavac server
> >>
> >> === Output from failing command(s) repeated here ===
> >> * For target hotspot_variant-server_libjvm_objs_lcm.o:
> >> /Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35:
> error:
> >> ordered comparison between pointer and zero ('address' (aka 'unsigned
> char
> >> *') and 'int')
> >>    if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.
> >>        ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
> >> 1 error generated.
> >>
> >> * All command lines available in
> >>
> /Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
> >> === End of repeated output ===
> >>
> >> No indication of failed target found.
> >> Hint: Try searching the build log for '] Error'.
> >> Hint: See common/doc/building.html#troubleshooting for assistance.
> >>
> >> make[1]: *** [main] Error 2
> >> make: *** [all] Error 2
> >>
> >>
> >>
> >> Thank you,
> >> Sebastian.
> >>
> >>
> >>
> >> On Fri, Jun 15, 2018 at 12:03 PM Erik Joelsson <
> erik.joelsson at oracle.com>
> >> wrote:
> >>
> >>> Hello Sebastian,
> >>>
> >>> Please try running configure with --disable-warnings-as-errors.
> >>>
> >>> When using compiler versions (or OS versions) other than the ones
> listed
> >>> in doc/building.md it's common to have warnings triggered and we run
> >>> with warnings treated as errors by default.
> >>>
> >>> /Erik
> >>>
> >>>
> >>> On 2018-06-11 12:49, Sebastian Demian wrote:
> >>>> Hello,
> >>>>
> >>>> I am trying to setup project panama on my local mac, and I am not able
> >>> to
> >>>> build the project.
> >>>>
> >>>> Configuration summary:
> >>>> * Debug level:    release
> >>>> * HS debug level: product
> >>>> * JDK variant:    normal
> >>>> * JVM variants:   server
> >>>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length:
> 64
> >>>> * Version string: 9-internal+0-adhoc.sd.panama (9-internal)
> >>>>
> >>>> Tools summary:
> >>>> * Boot JDK:       java version "1.8.0_171" Java(TM) SE Runtime
> >>> Environment
> >>>> (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
> >>> 25.171-b11,
> >>>> mixed mode)  (at
> >>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
> >>>> * Toolchain:      clang (clang/LLVM)
> >>>> * C Compiler:     Version 9.1.0 (at /usr/bin/clang)
> >>>> * C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)
> >>>>
> >>>> Build performance summary:
> >>>> * Cores to use:   4
> >>>> * Memory limit:   16384 MB
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> I have attached the full log output from running make. I have read the
> >>>> building.html and troubleshooting section and did not find anything
> >>>> relevant to this error:
> >>>>
> >>>>
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
> >>>> error: macro expansion producing 'defined' has undefined behavior
> >>>> [-Werror,-Wexpansion-to-defined]
> >>>> #if HEAP_REGION_SET_FORCE_VERIFY
> >>>>       ^
> >>>>
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
> >>>> note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
> >>>> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
> >>>>                                        ^
> >>>> In file included from
> >>>>
> >>>
> /Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
> >>>> In file included from
> >>>>
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
> >>>> In file included from
> >>>>
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
> >>>> error: macro expansion producing 'defined' has undefined behavior
> >>>> [-Werror,-Wexpansion-to-defined]
> >>>> #if HEAP_REGION_SET_FORCE_VERIFY
> >>>>       ^
> >>>>
> >>>>
> >>>> Any help would be appreciated.
> >>>>
> >>>> Thanks,
> >>>> Sebastian.
> >>>
>
>


From javalists at cbfiddle.com  Sat Jun 16 05:35:01 2018
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 15 Jun 2018 22:35:01 -0700
Subject: build failure on macOS: Bus error in BUILD_JIGSAW_TOOLS
Message-ID: <AB4BA20B-790E-4A07-B999-9C16F3F2FF59@cbfiddle.com>

I have just started getting a reliable build failure on macOS, even with a new clone of the client repo.

I?m not sure what might have changed, other than using a new SDK (from macOS 10.14) and Xcode 10.

The key lines are:

Compiling 4 files for BUILD_JIGSAW_TOOLS
make[3]: *** [/Volumes/A/JDK/client2/build/macosx-x86_64-normal-server-release/jdk/_packages_attribute.done] Bus error: 10
make[2]: *** [exploded-image-optimize] Error 2



From javalists at cbfiddle.com  Sun Jun 17 04:50:25 2018
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sat, 16 Jun 2018 21:50:25 -0700
Subject: build failure on macOS: Bus error in BUILD_JIGSAW_TOOLS
Message-ID: <96223F61-4837-47B7-8A60-2E6053227863@cbfiddle.com>

I figured out how to configure to use Xcode 9 and the build problem went away.

  Alan



From david.holmes at oracle.com  Mon Jun 18 06:17:04 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 18 Jun 2018 16:17:04 +1000
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
Message-ID: <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>

Hi Volker,

src/hotspot/share/runtime/globals.hpp

This change should not be needed! We do minimal VM builds without CDS 
and we don't have to touch the UseSharedSpaces defaults (unless recent 
change have broken this - in which case that needs to be addressed in 
its own right!)

src/hotspot/share/classfile/javaClasses.cpp

AFAICS you should be using INCLUDE_CDS in the ifdefs not 
INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this 
should be needed as we have not needed it before. As Thomas notes we have:

./hotspot/share/memory/metaspaceShared.hpp:  static bool 
is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
./hotspot/share/classfile/stringTable.hpp:  static oop 
create_archived_string(oop s, Thread* THREAD) 
NOT_CDS_JAVA_HEAP_RETURN_(NULL);

so these methods should be defined when CDS is not available.

??

Thanks,
David
-----




On 15/06/2018 12:26 AM, Volker Simonis wrote:
> Hi,
> 
> can I please have a review for the following fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
> https://bugs.openjdk.java.net/browse/JDK-8204965
> 
> CDS does currently not work on AIX because of the way how we
> reserve/commit memory on AIX. The problem is that we're using a
> combination of shmat/mmap depending on the page size and the size of
> the memory chunk to reserve. This makes it impossible to reliably
> reserve the memory for the CDS archive and later on map the various
> parts of the archive into these regions.
> 
> In order to fix this we would have to completely rework the memory
> reserve/commit/uncommit logic on AIX which is currently out of our
> scope because of resource limitations.
> 
> Unfortunately, I could not simply disable CDS in the configure step
> because some of the shared code apparently relies on parts of the CDS
> code which gets excluded from the build when CDS is disabled. So I
> also fixed the offending parts in hotspot and cleaned up the configure
> logic for CDS.
> 
> Thank you and best regards,
> Volker
> 
> PS: I did run the job through the submit forest
> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
> weren't really useful because they mention build failures on linux-x64
> which I can't reproduce locally.
> 


From volker.simonis at gmail.com  Mon Jun 18 16:04:58 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 18 Jun 2018 18:04:58 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
Message-ID: <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>

On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Volker,
>
> src/hotspot/share/runtime/globals.hpp
>
> This change should not be needed! We do minimal VM builds without CDS and we
> don't have to touch the UseSharedSpaces defaults (unless recent change have
> broken this - in which case that needs to be addressed in its own right!)
>

Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
because UseSharedSpaces is reseted later on at the end of
Arguments::parse(). I just thought it would be cleaner to disable it
statically, if the VM doesn't support it. But anyway I don't really
mind and I've reverted that change in globals.hpp.

> src/hotspot/share/classfile/javaClasses.cpp
>
> AFAICS you should be using INCLUDE_CDS in the ifdefs not
> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this should
> be needed as we have not needed it before. As Thomas notes we have:
>
> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
> ./hotspot/share/classfile/stringTable.hpp:  static oop
> create_archived_string(oop s, Thread* THREAD)
> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>
> so these methods should be defined when CDS is not available.
>

Thomas and you are right. Must have been a mis-configuration on AIX
where I saw undefined symbols at link time. I've removed the ifdefs
from javaClasses.cpp now.

Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
into CDS_ONLY macros as suggested by Jiangli because the really only
make sense for a CDS-enabled VM.

Here's the new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/

Please let me know if you think there's still something missing.

Regards,
Volker


> ??
>
> Thanks,
> David
> -----
>
>
>
>
>
> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can I please have a review for the following fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>
>> CDS does currently not work on AIX because of the way how we
>> reserve/commit memory on AIX. The problem is that we're using a
>> combination of shmat/mmap depending on the page size and the size of
>> the memory chunk to reserve. This makes it impossible to reliably
>> reserve the memory for the CDS archive and later on map the various
>> parts of the archive into these regions.
>>
>> In order to fix this we would have to completely rework the memory
>> reserve/commit/uncommit logic on AIX which is currently out of our
>> scope because of resource limitations.
>>
>> Unfortunately, I could not simply disable CDS in the configure step
>> because some of the shared code apparently relies on parts of the CDS
>> code which gets excluded from the build when CDS is disabled. So I
>> also fixed the offending parts in hotspot and cleaned up the configure
>> logic for CDS.
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: I did run the job through the submit forest
>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>> weren't really useful because they mention build failures on linux-x64
>> which I can't reproduce locally.
>>
>


From thomas.stuefe at gmail.com  Mon Jun 18 16:14:24 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 18 Jun 2018 18:14:24 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
Message-ID: <CAA-vtUxqjJJ9CM-7S3Dp3yWFNJ549_9_G8UUTnnrrDAvu+j9pg@mail.gmail.com>

Looks good to me, Volker. Thank you for fixing the tests.

..Thomas

On Mon, Jun 18, 2018 at 6:04 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>>
>> src/hotspot/share/runtime/globals.hpp
>>
>> This change should not be needed! We do minimal VM builds without CDS and we
>> don't have to touch the UseSharedSpaces defaults (unless recent change have
>> broken this - in which case that needs to be addressed in its own right!)
>>
>
> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
> because UseSharedSpaces is reseted later on at the end of
> Arguments::parse(). I just thought it would be cleaner to disable it
> statically, if the VM doesn't support it. But anyway I don't really
> mind and I've reverted that change in globals.hpp.
>
>> src/hotspot/share/classfile/javaClasses.cpp
>>
>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this should
>> be needed as we have not needed it before. As Thomas notes we have:
>>
>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>> create_archived_string(oop s, Thread* THREAD)
>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>>
>> so these methods should be defined when CDS is not available.
>>
>
> Thomas and you are right. Must have been a mis-configuration on AIX
> where I saw undefined symbols at link time. I've removed the ifdefs
> from javaClasses.cpp now.
>
> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
> into CDS_ONLY macros as suggested by Jiangli because the really only
> make sense for a CDS-enabled VM.
>
> Here's the new webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
>
> Please let me know if you think there's still something missing.
>
> Regards,
> Volker
>
>
>> ??
>>
>> Thanks,
>> David
>> -----
>>
>>
>>
>>
>>
>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> can I please have a review for the following fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>
>>> CDS does currently not work on AIX because of the way how we
>>> reserve/commit memory on AIX. The problem is that we're using a
>>> combination of shmat/mmap depending on the page size and the size of
>>> the memory chunk to reserve. This makes it impossible to reliably
>>> reserve the memory for the CDS archive and later on map the various
>>> parts of the archive into these regions.
>>>
>>> In order to fix this we would have to completely rework the memory
>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>> scope because of resource limitations.
>>>
>>> Unfortunately, I could not simply disable CDS in the configure step
>>> because some of the shared code apparently relies on parts of the CDS
>>> code which gets excluded from the build when CDS is disabled. So I
>>> also fixed the offending parts in hotspot and cleaned up the configure
>>> logic for CDS.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: I did run the job through the submit forest
>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>> weren't really useful because they mention build failures on linux-x64
>>> which I can't reproduce locally.
>>>
>>


From jiangli.zhou at oracle.com  Mon Jun 18 16:41:59 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Mon, 18 Jun 2018 09:41:59 -0700
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
Message-ID: <5C9B2902-9174-4477-9434-D4BA6514549B@oracle.com>

Hi Volker,

Thanks for adding CDS_ONLY to all FileMapInfo fields. It looks cleaner also with Thomas and David?s suggestion to remove the macros in globals.hpp and javaClasses.cpp.

Thanks!
Jiangli

> On Jun 18, 2018, at 9:04 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>> 
>> src/hotspot/share/runtime/globals.hpp
>> 
>> This change should not be needed! We do minimal VM builds without CDS and we
>> don't have to touch the UseSharedSpaces defaults (unless recent change have
>> broken this - in which case that needs to be addressed in its own right!)
>> 
> 
> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
> because UseSharedSpaces is reseted later on at the end of
> Arguments::parse(). I just thought it would be cleaner to disable it
> statically, if the VM doesn't support it. But anyway I don't really
> mind and I've reverted that change in globals.hpp.
> 
>> src/hotspot/share/classfile/javaClasses.cpp
>> 
>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this should
>> be needed as we have not needed it before. As Thomas notes we have:
>> 
>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>> create_archived_string(oop s, Thread* THREAD)
>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>> 
>> so these methods should be defined when CDS is not available.
>> 
> 
> Thomas and you are right. Must have been a mis-configuration on AIX
> where I saw undefined symbols at link time. I've removed the ifdefs
> from javaClasses.cpp now.
> 
> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
> into CDS_ONLY macros as suggested by Jiangli because the really only
> make sense for a CDS-enabled VM.
> 
> Here's the new webrev:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
> 
> Please let me know if you think there's still something missing.
> 
> Regards,
> Volker
> 
> 
>> ??
>> 
>> Thanks,
>> David
>> -----
>> 
>> 
>> 
>> 
>> 
>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>> 
>>> Hi,
>>> 
>>> can I please have a review for the following fix:
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>> 
>>> CDS does currently not work on AIX because of the way how we
>>> reserve/commit memory on AIX. The problem is that we're using a
>>> combination of shmat/mmap depending on the page size and the size of
>>> the memory chunk to reserve. This makes it impossible to reliably
>>> reserve the memory for the CDS archive and later on map the various
>>> parts of the archive into these regions.
>>> 
>>> In order to fix this we would have to completely rework the memory
>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>> scope because of resource limitations.
>>> 
>>> Unfortunately, I could not simply disable CDS in the configure step
>>> because some of the shared code apparently relies on parts of the CDS
>>> code which gets excluded from the build when CDS is disabled. So I
>>> also fixed the offending parts in hotspot and cleaned up the configure
>>> logic for CDS.
>>> 
>>> Thank you and best regards,
>>> Volker
>>> 
>>> PS: I did run the job through the submit forest
>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>> weren't really useful because they mention build failures on linux-x64
>>> which I can't reproduce locally.
>>> 
>> 



From patrick at reini.net  Mon Jun 18 19:36:20 2018
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 18 Jun 2018 21:36:20 +0200
Subject: JDK Build on Fedora 28
Message-ID: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>

Hi everybody,

Can anyone give me some advice in what I should do in order to build the OpenJDK on a Fedora 28?


-Patrick


At the moment I get those errors:

Compiling 5 files for jdk.internal.vm.compiler.management
/home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp: In static member function ?static int os::create_file_for_heap(const char*)?:
/home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:172:16: error: ?char* strncpy(char*, const char*, size_t)? specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
   (void)strncpy(fullname, dir, strlen(dir)+1);
         ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:172:38: note: length computed here
   (void)strncpy(fullname, dir, strlen(dir)+1);
                                ~~~~~~^~~~~
/home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:173:16: error: ?char* strncat(char*, const char*, size_t)? specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
   (void)strncat(fullname, name_template, strlen(name_template));
         ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
gmake[3]: *** [lib/CompileJvm.gmk:151: /home/pr/sources/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/os_posix.o] Error 1
gmake[3]: *** Waiting for unfinished jobs....
gmake[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2

ERROR: Build failed for target 'default (exploded-image)' in configuration 'linux-x86_64-normal-server-release' (exit code 2)
Stopping sjavac server



From glaubitz at physik.fu-berlin.de  Mon Jun 18 20:02:52 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 18 Jun 2018 22:02:52 +0200
Subject: JDK Build on Fedora 28
In-Reply-To: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>
References: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>
Message-ID: <59BE0B6B-DBE0-4B4C-90EC-50AD32F20410@physik.fu-berlin.de>

Hi Patrick!

Try building with ??disable-warnings-as-errors?, that should fix the problem.

Adrian

PS: Replying from mobile, excuse my brevity.

> On Jun 18, 2018, at 9:36 PM, Patrick Reinhart <patrick at reini.net> wrote:
> 
> Hi everybody,
> 
> Can anyone give me some advice in what I should do in order to build the OpenJDK on a Fedora 28?
> 
> 
> -Patrick
> 
> 
> At the moment I get those errors:
> 
> Compiling 5 files for jdk.internal.vm.compiler.management
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp: In static member function ?static int os::create_file_for_heap(const char*)?:
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:172:16: error: ?char* strncpy(char*, const char*, size_t)? specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
>   (void)strncpy(fullname, dir, strlen(dir)+1);
>         ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:172:38: note: length computed here
>   (void)strncpy(fullname, dir, strlen(dir)+1);
>                                ~~~~~~^~~~~
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:173:16: error: ?char* strncat(char*, const char*, size_t)? specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
>   (void)strncat(fullname, name_template, strlen(name_template));
>         ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1plus: all warnings being treated as errors
> gmake[3]: *** [lib/CompileJvm.gmk:151: /home/pr/sources/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/os_posix.o] Error 1
> gmake[3]: *** Waiting for unfinished jobs....
> gmake[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2
> 
> ERROR: Build failed for target 'default (exploded-image)' in configuration 'linux-x86_64-normal-server-release' (exit code 2)
> Stopping sjavac server



From patrick at reini.net  Mon Jun 18 20:13:29 2018
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 18 Jun 2018 22:13:29 +0200
Subject: JDK Build on Fedora 28
In-Reply-To: <59BE0B6B-DBE0-4B4C-90EC-50AD32F20410@physik.fu-berlin.de>
References: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>
 <59BE0B6B-DBE0-4B4C-90EC-50AD32F20410@physik.fu-berlin.de>
Message-ID: <B484FF05-A502-4F1F-87BD-357A5ED57183@reini.net>

Hi Adrian,

Thanks for the tip, worked flawlessly :-)

-Patrick


> Am 18.06.2018 um 22:02 schrieb John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>:
> 
> Hi Patrick!
> 
> Try building with ??disable-warnings-as-errors?, that should fix the problem.
> 
> Adrian
> 
> PS: Replying from mobile, excuse my brevity.
> 
>> On Jun 18, 2018, at 9:36 PM, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>> Hi everybody,
>> 
>> Can anyone give me some advice in what I should do in order to build the OpenJDK on a Fedora 28?
>> 
>> 
>> -Patrick



From erik.joelsson at oracle.com  Mon Jun 18 20:34:24 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 18 Jun 2018 13:34:24 -0700
Subject: RFR: JDK-8205183: Warning about using VS2017 should be removed
Message-ID: <435f2e08-d573-8bff-e15a-973265e2744e@oracle.com>

When using VS2017, configure prints a warning about the toolchain being 
unsupported. This needs to change now that this is the main toolchain 
version for OpenJDK on Windows (at least for Oracle).

This patch removes the warning for VS2017 and adds it back for all other 
versions of Visual Studio. I've made it possible to toggle this 
individually for each VS version so if someone wants to claim support 
for another VS version, they can flip it back.

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

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

/Erik



From erik.joelsson at oracle.com  Mon Jun 18 20:53:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 18 Jun 2018 13:53:33 -0700
Subject: RFR: JDK-8205055: Fix compilation optimization errors with new
 Solaris toolchain
In-Reply-To: <9dd27bd6-36ab-7616-8069-f7a9dbdc080d@oracle.com>
References: <cdc7ea23-cd77-e51c-5304-becebcbec503@oracle.com>
 <9dd27bd6-36ab-7616-8069-f7a9dbdc080d@oracle.com>
Message-ID: <1dc6ac3f-7af4-d66c-7276-38567708b18c@oracle.com>

Hello,

On 2018-06-15 05:44, Magnus Ihse Bursie wrote:
> On 2018-06-15 01:26, gary.adams at oracle.com wrote:
>> Locally tested the fix below and via mach5 jobs.
>> The ~50 failed tests all completed successfully.
>> It'd be good for Erik to repeat his full testing with
>> this patch included in case it blocked other issues
>> from being observed.
>>
>> This fix can be integrated after the sync from jdk/client.
>>
>> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8205055
>>
>> Proposed fix:
>>
>> diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk 
>> b/make/hotspot/lib/JvmOverrideFiles.gmk
>> --- a/make/hotspot/lib/JvmOverrideFiles.gmk
>> +++ b/make/hotspot/lib/JvmOverrideFiles.gmk
>> @@ -74,6 +74,8 @@
>>
>> ?else ifeq ($(OPENJDK_TARGET_OS), solaris)
>> ???ifneq ($(DEBUG_LEVEL), slowdebug)
>> + # dev studio 12.6 workaround
>> + BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW
>
> The if should test
> ifeq ($(TOOLCHAIN_TYPE), solstudio)
> since this is a compiler issue, not an OS issue.
>
> Ideally, it should also test if using version 12.6, but unfortunately 
> there's currently no elegant way of expressing that in the makefiles, 
> so I'm OK with the workaround of just having a comment. I assume, from 
> the name and a quick glance at the file, that the contents makes it 
> unlikely that a lowevered optimization level wouldprovoke a 
> performance regression in pre-12.6 solstudio compilations.
>
> Still, it would be nice if you are able to drill down the issue to 
> figure out exactly why a higher optimization level causes this file to 
> be incorrectly compiled. It might be code in hotspot with undefined 
> behavior, or it might be bugs in solstudio. In any case, it should be 
> addressed. As an initial fix to allow compilation to proceed, this is 
> fine, though.
>
I have run more testing using this patch and it does look like it works 
pretty well with just this change. Nothing sticks out.

I agree with Magnus that it needs a TOOLCHAIN_TYPE check.

Will you file a followup for investigating what actually goes wrong?

/Erik


From philip.race at oracle.com  Mon Jun 18 20:58:02 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 18 Jun 2018 13:58:02 -0700
Subject: RFR: JDK-8205183: Warning about using VS2017 should be removed
In-Reply-To: <435f2e08-d573-8bff-e15a-973265e2744e@oracle.com>
References: <435f2e08-d573-8bff-e15a-973265e2744e@oracle.com>
Message-ID: <d5d7dc2e-b2ff-92ad-44b6-3e7709fa43a8@oracle.com>

+1

-phil.

On 06/18/2018 01:34 PM, Erik Joelsson wrote:
> When using VS2017, configure prints a warning about the toolchain 
> being unsupported. This needs to change now that this is the main 
> toolchain version for OpenJDK on Windows (at least for Oracle).
>
> This patch removes the warning for VS2017 and adds it back for all 
> other versions of Visual Studio. I've made it possible to toggle this 
> individually for each VS version so if someone wants to claim support 
> for another VS version, they can flip it back.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205183
>
> Webrev: http://cr.openjdk.java.net/~erikj/8205183/webrev.01/
>
> /Erik
>



From tim.bell at oracle.com  Mon Jun 18 22:39:38 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 18 Jun 2018 15:39:38 -0700
Subject: RFR: JDK-8205183: Warning about using VS2017 should be removed
In-Reply-To: <d5d7dc2e-b2ff-92ad-44b6-3e7709fa43a8@oracle.com>
References: <435f2e08-d573-8bff-e15a-973265e2744e@oracle.com>
 <d5d7dc2e-b2ff-92ad-44b6-3e7709fa43a8@oracle.com>
Message-ID: <5B2834AA.5090800@oracle.com>

Erik-

Looks good to me as well.

/Tim

On 06/18/18 13:58, Phil Race wrote:
> +1
>
> -phil.
>
> On 06/18/2018 01:34 PM, Erik Joelsson wrote:
>> When using VS2017, configure prints a warning about the toolchain
>> being unsupported. This needs to change now that this is the main
>> toolchain version for OpenJDK on Windows (at least for Oracle).
>>
>> This patch removes the warning for VS2017 and adds it back for all
>> other versions of Visual Studio. I've made it possible to toggle this
>> individually for each VS version so if someone wants to claim support
>> for another VS version, they can flip it back.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205183
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8205183/webrev.01/
>>
>> /Erik
>>
>



From martinrb at google.com  Tue Jun 19 00:36:46 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Jun 2018 17:36:46 -0700
Subject: RFR: 8205197: Never default to using libc++ on Linux
Message-ID: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>

8205197: Never default to using libc++ on Linux
http://cr.openjdk.java.net/~martin/webrevs/jdk/stlib-default/
https://bugs.openjdk.java.net/browse/JDK-8205197


From tim.bell at oracle.com  Tue Jun 19 01:29:21 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 18 Jun 2018 18:29:21 -0700
Subject: RFR: 8205197: Never default to using libc++ on Linux
In-Reply-To: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>
References: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>
Message-ID: <5B285C71.9050407@oracle.com>

Martin:

> 8205197: Never default to using libc++ on Linux
> http://cr.openjdk.java.net/~martin/webrevs/jdk/stlib-default/
> https://bugs.openjdk.java.net/browse/JDK-8205197

Looks good.

/Tim




From david.holmes at oracle.com  Tue Jun 19 02:30:48 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jun 2018 12:30:48 +1000
Subject: JDK Build on Fedora 28
In-Reply-To: <B484FF05-A502-4F1F-87BD-357A5ED57183@reini.net>
References: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>
 <59BE0B6B-DBE0-4B4C-90EC-50AD32F20410@physik.fu-berlin.de>
 <B484FF05-A502-4F1F-87BD-357A5ED57183@reini.net>
Message-ID: <ae480d1b-6836-a897-22d4-9af3ce135afa@oracle.com>

I've filed:

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

for the underlying issue. Hotspot folk need to check if the warnings are 
legitmate or not. If not then we may need to disable this warning in the 
build.

David

On 19/06/2018 6:13 AM, Patrick Reinhart wrote:
> Hi Adrian,
> 
> Thanks for the tip, worked flawlessly :-)
> 
> -Patrick
> 
> 
>> Am 18.06.2018 um 22:02 schrieb John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>:
>>
>> Hi Patrick!
>>
>> Try building with ??disable-warnings-as-errors?, that should fix the problem.
>>
>> Adrian
>>
>> PS: Replying from mobile, excuse my brevity.
>>
>>> On Jun 18, 2018, at 9:36 PM, Patrick Reinhart <patrick at reini.net> wrote:
>>>
>>> Hi everybody,
>>>
>>> Can anyone give me some advice in what I should do in order to build the OpenJDK on a Fedora 28?
>>>
>>>
>>> -Patrick
> 


From david.holmes at oracle.com  Tue Jun 19 04:54:25 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jun 2018 14:54:25 +1000
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
Message-ID: <67efe9b2-bd7a-e23a-74d6-786cbc135d16@oracle.com>

Hi Volker,

v3 looks much cleaner - thanks.

But AFAICS the change to jvmtiEnv.cpp is also not needed. 
ClassLoaderExt::append_boot_classpath exists regardless of INCLUDE_CDS 
but operates differently (just calling 
ClassLoader::add_to_boot_append_entries).

Thanks,
David

On 19/06/2018 2:04 AM, Volker Simonis wrote:
> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>>
>> src/hotspot/share/runtime/globals.hpp
>>
>> This change should not be needed! We do minimal VM builds without CDS and we
>> don't have to touch the UseSharedSpaces defaults (unless recent change have
>> broken this - in which case that needs to be addressed in its own right!)
>>
> 
> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
> because UseSharedSpaces is reseted later on at the end of
> Arguments::parse(). I just thought it would be cleaner to disable it
> statically, if the VM doesn't support it. But anyway I don't really
> mind and I've reverted that change in globals.hpp.
> 
>> src/hotspot/share/classfile/javaClasses.cpp
>>
>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this should
>> be needed as we have not needed it before. As Thomas notes we have:
>>
>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>> create_archived_string(oop s, Thread* THREAD)
>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>>
>> so these methods should be defined when CDS is not available.
>>
> 
> Thomas and you are right. Must have been a mis-configuration on AIX
> where I saw undefined symbols at link time. I've removed the ifdefs
> from javaClasses.cpp now.
> 
> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
> into CDS_ONLY macros as suggested by Jiangli because the really only
> make sense for a CDS-enabled VM.
> 
> Here's the new webrev:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
> 
> Please let me know if you think there's still something missing.
> 
> Regards,
> Volker
> 
> 
>> ??
>>
>> Thanks,
>> David
>> -----
>>
>>
>>
>>
>>
>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> can I please have a review for the following fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>
>>> CDS does currently not work on AIX because of the way how we
>>> reserve/commit memory on AIX. The problem is that we're using a
>>> combination of shmat/mmap depending on the page size and the size of
>>> the memory chunk to reserve. This makes it impossible to reliably
>>> reserve the memory for the CDS archive and later on map the various
>>> parts of the archive into these regions.
>>>
>>> In order to fix this we would have to completely rework the memory
>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>> scope because of resource limitations.
>>>
>>> Unfortunately, I could not simply disable CDS in the configure step
>>> because some of the shared code apparently relies on parts of the CDS
>>> code which gets excluded from the build when CDS is disabled. So I
>>> also fixed the offending parts in hotspot and cleaned up the configure
>>> logic for CDS.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: I did run the job through the submit forest
>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>> weren't really useful because they mention build failures on linux-x64
>>> which I can't reproduce locally.
>>>
>>


From volker.simonis at gmail.com  Tue Jun 19 06:50:37 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 19 Jun 2018 08:50:37 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <67efe9b2-bd7a-e23a-74d6-786cbc135d16@oracle.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
 <67efe9b2-bd7a-e23a-74d6-786cbc135d16@oracle.com>
Message-ID: <CA+3eh13ykMSQvNJ9EBjKjck_PUMPe0wkJ-5v5KCe6G_YzA068w@mail.gmail.com>

On Tue, Jun 19, 2018 at 6:54 AM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Volker,
>
> v3 looks much cleaner - thanks.
>
> But AFAICS the change to jvmtiEnv.cpp is also not needed.
> ClassLoaderExt::append_boot_classpath exists regardless of INCLUDE_CDS but
> operates differently (just calling ClassLoader::add_to_boot_append_entries).
>

That's not entirely true because the whole compilation unit (i.e.
classLoaderExt.cpp) which contains
'ClassLoaderExt::append_boot_classpath()' is excluded from the
compilation if CDS is disabled (see make/hotspot/lib/JvmFeatures.gmk).

So I can either move the whole implementation of
'ClassLoaderExt::append_boot_classpath()' into classLoaderExt.hpp in
which case things would work as you explained and my changes to
jvmtiEnv.cpp could be removed or leave the whole code and change as
is. Please let me know what you think?

Regards,
Volker

> Thanks,
> David
>
>
> On 19/06/2018 2:04 AM, Volker Simonis wrote:
>>
>> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> Hi Volker,
>>>
>>> src/hotspot/share/runtime/globals.hpp
>>>
>>> This change should not be needed! We do minimal VM builds without CDS and
>>> we
>>> don't have to touch the UseSharedSpaces defaults (unless recent change
>>> have
>>> broken this - in which case that needs to be addressed in its own right!)
>>>
>>
>> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
>> because UseSharedSpaces is reseted later on at the end of
>> Arguments::parse(). I just thought it would be cleaner to disable it
>> statically, if the VM doesn't support it. But anyway I don't really
>> mind and I've reverted that change in globals.hpp.
>>
>>> src/hotspot/share/classfile/javaClasses.cpp
>>>
>>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this
>>> should
>>> be needed as we have not needed it before. As Thomas notes we have:
>>>
>>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>>> create_archived_string(oop s, Thread* THREAD)
>>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>>>
>>> so these methods should be defined when CDS is not available.
>>>
>>
>> Thomas and you are right. Must have been a mis-configuration on AIX
>> where I saw undefined symbols at link time. I've removed the ifdefs
>> from javaClasses.cpp now.
>>
>> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
>> into CDS_ONLY macros as suggested by Jiangli because the really only
>> make sense for a CDS-enabled VM.
>>
>> Here's the new webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
>>
>> Please let me know if you think there's still something missing.
>>
>> Regards,
>> Volker
>>
>>
>>> ??
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>
>>>
>>>
>>>
>>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> can I please have a review for the following fix:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>>
>>>> CDS does currently not work on AIX because of the way how we
>>>> reserve/commit memory on AIX. The problem is that we're using a
>>>> combination of shmat/mmap depending on the page size and the size of
>>>> the memory chunk to reserve. This makes it impossible to reliably
>>>> reserve the memory for the CDS archive and later on map the various
>>>> parts of the archive into these regions.
>>>>
>>>> In order to fix this we would have to completely rework the memory
>>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>>> scope because of resource limitations.
>>>>
>>>> Unfortunately, I could not simply disable CDS in the configure step
>>>> because some of the shared code apparently relies on parts of the CDS
>>>> code which gets excluded from the build when CDS is disabled. So I
>>>> also fixed the offending parts in hotspot and cleaned up the configure
>>>> logic for CDS.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> PS: I did run the job through the submit forest
>>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>>> weren't really useful because they mention build failures on linux-x64
>>>> which I can't reproduce locally.
>>>>
>>>
>


From david.holmes at oracle.com  Tue Jun 19 07:25:44 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jun 2018 17:25:44 +1000
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh13ykMSQvNJ9EBjKjck_PUMPe0wkJ-5v5KCe6G_YzA068w@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
 <67efe9b2-bd7a-e23a-74d6-786cbc135d16@oracle.com>
 <CA+3eh13ykMSQvNJ9EBjKjck_PUMPe0wkJ-5v5KCe6G_YzA068w@mail.gmail.com>
Message-ID: <8ada6cad-09f4-cde2-69c8-561a142bc3bb@oracle.com>

Hi Volker,

On 19/06/2018 4:50 PM, Volker Simonis wrote:
> On Tue, Jun 19, 2018 at 6:54 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>>
>> v3 looks much cleaner - thanks.
>>
>> But AFAICS the change to jvmtiEnv.cpp is also not needed.
>> ClassLoaderExt::append_boot_classpath exists regardless of INCLUDE_CDS but
>> operates differently (just calling ClassLoader::add_to_boot_append_entries).
>>
> 
> That's not entirely true because the whole compilation unit (i.e.
> classLoaderExt.cpp) which contains
> 'ClassLoaderExt::append_boot_classpath()' is excluded from the
> compilation if CDS is disabled (see make/hotspot/lib/JvmFeatures.gmk).

Hmmm. There's a CDS bug there. Either classLoaderExt.cpp should not be 
excluded from a non-CDS build, or it should not contain any INCLUDE_CDS 
guards! I suspect it should not be excluded.

> So I can either move the whole implementation of
> 'ClassLoaderExt::append_boot_classpath()' into classLoaderExt.hpp in
> which case things would work as you explained and my changes to
> jvmtiEnv.cpp could be removed or leave the whole code and change as
> is. Please let me know what you think?

In the interest of moving forward you can push what you have and I will 
file a bug against CDS to sort out classLoaderExt.cpp.

Thanks,
David

> Regards,
> Volker
> 
>> Thanks,
>> David
>>
>>
>> On 19/06/2018 2:04 AM, Volker Simonis wrote:
>>>
>>> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> src/hotspot/share/runtime/globals.hpp
>>>>
>>>> This change should not be needed! We do minimal VM builds without CDS and
>>>> we
>>>> don't have to touch the UseSharedSpaces defaults (unless recent change
>>>> have
>>>> broken this - in which case that needs to be addressed in its own right!)
>>>>
>>>
>>> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
>>> because UseSharedSpaces is reseted later on at the end of
>>> Arguments::parse(). I just thought it would be cleaner to disable it
>>> statically, if the VM doesn't support it. But anyway I don't really
>>> mind and I've reverted that change in globals.hpp.
>>>
>>>> src/hotspot/share/classfile/javaClasses.cpp
>>>>
>>>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>>>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this
>>>> should
>>>> be needed as we have not needed it before. As Thomas notes we have:
>>>>
>>>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>>>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>>>> create_archived_string(oop s, Thread* THREAD)
>>>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>>>>
>>>> so these methods should be defined when CDS is not available.
>>>>
>>>
>>> Thomas and you are right. Must have been a mis-configuration on AIX
>>> where I saw undefined symbols at link time. I've removed the ifdefs
>>> from javaClasses.cpp now.
>>>
>>> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
>>> into CDS_ONLY macros as suggested by Jiangli because the really only
>>> make sense for a CDS-enabled VM.
>>>
>>> Here's the new webrev:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
>>>
>>> Please let me know if you think there's still something missing.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>>> ??
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> can I please have a review for the following fix:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>>>
>>>>> CDS does currently not work on AIX because of the way how we
>>>>> reserve/commit memory on AIX. The problem is that we're using a
>>>>> combination of shmat/mmap depending on the page size and the size of
>>>>> the memory chunk to reserve. This makes it impossible to reliably
>>>>> reserve the memory for the CDS archive and later on map the various
>>>>> parts of the archive into these regions.
>>>>>
>>>>> In order to fix this we would have to completely rework the memory
>>>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>>>> scope because of resource limitations.
>>>>>
>>>>> Unfortunately, I could not simply disable CDS in the configure step
>>>>> because some of the shared code apparently relies on parts of the CDS
>>>>> code which gets excluded from the build when CDS is disabled. So I
>>>>> also fixed the offending parts in hotspot and cleaned up the configure
>>>>> logic for CDS.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>> PS: I did run the job through the submit forest
>>>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>>>> weren't really useful because they mention build failures on linux-x64
>>>>> which I can't reproduce locally.
>>>>>
>>>>
>>


From aph at redhat.com  Tue Jun 19 09:20:19 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Jun 2018 10:20:19 +0100
Subject: JDK Build on Fedora 28
In-Reply-To: <ae480d1b-6836-a897-22d4-9af3ce135afa@oracle.com>
References: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>
 <59BE0B6B-DBE0-4B4C-90EC-50AD32F20410@physik.fu-berlin.de>
 <B484FF05-A502-4F1F-87BD-357A5ED57183@reini.net>
 <ae480d1b-6836-a897-22d4-9af3ce135afa@oracle.com>
Message-ID: <2f609954-2950-33e1-b16d-fc739d4b3aec@redhat.com>

On 06/19/2018 03:30 AM, David Holmes wrote:
> I've filed:
> 
> https://bugs.openjdk.java.net/browse/JDK-8205201
> 
> for the underlying issue. Hotspot folk need to check if the warnings are 
> legitmate or not. If not then we may need to disable this warning in the 
> build.

The warnings are legitimate: it's unnecessarily hairy code.  It could
easily be rewritten to use memcpy(), would be obviously guaranteed not
to exceed array bounds, and might even be slightly faster.  Fixing
these warnings is an opportunity to clean up some of this code.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From patrick at reini.net  Tue Jun 19 10:49:58 2018
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 19 Jun 2018 12:49:58 +0200
Subject: JDK Build on Fedora 28
In-Reply-To: <2f609954-2950-33e1-b16d-fc739d4b3aec@redhat.com>
References: <6DAEF75F-3614-4BD8-8FAB-6E3401CC225E@reini.net>
 <59BE0B6B-DBE0-4B4C-90EC-50AD32F20410@physik.fu-berlin.de>
 <B484FF05-A502-4F1F-87BD-357A5ED57183@reini.net>
 <ae480d1b-6836-a897-22d4-9af3ce135afa@oracle.com>
 <2f609954-2950-33e1-b16d-fc739d4b3aec@redhat.com>
Message-ID: <c091cb348588c1133b9e2e1488275476@reini.net>

I went thru the remaining warnings, that show up when building under gcc 
8.1.1 on Fedora 28:

/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c: 
In function ?jniFatalError?:
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:650:24: 
warning: passing argument 1 to restrict-qualified parameter aliases with 
argument 4 [-Wrestrict]
          (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
                         ^~~                          ~~~
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c: 
In function ?jniFatalError.constprop?:
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:650:48: 
warning: ?%s? directive output may be truncated writing up to 511 bytes 
into a region of size 507 [-Wformat-truncation=]
          (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
                                                 ^~   ~~~
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:650:15: 
note: ?snprintf? output between 6 and 517 bytes into a destination of 
size 512
          (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c: 
In function ?log_message_end?:
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: 
warning: ?%.3d? directive output may be truncated writing between 3 and 
11 bytes into a region of size between 0 and 80 [-Wformat-truncation=]
                     "%s.%.3d %s", timestamp_prefix,
                         ^~~~
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:20: 
note: using the range [-2147483648, 2147483647] for directive argument
                     "%s.%.3d %s", timestamp_prefix,
                     ^~~~~~~~~~~~
/home/rep/sources/jdk/src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:74:11: 
note: ?snprintf? output between 6 and 174 bytes into a destination of 
size 81
      (void)snprintf(tbuf, ltbuf,
            ^~~~~~~~~~~~~~~~~~~~~
                     "%s.%.3d %s", timestamp_prefix,
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     (int)(millisecs), timestamp_postfix);
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


and a lot of those:

/home/rep/sources/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-debug.hh:130:1: 
warning: explicit specialization ?void _hb_debug_msg_va(const char*, 
const void*, const char*, bool, unsigned int, int, const char*, 
__va_list_tag*) [with int max_level = 0]? may be missing attributes 
[-Wmissing-attributes]
  _hb_debug_msg_va<0> (const char *what HB_UNUSED,
  ^~~~~~~~~~~~~~~~~~~




On 2018-06-19 11:20, Andrew Haley wrote:
> On 06/19/2018 03:30 AM, David Holmes wrote:
>> I've filed:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8205201
>> 
>> for the underlying issue. Hotspot folk need to check if the warnings 
>> are
>> legitmate or not. If not then we may need to disable this warning in 
>> the
>> build.
> 
> The warnings are legitimate: it's unnecessarily hairy code.  It could
> easily be rewritten to use memcpy(), would be obviously guaranteed not
> to exceed array bounds, and might even be slightly faster.  Fixing
> these warnings is an opportunity to clean up some of this code.


From volker.simonis at gmail.com  Tue Jun 19 12:21:54 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 19 Jun 2018 14:21:54 +0200
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <8ada6cad-09f4-cde2-69c8-561a142bc3bb@oracle.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
 <67efe9b2-bd7a-e23a-74d6-786cbc135d16@oracle.com>
 <CA+3eh13ykMSQvNJ9EBjKjck_PUMPe0wkJ-5v5KCe6G_YzA068w@mail.gmail.com>
 <8ada6cad-09f4-cde2-69c8-561a142bc3bb@oracle.com>
Message-ID: <CA+3eh12QVukbysM201ER_j-z=X9jQ08LufRUYzZgfEfuhZtjpg@mail.gmail.com>

On Tue, Jun 19, 2018 at 9:25 AM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Volker,
>
> On 19/06/2018 4:50 PM, Volker Simonis wrote:
>>
>> On Tue, Jun 19, 2018 at 6:54 AM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> Hi Volker,
>>>
>>> v3 looks much cleaner - thanks.
>>>
>>> But AFAICS the change to jvmtiEnv.cpp is also not needed.
>>> ClassLoaderExt::append_boot_classpath exists regardless of INCLUDE_CDS
>>> but
>>> operates differently (just calling
>>> ClassLoader::add_to_boot_append_entries).
>>>
>>
>> That's not entirely true because the whole compilation unit (i.e.
>> classLoaderExt.cpp) which contains
>> 'ClassLoaderExt::append_boot_classpath()' is excluded from the
>> compilation if CDS is disabled (see make/hotspot/lib/JvmFeatures.gmk).
>
>
> Hmmm. There's a CDS bug there. Either classLoaderExt.cpp should not be
> excluded from a non-CDS build, or it should not contain any INCLUDE_CDS
> guards! I suspect it should not be excluded.
>
>> So I can either move the whole implementation of
>> 'ClassLoaderExt::append_boot_classpath()' into classLoaderExt.hpp in
>> which case things would work as you explained and my changes to
>> jvmtiEnv.cpp could be removed or leave the whole code and change as
>> is. Please let me know what you think?
>
>
> In the interest of moving forward you can push what you have and I will file
> a bug against CDS to sort out classLoaderExt.cpp.
>

Thanks! As the current version also passed the submit-repo tests I've pushed it.

Regarding classLoaderExt.cpp, I think it is OK to exclude it for
non-CDS builds. If my IDE doesn't cheat on me (see [1]),
ClassLoaderExt is mostly used from other CDS-only files
(classListParser.cpp, systemDictionaryShared.cpp, filemap.cpp,
metaspaceShared.cpp). The only references from non-CDS files are from
classLoader.cpp an jvmtiEnv.cpp. The ones from classLoader.cpp are all
guarded with 'INCLUDE_CDS' or they only use functions defined in
classLoaderExt.hpp. The single remaining reference from jvmtiEnv.cpp
has been guarded with 'INCLUDE_CDS' by my change.

I think it is a matter of taste if we leave this as is or move the
offending function from classLoaderExt.cpp to classLoaderExt.hpp and
remove the new guard from jvmtiEnv.cpp.

Regards,
Volker

[1] http://cr.openjdk.java.net/~simonis/webrevs/2018/ClassLoaderExt.html

> Thanks,
> David
>
>
>> Regards,
>> Volker
>>
>>> Thanks,
>>> David
>>>
>>>
>>> On 19/06/2018 2:04 AM, Volker Simonis wrote:
>>>>
>>>>
>>>> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> src/hotspot/share/runtime/globals.hpp
>>>>>
>>>>> This change should not be needed! We do minimal VM builds without CDS
>>>>> and
>>>>> we
>>>>> don't have to touch the UseSharedSpaces defaults (unless recent change
>>>>> have
>>>>> broken this - in which case that needs to be addressed in its own
>>>>> right!)
>>>>>
>>>>
>>>> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
>>>> because UseSharedSpaces is reseted later on at the end of
>>>> Arguments::parse(). I just thought it would be cleaner to disable it
>>>> statically, if the VM doesn't support it. But anyway I don't really
>>>> mind and I've reverted that change in globals.hpp.
>>>>
>>>>> src/hotspot/share/classfile/javaClasses.cpp
>>>>>
>>>>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>>>>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this
>>>>> should
>>>>> be needed as we have not needed it before. As Thomas notes we have:
>>>>>
>>>>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>>>>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>>>>> create_archived_string(oop s, Thread* THREAD)
>>>>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>>>>>
>>>>> so these methods should be defined when CDS is not available.
>>>>>
>>>>
>>>> Thomas and you are right. Must have been a mis-configuration on AIX
>>>> where I saw undefined symbols at link time. I've removed the ifdefs
>>>> from javaClasses.cpp now.
>>>>
>>>> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
>>>> into CDS_ONLY macros as suggested by Jiangli because the really only
>>>> make sense for a CDS-enabled VM.
>>>>
>>>> Here's the new webrev:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
>>>>
>>>> Please let me know if you think there's still something missing.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>>> ??
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> can I please have a review for the following fix:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>>>>
>>>>>> CDS does currently not work on AIX because of the way how we
>>>>>> reserve/commit memory on AIX. The problem is that we're using a
>>>>>> combination of shmat/mmap depending on the page size and the size of
>>>>>> the memory chunk to reserve. This makes it impossible to reliably
>>>>>> reserve the memory for the CDS archive and later on map the various
>>>>>> parts of the archive into these regions.
>>>>>>
>>>>>> In order to fix this we would have to completely rework the memory
>>>>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>>>>> scope because of resource limitations.
>>>>>>
>>>>>> Unfortunately, I could not simply disable CDS in the configure step
>>>>>> because some of the shared code apparently relies on parts of the CDS
>>>>>> code which gets excluded from the build when CDS is disabled. So I
>>>>>> also fixed the offending parts in hotspot and cleaned up the configure
>>>>>> logic for CDS.
>>>>>>
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>>
>>>>>> PS: I did run the job through the submit forest
>>>>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>>>>> weren't really useful because they mention build failures on linux-x64
>>>>>> which I can't reproduce locally.
>>>>>>
>>>>>
>>>
>


From sgehwolf at redhat.com  Tue Jun 19 13:30:17 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 19 Jun 2018 15:30:17 +0200
Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves
 symbolic links AND 8148351: Only display resolved symlink for compiler, do
 not change path
In-Reply-To: <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com>
References: <bd19ac583e7a49d72d80f082ffec40e8ce825f6f.camel@redhat.com>
 <20180618164544.GB3250@vimes>
 <7519930b-8524-be33-f512-3ec222969dec@oracle.com>
 <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com>
 <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com>
Message-ID: <a20258b56272261ef732816b04a45c2e4b525708.camel@redhat.com>

Hi Kevin,

Thanks for your help! Adding in build-dev for additional input.

On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote:
> Hi Severin -
> 
> Ah, actually there's a conflict with the way we build, where we use 
> ccache in the path, and it no longer likes it with this change:
> 
> Our build system jprt fails, with the configure output:
> ...
> checking flags for boot jdk java command for small workloads... 
> -XX:+UseSerialGC -Xms32M -Xmx512M
> configure: Using default toolchain gcc (GNU Compiler Collection)
> checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc
> checking resolved symbolic links for CC... 
> /opt/jprt/products/P1/ccache2.4/bin/ccache
> configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic 
> link to ccache. This is not supported.
> configure: Please use --enable-ccache instead of providing a wrapped 
> compiler.
> configure exiting with result code 1

Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way
to use "--enable-ccache" for JDK 8 builds?

> It's the second change, 8148351, which triggers this failure, as it 
> removes lines at 549 onwards which previously tried to handle the ccache 
> in the path case.

Right. It's 8148351 which we'd be interested in.

> Yes, in 9 onward we abort the build if ccache is found at the end of a 
> link, we haven't done that in jdk 8 before... Would retaining the ccache 
> handling code in toolchain.m4 still give you the behaviour you want from 
> doing the backport?

Thanks,
Severin

> Thanks
> Kevin
> 
> 
> 
> 
> 
> On 19/06/2018 07:23, Severin Gehwolf wrote:
> > Hi Kevin,
> > 
> > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote:
> > > Hi -- I've been doing various 8u build changes recently -- would you
> > > like me to push this, with the regenerated autogen-generated file?
> > 
> > It would be very much appreciated!
> > 
> > Thanks,
> > Severin
> > 
> > > 
> > > On 18/06/2018 17:45, Rob McKenna wrote:
> > > > Approved. Please work with the appropriate team to find a sponsor.
> > > > 
> > > >       -Rob
> > > > 
> > > > On 18/06/18 16:36, Severin Gehwolf wrote:
> > > > > Hi,
> > > > > 
> > > > > Please approve these two backports to JDK 8u-dev which are already in
> > > > > JDK 9 and better.
> > > > > 
> > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links
> > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/
> > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch
> > > > > 
> > > > > 8148351: Only display resolved symlink for compiler, do not change path
> > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/
> > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch
> > > > > 
> > > > > Bug 8031668 is a dependency for 8148351 which actually fixes the
> > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is
> > > > > the same as for JDK 9, modulo some context changes. After the JDK 8
> > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is.
> > > > > 
> > > > > The issue at hand is that one cannot build the JDK 8 tree with certain
> > > > > compiler wrappers such as cscppc. It currently fails with:
> > > > > 
> > > > > configure: Using default toolchain gcc (GNU Compiler Collection)
> > > > > checking for gcc... /usr/lib64/cscppc/gcc
> > > > > checking resolved symbolic links for CC... /usr/bin/cscppc
> > > > > checking if CC is disguised ccache... no, keeping CC
> > > > > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler.
> > > > > configure: The result from running with --version was: ""
> > > > > configure: error: A gcc compiler is required. Try setting --with-tools-dir.
> > > > > configure exiting with result code 1
> > > > > 
> > > > > After both backports configure with a wrapped GCC succeeds.
> > > > > 
> > > > > Please note that I'd need an Oracle sponsor for getting this pushed to
> > > > > jdk8u-dev since both changes require re-generation of generated-
> > > > > configure.sh
> > > > > 
> > > > > Thanks,
> > > > > Severin
> 
> 


From erik.joelsson at oracle.com  Tue Jun 19 13:34:50 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 19 Jun 2018 06:34:50 -0700
Subject: RFR: 8205197: Never default to using libc++ on Linux
In-Reply-To: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>
References: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>
Message-ID: <d23cd792-a019-0fef-4cab-fc46edd967cb@oracle.com>

Looks ok to me.

/Erik


On 2018-06-18 17:36, Martin Buchholz wrote:
> 8205197: Never default to using libc++ on Linux
> http://cr.openjdk.java.net/~martin/webrevs/jdk/stlib-default/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/jdk/stlib-default/>
> https://bugs.openjdk.java.net/browse/JDK-8205197
>



From erik.joelsson at oracle.com  Tue Jun 19 14:06:50 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 19 Jun 2018 07:06:50 -0700
Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves
 symbolic links AND 8148351: Only display resolved symlink for compiler, do
 not change path
In-Reply-To: <a20258b56272261ef732816b04a45c2e4b525708.camel@redhat.com>
References: <bd19ac583e7a49d72d80f082ffec40e8ce825f6f.camel@redhat.com>
 <20180618164544.GB3250@vimes>
 <7519930b-8524-be33-f512-3ec222969dec@oracle.com>
 <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com>
 <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com>
 <a20258b56272261ef732816b04a45c2e4b525708.camel@redhat.com>
Message-ID: <f273abba-d19d-1cc0-fedd-e53ecd9a76d9@oracle.com>

Hello,

On 2018-06-19 06:30, Severin Gehwolf wrote:
> Hi Kevin,
>
> Thanks for your help! Adding in build-dev for additional input.
>
> On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote:
>> Hi Severin -
>>
>> Ah, actually there's a conflict with the way we build, where we use
>> ccache in the path, and it no longer likes it with this change:
>>
>> Our build system jprt fails, with the configure output:
>> ...
>> checking flags for boot jdk java command for small workloads...
>> -XX:+UseSerialGC -Xms32M -Xmx512M
>> configure: Using default toolchain gcc (GNU Compiler Collection)
>> checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc
>> checking resolved symbolic links for CC...
>> /opt/jprt/products/P1/ccache2.4/bin/ccache
>> configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic
>> link to ccache. This is not supported.
>> configure: Please use --enable-ccache instead of providing a wrapped
>> compiler.
>> configure exiting with result code 1
> Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way
> to use "--enable-ccache" for JDK 8 builds?
We don't. The problem here is that the build machines we have for 8 have 
ccache installed as a gcc wrapper. This was done back in 7 with the 
intention of transparently improving build performance (but in reality 
it didn't). Because of this situation, we implemented a workaround for 8 
where we explicitly don't accept ccache as gcc wrapper and look for gcc 
elsewhere instead. Our build machines for 9 do not have cache installed 
at all (it's still in the devkit, but not as a wrapper, and since we saw 
no benefit for our use case we don't use ccache anyway).

The change being backported here removes the workaround that allows the 
build to function with the ccache wrapper on the system. I don't think 
that's a good idea for 8. We need to retain that workaround so the patch 
needs to be modified before going into 8u.

Reproducing this issue locally should be pretty simple. Create a dummy 
script named ccache somewhere. Put a symlink named gcc, pointing to that 
ccache script first in your path. Then run configure.

/Erik
>> It's the second change, 8148351, which triggers this failure, as it
>> removes lines at 549 onwards which previously tried to handle the ccache
>> in the path case.
> Right. It's 8148351 which we'd be interested in.
>
>> Yes, in 9 onward we abort the build if ccache is found at the end of a
>> link, we haven't done that in jdk 8 before... Would retaining the ccache
>> handling code in toolchain.m4 still give you the behaviour you want from
>> doing the backport?
> Thanks,
> Severin
>
>> Thanks
>> Kevin
>>
>>
>>
>>
>>
>> On 19/06/2018 07:23, Severin Gehwolf wrote:
>>> Hi Kevin,
>>>
>>> On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote:
>>>> Hi -- I've been doing various 8u build changes recently -- would you
>>>> like me to push this, with the regenerated autogen-generated file?
>>> It would be very much appreciated!
>>>
>>> Thanks,
>>> Severin
>>>
>>>> On 18/06/2018 17:45, Rob McKenna wrote:
>>>>> Approved. Please work with the appropriate team to find a sponsor.
>>>>>
>>>>>        -Rob
>>>>>
>>>>> On 18/06/18 16:36, Severin Gehwolf wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please approve these two backports to JDK 8u-dev which are already in
>>>>>> JDK 9 and better.
>>>>>>
>>>>>> 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links
>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/
>>>>>> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch
>>>>>>
>>>>>> 8148351: Only display resolved symlink for compiler, do not change path
>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/
>>>>>> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch
>>>>>>
>>>>>> Bug 8031668 is a dependency for 8148351 which actually fixes the
>>>>>> wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is
>>>>>> the same as for JDK 9, modulo some context changes. After the JDK 8
>>>>>> patch of 8031668, the JDK 9 patch of 8148351 imports as is.
>>>>>>
>>>>>> The issue at hand is that one cannot build the JDK 8 tree with certain
>>>>>> compiler wrappers such as cscppc. It currently fails with:
>>>>>>
>>>>>> configure: Using default toolchain gcc (GNU Compiler Collection)
>>>>>> checking for gcc... /usr/lib64/cscppc/gcc
>>>>>> checking resolved symbolic links for CC... /usr/bin/cscppc
>>>>>> checking if CC is disguised ccache... no, keeping CC
>>>>>> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler.
>>>>>> configure: The result from running with --version was: ""
>>>>>> configure: error: A gcc compiler is required. Try setting --with-tools-dir.
>>>>>> configure exiting with result code 1
>>>>>>
>>>>>> After both backports configure with a wrapped GCC succeeds.
>>>>>>
>>>>>> Please note that I'd need an Oracle sponsor for getting this pushed to
>>>>>> jdk8u-dev since both changes require re-generation of generated-
>>>>>> configure.sh
>>>>>>
>>>>>> Thanks,
>>>>>> Severin
>>



From sgehwolf at redhat.com  Tue Jun 19 14:17:08 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 19 Jun 2018 16:17:08 +0200
Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves
 symbolic links AND 8148351: Only display resolved symlink for compiler, do
 not change path
In-Reply-To: <f273abba-d19d-1cc0-fedd-e53ecd9a76d9@oracle.com>
References: <bd19ac583e7a49d72d80f082ffec40e8ce825f6f.camel@redhat.com>
 <20180618164544.GB3250@vimes>
 <7519930b-8524-be33-f512-3ec222969dec@oracle.com>
 <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com>
 <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com>
 <a20258b56272261ef732816b04a45c2e4b525708.camel@redhat.com>
 <f273abba-d19d-1cc0-fedd-e53ecd9a76d9@oracle.com>
Message-ID: <c97e2ad96a22c5140779a306ca425f464341bebc.camel@redhat.com>

Hi Erik,

On Tue, 2018-06-19 at 07:06 -0700, Erik Joelsson wrote:
> Hello,
> 
> On 2018-06-19 06:30, Severin Gehwolf wrote:
> > Hi Kevin,
> > 
> > Thanks for your help! Adding in build-dev for additional input.
> > 
> > On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote:
> > > Hi Severin -
> > > 
> > > Ah, actually there's a conflict with the way we build, where we use
> > > ccache in the path, and it no longer likes it with this change:
> > > 
> > > Our build system jprt fails, with the configure output:
> > > ...
> > > checking flags for boot jdk java command for small workloads...
> > > -XX:+UseSerialGC -Xms32M -Xmx512M
> > > configure: Using default toolchain gcc (GNU Compiler Collection)
> > > checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc
> > > checking resolved symbolic links for CC...
> > > /opt/jprt/products/P1/ccache2.4/bin/ccache
> > > configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic
> > > link to ccache. This is not supported.
> > > configure: Please use --enable-ccache instead of providing a wrapped
> > > compiler.
> > > configure exiting with result code 1
> > 
> > Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way
> > to use "--enable-ccache" for JDK 8 builds?
> 
> We don't. The problem here is that the build machines we have for 8 have 
> ccache installed as a gcc wrapper. This was done back in 7 with the 
> intention of transparently improving build performance (but in reality 
> it didn't). Because of this situation, we implemented a workaround for 8 
> where we explicitly don't accept ccache as gcc wrapper and look for gcc 
> elsewhere instead. Our build machines for 9 do not have cache installed 
> at all (it's still in the devkit, but not as a wrapper, and since we saw 
> no benefit for our use case we don't use ccache anyway).
> 
> The change being backported here removes the workaround that allows the 
> build to function with the ccache wrapper on the system. I don't think 
> that's a good idea for 8. We need to retain that workaround so the patch 
> needs to be modified before going into 8u.

Sigh. Back to the drawing board ;-)

> Reproducing this issue locally should be pretty simple. Create a dummy 
> script named ccache somewhere. Put a symlink named gcc, pointing to that 
> ccache script first in your path. Then run configure.

Thanks, yes. I've got that reproduced.

Cheers,
Severin

> /Erik
> > > It's the second change, 8148351, which triggers this failure, as it
> > > removes lines at 549 onwards which previously tried to handle the ccache
> > > in the path case.
> > 
> > Right. It's 8148351 which we'd be interested in.
> > 
> > > Yes, in 9 onward we abort the build if ccache is found at the end of a
> > > link, we haven't done that in jdk 8 before... Would retaining the ccache
> > > handling code in toolchain.m4 still give you the behaviour you want from
> > > doing the backport?
> > 
> > Thanks,
> > Severin
> > 
> > > Thanks
> > > Kevin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On 19/06/2018 07:23, Severin Gehwolf wrote:
> > > > Hi Kevin,
> > > > 
> > > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote:
> > > > > Hi -- I've been doing various 8u build changes recently -- would you
> > > > > like me to push this, with the regenerated autogen-generated file?
> > > > 
> > > > It would be very much appreciated!
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > On 18/06/2018 17:45, Rob McKenna wrote:
> > > > > > Approved. Please work with the appropriate team to find a sponsor.
> > > > > > 
> > > > > >        -Rob
> > > > > > 
> > > > > > On 18/06/18 16:36, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Please approve these two backports to JDK 8u-dev which are already in
> > > > > > > JDK 9 and better.
> > > > > > > 
> > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links
> > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/
> > > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch
> > > > > > > 
> > > > > > > 8148351: Only display resolved symlink for compiler, do not change path
> > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/
> > > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch
> > > > > > > 
> > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes the
> > > > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is
> > > > > > > the same as for JDK 9, modulo some context changes. After the JDK 8
> > > > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is.
> > > > > > > 
> > > > > > > The issue at hand is that one cannot build the JDK 8 tree with certain
> > > > > > > compiler wrappers such as cscppc. It currently fails with:
> > > > > > > 
> > > > > > > configure: Using default toolchain gcc (GNU Compiler Collection)
> > > > > > > checking for gcc... /usr/lib64/cscppc/gcc
> > > > > > > checking resolved symbolic links for CC... /usr/bin/cscppc
> > > > > > > checking if CC is disguised ccache... no, keeping CC
> > > > > > > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler.
> > > > > > > configure: The result from running with --version was: ""
> > > > > > > configure: error: A gcc compiler is required. Try setting --with-tools-dir.
> > > > > > > configure exiting with result code 1
> > > > > > > 
> > > > > > > After both backports configure with a wrapped GCC succeeds.
> > > > > > > 
> > > > > > > Please note that I'd need an Oracle sponsor for getting this pushed to
> > > > > > > jdk8u-dev since both changes require re-generation of generated-
> > > > > > > configure.sh
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Severin
> 
> 


From sgehwolf at redhat.com  Tue Jun 19 16:57:40 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 19 Jun 2018 18:57:40 +0200
Subject: [8u] RFR: 8148351: Only display resolved symlink for compiler, do
 not change path
Message-ID: <1d446a7c2c17dcab2f6458cd5015aa115c9c89eb.camel@redhat.com>

Hi,

After discussion in [1], please review this revised JDK 8u backport of
JDK-8148351. When the compiler is a symlink to ccache it'll continue to
use it's work-around to keep the Oracle JDK 8 build working. If the
compiler isn't a symlink it'll print this as a configure message and
won't do the ccache work-around (which it did prior this patch). 

Example:

Before:

checking for gcc... /usr/bin/gcc
checking resolved symbolic links for CC... /usr/bin/gcc
checking if CC is disguised ccache... no, keeping CC
configure: Using gcc C compiler version 8.1.1 [gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)]

After:

checking for gcc... /usr/bin/gcc
checking resolved symbolic links for CC... no symlink
configure: Using gcc C compiler version 8.1.1 [gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)]

webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.02/

Thoughts?

Thanks,
Severin

[1] http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022444.html


From erik.joelsson at oracle.com  Tue Jun 19 17:12:40 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 19 Jun 2018 10:12:40 -0700
Subject: [8u] RFR: 8148351: Only display resolved symlink for compiler, do
 not change path
In-Reply-To: <1d446a7c2c17dcab2f6458cd5015aa115c9c89eb.camel@redhat.com>
References: <1d446a7c2c17dcab2f6458cd5015aa115c9c89eb.camel@redhat.com>
Message-ID: <1626b8d5-3060-5d98-c343-7b83ea3e73fd@oracle.com>

This looks good to me.

/Erik


On 2018-06-19 09:57, Severin Gehwolf wrote:
> Hi,
>
> After discussion in [1], please review this revised JDK 8u backport of
> JDK-8148351. When the compiler is a symlink to ccache it'll continue to
> use it's work-around to keep the Oracle JDK 8 build working. If the
> compiler isn't a symlink it'll print this as a configure message and
> won't do the ccache work-around (which it did prior this patch).
>
> Example:
>
> Before:
>
> checking for gcc... /usr/bin/gcc
> checking resolved symbolic links for CC... /usr/bin/gcc
> checking if CC is disguised ccache... no, keeping CC
> configure: Using gcc C compiler version 8.1.1 [gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)]
>
> After:
>
> checking for gcc... /usr/bin/gcc
> checking resolved symbolic links for CC... no symlink
> configure: Using gcc C compiler version 8.1.1 [gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)]
>
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.02/
>
> Thoughts?
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022444.html



From jiangli.zhou at oracle.com  Tue Jun 19 18:10:24 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 19 Jun 2018 11:10:24 -0700
Subject: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by
 default
In-Reply-To: <CA+3eh12QVukbysM201ER_j-z=X9jQ08LufRUYzZgfEfuhZtjpg@mail.gmail.com>
References: <CA+3eh12TtXe7GyYdoC0DQxx_UvEsEW6FNr=fh6m5RBxnyo64+Q@mail.gmail.com>
 <f781f727-2c90-f87d-d9d8-533681972454@oracle.com>
 <CA+3eh128neW77p_bbOjfcgzJzJv58AUbO08x_FJ8i6fKPK4fsA@mail.gmail.com>
 <67efe9b2-bd7a-e23a-74d6-786cbc135d16@oracle.com>
 <CA+3eh13ykMSQvNJ9EBjKjck_PUMPe0wkJ-5v5KCe6G_YzA068w@mail.gmail.com>
 <8ada6cad-09f4-cde2-69c8-561a142bc3bb@oracle.com>
 <CA+3eh12QVukbysM201ER_j-z=X9jQ08LufRUYzZgfEfuhZtjpg@mail.gmail.com>
Message-ID: <E1C428AE-5177-4D31-BA0E-F3B4B736E071@oracle.com>


> On Jun 19, 2018, at 5:21 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Tue, Jun 19, 2018 at 9:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>> 
>> On 19/06/2018 4:50 PM, Volker Simonis wrote:
>>> 
>>> On Tue, Jun 19, 2018 at 6:54 AM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>> 
>>>> Hi Volker,
>>>> 
>>>> v3 looks much cleaner - thanks.
>>>> 
>>>> But AFAICS the change to jvmtiEnv.cpp is also not needed.
>>>> ClassLoaderExt::append_boot_classpath exists regardless of INCLUDE_CDS
>>>> but
>>>> operates differently (just calling
>>>> ClassLoader::add_to_boot_append_entries).
>>>> 
>>> 
>>> That's not entirely true because the whole compilation unit (i.e.
>>> classLoaderExt.cpp) which contains
>>> 'ClassLoaderExt::append_boot_classpath()' is excluded from the
>>> compilation if CDS is disabled (see make/hotspot/lib/JvmFeatures.gmk).
>> 
>> 
>> Hmmm. There's a CDS bug there. Either classLoaderExt.cpp should not be
>> excluded from a non-CDS build, or it should not contain any INCLUDE_CDS
>> guards! I suspect it should not be excluded.
>> 
>>> So I can either move the whole implementation of
>>> 'ClassLoaderExt::append_boot_classpath()' into classLoaderExt.hpp in
>>> which case things would work as you explained and my changes to
>>> jvmtiEnv.cpp could be removed or leave the whole code and change as
>>> is. Please let me know what you think?
>> 
>> 
>> In the interest of moving forward you can push what you have and I will file
>> a bug against CDS to sort out classLoaderExt.cpp.
>> 
> 
> Thanks! As the current version also passed the submit-repo tests I've pushed it.
> 
> Regarding classLoaderExt.cpp, I think it is OK to exclude it for
> non-CDS builds. If my IDE doesn't cheat on me (see [1]),
> ClassLoaderExt is mostly used from other CDS-only files
> (classListParser.cpp, systemDictionaryShared.cpp, filemap.cpp,
> metaspaceShared.cpp). The only references from non-CDS files are from
> classLoader.cpp an jvmtiEnv.cpp. The ones from classLoader.cpp are all
> guarded with 'INCLUDE_CDS' or they only use functions defined in
> classLoaderExt.hpp. The single remaining reference from jvmtiEnv.cpp
> has been guarded with 'INCLUDE_CDS' by my change.
> 
> I think it is a matter of taste if we leave this as is or move the
> offending function from classLoaderExt.cpp to classLoaderExt.hpp and
> remove the new guard from jvmtiEnv.cpp.

For the classLoaderExt.cpp bug, we could use a private function, ClassLoaderExt::disable_shared_platform_and_app_classes, which does the logic in the original ClassLoaderExt::append_boot_classpath #INCLUDE_CDS. ClassLoaderExt::append_boot_classpath could be defined in classLoaderExt.hpp as:

void disable_shared_platform_and_app_classes() NOT_CDS_RETURN;

void append_boot_classpath(ClassPathEntry* new_entry) {
  disable_shared_platform_and_app_classes();
  ClassLoader::add_to_boot_append_entries(new_entry);
}

The new guard can be removed from jvmtiEnv.cpp with those. Reducing CDS specifics from general code probably is cleaner.

Thanks,
Jiangli


> 
> Regards,
> Volker
> 
> [1] http://cr.openjdk.java.net/~simonis/webrevs/2018/ClassLoaderExt.html
> 
>> Thanks,
>> David
>> 
>> 
>>> Regards,
>>> Volker
>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> 
>>>> On 19/06/2018 2:04 AM, Volker Simonis wrote:
>>>>> 
>>>>> 
>>>>> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes <david.holmes at oracle.com>
>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi Volker,
>>>>>> 
>>>>>> src/hotspot/share/runtime/globals.hpp
>>>>>> 
>>>>>> This change should not be needed! We do minimal VM builds without CDS
>>>>>> and
>>>>>> we
>>>>>> don't have to touch the UseSharedSpaces defaults (unless recent change
>>>>>> have
>>>>>> broken this - in which case that needs to be addressed in its own
>>>>>> right!)
>>>>>> 
>>>>> 
>>>>> Yes, you're right, CDS_ONLY/NOT_CDS isn't really required here,
>>>>> because UseSharedSpaces is reseted later on at the end of
>>>>> Arguments::parse(). I just thought it would be cleaner to disable it
>>>>> statically, if the VM doesn't support it. But anyway I don't really
>>>>> mind and I've reverted that change in globals.hpp.
>>>>> 
>>>>>> src/hotspot/share/classfile/javaClasses.cpp
>>>>>> 
>>>>>> AFAICS you should be using INCLUDE_CDS in the ifdefs not
>>>>>> INCLUDE_CDS_JAVA_HEAP. But again I'm unclear (as was Thomas) why this
>>>>>> should
>>>>>> be needed as we have not needed it before. As Thomas notes we have:
>>>>>> 
>>>>>> ./hotspot/share/memory/metaspaceShared.hpp:  static bool
>>>>>> is_archive_object(oop p) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>> ./hotspot/share/classfile/stringTable.hpp:  static oop
>>>>>> create_archived_string(oop s, Thread* THREAD)
>>>>>> NOT_CDS_JAVA_HEAP_RETURN_(NULL);
>>>>>> 
>>>>>> so these methods should be defined when CDS is not available.
>>>>>> 
>>>>> 
>>>>> Thomas and you are right. Must have been a mis-configuration on AIX
>>>>> where I saw undefined symbols at link time. I've removed the ifdefs
>>>>> from javaClasses.cpp now.
>>>>> 
>>>>> Finally, I've also wrapped all the FileMapInfo fields in vmStructs.cpp
>>>>> into CDS_ONLY macros as suggested by Jiangli because the really only
>>>>> make sense for a CDS-enabled VM.
>>>>> 
>>>>> Here's the new webrev:
>>>>> 
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965.v3/
>>>>> 
>>>>> Please let me know if you think there's still something missing.
>>>>> 
>>>>> Regards,
>>>>> Volker
>>>>> 
>>>>> 
>>>>>> ??
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 15/06/2018 12:26 AM, Volker Simonis wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> can I please have a review for the following fix:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>>>>> 
>>>>>>> CDS does currently not work on AIX because of the way how we
>>>>>>> reserve/commit memory on AIX. The problem is that we're using a
>>>>>>> combination of shmat/mmap depending on the page size and the size of
>>>>>>> the memory chunk to reserve. This makes it impossible to reliably
>>>>>>> reserve the memory for the CDS archive and later on map the various
>>>>>>> parts of the archive into these regions.
>>>>>>> 
>>>>>>> In order to fix this we would have to completely rework the memory
>>>>>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>>>>>> scope because of resource limitations.
>>>>>>> 
>>>>>>> Unfortunately, I could not simply disable CDS in the configure step
>>>>>>> because some of the shared code apparently relies on parts of the CDS
>>>>>>> code which gets excluded from the build when CDS is disabled. So I
>>>>>>> also fixed the offending parts in hotspot and cleaned up the configure
>>>>>>> logic for CDS.
>>>>>>> 
>>>>>>> Thank you and best regards,
>>>>>>> Volker
>>>>>>> 
>>>>>>> PS: I did run the job through the submit forest
>>>>>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>>>>>> weren't really useful because they mention build failures on linux-x64
>>>>>>> which I can't reproduce locally.
>>>>>>> 
>>>>>> 
>>>> 
>> 



From kevin.walls at oracle.com  Tue Jun 19 20:06:00 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 19 Jun 2018 21:06:00 +0100
Subject: [8u] RFR: 8148351: Only display resolved symlink for compiler, do
 not change path
In-Reply-To: <1d446a7c2c17dcab2f6458cd5015aa115c9c89eb.camel@redhat.com>
References: <1d446a7c2c17dcab2f6458cd5015aa115c9c89eb.camel@redhat.com>
Message-ID: <dca0be87-88a7-0c45-75bc-b021aae805fa@oracle.com>

Thanks Severin,

Yes, keeping the special case about ccache should keep our own builds 
happy.? I ran this in JPRT earlier today and the builds went OK, so if 
it fixes your issue also then it looks good to me.

Thanks
Kevin


On 19/06/2018 17:57, Severin Gehwolf wrote:
> Hi,
>
> After discussion in [1], please review this revised JDK 8u backport of
> JDK-8148351. When the compiler is a symlink to ccache it'll continue to
> use it's work-around to keep the Oracle JDK 8 build working. If the
> compiler isn't a symlink it'll print this as a configure message and
> won't do the ccache work-around (which it did prior this patch).
>
> Example:
>
> Before:
>
> checking for gcc... /usr/bin/gcc
> checking resolved symbolic links for CC... /usr/bin/gcc
> checking if CC is disguised ccache... no, keeping CC
> configure: Using gcc C compiler version 8.1.1 [gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)]
>
> After:
>
> checking for gcc... /usr/bin/gcc
> checking resolved symbolic links for CC... no symlink
> configure: Using gcc C compiler version 8.1.1 [gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)]
>
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.02/
>
> Thoughts?
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022444.html



From erik.joelsson at oracle.com  Tue Jun 19 21:00:14 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 19 Jun 2018 14:00:14 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
Message-ID: <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>

Hello,

Please always include build-dev when reviewing build changes.

In general this looks pretty good but there are some details that need 
fixing.

(Aside from this particular review, I must state my reservation against 
all the special treatment graal is enjoying from a source and test 
layout and build perspective. My understanding here is that someone will 
have to regularly update the wrapper jtreg tests manually using the 
script. This in addition to having to implement this very convoluted 
redirection logic because the tests are in the wrong place. Wouldn't it 
make a lot more sense to put the complicated logic in the import 
procedure for graal source so that it would fit nicely into the OpenJDK 
source/build/test model, instead of adding more and more complicated 
workarounds in the OpenJDK build and test procedures?)

On 2018-06-18 22:26, Ekaterina Pavlova wrote:
> Hi All,
>
> please review porting of Graal unit tests under jtreg. The main idea 
> of this porting is to keep Graal unit tests as is
> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run 
> them similar way they are run in Graal project.
> To achieve this 
> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java 
> helper class has been written
> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run 
> specified set of Graal unit tests. The groups of
> Graal unit tests to run are defined in auto-generated 
> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>
> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests 
> into jdk.vm.compiler.tests.jar and then install
> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>
GRAALUNIT_LIB is never defined (in the open). Since this is used in open 
makefiles, we need an open configure option to set it.

To make things clearer, I would rename LIB_DIR to something like 
LIB_OUTPUTDIR to signal that this is a location to put files in, rather 
than read them from.

FLATTEN has no effect in the SetupCopyFiles call since all the jar files 
found by wildcard can only be in one directory anyway.

BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests 
classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/... 
Please create a suitable sub directory there for the output from this 
makefile.

The all and test-image targets are never called so no need to declare them.

There are some style issues too. (Please see 
http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
* 43 logic indent 2 spaces
* 52 we like to put the ending )) on a new line with ', \' at the end of 
the line before
* 58 continuation indent 4 spaces
* 88, 89 please break long lines
* 90 continuation indent 4 spaces
* 99 continuation indent 4 spaces
* 120 break before ))
> make/Main.gmk adds proper dependencies for 
> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>
The target build-test-hotspot-jtreg-graal only needs to depend on 
exploded-image-optimize.

The new graal specific targets should be guarded by INCLUDE_GRAAL in 
Main.gmk. Otherwise those targets will silently do nothing if invoked 
without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to 
be conditional too.
> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg 
> knows where to find Graal tests and libs.
>
This needs to be duplicated for make/RunTest.gmk so that these tests 
work with "make run-test" as well.

/Erik
> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines 
> "testName -> testPrefix [requiresStatement]" mapping
> which is used by 
> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to 
> generate jtreg tests.
>
> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was 
> ported from mx project without any changes.
>
>
> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
> ?webrev: 
> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
> testing: new tests were executed as part of automatic HS testing for 
> several months.
>
>
> thanks,
> -katya
>
> p.s.
> ?Igor Ignatyev volunteered to sponsor this change. 



From gerard.ziemski at oracle.com  Tue Jun 19 21:00:25 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Tue, 19 Jun 2018 16:00:25 -0500
Subject: RFR: 8205197: Never default to using libc++ on Linux
In-Reply-To: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>
References: <CA+kOe0_JvBbH7nMk0h+A5y5Q_570p=ENjBcmf9HZf=K1Hdoq-w@mail.gmail.com>
Message-ID: <5C0FCD28-725A-42C8-816C-6F01A6CCB014@oracle.com>

Thank you for fixing this.


> On Jun 18, 2018, at 7:36 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> 8205197: Never default to using libc++ on Linux
> http://cr.openjdk.java.net/~martin/webrevs/jdk/stlib-default/
> https://bugs.openjdk.java.net/browse/JDK-8205197
> 



From doug.simon at oracle.com  Tue Jun 19 21:10:11 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 19 Jun 2018 23:10:11 +0200
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
Message-ID: <C52AD55D-81AD-447E-A8D2-3C74F5B97092@oracle.com>



> On 19 Jun 2018, at 23:00, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> Please always include build-dev when reviewing build changes.
> 
> In general this looks pretty good but there are some details that need fixing.
> 
> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)

Yes, the updategraalinopenjdk command[1] can be modified in anyway seen fit to make Graal a better citizen when copied to JDK. It would also be ok to add the jtreg commands in test source headers.

-Doug

[1] https://github.com/oracle/graal/blob/27288e546392f44ebf8107795647e0db155faf38/compiler/mx.compiler/mx_compiler.py#L1161

> 
> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>> Hi All,
>> 
>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>> 
>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>> 
> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
> 
> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
> 
> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
> 
> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/... Please create a suitable sub directory there for the output from this makefile.
> 
> The all and test-image targets are never called so no need to declare them.
> 
> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
> * 43 logic indent 2 spaces
> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
> * 58 continuation indent 4 spaces
> * 88, 89 please break long lines
> * 90 continuation indent 4 spaces
> * 99 continuation indent 4 spaces
> * 120 break before ))
>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>> 
> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
> 
> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>> 
> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
> 
> /Erik
>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>> 
>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>> 
>> 
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>  webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>> testing: new tests were executed as part of automatic HS testing for several months.
>> 
>> 
>> thanks,
>> -katya
>> 
>> p.s.
>>  Igor Ignatyev volunteered to sponsor this change. 
> 



From erik.joelsson at oracle.com  Tue Jun 19 21:27:14 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 19 Jun 2018 14:27:14 -0700
Subject: RFR: JDK-8200115: System property java.vm.vendor value includes
 quotation marks
Message-ID: <b4252fd7-22d0-57e7-57c5-58a998ae1a4f@oracle.com>

Hello,

Since JDK-8189761, the java.vm.vendor string for an OracleJDK build 
contains quotation marks. This would also be true for any other build of 
OpenJDK where the user set the --with-vendor-name configure option.

I found the culprit of this to be the combination of the build setting 
the preprocessor flag as -DVENDOR='"value"' (double quotes inside single 
quotes) and vm_version.cpp using the XSTR macro to convert the value of 
VENDOR into a C string. The -DVENDOR argument is also given to libjava, 
where System.c does not apply a similar conversion, so it requires the 
double quotes to be supplied on the command line.

I found the simplest solution for unifying the behavior between libjvm 
and libjava to be to remove the XSTR macro call in vm_version.cpp.

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

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

Testing: mach5 tier1

/Erik



From tim.bell at oracle.com  Tue Jun 19 21:40:58 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 19 Jun 2018 14:40:58 -0700
Subject: RFR: JDK-8200115: System property java.vm.vendor value includes
 quotation marks
In-Reply-To: <b4252fd7-22d0-57e7-57c5-58a998ae1a4f@oracle.com>
References: <b4252fd7-22d0-57e7-57c5-58a998ae1a4f@oracle.com>
Message-ID: <5B29786A.8020007@oracle.com>

Erik:

> Since JDK-8189761, the java.vm.vendor string for an OracleJDK build
> contains quotation marks. This would also be true for any other build of
> OpenJDK where the user set the --with-vendor-name configure option.
>
> I found the culprit of this to be the combination of the build setting
> the preprocessor flag as -DVENDOR='"value"' (double quotes inside single
> quotes) and vm_version.cpp using the XSTR macro to convert the value of
> VENDOR into a C string. The -DVENDOR argument is also given to libjava,
> where System.c does not apply a similar conversion, so it requires the
> double quotes to be supplied on the command line.
>
> I found the simplest solution for unifying the behavior between libjvm
> and libjava to be to remove the XSTR macro call in vm_version.cpp.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189761

Er ... the follow-on bug report is:
    https://bugs.openjdk.java.net/browse/JDK-8200115

> Webrev: http://cr.openjdk.java.net/~erikj/8200115/webrev.01/
>
> Testing: mach5 tier1

Looks good.

/Tim



From abhijit_saha at hotmail.com  Tue Jun 19 22:04:01 2018
From: abhijit_saha at hotmail.com (Abhijit Saha)
Date: Tue, 19 Jun 2018 22:04:01 +0000
Subject: RFR: JDK-8200115: System property java.vm.vendor value includes
 quotation marks
In-Reply-To: <5B29786A.8020007@oracle.com>
References: <b4252fd7-22d0-57e7-57c5-58a998ae1a4f@oracle.com>
 <5B29786A.8020007@oracle.com>
Message-ID: <CO2PR04MB221474343A77E45053F93616FE700@CO2PR04MB2214.namprd04.prod.outlook.com>



> On Jun 19, 2018, at 2:40 PM, Tim Bell <tim.bell at oracle.com> wrote:
> 
> Erik:
> 
>> Since JDK-8189761, the java.vm.vendor string for an OracleJDK build
>> contains quotation marks. This would also be true for any other build of
>> OpenJDK where the user set the --with-vendor-name configure option.
>> 
>> I found the culprit of this to be the combination of the build setting
>> the preprocessor flag as -DVENDOR='"value"' (double quotes inside single
>> quotes) and vm_version.cpp using the XSTR macro to convert the value of
>> VENDOR into a C string. The -DVENDOR argument is also given to libjava,
>> where System.c does not apply a similar conversion, so it requires the
>> double quotes to be supplied on the command line.
>> 
>> I found the simplest solution for unifying the behavior between libjvm
>> and libjava to be to remove the XSTR macro call in vm_version.cpp.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189761
> 
> Er ... the follow-on bug report is:
>   https://bugs.openjdk.java.net/browse/JDK-8200115
> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8200115/webrev.01/

Looks good to me too.

/Abhijit

>> 
>> Testing: mach5 tier1
> 
> Looks good.
> 
> /Tim
> 



From thomas.stuefe at gmail.com  Wed Jun 20 08:00:36 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jun 2018 10:00:36 +0200
Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
Message-ID: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>

Hi all,

May I please have reviews for this small build fix?

https://bugs.openjdk.java.net/browse/JDK-8205407
http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/

In short, we need to disable C4800 for the JVM build as well since 8203197.

Thank you,

Thomas


From thomas.stuefe at gmail.com  Wed Jun 20 13:40:10 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jun 2018 15:40:10 +0200
Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
In-Reply-To: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
References: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
Message-ID: <CAA-vtUyVxxfNAYTqoxWtdRd67vzNiRq+zNVgzUHoEaWyB_QtiA@mail.gmail.com>

jdk-submit ran through without errors.

Anyone?

Plus, do you agree this falls under the trivial rule?

Thanks, Thomas

On Wed, Jun 20, 2018 at 10:00 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi all,
>
> May I please have reviews for this small build fix?
>
> https://bugs.openjdk.java.net/browse/JDK-8205407
> http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/
>
> In short, we need to disable C4800 for the JVM build as well since 8203197.
>
> Thank you,
>
> Thomas


From tim.bell at oracle.com  Wed Jun 20 13:48:01 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 20 Jun 2018 06:48:01 -0700
Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
In-Reply-To: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
References: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
Message-ID: <5B2A5B11.9070802@oracle.com>

Thomas:

> May I please have reviews for this small build fix?
>
> https://bugs.openjdk.java.net/browse/JDK-8205407
> http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/
>
> In short, we need to disable C4800 for the JVM build as well since 8203197.

Looks good.

Tim




From thomas.stuefe at gmail.com  Wed Jun 20 13:49:42 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jun 2018 15:49:42 +0200
Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
In-Reply-To: <5B2A5B11.9070802@oracle.com>
References: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
 <5B2A5B11.9070802@oracle.com>
Message-ID: <CAA-vtUzTOC5OyVGkxH3x4PhfyRnZNr=oubHg+maCpNEbHsdQSQ@mail.gmail.com>

Thanks Tim.


On Wed, Jun 20, 2018 at 3:48 PM, Tim Bell <tim.bell at oracle.com> wrote:
> Thomas:
>
>> May I please have reviews for this small build fix?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8205407
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-c4800/webrev.00/webrev/
>>
>> In short, we need to disable C4800 for the JVM build as well since
>> 8203197.
>
>
> Looks good.
>
> Tim
>
>


From matthias.baesken at sap.com  Wed Jun 20 15:00:13 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 20 Jun 2018 15:00:13 +0000
Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
In-Reply-To: <CAA-vtUw_A3A=BdH0gPuqw5N_aSYXAPtW48ru=M=j-oYBpjD5-w@mail.gmail.com>
References: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
 <CAA-vtUw_A3A=BdH0gPuqw5N_aSYXAPtW48ru=M=j-oYBpjD5-w@mail.gmail.com>
Message-ID: <614c562dc7d949c49b8f2533272aefd6@sap.com>

Hi  Thomas , looks good  (however I am not a Reviewer) !


> From: Thomas St?fe <thomas.stuefe at gmail.com>
> Date: Wed, Jun 20, 2018 at 10:00 AM
> Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
> To: build-dev <build-dev at openjdk.java.net>
> 
> 
> Hi all,
> 
> May I please have reviews for this small build fix?
> 
> https://bugs.openjdk.java.net/browse/JDK-8205407
> http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-
> c4800/webrev.00/webrev/
> 
> In short, we need to disable C4800 for the JVM build as well since 8203197.
> 
> Thank you,
> 
> Thomas

From thomas.stuefe at gmail.com  Wed Jun 20 15:10:22 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jun 2018 17:10:22 +0200
Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
In-Reply-To: <614c562dc7d949c49b8f2533272aefd6@sap.com>
References: <CAA-vtUxurqukHNzXE25D_c7TDj3hvLHHeBfHcJ+B_Fkw7o_5Rw@mail.gmail.com>
 <CAA-vtUw_A3A=BdH0gPuqw5N_aSYXAPtW48ru=M=j-oYBpjD5-w@mail.gmail.com>
 <614c562dc7d949c49b8f2533272aefd6@sap.com>
Message-ID: <CAA-vtUyO=AgRcYJf1sE1h1i8PnMWTB3g4DGQW6T-BD0Xidt8uw@mail.gmail.com>

Yes, but you are a Committer, so that is fine in this case, since we
have two Reviewers already :)

Thank you! I'll push now.

..Thomas

On Wed, Jun 20, 2018 at 5:00 PM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> Hi  Thomas , looks good  (however I am not a Reviewer) !
>
>
>> From: Thomas St?fe <thomas.stuefe at gmail.com>
>> Date: Wed, Jun 20, 2018 at 10:00 AM
>> Subject: RFR(xxs): 8205407: [windows, vs<2017] C4800 after 8203197
>> To: build-dev <build-dev at openjdk.java.net>
>>
>>
>> Hi all,
>>
>> May I please have reviews for this small build fix?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8205407
>> http://cr.openjdk.java.net/~stuefe/webrevs/8205497-windows-
>> c4800/webrev.00/webrev/
>>
>> In short, we need to disable C4800 for the JVM build as well since 8203197.
>>
>> Thank you,
>>
>> Thomas


From bsrbnd at gmail.com  Wed Jun 20 16:01:18 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 20 Jun 2018 18:01:18 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <DB7PR08MB3115DB4E83915356F88AA1A696770@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
 <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
 <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
 <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
 <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com>
 <CD051513-A64A-4DB1-B515-9E2A1D24D03D@oracle.com>
 <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com>
 <EED7D257-F426-4F86-9869-E26A9DF0E4FB@oracle.com>
 <CAEgw74CjmBoOQhx7VDx8AZ-dd5AecF29YvUVbHN3SR5Mpkq-hA@mail.gmail.com>
 <FCE26F92-7BCC-4CC8-9B1C-51EBA23BD6A3@oracle.com>
 <CAEgw74BYg8h+pLt_KWB0d6JuQ_6Gsr4fhcp+GJhawQM8OpDERA@mail.gmail.com>
 <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com>
 <CAEgw74DP8bP-Jf6n4MzYSo5rqpw2=GL7+_7aXNp=781yOwhxYA@mail.gmail.com>
 <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com>
 <CAEgw74Cch2r_oeUnbZcB5Lp+eQ4G0jUHDLuBqiaaZQoiM8ZpvQ@mail.gmail.com>
 <CAEgw74ASZxM8zRuBaqN_3awwKMv84EncPsoGeGBgWoDaFp_y6g@mail.gmail.com>
 <CAEgw74CL28T5UqTq2b7NsNKGyB1=+dZ+s5icz8SEcyKf8H9yMA@mail.gmail.com>
 <CAF82E1C-2DA2-4022-8C83-7DA49CBE6107@oracle.com>
 <CACO5V=bs0St3+HBVmKMBhT0OFo3fKm1D8rfP_V4DxWB1Dd08hQ@mail.gmail.com>
 <DB7PR08MB3115DB4E83915356F88AA1A696770@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <CAEgw74BRUB-+XSaWjpzb4+UWF5v_WS1VYQ6ZeGYnQkFtG+5mkw@mail.gmail.com>

Hi Pengfei,

On 20 June 2018 at 12:08, Pengfei Li <Pengfei.Li at arm.com> wrote:
> Hi
>
> I have tried the patch ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html ) on Ubuntu 18.04 machines (x86_64 & aarch64) with glibc=2.26.1 and build is OK.
>
> There's a small issue within the following code in src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
> Unlike readdir_r(), readdir() does not return int value. The value of res is always 0 before #ifdef.
>
>  727     /* EINTR not listed as a possible error */
>  728     errno = 0;
>  729     ptr = readdir64(dirp);
>  730     res = errno;
>  731
>  732 #ifdef _AIX
>  733     /* On AIX, readdir() returns EBADF (i.e. '9') and sets 'result' to NULL for the */
>  734     /* directory stream end. Otherwise, 'errno' will contain the error code. */
>  735     if (res != 0) {
>  736         res = (ptr == NULL && res == EBADF) ? 0 : errno;
>  737     }
>  738 #endif
>
> May I know that if this core-libs change going to be merged recently, or more platforms needs to be explored?
>
> --
> Thanks,
> Pengfei

Thanks for evaluating this patch, 'readdir()' doesn't return an 'int'
value but it sets 'errno' instead which is then assigned to 'res'.
So, I guess the fix is OK, or did I miss anything?

I've also tested it on Linux/x86_64 but ideally, the patch should be
tested on all supported POSIX platforms before being integrated.
The JBS issue [1] doesn't mention any fix version, so I'm not sure if
it'll be targeted to 11 or 12.

But if someone is available to test it on other POSIX platforms and
review it, this would be nice?

Thanks,
Bernard

[1] https://bugs.openjdk.java.net/browse/JDK-8202794


From erik.joelsson at oracle.com  Wed Jun 20 16:07:31 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 09:07:31 -0700
Subject: RFR: JDK-8205424: Change to Xcode 9.4 for building on Macosx at Oracle
Message-ID: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>

It's time for Oracle to change the official compiler used for building 
OpenJDK on Macosx. The new version will be 9.4 and the build will happen 
on Macosx 10.13(.4).

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

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

/Erik



From tim.bell at oracle.com  Wed Jun 20 17:00:07 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 20 Jun 2018 10:00:07 -0700
Subject: RFR: JDK-8205424: Change to Xcode 9.4 for building on Macosx
 at Oracle
In-Reply-To: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
References: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
Message-ID: <5B2A8817.7020205@oracle.com>

Erik:

> It's time for Oracle to change the official compiler used for building
> OpenJDK on Macosx. The new version will be 9.4 and the build will happen
> on Macosx 10.13(.4).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
>
> Webrev: http://cr.openjdk.java.net/~erikj/8205424/webrev.01/

Looks good.

/Tim



From philip.race at oracle.com  Wed Jun 20 17:09:37 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 20 Jun 2018 10:09:37 -0700
Subject: RFR: JDK-8205424: Change to Xcode 9.4 for building on Macosx at
 Oracle
In-Reply-To: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
References: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
Message-ID: <a5a16750-f601-8259-8902-7e3c8de785ea@oracle.com>

Looks fine.

-phil.

On 06/20/2018 09:07 AM, Erik Joelsson wrote:
> It's time for Oracle to change the official compiler used for building 
> OpenJDK on Macosx. The new version will be 9.4 and the build will 
> happen on Macosx 10.13(.4).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
>
> Webrev: http://cr.openjdk.java.net/~erikj/8205424/webrev.01/
>
> /Erik
>



From Sergey.Bylokhov at oracle.com  Wed Jun 20 18:10:31 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 20 Jun 2018 11:10:31 -0700
Subject: RFR: JDK-8205424: Change to Xcode 9.4 for building on Macosx at
 Oracle
In-Reply-To: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
References: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
Message-ID: <a918a7c3-20d1-4e6c-4ee7-2d7eccba94ed@oracle.com>

Hi, Erik.
Can you please clarify what will be minimum supported versions(macOS,xcode)?

On 20/06/2018 09:07, Erik Joelsson wrote:
> It's time for Oracle to change the official compiler used for building 
> OpenJDK on Macosx. The new version will be 9.4 and the build will happen 
> on Macosx 10.13(.4).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8205424/webrev.01/
> 
> /Erik
> 


-- 
Best regards, Sergey.


From erik.joelsson at oracle.com  Wed Jun 20 22:13:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 15:13:09 -0700
Subject: RFR: JDK-8205424: Change to Xcode 9.4 for building on Macosx at
 Oracle
In-Reply-To: <a918a7c3-20d1-4e6c-4ee7-2d7eccba94ed@oracle.com>
References: <f484ab98-f387-3acd-ce0d-8f8a695321ab@oracle.com>
 <a918a7c3-20d1-4e6c-4ee7-2d7eccba94ed@oracle.com>
Message-ID: <6c76d0ad-180b-d716-81a2-b6c4cf5f15b4@oracle.com>

On 2018-06-20 11:10, Sergey Bylokhov wrote:
> Hi, Erik.
> Can you please clarify what will be minimum supported 
> versions(macOS,xcode)?
>
Older versions of Xcode installed on local machines will likely continue 
to work for a while, as long as the community supports it.

Xcode 9.4 has 10.13.4 listed as minimum version of Macos to run. The 
devkit may still work on 10.12, since 9.2 worked there, but I have not 
tested it and don't have access to such a machine to try it either.

/Erik
> On 20/06/2018 09:07, Erik Joelsson wrote:
>> It's time for Oracle to change the official compiler used for 
>> building OpenJDK on Macosx. The new version will be 9.4 and the build 
>> will happen on Macosx 10.13(.4).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205424
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8205424/webrev.01/
>>
>> /Erik
>>
>
>



From martinrb at google.com  Wed Jun 20 23:03:13 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Jun 2018 16:03:13 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
Message-ID: <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>

Hi David and build-dev folk,

After way too much build/hotspot hacking, I have a better fix:

clang inlined os::current_stack_pointer into its caller __in the same
translation unit___ (that could be fixed in a separate change) so of course
in this case it didn't have to follow the ABI.  Fix is obvious in hindsight:

-address os::current_stack_pointer() {
+NOINLINE address os::current_stack_pointer() {

While working on this I noticed that the clang stack alignment flags on
Linux are missing.  They should be moved from a macosx-specific check to a
clang-specific check.  macosx is not synonymous with clang!

--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -470,6 +470,14 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
     # COMMON to gcc and clang
     TOOLCHAIN_CFLAGS_JVM="-pipe -fno-rtti -fno-exceptions \
         -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer"
+
+    if test "x$TOOLCHAIN_TYPE" = xclang; then
+      # In principle the stack alignment below is cpu- and ABI-dependent
and
+      # should agree with values of StackAlignmentInBytes in various
+      # src/hotspot/cpu/*/globalDefinitions_*.hpp files, but this value
+      # currently works for all platforms.
+      TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM
-mno-omit-leaf-frame-pointer -mstack-alignment=16"
+    fi
   fi

   if test "x$TOOLCHAIN_TYPE" = xgcc; then
@@ -601,10 +609,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
     fi
   fi

-  if test "x$OPENJDK_TARGET_OS" = xmacosx; then
-    OS_CFLAGS_JVM="$OS_CFLAGS_JVM -mno-omit-leaf-frame-pointer
-mstack-alignment=16"
-  fi
-
   # Optional POSIX functionality needed by the JVM
   #
   # Check if clock_gettime is available and in which library. This
indicates


8186780: clang-4.0 fastdebug assertion failure in
os_linux_x86:os::verify_stack_alignment()
http://cr.openjdk.java.net/~martin/webrevs/jdk/clang-stack-alignment/
https://bugs.openjdk.java.net/browse/JDK-8186780

On Wed, Jun 20, 2018 at 12:30 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Martin,
>
>
> On 20/06/2018 3:03 AM, Martin Buchholz wrote:
>
>> (There's surely a better fix that involves refactoring os/cpu/compiler
>> support)
>>
>> 8186780: clang-4.0 fastdebug assertion failure in
>> os_linux_x86:os::verify_stack_alignment()
>> http://cr.openjdk.java.net/~martin/webrevs/jdk/clang-verify_
>> stack_alignment/
>> https://bugs.openjdk.java.net/browse/JDK-8186780
>>
>
> I remain concerned about what it may mean for the stack pointer to not be
> aligned. I would have thought stack pointer alignment was part of the ABI
> for a CPU architecture, not something the compiler could choose at will?
> What about all the other code that uses StackAlignmentInBytes ??
>
> That aside your fix excludes the assert when building with clang for linux
> x86 as intended. And I see that for BSD x86 (where we also use clang) that
> verify_stack_alignment is empty.
>
> Thanks,
> David
>


From erik.joelsson at oracle.com  Wed Jun 20 23:19:06 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 16:19:06 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
Message-ID: <e3df8a9b-49a1-2d65-09bd-b9b5bc2d9eda@oracle.com>

Hello,

It's very probable that we have made several such mistakes with our 
flags, since for the most part, we have a 1-1 mapping of compiler and 
OS. We certainly appreciate correcting this whenever possible. I don't 
have the expertise to verify your claim here, but I will take your word 
for it.

The change looks ok, but there is already a big block of clang specific 
stuff close by. Perhaps move this assignment there?

/Erik


On 2018-06-20 16:03, Martin Buchholz wrote:
> Hi David and build-dev folk,
>
> After way too much build/hotspot hacking, I have a better fix:
>
> clang inlined os::current_stack_pointer into its caller __in the same
> translation unit___ (that could be fixed in a separate change) so of course
> in this case it didn't have to follow the ABI.  Fix is obvious in hindsight:
>
> -address os::current_stack_pointer() {
> +NOINLINE address os::current_stack_pointer() {
>
> While working on this I noticed that the clang stack alignment flags on
> Linux are missing.  They should be moved from a macosx-specific check to a
> clang-specific check.  macosx is not synonymous with clang!
>
> --- a/make/autoconf/flags-cflags.m4
> +++ b/make/autoconf/flags-cflags.m4
> @@ -470,6 +470,14 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
>       # COMMON to gcc and clang
>       TOOLCHAIN_CFLAGS_JVM="-pipe -fno-rtti -fno-exceptions \
>           -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer"
> +
> +    if test "x$TOOLCHAIN_TYPE" = xclang; then
> +      # In principle the stack alignment below is cpu- and ABI-dependent
> and
> +      # should agree with values of StackAlignmentInBytes in various
> +      # src/hotspot/cpu/*/globalDefinitions_*.hpp files, but this value
> +      # currently works for all platforms.
> +      TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM
> -mno-omit-leaf-frame-pointer -mstack-alignment=16"
> +    fi
>     fi
>
>     if test "x$TOOLCHAIN_TYPE" = xgcc; then
> @@ -601,10 +609,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
>       fi
>     fi
>
> -  if test "x$OPENJDK_TARGET_OS" = xmacosx; then
> -    OS_CFLAGS_JVM="$OS_CFLAGS_JVM -mno-omit-leaf-frame-pointer
> -mstack-alignment=16"
> -  fi
> -
>     # Optional POSIX functionality needed by the JVM
>     #
>     # Check if clock_gettime is available and in which library. This
> indicates
>
>
> 8186780: clang-4.0 fastdebug assertion failure in
> os_linux_x86:os::verify_stack_alignment()
> http://cr.openjdk.java.net/~martin/webrevs/jdk/clang-stack-alignment/
> https://bugs.openjdk.java.net/browse/JDK-8186780
>
> On Wed, Jun 20, 2018 at 12:30 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>>
>> On 20/06/2018 3:03 AM, Martin Buchholz wrote:
>>
>>> (There's surely a better fix that involves refactoring os/cpu/compiler
>>> support)
>>>
>>> 8186780: clang-4.0 fastdebug assertion failure in
>>> os_linux_x86:os::verify_stack_alignment()
>>> http://cr.openjdk.java.net/~martin/webrevs/jdk/clang-verify_
>>> stack_alignment/
>>> https://bugs.openjdk.java.net/browse/JDK-8186780
>>>
>> I remain concerned about what it may mean for the stack pointer to not be
>> aligned. I would have thought stack pointer alignment was part of the ABI
>> for a CPU architecture, not something the compiler could choose at will?
>> What about all the other code that uses StackAlignmentInBytes ??
>>
>> That aside your fix excludes the assert when building with clang for linux
>> x86 as intended. And I see that for BSD x86 (where we also use clang) that
>> verify_stack_alignment is empty.
>>
>> Thanks,
>> David
>>



From martinrb at google.com  Wed Jun 20 23:30:52 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Jun 2018 16:30:52 -0700
Subject: THIS_FILE
Message-ID: <CA+kOe0-gyk3v=RnjYyi0ErSXf4Jo3+u0gMOBF_QF0in1yDVKyA@mail.gmail.com>

While exploring the *.cmdline files created by the build (thank you, those
are very helpful!) I noticed that they all contain

 -DTHIS_FILE='""'

Probably there should be an actual file name there.


From erik.joelsson at oracle.com  Wed Jun 20 23:36:45 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 16:36:45 -0700
Subject: THIS_FILE
In-Reply-To: <CA+kOe0-gyk3v=RnjYyi0ErSXf4Jo3+u0gMOBF_QF0in1yDVKyA@mail.gmail.com>
References: <CA+kOe0-gyk3v=RnjYyi0ErSXf4Jo3+u0gMOBF_QF0in1yDVKyA@mail.gmail.com>
Message-ID: <1cc95d85-b420-5d72-09f1-f04015208ae1@oracle.com>

That certainly looks like a bug. That macro was added to try to get rid 
of the __FILE__ macro in the source code. Using __FILE__ and __DATE__ 
makes it hard to achieve fully reproducible builds where we can verify 
build changes by simply comparing the output files.

/Erik


On 2018-06-20 16:30, Martin Buchholz wrote:
> While exploring the *.cmdline files created by the build (thank you, those
> are very helpful!) I noticed that they all contain
>
>   -DTHIS_FILE='""'
>
> Probably there should be an actual file name there.



From martinrb at google.com  Wed Jun 20 23:39:14 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Jun 2018 16:39:14 -0700
Subject: clang and -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc
Message-ID: <CA+kOe094VsX=Udb2UdKiyZ=_zquon=aQFGNuHvD1xrmNdH1=4g@mail.gmail.com>

I saw in the *.cmdline files that when I build with clang, we get these
defines:
 -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc

I see now that -DTARGET_COMPILER_gcc was intentional

  HOTSPOT_TOOLCHAIN_TYPE=$TOOLCHAIN_TYPE
  if test "x$TOOLCHAIN_TYPE" = xclang; then
    HOTSPOT_TOOLCHAIN_TYPE=gcc

but it's very confusing and isn't used in too many places, so should be
fixed.


From erik.joelsson at oracle.com  Wed Jun 20 23:41:22 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 16:41:22 -0700
Subject: THIS_FILE
In-Reply-To: <1cc95d85-b420-5d72-09f1-f04015208ae1@oracle.com>
References: <CA+kOe0-gyk3v=RnjYyi0ErSXf4Jo3+u0gMOBF_QF0in1yDVKyA@mail.gmail.com>
 <1cc95d85-b420-5d72-09f1-f04015208ae1@oracle.com>
Message-ID: <b83650c2-37fa-272e-0fb1-217ccfd9022a@oracle.com>

Filed https://bugs.openjdk.java.net/browse/JDK-8205451

/Erik


On 2018-06-20 16:36, Erik Joelsson wrote:
> That certainly looks like a bug. That macro was added to try to get 
> rid of the __FILE__ macro in the source code. Using __FILE__ and 
> __DATE__ makes it hard to achieve fully reproducible builds where we 
> can verify build changes by simply comparing the output files.
>
> /Erik
>
>
> On 2018-06-20 16:30, Martin Buchholz wrote:
>> While exploring the *.cmdline files created by the build (thank you, 
>> those
>> are very helpful!) I noticed that they all contain
>>
>> ? -DTHIS_FILE='""'
>>
>> Probably there should be an actual file name there.
>



From erik.joelsson at oracle.com  Wed Jun 20 23:43:38 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 16:43:38 -0700
Subject: clang and -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc
In-Reply-To: <CA+kOe094VsX=Udb2UdKiyZ=_zquon=aQFGNuHvD1xrmNdH1=4g@mail.gmail.com>
References: <CA+kOe094VsX=Udb2UdKiyZ=_zquon=aQFGNuHvD1xrmNdH1=4g@mail.gmail.com>
Message-ID: <de1156e8-29a7-7ee2-0aa7-5a6ce41c85d0@oracle.com>

I agree. This looks like a good example of legacy hotspot build settings 
that we just translated as they were from the old hotspot build system.

/Erik


On 2018-06-20 16:39, Martin Buchholz wrote:
> I saw in the *.cmdline files that when I build with clang, we get these
> defines:
>   -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc
>
> I see now that -DTARGET_COMPILER_gcc was intentional
>
>    HOTSPOT_TOOLCHAIN_TYPE=$TOOLCHAIN_TYPE
>    if test "x$TOOLCHAIN_TYPE" = xclang; then
>      HOTSPOT_TOOLCHAIN_TYPE=gcc
>
> but it's very confusing and isn't used in too many places, so should be
> fixed.



From martinrb at google.com  Wed Jun 20 23:49:46 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Jun 2018 16:49:46 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <e3df8a9b-49a1-2d65-09bd-b9b5bc2d9eda@oracle.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <e3df8a9b-49a1-2d65-09bd-b9b5bc2d9eda@oracle.com>
Message-ID: <CA+kOe0-Vcav8dVaxb32UiZHRB9DQxR-fWy3RmsRzsQ9fLMA1fQ@mail.gmail.com>

Thanks Erik.

On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello,
>
> It's very probable that we have made several such mistakes with our flags,
> since for the most part, we have a 1-1 mapping of compiler and OS. We
> certainly appreciate correcting this whenever possible. I don't have the
> expertise to verify your claim here, but I will take your word for it.
>
> The change looks ok, but there is already a big block of clang specific
> stuff close by. Perhaps move this assignment there?


Yes, that does look like a better place:

 --- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -470,14 +470,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
     # COMMON to gcc and clang
     TOOLCHAIN_CFLAGS_JVM="-pipe -fno-rtti -fno-exceptions \
         -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer"
-
-    if test "x$TOOLCHAIN_TYPE" = xclang; then
-      # In principle the stack alignment below is cpu- and ABI-dependent
and
-      # should agree with values of StackAlignmentInBytes in various
-      # src/hotspot/cpu/*/globalDefinitions_*.hpp files, but this value
-      # currently works for all platforms.
-      TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM
-mno-omit-leaf-frame-pointer -mstack-alignment=16"
-    fi
   fi

   if test "x$TOOLCHAIN_TYPE" = xgcc; then
@@ -499,6 +491,12 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
     # (see http://llvm.org/bugs/show_bug.cgi?id=7554)
     TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -flimit-debug-info"

+    # In principle the stack alignment below is cpu- and ABI-dependent and
+    # should agree with values of StackAlignmentInBytes in various
+    # src/hotspot/cpu/*/globalDefinitions_*.hpp files, but this value
+    # currently works for all platforms.
+    TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM
-mno-omit-leaf-frame-pointer -mstack-alignment=16"
+
     if test "x$OPENJDK_TARGET_OS" = xlinux; then
       TOOLCHAIN_CFLAGS_JDK="-pipe"
       TOOLCHAIN_CFLAGS_JDK_CONLY="-fno-strict-aliasing" # technically NOT
for CXX


From erik.joelsson at oracle.com  Wed Jun 20 23:54:29 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 20 Jun 2018 16:54:29 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe0-Vcav8dVaxb32UiZHRB9DQxR-fWy3RmsRzsQ9fLMA1fQ@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <e3df8a9b-49a1-2d65-09bd-b9b5bc2d9eda@oracle.com>
 <CA+kOe0-Vcav8dVaxb32UiZHRB9DQxR-fWy3RmsRzsQ9fLMA1fQ@mail.gmail.com>
Message-ID: <94d9950e-dfc8-156f-d0b9-965300ca43de@oracle.com>

Looks good to me.

/Erik


On 2018-06-20 16:49, Martin Buchholz wrote:
> Thanks Erik.
>
> On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson 
> <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>
>     Hello,
>
>     It's very probable that we have made several such mistakes with
>     our flags, since for the most part, we have a 1-1 mapping of
>     compiler and OS. We certainly appreciate correcting this whenever
>     possible. I don't have the expertise to verify your claim here,
>     but I will take your word for it.
>
>     The change looks ok, but there is already a big block of clang
>     specific stuff close by. Perhaps move this assignment there?
>
>
> Yes, that does look like a better place:
>
> ?--- a/make/autoconf/flags-cflags.m4
> +++ b/make/autoconf/flags-cflags.m4
> @@ -470,14 +470,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
> ? ? ?# COMMON to gcc and clang
> ? ? ?TOOLCHAIN_CFLAGS_JVM="-pipe -fno-rtti -fno-exceptions \
> ? ? ? ? ?-fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer"
> -
> -? ? if test "x$TOOLCHAIN_TYPE" = xclang; then
> -? ? ? # In principle the stack alignment below is cpu- and 
> ABI-dependent and
> -? ? ? # should agree with values of StackAlignmentInBytes in various
> -? ? ? # src/hotspot/cpu/*/globalDefinitions_*.hpp files, but this value
> -? ? ? # currently works for all platforms.
> -? ? ? TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM 
> -mno-omit-leaf-frame-pointer -mstack-alignment=16"
> -? ? fi
> ? ?fi
> ? ?if test "x$TOOLCHAIN_TYPE" = xgcc; then
> @@ -499,6 +491,12 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
> ? ? ?# (see http://llvm.org/bugs/show_bug.cgi?id=7554)
> ? ? ?TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -flimit-debug-info"
> +? ? # In principle the stack alignment below is cpu- and 
> ABI-dependent and
> +? ? # should agree with values of StackAlignmentInBytes in various
> +? ? # src/hotspot/cpu/*/globalDefinitions_*.hpp files, but this value
> +? ? # currently works for all platforms.
> +? ? TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM 
> -mno-omit-leaf-frame-pointer -mstack-alignment=16"
> +
> ? ? ?if test "x$OPENJDK_TARGET_OS" = xlinux; then
> ? ? ? ?TOOLCHAIN_CFLAGS_JDK="-pipe"
> ?TOOLCHAIN_CFLAGS_JDK_CONLY="-fno-strict-aliasing" # technically NOT 
> for CXX
>



From martinrb at google.com  Thu Jun 21 00:05:27 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Jun 2018 17:05:27 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
Message-ID: <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>

On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com>
wrote:

> Hi David and build-dev folk,
>
> After way too much build/hotspot hacking, I have a better fix:
>
> clang inlined os::current_stack_pointer into its caller __in the same
> translation unit___ (that could be fixed in a separate change) so of course
> in this case it didn't have to follow the ABI.  Fix is obvious in hindsight:
>
> -address os::current_stack_pointer() {
> +NOINLINE address os::current_stack_pointer() {
>

If y'all like the addition of NOINLINE, it should probably be added to all
of the 14 variants of  os::current_stack_pointer.
Gives me a chance to try out the submit repo.


From constatinus at gmail.com  Thu Jun 21 08:03:00 2018
From: constatinus at gmail.com (pilot constatinus)
Date: Thu, 21 Jun 2018 10:03:00 +0200
Subject: Openjdk build problem
Message-ID: <CAKZd3Gzf_gheH0rA7e508yro3KgFniyQGChT8ATMz1ke5rTG9g@mail.gmail.com>

Hi, i recently tried to compile openjdk 9. Fedora x86_64 28 gcc 8.1.1. I
think gcc is causing this problem. I did a default bash get_source.sh and
bash ./configure. Now make is the problem.

https://pastebin.com/VhmStrYP


From patrick at reini.net  Thu Jun 21 08:33:33 2018
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 21 Jun 2018 10:33:33 +0200
Subject: Openjdk build problem
In-Reply-To: <CAKZd3Gzf_gheH0rA7e508yro3KgFniyQGChT8ATMz1ke5rTG9g@mail.gmail.com>
References: <CAKZd3Gzf_gheH0rA7e508yro3KgFniyQGChT8ATMz1ke5rTG9g@mail.gmail.com>
Message-ID: <a48fce0a0d60c56a09e13045bc68f233@reini.net>

Hi Constaninus

See 
http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022427.html 
for a work-around and the follow up issue raised to solve it correctly.

-Patrick


On 2018-06-21 10:03, pilot constatinus wrote:
> Hi, i recently tried to compile openjdk 9. Fedora x86_64 28 gcc 8.1.1. 
> I
> think gcc is causing this problem. I did a default bash get_source.sh 
> and
> bash ./configure. Now make is the problem.
> 
> https://pastebin.com/VhmStrYP


From aph at redhat.com  Thu Jun 21 08:35:00 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Jun 2018 09:35:00 +0100
Subject: Openjdk build problem
In-Reply-To: <CAKZd3Gzf_gheH0rA7e508yro3KgFniyQGChT8ATMz1ke5rTG9g@mail.gmail.com>
References: <CAKZd3Gzf_gheH0rA7e508yro3KgFniyQGChT8ATMz1ke5rTG9g@mail.gmail.com>
Message-ID: <a80a622c-be3d-e02f-ee84-a25154e800c7@redhat.com>

On 06/21/2018 09:03 AM, pilot constatinus wrote:
> Hi, i recently tried to compile openjdk 9. Fedora x86_64 28 gcc 8.1.1. I
> think gcc is causing this problem. I did a default bash get_source.sh and
> bash ./configure. Now make is the problem.
> 
> https://pastebin.com/VhmStrYP

Configure with --disable-warnings-as-errors.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From glaubitz at physik.fu-berlin.de  Thu Jun 21 09:57:39 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 21 Jun 2018 11:57:39 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
Message-ID: <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>

Hi Fridrich!

Is this still an issue? Shall I open a bug report in JBS?

Adrian

On 06/15/2018 06:02 PM, Fridrich Strba wrote:
> Hello, Magnus,
> 
> Your original patch had a problem, since the second statement overwrote
> the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
> like osSupport.hpp, jawt_md.h and so on could not be found in build of
> tests. So, I modified your patch to read as attached and the build
> finished. It is basically a 2-liner.
> 
> Cheers
> 
> Fridrich
> 
> On 15/06/18 13:10, Magnus Ihse Bursie wrote:
>> Here's a better patch. Please try and see if it solves your problems.
>> Unfortunately, I'm leaving on vacation for today and will be gone most
>> of the summer, so I can't help sponsor this patch. But if it works, I'm
>> sure someone else can take over it.
>>
>> If it does not work, the original patch should at the very least be
>> changed so that EXTRA_HEADER_DIRS gets an additional "$(call
>> GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
>> hard to eradicate from the CFLAGS).

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From weijun.wang at oracle.com  Thu Jun 21 11:12:53 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 21 Jun 2018 19:12:53 +0800
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
Message-ID: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>

Please take a review on this change

  http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
   
and the release note at

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

The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.

Several notes:

1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.

2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.

3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.

4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.

Thanks
Max

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx



From david.holmes at oracle.com  Thu Jun 21 11:27:54 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 21 Jun 2018 21:27:54 +1000
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
Message-ID: <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>

On 21/06/2018 10:05 AM, Martin Buchholz wrote:
> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
> 
>     Hi David and build-dev folk,
> 
>     After way too much build/hotspot hacking, I have a better fix:
> 
>     clang inlined?os::current_stack_pointer into its caller __in the
>     same translation unit___ (that could be fixed in a separate change)
>     so of course in this case it didn't have to follow the ABI.? Fix is
>     obvious in hindsight:
> 
>     -address os::current_stack_pointer() {
>     +NOINLINE address os::current_stack_pointer() {
> 
> 
> If y'all like the addition of NOINLINE, it should probably be added to 
> all of the 14 variants of os::current_stack_pointer.
> Gives me a chance to try out the submit repo.

I can't help but think other platforms actually rely on it being inlined 
so that it really does return the stack pointer of the method calling 
os::current_stack_pointer!

David


From fridrich.strba at suse.com  Thu Jun 21 12:34:38 2018
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Thu, 21 Jun 2018 14:34:38 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
Message-ID: <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>

Yes, I have tested this consolidated version and it builds just fine for me.

Cheers

F.

On 21/06/18 11:57, John Paul Adrian Glaubitz wrote:
> Hi Fridrich!
> 
> Is this still an issue? Shall I open a bug report in JBS?
> 
> Adrian
> 
> On 06/15/2018 06:02 PM, Fridrich Strba wrote:
>> Hello, Magnus,
>>
>> Your original patch had a problem, since the second statement overwrote
>> the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
>> like osSupport.hpp, jawt_md.h and so on could not be found in build of
>> tests. So, I modified your patch to read as attached and the build
>> finished. It is basically a 2-liner.
>>
>> Cheers
>>
>> Fridrich
>>
>> On 15/06/18 13:10, Magnus Ihse Bursie wrote:
>>> Here's a better patch. Please try and see if it solves your problems.
>>> Unfortunately, I'm leaving on vacation for today and will be gone most
>>> of the summer, so I can't help sponsor this patch. But if it works, I'm
>>> sure someone else can take over it.
>>>
>>> If it does not work, the original patch should at the very least be
>>> changed so that EXTRA_HEADER_DIRS gets an additional "$(call
>>> GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
>>> hard to eradicate from the CFLAGS).
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: generated-headers.patch
Type: text/x-patch
Size: 718 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20180621/1c85f0a1/generated-headers.patch>

From thomas.stuefe at gmail.com  Thu Jun 21 12:37:21 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 21 Jun 2018 14:37:21 +0200
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
Message-ID: <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>

On Thu, Jun 21, 2018 at 1:27 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 21/06/2018 10:05 AM, Martin Buchholz wrote:
>>
>> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com
>> <mailto:martinrb at google.com>> wrote:
>>
>>     Hi David and build-dev folk,
>>
>>     After way too much build/hotspot hacking, I have a better fix:
>>
>>     clang inlined os::current_stack_pointer into its caller __in the
>>     same translation unit___ (that could be fixed in a separate change)
>>     so of course in this case it didn't have to follow the ABI.  Fix is
>>     obvious in hindsight:
>>
>>     -address os::current_stack_pointer() {
>>     +NOINLINE address os::current_stack_pointer() {
>>
>>
>> If y'all like the addition of NOINLINE, it should probably be added to all
>> of the 14 variants of os::current_stack_pointer.
>> Gives me a chance to try out the submit repo.
>
>
> I can't help but think other platforms actually rely on it being inlined so
> that it really does return the stack pointer of the method calling
> os::current_stack_pointer!
>

But we only inline today if caller is in the same translation unit and
builds with optimization, no?

..Thomas

> David


From Pengfei.Li at arm.com  Thu Jun 21 10:57:40 2018
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Thu, 21 Jun 2018 10:57:40 +0000
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <CAEgw74BRUB-+XSaWjpzb4+UWF5v_WS1VYQ6ZeGYnQkFtG+5mkw@mail.gmail.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
 <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
 <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
 <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
 <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com>
 <CD051513-A64A-4DB1-B515-9E2A1D24D03D@oracle.com>
 <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com>
 <EED7D257-F426-4F86-9869-E26A9DF0E4FB@oracle.com>
 <CAEgw74CjmBoOQhx7VDx8AZ-dd5AecF29YvUVbHN3SR5Mpkq-hA@mail.gmail.com>
 <FCE26F92-7BCC-4CC8-9B1C-51EBA23BD6A3@oracle.com>
 <CAEgw74BYg8h+pLt_KWB0d6JuQ_6Gsr4fhcp+GJhawQM8OpDERA@mail.gmail.com>
 <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com>
 <CAEgw74DP8bP-Jf6n4MzYSo5rqpw2=GL7+_7aXNp=781yOwhxYA@mail.gmail.com>
 <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com>
 <CAEgw74Cch2r_oeUnbZcB5Lp+eQ4G0jUHDLuBqiaaZQoiM8ZpvQ@mail.gmail.com>
 <CAEgw74ASZxM8zRuBaqN_3awwKMv84EncPsoGeGBgWoDaFp_y6g@mail.gmail.com>
 <CAEgw74CL28T5UqTq2b7NsNKGyB1=+dZ+s5icz8SEcyKf8H9yMA@mail.gmail.com>
 <CAF82E1C-2DA2-4022-8C83-7DA49CBE6107@oracle.com>
 <CACO5V=bs0St3+HBVmKMBhT0OFo3fKm1D8rfP_V4DxWB1Dd08hQ@mail.gmail.com>
 <DB7PR08MB3115DB4E83915356F88AA1A696770@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <CAEgw74BRUB-+XSaWjpzb4+UWF5v_WS1VYQ6ZeGYnQkFtG+5mkw@mail.gmail.com>
Message-ID: <DB7PR08MB3115167C661F74B6AA43520296760@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi Bernard,

Yes, your fix is good but would be nicer if the comment in line 733 is modified as well since it might be misleading.
>  733     /* On AIX, readdir() returns EBADF ...

I only have Linux machines to test. But I suggest that your patch being merged soon as the deprecated use breaks the build on many latest Linux distributions, and it's hard for guys to find other POSIX platforms in a short time.

--
Thanks,
Pengfei


-----Original Message-----
From: B. Blaser <bsrbnd at gmail.com> 
Sent: Thursday, June 21, 2018 00:01
To: Pengfei Li <Pengfei.Li at arm.com>
Cc: kim.barrett at oracle.com; core-libs-dev at openjdk.java.net; nd <nd at arm.com>; build-dev at openjdk.java.net
Subject: Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

Hi Pengfei,

On 20 June 2018 at 12:08, Pengfei Li <Pengfei.Li at arm.com> wrote:
> Hi
>
> I have tried the patch ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html ) on Ubuntu 18.04 machines (x86_64 & aarch64) with glibc=2.26.1 and build is OK.
>
> There's a small issue within the following code in 
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
> Unlike readdir_r(), readdir() does not return int value. The value of res is always 0 before #ifdef.
>
>  727     /* EINTR not listed as a possible error */
>  728     errno = 0;
>  729     ptr = readdir64(dirp);
>  730     res = errno;
>  731
>  732 #ifdef _AIX
>  733     /* On AIX, readdir() returns EBADF (i.e. '9') and sets 'result' to NULL for the */
>  734     /* directory stream end. Otherwise, 'errno' will contain the error code. */
>  735     if (res != 0) {
>  736         res = (ptr == NULL && res == EBADF) ? 0 : errno;
>  737     }
>  738 #endif
>
> May I know that if this core-libs change going to be merged recently, or more platforms needs to be explored?
>
> --
> Thanks,
> Pengfei

Thanks for evaluating this patch, 'readdir()' doesn't return an 'int'
value but it sets 'errno' instead which is then assigned to 'res'.
So, I guess the fix is OK, or did I miss anything?

I've also tested it on Linux/x86_64 but ideally, the patch should be tested on all supported POSIX platforms before being integrated.
The JBS issue [1] doesn't mention any fix version, so I'm not sure if it'll be targeted to 11 or 12.

But if someone is available to test it on other POSIX platforms and review it, this would be nice?

Thanks,
Bernard

[1] https://bugs.openjdk.java.net/browse/JDK-8202794

From xuelei.fan at oracle.com  Thu Jun 21 15:07:06 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 21 Jun 2018 08:07:06 -0700
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
Message-ID: <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>

Hi Weijun,

The release note and the following notes look reasonable to me.

For the implementation part, could it be a little bit more 
straightforward if wrapping the new attributes 
(pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, 
etc) in the PSS subclass?

Did you want to remove the debug code in the security.cpp?  It seems 
that they are not used any more.

Xuelei

On 6/21/2018 4:12 AM, Weijun Wang wrote:
> Please take a review on this change
> 
>    http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>     
> and the release note at
> 
>    https://bugs.openjdk.java.net/browse/JDK-8205471
> 
> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
> 
> Several notes:
> 
> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
> 
> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
> 
> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
> 
> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
> 
> Thanks
> Max
> 
> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx
> 


From weijun.wang at oracle.com  Thu Jun 21 15:23:21 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 21 Jun 2018 23:23:21 +0800
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
Message-ID: <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>



> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi Weijun,
> 
> The release note and the following notes look reasonable to me.
> 
> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?

Sounds good. I'll try it.

> 
> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.

Sure I can.

Thanks
Max

> 
> Xuelei
> 
> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>> Please take a review on this change
>>   http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>    and the release note at
>>   https://bugs.openjdk.java.net/browse/JDK-8205471
>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>> Several notes:
>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>> Thanks
>> Max
>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx



From erik.joelsson at oracle.com  Thu Jun 21 16:25:18 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 21 Jun 2018 09:25:18 -0700
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
Message-ID: <107535b7-5489-a2c9-0433-b25488fc42d3@oracle.com>

Build change looks good.

/Erik


On 2018-06-21 04:12, Weijun Wang wrote:
> Please take a review on this change
>
>    http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>     
> and the release note at
>
>    https://bugs.openjdk.java.net/browse/JDK-8205471
>
> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>
> Several notes:
>
> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>
> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>
> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>
> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>
> Thanks
> Max
>
> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx
>



From martinrb at google.com  Thu Jun 21 20:24:25 2018
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 Jun 2018 13:24:25 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
Message-ID: <CA+kOe0_e09juQ00uy1=J9hOwxFoV=sC64HCK5WqvDc_-MmOY5w@mail.gmail.com>

I see:

Don't use
  // os::current_stack_pointer(), as its result can be slightly below
current
  // stack pointer, causing us to not alloca enough to reach "bottom".

If you really really want to get the stack pointer of the current frame,
you can't put it in a function!  Use magic compiler extensions via a macro.

gcc and clang both have __builtin_frame_address(0).

gcc BUT not clang has
register uint64_t rsp asm ("rsp");
BUT that gives a slightly different value from __builtin_frame_address(0)
(different register? don't know much about x86 assembly)


On Thu, Jun 21, 2018 at 5:37 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> > On 21/06/2018 10:05 AM, Martin Buchholz wrote:
> >>
> >> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com
> >> <mailto:martinrb at google.com>> wrote:
> >>
> >>     Hi David and build-dev folk,
> >>
> >>     After way too much build/hotspot hacking, I have a better fix:
> >>
> >>     clang inlined os::current_stack_pointer into its caller __in the
> >>     same translation unit___ (that could be fixed in a separate change)
> >>     so of course in this case it didn't have to follow the ABI.  Fix is
> >>     obvious in hindsight:
> >>
> >>     -address os::current_stack_pointer() {
> >>     +NOINLINE address os::current_stack_pointer() {
> >>
> >>
> >> If y'all like the addition of NOINLINE, it should probably be added to
> all
> >> of the 14 variants of os::current_stack_pointer.
> >> Gives me a chance to try out the submit repo.
> >
> >
> > I can't help but think other platforms actually rely on it being inlined
> so
> > that it really does return the stack pointer of the method calling
> > os::current_stack_pointer!
> >
>
> But we only inline today if caller is in the same translation unit and
> builds with optimization, no?
>
> ..Thomas
>
> > David
>


From philip.race at oracle.com  Thu Jun 21 22:09:05 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 21 Jun 2018 15:09:05 -0700
Subject: RFR: 8205494: Convert or remove all AWT applet demos
Message-ID: <74cb2cc2-3118-07e4-a8a1-fb61eb5d4d3b@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8205494
Webrev : http://cr.openjdk.java.net/~prr/8205494/

This removes all the old 1990's vintage applet demos which can't be run 
anymore.
If any are interesting enough to turn into main programs then they can be
retrieved from the mercurial history or the arched OpenJDK10 forest.

-phil


From erik.joelsson at oracle.com  Thu Jun 21 23:04:55 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 21 Jun 2018 16:04:55 -0700
Subject: RFR: 8205494: Convert or remove all AWT applet demos
In-Reply-To: <74cb2cc2-3118-07e4-a8a1-fb61eb5d4d3b@oracle.com>
References: <74cb2cc2-3118-07e4-a8a1-fb61eb5d4d3b@oracle.com>
Message-ID: <c0a89db3-744f-a158-467b-0f68c4c82905@oracle.com>

Looks good.

/Erik


On 2018-06-21 15:09, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205494
> Webrev : http://cr.openjdk.java.net/~prr/8205494/
>
> This removes all the old 1990's vintage applet demos which can't be 
> run anymore.
> If any are interesting enough to turn into main programs then they can be
> retrieved from the mercurial history or the arched OpenJDK10 forest.
>
> -phil



From Sergey.Bylokhov at oracle.com  Thu Jun 21 23:39:09 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Jun 2018 16:39:09 -0700
Subject: RFR: 8205494: Convert or remove all AWT applet demos
In-Reply-To: <c0a89db3-744f-a158-467b-0f68c4c82905@oracle.com>
References: <74cb2cc2-3118-07e4-a8a1-fb61eb5d4d3b@oracle.com>
 <c0a89db3-744f-a158-467b-0f68c4c82905@oracle.com>
Message-ID: <2359c38a-9140-048a-d9e2-c9825795278a@oracle.com>

+1

On 21/06/2018 16:04, Erik Joelsson wrote:
> Looks good.
> 
> /Erik
> 
> 
> On 2018-06-21 15:09, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205494
>> Webrev : http://cr.openjdk.java.net/~prr/8205494/
>>
>> This removes all the old 1990's vintage applet demos which can't be 
>> run anymore.
>> If any are interesting enough to turn into main programs then they can be
>> retrieved from the mercurial history or the arched OpenJDK10 forest.
>>
>> -phil
> 


-- 
Best regards, Sergey.


From weijun.wang at oracle.com  Fri Jun 22 05:39:30 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 22 Jun 2018 13:39:30 +0800
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
Message-ID: <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>

Webrev updated at

  http://cr.openjdk.java.net/~weijun/8205445/webrev.01

I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.

BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.

Thanks
Max

> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> 
>> Hi Weijun,
>> 
>> The release note and the following notes look reasonable to me.
>> 
>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
> 
> Sounds good. I'll try it.
> 
>> 
>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
> 
> Sure I can.
> 
> Thanks
> Max
> 
>> 
>> Xuelei
>> 
>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>> Please take a review on this change
>>>  http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>   and the release note at
>>>  https://bugs.openjdk.java.net/browse/JDK-8205471
>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>> Several notes:
>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>> Thanks
>>> Max
>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx
> 



From glaubitz at physik.fu-berlin.de  Fri Jun 22 10:53:19 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 22 Jun 2018 12:53:19 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
 <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
Message-ID: <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>

Hi Fridrich!

On 06/21/2018 02:34 PM, Fridrich Strba wrote:
> Yes, I have tested this consolidated version and it builds just fine for me.
I have just verified that the problem exists on Debian unstable as well when
using the system headers for libjpeg and the other libraries. I can also
confirm that the patch you provided fixes the problem for me.

Now, before I create the bug report, do you happen to know which changeset
introduced the regression? We usually include that in the bug report.

And I also need to know whom to credit for the patch because of the several
backs and forths, I lost the overview.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From sgehwolf at redhat.com  Fri Jun 22 11:19:27 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 22 Jun 2018 13:19:27 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
 <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
 <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>
Message-ID: <61d15fe3ac5ddf12de11ae842c7a8e964afacc8f.camel@redhat.com>

On Fri, 2018-06-22 at 12:53 +0200, John Paul Adrian Glaubitz wrote:
> Hi Fridrich!
> 
> On 06/21/2018 02:34 PM, Fridrich Strba wrote:
> > Yes, I have tested this consolidated version and it builds just fine for me.
> 
> I have just verified that the problem exists on Debian unstable as well when
> using the system headers for libjpeg and the other libraries. I can also
> confirm that the patch you provided fixes the problem for me.
> 
> Now, before I create the bug report, do you happen to know which changeset
> introduced the regression? We usually include that in the bug report.

http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855

> And I also need to know whom to credit for the patch because of the several
> backs and forths, I lost the overview.

I'd propose:

Contributed-by: Magnuse Ihse Bursie <magnus.ihse.bursie at oracle.com>, Fridrich Strba <fridrich.strba at suse.com>

Thanks,
Severin


From glaubitz at physik.fu-berlin.de  Fri Jun 22 11:31:45 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 22 Jun 2018 13:31:45 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <61d15fe3ac5ddf12de11ae842c7a8e964afacc8f.camel@redhat.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
 <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
 <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>
 <61d15fe3ac5ddf12de11ae842c7a8e964afacc8f.camel@redhat.com>
Message-ID: <67fe9713-8836-e19c-bf52-87648fb501f5@physik.fu-berlin.de>

Hi Severin!

On 06/22/2018 01:19 PM, Severin Gehwolf wrote:
>> Now, before I create the bug report, do you happen to know which changeset
>> introduced the regression? We usually include that in the bug report.
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855
> 
>> And I also need to know whom to credit for the patch because of the several
>> backs and forths, I lost the overview.
> 
> I'd propose:
> 
> Contributed-by: Magnuse Ihse Bursie <magnus.ihse.bursie at oracle.com>, Fridrich Strba <fridrich.strba at suse.com>

Perfect, thank you!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From david.holmes at oracle.com  Fri Jun 22 11:57:08 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jun 2018 21:57:08 +1000
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
Message-ID: <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>

On 21/06/2018 10:37 PM, Thomas St?fe wrote:
> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 21/06/2018 10:05 AM, Martin Buchholz wrote:
>>>
>>> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com
>>> <mailto:martinrb at google.com>> wrote:
>>>
>>>      Hi David and build-dev folk,
>>>
>>>      After way too much build/hotspot hacking, I have a better fix:
>>>
>>>      clang inlined os::current_stack_pointer into its caller __in the
>>>      same translation unit___ (that could be fixed in a separate change)
>>>      so of course in this case it didn't have to follow the ABI.  Fix is
>>>      obvious in hindsight:
>>>
>>>      -address os::current_stack_pointer() {
>>>      +NOINLINE address os::current_stack_pointer() {
>>>
>>>
>>> If y'all like the addition of NOINLINE, it should probably be added to all
>>> of the 14 variants of os::current_stack_pointer.
>>> Gives me a chance to try out the submit repo.
>>
>>
>> I can't help but think other platforms actually rely on it being inlined so
>> that it really does return the stack pointer of the method calling
>> os::current_stack_pointer!
>>
> 
> But we only inline today if caller is in the same translation unit and
> builds with optimization, no?

Don't know, but Martin's encountering a case where it is being inlined - 
is that likely to be unique for some reason?

I never assume the compiler does the obvious these days :) or that there 
can't be clever link-time tricks as well.

Maybe the safest thing to do is to only make a change for the clang case 
and leave everything else alone.

David
-----

> 
> ..Thomas
> 
>> David


From xuelei.fan at oracle.com  Fri Jun 22 13:22:27 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 22 Jun 2018 06:22:27 -0700
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
 <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
Message-ID: <83db6a65-5c54-8764-a8ef-42b4edb9f581@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 6/21/2018 10:39 PM, Weijun Wang wrote:
> Webrev updated at
> 
>    http://cr.openjdk.java.net/~weijun/8205445/webrev.01
> 
> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.
> 
> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.
> 
> Thanks
> Max
> 
>> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>>
>>
>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> Hi Weijun,
>>>
>>> The release note and the following notes look reasonable to me.
>>>
>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
>>
>> Sounds good. I'll try it.
>>
>>>
>>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
>>
>> Sure I can.
>>
>> Thanks
>> Max
>>
>>>
>>> Xuelei
>>>
>>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>>> Please take a review on this change
>>>>   http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>>    and the release note at
>>>>   https://bugs.openjdk.java.net/browse/JDK-8205471
>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>>> Several notes:
>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>>> Thanks
>>>> Max
>>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx
>>
> 


From thomas.stuefe at gmail.com  Fri Jun 22 15:27:49 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 22 Jun 2018 17:27:49 +0200
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
 <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>
Message-ID: <CAA-vtUxUwBbgveX+iB_O0N6Dyd22qFhXJ6+RvOZDHcJKvrUmjw@mail.gmail.com>

On Fri, Jun 22, 2018 at 1:57 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 21/06/2018 10:37 PM, Thomas St?fe wrote:
>>
>> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> On 21/06/2018 10:05 AM, Martin Buchholz wrote:
>>>>
>>>>
>>>> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com
>>>> <mailto:martinrb at google.com>> wrote:
>>>>
>>>>      Hi David and build-dev folk,
>>>>
>>>>      After way too much build/hotspot hacking, I have a better fix:
>>>>
>>>>      clang inlined os::current_stack_pointer into its caller __in the
>>>>      same translation unit___ (that could be fixed in a separate change)
>>>>      so of course in this case it didn't have to follow the ABI.  Fix is
>>>>      obvious in hindsight:
>>>>
>>>>      -address os::current_stack_pointer() {
>>>>      +NOINLINE address os::current_stack_pointer() {
>>>>
>>>>
>>>> If y'all like the addition of NOINLINE, it should probably be added to
>>>> all
>>>> of the 14 variants of os::current_stack_pointer.
>>>> Gives me a chance to try out the submit repo.
>>>
>>>
>>>
>>> I can't help but think other platforms actually rely on it being inlined
>>> so
>>> that it really does return the stack pointer of the method calling
>>> os::current_stack_pointer!
>>>
>>
>> But we only inline today if caller is in the same translation unit and
>> builds with optimization, no?
>
>
> Don't know, but Martin's encountering a case where it is being inlined - is
> that likely to be unique for some reason?
>

Okay I may have confused myself.

My original reasoning was: A lot of calls to
os::current_stack_pointer() today happen not-inlined. That includes
calls from outside os_<os>_<cpu>.cpp, and calls from inside
os_<os>_<cpu>.cpp if slowdebug. Hence, since the VM - in particular
the slowdebug one - seems to work fine, it should be okay to mark
os::current_stack_pointer() unconditionally as NOINLINE.

However, then I saw that the only "real" function (real meaning not
just asserting something) using os::current_stack_pointer() and living
in the same translation unit is os::current_frame(), e.g. on linux:

frame os::current_frame() {
  intptr_t* fp = _get_previous_fp();
  frame myframe((intptr_t*)os::current_stack_pointer(),
                (intptr_t*)fp,
                CAST_FROM_FN_PTR(address, os::current_frame));
  if (os::is_first_C_frame(&myframe)) {
    // stack is not walkable
    return frame();
  } else {
    return os::get_sender_for_C_frame(&myframe);
  }
}

how does this even work if os::current_stack_pointer() is not inlined?
In slowdebug? Would the frame object in this case not contain the SP
from the frame built up for os::current_stack_pointer()?

So, now I wonder if making os::current_stack_pointer() NOINLINE would
break os::current_frame() - make if produce frames with a slightly-off
SP. os::current_frame() is used e.g. in NMT. So, I wonder if NMT still
works if os::current_stack_pointer is made NOINLINE, or in slowdebug.

> I never assume the compiler does the obvious these days :) or that there
> can't be clever link-time tricks as well.

Oh. I did not think of that at all, you are right.

>
> Maybe the safest thing to do is to only make a change for the clang case and
> leave everything else alone.
>

It would be better to know for sure, though.

..Thomas

> David
> -----
>
>>
>> ..Thomas
>>
>>> David


From martinrb at google.com  Fri Jun 22 16:41:46 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 Jun 2018 09:41:46 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CAA-vtUxUwBbgveX+iB_O0N6Dyd22qFhXJ6+RvOZDHcJKvrUmjw@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
 <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>
 <CAA-vtUxUwBbgveX+iB_O0N6Dyd22qFhXJ6+RvOZDHcJKvrUmjw@mail.gmail.com>
Message-ID: <CA+kOe09o9NR+PTbsNua8LYG504ZUKJZgEa++UENRKmn9Sgi6pA@mail.gmail.com>

(I keep trying not to become a hotspot engineer...)

I would define current_stack_pointer as a macro using expression
statements: prototype is:

#if defined(__clang__)
#define sp_3() ({ intptr_t rsp; __asm__ __volatile__ ("mov %% rsp,
%0":"=r"(rsp):); rsp; })
#else
#define sp_3() ({ register intptr_t rsp asm ("rsp"); rsp; })
#endif

Then we can call that everywhere and actually get the right answer.
(Other compilers and cpu architectures left as an exercise for the reader)
(Probably we won't be able to do this for every compiler we'd like to use)

Then we can make all the
os::verify_stack_alignment functions in non-product mode NOINLINE so that
they have a real stack frame with a real stack pointer.

But that's starting to be a big change and a hotspot culture change, so can
hotspot engineers please take over ?!

On Fri, Jun 22, 2018 at 8:27 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> On Fri, Jun 22, 2018 at 1:57 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> > On 21/06/2018 10:37 PM, Thomas St?fe wrote:
> >>
> >> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes <david.holmes at oracle.com>
> >> wrote:
> >>>
> >>> On 21/06/2018 10:05 AM, Martin Buchholz wrote:
> >>>>
> >>>>
> >>>> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz <martinrb at google.com
> >>>> <mailto:martinrb at google.com>> wrote:
> >>>>
> >>>>      Hi David and build-dev folk,
> >>>>
> >>>>      After way too much build/hotspot hacking, I have a better fix:
> >>>>
> >>>>      clang inlined os::current_stack_pointer into its caller __in the
> >>>>      same translation unit___ (that could be fixed in a separate
> change)
> >>>>      so of course in this case it didn't have to follow the ABI.  Fix
> is
> >>>>      obvious in hindsight:
> >>>>
> >>>>      -address os::current_stack_pointer() {
> >>>>      +NOINLINE address os::current_stack_pointer() {
> >>>>
> >>>>
> >>>> If y'all like the addition of NOINLINE, it should probably be added to
> >>>> all
> >>>> of the 14 variants of os::current_stack_pointer.
> >>>> Gives me a chance to try out the submit repo.
> >>>
> >>>
> >>>
> >>> I can't help but think other platforms actually rely on it being
> inlined
> >>> so
> >>> that it really does return the stack pointer of the method calling
> >>> os::current_stack_pointer!
> >>>
> >>
> >> But we only inline today if caller is in the same translation unit and
> >> builds with optimization, no?
> >
> >
> > Don't know, but Martin's encountering a case where it is being inlined -
> is
> > that likely to be unique for some reason?
> >
>
> Okay I may have confused myself.
>
> My original reasoning was: A lot of calls to
> os::current_stack_pointer() today happen not-inlined. That includes
> calls from outside os_<os>_<cpu>.cpp, and calls from inside
> os_<os>_<cpu>.cpp if slowdebug. Hence, since the VM - in particular
> the slowdebug one - seems to work fine, it should be okay to mark
> os::current_stack_pointer() unconditionally as NOINLINE.
>
> However, then I saw that the only "real" function (real meaning not
> just asserting something) using os::current_stack_pointer() and living
> in the same translation unit is os::current_frame(), e.g. on linux:
>
> frame os::current_frame() {
>   intptr_t* fp = _get_previous_fp();
>   frame myframe((intptr_t*)os::current_stack_pointer(),
>                 (intptr_t*)fp,
>                 CAST_FROM_FN_PTR(address, os::current_frame));
>   if (os::is_first_C_frame(&myframe)) {
>     // stack is not walkable
>     return frame();
>   } else {
>     return os::get_sender_for_C_frame(&myframe);
>   }
> }
>
> how does this even work if os::current_stack_pointer() is not inlined?
> In slowdebug? Would the frame object in this case not contain the SP
> from the frame built up for os::current_stack_pointer()?
>
> So, now I wonder if making os::current_stack_pointer() NOINLINE would
> break os::current_frame() - make if produce frames with a slightly-off
> SP. os::current_frame() is used e.g. in NMT. So, I wonder if NMT still
> works if os::current_stack_pointer is made NOINLINE, or in slowdebug.
>
> > I never assume the compiler does the obvious these days :) or that there
> > can't be clever link-time tricks as well.
>
> Oh. I did not think of that at all, you are right.
>
> >
> > Maybe the safest thing to do is to only make a change for the clang case
> and
> > leave everything else alone.
> >
>
> It would be better to know for sure, though.
>
> ..Thomas
>
> > David
> > -----
> >
> >>
> >> ..Thomas
> >>
> >>> David
>


From martinrb at google.com  Fri Jun 22 16:48:32 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 Jun 2018 09:48:32 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe09o9NR+PTbsNua8LYG504ZUKJZgEa++UENRKmn9Sgi6pA@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
 <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>
 <CAA-vtUxUwBbgveX+iB_O0N6Dyd22qFhXJ6+RvOZDHcJKvrUmjw@mail.gmail.com>
 <CA+kOe09o9NR+PTbsNua8LYG504ZUKJZgEa++UENRKmn9Sgi6pA@mail.gmail.com>
Message-ID: <CA+kOe09Rdkqb8VqdQwnXHMe5nPPj8ZJSWT8JTrggZVWCdmzbiQ@mail.gmail.com>

There sure seems to be a lot of confusion about how many stack frames we're
getting at the hot end of the stack, e.g.

  register intptr_t **fp __asm__ (SPELL_REG_FP);

  // fp is for this frame (_get_previous_fp). We want the fp for the
  // caller of os::current_frame*(), so go up two frames. However, for
  // optimized builds, _get_previous_fp() will be inlined, so only go
  // up 1 frame in that case.
  #ifdef _NMT_NOINLINE_
    return **(intptr_t***)fp;
  #else
    return *fp;
  #endif


From martinrb at google.com  Fri Jun 22 17:03:32 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 Jun 2018 10:03:32 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe09Rdkqb8VqdQwnXHMe5nPPj8ZJSWT8JTrggZVWCdmzbiQ@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
 <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>
 <CAA-vtUxUwBbgveX+iB_O0N6Dyd22qFhXJ6+RvOZDHcJKvrUmjw@mail.gmail.com>
 <CA+kOe09o9NR+PTbsNua8LYG504ZUKJZgEa++UENRKmn9Sgi6pA@mail.gmail.com>
 <CA+kOe09Rdkqb8VqdQwnXHMe5nPPj8ZJSWT8JTrggZVWCdmzbiQ@mail.gmail.com>
Message-ID: <CA+kOe0-rpdO8POQ8-wRB0vt1Qu4E3z22QG9-6-09gq3wUqV+pQ@mail.gmail.com>

I see stack pointers (and frame pointers) declared as intptr_t* which makes
no sense to me.  These are all "just" pointers, so declare them as either
void* or intptr_t or address

In the construct below, we could elide the cast if we had declared esp
right in the first place?!

  intptr_t* esp;
  __asm__ __volatile__ ("mov %%"SPELL_REG_SP", %0":"=r"(esp):);
  return (address) esp;


From jini.george at oracle.com  Fri Jun 22 18:11:52 2018
From: jini.george at oracle.com (Jini George)
Date: Fri, 22 Jun 2018 23:41:52 +0530
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with
 PT_ATTACHEXC
In-Reply-To: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
Message-ID: <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>

Hi all,

[Including build-dev also since this includes build related changes].

Requesting reviews for:

https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace 
the deprecated PT_ATTACH with PT_ATTACHEXC)

Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/

This is the follow-up solution for the temporary restoration of 
PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042 
(several serviceability/sa tests timed out on MacOS X), which was done 
in Oct 2017. The mails related to this are at:

http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021702.html

Changes as compared to the patch sent last year 
(http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):

* Addressed the review comments which were provided by Poonam, Dan, Dmitry.
* A major change as compared to what was done last year is that the MIG 
generated files have been included as a part of the JDK build process.
* The test case which was provided in the patch last year is no longer 
required since we have ClhsdbAttach.java testing the same functionality 
as a part of the SA testsuite now.
* Other than that, some minor improvements have been done wrt error 
handling.

The steps for the proposed solution have been provided in JBS.

Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.

Thanks to Sharath, Robin, Gerard and Dan for looking into the changes 
and providing valuable comments.

Thanks,
Jini.


From valerie.peng at oracle.com  Fri Jun 22 18:30:02 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 22 Jun 2018 11:30:02 -0700
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
 <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
Message-ID: <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com>

Max,

Good catch on the SunRsaSign provider bug.

Looking at the changes, I think we may have to fine-grain the check on 
the ensureInit() call, i.e.

use ensureInit(boolean sign) instead of ensureInit(), as the current 
method only ensures that at least one of the privKey, pubKey or 
fallbackSignature is non-null, I think it should check the right one is 
non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature.

In the PSS class engineInitVerify(...) method if the specified key is a 
MSCAPI public key, then fallbackSignature is set to null and the native 
verifyPssSignedHash method is used, right?

Thanks,

Valerie

On 6/21/2018 10:39 PM, Weijun Wang wrote:
> Webrev updated at
>
>    http://cr.openjdk.java.net/~weijun/8205445/webrev.01
>
> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.
>
> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.
>
> Thanks
> Max
>
>> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>>
>>
>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> Hi Weijun,
>>>
>>> The release note and the following notes look reasonable to me.
>>>
>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
>> Sounds good. I'll try it.
>>
>>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
>> Sure I can.
>>
>> Thanks
>> Max
>>
>>> Xuelei
>>>
>>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>>> Please take a review on this change
>>>>   http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>>    and the release note at
>>>>   https://bugs.openjdk.java.net/browse/JDK-8205471
>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>>> Several notes:
>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>>> Thanks
>>>> Max
>>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>>> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>>> [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx



From ekaterina.pavlova at oracle.com  Fri Jun 22 21:16:34 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Fri, 22 Jun 2018 14:16:34 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
Message-ID: <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>

Erik, Doug,

thank you a lot for your reviews and advises.
I fixed everything what Erik has pointed out, please see my answers inlined.
As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
so I will prefer to do this improvement/refactoring as part of separate JDK issue.

New webrev is here:
   webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
      JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
  testing: tested by building and running graal unit tests


On 6/19/18 2:00 PM, Erik Joelsson wrote:
> Hello,
> 
> Please always include build-dev when reviewing build changes.
> 
> In general this looks pretty good but there are some details that need fixing.
> 
> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
> 
> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>> Hi All,
>>
>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>
>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>
> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.

ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.

> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.

ok, renamed

> 
> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.

ok, removed

> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.

ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.

> The all and test-image targets are never called so no need to declare them.
> 
> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
> * 43 logic indent 2 spaces
> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
> * 58 continuation indent 4 spaces
> * 88, 89 please break long lines
> * 90 continuation indent 4 spaces
> * 99 continuation indent 4 spaces
> * 120 break before ))

I think I fixed everything

>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>
> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.

fixed

> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.

fixed

>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>
> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.

added

thanks,
-katya

> /Erik
>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>
>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>
>>
>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>> testing: new tests were executed as part of automatic HS testing for several months.
>>
>>
>> thanks,
>> -katya
>>
>> p.s.
>> ?Igor Ignatyev volunteered to sponsor this change. 
> 



From doug.simon at oracle.com  Fri Jun 22 21:29:14 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 22 Jun 2018 23:29:14 +0200
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
Message-ID: <D8B1FDB2-0861-4E17-B85F-09E06EF11EF2@oracle.com>



> On 22 Jun 2018, at 23:16, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
> 
> Erik, Doug,
> 
> thank you a lot for your reviews and advises.
> I fixed everything what Erik has pointed out, please see my answers inlined.
> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
> so I will prefer to do this improvement/refactoring as part of separate JDK issue.

Sorry for not being clearer. I don't expect you to fix/enhance updategraalinopenjdk. I was simply commenting on a possible solution to Joel's reasonable request for having Graal sources and test layout more normalized in the JDK code base.

-Doug

From erik.joelsson at oracle.com  Fri Jun 22 21:38:43 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 22 Jun 2018 14:38:43 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
Message-ID: <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>

Hello Katya,

This looks much better, thanks!

A few suggestions still:

Main.gmk: instead of repeating the assignment in both if and else block:

ifeq ($(INCLUDE_GRAAL), true)
 ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
endif

I think it's fine to do that without the ?= because an alternative JVM 
implementation is unlikely to be using graal anyway.

In JtregGraalUnit.gmk: Some minor style nits:
54: align )) with first eval line as you have done with the other eval calls
118: Since 117 is a one line parameter, please move comma to 117
133: Same as for 118
130-132: Please indent 4 spaces for continuation

/Erik

On 2018-06-22 14:16, Ekaterina Pavlova wrote:
> Erik, Doug,
>
> thank you a lot for your reviews and advises.
> I fixed everything what Erik has pointed out, please see my answers 
> inlined.
> As about moving more staff in 'updategraalinopenjdk' can we consider 
> this as next step?
> I am not quite familiar with 'updategraalinopenjdk' and didn't 
> contribute into Graal ws yet,
> so I will prefer to do this improvement/refactoring as part of 
> separate JDK issue.
>
> New webrev is here:
> ? webrev: 
> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
> ?testing: tested by building and running graal unit tests
>
>
> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>> Hello,
>>
>> Please always include build-dev when reviewing build changes.
>>
>> In general this looks pretty good but there are some details that 
>> need fixing.
>>
>> (Aside from this particular review, I must state my reservation 
>> against all the special treatment graal is enjoying from a source and 
>> test layout and build perspective. My understanding here is that 
>> someone will have to regularly update the wrapper jtreg tests 
>> manually using the script. This in addition to having to implement 
>> this very convoluted redirection logic because the tests are in the 
>> wrong place. Wouldn't it make a lot more sense to put the complicated 
>> logic in the import procedure for graal source so that it would fit 
>> nicely into the OpenJDK source/build/test model, instead of adding 
>> more and more complicated workarounds in the OpenJDK build and test 
>> procedures?)
>>
>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>> Hi All,
>>>
>>> please review porting of Graal unit tests under jtreg. The main idea 
>>> of this porting is to keep Graal unit tests as is
>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and 
>>> run them similar way they are run in Graal project.
>>> To achieve this 
>>> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java 
>>> helper class has been written
>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run 
>>> specified set of Graal unit tests. The groups of
>>> Graal unit tests to run are defined in auto-generated 
>>> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>
>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests 
>>> into jdk.vm.compiler.tests.jar and then install
>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>
>> GRAALUNIT_LIB is never defined (in the open). Since this is used in 
>> open makefiles, we need an open configure option to set it.
>
> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal 
> related staff there.
>
>> To make things clearer, I would rename LIB_DIR to something like 
>> LIB_OUTPUTDIR to signal that this is a location to put files in, 
>> rather than read them from.
>
> ok, renamed
>
>>
>> FLATTEN has no effect in the SetupCopyFiles call since all the jar 
>> files found by wildcard can only be in one directory anyway.
>
> ok, removed
>
>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests 
>> classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> 
>> Please create a suitable sub directory there for the output from this 
>> makefile.
>
> ok, introduced COMPILE_OUTPUTDIR := 
> $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit 
> test classes.
>
>> The all and test-image targets are never called so no need to declare 
>> them.
>>
>> There are some style issues too. (Please see 
>> http://openjdk.java.net/groups/build/doc/code-conventions.html for 
>> details.)
>> * 43 logic indent 2 spaces
>> * 52 we like to put the ending )) on a new line with ', \' at the end 
>> of the line before
>> * 58 continuation indent 4 spaces
>> * 88, 89 please break long lines
>> * 90 continuation indent 4 spaces
>> * 99 continuation indent 4 spaces
>> * 120 break before ))
>
> I think I fixed everything
>
>>> make/Main.gmk adds proper dependencies for 
>>> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>
>> The target build-test-hotspot-jtreg-graal only needs to depend on 
>> exploded-image-optimize.
>
> fixed
>
>> The new graal specific targets should be guarded by INCLUDE_GRAAL in 
>> Main.gmk. Otherwise those targets will silently do nothing if invoked 
>> without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs 
>> to be conditional too.
>
> fixed
>
>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg 
>>> knows where to find Graal tests and libs.
>>>
>> This needs to be duplicated for make/RunTest.gmk so that these tests 
>> work with "make run-test" as well.
>
> added
>
> thanks,
> -katya
>
>> /Erik
>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines 
>>> "testName -> testPrefix [requiresStatement]" mapping
>>> which is used by 
>>> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to 
>>> generate jtreg tests.
>>>
>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was 
>>> ported from mx project without any changes.
>>>
>>>
>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>> ?webrev: 
>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>> testing: new tests were executed as part of automatic HS testing for 
>>> several months.
>>>
>>>
>>> thanks,
>>> -katya
>>>
>>> p.s.
>>> ?Igor Ignatyev volunteered to sponsor this change. 
>>
>



From erik.joelsson at oracle.com  Fri Jun 22 22:01:13 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 22 Jun 2018 15:01:13 -0700
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
Message-ID: <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>

Hello Jini,

In general this looks pretty good, but it's also breaking some new 
ground as it's adding generation of native source in the java gensrc 
step. Mixing native code with the java code that the genrcs targets and 
gensrc output directories are meant for seems ok for now, but may cause 
trouble in the future. I'm going to accept it for now though.

In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in its 
own section (as delimited by the 80x # lines) and put that whole thing 
inside a conditional for macosx. Also please break line 47 (for recipe 
lines, indent with tab and 4 additional spaces for continuation [1]).

In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be 
enough as that will implicitly add the same directories as header dirs 
by default. At least that's the intention.

/Erik

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

On 2018-06-22 11:11, Jini George wrote:
> Hi all,
>
> [Including build-dev also since this includes build related changes].
>
> Requesting reviews for:
>
> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace 
> the deprecated PT_ATTACH with PT_ATTACHEXC)
>
> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>
> This is the follow-up solution for the temporary restoration of 
> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042 
> (several serviceability/sa tests timed out on MacOS X), which was done 
> in Oct 2017. The mails related to this are at:
>
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021702.html 
>
>
> Changes as compared to the patch sent last year 
> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>
> * Addressed the review comments which were provided by Poonam, Dan, 
> Dmitry.
> * A major change as compared to what was done last year is that the 
> MIG generated files have been included as a part of the JDK build 
> process.
> * The test case which was provided in the patch last year is no longer 
> required since we have ClhsdbAttach.java testing the same 
> functionality as a part of the SA testsuite now.
> * Other than that, some minor improvements have been done wrt error 
> handling.
>
> The steps for the proposed solution have been provided in JBS.
>
> Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.
>
> Thanks to Sharath, Robin, Gerard and Dan for looking into the changes 
> and providing valuable comments.
>
> Thanks,
> Jini.



From doug.simon at oracle.com  Fri Jun 22 22:07:13 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Sat, 23 Jun 2018 00:07:13 +0200
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <D8B1FDB2-0861-4E17-B85F-09E06EF11EF2@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <D8B1FDB2-0861-4E17-B85F-09E06EF11EF2@oracle.com>
Message-ID: <7CFCE7E6-DA8A-4B3C-8743-5A895B948DBB@oracle.com>



> On 22 Jun 2018, at 23:29, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
> 
>> On 22 Jun 2018, at 23:16, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>> 
>> Erik, Doug,
>> 
>> thank you a lot for your reviews and advises.
>> I fixed everything what Erik has pointed out, please see my answers inlined.
>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
> 
> Sorry for not being clearer. I don't expect you to fix/enhance updategraalinopenjdk. I was simply commenting on a possible solution to Joel's reasonable request for having Graal sources and test layout more normalized in the JDK code base.

Of course I meant Erik's request ;-)

-Doug

From ekaterina.pavlova at oracle.com  Fri Jun 22 22:08:06 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Fri, 22 Jun 2018 15:08:06 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <D8B1FDB2-0861-4E17-B85F-09E06EF11EF2@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <D8B1FDB2-0861-4E17-B85F-09E06EF11EF2@oracle.com>
Message-ID: <ddb74f76-de7f-744d-336b-4bf2494d8cd4@oracle.com>

On 6/22/18 2:29 PM, Doug Simon wrote:
> 
> 
>> On 22 Jun 2018, at 23:16, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
>>
>> Erik, Doug,
>>
>> thank you a lot for your reviews and advises.
>> I fixed everything what Erik has pointed out, please see my answers inlined.
>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
> 
> Sorry for not being clearer. I don't expect you to fix/enhance updategraalinopenjdk. I was simply commenting on a possible solution to Joel's reasonabl> request for having Graal sources and test layout more normalized in the JDK code base.

ok, good :)

-katya


From ekaterina.pavlova at oracle.com  Fri Jun 22 22:22:16 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Fri, 22 Jun 2018 15:22:16 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
Message-ID: <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>

Fixed and regenerated webrev at the same location:
  http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html

Erik,
thanks again for your detailed reviews!

-katya

On 6/22/18 2:38 PM, Erik Joelsson wrote:
> Hello Katya,
> 
> This looks much better, thanks!
> 
> A few suggestions still:
> 
> Main.gmk: instead of repeating the assignment in both if and else block:
> 
> ifeq ($(INCLUDE_GRAAL), true)
>  ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
> endif
> 
> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway.
> 
> In JtregGraalUnit.gmk: Some minor style nits:
> 54: align )) with first eval line as you have done with the other eval calls
> 118: Since 117 is a one line parameter, please move comma to 117
> 133: Same as for 118
> 130-132: Please indent 4 spaces for continuation
> 
> /Erik
> 
> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>> Erik, Doug,
>>
>> thank you a lot for your reviews and advises.
>> I fixed everything what Erik has pointed out, please see my answers inlined.
>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
>>
>> New webrev is here:
>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>> ?testing: tested by building and running graal unit tests
>>
>>
>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please always include build-dev when reviewing build changes.
>>>
>>> In general this looks pretty good but there are some details that need fixing.
>>>
>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
>>>
>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>> Hi All,
>>>>
>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>
>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>
>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
>>
>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.
>>
>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
>>
>> ok, renamed
>>
>>>
>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
>>
>> ok, removed
>>
>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.
>>
>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.
>>
>>> The all and test-image targets are never called so no need to declare them.
>>>
>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
>>> * 43 logic indent 2 spaces
>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
>>> * 58 continuation indent 4 spaces
>>> * 88, 89 please break long lines
>>> * 90 continuation indent 4 spaces
>>> * 99 continuation indent 4 spaces
>>> * 120 break before ))
>>
>> I think I fixed everything
>>
>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>
>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
>>
>> fixed
>>
>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>
>> fixed
>>
>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>>>
>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
>>
>> added
>>
>> thanks,
>> -katya
>>
>>> /Erik
>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>>>
>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>>>
>>>>
>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>> testing: new tests were executed as part of automatic HS testing for several months.
>>>>
>>>>
>>>> thanks,
>>>> -katya
>>>>
>>>> p.s.
>>>> ?Igor Ignatyev volunteered to sponsor this change. 
>>>
>>
> 



From weijun.wang at oracle.com  Fri Jun 22 22:23:28 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 23 Jun 2018 06:23:28 +0800
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
 <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
 <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com>
Message-ID: <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com>



> On Jun 23, 2018, at 2:30 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Max,
> 
> Good catch on the SunRsaSign provider bug.
> 
> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e.
> 
> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature.

Could anything go wrong? This method just ensures one of initSign() or initVerify() is called.

> 
> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right?

Yes. The native method only fails when trying to import from a blob.

Thanks
Max

> 
> Thanks,
> 
> Valerie
> 
> On 6/21/2018 10:39 PM, Weijun Wang wrote:
>> Webrev updated at
>> 
>>   
>> http://cr.openjdk.java.net/~weijun/8205445/webrev.01
>> 
>> 
>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.
>> 
>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.
>> 
>> Thanks
>> Max
>> 
>> 
>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com>
>>>  wrote:
>>> 
>>> 
>>> 
>>> 
>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com>
>>>>  wrote:
>>>> 
>>>> Hi Weijun,
>>>> 
>>>> The release note and the following notes look reasonable to me.
>>>> 
>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
>>>> 
>>> Sounds good. I'll try it.
>>> 
>>> 
>>>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
>>>> 
>>> Sure I can.
>>> 
>>> Thanks
>>> Max
>>> 
>>> 
>>>> Xuelei
>>>> 
>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>>> 
>>>>> Please take a review on this change
>>>>>  
>>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>>> 
>>>>>   and the release note at
>>>>>  
>>>>> https://bugs.openjdk.java.net/browse/JDK-8205471
>>>>> 
>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>>>> Several notes:
>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>>>> Thanks
>>>>> Max
>>>>> [1] 
>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>>>> 
>>>>> [2] 
>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>>>> 
>>>>> [3] 
>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx
> 



From valerie.peng at oracle.com  Sat Jun 23 00:35:11 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 22 Jun 2018 17:35:11 -0700
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
 <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
 <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com>
 <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com>
Message-ID: <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com>



On 6/22/2018 3:23 PM, Weijun Wang wrote:
>> On Jun 23, 2018, at 2:30 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Max,
>>
>> Good catch on the SunRsaSign provider bug.
>>
>> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e.
>>
>> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature.
> Could anything go wrong? This method just ensures one of initSign() or initVerify() is called.
Only when the initSign()/initVerify() does not match the subsequent 
calls of sign()/verify() I suppose.
Valerie
>> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right?
> Yes. The native method only fails when trying to import from a blob.
>
> Thanks
> Max
>
>> Thanks,
>>
>> Valerie
>>
>> On 6/21/2018 10:39 PM, Weijun Wang wrote:
>>> Webrev updated at
>>>
>>>    
>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.01
>>>
>>>
>>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.
>>>
>>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.
>>>
>>> Thanks
>>> Max
>>>
>>>
>>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com>
>>>>   wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com>
>>>>>   wrote:
>>>>>
>>>>> Hi Weijun,
>>>>>
>>>>> The release note and the following notes look reasonable to me.
>>>>>
>>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
>>>>>
>>>> Sounds good. I'll try it.
>>>>
>>>>
>>>>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
>>>>>
>>>> Sure I can.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>
>>>>> Xuelei
>>>>>
>>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>>>>
>>>>>> Please take a review on this change
>>>>>>   
>>>>>> http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>>>>
>>>>>>    and the release note at
>>>>>>   
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205471
>>>>>>
>>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>>>>> Several notes:
>>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>>>>> Thanks
>>>>>> Max
>>>>>> [1]
>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>>>>>
>>>>>> [2]
>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>>>>>
>>>>>> [3]
>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx



From weijun.wang at oracle.com  Sat Jun 23 00:40:58 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 23 Jun 2018 08:40:58 +0800
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
 <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
 <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com>
 <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com>
 <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com>
Message-ID: <55A55402-DDA5-483B-B548-18E096BB0765@oracle.com>



> On Jun 23, 2018, at 8:35 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> On 6/22/2018 3:23 PM, Weijun Wang wrote:
>>> On Jun 23, 2018, at 2:30 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>> 
>>> Max,
>>> 
>>> Good catch on the SunRsaSign provider bug.
>>> 
>>> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e.
>>> 
>>> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature.
>> Could anything go wrong? This method just ensures one of initSign() or initVerify() is called.
> Only when the initSign()/initVerify() does not match the subsequent calls of sign()/verify() I suppose.

I see what you mean.

The Signature class takes care of it:

    public final byte[] sign() throws SignatureException {
        if (state == SIGN) {
            return engineSign();
        }
        throw new SignatureException("object not initialized for " +
                                     "signing");
    }

Thanks
Max

> Valerie
>>> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right?
>> Yes. The native method only fails when trying to import from a blob.
>> 
>> Thanks
>> Max
>> 
>>> Thanks,
>>> 
>>> Valerie
>>> 
>>> On 6/21/2018 10:39 PM, Weijun Wang wrote:
>>>> Webrev updated at
>>>> 
>>>>   http://cr.openjdk.java.net/~weijun/8205445/webrev.01
>>>> 
>>>> 
>>>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.
>>>> 
>>>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>> 
>>>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com>
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com>
>>>>>>  wrote:
>>>>>> 
>>>>>> Hi Weijun,
>>>>>> 
>>>>>> The release note and the following notes look reasonable to me.
>>>>>> 
>>>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
>>>>>> 
>>>>> Sounds good. I'll try it.
>>>>> 
>>>>> 
>>>>>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
>>>>>> 
>>>>> Sure I can.
>>>>> 
>>>>> Thanks
>>>>> Max
>>>>> 
>>>>> 
>>>>>> Xuelei
>>>>>> 
>>>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>>>>> 
>>>>>>> Please take a review on this change
>>>>>>>  http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>>>>> 
>>>>>>>   and the release note at
>>>>>>>  https://bugs.openjdk.java.net/browse/JDK-8205471
>>>>>>> 
>>>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>>>>>> Several notes:
>>>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>>>>>> Thanks
>>>>>>> Max
>>>>>>> [1]
>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>>>>>> 
>>>>>>> [2]
>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>>>>>> 
>>>>>>> [3]
>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx
> 



From martinrb at google.com  Sat Jun 23 01:04:24 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 Jun 2018 18:04:24 -0700
Subject: RFR: 8186780: clang-4.0 fastdebug assertion failure in
 os_linux_x86:os::verify_stack_alignment()
In-Reply-To: <CA+kOe0-rpdO8POQ8-wRB0vt1Qu4E3z22QG9-6-09gq3wUqV+pQ@mail.gmail.com>
References: <CA+kOe08vOOH2LA==6XH5tCs75qU0imBJYus62YnPb6a7Nod5rg@mail.gmail.com>
 <f9c2241d-d9f2-d70c-cf4c-900c3ef6fccc@oracle.com>
 <CA+kOe08jE8Pb37JHNQFa2_TK2nzrEFNYewELcAHpkPuQQcUfdA@mail.gmail.com>
 <CA+kOe08nhD2oKGRQBAvxm1hQZ9RKQSgc_=tSasgRLexw27upeQ@mail.gmail.com>
 <c2cb00ae-3a29-fb61-4fe6-3b4a4ba3c955@oracle.com>
 <CAA-vtUxkmxfJca_fvAjnsROHpY4Ae3A7gooq2V++70GrDD7mmg@mail.gmail.com>
 <82524f2c-723b-0322-1272-2062b1c3ca27@oracle.com>
 <CAA-vtUxUwBbgveX+iB_O0N6Dyd22qFhXJ6+RvOZDHcJKvrUmjw@mail.gmail.com>
 <CA+kOe09o9NR+PTbsNua8LYG504ZUKJZgEa++UENRKmn9Sgi6pA@mail.gmail.com>
 <CA+kOe09Rdkqb8VqdQwnXHMe5nPPj8ZJSWT8JTrggZVWCdmzbiQ@mail.gmail.com>
 <CA+kOe0-rpdO8POQ8-wRB0vt1Qu4E3z22QG9-6-09gq3wUqV+pQ@mail.gmail.com>
Message-ID: <CA+kOe0-vSDPtrN72UDPoQLXX6WfumtdUrGZoGj9_ND0y-9qAQA@mail.gmail.com>

Since the question of how to get the stack pointer in hotspot is
unexpectedly difficult, I propose we split into two separate changes and we
can submit the make/ changes that Erik is happy with.


From jini.george at oracle.com  Sun Jun 24 17:37:26 2018
From: jini.george at oracle.com (Jini George)
Date: Sun, 24 Jun 2018 23:07:26 +0530
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
Message-ID: <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>

Hi Erik,

Thank you very much for looking into this. I have addressed your 
comments. The latest webrev is at:

http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/

Thank you,
Jini.


On 6/23/2018 3:31 AM, Erik Joelsson wrote:
> Hello Jini,
> 
> In general this looks pretty good, but it's also breaking some new 
> ground as it's adding generation of native source in the java gensrc 
> step. Mixing native code with the java code that the genrcs targets and 
> gensrc output directories are meant for seems ok for now, but may cause 
> trouble in the future. I'm going to accept it for now though.
> 
> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in its 
> own section (as delimited by the 80x # lines) and put that whole thing 
> inside a conditional for macosx. Also please break line 47 (for recipe 
> lines, indent with tab and 4 additional spaces for continuation [1]).
> 
> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be 
> enough as that will implicitly add the same directories as header dirs 
> by default. At least that's the intention.
> 
> /Erik
> 
> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
> 
> On 2018-06-22 11:11, Jini George wrote:
>> Hi all,
>>
>> [Including build-dev also since this includes build related changes].
>>
>> Requesting reviews for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace 
>> the deprecated PT_ATTACH with PT_ATTACHEXC)
>>
>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>
>> This is the follow-up solution for the temporary restoration of 
>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042 
>> (several serviceability/sa tests timed out on MacOS X), which was done 
>> in Oct 2017. The mails related to this are at:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021702.html 
>>
>>
>> Changes as compared to the patch sent last year 
>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>
>> * Addressed the review comments which were provided by Poonam, Dan, 
>> Dmitry.
>> * A major change as compared to what was done last year is that the 
>> MIG generated files have been included as a part of the JDK build 
>> process.
>> * The test case which was provided in the patch last year is no longer 
>> required since we have ClhsdbAttach.java testing the same 
>> functionality as a part of the SA testsuite now.
>> * Other than that, some minor improvements have been done wrt error 
>> handling.
>>
>> The steps for the proposed solution have been provided in JBS.
>>
>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.
>>
>> Thanks to Sharath, Robin, Gerard and Dan for looking into the changes 
>> and providing valuable comments.
>>
>> Thanks,
>> Jini.
> 


From jini.george at oracle.com  Mon Jun 25 10:11:10 2018
From: jini.george at oracle.com (Jini George)
Date: Mon, 25 Jun 2018 15:41:10 +0530
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <fa7627f5-6953-498e-8e2a-6d80112081f1@default>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
 <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
 <fa7627f5-6953-498e-8e2a-6d80112081f1@default>
Message-ID: <5ba6916b-35bf-617e-fff8-93f096162047@oracle.com>

Thank you, Sharath. May I have a Reviewer to take a look at the 
MacosxDebuggerLocal code?

Thanks,
Jini.

On 6/25/2018 1:52 PM, Sharath Ballal wrote:
> Hi Jini,
> 
> Changes in MacosxDebuggerLocal.m looks good.
> 
> Thanks,
> Sharath
> 
> 
> -----Original Message-----
> From: Jini George
> Sent: Sunday, June 24, 2018 11:07 PM
> To: Erik Joelsson; serviceability-dev at openjdk.java.net; build-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC
> 
> Hi Erik,
> 
> Thank you very much for looking into this. I have addressed your comments. The latest webrev is at:
> 
> http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/
> 
> Thank you,
> Jini.
> 
> 
> On 6/23/2018 3:31 AM, Erik Joelsson wrote:
>> Hello Jini,
>>
>> In general this looks pretty good, but it's also breaking some new
>> ground as it's adding generation of native source in the java gensrc
>> step. Mixing native code with the java code that the genrcs targets
>> and gensrc output directories are meant for seems ok for now, but may
>> cause trouble in the future. I'm going to accept it for now though.
>>
>> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in
>> its own section (as delimited by the 80x # lines) and put that whole
>> thing inside a conditional for macosx. Also please break line 47 (for
>> recipe lines, indent with tab and 4 additional spaces for continuation [1]).
>>
>> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be
>> enough as that will implicitly add the same directories as header dirs
>> by default. At least that's the intention.
>>
>> /Erik
>>
>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>
>> On 2018-06-22 11:11, Jini George wrote:
>>> Hi all,
>>>
>>> [Including build-dev also since this includes build related changes].
>>>
>>> Requesting reviews for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace
>>> the deprecated PT_ATTACH with PT_ATTACHEXC)
>>>
>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>>
>>> This is the follow-up solution for the temporary restoration of
>>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042
>>> (several serviceability/sa tests timed out on MacOS X), which was
>>> done in Oct 2017. The mails related to this are at:
>>>
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August
>>> /021702.html
>>>
>>>
>>> Changes as compared to the patch sent last year
>>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>>
>>> * Addressed the review comments which were provided by Poonam, Dan,
>>> Dmitry.
>>> * A major change as compared to what was done last year is that the
>>> MIG generated files have been included as a part of the JDK build
>>> process.
>>> * The test case which was provided in the patch last year is no
>>> longer required since we have ClhsdbAttach.java testing the same
>>> functionality as a part of the SA testsuite now.
>>> * Other than that, some minor improvements have been done wrt error
>>> handling.
>>>
>>> The steps for the proposed solution have been provided in JBS.
>>>
>>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.
>>>
>>> Thanks to Sharath, Robin, Gerard and Dan for looking into the changes
>>> and providing valuable comments.
>>>
>>> Thanks,
>>> Jini.
>>


From sgehwolf at redhat.com  Mon Jun 25 14:12:55 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 25 Jun 2018 16:12:55 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <67fe9713-8836-e19c-bf52-87648fb501f5@physik.fu-berlin.de>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
 <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
 <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>
 <61d15fe3ac5ddf12de11ae842c7a8e964afacc8f.camel@redhat.com>
 <67fe9713-8836-e19c-bf52-87648fb501f5@physik.fu-berlin.de>
Message-ID: <9d6d945c2e44d3c6834631cfe1270a0f09c08444.camel@redhat.com>

On Fri, 2018-06-22 at 13:31 +0200, John Paul Adrian Glaubitz wrote:
> Hi Severin!
> 
> On 06/22/2018 01:19 PM, Severin Gehwolf wrote:
> > > Now, before I create the bug report, do you happen to know which changeset
> > > introduced the regression? We usually include that in the bug report.
> > 
> > http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855
> > 
> > > And I also need to know whom to credit for the patch because of the several
> > > backs and forths, I lost the overview.
> > 
> > I'd propose:
> > 
> > Contributed-by: Magnuse Ihse Bursie <magnus.ihse.bursie at oracle.com>, Fridrich Strba <fridrich.strba at suse.com>
> 
> Perfect, thank you!

Adrian, any update on this? Is there a bug open? We need this fix for
our future JDK 11 packages.

Thanks,
Severin


From glaubitz at physik.fu-berlin.de  Mon Jun 25 14:35:21 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 25 Jun 2018 16:35:21 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <9d6d945c2e44d3c6834631cfe1270a0f09c08444.camel@redhat.com>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
 <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
 <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>
 <61d15fe3ac5ddf12de11ae842c7a8e964afacc8f.camel@redhat.com>
 <67fe9713-8836-e19c-bf52-87648fb501f5@physik.fu-berlin.de>
 <9d6d945c2e44d3c6834631cfe1270a0f09c08444.camel@redhat.com>
Message-ID: <f55e6ab0-98fd-452b-63a8-a53937a5768d@physik.fu-berlin.de>

Hi Severin!

On 06/25/2018 04:12 PM, Severin Gehwolf wrote:
>>> I'd propose:
>>>
>>> Contributed-by: Magnuse Ihse Bursie <magnus.ihse.bursie at oracle.com>, Fridrich Strba <fridrich.strba at suse.com>
>>
>> Perfect, thank you!
> 
> Adrian, any update on this? Is there a bug open? We need this fix for
> our future JDK 11 packages.

Sorry, I was traveling over the weekend. I should be able to do it later
today.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From VicWang at zhaoxin.com  Mon Jun 25 15:19:51 2018
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Mon, 25 Jun 2018 15:19:51 +0000
Subject: =?gb2312?B?SW5xdWlyeSB3aGV0aGVyIGpkazh1IGNhbiBjb21waWxlIHdpdGggaWNjo78=?=
In-Reply-To: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
Message-ID: <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>

Hi,

       I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler.
       How to configure jvm before using ICC compiling?
       If there are any tips for ICC compiling, please let me know. Thanks a lot.

Best Regards!
VicWang


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From yumin.qi at gmail.com  Mon Jun 25 15:43:25 2018
From: yumin.qi at gmail.com (yumin qi)
Date: Mon, 25 Jun 2018 08:43:25 -0700
Subject: =?UTF-8?Q?Re=3A_Inquiry_whether_jdk8u_can_compile_with_icc=EF=BC=9F?=
In-Reply-To: <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
Message-ID: <CAOEheN5pjnOGmY89TCjA-FYdck35QVfqTZs4nMde_Q9EgXmTvA@mail.gmail.com>

Hi, Vic

  You can try the help:
       sh configure --help
  Also
       export CC='your ICC'

Yumin

On Mon, Jun 25, 2018 at 8:20 AM Vic Wang(BJ-RD) <VicWang at zhaoxin.com> wrote:

> Hi,
>
>        I get the openjdk-jdk8u-jdk8u source code, and I want to compile
> jvm with ICC compiler.
>        How to configure jvm before using ICC compiling?
>        If there are any tips for ICC compiling, please let me know. Thanks
> a lot.
>
> Best Regards!
> VicWang
>
>
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is
> for the sole use of its intended recipient. Any unauthorized review, use,
> copying or forwarding of this email or the content of this email is
> strictly prohibited.
>

From erik.joelsson at oracle.com  Mon Jun 25 15:52:17 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 25 Jun 2018 08:52:17 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
Message-ID: <00f1cb15-8968-5412-e357-79f11d4fd013@oracle.com>

Looks ok to me.

/Erik


On 2018-06-22 15:22, Ekaterina Pavlova wrote:
> Fixed and regenerated webrev at the same location:
> ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>
> Erik,
> thanks again for your detailed reviews!
>
> -katya
>
> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>> Hello Katya,
>>
>> This looks much better, thanks!
>>
>> A few suggestions still:
>>
>> Main.gmk: instead of repeating the assignment in both if and else block:
>>
>> ifeq ($(INCLUDE_GRAAL), true)
>> ?? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>> endif
>>
>> I think it's fine to do that without the ?= because an alternative 
>> JVM implementation is unlikely to be using graal anyway.
>>
>> In JtregGraalUnit.gmk: Some minor style nits:
>> 54: align )) with first eval line as you have done with the other 
>> eval calls
>> 118: Since 117 is a one line parameter, please move comma to 117
>> 133: Same as for 118
>> 130-132: Please indent 4 spaces for continuation
>>
>> /Erik
>>
>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>> Erik, Doug,
>>>
>>> thank you a lot for your reviews and advises.
>>> I fixed everything what Erik has pointed out, please see my answers 
>>> inlined.
>>> As about moving more staff in 'updategraalinopenjdk' can we consider 
>>> this as next step?
>>> I am not quite familiar with 'updategraalinopenjdk' and didn't 
>>> contribute into Graal ws yet,
>>> so I will prefer to do this improvement/refactoring as part of 
>>> separate JDK issue.
>>>
>>> New webrev is here:
>>> ? webrev: 
>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>> ?testing: tested by building and running graal unit tests
>>>
>>>
>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> Please always include build-dev when reviewing build changes.
>>>>
>>>> In general this looks pretty good but there are some details that 
>>>> need fixing.
>>>>
>>>> (Aside from this particular review, I must state my reservation 
>>>> against all the special treatment graal is enjoying from a source 
>>>> and test layout and build perspective. My understanding here is 
>>>> that someone will have to regularly update the wrapper jtreg tests 
>>>> manually using the script. This in addition to having to implement 
>>>> this very convoluted redirection logic because the tests are in the 
>>>> wrong place. Wouldn't it make a lot more sense to put the 
>>>> complicated logic in the import procedure for graal source so that 
>>>> it would fit nicely into the OpenJDK source/build/test model, 
>>>> instead of adding more and more complicated workarounds in the 
>>>> OpenJDK build and test procedures?)
>>>>
>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>> Hi All,
>>>>>
>>>>> please review porting of Graal unit tests under jtreg. The main 
>>>>> idea of this porting is to keep Graal unit tests as is
>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and 
>>>>> run them similar way they are run in Graal project.
>>>>> To achieve this 
>>>>> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java 
>>>>> helper class has been written
>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to 
>>>>> run specified set of Graal unit tests. The groups of
>>>>> Graal unit tests to run are defined in auto-generated 
>>>>> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>>
>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests 
>>>>> into jdk.vm.compiler.tests.jar and then install
>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>>
>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in 
>>>> open makefiles, we need an open configure option to set it.
>>>
>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal 
>>> related staff there.
>>>
>>>> To make things clearer, I would rename LIB_DIR to something like 
>>>> LIB_OUTPUTDIR to signal that this is a location to put files in, 
>>>> rather than read them from.
>>>
>>> ok, renamed
>>>
>>>>
>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar 
>>>> files found by wildcard can only be in one directory anyway.
>>>
>>> ok, removed
>>>
>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. 
>>>> Tests classes and jars should be built into 
>>>> $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub 
>>>> directory there for the output from this makefile.
>>>
>>> ok, introduced COMPILE_OUTPUTDIR := 
>>> $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit 
>>> test classes.
>>>
>>>> The all and test-image targets are never called so no need to 
>>>> declare them.
>>>>
>>>> There are some style issues too. (Please see 
>>>> http://openjdk.java.net/groups/build/doc/code-conventions.html for 
>>>> details.)
>>>> * 43 logic indent 2 spaces
>>>> * 52 we like to put the ending )) on a new line with ', \' at the 
>>>> end of the line before
>>>> * 58 continuation indent 4 spaces
>>>> * 88, 89 please break long lines
>>>> * 90 continuation indent 4 spaces
>>>> * 99 continuation indent 4 spaces
>>>> * 120 break before ))
>>>
>>> I think I fixed everything
>>>
>>>>> make/Main.gmk adds proper dependencies for 
>>>>> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>>
>>>> The target build-test-hotspot-jtreg-graal only needs to depend on 
>>>> exploded-image-optimize.
>>>
>>> fixed
>>>
>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL 
>>>> in Main.gmk. Otherwise those targets will silently do nothing if 
>>>> invoked without graal. That means adding them to 
>>>> JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>>
>>> fixed
>>>
>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg 
>>>>> knows where to find Graal tests and libs.
>>>>>
>>>> This needs to be duplicated for make/RunTest.gmk so that these 
>>>> tests work with "make run-test" as well.
>>>
>>> added
>>>
>>> thanks,
>>> -katya
>>>
>>>> /Erik
>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file 
>>>>> defines "testName -> testPrefix [requiresStatement]" mapping
>>>>> which is used by 
>>>>> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to 
>>>>> generate jtreg tests.
>>>>>
>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was 
>>>>> ported from mx project without any changes.
>>>>>
>>>>>
>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>> ?webrev: 
>>>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>> testing: new tests were executed as part of automatic HS testing 
>>>>> for several months.
>>>>>
>>>>>
>>>>> thanks,
>>>>> -katya
>>>>>
>>>>> p.s.
>>>>> ?Igor Ignatyev volunteered to sponsor this change. 
>>>>
>>>
>>
>



From erik.joelsson at oracle.com  Mon Jun 25 15:53:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 25 Jun 2018 08:53:39 -0700
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
 <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
Message-ID: <30d34a04-1611-f6f5-6d9b-548cb6bc9b45@oracle.com>

Build changes look good.

/Erik


On 2018-06-24 10:37, Jini George wrote:
> Hi Erik,
>
> Thank you very much for looking into this. I have addressed your 
> comments. The latest webrev is at:
>
> http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/
>
> Thank you,
> Jini.
>
>
> On 6/23/2018 3:31 AM, Erik Joelsson wrote:
>> Hello Jini,
>>
>> In general this looks pretty good, but it's also breaking some new 
>> ground as it's adding generation of native source in the java gensrc 
>> step. Mixing native code with the java code that the genrcs targets 
>> and gensrc output directories are meant for seems ok for now, but may 
>> cause trouble in the future. I'm going to accept it for now though.
>>
>> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in 
>> its own section (as delimited by the 80x # lines) and put that whole 
>> thing inside a conditional for macosx. Also please break line 47 (for 
>> recipe lines, indent with tab and 4 additional spaces for 
>> continuation [1]).
>>
>> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be 
>> enough as that will implicitly add the same directories as header 
>> dirs by default. At least that's the intention.
>>
>> /Erik
>>
>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>
>> On 2018-06-22 11:11, Jini George wrote:
>>> Hi all,
>>>
>>> [Including build-dev also since this includes build related changes].
>>>
>>> Requesting reviews for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: 
>>> Replace the deprecated PT_ATTACH with PT_ATTACHEXC)
>>>
>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>>
>>> This is the follow-up solution for the temporary restoration of 
>>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042 
>>> (several serviceability/sa tests timed out on MacOS X), which was 
>>> done in Oct 2017. The mails related to this are at:
>>>
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021702.html 
>>>
>>>
>>> Changes as compared to the patch sent last year 
>>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>>
>>> * Addressed the review comments which were provided by Poonam, Dan, 
>>> Dmitry.
>>> * A major change as compared to what was done last year is that the 
>>> MIG generated files have been included as a part of the JDK build 
>>> process.
>>> * The test case which was provided in the patch last year is no 
>>> longer required since we have ClhsdbAttach.java testing the same 
>>> functionality as a part of the SA testsuite now.
>>> * Other than that, some minor improvements have been done wrt error 
>>> handling.
>>>
>>> The steps for the proposed solution have been provided in JBS.
>>>
>>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.
>>>
>>> Thanks to Sharath, Robin, Gerard and Dan for looking into the 
>>> changes and providing valuable comments.
>>>
>>> Thanks,
>>> Jini.
>>



From erik.joelsson at oracle.com  Mon Jun 25 16:20:18 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 25 Jun 2018 09:20:18 -0700
Subject: =?UTF-8?Q?Re:_Inquiry_whether_jdk8u_can_compile_with_icc=ef=bc=9f?=
In-Reply-To: <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
Message-ID: <4d86af32-21c1-2680-aec3-7fa8d45519b2@oracle.com>

Hello,

There is no support for ICC as far as I know. If ICC is compatible with 
the default toolchain for the platform, you may get something to work, 
but I doubt you will have any luck without modifying build logic.

Which platform are you trying to build on?

/Erik


On 2018-06-25 08:19, Vic Wang(BJ-RD) wrote:
> Hi,
>
>         I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler.
>         How to configure jvm before using ICC compiling?
>         If there are any tips for ICC compiling, please let me know. Thanks a lot.
>
> Best Regards!
> VicWang
>
>
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.



From jini.george at oracle.com  Mon Jun 25 16:21:47 2018
From: jini.george at oracle.com (Jini George)
Date: Mon, 25 Jun 2018 21:51:47 +0530
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <30d34a04-1611-f6f5-6d9b-548cb6bc9b45@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
 <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
 <30d34a04-1611-f6f5-6d9b-548cb6bc9b45@oracle.com>
Message-ID: <d63bb8bd-d7e6-d8c6-74a0-81b9261991e4@oracle.com>

Thank you, Erik !

- Jini.

On 6/25/2018 9:23 PM, Erik Joelsson wrote:
> Build changes look good.
> 
> /Erik
> 
> 
> On 2018-06-24 10:37, Jini George wrote:
>> Hi Erik,
>>
>> Thank you very much for looking into this. I have addressed your 
>> comments. The latest webrev is at:
>>
>> http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/
>>
>> Thank you,
>> Jini.
>>
>>
>> On 6/23/2018 3:31 AM, Erik Joelsson wrote:
>>> Hello Jini,
>>>
>>> In general this looks pretty good, but it's also breaking some new 
>>> ground as it's adding generation of native source in the java gensrc 
>>> step. Mixing native code with the java code that the genrcs targets 
>>> and gensrc output directories are meant for seems ok for now, but may 
>>> cause trouble in the future. I'm going to accept it for now though.
>>>
>>> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in 
>>> its own section (as delimited by the 80x # lines) and put that whole 
>>> thing inside a conditional for macosx. Also please break line 47 (for 
>>> recipe lines, indent with tab and 4 additional spaces for 
>>> continuation [1]).
>>>
>>> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be 
>>> enough as that will implicitly add the same directories as header 
>>> dirs by default. At least that's the intention.
>>>
>>> /Erik
>>>
>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>>
>>> On 2018-06-22 11:11, Jini George wrote:
>>>> Hi all,
>>>>
>>>> [Including build-dev also since this includes build related changes].
>>>>
>>>> Requesting reviews for:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: 
>>>> Replace the deprecated PT_ATTACH with PT_ATTACHEXC)
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>>>
>>>> This is the follow-up solution for the temporary restoration of 
>>>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042 
>>>> (several serviceability/sa tests timed out on MacOS X), which was 
>>>> done in Oct 2017. The mails related to this are at:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021702.html 
>>>>
>>>>
>>>> Changes as compared to the patch sent last year 
>>>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>>>
>>>> * Addressed the review comments which were provided by Poonam, Dan, 
>>>> Dmitry.
>>>> * A major change as compared to what was done last year is that the 
>>>> MIG generated files have been included as a part of the JDK build 
>>>> process.
>>>> * The test case which was provided in the patch last year is no 
>>>> longer required since we have ClhsdbAttach.java testing the same 
>>>> functionality as a part of the SA testsuite now.
>>>> * Other than that, some minor improvements have been done wrt error 
>>>> handling.
>>>>
>>>> The steps for the proposed solution have been provided in JBS.
>>>>
>>>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.
>>>>
>>>> Thanks to Sharath, Robin, Gerard and Dan for looking into the 
>>>> changes and providing valuable comments.
>>>>
>>>> Thanks,
>>>> Jini.
>>>
> 


From glaubitz at physik.fu-berlin.de  Mon Jun 25 16:57:42 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 25 Jun 2018 18:57:42 +0200
Subject: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]
In-Reply-To: <f55e6ab0-98fd-452b-63a8-a53937a5768d@physik.fu-berlin.de>
References: <6932dc67-739b-ce78-4ca2-ffa14dfe735b@suse.com>
 <ad9a42f87508195dbc763dc19cc2dd5c5a0db286.camel@redhat.com>
 <e84b3af0-ee49-a4a8-dfa0-80b6390e9aab@physik.fu-berlin.de>
 <2226554b-4452-06a4-a628-9ec79920822c@oracle.com>
 <30d6e664-46b3-5ed6-9477-d46d6bff2257@suse.com>
 <05d65ad2-14d4-de5f-3df5-ea4be9873924@physik.fu-berlin.de>
 <ca275678-8bbd-6185-a3a6-e8e2b6e4e1ff@suse.com>
 <d794bab0-a9b4-eccf-78a4-2b741b24d3b4@physik.fu-berlin.de>
 <61d15fe3ac5ddf12de11ae842c7a8e964afacc8f.camel@redhat.com>
 <67fe9713-8836-e19c-bf52-87648fb501f5@physik.fu-berlin.de>
 <9d6d945c2e44d3c6834631cfe1270a0f09c08444.camel@redhat.com>
 <f55e6ab0-98fd-452b-63a8-a53937a5768d@physik.fu-berlin.de>
Message-ID: <ce79648b-032e-bd37-38c9-f5f0cca515a8@physik.fu-berlin.de>

On 06/25/2018 04:35 PM, John Paul Adrian Glaubitz wrote:
>> Adrian, any update on this? Is there a bug open? We need this fix for
>> our future JDK 11 packages.
> 
> Sorry, I was traveling over the weekend. I should be able to do it later
> today.

Bug report is:

> https://bugs.openjdk.java.net/browse/JDK-8205616

Webrev coming.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From joe.darcy at oracle.com  Mon Jun 25 18:10:33 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 25 Jun 2018 11:10:33 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
Message-ID: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>

Hello,

With the JDK 11 and 12 split fast approaching [1], it is time to work on 
the various start of release update tasks for JDK 12. Those tasks are 
being tracked under the umbrella bug JDK-8205615: "Start of release 
updates for JDK 12".

This thread is to review the build-related portions of the work 
including JDK-8205621: "Increment JDK version for JDK 12." Current webrev:

 ??? http://cr.openjdk.java.net/~darcy/8205615.4/

A handful of test failures still need to be addressed, so there will be 
some minor adjustments to the aggregate set of changes before they are 
pushed.

Cheers,

-Joe

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html



From glaubitz at physik.fu-berlin.de  Mon Jun 25 18:30:50 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 25 Jun 2018 20:30:50 +0200
Subject: Python issues with defpath and jcheck
Message-ID: <af984ef9-5f70-7cf0-8661-97877efb3cf9@physik.fu-berlin.de>

Hi!

I have tried to submit a patch to the submit repository today and was
presented with a Python backtrace. I have already updated both "defpath"
and "jcheck" to their latest version from Mercurual (trace below).

Has anyone else seen this?

glaubitz at z6:..incoming/submit> hg defpath -du glaubitz
** Unknown exception encountered with possibly-broken third-party extension jcheck
** which supports versions unknown of Mercurial.
** Please disable jcheck and try your action again.
** If that fixes the bug please report it to the extension author.
** Python 2.7.15 (default, May  1 2018, 05:55:50) [GCC 7.3.0]
** Mercurial Distributed SCM (version 4.6.1)
** Extensions loaded: strip, mq, histedit, purge, jcheck, defpath
Traceback (most recent call last):
  File "/usr/bin/hg", line 41, in <module>
    dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 90, in run
    status = (dispatch(req) or 0)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 210, in dispatch
    ret = _runcatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 351, in _runcatch
    return _callcatch(ui, _runcatchfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 359, in _callcatch
    return scmutil.callcatch(ui, func)
  File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 160, in callcatch
    return func()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 341, in _runcatchfunc
    return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 971, in _dispatch
    cmdpats, cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 727, in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 979, in _runcommand
    return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 968, in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3599, in mqcommand
    return orig(ui, repo, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
    return func(*args, **kwargs)
  File "/home/glaubitz/upstream/defpath/defpath.py", line 352, in cmd_defpath
    return defpath(ui, repo, peer, peer_push, walk_self, opts)
  File "/home/glaubitz/upstream/defpath/defpath.py", line 287, in defpath
    except util.Abort, x:
AttributeError: 'module' object has no attribute 'Abort'
glaubitz at z6:..incoming/submit>

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Mon Jun 25 18:38:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 25 Jun 2018 11:38:09 -0700
Subject: Python issues with defpath and jcheck
In-Reply-To: <af984ef9-5f70-7cf0-8661-97877efb3cf9@physik.fu-berlin.de>
References: <af984ef9-5f70-7cf0-8661-97877efb3cf9@physik.fu-berlin.de>
Message-ID: <9a79a0f8-9a00-8757-b4ba-e2454bc85354@oracle.com>

Hello John,

I have a patch on review for fixing trees to work with Mercurial 4.6:

http://mail.openjdk.java.net/pipermail/hg-tools-dev/2018-June/000236.html

It looks like the defpath plugin is suffering similar problems. If you 
want to fix your local copy, Mercurial moved the method util.Abort to 
error.Abort.

/Erik


On 2018-06-25 11:30, John Paul Adrian Glaubitz wrote:
> Hi!
>
> I have tried to submit a patch to the submit repository today and was
> presented with a Python backtrace. I have already updated both "defpath"
> and "jcheck" to their latest version from Mercurual (trace below).
>
> Has anyone else seen this?
>
> glaubitz at z6:..incoming/submit> hg defpath -du glaubitz
> ** Unknown exception encountered with possibly-broken third-party extension jcheck
> ** which supports versions unknown of Mercurial.
> ** Please disable jcheck and try your action again.
> ** If that fixes the bug please report it to the extension author.
> ** Python 2.7.15 (default, May  1 2018, 05:55:50) [GCC 7.3.0]
> ** Mercurial Distributed SCM (version 4.6.1)
> ** Extensions loaded: strip, mq, histedit, purge, jcheck, defpath
> Traceback (most recent call last):
>    File "/usr/bin/hg", line 41, in <module>
>      dispatch.run()
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 90, in run
>      status = (dispatch(req) or 0)
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 210, in dispatch
>      ret = _runcatch(req)
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 351, in _runcatch
>      return _callcatch(ui, _runcatchfunc)
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 359, in _callcatch
>      return scmutil.callcatch(ui, func)
>    File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 160, in callcatch
>      return func()
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 341, in _runcatchfunc
>      return _dispatch(req)
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 971, in _dispatch
>      cmdpats, cmdoptions)
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 727, in runcommand
>      ret = _runcommand(ui, options, cmd, d)
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 979, in _runcommand
>      return cmdfunc()
>    File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 968, in <lambda>
>      d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
>    File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
>      return func(*args, **kwargs)
>    File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
>      return func(*args, **kwargs)
>    File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3599, in mqcommand
>      return orig(ui, repo, *args, **kwargs)
>    File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
>      return func(*args, **kwargs)
>    File "/home/glaubitz/upstream/defpath/defpath.py", line 352, in cmd_defpath
>      return defpath(ui, repo, peer, peer_push, walk_self, opts)
>    File "/home/glaubitz/upstream/defpath/defpath.py", line 287, in defpath
>      except util.Abort, x:
> AttributeError: 'module' object has no attribute 'Abort'
> glaubitz at z6:..incoming/submit>
>



From valerie.peng at oracle.com  Mon Jun 25 19:00:35 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 25 Jun 2018 12:00:35 -0700
Subject: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
In-Reply-To: <55A55402-DDA5-483B-B548-18E096BB0765@oracle.com>
References: <57FDA7ED-BFBF-4694-868E-DAB89092BD09@oracle.com>
 <7ad6e500-57c8-2a45-838e-a0ff75d03fd8@oracle.com>
 <40781CC8-0D81-4182-B070-3122AD9E88FE@oracle.com>
 <6C5264A2-3651-4832-AA96-E6B9838CCC67@oracle.com>
 <7668a378-b061-64b2-2873-12ef7fa38dfa@oracle.com>
 <5AFA267F-05A7-474A-9779-FB80120E9DF0@oracle.com>
 <47e0f5d3-a46a-5708-9164-8b556f45ce60@oracle.com>
 <55A55402-DDA5-483B-B548-18E096BB0765@oracle.com>
Message-ID: <d812894d-bc3d-7599-f251-cc8730dd9f1b@oracle.com>

Great, that's good then.

Valerie


On 6/22/2018 5:40 PM, Weijun Wang wrote:
>
>> On Jun 23, 2018, at 8:35 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> On 6/22/2018 3:23 PM, Weijun Wang wrote:
>>>> On Jun 23, 2018, at 2:30 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>>
>>>> Max,
>>>>
>>>> Good catch on the SunRsaSign provider bug.
>>>>
>>>> Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e.
>>>>
>>>> use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSignature is non-null, I think it should check the right one is non-null, i.e. sign -> privKey, verify -> pubKey/fallbackSignature.
>>> Could anything go wrong? This method just ensures one of initSign() or initVerify() is called.
>> Only when the initSign()/initVerify() does not match the subsequent calls of sign()/verify() I suppose.
> I see what you mean.
>
> The Signature class takes care of it:
>
>      public final byte[] sign() throws SignatureException {
>          if (state == SIGN) {
>              return engineSign();
>          }
>          throw new SignatureException("object not initialized for " +
>                                       "signing");
>      }
>
> Thanks
> Max
>
>> Valerie
>>>> In the PSS class engineInitVerify(...) method if the specified key is a MSCAPI public key, then fallbackSignature is set to null and the native verifyPssSignedHash method is used, right?
>>> Yes. The native method only fails when trying to import from a blob.
>>>
>>> Thanks
>>> Max
>>>
>>>> Thanks,
>>>>
>>>> Valerie
>>>>
>>>> On 6/21/2018 10:39 PM, Weijun Wang wrote:
>>>>> Webrev updated at
>>>>>
>>>>>    http://cr.openjdk.java.net/~weijun/8205445/webrev.01
>>>>>
>>>>>
>>>>> I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test.
>>>>>
>>>>> BTW, I commented out the debug code in security.cpp. Once there is a bug I can use it.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>
>>>>>> On Jun 21, 2018, at 11:23 PM, Weijun Wang <weijun.wang at oracle.com>
>>>>>>   wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jun 21, 2018, at 11:07 PM, Xuelei Fan <xuelei.fan at oracle.com>
>>>>>>>   wrote:
>>>>>>>
>>>>>>> Hi Weijun,
>>>>>>>
>>>>>>> The release note and the following notes look reasonable to me.
>>>>>>>
>>>>>>> For the implementation part, could it be a little bit more straightforward if wrapping the new attributes (pss/pssParams/fallbackSignature) and codes (if pss/fallbackSignature, etc) in the PSS subclass?
>>>>>>>
>>>>>> Sounds good. I'll try it.
>>>>>>
>>>>>>
>>>>>>> Did you want to remove the debug code in the security.cpp?  It seems that they are not used any more.
>>>>>>>
>>>>>> Sure I can.
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>>
>>>>>>> Xuelei
>>>>>>>
>>>>>>> On 6/21/2018 4:12 AM, Weijun Wang wrote:
>>>>>>>
>>>>>>>> Please take a review on this change
>>>>>>>>   http://cr.openjdk.java.net/~weijun/8205445/webrev.00/
>>>>>>>>
>>>>>>>>    and the release note at
>>>>>>>>   https://bugs.openjdk.java.net/browse/JDK-8205471
>>>>>>>>
>>>>>>>> The code change adds RSASSA-PSS signature support to the SunMSCAPI provider.
>>>>>>>> Several notes:
>>>>>>>> 1. CryptoAPI (which SunMSCAPI is based on and now a deprecated technology) does not support RSASSA-PSS. In fact, CNG [1] is used to perform the signing and verification. This is certainly not a perfect solution and we are thinking of support CNG in a more sophisticated way in future releases of JDK.
>>>>>>>> 2. For unknown reason, the newly added verification code for RSASSA-PSS does not work correctly (precisely, ::NCryptTranslateHandle returns NTE_INVALID_PARAMETER). A fallback mechanism is added into mscapi/RSASignature.java. A SunRsaSign Signature object is actually used when a SunMSCAPI Signature is initialized to verify an RSASSA-PSS signature.
>>>>>>>> 3. It looks like CNG only supports PSSParamterSpec with the same message hash algorithm and MGF1 hash algorithm, because there is only one algorithm field in BCRYPT_PSS_PADDING_INFO [2]. This is checked when setting the parameter.
>>>>>>>> 4. It looks like CNG only supports RSASSA-PSS using these hash algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. This is not checked at parameter setting but sign() will throw a SignatureException saying "Unrecognised hash algorithm". Since the verify() side uses a fallback SunRsaSign signature, other hash algorithms are supported.
>>>>>>>> Thanks
>>>>>>>> Max
>>>>>>>> [1]
>>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
>>>>>>>>
>>>>>>>> [2]
>>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375529(v=vs.85).aspx
>>>>>>>>
>>>>>>>> [3]
>>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx



From ekaterina.pavlova at oracle.com  Mon Jun 25 19:47:06 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Mon, 25 Jun 2018 12:47:06 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <00f1cb15-8968-5412-e357-79f11d4fd013@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
 <00f1cb15-8968-5412-e357-79f11d4fd013@oracle.com>
Message-ID: <90f60412-c7ec-d9f8-af88-946e383c867f@oracle.com>

Thanks Erik!

-katya

On 6/25/18 8:52 AM, Erik Joelsson wrote:
> Looks ok to me.
> 
> /Erik
> 
> 
> On 2018-06-22 15:22, Ekaterina Pavlova wrote:
>> Fixed and regenerated webrev at the same location:
>> ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>
>> Erik,
>> thanks again for your detailed reviews!
>>
>> -katya
>>
>> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>>> Hello Katya,
>>>
>>> This looks much better, thanks!
>>>
>>> A few suggestions still:
>>>
>>> Main.gmk: instead of repeating the assignment in both if and else block:
>>>
>>> ifeq ($(INCLUDE_GRAAL), true)
>>> ?? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>>> endif
>>>
>>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway.
>>>
>>> In JtregGraalUnit.gmk: Some minor style nits:
>>> 54: align )) with first eval line as you have done with the other eval calls
>>> 118: Since 117 is a one line parameter, please move comma to 117
>>> 133: Same as for 118
>>> 130-132: Please indent 4 spaces for continuation
>>>
>>> /Erik
>>>
>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>>> Erik, Doug,
>>>>
>>>> thank you a lot for your reviews and advises.
>>>> I fixed everything what Erik has pointed out, please see my answers inlined.
>>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
>>>>
>>>> New webrev is here:
>>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>> ?testing: tested by building and running graal unit tests
>>>>
>>>>
>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> Please always include build-dev when reviewing build changes.
>>>>>
>>>>> In general this looks pretty good but there are some details that need fixing.
>>>>>
>>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
>>>>>
>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>>>
>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>>>
>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
>>>>
>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.
>>>>
>>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
>>>>
>>>> ok, renamed
>>>>
>>>>>
>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
>>>>
>>>> ok, removed
>>>>
>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.
>>>>
>>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.
>>>>
>>>>> The all and test-image targets are never called so no need to declare them.
>>>>>
>>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
>>>>> * 43 logic indent 2 spaces
>>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
>>>>> * 58 continuation indent 4 spaces
>>>>> * 88, 89 please break long lines
>>>>> * 90 continuation indent 4 spaces
>>>>> * 99 continuation indent 4 spaces
>>>>> * 120 break before ))
>>>>
>>>> I think I fixed everything
>>>>
>>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>>>
>>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
>>>>
>>>> fixed
>>>>
>>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>>>
>>>> fixed
>>>>
>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>>>>>
>>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
>>>>
>>>> added
>>>>
>>>> thanks,
>>>> -katya
>>>>
>>>>> /Erik
>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>>>>>
>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>>>>>
>>>>>>
>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>>> testing: new tests were executed as part of automatic HS testing for several months.
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> -katya
>>>>>>
>>>>>> p.s.
>>>>>> ?Igor Ignatyev volunteered to sponsor this change. 
>>>>>
>>>>
>>>
>>
> 



From erik.joelsson at oracle.com  Mon Jun 25 20:27:10 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 25 Jun 2018 13:27:10 -0700
Subject: RFR: JDK-8205625: linux-aarch64-cmp-baseline fails builds-tier5
Message-ID: <90a94675-a7d1-e59d-d1b1-d01ef96e91dd@oracle.com>

The open part of this change adds debug versions of the *-cmp-baseline 
Jib profies.

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

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

/Erik



From glaubitz at physik.fu-berlin.de  Mon Jun 25 20:29:15 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 25 Jun 2018 22:29:15 +0200
Subject: Python issues with defpath and jcheck
In-Reply-To: <9a79a0f8-9a00-8757-b4ba-e2454bc85354@oracle.com>
References: <af984ef9-5f70-7cf0-8661-97877efb3cf9@physik.fu-berlin.de>
 <9a79a0f8-9a00-8757-b4ba-e2454bc85354@oracle.com>
Message-ID: <f2c8fa6b-2876-21eb-2d40-b67558fbc398@physik.fu-berlin.de>

Hi Erik!

On 06/25/2018 08:38 PM, Erik Joelsson wrote:
> I have a patch on review for fixing trees to work with Mercurial 4.6:
> 
> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2018-June/000236.html
> 
> It looks like the defpath plugin is suffering similar problems. If you want to fix your local copy, Mercurial moved the method util.Abort to error.Abort.
Indeed. For defpath, it's enough to add "error" to the list of imports
from mercurial.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From mandy.chung at oracle.com  Mon Jun 25 21:09:58 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 25 Jun 2018 14:09:58 -0700
Subject: Review Request JDK-8205627: Replace hardcoded spec version value in
 build.tools.ExtLink taglet
Message-ID: <cbe50680-cab1-0c4d-553f-8d384f428ebf@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205627/webrev.00

ExtLink taglet generates an external link to a JDK documentation page of 
a specific release.  This patch replaces the hardcoded value with the 
value of a system property "extlink.spec.version" passed to the javadoc 
at runtime.  The taglet can't rely on Runtime.version().feature() 
because javadoc is running on the boot JDK.

Mandy


From jonathan.gibbons at oracle.com  Mon Jun 25 21:11:19 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Jun 2018 14:11:19 -0700
Subject: Review Request JDK-8205627: Replace hardcoded spec version value
 in build.tools.ExtLink taglet
In-Reply-To: <cbe50680-cab1-0c4d-553f-8d384f428ebf@oracle.com>
References: <cbe50680-cab1-0c4d-553f-8d384f428ebf@oracle.com>
Message-ID: <5B315A77.80302@oracle.com>

+1

-- Jon

On 06/25/2018 02:09 PM, mandy chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205627/webrev.00
>
> ExtLink taglet generates an external link to a JDK documentation page 
> of a specific release.  This patch replaces the hardcoded value with 
> the value of a system property "extlink.spec.version" passed to the 
> javadoc at runtime.  The taglet can't rely on 
> Runtime.version().feature() because javadoc is running on the boot JDK.
>
> Mandy



From erik.joelsson at oracle.com  Mon Jun 25 21:18:14 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 25 Jun 2018 14:18:14 -0700
Subject: Review Request JDK-8205627: Replace hardcoded spec version value
 in build.tools.ExtLink taglet
In-Reply-To: <cbe50680-cab1-0c4d-553f-8d384f428ebf@oracle.com>
References: <cbe50680-cab1-0c4d-553f-8d384f428ebf@oracle.com>
Message-ID: <0f687865-6649-c12b-2840-a3e9c075381c@oracle.com>

Looks good to me.

/Erik


On 2018-06-25 14:09, mandy chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205627/webrev.00
>
> ExtLink taglet generates an external link to a JDK documentation page 
> of a specific release.? This patch replaces the hardcoded value with 
> the value of a system property "extlink.spec.version" passed to the 
> javadoc at runtime.? The taglet can't rely on 
> Runtime.version().feature() because javadoc is running on the boot JDK.
>
> Mandy



From david.holmes at oracle.com  Mon Jun 25 23:13:04 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Jun 2018 09:13:04 +1000
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
Message-ID: <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>

Hi Joe,

On 26/06/2018 4:10 AM, joe darcy wrote:
> Hello,
> 
> With the JDK 11 and 12 split fast approaching [1], it is time to work on 
> the various start of release update tasks for JDK 12. Those tasks are 
> being tracked under the umbrella bug JDK-8205615: "Start of release 
> updates for JDK 12".
> 
> This thread is to review the build-related portions of the work 
> including JDK-8205621: "Increment JDK version for JDK 12." Current webrev:
> 
>  ??? http://cr.openjdk.java.net/~darcy/8205615.4/

make/autoconf/version-numbers

If we're going to ensure we bump the version and classfile version 
together then we should be able to restore:

DEFAULT_VERSION_CLASSFILE_MAJOR=56  # "`$EXPR $DEFAULT_VERSION_FEATURE + 
44`"

to just:

DEFAULT_VERSION_CLASSFILE_MAJOR="`$EXPR $DEFAULT_VERSION_FEATURE + 44`"

Possibly we could also set:

DEFAULT_ACCEPTABLE_BOOT_VERSIONS

to use DEFAULT_VERSION_FEATURE, DEFAULT_VERSION_FEATURE-1 
DEFAULT_VERSION_FEATURE-2 ? If that is our boot JDK policy. Or will we 
drop 10 at some point in the process?

---

make/common/SetupJavaCompilers.gmk

Again if we're bumping everything en-masse can we use 
DEFAULT_VERSION_FEATURE instead of hard-wiring 12?

And should these be using --release instead of -source + -target?

---

Thanks,
David

> A handful of test failures still need to be addressed, so there will be 
> some minor adjustments to the aggregate set of changes before they are 
> pushed.
> 
> Cheers,
> 
> -Joe
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html
> 


From jonathan.gibbons at oracle.com  Mon Jun 25 23:30:36 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Jun 2018 16:30:36 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>
Message-ID: <5ac9bade-2f62-f843-9645-9ba1d0a0cb3e@oracle.com>



On 6/25/18 4:13 PM, David Holmes wrote:
>
> And should these be using --release instead of -source + -target? 
There might be a chicken-and-egg problem here, since --release needs to 
be appropriately updated as well.? -source and -target are simpler and 
more likely to be easy to update.

-- Jon


From joe.darcy at oracle.com  Mon Jun 25 23:42:03 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 25 Jun 2018 16:42:03 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>
Message-ID: <f3c3bb48-9afb-6b4a-7e21-e2409170b092@oracle.com>

Hi David,


On 6/25/2018 4:13 PM, David Holmes wrote:
> Hi Joe,
>
> On 26/06/2018 4:10 AM, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 and 12 split fast approaching [1], it is time to work 
>> on the various start of release update tasks for JDK 12. Those tasks 
>> are being tracked under the umbrella bug JDK-8205615: "Start of 
>> release updates for JDK 12".
>>
>> This thread is to review the build-related portions of the work 
>> including JDK-8205621: "Increment JDK version for JDK 12." Current 
>> webrev:
>>
>> ???? http://cr.openjdk.java.net/~darcy/8205615.4/
>
> make/autoconf/version-numbers
>
> If we're going to ensure we bump the version and classfile version 
> together then we should be able to restore:
>
> DEFAULT_VERSION_CLASSFILE_MAJOR=56? # "`$EXPR $DEFAULT_VERSION_FEATURE 
> + 44`"
>
> to just:
>
> DEFAULT_VERSION_CLASSFILE_MAJOR="`$EXPR $DEFAULT_VERSION_FEATURE + 44`"

Hmm. I don't know if I want to implicitly mandate we bump the class file 
version and JDK version at the same time.

>
> Possibly we could also set:
>
> DEFAULT_ACCEPTABLE_BOOT_VERSIONS
>
> to use DEFAULT_VERSION_FEATURE, DEFAULT_VERSION_FEATURE-1 
> DEFAULT_VERSION_FEATURE-2 ? If that is our boot JDK policy. Or will we 
> drop 10 at some point in the process?

We will drop 10 at some point. Per the last round of conversations, the 
boot JDK policy is official builds are done with the most recently GA'ed 
release, which right now is 10, but we want to allow the subsequent 
releases too for bootstrap builds, etc.

>
> ---
>
> make/common/SetupJavaCompilers.gmk
>
> Again if we're bumping everything en-masse can we use 
> DEFAULT_VERSION_FEATURE instead of hard-wiring 12?

Same reaction; I think it is acceptable if we explicitly opt-into the 
new source/target values for the build.

If we end up successfully doing the coordinated update for 12 followed 
by the same feat for 13, I'd be more inclined to change these files to 
avoid needing to do explicit updates ;-)

>
> And should these be using --release instead of -source + -target?

That is a reasonable suggestion and I inquired about that myself with 
Erik off-list. There may have been a hiccup using that in the past and 
it is worth looking into again. However, I'd prefer to handle that 
investigation separately to avoid delaying the start-of-12 changes from 
getting back.

Thanks,

-Joe

>
> ---
>
> Thanks,
> David
>
>> A handful of test failures still need to be addressed, so there will 
>> be some minor adjustments to the aggregate set of changes before they 
>> are pushed.
>>
>> Cheers,
>>
>> -Joe
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html
>>



From david.holmes at oracle.com  Mon Jun 25 23:59:32 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Jun 2018 09:59:32 +1000
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <f3c3bb48-9afb-6b4a-7e21-e2409170b092@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>
 <f3c3bb48-9afb-6b4a-7e21-e2409170b092@oracle.com>
Message-ID: <51c4c3e2-7731-3110-46cf-be635d295af5@oracle.com>

Hi Joe,

Okay - no problem. Just looking for opportunities to streamline the process.

Cheers,
David

On 26/06/2018 9:42 AM, joe darcy wrote:
> Hi David,
> 
> 
> On 6/25/2018 4:13 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 26/06/2018 4:10 AM, joe darcy wrote:
>>> Hello,
>>>
>>> With the JDK 11 and 12 split fast approaching [1], it is time to work 
>>> on the various start of release update tasks for JDK 12. Those tasks 
>>> are being tracked under the umbrella bug JDK-8205615: "Start of 
>>> release updates for JDK 12".
>>>
>>> This thread is to review the build-related portions of the work 
>>> including JDK-8205621: "Increment JDK version for JDK 12." Current 
>>> webrev:
>>>
>>> ???? http://cr.openjdk.java.net/~darcy/8205615.4/
>>
>> make/autoconf/version-numbers
>>
>> If we're going to ensure we bump the version and classfile version 
>> together then we should be able to restore:
>>
>> DEFAULT_VERSION_CLASSFILE_MAJOR=56? # "`$EXPR $DEFAULT_VERSION_FEATURE 
>> + 44`"
>>
>> to just:
>>
>> DEFAULT_VERSION_CLASSFILE_MAJOR="`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
> 
> Hmm. I don't know if I want to implicitly mandate we bump the class file 
> version and JDK version at the same time.
> 
>>
>> Possibly we could also set:
>>
>> DEFAULT_ACCEPTABLE_BOOT_VERSIONS
>>
>> to use DEFAULT_VERSION_FEATURE, DEFAULT_VERSION_FEATURE-1 
>> DEFAULT_VERSION_FEATURE-2 ? If that is our boot JDK policy. Or will we 
>> drop 10 at some point in the process?
> 
> We will drop 10 at some point. Per the last round of conversations, the 
> boot JDK policy is official builds are done with the most recently GA'ed 
> release, which right now is 10, but we want to allow the subsequent 
> releases too for bootstrap builds, etc.
> 
>>
>> ---
>>
>> make/common/SetupJavaCompilers.gmk
>>
>> Again if we're bumping everything en-masse can we use 
>> DEFAULT_VERSION_FEATURE instead of hard-wiring 12?
> 
> Same reaction; I think it is acceptable if we explicitly opt-into the 
> new source/target values for the build.
> 
> If we end up successfully doing the coordinated update for 12 followed 
> by the same feat for 13, I'd be more inclined to change these files to 
> avoid needing to do explicit updates ;-)
> 
>>
>> And should these be using --release instead of -source + -target?
> 
> That is a reasonable suggestion and I inquired about that myself with 
> Erik off-list. There may have been a hiccup using that in the past and 
> it is worth looking into again. However, I'd prefer to handle that 
> investigation separately to avoid delaying the start-of-12 changes from 
> getting back.
> 
> Thanks,
> 
> -Joe
> 
>>
>> ---
>>
>> Thanks,
>> David
>>
>>> A handful of test failures still need to be addressed, so there will 
>>> be some minor adjustments to the aggregate set of changes before they 
>>> are pushed.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html
>>>
> 


From glaubitz at physik.fu-berlin.de  Tue Jun 26 00:21:20 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 26 Jun 2018 02:21:20 +0200
Subject: RFR: 8205616: Build fails with system headers after 8204572
Message-ID: <c30298bf-c9bf-0b80-8e34-1190725f132b@physik.fu-berlin.de>

Hi!

Please review this small change contributed by Fridrich Strba of SUSE
and modified by Magnus which fixes the OpenJDK build when configuring
to use system headers for libraries like jpeg and lcms.

The bug report can be found in [1] and the webrev in [2].

Thanks,
Adrian

> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From joe.darcy at oracle.com  Tue Jun 26 00:32:52 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 25 Jun 2018 17:32:52 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <51c4c3e2-7731-3110-46cf-be635d295af5@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <f42e193b-71e4-4e4c-67b4-c84548d55d2b@oracle.com>
 <f3c3bb48-9afb-6b4a-7e21-e2409170b092@oracle.com>
 <51c4c3e2-7731-3110-46cf-be635d295af5@oracle.com>
Message-ID: <ae547331-1156-43b9-fb60-61b88528a6c6@oracle.com>

Hi David,


On 6/25/2018 4:59 PM, David Holmes wrote:
> Hi Joe,
>
> Okay - no problem. Just looking for opportunities to streamline the 
> process.
>
> Cheers,
> David
>

I agree with the goal of striving for the a more streamlined process, 
but don't want to have to use it just yet ;-)

-Joe


From VicWang at zhaoxin.com  Tue Jun 26 06:46:28 2018
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Tue, 26 Jun 2018 06:46:28 +0000
Subject: =?utf-8?B?562U5aSNOiBJbnF1aXJ5IHdoZXRoZXIgamRrOHUgY2FuIGNvbXBpbGUgd2l0?=
 =?utf-8?B?aCBpY2PvvJ8=?=
In-Reply-To: <CAOEheN5pjnOGmY89TCjA-FYdck35QVfqTZs4nMde_Q9EgXmTvA@mail.gmail.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
 <CAOEheN5pjnOGmY89TCjA-FYdck35QVfqTZs4nMde_Q9EgXmTvA@mail.gmail.com>
Message-ID: <3d11f69b67684ac4889922301dbbd260@zhaoxin.com>

Hi  Yumin:

       When exporting CC=icc and CXX=icc, and modifying some lines in the configure files, it can work to generate the Makefile successfully.  But it occurs some errors in the end when execute ?make images?.
       The first error is as follows, does it harmful? And how to eliminate these errors?
>Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
>Classes: Table size 32 (5 bits), shift 1, max chain depth 3
>Cache: Table size 32 (5 bits), shift 1, max chain depth 3
>Generating X11 wrapper (64-bit version)
>Generating beaninfo
>Generating Nimbus source files
>[Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 11.0, 16.0)
>Verifying /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/gensrc_x11wrappers/sizes.64.verification.tmp to /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/gensrc_x11wrappers/sizes.64
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
>[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
>[Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
>Generating HTML DTD file
>Compiling 4 files for BUILD_BREAKITERATOR

       And the other kind of error is :
              >ld: /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/bin/extcheck: local symbol `__intel_sse2_strrchr' in /opt/intel/composer_xe_2015.2.164/compiler/lib/intel64/libirc.a(sse2_strrchr.o) is referenced by DSO
>ld: final link failed: Bad value
>ld: /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/objs/java_objs/java: local symbol `__intel_sse2_strrchr' in /opt/intel/composer_xe_2015.2.164/compiler/lib/intel64/libirc.a(sse2_strrchr.o) is referenced by DSO
>ld: final link failed: Bad value
make[2]: *** [/home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/bin/extcheck] Error 1
>make[2]: *** Waiting for unfinished jobs....
>make[2]: *** [/home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/objs/java_objs/java] Error 1

       Does anyone have some suggestions for these? Thanks!

Best Regards!
VicWang

???: yumin qi [mailto:yumin.qi at gmail.com]
????: 2018?6?25? 23:43
???: Vic Wang(BJ-RD) <VicWang at zhaoxin.com>
??: build-dev at openjdk.java.net
??: Re: Inquiry whether jdk8u can compile with icc?

Hi, Vic

  You can try the help:
       sh configure --help
  Also
       export CC='your ICC'

Yumin

On Mon, Jun 25, 2018 at 8:20 AM Vic Wang(BJ-RD) <VicWang at zhaoxin.com<mailto:VicWang at zhaoxin.com>> wrote:
Hi,

       I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler.
       How to configure jvm before using ICC compiling?
       If there are any tips for ICC compiling, please let me know. Thanks a lot.

Best Regards!
VicWang


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From VicWang at zhaoxin.com  Tue Jun 26 06:56:52 2018
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Tue, 26 Jun 2018 06:56:52 +0000
Subject: =?gb2312?B?tPC4tDogSW5xdWlyeSB3aGV0aGVyIGpkazh1IGNhbiBjb21waWxlIHdpdGgg?=
 =?gb2312?B?aWNjo78=?=
In-Reply-To: <4d86af32-21c1-2680-aec3-7fa8d45519b2@oracle.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
 <4d86af32-21c1-2680-aec3-7fa8d45519b2@oracle.com>
Message-ID: <7a9dfa8113d24e88ae70dd0eba6539ac@zhaoxin.com>

Hi Erik,

Yeah, it need to modify some configure files before generating the Makefile file. But I am not lucky to build the binary successfully. It occurs some ld's error.
>ld: /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/objs/java_objs/java: local symbol `__intel_sse2_strrchr' in /opt/intel/composer_xe_2015.2.164/compiler/lib/intel64/libirc.a(sse2_strrchr.o) is referenced by DSO
>ld: final link failed: Bad value
Do you have any ideas for this?
I want to build JVM on intel i5-6600k platform.
Thanks very much.

Best Regards!
VicWang


-----????-----
???: Erik Joelsson [mailto:erik.joelsson at oracle.com]
????: 2018?6?26? 0:20
???: Vic Wang(BJ-RD) <VicWang at zhaoxin.com>; build-dev at openjdk.java.net
??: Re: Inquiry whether jdk8u can compile with icc?

Hello,

There is no support for ICC as far as I know. If ICC is compatible with the default toolchain for the platform, you may get something to work, but I doubt you will have any luck without modifying build logic.

Which platform are you trying to build on?

/Erik


On 2018-06-25 08:19, Vic Wang(BJ-RD) wrote:
> Hi,
>
>         I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler.
>         How to configure jvm before using ICC compiling?
>         If there are any tips for ICC compiling, please let me know. Thanks a lot.
>
> Best Regards!
> VicWang
>
>
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.



?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From jini.george at oracle.com  Tue Jun 26 07:25:22 2018
From: jini.george at oracle.com (Jini George)
Date: Tue, 26 Jun 2018 12:55:22 +0530
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <5ba6916b-35bf-617e-fff8-93f096162047@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
 <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
 <fa7627f5-6953-498e-8e2a-6d80112081f1@default>
 <5ba6916b-35bf-617e-fff8-93f096162047@oracle.com>
Message-ID: <8e5f1747-3d1f-7381-549c-965ee3d5ef08@oracle.com>

Ping - Gentle reminder !

Thanks,
Jini.

On 6/25/2018 3:41 PM, Jini George wrote:
> Thank you, Sharath. May I have a Reviewer to take a look at the 
> MacosxDebuggerLocal code?
> 
> Thanks,
> Jini.
> 
> On 6/25/2018 1:52 PM, Sharath Ballal wrote:
>> Hi Jini,
>>
>> Changes in MacosxDebuggerLocal.m looks good.
>>
>> Thanks,
>> Sharath
>>
>>
>> -----Original Message-----
>> From: Jini George
>> Sent: Sunday, June 24, 2018 11:07 PM
>> To: Erik Joelsson; serviceability-dev at openjdk.java.net; 
>> build-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated 
>> PT_ATTACH with PT_ATTACHEXC
>>
>> Hi Erik,
>>
>> Thank you very much for looking into this. I have addressed your 
>> comments. The latest webrev is at:
>>
>> http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/
>>
>> Thank you,
>> Jini.
>>
>>
>> On 6/23/2018 3:31 AM, Erik Joelsson wrote:
>>> Hello Jini,
>>>
>>> In general this looks pretty good, but it's also breaking some new
>>> ground as it's adding generation of native source in the java gensrc
>>> step. Mixing native code with the java code that the genrcs targets
>>> and gensrc output directories are meant for seems ok for now, but may
>>> cause trouble in the future. I'm going to accept it for now though.
>>>
>>> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in
>>> its own section (as delimited by the 80x # lines) and put that whole
>>> thing inside a conditional for macosx. Also please break line 47 (for
>>> recipe lines, indent with tab and 4 additional spaces for 
>>> continuation [1]).
>>>
>>> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be
>>> enough as that will implicitly add the same directories as header dirs
>>> by default. At least that's the intention.
>>>
>>> /Erik
>>>
>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>>
>>> On 2018-06-22 11:11, Jini George wrote:
>>>> Hi all,
>>>>
>>>> [Including build-dev also since this includes build related changes].
>>>>
>>>> Requesting reviews for:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace
>>>> the deprecated PT_ATTACH with PT_ATTACHEXC)
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>>>
>>>> This is the follow-up solution for the temporary restoration of
>>>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042
>>>> (several serviceability/sa tests timed out on MacOS X), which was
>>>> done in Oct 2017. The mails related to this are at:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August
>>>> /021702.html
>>>>
>>>>
>>>> Changes as compared to the patch sent last year
>>>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>>>
>>>> * Addressed the review comments which were provided by Poonam, Dan,
>>>> Dmitry.
>>>> * A major change as compared to what was done last year is that the
>>>> MIG generated files have been included as a part of the JDK build
>>>> process.
>>>> * The test case which was provided in the patch last year is no
>>>> longer required since we have ClhsdbAttach.java testing the same
>>>> functionality as a part of the SA testsuite now.
>>>> * Other than that, some minor improvements have been done wrt error
>>>> handling.
>>>>
>>>> The steps for the proposed solution have been provided in JBS.
>>>>
>>>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 platforms.
>>>>
>>>> Thanks to Sharath, Robin, Gerard and Dan for looking into the changes
>>>> and providing valuable comments.
>>>>
>>>> Thanks,
>>>> Jini.
>>>


From magnus.ihse.bursie at oracle.com  Tue Jun 26 07:50:46 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 26 Jun 2018 09:50:46 +0200
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
Message-ID: <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com>

> 23 juni 2018 kl. 00:22 skrev Ekaterina Pavlova <ekaterina.pavlova at oracle.com>:
> 
> Fixed and regenerated webrev at the same location:
> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html

Better, but not done yet. 

In JtregGraalUnit.gmk: line 52-53 should be on a single line. 

The SRC list for BUILD_VM_COMPILER_TESTS looks insane, but the root cause here is the weird layout on disk. But the .test part really surprises me, I thought we had a clear rule to have no test source in src?!

In lib-tests.m4: Copy paste error: AC_MSG_ERROR([You must specify the path to tonga jar])

The addition in RunTests.gmk and TestCommon.gmk should be guarded by:
  ifeq ($(INCLUDE_GRAAL), true)

/Magnus

> 
> Erik,
> thanks again for your detailed reviews!
> 
> -katya
> 
>> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>> Hello Katya,
>> This looks much better, thanks!
>> A few suggestions still:
>> Main.gmk: instead of repeating the assignment in both if and else block:
>> ifeq ($(INCLUDE_GRAAL), true)
>>   JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>> endif
>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway.
>> In JtregGraalUnit.gmk: Some minor style nits:
>> 54: align )) with first eval line as you have done with the other eval calls
>> 118: Since 117 is a one line parameter, please move comma to 117
>> 133: Same as for 118
>> 130-132: Please indent 4 spaces for continuation
>> /Erik
>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>> Erik, Doug,
>>> 
>>> thank you a lot for your reviews and advises.
>>> I fixed everything what Erik has pointed out, please see my answers inlined.
>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
>>> 
>>> New webrev is here:
>>>   webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>>      JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>  testing: tested by building and running graal unit tests
>>> 
>>> 
>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>> Hello,
>>>> 
>>>> Please always include build-dev when reviewing build changes.
>>>> 
>>>> In general this looks pretty good but there are some details that need fixing.
>>>> 
>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
>>>> 
>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>> Hi All,
>>>>> 
>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>> 
>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>> 
>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
>>> 
>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.
>>> 
>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
>>> 
>>> ok, renamed
>>> 
>>>> 
>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
>>> 
>>> ok, removed
>>> 
>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.
>>> 
>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.
>>> 
>>>> The all and test-image targets are never called so no need to declare them.
>>>> 
>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
>>>> * 43 logic indent 2 spaces
>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
>>>> * 58 continuation indent 4 spaces
>>>> * 88, 89 please break long lines
>>>> * 90 continuation indent 4 spaces
>>>> * 99 continuation indent 4 spaces
>>>> * 120 break before ))
>>> 
>>> I think I fixed everything
>>> 
>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>> 
>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
>>> 
>>> fixed
>>> 
>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>> 
>>> fixed
>>> 
>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>>>> 
>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
>>> 
>>> added
>>> 
>>> thanks,
>>> -katya
>>> 
>>>> /Erik
>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>>>> 
>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>>>> 
>>>>> 
>>>>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>  webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>> testing: new tests were executed as part of automatic HS testing for several months.
>>>>> 
>>>>> 
>>>>> thanks,
>>>>> -katya
>>>>> 
>>>>> p.s.
>>>>>  Igor Ignatyev volunteered to sponsor this change. 
>>>> 
>>> 
> 


From Alan.Bateman at oracle.com  Tue Jun 26 09:23:28 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 26 Jun 2018 10:23:28 +0100
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
Message-ID: <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>

On 25/06/2018 19:10, joe darcy wrote:
> Hello,
>
> With the JDK 11 and 12 split fast approaching [1], it is time to work 
> on the various start of release update tasks for JDK 12. Those tasks 
> are being tracked under the umbrella bug JDK-8205615: "Start of 
> release updates for JDK 12".
>
> This thread is to review the build-related portions of the work 
> including JDK-8205621: "Increment JDK version for JDK 12." Current 
> webrev:
>
> ??? http://cr.openjdk.java.net/~darcy/8205615.4/
>
> A handful of test failures still need to be addressed, so there will 
> be some minor adjustments to the aggregate set of changes before they 
> are pushed.
>
I looked through the changes with the exception of javac and 
test/langtools and it all looks okay to me. The updates to the tests, 
for MR JARs in particular, look fine.

I see David brought up the -source/-target 12 in SetupJavaCompilers.gmk. 
I assume it wouldn't be too hard to have that use the value from 
DEFAULT_VERSION_FEATURE.

Keeping 10 in the list of DEFAULT_ACCEPTABLE_BOOT_VERSIONS seems right 
for now, I assume 10 will be dropped from that list as soon as 11 ships.

-Alan






From erik.joelsson at oracle.com  Tue Jun 26 14:33:53 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 26 Jun 2018 07:33:53 -0700
Subject: RFR: 8205616: Build fails with system headers after 8204572
In-Reply-To: <c30298bf-c9bf-0b80-8e34-1190725f132b@physik.fu-berlin.de>
References: <c30298bf-c9bf-0b80-8e34-1190725f132b@physik.fu-berlin.de>
Message-ID: <e8c5bda0-1af0-c61b-413c-6e0742c3970f@oracle.com>

Looks good.

/Erik


On 2018-06-25 17:21, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Please review this small change contributed by Fridrich Strba of SUSE
> and modified by Magnus which fixes the OpenJDK build when configuring
> to use system headers for libraries like jpeg and lcms.
>
> The bug report can be found in [1] and the webrev in [2].
>
> Thanks,
> Adrian
>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
>> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/



From glaubitz at physik.fu-berlin.de  Tue Jun 26 14:35:13 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 26 Jun 2018 16:35:13 +0200
Subject: RFR: 8205616: Build fails with system headers after 8204572
In-Reply-To: <e8c5bda0-1af0-c61b-413c-6e0742c3970f@oracle.com>
References: <c30298bf-c9bf-0b80-8e34-1190725f132b@physik.fu-berlin.de>
 <e8c5bda0-1af0-c61b-413c-6e0742c3970f@oracle.com>
Message-ID: <ecb37b2c-8e43-2252-6209-a17bc487dcb7@physik.fu-berlin.de>

Hi Erik!

Thanks!

I assume since this affects the build infrastructure only, one reviewer
is enough, correct?

Adrian

On 06/26/2018 04:33 PM, Erik Joelsson wrote:
> Looks good.
> 
> /Erik
> 
> 
> On 2018-06-25 17:21, John Paul Adrian Glaubitz wrote:
>> Hi!
>>
>> Please review this small change contributed by Fridrich Strba of SUSE
>> and modified by Magnus which fixes the OpenJDK build when configuring
>> to use system headers for libraries like jpeg and lcms.
>>
>> The bug report can be found in [1] and the webrev in [2].
>>
>> Thanks,
>> Adrian
>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
>>> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Tue Jun 26 14:46:12 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 26 Jun 2018 07:46:12 -0700
Subject: =?UTF-8?Q?Re:_=e7=ad=94=e5=a4=8d:_Inquiry_whether_jdk8u_can_compile?=
 =?UTF-8?B?IHdpdGggaWNj77yf?=
In-Reply-To: <7a9dfa8113d24e88ae70dd0eba6539ac@zhaoxin.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
 <4d86af32-21c1-2680-aec3-7fa8d45519b2@oracle.com>
 <7a9dfa8113d24e88ae70dd0eba6539ac@zhaoxin.com>
Message-ID: <65edd028-b9f1-5b5d-ec71-27a526200722@oracle.com>

Hello VicWang,

The native source for Linux is written for GCC. Making it work with a 
different compiler is likely a lot of work that requires deep knowledge 
both in the JVM source and with the particular compiler. I have neither. 
Even if you got it to compile it's unlikely to work well since nobody 
(that I know of) has tested the combination before.

I recommend that you build with the supported compiler instead. What do 
you expect to gain from using ICC?

/Erik


On 2018-06-25 23:56, Vic Wang(BJ-RD) wrote:
> Hi Erik,
>
> Yeah, it need to modify some configure files before generating the Makefile file. But I am not lucky to build the binary successfully. It occurs some ld's error.
>> ld: /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/objs/java_objs/java: local symbol `__intel_sse2_strrchr' in /opt/intel/composer_xe_2015.2.164/compiler/lib/intel64/libirc.a(sse2_strrchr.o) is referenced by DSO
>> ld: final link failed: Bad value
> Do you have any ideas for this?
> I want to build JVM on intel i5-6600k platform.
> Thanks very much.
>
> Best Regards!
> VicWang
>
>
> -----????-----
> ???: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> ????: 2018?6?26? 0:20
> ???: Vic Wang(BJ-RD) <VicWang at zhaoxin.com>; build-dev at openjdk.java.net
> ??: Re: Inquiry whether jdk8u can compile with icc?
>
> Hello,
>
> There is no support for ICC as far as I know. If ICC is compatible with the default toolchain for the platform, you may get something to work, but I doubt you will have any luck without modifying build logic.
>
> Which platform are you trying to build on?
>
> /Erik
>
>
> On 2018-06-25 08:19, Vic Wang(BJ-RD) wrote:
>> Hi,
>>
>>          I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler.
>>          How to configure jvm before using ICC compiling?
>>          If there are any tips for ICC compiling, please let me know. Thanks a lot.
>>
>> Best Regards!
>> VicWang
>>
>>
>> ?????
>> ?????????????????????????????????????????????????????
>> CONFIDENTIAL NOTE:
>> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
>
>
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.



From erik.joelsson at oracle.com  Tue Jun 26 14:51:04 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 26 Jun 2018 07:51:04 -0700
Subject: RFR: 8205616: Build fails with system headers after 8204572
In-Reply-To: <ecb37b2c-8e43-2252-6209-a17bc487dcb7@physik.fu-berlin.de>
References: <c30298bf-c9bf-0b80-8e34-1190725f132b@physik.fu-berlin.de>
 <e8c5bda0-1af0-c61b-413c-6e0742c3970f@oracle.com>
 <ecb37b2c-8e43-2252-6209-a17bc487dcb7@physik.fu-berlin.de>
Message-ID: <139c7b6f-a5cb-07e9-8140-b06d93902ca7@oracle.com>

Correct.

/Erik


On 2018-06-26 07:35, John Paul Adrian Glaubitz wrote:
> Hi Erik!
>
> Thanks!
>
> I assume since this affects the build infrastructure only, one reviewer
> is enough, correct?
>
> Adrian
>
> On 06/26/2018 04:33 PM, Erik Joelsson wrote:
>> Looks good.
>>
>> /Erik
>>
>>
>> On 2018-06-25 17:21, John Paul Adrian Glaubitz wrote:
>>> Hi!
>>>
>>> Please review this small change contributed by Fridrich Strba of SUSE
>>> and modified by Magnus which fixes the OpenJDK build when configuring
>>> to use system headers for libraries like jpeg and lcms.
>>>
>>> The bug report can be found in [1] and the webrev in [2].
>>>
>>> Thanks,
>>> Adrian
>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
>>>> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/



From ekaterina.pavlova at oracle.com  Tue Jun 26 16:08:30 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Tue, 26 Jun 2018 09:08:30 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
 <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com>
Message-ID: <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com>

Hello Magnus,

On 6/26/18 12:50 AM, Magnus Ihse Bursie wrote:
> 23 juni 2018 kl. 00:22 skrev Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>>:
> 
>> Fixed and regenerated webrev at the same location:
>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
> 
> Better, but not done yet.
> 
> In JtregGraalUnit.gmk: line 52-53 should be on a single line.

will fix

> The SRC list for?BUILD_VM_COMPILER_TESTS looks insane, but the root cause here is the weird layout on disk. But the .test part really surprises me, I thought we had a clear rule to have no test source in src?!

These are not jtreg tests, these are graalunit tests which are coming as part of Graal port (from Graal ws).
We can't change this layout right now.

  
> In lib-tests.m4: Copy paste error:?AC_MSG_ERROR([You must specify the path to tonga jar])

ops, will fix

> The addition in RunTests.gmk and TestCommon.gmk should be guarded by:
>  ? ifeq ($(INCLUDE_GRAAL), true)
  
ok, will look

> /Magnus
> 
>>
>> Erik,
>> thanks again for your detailed reviews!
>>
>> -katya
>>
>> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>>> Hello Katya,
>>> This looks much better, thanks!
>>> A few suggestions still:
>>> Main.gmk: instead of repeating the assignment in both if and else block:
>>> ifeq ($(INCLUDE_GRAAL), true)
>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>>> endif
>>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway.
>>> In JtregGraalUnit.gmk: Some minor style nits:
>>> 54: align )) with first eval line as you have done with the other eval calls
>>> 118: Since 117 is a one line parameter, please move comma to 117
>>> 133: Same as for 118
>>> 130-132: Please indent 4 spaces for continuation
>>> /Erik
>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>>> Erik, Doug,
>>>>
>>>> thank you a lot for your reviews and advises.
>>>> I fixed everything what Erik has pointed out, please see my answers inlined.
>>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
>>>>
>>>> New webrev is here:
>>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>> ?testing: tested by building and running graal unit tests
>>>>
>>>>
>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> Please always include build-dev when reviewing build changes.
>>>>>
>>>>> In general this looks pretty good but there are some details that need fixing.
>>>>>
>>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
>>>>>
>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>>>
>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>>>
>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
>>>>
>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.
>>>>
>>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
>>>>
>>>> ok, renamed
>>>>
>>>>>
>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
>>>>
>>>> ok, removed
>>>>
>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.
>>>>
>>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.
>>>>
>>>>> The all and test-image targets are never called so no need to declare them.
>>>>>
>>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
>>>>> * 43 logic indent 2 spaces
>>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
>>>>> * 58 continuation indent 4 spaces
>>>>> * 88, 89 please break long lines
>>>>> * 90 continuation indent 4 spaces
>>>>> * 99 continuation indent 4 spaces
>>>>> * 120 break before ))
>>>>
>>>> I think I fixed everything
>>>>
>>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>>>
>>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
>>>>
>>>> fixed
>>>>
>>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>>>
>>>> fixed
>>>>
>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>>>>>
>>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
>>>>
>>>> added
>>>>
>>>> thanks,
>>>> -katya
>>>>
>>>>> /Erik
>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>>>>>
>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>>>>>
>>>>>>
>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>>> testing: new tests were executed as part of automatic HS testing for several months.
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> -katya
>>>>>>
>>>>>> p.s.
>>>>>> ?Igor Ignatyev volunteered to sponsor this change.
>>>>>
>>>>
>>



From joe.darcy at oracle.com  Tue Jun 26 16:30:08 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 26 Jun 2018 09:30:08 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
Message-ID: <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>

Hi Alan,


On 6/26/2018 2:23 AM, Alan Bateman wrote:
> On 25/06/2018 19:10, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 and 12 split fast approaching [1], it is time to work 
>> on the various start of release update tasks for JDK 12. Those tasks 
>> are being tracked under the umbrella bug JDK-8205615: "Start of 
>> release updates for JDK 12".
>>
>> This thread is to review the build-related portions of the work 
>> including JDK-8205621: "Increment JDK version for JDK 12." Current 
>> webrev:
>>
>> ??? http://cr.openjdk.java.net/~darcy/8205615.4/

>>
>> A handful of test failures still need to be addressed, so there will 
>> be some minor adjustments to the aggregate set of changes before they 
>> are pushed.
>>

Slightly modified version now up in

 ??? http://cr.openjdk.java.net/~darcy/8205615.5/

* Changed projected ship date in make/autoconf/version-numbers
* Some changes and merges to jdeprscan; I'll ask Stuart to review those

Some hotspot test changes in the work too based on a separate review thread.

> I looked through the changes with the exception of javac and 
> test/langtools and it all looks okay to me. The updates to the tests, 
> for MR JARs in particular, look fine.

Hopefully after this round of changes the MR JAR tests won't need any 
more updates when we go from 12 -> 13 and beyond.

>
> I see David brought up the -source/-target 12 in 
> SetupJavaCompilers.gmk. I assume it wouldn't be too hard to have that 
> use the value from DEFAULT_VERSION_FEATURE.
>
> Keeping 10 in the list of DEFAULT_ACCEPTABLE_BOOT_VERSIONS seems right 
> for now, I assume 10 will be dropped from that list as soon as 11 ships.
>

That is my understanding of the policy discussion from Mark:

http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html

Thanks,

-Joe


From erik.joelsson at oracle.com  Tue Jun 26 16:40:21 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 26 Jun 2018 09:40:21 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
 <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
Message-ID: <d657c9bf-78e8-4168-4944-64aff9920e94@oracle.com>

Build changes look good. I'm happy at least those are very few at this 
point.

To make the updating of "-source 12 -target 12" easier in the future, we 
could introduce another variable in version-numbers that is used for 
these flags in SetupJavaCompilers.gmk so we get the build changes down 
to one file next time. I can do that as a followup in 12.

/Erik


On 2018-06-26 09:30, joe darcy wrote:
> Hi Alan,
>
>
> On 6/26/2018 2:23 AM, Alan Bateman wrote:
>> On 25/06/2018 19:10, joe darcy wrote:
>>> Hello,
>>>
>>> With the JDK 11 and 12 split fast approaching [1], it is time to 
>>> work on the various start of release update tasks for JDK 12. Those 
>>> tasks are being tracked under the umbrella bug JDK-8205615: "Start 
>>> of release updates for JDK 12".
>>>
>>> This thread is to review the build-related portions of the work 
>>> including JDK-8205621: "Increment JDK version for JDK 12." Current 
>>> webrev:
>>>
>>> ??? http://cr.openjdk.java.net/~darcy/8205615.4/
>
>>>
>>> A handful of test failures still need to be addressed, so there will 
>>> be some minor adjustments to the aggregate set of changes before 
>>> they are pushed.
>>>
>
> Slightly modified version now up in
>
> ??? http://cr.openjdk.java.net/~darcy/8205615.5/
>
> * Changed projected ship date in make/autoconf/version-numbers
> * Some changes and merges to jdeprscan; I'll ask Stuart to review those
>
> Some hotspot test changes in the work too based on a separate review 
> thread.
>
>> I looked through the changes with the exception of javac and 
>> test/langtools and it all looks okay to me. The updates to the tests, 
>> for MR JARs in particular, look fine.
>
> Hopefully after this round of changes the MR JAR tests won't need any 
> more updates when we go from 12 -> 13 and beyond.
>
>>
>> I see David brought up the -source/-target 12 in 
>> SetupJavaCompilers.gmk. I assume it wouldn't be too hard to have that 
>> use the value from DEFAULT_VERSION_FEATURE.
>>
>> Keeping 10 in the list of DEFAULT_ACCEPTABLE_BOOT_VERSIONS seems 
>> right for now, I assume 10 will be dropped from that list as soon as 
>> 11 ships.
>>
>
> That is my understanding of the policy discussion from Mark:
>
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html
>
> Thanks,
>
> -Joe



From yumin.qi at gmail.com  Tue Jun 26 16:41:08 2018
From: yumin.qi at gmail.com (yumin qi)
Date: Tue, 26 Jun 2018 09:41:08 -0700
Subject: =?UTF-8?Q?Re=3A_Inquiry_whether_jdk8u_can_compile_with_icc=EF=BC=9F?=
In-Reply-To: <7a9dfa8113d24e88ae70dd0eba6539ac@zhaoxin.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
 <4d86af32-21c1-2680-aec3-7fa8d45519b2@oracle.com>
 <7a9dfa8113d24e88ae70dd0eba6539ac@zhaoxin.com>
Message-ID: <CAOEheN4DUxR-pbk5LXuB8ou7VqTVzE-+DTifvO8udsNMfkjHNg@mail.gmail.com>

The first error is known issue and fixed in jdk 9:
https://bugs.openjdk.java.net/browse/JDK-8016451

For the second one, I am not familiar with icc/icpc, it looks the linker
find a static version which is not an expected version. you need to check
the detail of library dependency.

Yumin

On Mon, Jun 25, 2018 at 11:57 PM Vic Wang(BJ-RD) <VicWang at zhaoxin.com>
wrote:

> Hi Erik,
>
> Yeah, it need to modify some configure files before generating the
> Makefile file. But I am not lucky to build the binary successfully. It
> occurs some ld's error.
> >ld:
> /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/objs/java_objs/java:
> local symbol `__intel_sse2_strrchr' in
> /opt/intel/composer_xe_2015.2.164/compiler/lib/intel64/libirc.a(sse2_strrchr.o)
> is referenced by DSO
> >ld: final link failed: Bad value
> Do you have any ideas for this?
> I want to build JVM on intel i5-6600k platform.
> Thanks very much.
>
> Best Regards!
> VicWang
>
>
> -----????-----
> ???: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> ????: 2018?6?26? 0:20
> ???: Vic Wang(BJ-RD) <VicWang at zhaoxin.com>; build-dev at openjdk.java.net
> ??: Re: Inquiry whether jdk8u can compile with icc?
>
> Hello,
>
> There is no support for ICC as far as I know. If ICC is compatible with
> the default toolchain for the platform, you may get something to work, but
> I doubt you will have any luck without modifying build logic.
>
> Which platform are you trying to build on?
>
> /Erik
>
>
> On 2018-06-25 08:19, Vic Wang(BJ-RD) wrote:
> > Hi,
> >
> >         I get the openjdk-jdk8u-jdk8u source code, and I want to compile
> jvm with ICC compiler.
> >         How to configure jvm before using ICC compiling?
> >         If there are any tips for ICC compiling, please let me know.
> Thanks a lot.
> >
> > Best Regards!
> > VicWang
> >
> >
> > ?????
> > ?????????????????????????????????????????????????????
> > CONFIDENTIAL NOTE:
> > This email contains confidential or legally privileged information and
> is for the sole use of its intended recipient. Any unauthorized review,
> use, copying or forwarding of this email or the content of this email is
> strictly prohibited.
>
>
>
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is
> for the sole use of its intended recipient. Any unauthorized review, use,
> copying or forwarding of this email or the content of this email is
> strictly prohibited.
>


From paul.sandoz at oracle.com  Tue Jun 26 17:11:37 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 26 Jun 2018 10:11:37 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
 <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
Message-ID: <DD8C3D81-3AAF-4F3D-8765-AC1E818E7CA3@oracle.com>

This generally looks good. Having it all consolidated helps a lot, and we are slowly chipping away at reducing this for each release.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java
?

 118         V55(55, 0),   // JDK 11: constant dynamic
 119         V56(56, 0);   // JDK 12


We can add nestmates to the list of stuff in 11

Paul.

> On Jun 26, 2018, at 9:30 AM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hi Alan,
> 
> 
> On 6/26/2018 2:23 AM, Alan Bateman wrote:
>> On 25/06/2018 19:10, joe darcy wrote:
>>> Hello,
>>> 
>>> With the JDK 11 and 12 split fast approaching [1], it is time to work on the various start of release update tasks for JDK 12. Those tasks are being tracked under the umbrella bug JDK-8205615: "Start of release updates for JDK 12".
>>> 
>>> This thread is to review the build-related portions of the work including JDK-8205621: "Increment JDK version for JDK 12." Current webrev:
>>> 
>>>     http://cr.openjdk.java.net/~darcy/8205615.4/
> 
>>> 
>>> A handful of test failures still need to be addressed, so there will be some minor adjustments to the aggregate set of changes before they are pushed.
>>> 
> 
> Slightly modified version now up in
> 
>     http://cr.openjdk.java.net/~darcy/8205615.5/
> 
> * Changed projected ship date in make/autoconf/version-numbers
> * Some changes and merges to jdeprscan; I'll ask Stuart to review those
> 
> Some hotspot test changes in the work too based on a separate review thread.
> 
>> I looked through the changes with the exception of javac and test/langtools and it all looks okay to me. The updates to the tests, for MR JARs in particular, look fine.
> 
> Hopefully after this round of changes the MR JAR tests won't need any more updates when we go from 12 -> 13 and beyond.
> 
>> 
>> I see David brought up the -source/-target 12 in SetupJavaCompilers.gmk. I assume it wouldn't be too hard to have that use the value from DEFAULT_VERSION_FEATURE.
>> 
>> Keeping 10 in the list of DEFAULT_ACCEPTABLE_BOOT_VERSIONS seems right for now, I assume 10 will be dropped from that list as soon as 11 ships.
>> 
> 
> That is my understanding of the policy discussion from Mark:
> 
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html
> 
> Thanks,
> 
> -Joe



From joe.darcy at oracle.com  Tue Jun 26 17:55:33 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 26 Jun 2018 10:55:33 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <DD8C3D81-3AAF-4F3D-8765-AC1E818E7CA3@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
 <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
 <DD8C3D81-3AAF-4F3D-8765-AC1E818E7CA3@oracle.com>
Message-ID: <213666cd-aae9-513c-f891-c0f754bb81f9@oracle.com>

On 6/26/2018 10:11 AM, Paul Sandoz wrote:
> This generally looks good. Having it all consolidated helps a lot, and we are slowly chipping away at reducing this for each release.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java
> ?
>
>   118         V55(55, 0),   // JDK 11: constant dynamic
>   119         V56(56, 0);   // JDK 12
>
>
> We can add nestmates to the list of stuff in 11
>
>

Added ", nest mates" to the list for 11.

Thanks,

-Joe


From sundararajan.athijegannathan at oracle.com  Wed Jun 27 04:19:33 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 27 Jun 2018 09:49:33 +0530
Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning
 to nashorn, jjs
In-Reply-To: <5B330F8B.1050509@oracle.com>
References: <5B330F8B.1050509@oracle.com>
Message-ID: <5B331055.4060305@oracle.com>

Forgot to CC build-dev for makefile changes.

-Sundar

On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote:
> Please review.
>
> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>
> Related:
>
> JEP http://openjdk.java.net/jeps/335
> CSR https://bugs.openjdk.java.net/browse/JDK-8205594
>
> Thanks,
> -Sundar
>


From david.holmes at oracle.com  Wed Jun 27 06:32:34 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jun 2018 16:32:34 +1000
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <8e5f1747-3d1f-7381-549c-965ee3d5ef08@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
 <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
 <fa7627f5-6953-498e-8e2a-6d80112081f1@default>
 <5ba6916b-35bf-617e-fff8-93f096162047@oracle.com>
 <8e5f1747-3d1f-7381-549c-965ee3d5ef08@oracle.com>
Message-ID: <91f8141a-d550-7a70-c65e-efa9321d8977@oracle.com>

Hi Jini,

I took a look ... that's about all I can say :)

I know that you and Sharath have worked through this in detail over an 
extended period of time, so I'm okay to add my Reviewed stamp to it.

About the only thing I'd suggest, if not already done, is to do a mach5 
run only on OSX with --test-repeat 10, to try to check that we are okay 
on a range of OSX machines.

Thanks,
David

On 26/06/2018 5:25 PM, Jini George wrote:
> Ping - Gentle reminder !
> 
> Thanks,
> Jini.
> 
> On 6/25/2018 3:41 PM, Jini George wrote:
>> Thank you, Sharath. May I have a Reviewer to take a look at the 
>> MacosxDebuggerLocal code?
>>
>> Thanks,
>> Jini.
>>
>> On 6/25/2018 1:52 PM, Sharath Ballal wrote:
>>> Hi Jini,
>>>
>>> Changes in MacosxDebuggerLocal.m looks good.
>>>
>>> Thanks,
>>> Sharath
>>>
>>>
>>> -----Original Message-----
>>> From: Jini George
>>> Sent: Sunday, June 24, 2018 11:07 PM
>>> To: Erik Joelsson; serviceability-dev at openjdk.java.net; 
>>> build-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated 
>>> PT_ATTACH with PT_ATTACHEXC
>>>
>>> Hi Erik,
>>>
>>> Thank you very much for looking into this. I have addressed your 
>>> comments. The latest webrev is at:
>>>
>>> http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/
>>>
>>> Thank you,
>>> Jini.
>>>
>>>
>>> On 6/23/2018 3:31 AM, Erik Joelsson wrote:
>>>> Hello Jini,
>>>>
>>>> In general this looks pretty good, but it's also breaking some new
>>>> ground as it's adding generation of native source in the java gensrc
>>>> step. Mixing native code with the java code that the genrcs targets
>>>> and gensrc output directories are meant for seems ok for now, but may
>>>> cause trouble in the future. I'm going to accept it for now though.
>>>>
>>>> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in
>>>> its own section (as delimited by the 80x # lines) and put that whole
>>>> thing inside a conditional for macosx. Also please break line 47 (for
>>>> recipe lines, indent with tab and 4 additional spaces for 
>>>> continuation [1]).
>>>>
>>>> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be
>>>> enough as that will implicitly add the same directories as header dirs
>>>> by default. At least that's the intention.
>>>>
>>>> /Erik
>>>>
>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>>>
>>>> On 2018-06-22 11:11, Jini George wrote:
>>>>> Hi all,
>>>>>
>>>>> [Including build-dev also since this includes build related changes].
>>>>>
>>>>> Requesting reviews for:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace
>>>>> the deprecated PT_ATTACH with PT_ATTACHEXC)
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>>>>
>>>>> This is the follow-up solution for the temporary restoration of
>>>>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042
>>>>> (several serviceability/sa tests timed out on MacOS X), which was
>>>>> done in Oct 2017. The mails related to this are at:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August
>>>>> /021702.html
>>>>>
>>>>>
>>>>> Changes as compared to the patch sent last year
>>>>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>>>>
>>>>> * Addressed the review comments which were provided by Poonam, Dan,
>>>>> Dmitry.
>>>>> * A major change as compared to what was done last year is that the
>>>>> MIG generated files have been included as a part of the JDK build
>>>>> process.
>>>>> * The test case which was provided in the patch last year is no
>>>>> longer required since we have ClhsdbAttach.java testing the same
>>>>> functionality as a part of the SA testsuite now.
>>>>> * Other than that, some minor improvements have been done wrt error
>>>>> handling.
>>>>>
>>>>> The steps for the proposed solution have been provided in JBS.
>>>>>
>>>>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 
>>>>> platforms.
>>>>>
>>>>> Thanks to Sharath, Robin, Gerard and Dan for looking into the changes
>>>>> and providing valuable comments.
>>>>>
>>>>> Thanks,
>>>>> Jini.
>>>>


From jini.george at oracle.com  Wed Jun 27 07:09:58 2018
From: jini.george at oracle.com (Jini George)
Date: Wed, 27 Jun 2018 12:39:58 +0530
Subject: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH
 with PT_ATTACHEXC
In-Reply-To: <91f8141a-d550-7a70-c65e-efa9321d8977@oracle.com>
References: <cc34b440-0ec2-ace2-36b8-14f384fe466e@oracle.com>
 <7abea33e-7fb0-fbe0-d463-8999ccdf54da@oracle.com>
 <b01c4ddd-2d50-1b9d-148f-0f3cad307d47@oracle.com>
 <0c93044e-7aaf-179b-c80c-45ff4d7e2712@oracle.com>
 <fa7627f5-6953-498e-8e2a-6d80112081f1@default>
 <5ba6916b-35bf-617e-fff8-93f096162047@oracle.com>
 <8e5f1747-3d1f-7381-549c-965ee3d5ef08@oracle.com>
 <91f8141a-d550-7a70-c65e-efa9321d8977@oracle.com>
Message-ID: <d21f27ac-9816-0754-edc6-5bef2ec8fd4e@oracle.com>

Thank you very much, David. I will do the test-repeat run of the tests 
(after a temp fix to enable OSX runs on Mach5 (JDK-8199700)).

Thanks,
Jini.

On 6/27/2018 12:02 PM, David Holmes wrote:
> Hi Jini,
> 
> I took a look ... that's about all I can say :)
> 
> I know that you and Sharath have worked through this in detail over an 
> extended period of time, so I'm okay to add my Reviewed stamp to it.
> 
> About the only thing I'd suggest, if not already done, is to do a mach5 
> run only on OSX with --test-repeat 10, to try to check that we are okay 
> on a range of OSX machines.
> 
> Thanks,
> David
> 
> On 26/06/2018 5:25 PM, Jini George wrote:
>> Ping - Gentle reminder !
>>
>> Thanks,
>> Jini.
>>
>> On 6/25/2018 3:41 PM, Jini George wrote:
>>> Thank you, Sharath. May I have a Reviewer to take a look at the 
>>> MacosxDebuggerLocal code?
>>>
>>> Thanks,
>>> Jini.
>>>
>>> On 6/25/2018 1:52 PM, Sharath Ballal wrote:
>>>> Hi Jini,
>>>>
>>>> Changes in MacosxDebuggerLocal.m looks good.
>>>>
>>>> Thanks,
>>>> Sharath
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jini George
>>>> Sent: Sunday, June 24, 2018 11:07 PM
>>>> To: Erik Joelsson; serviceability-dev at openjdk.java.net; 
>>>> build-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated 
>>>> PT_ATTACH with PT_ATTACHEXC
>>>>
>>>> Hi Erik,
>>>>
>>>> Thank you very much for looking into this. I have addressed your 
>>>> comments. The latest webrev is at:
>>>>
>>>> http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/
>>>>
>>>> Thank you,
>>>> Jini.
>>>>
>>>>
>>>> On 6/23/2018 3:31 AM, Erik Joelsson wrote:
>>>>> Hello Jini,
>>>>>
>>>>> In general this looks pretty good, but it's also breaking some new
>>>>> ground as it's adding generation of native source in the java gensrc
>>>>> step. Mixing native code with the java code that the genrcs targets
>>>>> and gensrc output directories are meant for seems ok for now, but may
>>>>> cause trouble in the future. I'm going to accept it for now though.
>>>>>
>>>>> In Gensrc-jdk.hotspot.agent.gmk: Please put the new macosx stuff in
>>>>> its own section (as delimited by the 80x # lines) and put that whole
>>>>> thing inside a conditional for macosx. Also please break line 47 (for
>>>>> recipe lines, indent with tab and 4 additional spaces for 
>>>>> continuation [1]).
>>>>>
>>>>> In Lib-jdk.hotspot.agent.gmk: I believe adding extra src should be
>>>>> enough as that will implicitly add the same directories as header dirs
>>>>> by default. At least that's the intention.
>>>>>
>>>>> /Erik
>>>>>
>>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>>>>
>>>>> On 2018-06-22 11:11, Jini George wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> [Including build-dev also since this includes build related changes].
>>>>>>
>>>>>> Requesting reviews for:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace
>>>>>> the deprecated PT_ATTACH with PT_ATTACHEXC)
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/
>>>>>>
>>>>>> This is the follow-up solution for the temporary restoration of
>>>>>> PT_ATTACH to fix https://bugs.openjdk.java.net/browse/JDK-8184042
>>>>>> (several serviceability/sa tests timed out on MacOS X), which was
>>>>>> done in Oct 2017. The mails related to this are at:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August
>>>>>> /021702.html
>>>>>>
>>>>>>
>>>>>> Changes as compared to the patch sent last year
>>>>>> (http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/):
>>>>>>
>>>>>> * Addressed the review comments which were provided by Poonam, Dan,
>>>>>> Dmitry.
>>>>>> * A major change as compared to what was done last year is that the
>>>>>> MIG generated files have been included as a part of the JDK build
>>>>>> process.
>>>>>> * The test case which was provided in the patch last year is no
>>>>>> longer required since we have ClhsdbAttach.java testing the same
>>>>>> functionality as a part of the SA testsuite now.
>>>>>> * Other than that, some minor improvements have been done wrt error
>>>>>> handling.
>>>>>>
>>>>>> The steps for the proposed solution have been provided in JBS.
>>>>>>
>>>>>> Testing: ALL the SA tests pass on MacOSX and the other Mach5 
>>>>>> platforms.
>>>>>>
>>>>>> Thanks to Sharath, Robin, Gerard and Dan for looking into the changes
>>>>>> and providing valuable comments.
>>>>>>
>>>>>> Thanks,
>>>>>> Jini.
>>>>>


From ekaterina.pavlova at oracle.com  Wed Jun 27 07:29:35 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Wed, 27 Jun 2018 00:29:35 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
 <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com>
 <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com>
Message-ID: <c6a45ec0-89f8-8a1e-93a4-b20efea03572@oracle.com>


On 6/26/18 9:08 AM, Ekaterina Pavlova wrote:
> Hello Magnus,
> 
> On 6/26/18 12:50 AM, Magnus Ihse Bursie wrote:
>> 23 juni 2018 kl. 00:22 skrev Ekaterina Pavlova <ekaterina.pavlova at oracle.com <mailto:ekaterina.pavlova at oracle.com>>:
>>
>>> Fixed and regenerated webrev at the same location:
>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>
>> Better, but not done yet.
>>
>> In JtregGraalUnit.gmk: line 52-53 should be on a single line.
> 
> will fix

done

>> The SRC list for?BUILD_VM_COMPILER_TESTS looks insane, but the root cause here is the weird layout on disk. But the .test part really surprises me, I thought we had a clear rule to have no test source in src?!
> 
> These are not jtreg tests, these are graalunit tests which are coming as part of Graal port (from Graal ws).
> We can't change this layout right now.
> 
> 
>> In lib-tests.m4: Copy paste error:?AC_MSG_ERROR([You must specify the path to tonga jar])
> 
> ops, will fix

done

>> The addition in RunTests.gmk and TestCommon.gmk should be guarded by:
>> ?? ifeq ($(INCLUDE_GRAAL), true)
> 
> ok, will look

well, INCLUDE_GRAAL is not defined at the time we run tests.
I can try to guard by something like
  ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU),linux-x64 macosx-x64 windows-x64))

but I am not sure we should proceed this way. It looks too much complicated.
It is safe to pass -e:TEST_IMAGE_GRAAL_DIR to jtreg even it will not be used.
We also do similar way for example for -e:JDK8_HOME

I have uploaded new webrev at the same location:
  http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html


thanks for reviewing,
-katya

>> /Magnus
>>
>>>
>>> Erik,
>>> thanks again for your detailed reviews!
>>>
>>> -katya
>>>
>>> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>>>> Hello Katya,
>>>> This looks much better, thanks!
>>>> A few suggestions still:
>>>> Main.gmk: instead of repeating the assignment in both if and else block:
>>>> ifeq ($(INCLUDE_GRAAL), true)
>>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>>>> endif
>>>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway.
>>>> In JtregGraalUnit.gmk: Some minor style nits:
>>>> 54: align )) with first eval line as you have done with the other eval calls
>>>> 118: Since 117 is a one line parameter, please move comma to 117
>>>> 133: Same as for 118
>>>> 130-132: Please indent 4 spaces for continuation
>>>> /Erik
>>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>>>> Erik, Doug,
>>>>>
>>>>> thank you a lot for your reviews and advises.
>>>>> I fixed everything what Erik has pointed out, please see my answers inlined.
>>>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>>>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
>>>>>
>>>>> New webrev is here:
>>>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>> ?testing: tested by building and running graal unit tests
>>>>>
>>>>>
>>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please always include build-dev when reviewing build changes.
>>>>>>
>>>>>> In general this looks pretty good but there are some details that need fixing.
>>>>>>
>>>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
>>>>>>
>>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>>>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>>>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>>>>
>>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>>>>
>>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
>>>>>
>>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.
>>>>>
>>>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
>>>>>
>>>>> ok, renamed
>>>>>
>>>>>>
>>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
>>>>>
>>>>> ok, removed
>>>>>
>>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.
>>>>>
>>>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.
>>>>>
>>>>>> The all and test-image targets are never called so no need to declare them.
>>>>>>
>>>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
>>>>>> * 43 logic indent 2 spaces
>>>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
>>>>>> * 58 continuation indent 4 spaces
>>>>>> * 88, 89 please break long lines
>>>>>> * 90 continuation indent 4 spaces
>>>>>> * 99 continuation indent 4 spaces
>>>>>> * 120 break before ))
>>>>>
>>>>> I think I fixed everything
>>>>>
>>>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>>>>
>>>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
>>>>>
>>>>> fixed
>>>>>
>>>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>>>>
>>>>> fixed
>>>>>
>>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>>>>>>
>>>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
>>>>>
>>>>> added
>>>>>
>>>>> thanks,
>>>>> -katya
>>>>>
>>>>>> /Erik
>>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>>>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>>>>>>
>>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>>>>>>
>>>>>>>
>>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>>>> testing: new tests were executed as part of automatic HS testing for several months.
>>>>>>>
>>>>>>>
>>>>>>> thanks,
>>>>>>> -katya
>>>>>>>
>>>>>>> p.s.
>>>>>>> ?Igor Ignatyev volunteered to sponsor this change.
>>>>>>
>>>>>
>>>
> 



From hannes.wallnoefer at oracle.com  Wed Jun 27 09:42:10 2018
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Wed, 27 Jun 2018 11:42:10 +0200
Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and
 warning to nashorn, jjs
In-Reply-To: <5B331055.4060305@oracle.com>
References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com>
Message-ID: <5B235217-1C30-4017-99FE-766DCDA67C23@oracle.com>

Looks good.

Hannes

> Am 27.06.2018 um 06:19 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Forgot to CC build-dev for makefile changes.
> 
> -Sundar
> 
> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote:
>> Please review.
>> 
>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>> 
>> Related:
>> 
>> JEP http://openjdk.java.net/jeps/335
>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594
>> 
>> Thanks,
>> -Sundar
>> 



From volker.simonis at gmail.com  Wed Jun 27 10:26:14 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 27 Jun 2018 12:26:14 +0200
Subject: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to
 handle both, RPATH and RUNPATH
Message-ID: <CA+3eh13wcy3d0BykomPBPZaupC_=BTX9zhZDBHB45F73QRWZBw@mail.gmail.com>

Hi,

can I please have a review for the following tiny test fix (I'm
actually not sure which would be the appropriate mailing list for this
fix so please redirect if necessary):

http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/
https://bugs.openjdk.java.net/browse/JDK-8205916

The test currently only checks for RPATH in the dynamic section of the
launcher, but some linkers / Linux distributions (notably SLES) use
RUNPATH instead.

Following are the gory details:

The test jdk/tools/launcher/RunpathTest.java checks that the java
launcher on Linux and Solaris has the correct RPATH path baked into
the executable.

Unfortunately, the situation with RPATH is a little weird:

  - in order to bake a runtime path into a dynamically linked library
or executable one has to use the "-rpath <PATH>" linker option (from
the C/C++ compiler this is usually available as "-Wl,-rpath,<path>").
  - depending on the dynamic linker version and Linux distribution,
the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04,
RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries
together (SLES 11.3) to the dynamic section of the shared
library/executable.
  - the semantics of "RPATH" and "RUNPATH" are slightly different:
"RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH"
isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH
(i.e. RUNPATH can be overridden at runtime by setting
LD_LIBRARY_PATH).
  - "RPATH" is considered obsolete and should be replaced by "RUNPATH"
according to the man-page of "ld.so (8)".
  - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or
the corresponding compiler flags
"-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to
enforce the generation of "RUNPATH"/"RPATH" respectively (except for
systems like SLES 11.3 where "--enable-new-dtags" generates both
"RPATH" and "RUNPATH" while "--disable-new-dtags" only generates
"RPATH").

But this issue is not about fixing the build so to cut a long story
short - the test RunpathTest.java should be able to handle both
runtime path variants equally well. This can be easily achieved by
extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to
".*R(UN)?PATH.*\\$ORIGIN/../lib.*"

Thank you and best regards,
Volker


From martinrb at google.com  Wed Jun 27 14:45:08 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 27 Jun 2018 07:45:08 -0700
Subject: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to
 handle both, RPATH and RUNPATH
In-Reply-To: <CA+3eh13wcy3d0BykomPBPZaupC_=BTX9zhZDBHB45F73QRWZBw@mail.gmail.com>
References: <CA+3eh13wcy3d0BykomPBPZaupC_=BTX9zhZDBHB45F73QRWZBw@mail.gmail.com>
Message-ID: <CA+kOe0_sFhdzXEUvcTze-6TsC=O7MmFXSnRc4rx2+6nOZPrSsA@mail.gmail.com>

Looks good to me!

On Wed, Jun 27, 2018 at 3:26 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi,
>
> can I please have a review for the following tiny test fix (I'm
> actually not sure which would be the appropriate mailing list for this
> fix so please redirect if necessary):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/
> https://bugs.openjdk.java.net/browse/JDK-8205916
>
> The test currently only checks for RPATH in the dynamic section of the
> launcher, but some linkers / Linux distributions (notably SLES) use
> RUNPATH instead.
>
> Following are the gory details:
>
> The test jdk/tools/launcher/RunpathTest.java checks that the java
> launcher on Linux and Solaris has the correct RPATH path baked into
> the executable.
>
> Unfortunately, the situation with RPATH is a little weird:
>
>   - in order to bake a runtime path into a dynamically linked library
> or executable one has to use the "-rpath <PATH>" linker option (from
> the C/C++ compiler this is usually available as "-Wl,-rpath,<path>").
>   - depending on the dynamic linker version and Linux distribution,
> the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04,
> RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries
> together (SLES 11.3) to the dynamic section of the shared
> library/executable.
>   - the semantics of "RPATH" and "RUNPATH" are slightly different:
> "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH"
> isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH
> (i.e. RUNPATH can be overridden at runtime by setting
> LD_LIBRARY_PATH).
>   - "RPATH" is considered obsolete and should be replaced by "RUNPATH"
> according to the man-page of "ld.so (8)".
>   - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or
> the corresponding compiler flags
> "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to
> enforce the generation of "RUNPATH"/"RPATH" respectively (except for
> systems like SLES 11.3 where "--enable-new-dtags" generates both
> "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates
> "RPATH").
>
> But this issue is not about fixing the build so to cut a long story
> short - the test RunpathTest.java should be able to handle both
> runtime path variants equally well. This can be easily achieved by
> extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to
> ".*R(UN)?PATH.*\\$ORIGIN/../lib.*"
>
> Thank you and best regards,
> Volker
>


From erik.joelsson at oracle.com  Wed Jun 27 15:36:51 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 08:36:51 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <c6a45ec0-89f8-8a1e-93a4-b20efea03572@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
 <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com>
 <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com>
 <c6a45ec0-89f8-8a1e-93a4-b20efea03572@oracle.com>
Message-ID: <8f45dc06-5c26-76b9-b7e9-ebfde0cfe320@oracle.com>



On 2018-06-27 00:29, Ekaterina Pavlova wrote:
>
> well, INCLUDE_GRAAL is not defined at the time we run tests.
> I can try to guard by something like
> ?ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), $(filter 
> $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU),linux-x64 macosx-x64 
> windows-x64))
>
> but I am not sure we should proceed this way. It looks too much 
> complicated.
> It is safe to pass -e:TEST_IMAGE_GRAAL_DIR to jtreg even it will not 
> be used.
> We also do similar way for example for -e:JDK8_HOME
>
I agree, no need to guard the addition of the env variable pass through.
> I have uploaded new webrev at the same location:
> ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>
Looks good to me now. (Magnus is on vacation so you probably don't want 
to wait for him to respond)

/Erik
>
> thanks for reviewing,
> -katya
>
>>> /Magnus
>>>
>>>>
>>>> Erik,
>>>> thanks again for your detailed reviews!
>>>>
>>>> -katya
>>>>
>>>> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>>>>> Hello Katya,
>>>>> This looks much better, thanks!
>>>>> A few suggestions still:
>>>>> Main.gmk: instead of repeating the assignment in both if and else 
>>>>> block:
>>>>> ifeq ($(INCLUDE_GRAAL), true)
>>>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>>>>> endif
>>>>> I think it's fine to do that without the ?= because an alternative 
>>>>> JVM implementation is unlikely to be using graal anyway.
>>>>> In JtregGraalUnit.gmk: Some minor style nits:
>>>>> 54: align )) with first eval line as you have done with the other 
>>>>> eval calls
>>>>> 118: Since 117 is a one line parameter, please move comma to 117
>>>>> 133: Same as for 118
>>>>> 130-132: Please indent 4 spaces for continuation
>>>>> /Erik
>>>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>>>>> Erik, Doug,
>>>>>>
>>>>>> thank you a lot for your reviews and advises.
>>>>>> I fixed everything what Erik has pointed out, please see my 
>>>>>> answers inlined.
>>>>>> As about moving more staff in 'updategraalinopenjdk' can we 
>>>>>> consider this as next step?
>>>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't 
>>>>>> contribute into Graal ws yet,
>>>>>> so I will prefer to do this improvement/refactoring as part of 
>>>>>> separate JDK issue.
>>>>>>
>>>>>> New webrev is here:
>>>>>> ? webrev: 
>>>>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>> ?testing: tested by building and running graal unit tests
>>>>>>
>>>>>>
>>>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please always include build-dev when reviewing build changes.
>>>>>>>
>>>>>>> In general this looks pretty good but there are some details 
>>>>>>> that need fixing.
>>>>>>>
>>>>>>> (Aside from this particular review, I must state my reservation 
>>>>>>> against all the special treatment graal is enjoying from a 
>>>>>>> source and test layout and build perspective. My understanding 
>>>>>>> here is that someone will have to regularly update the wrapper 
>>>>>>> jtreg tests manually using the script. This in addition to 
>>>>>>> having to implement this very convoluted redirection logic 
>>>>>>> because the tests are in the wrong place. Wouldn't it make a lot 
>>>>>>> more sense to put the complicated logic in the import procedure 
>>>>>>> for graal source so that it would fit nicely into the OpenJDK 
>>>>>>> source/build/test model, instead of adding more and more 
>>>>>>> complicated workarounds in the OpenJDK build and test procedures?)
>>>>>>>
>>>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> please review porting of Graal unit tests under jtreg. The main 
>>>>>>>> idea of this porting is to keep Graal unit tests as is
>>>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) 
>>>>>>>> and run them similar way they are run in Graal project.
>>>>>>>> To achieve this 
>>>>>>>> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java 
>>>>>>>> helper class has been written
>>>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to 
>>>>>>>> run specified set of Graal unit tests. The groups of
>>>>>>>> Graal unit tests to run are defined in auto-generated 
>>>>>>>> test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>>>>>
>>>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit 
>>>>>>>> tests into jdk.vm.compiler.tests.jar and then install
>>>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>>>>>
>>>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used 
>>>>>>> in open makefiles, we need an open configure option to set it.
>>>>>>
>>>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal 
>>>>>> related staff there.
>>>>>>
>>>>>>> To make things clearer, I would rename LIB_DIR to something like 
>>>>>>> LIB_OUTPUTDIR to signal that this is a location to put files in, 
>>>>>>> rather than read them from.
>>>>>>
>>>>>> ok, renamed
>>>>>>
>>>>>>>
>>>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the 
>>>>>>> jar files found by wildcard can only be in one directory anyway.
>>>>>>
>>>>>> ok, removed
>>>>>>
>>>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. 
>>>>>>> Tests classes and jars should be built into 
>>>>>>> $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub 
>>>>>>> directory there for the output from this makefile.
>>>>>>
>>>>>> ok, introduced COMPILE_OUTPUTDIR := 
>>>>>> $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal 
>>>>>> unit test classes.
>>>>>>
>>>>>>> The all and test-image targets are never called so no need to 
>>>>>>> declare them.
>>>>>>>
>>>>>>> There are some style issues too. (Please see 
>>>>>>> http://openjdk.java.net/groups/build/doc/code-conventions.html 
>>>>>>> for details.)
>>>>>>> * 43 logic indent 2 spaces
>>>>>>> * 52 we like to put the ending )) on a new line with ', \' at 
>>>>>>> the end of the line before
>>>>>>> * 58 continuation indent 4 spaces
>>>>>>> * 88, 89 please break long lines
>>>>>>> * 90 continuation indent 4 spaces
>>>>>>> * 99 continuation indent 4 spaces
>>>>>>> * 120 break before ))
>>>>>>
>>>>>> I think I fixed everything
>>>>>>
>>>>>>>> make/Main.gmk adds proper dependencies for 
>>>>>>>> build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>>>>>
>>>>>>> The target build-test-hotspot-jtreg-graal only needs to depend 
>>>>>>> on exploded-image-optimize.
>>>>>>
>>>>>> fixed
>>>>>>
>>>>>>> The new graal specific targets should be guarded by 
>>>>>>> INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently 
>>>>>>> do nothing if invoked without graal. That means adding them to 
>>>>>>> JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>>>>>
>>>>>> fixed
>>>>>>
>>>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so 
>>>>>>>> jtreg knows where to find Graal tests and libs.
>>>>>>>>
>>>>>>> This needs to be duplicated for make/RunTest.gmk so that these 
>>>>>>> tests work with "make run-test" as well.
>>>>>>
>>>>>> added
>>>>>>
>>>>>> thanks,
>>>>>> -katya
>>>>>>
>>>>>>> /Erik
>>>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file 
>>>>>>>> defines "testName -> testPrefix [requiresStatement]" mapping
>>>>>>>> which is used by 
>>>>>>>> test/hotspot/jtreg/compiler/graalunit/generateTests.sh script 
>>>>>>>> to generate jtreg tests.
>>>>>>>>
>>>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit 
>>>>>>>> was ported from mx project without any changes.
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>>>> ?webrev: 
>>>>>>>> http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>>>>> testing: new tests were executed as part of automatic HS 
>>>>>>>> testing for several months.
>>>>>>>>
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> -katya
>>>>>>>>
>>>>>>>> p.s.
>>>>>>>> ?Igor Ignatyev volunteered to sponsor this change.
>>>>>>>
>>>>>>
>>>>
>>
>



From erik.joelsson at oracle.com  Wed Jun 27 15:41:45 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 08:41:45 -0700
Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and
 warning to nashorn, jjs
In-Reply-To: <5B331055.4060305@oracle.com>
References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com>
Message-ID: <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com>

Hello Sundar,

Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't 
jdk.scripting.nashorn pretty much warning frree now? What warnings do 
you really need to disable?

/Erik


On 2018-06-26 21:19, Sundararajan Athijegannathan wrote:
> Forgot to CC build-dev for makefile changes.
>
> -Sundar
>
> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote:
>> Please review.
>>
>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>>
>> Related:
>>
>> JEP http://openjdk.java.net/jeps/335
>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594
>>
>> Thanks,
>> -Sundar
>>



From erik.joelsson at oracle.com  Wed Jun 27 15:53:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 08:53:11 -0700
Subject: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to
 handle both, RPATH and RUNPATH
In-Reply-To: <CA+3eh13wcy3d0BykomPBPZaupC_=BTX9zhZDBHB45F73QRWZBw@mail.gmail.com>
References: <CA+3eh13wcy3d0BykomPBPZaupC_=BTX9zhZDBHB45F73QRWZBw@mail.gmail.com>
Message-ID: <d90f218c-354a-faf4-42cc-ead249bfa57d@oracle.com>

Looks ok to me.

/Erik


On 2018-06-27 03:26, Volker Simonis wrote:
> Hi,
>
> can I please have a review for the following tiny test fix (I'm
> actually not sure which would be the appropriate mailing list for this
> fix so please redirect if necessary):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/
> https://bugs.openjdk.java.net/browse/JDK-8205916
>
> The test currently only checks for RPATH in the dynamic section of the
> launcher, but some linkers / Linux distributions (notably SLES) use
> RUNPATH instead.
>
> Following are the gory details:
>
> The test jdk/tools/launcher/RunpathTest.java checks that the java
> launcher on Linux and Solaris has the correct RPATH path baked into
> the executable.
>
> Unfortunately, the situation with RPATH is a little weird:
>
>    - in order to bake a runtime path into a dynamically linked library
> or executable one has to use the "-rpath <PATH>" linker option (from
> the C/C++ compiler this is usually available as "-Wl,-rpath,<path>").
>    - depending on the dynamic linker version and Linux distribution,
> the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04,
> RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries
> together (SLES 11.3) to the dynamic section of the shared
> library/executable.
>    - the semantics of "RPATH" and "RUNPATH" are slightly different:
> "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH"
> isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH
> (i.e. RUNPATH can be overridden at runtime by setting
> LD_LIBRARY_PATH).
>    - "RPATH" is considered obsolete and should be replaced by "RUNPATH"
> according to the man-page of "ld.so (8)".
>    - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or
> the corresponding compiler flags
> "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to
> enforce the generation of "RUNPATH"/"RPATH" respectively (except for
> systems like SLES 11.3 where "--enable-new-dtags" generates both
> "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates
> "RPATH").
>
> But this issue is not about fixing the build so to cut a long story
> short - the test RunpathTest.java should be able to handle both
> runtime path variants equally well. This can be easily achieved by
> extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to
> ".*R(UN)?PATH.*\\$ORIGIN/../lib.*"
>
> Thank you and best regards,
> Volker



From sundararajan.athijegannathan at oracle.com  Wed Jun 27 15:59:02 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 27 Jun 2018 21:29:02 +0530
Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning
 to nashorn, jjs
In-Reply-To: <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com>
References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com>
 <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com>
Message-ID: <5B33B446.40109@oracle.com>

Hi Erik,

Yes, nashorn is warning free afaik. Besides nashorn is being deprecated. 
No further development expected other than perhaps occasional bug fixes.

We need to disable javac deprecation warnings. Without this javac 
deprecation warnings cause build failure.

-Sundar

On 27/06/18, 9:11 PM, Erik Joelsson wrote:
> Hello Sundar,
>
> Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't 
> jdk.scripting.nashorn pretty much warning frree now? What warnings do 
> you really need to disable?
>
> /Erik
>
>
> On 2018-06-26 21:19, Sundararajan Athijegannathan wrote:
>> Forgot to CC build-dev for makefile changes.
>>
>> -Sundar
>>
>> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote:
>>> Please review.
>>>
>>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
>>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>>>
>>> Related:
>>>
>>> JEP http://openjdk.java.net/jeps/335
>>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594
>>>
>>> Thanks,
>>> -Sundar
>>>
>


From erik.joelsson at oracle.com  Wed Jun 27 15:59:53 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 08:59:53 -0700
Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and
 warning to nashorn, jjs
In-Reply-To: <5B33B446.40109@oracle.com>
References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com>
 <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> <5B33B446.40109@oracle.com>
Message-ID: <70af42e4-4db2-320f-acf3-9940e61d9bd6@oracle.com>

If it's just deprecation you want to remove, then 
-Xlint:all,-deprecation should be enough to add. The current argument 
for jdk.scripting.nashorn is -Xlint:all (if I'm not mistaken).

/Erik


On 2018-06-27 08:59, Sundararajan Athijegannathan wrote:
> Hi Erik,
>
> Yes, nashorn is warning free afaik. Besides nashorn is being 
> deprecated. No further development expected other than perhaps 
> occasional bug fixes.
>
> We need to disable javac deprecation warnings. Without this javac 
> deprecation warnings cause build failure.
>
> -Sundar
>
> On 27/06/18, 9:11 PM, Erik Joelsson wrote:
>> Hello Sundar,
>>
>> Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't 
>> jdk.scripting.nashorn pretty much warning frree now? What warnings do 
>> you really need to disable?
>>
>> /Erik
>>
>>
>> On 2018-06-26 21:19, Sundararajan Athijegannathan wrote:
>>> Forgot to CC build-dev for makefile changes.
>>>
>>> -Sundar
>>>
>>> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote:
>>>> Please review.
>>>>
>>>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
>>>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>>>>
>>>> Related:
>>>>
>>>> JEP http://openjdk.java.net/jeps/335
>>>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594
>>>>
>>>> Thanks,
>>>> -Sundar
>>>>
>>



From ekaterina.pavlova at oracle.com  Wed Jun 27 16:51:38 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Wed, 27 Jun 2018 09:51:38 -0700
Subject: RFR(M): 8205207: Port Graal unit tests under jtreg
In-Reply-To: <8f45dc06-5c26-76b9-b7e9-ebfde0cfe320@oracle.com>
References: <41c21959-70d6-f1f1-d647-bdba727daf34@oracle.com>
 <05a26bc0-bea3-1157-c96a-eb224cfa180f@oracle.com>
 <0efa1c77-5280-d786-279f-2f9b1c64ed11@oracle.com>
 <5116257e-472d-13f5-f800-5e42d800934d@oracle.com>
 <eb22ba3b-4dea-8127-286a-1468663f9b08@oracle.com>
 <5F6B2552-C6F7-44BB-9036-847F60A0737B@oracle.com>
 <42868f25-ab86-628d-55f9-e81e2fec8985@oracle.com>
 <c6a45ec0-89f8-8a1e-93a4-b20efea03572@oracle.com>
 <8f45dc06-5c26-76b9-b7e9-ebfde0cfe320@oracle.com>
Message-ID: <d1269613-d28b-4d24-cd21-879ea5ac92cf@oracle.com>

Thanks Erik!

-katya

On 6/27/18 8:36 AM, Erik Joelsson wrote:
> 
> 
> On 2018-06-27 00:29, Ekaterina Pavlova wrote:
>>
>> well, INCLUDE_GRAAL is not defined at the time we run tests.
>> I can try to guard by something like
>> ?ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU),linux-x64 macosx-x64 windows-x64))
>>
>> but I am not sure we should proceed this way. It looks too much complicated.
>> It is safe to pass -e:TEST_IMAGE_GRAAL_DIR to jtreg even it will not be used.
>> We also do similar way for example for -e:JDK8_HOME
>>
> I agree, no need to guard the addition of the env variable pass through.
>> I have uploaded new webrev at the same location:
>> ?http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>
> Looks good to me now. (Magnus is on vacation so you probably don't want to wait for him to respond)
> 
> /Erik
>>
>> thanks for reviewing,
>> -katya
>>
>>>> /Magnus
>>>>
>>>>>
>>>>> Erik,
>>>>> thanks again for your detailed reviews!
>>>>>
>>>>> -katya
>>>>>
>>>>> On 6/22/18 2:38 PM, Erik Joelsson wrote:
>>>>>> Hello Katya,
>>>>>> This looks much better, thanks!
>>>>>> A few suggestions still:
>>>>>> Main.gmk: instead of repeating the assignment in both if and else block:
>>>>>> ifeq ($(INCLUDE_GRAAL), true)
>>>>>> ? JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal
>>>>>> endif
>>>>>> I think it's fine to do that without the ?= because an alternative JVM implementation is unlikely to be using graal anyway.
>>>>>> In JtregGraalUnit.gmk: Some minor style nits:
>>>>>> 54: align )) with first eval line as you have done with the other eval calls
>>>>>> 118: Since 117 is a one line parameter, please move comma to 117
>>>>>> 133: Same as for 118
>>>>>> 130-132: Please indent 4 spaces for continuation
>>>>>> /Erik
>>>>>> On 2018-06-22 14:16, Ekaterina Pavlova wrote:
>>>>>>> Erik, Doug,
>>>>>>>
>>>>>>> thank you a lot for your reviews and advises.
>>>>>>> I fixed everything what Erik has pointed out, please see my answers inlined.
>>>>>>> As about moving more staff in 'updategraalinopenjdk' can we consider this as next step?
>>>>>>> I am not quite familiar with 'updategraalinopenjdk' and didn't contribute into Graal ws yet,
>>>>>>> so I will prefer to do this improvement/refactoring as part of separate JDK issue.
>>>>>>>
>>>>>>> New webrev is here:
>>>>>>> ? webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html
>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>>> ?testing: tested by building and running graal unit tests
>>>>>>>
>>>>>>>
>>>>>>> On 6/19/18 2:00 PM, Erik Joelsson wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please always include build-dev when reviewing build changes.
>>>>>>>>
>>>>>>>> In general this looks pretty good but there are some details that need fixing.
>>>>>>>>
>>>>>>>> (Aside from this particular review, I must state my reservation against all the special treatment graal is enjoying from a source and test layout and build perspective. My understanding here is that someone will have to regularly update the wrapper jtreg tests manually using the script. This in addition to having to implement this very convoluted redirection logic because the tests are in the wrong place. Wouldn't it make a lot more sense to put the complicated logic in the import procedure for graal source so that it would fit nicely into the OpenJDK source/build/test model, instead of adding more and more complicated workarounds in the OpenJDK build and test procedures?)
>>>>>>>>
>>>>>>>> On 2018-06-18 22:26, Ekaterina Pavlova wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> please review porting of Graal unit tests under jtreg. The main idea of this porting is to keep Graal unit tests as is
>>>>>>>>> (located in src/jdk.internal.vm.compiler/share/classes/*.test) and run them similar way they are run in Graal project.
>>>>>>>>> To achieve this test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java helper class has been written
>>>>>>>>> which simply launches com.oracle.mxtool.junit.MxJUnitWrapper to run specified set of Graal unit tests. The groups of
>>>>>>>>> Graal unit tests to run are defined in auto-generated test/hotspot/jtreg/compiler/graalunit/*.java jtreg tests.
>>>>>>>>>
>>>>>>>>> New make/test/JtregGraalUnit.gmk is used to build Graal unit tests into jdk.vm.compiler.tests.jar and then install
>>>>>>>>> it in $(TEST_IMAGE_DIR)/hotspot/jtreg/graal/.
>>>>>>>>>
>>>>>>>> GRAALUNIT_LIB is never defined (in the open). Since this is used in open makefiles, we need an open configure option to set it.
>>>>>>>
>>>>>>> ok, I created open/make/autoconf/lib-tests.m4 and did put Graal related staff there.
>>>>>>>
>>>>>>>> To make things clearer, I would rename LIB_DIR to something like LIB_OUTPUTDIR to signal that this is a location to put files in, rather than read them from.
>>>>>>>
>>>>>>> ok, renamed
>>>>>>>
>>>>>>>>
>>>>>>>> FLATTEN has no effect in the SetupCopyFiles call since all the jar files found by wildcard can only be in one directory anyway.
>>>>>>>
>>>>>>> ok, removed
>>>>>>>
>>>>>>>> BUILDTOOLS_OUTPUTDIR is meant for tools used during the build. Tests classes and jars should be built into $(SUPPORT_OUTPUTDIR)/test/..> Please create a suitable sub directory there for the output from this makefile.
>>>>>>>
>>>>>>> ok, introduced COMPILE_OUTPUTDIR := $(SUPPORT_OUTPUTDIR)/test/graalunit to be used to build graal unit test classes.
>>>>>>>
>>>>>>>> The all and test-image targets are never called so no need to declare them.
>>>>>>>>
>>>>>>>> There are some style issues too. (Please see http://openjdk.java.net/groups/build/doc/code-conventions.html for details.)
>>>>>>>> * 43 logic indent 2 spaces
>>>>>>>> * 52 we like to put the ending )) on a new line with ', \' at the end of the line before
>>>>>>>> * 58 continuation indent 4 spaces
>>>>>>>> * 88, 89 please break long lines
>>>>>>>> * 90 continuation indent 4 spaces
>>>>>>>> * 99 continuation indent 4 spaces
>>>>>>>> * 120 break before ))
>>>>>>>
>>>>>>> I think I fixed everything
>>>>>>>
>>>>>>>>> make/Main.gmk adds proper dependencies for build-test-hotspot-jtreg-graal and test-image-hotspot-jtreg-graal.
>>>>>>>>>
>>>>>>>> The target build-test-hotspot-jtreg-graal only needs to depend on exploded-image-optimize.
>>>>>>>
>>>>>>> fixed
>>>>>>>
>>>>>>>> The new graal specific targets should be guarded by INCLUDE_GRAAL in Main.gmk. Otherwise those targets will silently do nothing if invoked without graal. That means adding them to JVM_TEST_IMAGE_TARGETS needs to be conditional too.
>>>>>>>
>>>>>>> fixed
>>>>>>>
>>>>>>>>> test/TestCommon.gmk passes TEST_IMAGE_GRAAL_DIR to jtreg so jtreg knows where to find Graal tests and libs.
>>>>>>>>>
>>>>>>>> This needs to be duplicated for make/RunTest.gmk so that these tests work with "make run-test" as well.
>>>>>>>
>>>>>>> added
>>>>>>>
>>>>>>> thanks,
>>>>>>> -katya
>>>>>>>
>>>>>>>> /Erik
>>>>>>>>> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt file defines "testName -> testPrefix [requiresStatement]" mapping
>>>>>>>>> which is used by test/hotspot/jtreg/compiler/graalunit/generateTests.sh script to generate jtreg tests.
>>>>>>>>>
>>>>>>>>> test/hotspot/jtreg/compiler/graalunit/com.oracle.mxtool.junit was ported from mx project without any changes.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8205207
>>>>>>>>> ?webrev: http://cr.openjdk.java.net/~epavlova//8205207/webrev.00/index.html
>>>>>>>>> testing: new tests were executed as part of automatic HS testing for several months.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> -katya
>>>>>>>>>
>>>>>>>>> p.s.
>>>>>>>>> ?Igor Ignatyev volunteered to sponsor this change.
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
> 



From daniel.fuchs at oracle.com  Wed Jun 27 19:48:16 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 27 Jun 2018 20:48:16 +0100
Subject: RFR: Revert unintended changes to
 make/gensrc/Gensrc-jdk.hotspot.agent.gmk
Message-ID: <7c060629-610c-9ca0-c409-a6aa6d23a415@oracle.com>

Hi,

My fix for  8205397 [1] includes a change to 
make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:

diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
--- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
+++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
@@ -49,6 +49,7 @@
    MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c

    $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
+ $(call MakeTargetDir)
         $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
             -header $(MACH_EXC_HEADER) 
$(SDKROOT)/usr/include/mach/mach_exc.defs

This patch is to revert the unintented change:

diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
--- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
+++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
@@ -49,7 +49,6 @@
    MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c

    $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
-	$(call MakeTargetDir)
  	$(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
  	    -header $(MACH_EXC_HEADER) $(SDKROOT)/usr/include/mach/mach_exc.defs


My deepest apologies for the mistake :-(

-- daniel

[1] http://hg.openjdk.java.net/jdk/jdk/rev/d21a3d3aa4fb


From daniel.fuchs at oracle.com  Wed Jun 27 19:50:33 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 27 Jun 2018 20:50:33 +0100
Subject: RFR: 8205945 - Revert unintended changes to
 make/gensrc/Gensrc-jdk.hotspot.agent.gmk
Message-ID: <37a77b03-a13b-f865-4c0b-f3fe6a0e59d2@oracle.com>

[resending with correct subject]
Hi,

https://bugs.openjdk.java.net/browse/JDK-8205945
8205945: Revert unintended changes to 
make/gensrc/Gensrc-jdk.hotspot.agent.gmk

My fix for  8205397 [1] includes a change to 
make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:

diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
--- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
+++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
@@ -49,6 +49,7 @@
    MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c

    $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
+ $(call MakeTargetDir)
         $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
             -header $(MACH_EXC_HEADER) 
$(SDKROOT)/usr/include/mach/mach_exc.defs

This patch is to revert the unintented change:

diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
--- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
+++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
@@ -49,7 +49,6 @@
    MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c

    $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
-	$(call MakeTargetDir)
  	$(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
  	    -header $(MACH_EXC_HEADER) $(SDKROOT)/usr/include/mach/mach_exc.defs


My deepest apologies for the mistake :-(

-- daniel

[1] http://hg.openjdk.java.net/jdk/jdk/rev/d21a3d3aa4fb


From jonathan.gibbons at oracle.com  Wed Jun 27 19:50:32 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Jun 2018 12:50:32 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12
 / JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <213666cd-aae9-513c-f891-c0f754bb81f9@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
 <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
 <DD8C3D81-3AAF-4F3D-8765-AC1E818E7CA3@oracle.com>
 <213666cd-aae9-513c-f891-c0f754bb81f9@oracle.com>
Message-ID: <5B33EA88.3030400@oracle.com>

Joe,

javac Source.java

   83
   84     /** 1.11 covers the to be determined language features that will be added in JDK 11. */
   85     JDK11("11"),
   86
   87     /** 12 covers the to be determined language features that will be added in JDK 12. */
   88     JDK12("12");

It would be nice if the comment for 11 was updated.

javac Profile.java

Nothing wrong in your edit, but maybe we should revisit/restrict this 
feature in due course.

javac PrintingProcessor

OK, but RFE: since this is part of javac, perhaps we could replace the 
annotation with an
override of the getSupportedSourceVersion method, returning 
SourceVersion.latest.

jdeps Main

OK, but RFE: compute the list of releasesWithForRemoval, from 9 up to 
java.spec.version

javac test JavacTestingAbstractProcessor.java

OK, but RFE: perhaps we could replace the annotations with an
override of the getSupportedSourceVersion method, returning 
SourceVersion.latest.

-- Jon

On 06/26/2018 10:55 AM, joe darcy wrote:
> On 6/26/2018 10:11 AM, Paul Sandoz wrote:
>> This generally looks good. Having it all consolidated helps a lot, 
>> and we are slowly chipping away at reducing this for each release.
>>
>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java
>> ?
>>
>>   118         V55(55, 0),   // JDK 11: constant dynamic
>>   119         V56(56, 0);   // JDK 12
>>
>>
>> We can add nestmates to the list of stuff in 11
>>
>>
>
> Added ", nest mates" to the list for 11.
>
> Thanks,
>
> -Joe



From glaubitz at physik.fu-berlin.de  Wed Jun 27 19:52:05 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 27 Jun 2018 21:52:05 +0200
Subject: RFR: 8205616: Build fails with system headers after 8204572
In-Reply-To: <139c7b6f-a5cb-07e9-8140-b06d93902ca7@oracle.com>
References: <c30298bf-c9bf-0b80-8e34-1190725f132b@physik.fu-berlin.de>
 <e8c5bda0-1af0-c61b-413c-6e0742c3970f@oracle.com>
 <ecb37b2c-8e43-2252-6209-a17bc487dcb7@physik.fu-berlin.de>
 <139c7b6f-a5cb-07e9-8140-b06d93902ca7@oracle.com>
Message-ID: <f6d9610f-16c7-6b3b-b8d8-9ec4a70ab03c@physik.fu-berlin.de>

Oops, I missed your reply. Will commit now.

Submit repo also passed without problems.

Adrian

On 06/26/2018 04:51 PM, Erik Joelsson wrote:
> Correct.
> 
> /Erik
> 
> 
> On 2018-06-26 07:35, John Paul Adrian Glaubitz wrote:
>> Hi Erik!
>>
>> Thanks!
>>
>> I assume since this affects the build infrastructure only, one reviewer
>> is enough, correct?
>>
>> Adrian
>>
>> On 06/26/2018 04:33 PM, Erik Joelsson wrote:
>>> Looks good.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-06-25 17:21, John Paul Adrian Glaubitz wrote:
>>>> Hi!
>>>>
>>>> Please review this small change contributed by Fridrich Strba of SUSE
>>>> and modified by Magnus which fixes the OpenJDK build when configuring
>>>> to use system headers for libraries like jpeg and lcms.
>>>>
>>>> The bug report can be found in [1] and the webrev in [2].
>>>>
>>>> Thanks,
>>>> Adrian
>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
>>>>> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From jonathan.gibbons at oracle.com  Wed Jun 27 19:53:22 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Jun 2018 12:53:22 -0700
Subject: RFR: 8205945 - Revert unintended changes to
 make/gensrc/Gensrc-jdk.hotspot.agent.gmk
In-Reply-To: <37a77b03-a13b-f865-4c0b-f3fe6a0e59d2@oracle.com>
References: <37a77b03-a13b-f865-4c0b-f3fe6a0e59d2@oracle.com>
Message-ID: <a48605ce-d929-7765-30b4-3aab11d768a1@oracle.com>

Looks OK to me, although I don't normally review hotspot or build changes.

-- Jon


On 6/27/18 12:50 PM, Daniel Fuchs wrote:
> [resending with correct subject]
> Hi,
>
> https://bugs.openjdk.java.net/browse/JDK-8205945
> 8205945: Revert unintended changes to 
> make/gensrc/Gensrc-jdk.hotspot.agent.gmk
>
> My fix for? 8205397 [1] includes a change to 
> make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:
>
> diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
> b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> +++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> @@ -49,6 +49,7 @@
> ?? MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c
>
> ?? $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
> + $(call MakeTargetDir)
> ??????? $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
> ??????????? -header $(MACH_EXC_HEADER) 
> $(SDKROOT)/usr/include/mach/mach_exc.defs
>
> This patch is to revert the unintented change:
>
> diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
> b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> +++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> @@ -49,7 +49,6 @@
> ?? MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c
>
> ?? $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
> -??? $(call MakeTargetDir)
> ???? $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
> ???????? -header $(MACH_EXC_HEADER) 
> $(SDKROOT)/usr/include/mach/mach_exc.defs
>
>
> My deepest apologies for the mistake :-(
>
> -- daniel
>
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/d21a3d3aa4fb



From erik.joelsson at oracle.com  Wed Jun 27 20:12:55 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 13:12:55 -0700
Subject: RFR: 8205945 - Revert unintended changes to
 make/gensrc/Gensrc-jdk.hotspot.agent.gmk
In-Reply-To: <37a77b03-a13b-f865-4c0b-f3fe6a0e59d2@oracle.com>
References: <37a77b03-a13b-f865-4c0b-f3fe6a0e59d2@oracle.com>
Message-ID: <ac90f050-5f84-eba0-d1bd-94c4ea080381@oracle.com>

Looks good to me.

/Erik


On 2018-06-27 12:50, Daniel Fuchs wrote:
> [resending with correct subject]
> Hi,
>
> https://bugs.openjdk.java.net/browse/JDK-8205945
> 8205945: Revert unintended changes to 
> make/gensrc/Gensrc-jdk.hotspot.agent.gmk
>
> My fix for? 8205397 [1] includes a change to 
> make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:
>
> diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
> b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> +++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> @@ -49,6 +49,7 @@
> ?? MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c
>
> ?? $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
> + $(call MakeTargetDir)
> ??????? $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
> ??????????? -header $(MACH_EXC_HEADER) 
> $(SDKROOT)/usr/include/mach/mach_exc.defs
>
> This patch is to revert the unintented change:
>
> diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
> b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> +++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> @@ -49,7 +49,6 @@
> ?? MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c
>
> ?? $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
> -??? $(call MakeTargetDir)
> ???? $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
> ???????? -header $(MACH_EXC_HEADER) 
> $(SDKROOT)/usr/include/mach/mach_exc.defs
>
>
> My deepest apologies for the mistake :-(
>
> -- daniel
>
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/d21a3d3aa4fb



From mandy.chung at oracle.com  Wed Jun 27 20:18:11 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 27 Jun 2018 13:18:11 -0700
Subject: RFR: Revert unintended changes to
 make/gensrc/Gensrc-jdk.hotspot.agent.gmk
In-Reply-To: <7c060629-610c-9ca0-c409-a6aa6d23a415@oracle.com>
References: <7c060629-610c-9ca0-c409-a6aa6d23a415@oracle.com>
Message-ID: <0551da35-8377-84f5-4406-1cb3fb5afbcc@oracle.com>

+1

Mandy

On 6/27/18 12:48 PM, Daniel Fuchs wrote:
> Hi,
> 
> My fix for? 8205397 [1] includes a change to 
> make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:
> 
> diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
> b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> +++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> @@ -49,6 +49,7 @@
>  ?? MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c
> 
>  ?? $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
> + $(call MakeTargetDir)
>  ??????? $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
>  ??????????? -header $(MACH_EXC_HEADER) 
> $(SDKROOT)/usr/include/mach/mach_exc.defs
> 
> This patch is to revert the unintented change:
> 
> diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk 
> b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> --- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> +++ b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
> @@ -49,7 +49,6 @@
>  ?? MACH_EXC_SERVER := $(MIG_OUTPUT_DIR)/mach_excServer.c
> 
>  ?? $(MACH_EXC_SERVER): $(SDKROOT)/usr/include/mach/mach_exc.defs
> -??? $(call MakeTargetDir)
>  ???? $(MIG) -isysroot $(SDKROOT) -server $@ -user $(MACH_EXC_USER) \
>  ???????? -header $(MACH_EXC_HEADER) 
> $(SDKROOT)/usr/include/mach/mach_exc.defs
> 
> 
> My deepest apologies for the mistake :-(
> 
> -- daniel
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/d21a3d3aa4fb


From joe.darcy at oracle.com  Wed Jun 27 20:50:19 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 27 Jun 2018 13:50:19 -0700
Subject: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 /
 JDK-8205621: Increment JDK version for JDK 12
In-Reply-To: <5B33EA88.3030400@oracle.com>
References: <b33acc6e-83d6-ba88-7c9b-8f7f4cf5bc98@oracle.com>
 <c97b4269-a97a-9636-adb3-06d11c5022f8@oracle.com>
 <c95037ea-4f35-3d3c-d570-68ce4e840285@oracle.com>
 <DD8C3D81-3AAF-4F3D-8765-AC1E818E7CA3@oracle.com>
 <213666cd-aae9-513c-f891-c0f754bb81f9@oracle.com>
 <5B33EA88.3030400@oracle.com>
Message-ID: <8e20eef3-5294-4de9-4f83-4b00f723a212@oracle.com>

Hi Jon,


On 6/27/2018 12:50 PM, Jonathan Gibbons wrote:
> Joe,
>
> javac Source.java
>
> ? 83
> ? 84???? /** 1.11 covers the to be determined language features that 
> will be added in JDK 11. */
> ? 85???? JDK11("11"),
> ? 86
> ? 87???? /** 12 covers the to be determined language features that 
> will be added in JDK 12. */
> ? 88???? JDK12("12");
>
> It would be nice if the comment for 11 was updated.

Will replace "to be determined" with "no explicit language changes".

>
> javac Profile.java
>
> Nothing wrong in your edit, but maybe we should revisit/restrict this 
> feature in due course.

Agreed; this would be a good item to review later in 12; filed 
JDK-8205952: Review profile feature

>
> javac PrintingProcessor
>
> OK, but RFE: since this is part of javac, perhaps we could replace the 
> annotation with an
> override of the getSupportedSourceVersion method, returning 
> SourceVersion.latest.

There are some reasons I'd prefer not to do that; I'll follow-up 
separately to discuss my rationale.

>
> jdeps Main
>
> OK, but RFE: compute the list of releasesWithForRemoval, from 9 up to 
> java.spec.version

Created JDK-8205950: Have jdeprscan compute releasesWithForRemoval more 
dynamically

>
> javac test JavacTestingAbstractProcessor.java
>
> OK, but RFE: perhaps we could replace the annotations with an
> override of the getSupportedSourceVersion method, returning 
> SourceVersion.latest.

Filed JDK-8205951: Reduce size of edits needed to update 
JavacTestingAbstractProcessor

Thanks for the review,

-Joe



From mark.reinhold at oracle.com  Wed Jun 27 22:08:46 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 27 Jun 2018 15:08:46 -0700
Subject: 11 RFR (XS) 8205956: Fix usage of =?utf-8?B?4oCcT3BlbkpES+KAnQ==?=
 in build and test instructions
Message-ID: <20180627150846.445612282@eggemoggin.niobe.net>

Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/

Quick links to handier HTML diffs:

  http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
  http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html

?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
As such it should be used only as an adjective, and not as a noun.
Phrases such as ?the OpenJDK? could be replaced by the more correct,
and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
but in most cases the context is sufficiently clear that we can just
write ?the JDK.?

- Mark


[1] http://openjdk.java.net/legal/openjdk-trademark-notice.html


From erik.joelsson at oracle.com  Wed Jun 27 22:29:46 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 15:29:46 -0700
Subject: RFR: JDK-8205942: Build failure on macosx after JDK-8189429
Message-ID: <9944fcf1-e218-e912-b526-a10f2fb5b813@oracle.com>

For some users, the build fails with:

dirname: illegal option -- s
usage: dirname path
usage: basename string [suffix]
 ?????? basename [-a] [-s suffix] string [...]
error: cannot read file 
/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c 

Gensrc-jdk.hotspot.agent.gmk:52: recipe for target 
'/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c' 
failed
make[3]: *** 
[/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c] 
Error 1
make/Main.gmk:112: recipe for target 'jdk.hotspot.agent-gensrc-src' failed
make[2]: *** [jdk.hotspot.agent-gensrc-src] Error 2
make[2]: *** Waiting for unfinished jobs....

I have identified two reasons for failures here and this patch makes it 
work for at least one reporter of the problem. The missing MakeTargetDir 
caues a race where the target directory may not exist yet. It seems mig 
on newer Macos handles this anyway. For some configurations, the SDKROOT 
variable does not have a value. In that case, we should not set the 
-isysroot parameter to mig. (I also changed the MKDIR in the other 
recipe to the now preferred MakeTargetDir macro)

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

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

/Erik



From lance.andersen at oracle.com  Wed Jun 27 22:32:21 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 27 Jun 2018 18:32:21 -0400
Subject: RFR: JDK-8205942: Build failure on macosx after JDK-8189429
In-Reply-To: <9944fcf1-e218-e912-b526-a10f2fb5b813@oracle.com>
References: <9944fcf1-e218-e912-b526-a10f2fb5b813@oracle.com>
Message-ID: <9A033A2D-DB5C-4812-A11B-D37D5F09991A@oracle.com>

I can verify the patch worked for me Erik

Best
Lance
> On Jun 27, 2018, at 6:29 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> For some users, the build fails with:
> 
> dirname: illegal option -- s
> usage: dirname path
> usage: basename string [suffix]
>        basename [-a] [-s suffix] string [...]
> error: cannot read file /Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c 
> Gensrc-jdk.hotspot.agent.gmk:52: recipe for target '/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c' failed
> make[3]: *** [/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c] Error 1
> make/Main.gmk:112: recipe for target 'jdk.hotspot.agent-gensrc-src' failed
> make[2]: *** [jdk.hotspot.agent-gensrc-src] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> I have identified two reasons for failures here and this patch makes it work for at least one reporter of the problem. The missing MakeTargetDir caues a race where the target directory may not exist yet. It seems mig on newer Macos handles this anyway. For some configurations, the SDKROOT variable does not have a value. In that case, we should not set the -isysroot parameter to mig. (I also changed the MKDIR in the other recipe to the now preferred MakeTargetDir macro)
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205942
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8205942/webrev.01/
> 
> /Erik
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>





From erik.joelsson at oracle.com  Wed Jun 27 22:33:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 27 Jun 2018 15:33:52 -0700
Subject: =?UTF-8?Q?Re:_11_RFR_=28XS=29_8205956:_Fix_usage_of_=e2=80=9cOpenJD?=
 =?UTF-8?Q?K=e2=80=9d_in_build_and_test_instructions?=
In-Reply-To: <20180627150846.445612282@eggemoggin.niobe.net>
References: <20180627150846.445612282@eggemoggin.niobe.net>
Message-ID: <6ab7d348-d1b5-cc7d-ba61-a8c7ac95ec6a@oracle.com>

Looks good.

/Erik


On 2018-06-27 15:08, mark.reinhold at oracle.com wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
> Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/
>
> Quick links to handier HTML diffs:
>
>    http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
>    http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html
>
> ?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
> As such it should be used only as an adjective, and not as a noun.
> Phrases such as ?the OpenJDK? could be replaced by the more correct,
> and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
> but in most cases the context is sufficiently clear that we can just
> write ?the JDK.?
>
> - Mark
>
>
> [1] http://openjdk.java.net/legal/openjdk-trademark-notice.html



From tim.bell at oracle.com  Wed Jun 27 22:45:40 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 27 Jun 2018 15:45:40 -0700
Subject: RFR: JDK-8205942: Build failure on macosx after JDK-8189429
In-Reply-To: <9A033A2D-DB5C-4812-A11B-D37D5F09991A@oracle.com>
References: <9944fcf1-e218-e912-b526-a10f2fb5b813@oracle.com>
 <9A033A2D-DB5C-4812-A11B-D37D5F09991A@oracle.com>
Message-ID: <5B341394.8020208@oracle.com>

Erik:

Looks good to me as well.

/Tim

On 06/27/18 15:32, Lance Andersen wrote:
> I can verify the patch worked for me Erik
>
> Best
> Lance
>> On Jun 27, 2018, at 6:29 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> For some users, the build fails with:
>>
>> dirname: illegal option -- s
>> usage: dirname path
>> usage: basename string [suffix]
>>         basename [-a] [-s suffix] string [...]
>> error: cannot read file /Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c
>> Gensrc-jdk.hotspot.agent.gmk:52: recipe for target '/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c' failed
>> make[3]: *** [/Users/danielfuchs/workspaces/jdk/jdk-dev/build/macosx-x64/support/gensrc/jdk.hotspot.agent/mach_excServer.c] Error 1
>> make/Main.gmk:112: recipe for target 'jdk.hotspot.agent-gensrc-src' failed
>> make[2]: *** [jdk.hotspot.agent-gensrc-src] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>>
>> I have identified two reasons for failures here and this patch makes it work for at least one reporter of the problem. The missing MakeTargetDir caues a race where the target directory may not exist yet. It seems mig on newer Macos handles this anyway. For some configurations, the SDKROOT variable does not have a value. In that case, we should not set the -isysroot parameter to mig. (I also changed the MKDIR in the other recipe to the now preferred MakeTargetDir macro)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205942
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8205942/webrev.01/
>>
>> /Erik



From tim.bell at oracle.com  Wed Jun 27 23:19:58 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 27 Jun 2018 16:19:58 -0700
Subject: 11 RFR (XS) 8205956: Fix usage of =?UTF-8?B?4oCcT3BlbkpES+KAnQ==?=
 =?UTF-8?B?IGluIGJ1aWxkIGFuZCB0ZXN0IGluc3RydWN0aW9ucw==?=
In-Reply-To: <6ab7d348-d1b5-cc7d-ba61-a8c7ac95ec6a@oracle.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <6ab7d348-d1b5-cc7d-ba61-a8c7ac95ec6a@oracle.com>
Message-ID: <5B341B9E.7050700@oracle.com>

Mark-

Looks good to me as well.

Tim

On 06/27/18 15:33, Erik Joelsson wrote:
> Looks good.
>
> /Erik
>
>
> On 2018-06-27 15:08, mark.reinhold at oracle.com wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
>> Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/





From sundararajan.athijegannathan at oracle.com  Thu Jun 28 04:53:22 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 28 Jun 2018 10:23:22 +0530
Subject: RFR 8204492 Add deprecation annotation to Nashorn APIs and warning
 to nashorn, jjs
In-Reply-To: <70af42e4-4db2-320f-acf3-9940e61d9bd6@oracle.com>
References: <5B330F8B.1050509@oracle.com> <5B331055.4060305@oracle.com>
 <50db4ba6-da6a-7541-ffe5-588822006530@oracle.com> <5B33B446.40109@oracle.com>
 <70af42e4-4db2-320f-acf3-9940e61d9bd6@oracle.com>
Message-ID: <5B3469C2.6070003@oracle.com>

Only -deprecation still results in build failure :( I'll go with what 
I've now to push the change before the deadline -- and we can revisit 
better makefile option in a future patch.

Thanks,
-Sundar

On 27/06/18, 9:29 PM, Erik Joelsson wrote:
> If it's just deprecation you want to remove, then 
> -Xlint:all,-deprecation should be enough to add. The current argument 
> for jdk.scripting.nashorn is -Xlint:all (if I'm not mistaken).
>
> /Erik
>
>
> On 2018-06-27 08:59, Sundararajan Athijegannathan wrote:
>> Hi Erik,
>>
>> Yes, nashorn is warning free afaik. Besides nashorn is being 
>> deprecated. No further development expected other than perhaps 
>> occasional bug fixes.
>>
>> We need to disable javac deprecation warnings. Without this javac 
>> deprecation warnings cause build failure.
>>
>> -Sundar
>>
>> On 27/06/18, 9:11 PM, Erik Joelsson wrote:
>>> Hello Sundar,
>>>
>>> Adding $(DISABLE_WARNINGS) disables a lot of warnings. Isn't 
>>> jdk.scripting.nashorn pretty much warning frree now? What warnings 
>>> do you really need to disable?
>>>
>>> /Erik
>>>
>>>
>>> On 2018-06-26 21:19, Sundararajan Athijegannathan wrote:
>>>> Forgot to CC build-dev for makefile changes.
>>>>
>>>> -Sundar
>>>>
>>>> On 27/06/18, 9:46 AM, Sundararajan Athijegannathan wrote:
>>>>> Please review.
>>>>>
>>>>> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
>>>>> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>>>>>
>>>>> Related:
>>>>>
>>>>> JEP http://openjdk.java.net/jeps/335
>>>>> CSR https://bugs.openjdk.java.net/browse/JDK-8205594
>>>>>
>>>>> Thanks,
>>>>> -Sundar
>>>>>
>>>
>


From volker.simonis at gmail.com  Thu Jun 28 06:21:34 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 Jun 2018 08:21:34 +0200
Subject: =?UTF-8?Q?Re=3A_11_RFR_=28XS=29_8205956=3A_Fix_usage_of_=E2=80=9COpenJDK=E2=80=9D_?=
 =?UTF-8?Q?in_build_and_test_instructions?=
In-Reply-To: <20180627150846.445612282@eggemoggin.niobe.net>
References: <20180627150846.445612282@eggemoggin.niobe.net>
Message-ID: <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>

On Thu, Jun 28, 2018 at 12:08 AM,  <mark.reinhold at oracle.com> wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
> Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/
>
> Quick links to handier HTML diffs:
>
>   http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
>   http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html
>
> ?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
> As such it should be used only as an adjective, and not as a noun.
> Phrases such as ?the OpenJDK? could be replaced by the more correct,
> and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
> but in most cases the context is sufficiently clear that we can just
> write ?the JDK.?
>

Sorry, but I don't see any sense in this change!

Do you plan to do the same for the OpenJDK web pages and the OpenJDK
Wiki. Do you plan to scan all the OpenJDK mails and reject them if
they use "OpenJDK" inappropriately?

And by the way, "JDK" is an Oracle trademark as well (see [1]) so this
change is basically a NOP.

Best regards,
Volker

[1] http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4807:9evmnn.2.10

> - Mark
>
>
> [1] http://openjdk.java.net/legal/openjdk-trademark-notice.html


From volker.simonis at gmail.com  Thu Jun 28 06:52:57 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 Jun 2018 08:52:57 +0200
Subject: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to
 handle both, RPATH and RUNPATH
In-Reply-To: <d90f218c-354a-faf4-42cc-ead249bfa57d@oracle.com>
References: <CA+3eh13wcy3d0BykomPBPZaupC_=BTX9zhZDBHB45F73QRWZBw@mail.gmail.com>
 <d90f218c-354a-faf4-42cc-ead249bfa57d@oracle.com>
Message-ID: <CA+3eh13yo7MhD8apDcq6i2Bb7MZjKxXGWrmYPUSsyHmXqcsuiA@mail.gmail.com>

Hi Martin, Erik,

thanks for the reviews!

Regards,
Volker


On Wed, Jun 27, 2018 at 5:53 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Looks ok to me.
>
> /Erik
>
>
>
> On 2018-06-27 03:26, Volker Simonis wrote:
>>
>> Hi,
>>
>> can I please have a review for the following tiny test fix (I'm
>> actually not sure which would be the appropriate mailing list for this
>> fix so please redirect if necessary):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/
>> https://bugs.openjdk.java.net/browse/JDK-8205916
>>
>> The test currently only checks for RPATH in the dynamic section of the
>> launcher, but some linkers / Linux distributions (notably SLES) use
>> RUNPATH instead.
>>
>> Following are the gory details:
>>
>> The test jdk/tools/launcher/RunpathTest.java checks that the java
>> launcher on Linux and Solaris has the correct RPATH path baked into
>> the executable.
>>
>> Unfortunately, the situation with RPATH is a little weird:
>>
>>    - in order to bake a runtime path into a dynamically linked library
>> or executable one has to use the "-rpath <PATH>" linker option (from
>> the C/C++ compiler this is usually available as "-Wl,-rpath,<path>").
>>    - depending on the dynamic linker version and Linux distribution,
>> the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04,
>> RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries
>> together (SLES 11.3) to the dynamic section of the shared
>> library/executable.
>>    - the semantics of "RPATH" and "RUNPATH" are slightly different:
>> "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH"
>> isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH
>> (i.e. RUNPATH can be overridden at runtime by setting
>> LD_LIBRARY_PATH).
>>    - "RPATH" is considered obsolete and should be replaced by "RUNPATH"
>> according to the man-page of "ld.so (8)".
>>    - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or
>> the corresponding compiler flags
>> "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to
>> enforce the generation of "RUNPATH"/"RPATH" respectively (except for
>> systems like SLES 11.3 where "--enable-new-dtags" generates both
>> "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates
>> "RPATH").
>>
>> But this issue is not about fixing the build so to cut a long story
>> short - the test RunpathTest.java should be able to handle both
>> runtime path variants equally well. This can be easily achieved by
>> extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to
>> ".*R(UN)?PATH.*\\$ORIGIN/../lib.*"
>>
>> Thank you and best regards,
>> Volker
>
>


From shade at redhat.com  Thu Jun 28 07:14:26 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Jun 2018 09:14:26 +0200
Subject: =?UTF-8?Q?Re:_11_RFR_=28XS=29_8205956:_Fix_usage_of_=e2=80=9cOpenJD?=
 =?UTF-8?Q?K=e2=80=9d_in_build_and_test_instructions?=
In-Reply-To: <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
Message-ID: <9f993a76-2afb-652b-1680-a1282ef3153a@redhat.com>

On 06/28/2018 08:21 AM, Volker Simonis wrote:
> On Thu, Jun 28, 2018 at 12:08 AM,  <mark.reinhold at oracle.com> wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
>> Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/
>>
>> Quick links to handier HTML diffs:
>>
>>   http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
>>   http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html
>>
>> ?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
>> As such it should be used only as an adjective, and not as a noun.
>> Phrases such as ?the OpenJDK? could be replaced by the more correct,
>> and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
>> but in most cases the context is sufficiently clear that we can just
>> write ?the JDK.?
>>
> 
> Sorry, but I don't see any sense in this change!

+1

Also, "(open-source) JDK" is way too generic, and does awkwardly apply to other JDK's in the wild,
including IBM's, Azul's, Excelsior's, etc. It stands to reason that build/test instruction for
OpenJDK project use "OpenJDK" to describe what those instructions apply to. It seems less confusing
to find the appropriate noun to go with "OpenJDK", e.g. "OpenJDK build", "OpenJDK binary", "OpenJDK
workspace", etc?

-Aleksey



From Pengfei.Li at arm.com  Thu Jun 28 10:01:08 2018
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Thu, 28 Jun 2018 10:01:08 +0000
Subject: RFR: 8202794: Native Unix code should use readdir rather than
 readdir_r
Message-ID: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>

Hi

Last month, Bernard proposed a patch to fix the OpenJDK build issue with recent versions of glibc.
See http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html
But this fix requires to be tested on all POSIX systems before getting integrated.

As recently, more and more guys are complaining about the OpenJDK build failure issue, shall we just add the following workaround to upstream before Bernard's real fix eventually merged?


diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c b/src/java.base/unix/native/libjava/TimeZone_md.c
index f0bb362afc..e156381acd 100644
--- a/src/java.base/unix/native/libjava/TimeZone_md.c
+++ b/src/java.base/unix/native/libjava/TimeZone_md.c
@@ -146,7 +146,7 @@ findZoneinfoFile(char *buf, size_t size, const char *dir)
         (void) closedir(dirp);
         return NULL;
     }
-
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) {
         /*
          * Skip '.' and '..' (and possibly other .* files)
diff --git a/src/java.base/unix/native/libjava/UnixFileSystem_md.c b/src/java.base/unix/native/libjava/UnixFileSystem_md.c
index 315aa92b64..5b9554dd47 100644
--- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c
+++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c
@@ -339,6 +339,7 @@ Java_java_io_UnixFileSystem_list(JNIEnv *env, jobject this,
     if (rv == NULL) goto error;

     /* Scan the directory */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     while ((readdir64_r(dir, ptr, &result) == 0)  && (result != NULL)) {
         jstring name;
         if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, ".."))
diff --git a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
index 53bb1c1009..72c38eb9a6 100644
--- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
+++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
@@ -731,6 +731,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv* env, jclass this, jlong val

     /* EINTR not listed as a possible error */
     /* TDB: reentrant version probably not required here */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     res = readdir64_r(dirp, ptr, &result);

#ifdef _AIX
diff --git a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
index 1adeaf7bb5..080cf2a89b 100644
--- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
+++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
@@ -80,6 +80,7 @@ static struct dirent* read_dir(DIR* dirp, struct dirent* entry) {
     return dbuf;
#else /* __linux__ || _ALLBSD_SOURCE */
     struct dirent* p;
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     if (readdir_r(dirp, entry, &p) == 0) {
         return p;
     } else {


--
Thanks,
Pengfei


From mark.reinhold at oracle.com  Thu Jun 28 14:50:06 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Jun 2018 07:50:06 -0700
Subject: 11 RFR (XS) 8205956: Fix usage of =?utf-8?B?4oCcT3BlbkpESw==?=
 =?utf-8?B?4oCd?= in build and test instructions
In-Reply-To: <5B341B9E.7050700@oracle.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <6ab7d348-d1b5-cc7d-ba61-a8c7ac95ec6a@oracle.com>
 <5B341B9E.7050700@oracle.com>
Message-ID: <20180628075006.697432914@eggemoggin.niobe.net>

2018/6/27 16:19:58 -0700, tim.bell at oracle.com:
> Looks good to me as well.
> 
> Tim
> 
> On 06/27/18 15:33, Erik Joelsson wrote:
>> Looks good.
>> 
>> /Erik

Thanks!

- Mark


From shade at redhat.com  Thu Jun 28 17:08:03 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Jun 2018 19:08:03 +0200
Subject: =?UTF-8?Q?Re:_11_RFR_=28XS=29_8205956:_Fix_usage_of_=e2=80=9cOpenJD?=
 =?UTF-8?Q?K=e2=80=9d_in_build_and_test_instructions?=
In-Reply-To: <9f993a76-2afb-652b-1680-a1282ef3153a@redhat.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
 <9f993a76-2afb-652b-1680-a1282ef3153a@redhat.com>
Message-ID: <d6722b56-7951-0900-7f76-cc73f2eab4b3@redhat.com>

On 06/28/2018 09:14 AM, Aleksey Shipilev wrote:
> On 06/28/2018 08:21 AM, Volker Simonis wrote:
>> On Thu, Jun 28, 2018 at 12:08 AM,  <mark.reinhold at oracle.com> wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
>>> Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/
>>>
>>> Quick links to handier HTML diffs:
>>>
>>>   http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
>>>   http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html
>>>
>>> ?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
>>> As such it should be used only as an adjective, and not as a noun.
>>> Phrases such as ?the OpenJDK? could be replaced by the more correct,
>>> and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
>>> but in most cases the context is sufficiently clear that we can just
>>> write ?the JDK.?
>>>
>>
>> Sorry, but I don't see any sense in this change!
>> 
>> And by the way, "JDK" is an Oracle trademark as well (see [1]) so this
>> change is basically a NOP.
> 
> +1
> 
> Also, "(open-source) JDK" is way too generic, and does awkwardly apply to other JDK's in the wild,
> including IBM's, Azul's, Excelsior's, etc. It stands to reason that build/test instruction for
> OpenJDK project use "OpenJDK" to describe what those instructions apply to. It seems less confusing
> to find the appropriate noun to go with "OpenJDK", e.g. "OpenJDK build", "OpenJDK binary", "OpenJDK
> workspace", etc?

I hate to be "that guy", but cannot help to notice the change was pushed [1] with comments above by
Volker and myself ignored, and not even acknowledged. I hope this is not how reviews work in
OpenJDK... JDK? work now.

-Aleksey

[1] http://hg.openjdk.java.net/jdk/jdk/rev/7c728fa9d1af



From mark.reinhold at oracle.com  Thu Jun 28 18:02:54 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Jun 2018 11:02:54 -0700
Subject: 11 RFR (XS) 8205956: Fix usage of =?utf-8?B?4oCcT3BlbkpESw==?=
 =?utf-8?B?4oCd?= in build and test instructions
In-Reply-To: <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
Message-ID: <20180628110254.775551120@eggemoggin.niobe.net>

2018/6/27 23:21:34 -0700, volker.simonis at gmail.com:
> On Thu, Jun 28, 2018 at 12:08 AM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> ?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
>> As such it should be used only as an adjective, and not as a noun.
>> Phrases such as ?the OpenJDK? could be replaced by the more correct,
>> and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
>> but in most cases the context is sufficiently clear that we can just
>> write ?the JDK.?
>> 
> 
> Sorry, but I don't see any sense in this change!

Trademark law doesn?t always make a lot of sense.

> Do you plan to do the same for the OpenJDK web pages and the OpenJDK
> Wiki.

Yes, on a best-effort basis, but priority will be given to more-prominent
documents such as these.

>       Do you plan to scan all the OpenJDK mails and reject them if
> they use "OpenJDK" inappropriately?

No, of course not.  That?d be silly.

> And by the way, "JDK" is an Oracle trademark as well (see [1]) so this
> change is basically a NOP.

Trademark law doesn?t always make a lot of sense.

- Mark


From mark.reinhold at oracle.com  Thu Jun 28 18:02:59 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Jun 2018 11:02:59 -0700
Subject: 11 RFR (XS) 8205956: Fix usage of =?utf-8?B?4oCcT3BlbkpESw==?=
 =?utf-8?B?4oCd?= in build and test instructions
In-Reply-To: <9f993a76-2afb-652b-1680-a1282ef3153a@redhat.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
 <9f993a76-2afb-652b-1680-a1282ef3153a@redhat.com>
Message-ID: <20180628110259.847223206@eggemoggin.niobe.net>

2018/6/28 0:14:26 -0700, Aleksey Shipilev <shade at redhat.com>:
> On 06/28/2018 08:21 AM, Volker Simonis wrote:
>> Sorry, but I don't see any sense in this change!
> 
> +1
> 
> Also, "(open-source) JDK" is way too generic, and does awkwardly apply
> to other JDK's in the wild, including IBM's, Azul's, Excelsior's,
> etc.

Agreed.  That?s another reason not to use that term.

>      It stands to reason that build/test instruction for OpenJDK
> project use "OpenJDK" to describe what those instructions apply to. It
> seems less confusing to find the appropriate noun to go with
> "OpenJDK", e.g. "OpenJDK build", "OpenJDK binary", "OpenJDK
> workspace", etc?

Yes, we could do that, but why use even more words to describe what
everyone knows is just ?the JDK??

When we started the OpenJDK Community we intentionally chose not to
use ?OpenJDK? in the names of the Projects that produce JDK feature and
update releases.  That?d just be redundant: ?The OpenJDK Project in the
OpenJDK Community??

Similar reasoning applies here.  The context of these instructions makes
it clear that they?re for the source code to a JDK implementation that
you found in the OpenJDK Community.  There?s no need to insert ?OpenJDK?
everywhere.

- Mark


From philip.race at oracle.com  Thu Jun 28 18:11:51 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Jun 2018 11:11:51 -0700
Subject: =?UTF-8?Q?Re:_11_RFR_=28XS=29_8205956:_Fix_usage_of_=e2=80=9cOpenJD?=
 =?UTF-8?Q?K=e2=80=9d_in_build_and_test_instructions?=
In-Reply-To: <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
Message-ID: <37e23b75-d565-9747-0a33-ba2d85d4619d@oracle.com>

I see the TM for JDK as Volker notes,
but searching for OpenJDK at the same site turns up nothing ..

-phil

On 06/27/2018 11:21 PM, Volker Simonis wrote:
> And by the way, "JDK" is an Oracle trademark as well (see [1]) so this
> change is basically a NOP.
>
> Best regards,
> Volker
>
> [1]http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4807:9evmnn.2.10



From jiangli.zhou at Oracle.COM  Thu Jun 28 23:15:07 2018
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Thu, 28 Jun 2018 16:15:07 -0700
Subject: RFR(L): 8202035: Archive the set of ModuleDescriptor and
 ModuleReference objects for system modules
Message-ID: <386DA770-8E9D-43A0-87CE-0E380977F884@oracle.com>

This is a follow-up RFE of JDK-8201650 (Move iteration order randomization of unmodifiable Set and Map to iterators), which was resolved to allow Set/Map objects being archived at CDS dump time (thanks Claes and Stuart Marks). In the current RFE, it archives the set of system ModuleReference and ModuleDescriptor objects (including their referenced objects) in 'open' archive heap region at CDS dump time. It allows reusing of the objects and bypassing the process of creating the system ModuleDescriptors and ModuleReferences at runtime for startup improvement. My preliminary measurements on linux-x64 showed ~5% startup improvement when running HelloWorld from -cp using archived module objects at runtime (without extra tuning).

The library changes in the following webrev are contributed by Alan Bateman. Thanks Alan and Mandy for discussions and help. Thanks Karen, Lois and Ioi for discussion and suggestions on initialization ordering.

The majority of the module object archiving code are in heapShared.hpp and heapShared.cpp. Thanks Coleen for pre-review and Eric Caspole for helping performance tests.

webrev: http://cr.openjdk.java.net/~jiangli/8202035/webrev.00/
RFE: https://bugs.openjdk.java.net/browse/JDK-8202035?filter=14921

Tested using tier1 - tier6 via mach5 including all new test cases added in the webrev.

Following are the details of system module archiving, which are duplicated in above bug report.
---------------------------------------------------------------------------------------------------------------------------
Support archiving system module graph when the initial module is unnamed module from -cp currently. 

Support G1 GC, 64-bit (non-Windows). Requires UseCompressedOops and UseCompressedClassPointers. 

Dump time system module object archiving 
================================= 
At dump time, the following fields in ArchivedModuleGraph are set to record the system module information created by ModuleBootstrap for archiving. 

 private static SystemModules archivedSystemModules;  
 private static ModuleFinder archivedSystemModuleFinder;  
 private static String archivedMainModule; 

The archiving process starts from a given static field in ArchivedModuleGraph class instance (java mirror object). The process archives the complete network of java heap objects that are reachable directly or indirectly from the starting object by following references. 

1. Starts from a given static field within the Class instance (java mirror). If the static field is a refererence field and points to a non-null java object, proceed to the next step. The static field and it's value is recorded and stored outside the archived mirror. 
2. Archives the referenced java object. If an archived copy of the current object already exists, updates the pointer in the archived copy of the referencing object to point to the current archived object. Otherwise, proceed to the next step. 
3. Follows all references within the current java object and recursively archive the sub-graph of objects starting from each reference encountered within the object. 
4. Updates the pointer in the archived copy of referecing object to point to the current archived object. 
5. The Klass of the current java object is added to a list of Klasses for loading and initializing before any object in the archived graph can be accessed at runtime. 

Runtime initialization from archived system module objects 
============================================ 
VM.initializeFromArchive(<class>) is called from ArchivedModuleGraph's static initializer to initialize from the archived module information. Klasses in the recorded list are loaded, linked and initialized. The static fields in ArchivedModuleGraph class instance are initialized using the archived field values. After initialization, the archived system module objects can be used directly. 

If the archived java heap data is not successfully mapped at runtime, or there is an error during VM.initializeFromArchive(), then all static fields in ArchivedModuleGraph are not initialized. In that case, system ModuleDescriptor and ModuleReference objects are created as normal.

In non-CDS mode, VM.initializeFromArchive(<class>) returns immediately with minimum added overhead for normal execution.

Thanks,
Jiangli




From erik.joelsson at oracle.com  Fri Jun 29 00:44:12 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 28 Jun 2018 17:44:12 -0700
Subject: RFR(L): 8202035: Archive the set of ModuleDescriptor and
 ModuleReference objects for system modules
In-Reply-To: <386DA770-8E9D-43A0-87CE-0E380977F884@oracle.com>
References: <386DA770-8E9D-43A0-87CE-0E380977F884@oracle.com>
Message-ID: <673771d5-0e61-6338-d222-9d1bd7f2826b@oracle.com>

Build changes look good.

/Erik


On 2018-06-28 16:15, Jiangli Zhou wrote:
> This is a follow-up RFE of JDK-8201650 (Move iteration order randomization of unmodifiable Set and Map to iterators), which was resolved to allow Set/Map objects being archived at CDS dump time (thanks Claes and Stuart Marks). In the current RFE, it archives the set of system ModuleReference and ModuleDescriptor objects (including their referenced objects) in 'open' archive heap region at CDS dump time. It allows reusing of the objects and bypassing the process of creating the system ModuleDescriptors and ModuleReferences at runtime for startup improvement. My preliminary measurements on linux-x64 showed ~5% startup improvement when running HelloWorld from -cp using archived module objects at runtime (without extra tuning).
>
> The library changes in the following webrev are contributed by Alan Bateman. Thanks Alan and Mandy for discussions and help. Thanks Karen, Lois and Ioi for discussion and suggestions on initialization ordering.
>
> The majority of the module object archiving code are in heapShared.hpp and heapShared.cpp. Thanks Coleen for pre-review and Eric Caspole for helping performance tests.
>
> webrev: http://cr.openjdk.java.net/~jiangli/8202035/webrev.00/
> RFE: https://bugs.openjdk.java.net/browse/JDK-8202035?filter=14921
>
> Tested using tier1 - tier6 via mach5 including all new test cases added in the webrev.
>
> Following are the details of system module archiving, which are duplicated in above bug report.
> ---------------------------------------------------------------------------------------------------------------------------
> Support archiving system module graph when the initial module is unnamed module from -cp currently.
>
> Support G1 GC, 64-bit (non-Windows). Requires UseCompressedOops and UseCompressedClassPointers.
>
> Dump time system module object archiving
> =================================
> At dump time, the following fields in ArchivedModuleGraph are set to record the system module information created by ModuleBootstrap for archiving.
>
>   private static SystemModules archivedSystemModules;
>   private static ModuleFinder archivedSystemModuleFinder;
>   private static String archivedMainModule;
>
> The archiving process starts from a given static field in ArchivedModuleGraph class instance (java mirror object). The process archives the complete network of java heap objects that are reachable directly or indirectly from the starting object by following references.
>
> 1. Starts from a given static field within the Class instance (java mirror). If the static field is a refererence field and points to a non-null java object, proceed to the next step. The static field and it's value is recorded and stored outside the archived mirror.
> 2. Archives the referenced java object. If an archived copy of the current object already exists, updates the pointer in the archived copy of the referencing object to point to the current archived object. Otherwise, proceed to the next step.
> 3. Follows all references within the current java object and recursively archive the sub-graph of objects starting from each reference encountered within the object.
> 4. Updates the pointer in the archived copy of referecing object to point to the current archived object.
> 5. The Klass of the current java object is added to a list of Klasses for loading and initializing before any object in the archived graph can be accessed at runtime.
>
> Runtime initialization from archived system module objects
> ============================================
> VM.initializeFromArchive(<class>) is called from ArchivedModuleGraph's static initializer to initialize from the archived module information. Klasses in the recorded list are loaded, linked and initialized. The static fields in ArchivedModuleGraph class instance are initialized using the archived field values. After initialization, the archived system module objects can be used directly.
>
> If the archived java heap data is not successfully mapped at runtime, or there is an error during VM.initializeFromArchive(), then all static fields in ArchivedModuleGraph are not initialized. In that case, system ModuleDescriptor and ModuleReference objects are created as normal.
>
> In non-CDS mode, VM.initializeFromArchive(<class>) returns immediately with minimum added overhead for normal execution.
>
> Thanks,
> Jiangli
>
>



From jiangli.zhou at oracle.com  Fri Jun 29 01:02:03 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 28 Jun 2018 18:02:03 -0700
Subject: RFR(L): 8202035: Archive the set of ModuleDescriptor and
 ModuleReference objects for system modules
In-Reply-To: <673771d5-0e61-6338-d222-9d1bd7f2826b@oracle.com>
References: <386DA770-8E9D-43A0-87CE-0E380977F884@oracle.com>
 <673771d5-0e61-6338-d222-9d1bd7f2826b@oracle.com>
Message-ID: <8BE8EC92-9624-4D8B-BF09-E7A5D41765DC@oracle.com>

Hi Erik,

Thank you for the quick review!

Jiangli

> On Jun 28, 2018, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Build changes look good.
> 
> /Erik
> 
> 
> On 2018-06-28 16:15, Jiangli Zhou wrote:
>> This is a follow-up RFE of JDK-8201650 (Move iteration order randomization of unmodifiable Set and Map to iterators), which was resolved to allow Set/Map objects being archived at CDS dump time (thanks Claes and Stuart Marks). In the current RFE, it archives the set of system ModuleReference and ModuleDescriptor objects (including their referenced objects) in 'open' archive heap region at CDS dump time. It allows reusing of the objects and bypassing the process of creating the system ModuleDescriptors and ModuleReferences at runtime for startup improvement. My preliminary measurements on linux-x64 showed ~5% startup improvement when running HelloWorld from -cp using archived module objects at runtime (without extra tuning).
>> 
>> The library changes in the following webrev are contributed by Alan Bateman. Thanks Alan and Mandy for discussions and help. Thanks Karen, Lois and Ioi for discussion and suggestions on initialization ordering.
>> 
>> The majority of the module object archiving code are in heapShared.hpp and heapShared.cpp. Thanks Coleen for pre-review and Eric Caspole for helping performance tests.
>> 
>> webrev: http://cr.openjdk.java.net/~jiangli/8202035/webrev.00/
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8202035?filter=14921
>> 
>> Tested using tier1 - tier6 via mach5 including all new test cases added in the webrev.
>> 
>> Following are the details of system module archiving, which are duplicated in above bug report.
>> ---------------------------------------------------------------------------------------------------------------------------
>> Support archiving system module graph when the initial module is unnamed module from -cp currently.
>> 
>> Support G1 GC, 64-bit (non-Windows). Requires UseCompressedOops and UseCompressedClassPointers.
>> 
>> Dump time system module object archiving
>> =================================
>> At dump time, the following fields in ArchivedModuleGraph are set to record the system module information created by ModuleBootstrap for archiving.
>> 
>>  private static SystemModules archivedSystemModules;
>>  private static ModuleFinder archivedSystemModuleFinder;
>>  private static String archivedMainModule;
>> 
>> The archiving process starts from a given static field in ArchivedModuleGraph class instance (java mirror object). The process archives the complete network of java heap objects that are reachable directly or indirectly from the starting object by following references.
>> 
>> 1. Starts from a given static field within the Class instance (java mirror). If the static field is a refererence field and points to a non-null java object, proceed to the next step. The static field and it's value is recorded and stored outside the archived mirror.
>> 2. Archives the referenced java object. If an archived copy of the current object already exists, updates the pointer in the archived copy of the referencing object to point to the current archived object. Otherwise, proceed to the next step.
>> 3. Follows all references within the current java object and recursively archive the sub-graph of objects starting from each reference encountered within the object.
>> 4. Updates the pointer in the archived copy of referecing object to point to the current archived object.
>> 5. The Klass of the current java object is added to a list of Klasses for loading and initializing before any object in the archived graph can be accessed at runtime.
>> 
>> Runtime initialization from archived system module objects
>> ============================================
>> VM.initializeFromArchive(<class>) is called from ArchivedModuleGraph's static initializer to initialize from the archived module information. Klasses in the recorded list are loaded, linked and initialized. The static fields in ArchivedModuleGraph class instance are initialized using the archived field values. After initialization, the archived system module objects can be used directly.
>> 
>> If the archived java heap data is not successfully mapped at runtime, or there is an error during VM.initializeFromArchive(), then all static fields in ArchivedModuleGraph are not initialized. In that case, system ModuleDescriptor and ModuleReference objects are created as normal.
>> 
>> In non-CDS mode, VM.initializeFromArchive(<class>) returns immediately with minimum added overhead for normal execution.
>> 
>> Thanks,
>> Jiangli
>> 
>> 
> 



From igor.ignatyev at oracle.com  Fri Jun 29 04:42:21 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 28 Jun 2018 21:42:21 -0700
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
Message-ID: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
> 1 line changed: 0 ins; 0 del; 1 mod; 

Hi all,

could you please review this one liner fix? 

webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB

Thanks,
-- Igor


From ekaterina.pavlova at oracle.com  Fri Jun 29 04:47:54 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Thu, 28 Jun 2018 21:47:54 -0700
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
In-Reply-To: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
References: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
Message-ID: <b515e0fc-4cff-ea7e-cf67-4f143e290dc5@oracle.com>

Good, thanks for quick response and webrev!

-katya

On 6/28/18 9:42 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>> 1 line changed: 0 ins; 0 del; 1 mod;
> 
> Hi all,
> 
> could you please review this one liner fix?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
> testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB
> 
> Thanks,
> -- Igor
> 



From erik.helin at oracle.com  Fri Jun 29 04:50:32 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 29 Jun 2018 06:50:32 +0200
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
In-Reply-To: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
References: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
Message-ID: <392fe894-88a4-0934-fc02-b3171e02d074@oracle.com>

On 06/29/2018 06:42 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>> 1 line changed: 0 ins; 0 del; 1 mod;
> 
> Hi all,
> 
> could you please review this one liner fix?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html

Hmmm, it seems like you are missing an end-of-string quotation mark in

+ $(info "Skip building of Graal unit tests because 3rd party libraries 
directory is not specified)

Or did I misunderstand the patch?
Thanks,
Erik

> JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
> testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB
> 
> Thanks,
> -- Igor
> 


From igor.ignatyev at oracle.com  Fri Jun 29 04:55:09 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 28 Jun 2018 21:55:09 -0700
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
In-Reply-To: <392fe894-88a4-0934-fc02-b3171e02d074@oracle.com>
References: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
 <392fe894-88a4-0934-fc02-b3171e02d074@oracle.com>
Message-ID: <A70E8099-1E31-4AE6-9B64-CC6317E62C91@oracle.com>

Hi Erik,

actually, I have a redundant quotation mark at the begging, removed. thanks for spotting this.

Thanks,
-- Igor

> On Jun 28, 2018, at 9:50 PM, Erik Helin <erik.helin at oracle.com> wrote:
> 
> On 06/29/2018 06:42 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>>> 1 line changed: 0 ins; 0 del; 1 mod;
>> Hi all,
>> could you please review this one liner fix?
>> webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
> 
> Hmmm, it seems like you are missing an end-of-string quotation mark in
> 
> + $(info "Skip building of Graal unit tests because 3rd party libraries directory is not specified)
> 
> Or did I misunderstand the patch?
> Thanks,
> Erik
> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
>> testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB
>> Thanks,
>> -- Igor



From erik.helin at oracle.com  Fri Jun 29 04:56:26 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 29 Jun 2018 06:56:26 +0200
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
In-Reply-To: <A70E8099-1E31-4AE6-9B64-CC6317E62C91@oracle.com>
References: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
 <392fe894-88a4-0934-fc02-b3171e02d074@oracle.com>
 <A70E8099-1E31-4AE6-9B64-CC6317E62C91@oracle.com>
Message-ID: <bd51ad70-c4f9-ddf3-d0f8-5a555adbd5f8@oracle.com>

On 06/29/2018 06:55 AM, Igor Ignatyev wrote:
> Hi Erik,
> 
> actually, I have a redundant quotation mark at the begging, removed. thanks for spotting this.

Yes, I realized that just as I had sent my email :) Anyways, patch looks 
good now, Reviewed.

Thanks,
Erik

> Thanks,
> -- Igor
> 
>> On Jun 28, 2018, at 9:50 PM, Erik Helin <erik.helin at oracle.com> wrote:
>>
>> On 06/29/2018 06:42 AM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>>>> 1 line changed: 0 ins; 0 del; 1 mod;
>>> Hi all,
>>> could you please review this one liner fix?
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>>
>> Hmmm, it seems like you are missing an end-of-string quotation mark in
>>
>> + $(info "Skip building of Graal unit tests because 3rd party libraries directory is not specified)
>>
>> Or did I misunderstand the patch?
>> Thanks,
>> Erik
>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
>>> testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB
>>> Thanks,
>>> -- Igor
> 


From igor.ignatyev at oracle.com  Fri Jun 29 05:00:11 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 28 Jun 2018 22:00:11 -0700
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
In-Reply-To: <bd51ad70-c4f9-ddf3-d0f8-5a555adbd5f8@oracle.com>
References: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
 <392fe894-88a4-0934-fc02-b3171e02d074@oracle.com>
 <A70E8099-1E31-4AE6-9B64-CC6317E62C91@oracle.com>
 <bd51ad70-c4f9-ddf3-d0f8-5a555adbd5f8@oracle.com>
Message-ID: <912AACE2-FF01-4199-B2C6-C018F83888E1@oracle.com>

Erik, Katya,

thank you for such fast reviews.

Cheers,
-- Igor

> On Jun 28, 2018, at 9:56 PM, Erik Helin <erik.helin at oracle.com> wrote:
> 
> On 06/29/2018 06:55 AM, Igor Ignatyev wrote:
>> Hi Erik,
>> actually, I have a redundant quotation mark at the begging, removed. thanks for spotting this.
> 
> Yes, I realized that just as I had sent my email :) Anyways, patch looks good now, Reviewed.
> 
> Thanks,
> Erik
> 
>> Thanks,
>> -- Igor
>>> On Jun 28, 2018, at 9:50 PM, Erik Helin <erik.helin at oracle.com> wrote:
>>> 
>>> On 06/29/2018 06:42 AM, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>>>>> 1 line changed: 0 ins; 0 del; 1 mod;
>>>> Hi all,
>>>> could you please review this one liner fix?
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>>> 
>>> Hmmm, it seems like you are missing an end-of-string quotation mark in
>>> 
>>> + $(info "Skip building of Graal unit tests because 3rd party libraries directory is not specified)
>>> 
>>> Or did I misunderstand the patch?
>>> Thanks,
>>> Erik
>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
>>>> testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB
>>>> Thanks,
>>>> -- Igor



From david.holmes at oracle.com  Fri Jun 29 05:32:55 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Jun 2018 15:32:55 +1000
Subject: RFR(XXS) : 8206088 : 8205207 broke builds
In-Reply-To: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
References: <2B0324FD-5550-497E-8736-A3AF1FE5C66C@oracle.com>
Message-ID: <1eda34bc-5028-46cf-6e47-bcc73a6b84de@oracle.com>

So now I only get spammed with this if LOG=info+ ?

Not sure why I need to be told about this if not asking for anything 
Graal related ...

David

On 29/06/2018 2:42 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
>> 1 line changed: 0 ins; 0 del; 1 mod;
> 
> Hi all,
> 
> could you please review this one liner fix?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8206088/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8206088
> testing:  make build-test-hotspot-jtreg-graal w/ empty GRAALUNIT_LIB
> 
> Thanks,
> -- Igor
> 


From VicWang at zhaoxin.com  Fri Jun 29 09:06:59 2018
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Fri, 29 Jun 2018 09:06:59 +0000
Subject: =?utf-8?B?562U5aSNOiBJbnF1aXJ5IHdoZXRoZXIgamRrOHUgY2FuIGNvbXBpbGUgd2l0?=
 =?utf-8?B?aCBpY2PvvJ8=?=
In-Reply-To: <CAOEheN4DUxR-pbk5LXuB8ou7VqTVzE-+DTifvO8udsNMfkjHNg@mail.gmail.com>
References: <9f5cb83ab2534d01982f4b339a4fbec3@zhaoxin.com>
 <4f78f97833204efb86511b16af87aaeb@zhaoxin.com>
 <4d86af32-21c1-2680-aec3-7fa8d45519b2@oracle.com>
 <7a9dfa8113d24e88ae70dd0eba6539ac@zhaoxin.com>
 <CAOEheN4DUxR-pbk5LXuB8ou7VqTVzE-+DTifvO8udsNMfkjHNg@mail.gmail.com>
Message-ID: <b8c0e1c1a7564167955fe3245ea81872@zhaoxin.com>

Hi Yumin:

       I?ve solved the compiling bugs by using ICC .
       You?re right. It?s not compatible with the static lib (libirc.a).
       With modifying the LDFLAGS with ?lirc, it can make successfully.
       But why using the ?O1 when linking? I?ve not clear for all the makefiles. I?ll study more about it.

Best Regards!
VicWang
???: yumin qi [mailto:yumin.qi at gmail.com]
????: 2018?6?27? 0:41
???: Vic Wang(BJ-RD) <VicWang at zhaoxin.com>
??: erik.joelsson at oracle.com; build-dev at openjdk.java.net
??: Re: Inquiry whether jdk8u can compile with icc?

The first error is known issue and fixed in jdk 9:
https://bugs.openjdk.java.net/browse/JDK-8016451

For the second one, I am not familiar with icc/icpc, it looks the linker find a static version which is not an expected version. you need to check the detail of library dependency.

Yumin

On Mon, Jun 25, 2018 at 11:57 PM Vic Wang(BJ-RD) <VicWang at zhaoxin.com<mailto:VicWang at zhaoxin.com>> wrote:
Hi Erik,

Yeah, it need to modify some configure files before generating the Makefile file. But I am not lucky to build the binary successfully. It occurs some ld's error.
>ld: /home/vic/Desktop/JVM/sourcecode/tmp/tmp/openjdk-jdk8u-jdk8u/build/linux-x86_64-normal-server-release/jdk/objs/java_objs/java: local symbol `__intel_sse2_strrchr' in /opt/intel/composer_xe_2015.2.164/compiler/lib/intel64/libirc.a(sse2_strrchr.o) is referenced by DSO
>ld: final link failed: Bad value
Do you have any ideas for this?
I want to build JVM on intel i5-6600k platform.
Thanks very much.

Best Regards!
VicWang


-----????-----
???: Erik Joelsson [mailto:erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com>]
????: 2018?6?26? 0:20
???: Vic Wang(BJ-RD) <VicWang at zhaoxin.com<mailto:VicWang at zhaoxin.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>
??: Re: Inquiry whether jdk8u can compile with icc?

Hello,

There is no support for ICC as far as I know. If ICC is compatible with the default toolchain for the platform, you may get something to work, but I doubt you will have any luck without modifying build logic.

Which platform are you trying to build on?

/Erik


On 2018-06-25 08:19, Vic Wang(BJ-RD) wrote:
> Hi,
>
>         I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler.
>         How to configure jvm before using ICC compiling?
>         If there are any tips for ICC compiling, please let me know. Thanks a lot.
>
> Best Regards!
> VicWang
>
>
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.



?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From volker.simonis at gmail.com  Fri Jun 29 10:03:09 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 29 Jun 2018 12:03:09 +0200
Subject: =?UTF-8?Q?Re=3A_11_RFR_=28XS=29_8205956=3A_Fix_usage_of_=E2=80=9COpenJDK=E2=80=9D_?=
 =?UTF-8?Q?in_build_and_test_instructions?=
In-Reply-To: <20180628110254.775551120@eggemoggin.niobe.net>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
 <20180628110254.775551120@eggemoggin.niobe.net>
Message-ID: <CA+3eh13ONyJa3gjOyq-kD_xbhtOJDmDV=o+PXAA922GmTGHbTw@mail.gmail.com>

On Thu, Jun 28, 2018 at 8:02 PM,  <mark.reinhold at oracle.com> wrote:
> 2018/6/27 23:21:34 -0700, volker.simonis at gmail.com:
>> On Thu, Jun 28, 2018 at 12:08 AM, mark.reinhold at oracle.com wrote:
>>> ...
>>>
>>> ?OpenJDK? is a trademarked term, per the OpenJDK Trademark Notice [1].
>>> As such it should be used only as an adjective, and not as a noun.
>>> Phrases such as ?the OpenJDK? could be replaced by the more correct,
>>> and much more verbose, ?the OpenJDK JDK,? or ?the open-source JDK,?
>>> but in most cases the context is sufficiently clear that we can just
>>> write ?the JDK.?
>>>
>>
>> Sorry, but I don't see any sense in this change!
>
> Trademark law doesn?t always make a lot of sense.
>
>> Do you plan to do the same for the OpenJDK web pages and the OpenJDK
>> Wiki.
>
> Yes, on a best-effort basis, but priority will be given to more-prominent
> documents such as these.
>
>>       Do you plan to scan all the OpenJDK mails and reject them if
>> they use "OpenJDK" inappropriately?
>
> No, of course not.  That?d be silly.
>
>> And by the way, "JDK" is an Oracle trademark as well (see [1]) so this
>> change is basically a NOP.
>
> Trademark law doesn?t always make a lot of sense.
>

This still doesn't explain why replacing one trademark with another
one is helpful here. "Building the JDK" is clearly using the trademark
"JDK" as a noun and thus infringing the "sens-less" trademark laws.
After Phil's remark, OpenJDK doesn't even seem to be registered as a
trademark, so in that sense the old version "Building the OpenJDK"
seemed to be even more trademark law compliant.

And by the way, I totally agree with Aleksey that changes shouldn't be
pushed if reviewers raise concerns (at least not before these concerns
have been addressed). Just to quote your words about the new release
cadence: "..if your changes don't make it into this release, they will
make it in to the next one which is just six month away" :)

> - Mark


From mark.reinhold at oracle.com  Fri Jun 29 15:21:19 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 29 Jun 2018 08:21:19 -0700
Subject: 11 RFR (XS) 8205956: Fix usage of =?utf-8?B?4oCcT3BlbkpESw==?=
 =?utf-8?B?4oCd?= in build and test instructions
In-Reply-To: <CA+3eh13ONyJa3gjOyq-kD_xbhtOJDmDV=o+PXAA922GmTGHbTw@mail.gmail.com>
References: <20180627150846.445612282@eggemoggin.niobe.net>
 <CA+3eh11nVhE5prbtpKhAWOx21zcBYmhBCpbAPrNPrM3JSvYLcw@mail.gmail.com>
 <20180628110254.775551120@eggemoggin.niobe.net>
 <CA+3eh13ONyJa3gjOyq-kD_xbhtOJDmDV=o+PXAA922GmTGHbTw@mail.gmail.com>
Message-ID: <20180629082119.864721979@eggemoggin.niobe.net>

2018/6/29 3:03:09 -0700, volker.simonis at gmail.com:
> This still doesn't explain why replacing one trademark with another
> one is helpful here.

Perhaps some trademarks are more important than others.

> After Phil's remark, OpenJDK doesn't even seem to be registered as a
> trademark, so in that sense the old version "Building the OpenJDK"
> seemed to be even more trademark law compliant.

I?m not qualified to engage in a legal argument, in this or any other
forum, and neither is Phil.  In this matter I am following the advice of
Oracle?s legal department regarding the usage of Oracle?s trademarks.

> And by the way, I totally agree with Aleksey that changes shouldn't be
> pushed if reviewers raise concerns (at least not before these concerns
> have been addressed).

My apologies.  I had no idea this would turn out to be such a volatile
issue.

- Mark