From jaroslav.bachorik at datadoghq.com  Fri Nov  1 12:11:36 2019
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 1 Nov 2019 13:11:36 +0100
Subject: CFV: New JDK Committer: Denghui Dong
In-Reply-To: <CAJwKKmYcYruB8C5Xjykq1xeru-hMbiioLygAP=Srb75oB3pwmA@mail.gmail.com>
References: <CAJwKKmYcYruB8C5Xjykq1xeru-hMbiioLygAP=Srb75oB3pwmA@mail.gmail.com>
Message-ID: <CAPb8aJ7MdKWb_93DKz+R=zn7XL3cvxca1Ww5ArdUgRcJC=EW_Q@mail.gmail.com>

Vote: yes

Cheers,

-JB-

On Wed, Oct 30, 2019 at 1:43 PM Mario Torre <neugens at redhat.com> wrote:

> Hi all,
>
> I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to
> JDK 8 Update committer.
>
> Denghui has been contributing a large number of backports for the
> Flight Recorder incubator project and is one of the authors of the
> original backport patch.
>
> Some of the backports include:
>
> jdk8u-jfr-incubator:
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1
>     8229401: Fix JFR code cache test failures
>     8223689: Add JFR Thread Sampling Support
>     8223690: Add JFR BiasedLock Event Support
>     8223691: Add JFR G1 Region Type Change Event Support
>     8223692: Add JFR G1 Heap Summary Event Support
>
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41
>     backport 8232117: JFR: Old Object Sample event slow on a deep heap
> in debug builds
>     backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed:
> invariant
>     backport 8232800: Regression caused by JDK-8214542 not installing
> complete checkpoint data to candidates
>
>   http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing)
>     backport 8227605: Kitchensink fails "assert((((klass)->trace_id()
> & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed:
> invariant"
>
> 11u:
>   https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7
>     backport 8232096: RecordingInfo should use textual representation of
> path
>   http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing)
>     backport 8185525: Add JFR event for DictionarySizes
>
> 8u:
>  http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing)
>     backport 8144732: VM_HeapDumper hits assert with bad dump_len
>  http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing)
>     8232355: Two obsolete flags have the wrong obsolete version in 8u
>
> Votes are due by Nov 13th 19:00 CET.
>
> Only current JDK Committers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying to this
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> [1] https://openjdk.java.net/census#ddong
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] https://openjdk.java.net/census
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>

From jai.forums2013 at gmail.com  Sat Nov  2 12:17:43 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 2 Nov 2019 17:47:43 +0530
Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses
 CREATE_NEW when no options specified
In-Reply-To: <AM6PR02MB4801EA659FE3D65E7C8FD2068A610@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <b1e521af-798f-cfa0-ba06-a3594c274226@gmail.com>
 <AM6PR02MB4801EA659FE3D65E7C8FD2068A610@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <113b720c-a178-c230-d8c1-7672ba2c5619@gmail.com>

Thank you Christoph.

On 29/10/19 1:54 PM, Langer, Christoph wrote:
> Hi Jaikiran,
>
> the backport looks good to me. I can sponsor it, once we get the approval label.

I'm guessing, I don't have to do anything specific to request it and it
will be handled in due course?

-Jaikiran


From bourges.laurent at gmail.com  Sat Nov  2 12:43:41 2019
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 2 Nov 2019 13:43:41 +0100
Subject: Marlin renderer patches for jdk8u integration
Message-ID: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>

Dear all,

Here are the exact 21 patches backporting the Marlin renderer 0.9.1.3 to
jdk8u-dev:
- 19 patches (from zulu8) m01 to m19 from:
https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-zulu

See my patch script:
https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-zulu/doPatch.sh

- 2 new patches 8-m20 and 8-m21 from:
https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-jdk/jdk8-patches

See the 2nd patch script:
https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-jdk/doPatch.sh

I applied cleanly patches on jdk8u-dev, made a clean build and performance
is good: marlin renderer is enabled by default, instead of the Pisces
renderer: up to 4x times faster in my benchmarks.

See my simple build scripts:
https://github.com/bourgesl/marlin-jdk8u/blob/master/doGetOpenJDK8.sh
https://github.com/bourgesl/marlin-jdk8u/blob/master/doBuild.sh
Such linux x64 build is available (pure openjdk8u-dev oct 16th + patches)
for testing purposes:
https://github.com/bourgesl/marlin-jdk8u/releases/tag/v0.1

FYI I prepared this backport and my review based on the following bug list:
https://github.com/bourgesl/marlin-jdk8u/blob/master/README.md


Finally I am ready to work with any jdk8u reviewer on the formal review
process (jdk8u label, individual patch RFR...).
Let me know how to proceed. Who could help me on the reviews and run
validation tests...

Question: do you agree to enable the Marlin renderer by default in OpenJDK8
? or prefer staying with the former Pisces renderer ? It consists in a few
line change in the RenderingEngine class.

PS: I can copy all this material on cr.openjdk.java.net if necessary. Just
tell me.

Cheers,
Laurent

From christoph.langer at sap.com  Mon Nov  4 06:53:56 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 4 Nov 2019 06:53:56 +0000
Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses
 CREATE_NEW when no options specified
In-Reply-To: <113b720c-a178-c230-d8c1-7672ba2c5619@gmail.com>
References: <b1e521af-798f-cfa0-ba06-a3594c274226@gmail.com>
 <AM6PR02MB4801EA659FE3D65E7C8FD2068A610@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <113b720c-a178-c230-d8c1-7672ba2c5619@gmail.com>
Message-ID: <AM6PR02MB480105B6B69F355A458D43278A7F0@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Jaikiran,

> > the backport looks good to me. I can sponsor it, once we get the approval
> label.
> 
> I'm guessing, I don't have to do anything specific to request it and it
> will be handled in due course?

Yes, I would assume so.

Best regards
Christoph


From martijnverburg at gmail.com  Mon Nov  4 10:36:02 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 4 Nov 2019 10:36:02 +0000
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
Message-ID: <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>

Hi all,

We can apply these patches at AdoptOpenJDK and see if any of our test
pipelines raise an issue if that would help?  This probably also needs a
TCK check though.

Cheers,
Martijn


On Sat, 2 Nov 2019 at 12:44, Laurent Bourg?s <bourges.laurent at gmail.com>
wrote:

> Dear all,
>
> Here are the exact 21 patches backporting the Marlin renderer 0.9.1.3 to
> jdk8u-dev:
> - 19 patches (from zulu8) m01 to m19 from:
> https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-zulu
>
> See my patch script:
> https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-zulu/doPatch.sh
>
> - 2 new patches 8-m20 and 8-m21 from:
>
> https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-jdk/jdk8-patches
>
> See the 2nd patch script:
> https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-jdk/doPatch.sh
>
> I applied cleanly patches on jdk8u-dev, made a clean build and performance
> is good: marlin renderer is enabled by default, instead of the Pisces
> renderer: up to 4x times faster in my benchmarks.
>
> See my simple build scripts:
> https://github.com/bourgesl/marlin-jdk8u/blob/master/doGetOpenJDK8.sh
> https://github.com/bourgesl/marlin-jdk8u/blob/master/doBuild.sh
> Such linux x64 build is available (pure openjdk8u-dev oct 16th + patches)
> for testing purposes:
> https://github.com/bourgesl/marlin-jdk8u/releases/tag/v0.1
>
> FYI I prepared this backport and my review based on the following bug list:
> https://github.com/bourgesl/marlin-jdk8u/blob/master/README.md
>
>
> Finally I am ready to work with any jdk8u reviewer on the formal review
> process (jdk8u label, individual patch RFR...).
> Let me know how to proceed. Who could help me on the reviews and run
> validation tests...
>
> Question: do you agree to enable the Marlin renderer by default in OpenJDK8
> ? or prefer staying with the former Pisces renderer ? It consists in a few
> line change in the RenderingEngine class.
>
> PS: I can copy all this material on cr.openjdk.java.net if necessary. Just
> tell me.
>
> Cheers,
> Laurent
>

From shade at redhat.com  Mon Nov  4 18:19:38 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 4 Nov 2019 19:19:38 +0100
Subject: [8u] RFR (XS) 8231201: hs_err should print coalesced safepoint
 operations in Events section
Message-ID: <faf7d4b6-cd97-1e8b-529f-446c6815f658@redhat.com>

Original fix:
  https://bugs.openjdk.java.net/browse/JDK-8231201
  https://hg.openjdk.java.net/jdk/jdk/rev/4eebb9aadbe3

Patch does not apply to 8u cleanly, because context is a bit different. 8u webrev:
  https://cr.openjdk.java.net/~shade/8231201/webrev.8u.01/

Testing: build; eyeballing hs_errs

-- 
Thanks,
-Aleksey


From alvdavi at amazon.com  Mon Nov  4 18:21:16 2019
From: alvdavi at amazon.com (Alvarez, David)
Date: Mon, 4 Nov 2019 18:21:16 +0000
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
Message-ID: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>

Hi,

We will do a TCK run, including interactive tests on Windows. We'll see if we do it on other platforms. 

--
David

?On 2019-11-04, 02:36, "jdk8u-dev on behalf of Martijn Verburg" <jdk8u-dev-bounces at openjdk.java.net on behalf of martijnverburg at gmail.com> wrote:

    Hi all,
    
    We can apply these patches at AdoptOpenJDK and see if any of our test
    pipelines raise an issue if that would help?  This probably also needs a
    TCK check though.
    
    Cheers,
    Martijn
    
    
    On Sat, 2 Nov 2019 at 12:44, Laurent Bourg?s <bourges.laurent at gmail.com>
    wrote:
    
    > Dear all,
    >
    > Here are the exact 21 patches backporting the Marlin renderer 0.9.1.3 to
    > jdk8u-dev:
    > - 19 patches (from zulu8) m01 to m19 from:
    > https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-zulu
    >
    > See my patch script:
    > https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-zulu/doPatch.sh
    >
    > - 2 new patches 8-m20 and 8-m21 from:
    >
    > https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-jdk/jdk8-patches
    >
    > See the 2nd patch script:
    > https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-jdk/doPatch.sh
    >
    > I applied cleanly patches on jdk8u-dev, made a clean build and performance
    > is good: marlin renderer is enabled by default, instead of the Pisces
    > renderer: up to 4x times faster in my benchmarks.
    >
    > See my simple build scripts:
    > https://github.com/bourgesl/marlin-jdk8u/blob/master/doGetOpenJDK8.sh
    > https://github.com/bourgesl/marlin-jdk8u/blob/master/doBuild.sh
    > Such linux x64 build is available (pure openjdk8u-dev oct 16th + patches)
    > for testing purposes:
    > https://github.com/bourgesl/marlin-jdk8u/releases/tag/v0.1
    >
    > FYI I prepared this backport and my review based on the following bug list:
    > https://github.com/bourgesl/marlin-jdk8u/blob/master/README.md
    >
    >
    > Finally I am ready to work with any jdk8u reviewer on the formal review
    > process (jdk8u label, individual patch RFR...).
    > Let me know how to proceed. Who could help me on the reviews and run
    > validation tests...
    >
    > Question: do you agree to enable the Marlin renderer by default in OpenJDK8
    > ? or prefer staying with the former Pisces renderer ? It consists in a few
    > line change in the RenderingEngine class.
    >
    > PS: I can copy all this material on cr.openjdk.java.net if necessary. Just
    > tell me.
    >
    > Cheers,
    > Laurent
    >
    


From hohensee at amazon.com  Mon Nov  4 18:24:06 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 4 Nov 2019 18:24:06 +0000
Subject: [8u] RFR (XS) 8231201: hs_err should print coalesced safepoint
 operations in Events section
In-Reply-To: <faf7d4b6-cd97-1e8b-529f-446c6815f658@redhat.com>
References: <faf7d4b6-cd97-1e8b-529f-446c6815f658@redhat.com>
Message-ID: <C909279C-88C7-494C-9A90-4AD014729534@amazon.com>

Lgtm.

Paul

?On 11/4/19, 10:20 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:

    Original fix:
      https://bugs.openjdk.java.net/browse/JDK-8231201
      https://hg.openjdk.java.net/jdk/jdk/rev/4eebb9aadbe3
    
    Patch does not apply to 8u cleanly, because context is a bit different. 8u webrev:
      https://cr.openjdk.java.net/~shade/8231201/webrev.8u.01/
    
    Testing: build; eyeballing hs_errs
    
    -- 
    Thanks,
    -Aleksey
    
    


From mbalao at redhat.com  Mon Nov  4 18:41:12 2019
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 4 Nov 2019 15:41:12 -0300
Subject: [8u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806)
Message-ID: <e93ccd62-7d5d-ab09-b6e9-5651946f3368@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8215032 [1].

CSR for 8u requested here [2].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.jdk8u.jdk.webrev.00/

Changes from 11u patch [3]:

 * File paths

 * java.security changes need to be populated through the different
java.security-<OS> files

 * Copyright dates
  * KerberosPrincipal.java
  * Checksum.java
  * Config.java
  * KrbAsRep.java
  * KrbTgsRep.java
  * PAData.java
  * KrbTgsReq.java

 * Failing hooks because of the context (no actual code changes)
  * KrbAsReq.java
   * Manually added "import java.util.Arrays;"
  * EncKDCRepPart.java
   * 8u has "<xmp>" tags because 8132130 was not backported to 8u
   * Manually replaced the structure adding "encrypted-pa-data [12]
SEQUENCE OF PA-DATA OPTIONAL"
  * KDC.java
   * Indentation issues

 * KrbTgsReq.java
  * "Arrays" already imported (introduced in 6355584 and not removed
since then)

 * ReferralsTest.java
  * @library jtreg header removed

Testing:

 * No regressions found in sun/security/krb5

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8215032
[2] - https://bugs.openjdk.java.net/browse/JDK-8233512
[3] - http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/f2b580a5721c


From hohensee at amazon.com  Mon Nov  4 19:30:43 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 4 Nov 2019 19:30:43 +0000
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
 <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
Message-ID: <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>

Also, we (Amazon) would like the Marlin renderer enabled by default, just as it is for Zulu. It's been well-tested starting in 9, plus I doubt it'll get much, if any, use in u242 if we e.g. disable it for u242 and then enable it for u252.

Please put the patches on cr.openjdk.java.net so we can go through a normal review process.

Thanks,

Paul

?On 11/4/19, 10:24 AM, "jdk8u-dev on behalf of Alvarez, David" <jdk8u-dev-bounces at openjdk.java.net on behalf of alvdavi at amazon.com> wrote:

    Hi,
    
    We will do a TCK run, including interactive tests on Windows. We'll see if we do it on other platforms. 
    
    --
    David
    
    On 2019-11-04, 02:36, "jdk8u-dev on behalf of Martijn Verburg" <jdk8u-dev-bounces at openjdk.java.net on behalf of martijnverburg at gmail.com> wrote:
    
        Hi all,
        
        We can apply these patches at AdoptOpenJDK and see if any of our test
        pipelines raise an issue if that would help?  This probably also needs a
        TCK check though.
        
        Cheers,
        Martijn
        
        
        On Sat, 2 Nov 2019 at 12:44, Laurent Bourg?s <bourges.laurent at gmail.com>
        wrote:
        
        > Dear all,
        >
        > Here are the exact 21 patches backporting the Marlin renderer 0.9.1.3 to
        > jdk8u-dev:
        > - 19 patches (from zulu8) m01 to m19 from:
        > https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-zulu
        >
        > See my patch script:
        > https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-zulu/doPatch.sh
        >
        > - 2 new patches 8-m20 and 8-m21 from:
        >
        > https://github.com/bourgesl/marlin-jdk8u/tree/master/marlin-jdk/jdk8-patches
        >
        > See the 2nd patch script:
        > https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-jdk/doPatch.sh
        >
        > I applied cleanly patches on jdk8u-dev, made a clean build and performance
        > is good: marlin renderer is enabled by default, instead of the Pisces
        > renderer: up to 4x times faster in my benchmarks.
        >
        > See my simple build scripts:
        > https://github.com/bourgesl/marlin-jdk8u/blob/master/doGetOpenJDK8.sh
        > https://github.com/bourgesl/marlin-jdk8u/blob/master/doBuild.sh
        > Such linux x64 build is available (pure openjdk8u-dev oct 16th + patches)
        > for testing purposes:
        > https://github.com/bourgesl/marlin-jdk8u/releases/tag/v0.1
        >
        > FYI I prepared this backport and my review based on the following bug list:
        > https://github.com/bourgesl/marlin-jdk8u/blob/master/README.md
        >
        >
        > Finally I am ready to work with any jdk8u reviewer on the formal review
        > process (jdk8u label, individual patch RFR...).
        > Let me know how to proceed. Who could help me on the reviews and run
        > validation tests...
        >
        > Question: do you agree to enable the Marlin renderer by default in OpenJDK8
        > ? or prefer staying with the former Pisces renderer ? It consists in a few
        > line change in the RenderingEngine class.
        >
        > PS: I can copy all this material on cr.openjdk.java.net if necessary. Just
        > tell me.
        >
        > Cheers,
        > Laurent
        >
        
    
    


From gromero at linux.vnet.ibm.com  Mon Nov  4 22:32:39 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 4 Nov 2019 19:32:39 -0300
Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
 generic vector CRC implementation (v2)
In-Reply-To: <VI1PR0201MB247951F074AA4A598CBF8B8B9A6A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com>
 <VI1PR0201MB2479B9E369C33E4D46B8F9149A680@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com>
 <VI1PR0201MB247951F074AA4A598CBF8B8B9A6A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <b5e148b7-1493-24f2-ecf2-89ce72f6df38@linux.vnet.ibm.com>

Hello Martin,

On 10/24/2019 07:17 AM, Doerr, Martin wrote:
> Hi Gustavo,
> 
> I think removing invertCRC is an unnecessary manual change.
> We should minimize that as far as possible. They may create merge conflicts for future backports.

Thanks a lot for the review.

I agree I should minimize the changes as far as possible. I added back invertCRC
and tried to follow your advice, so the final clean-up patch is almost similar
to the one found on jdk/jdk, for instance.

Please find v2 for the patchset below. v2 changes affect only 3/4 and 4/4.


[PPC64] More generic vector CRC implementation                           (1/4)
http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8198894/

v2:
- Adapt file names to OpenJDK 8u
- Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no CRC32C
- Add Assembler::add_const_optimized() from "8077838: Recent developments for ppc" [0]
- Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by VPERMXOR_OPCODE,
   accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1]
- Adapt signatures for the following functions and their callers, accordingly to
   "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2]:
    a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC' parameter
    b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter


[PPC64] Possibly unreliable stack frame resizing in template interpreter (2/4)
http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216376/

v2:
- Adapt file names to OpenJDK 8u
- Remove CRC32C code


[PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays
http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216060/   (3/4)

v2:
- Remove CRC32C code, keeping is_crc32c in crc32(), code related to is_crc32c
   and invertCRC, like code in kernel_crc32_vpmsum(), and not touching stub code
   mark in generate_CRC32_updateBytes() to avoid merge conflicts in future
   backports.


[PPC64] Cleanup non-vector version of CRC32
http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8217459/   (4/4)

v2:
- Add {BIG,LITTLE}_ENDIAN_ONLY to src/share/vm/utilities/macros.hpp
- Add kernel_crc32_singleByteReg from change 8175369 [2] as the clean-up uses it
   in InterpreterGenerator::generate_CRC32_update_entry().


--

Best regards,
Gustavo

[0] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/88847a1b3718
[1] http://hg.openjdk.java.net/jdk/jdk/rev/5a69ba3a4fd1#l1.7
[2] https://bugs.openjdk.java.net/browse/JDK-8175369

From sakamoto.osamu at nttcom.co.jp  Tue Nov  5 09:50:42 2019
From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto)
Date: Tue, 05 Nov 2019 18:50:42 +0900
Subject: SEGV occurs when ClassLoader and Metaspace is released in JDK 8
Message-ID: <6651ebd1-8384-06d8-e788-9af825aeed3e@nttcom.co.jp_1>

Hi all,

I have investigated the cause of SEGV occurring in CMS GC of OpenJDK 8, 
and I've not been able to clarify the cause.
Could you help me to solve the problem?

Our system uses OpenJDK 1.8.0.171 and crashed by SEGV when purging a 
ClassLoader at safepoint.
I found 2 strange points,

1. SEGV occrred when the metaspace destructor maneged by that 
Classloader is executed,
 ?? because the metaspace has illegal chunk address(0x10).

2. That ClassLoader's oop address indicates a character array, not a 
ClassLoader.

I think memory corruption was occurred, but I've not understood the 
reason yet.

I also asked this problem to hotspot-gc-dev mailing list, and I received 
a comment that it might be a JDK bug.
Detailed Information is summarized in the following hotspot-gc-dev ML 
thread.
<https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-October/027583.html>

Does anyone know this problem?

Thanks,

Osamu





From thomas.stuefe at gmail.com  Tue Nov  5 10:34:19 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 5 Nov 2019 11:34:19 +0100
Subject: SEGV occurs when ClassLoader and Metaspace is released in JDK 8
In-Reply-To: <6651ebd1-8384-06d8-e788-9af825aeed3e@nttcom.co.jp_1>
References: <6651ebd1-8384-06d8-e788-9af825aeed3e@nttcom.co.jp_1>
Message-ID: <CAA-vtUwr0ndo6VkvBA9JdrfZDtXO0afMNVxY_XEmMTrZ4t5w5w@mail.gmail.com>

Hi Osamu,

Strange and not easy to analyze. Looks too "deterministic" to be a random
memory overwrite. The first chunk of the medium chunk list is 0x10, but the
only place where this is set we immediately beforehand dereference this
pointer (
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/b44df6c5942c/src/share/vm/memory/metaspace.cpp#l2423)
so that should have crashed.

Could be https://bugs.openjdk.java.net/browse/JDK-8016731 but that has
never been solved.

Your best bet would be to obtain a debug (fastdebug) build of that JVM
version and attempt to reproduce the bug. The hs-err file may be more
helpful then.

Also, does this error happen in jdk11 too?

Cheers Thomas


On Tue, Nov 5, 2019 at 10:51 AM Osamu Sakamoto <sakamoto.osamu at nttcom.co.jp>
wrote:

> Hi all,
>
> I have investigated the cause of SEGV occurring in CMS GC of OpenJDK 8,
> and I've not been able to clarify the cause.
> Could you help me to solve the problem?
>
> Our system uses OpenJDK 1.8.0.171 and crashed by SEGV when purging a
> ClassLoader at safepoint.
> I found 2 strange points,
>
> 1. SEGV occrred when the metaspace destructor maneged by that
> Classloader is executed,
>     because the metaspace has illegal chunk address(0x10).
>
> 2. That ClassLoader's oop address indicates a character array, not a
> ClassLoader.
>
> I think memory corruption was occurred, but I've not understood the
> reason yet.
>
> I also asked this problem to hotspot-gc-dev mailing list, and I received
> a comment that it might be a JDK bug.
> Detailed Information is summarized in the following hotspot-gc-dev ML
> thread.
> <
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-October/027583.html
> >
>
> Does anyone know this problem?
>
> Thanks,
>
> Osamu
>
>
>
>
>

From bourges.laurent at gmail.com  Tue Nov  5 10:40:29 2019
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 5 Nov 2019 11:40:29 +0100
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
 <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
 <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>
Message-ID: <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>

Hi Paul

Le lun. 4 nov. 2019 ? 20:30, Hohensee, Paul <hohensee at amazon.com> a ?crit :

> Also, we (Amazon) would like the Marlin renderer enabled by default, just
> as it is for Zulu. It's been well-tested starting in 9, plus I doubt it'll
> get much, if any, use in u242 if we e.g. disable it for u242 and then
> enable it for u252.
>
> Please put the patches on cr.openjdk.java.net so we can go through a
> normal review process.
>

I uploaded all patch files (m01 to m21):
http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/

Laurent

From rwestrel at redhat.com  Tue Nov  5 13:42:20 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 05 Nov 2019 14:42:20 +0100
Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() ||
 phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no
 mismatched stores, except on raw memory
In-Reply-To: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
Message-ID: <87tv7ie8xv.fsf@redhat.com>


Hi Severin,

Thanks for taking care of this.

> Could I please get a review of this 8u only issue? The reason a
> fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark
> of the renaissance suite is because the 8u backport of JDK-8140309 was
> missing this hunk from JDK 9[1]:
>
> +             (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode
> +             (is_mismatched_access() || st->as_Store()->is_mismatched_access()),
>
> I had a closer look and there doesn't seem to be missing anything else.
> The proposed fix is to amend the assert condition in the appropriate
> place, which brings 8u in line with JDK 9 code where the failure isn't
> observed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233023
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/

Isn't this:

@@ -3213,6 +3221,9 @@
 // within the initialized memory.
 intptr_t InitializeNode::can_capture_store(StoreNode* st, PhaseTransform* phase, bool can_reshape) {
   const int FAIL = 0;
+  if (st->is_unaligned_access()) {
+    return FAIL;
+  }
   if (st->req() != MemNode::ValueIn + 1)
     return FAIL;                // an inscrutable StoreNode (card mark?)
   Node* ctl = st->in(MemNode::Control);

also missing from the 8140309?

It must be armless because nothing sets _unaligned_access AFAICT but
given the unaligned access part of the patch was backported I think we
should keep it consistent.

Also, 

+             (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode

is not from 8140309 but from 8080289. We're not going to backport it and
that line is unrelated to the change so backporting it sounds good. But
while doing this, we should backport the other changes to that assert
from 8080289 as well.

+             st->Opcode() == Op_StoreVector ||
+             Opcode() == Op_StoreVector ||

Roland.

From mbalao at redhat.com  Tue Nov  5 18:46:50 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 5 Nov 2019 15:46:50 -0300
Subject: [8u - JFR] RFR 8233623: Add classpath exception to copyright in
 EventHandlerProxyCreator.java file
Message-ID: <b8f921b4-13cf-987f-9ed9-1c38dffe6217@redhat.com>

Hi,

Can I have a review for 8233623 [1]?

This is a copyright trivial change.

Webrev.00:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8233623/8233623.webrev.00/

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8233623


From neugens at redhat.com  Tue Nov  5 19:13:24 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 05 Nov 2019 20:13:24 +0100
Subject: [8u - JFR] RFR 8233623: Add classpath exception to copyright in
 EventHandlerProxyCreator.java file
In-Reply-To: <b8f921b4-13cf-987f-9ed9-1c38dffe6217@redhat.com>
References: <b8f921b4-13cf-987f-9ed9-1c38dffe6217@redhat.com>
Message-ID: <86f13c5914997ea1bf33fd435482f51cfb3f8030.camel@redhat.com>

On Tue, 2019-11-05 at 15:46 -0300, Martin Balao wrote:
> Hi,
> 
> Can I have a review for 8233623 [1]?
> 
> This is a copyright trivial change.
> 
> Webrev.00:
> 
>  * 
> http://cr.openjdk.java.net/~mbalao/webrevs/8233623/8233623.webrev.00/
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8233623
> 

Good to go, and thanks for the fix!

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From sgehwolf at redhat.com  Tue Nov  5 19:18:06 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 05 Nov 2019 20:18:06 +0100
Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() ||
 phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no
 mismatched stores, except on raw memory
In-Reply-To: <87tv7ie8xv.fsf@redhat.com>
References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
 <87tv7ie8xv.fsf@redhat.com>
Message-ID: <66e485457444840d563685516765e31304691932.camel@redhat.com>

Hi Roland,

On Tue, 2019-11-05 at 14:42 +0100, Roland Westrelin wrote:
> Hi Severin,
> 
> Thanks for taking care of this.

Thanks for the review!

> > Could I please get a review of this 8u only issue? The reason a
> > fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark
> > of the renaissance suite is because the 8u backport of JDK-8140309 was
> > missing this hunk from JDK 9[1]:
> > 
> > +             (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode
> > +             (is_mismatched_access() || st->as_Store()->is_mismatched_access()),
> > 
> > I had a closer look and there doesn't seem to be missing anything else.
> > The proposed fix is to amend the assert condition in the appropriate
> > place, which brings 8u in line with JDK 9 code where the failure isn't
> > observed.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8233023
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/
> 
> Isn't this:
> 
> @@ -3213,6 +3221,9 @@
>  // within the initialized memory.
>  intptr_t InitializeNode::can_capture_store(StoreNode* st, PhaseTransform* phase, bool can_reshape) {
>    const int FAIL = 0;
> +  if (st->is_unaligned_access()) {
> +    return FAIL;
> +  }
>    if (st->req() != MemNode::ValueIn + 1)
>      return FAIL;                // an inscrutable StoreNode (card mark?)
>    Node* ctl = st->in(MemNode::Control);
> 
> also missing from the 8140309?

It wasn't missing from the 8u backport of 8140309. See:
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0ffee573412b

It was removed later by JDK-8202414.

> It must be armless because nothing sets _unaligned_access AFAICT but
> given the unaligned access part of the patch was backported I think we
> should keep it consistent.
> 
> Also, 
> 
> +             (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode
> 
> is not from 8140309 but from 8080289.

Aah, good catch. I didn't mean to include part of 8080289. Updated
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/02/webrev/

> We're not going to backport it and
> that line is unrelated to the change so backporting it sounds good. But
> while doing this, we should backport the other changes to that assert
> from 8080289 as well.
> 
> +             st->Opcode() == Op_StoreVector ||
> +             Opcode() == Op_StoreVector ||

Right. I've opted for not including any parts of 8080289, so we should
be consistent.

Thoughts?

Thanks,
Severin


From mbalao at redhat.com  Tue Nov  5 19:20:32 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 5 Nov 2019 16:20:32 -0300
Subject: CFV: New JDK Committer: Denghui Dong
In-Reply-To: <CAJwKKmYcYruB8C5Xjykq1xeru-hMbiioLygAP=Srb75oB3pwmA@mail.gmail.com>
References: <CAJwKKmYcYruB8C5Xjykq1xeru-hMbiioLygAP=Srb75oB3pwmA@mail.gmail.com>
Message-ID: <11af8931-755b-53fe-73c0-142e5d6c3f02@redhat.com>

Vote: yes

On 10/30/19 9:41 AM, Mario Torre wrote:
> Hi all,
> 
> I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to
> JDK 8 Update committer.
> 
> Denghui has been contributing a large number of backports for the
> Flight Recorder incubator project and is one of the authors of the
> original backport patch.
> 
> Some of the backports include:
> 
> jdk8u-jfr-incubator:
>   http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309
>   http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1
>     8229401: Fix JFR code cache test failures
>     8223689: Add JFR Thread Sampling Support
>     8223690: Add JFR BiasedLock Event Support
>     8223691: Add JFR G1 Region Type Change Event Support
>     8223692: Add JFR G1 Heap Summary Event Support
> 
>   http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41
>     backport 8232117: JFR: Old Object Sample event slow on a deep heap
> in debug builds
>     backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant
>     backport 8232800: Regression caused by JDK-8214542 not installing
> complete checkpoint data to candidates
> 
>   http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing)
>     backport 8227605: Kitchensink fails "assert((((klass)->trace_id()
> & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed:
> invariant"
> 
> 11u:
>   https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7
>     backport 8232096: RecordingInfo should use textual representation of path
>   http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing)
>     backport 8185525: Add JFR event for DictionarySizes
> 
> 8u:
>  http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing)
>     backport 8144732: VM_HeapDumper hits assert with bad dump_len
>  http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing)
>     8232355: Two obsolete flags have the wrong obsolete version in 8u
> 
> Votes are due by Nov 13th 19:00 CET.
> 
> Only current JDK Committers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> [1] https://openjdk.java.net/census#ddong
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] https://openjdk.java.net/census
> 
> 


From mbalao at redhat.com  Tue Nov  5 19:26:55 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 5 Nov 2019 16:26:55 -0300
Subject: [8u - JFR] RFR 8233623: Add classpath exception to copyright in
 EventHandlerProxyCreator.java file
In-Reply-To: <86f13c5914997ea1bf33fd435482f51cfb3f8030.camel@redhat.com>
References: <b8f921b4-13cf-987f-9ed9-1c38dffe6217@redhat.com>
 <86f13c5914997ea1bf33fd435482f51cfb3f8030.camel@redhat.com>
Message-ID: <d2589726-41db-65c6-b602-151924fbf8c7@redhat.com>

Pushed:
https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/2cff6d7bd868

Thanks,
Martin.-

On 11/5/19 4:13 PM, Mario Torre wrote:
> On Tue, 2019-11-05 at 15:46 -0300, Martin Balao wrote:
>> Hi,
>>
>> Can I have a review for 8233623 [1]?
>>
>> This is a copyright trivial change.
>>
>> Webrev.00:
>>
>>  * 
>> http://cr.openjdk.java.net/~mbalao/webrevs/8233623/8233623.webrev.00/
>>
>> Thanks,
>> Martin.-
>>
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8233623
>>
> 
> Good to go, and thanks for the fix!
> 
> Cheers,
> Mario
> 


From rwestrel at redhat.com  Wed Nov  6 08:42:48 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 06 Nov 2019 09:42:48 +0100
Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() ||
 phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no
 mismatched stores, except on raw memory
In-Reply-To: <66e485457444840d563685516765e31304691932.camel@redhat.com>
References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
 <87tv7ie8xv.fsf@redhat.com>
 <66e485457444840d563685516765e31304691932.camel@redhat.com>
Message-ID: <87r22le6pj.fsf@redhat.com>


>> Isn't this:
>> 
>> @@ -3213,6 +3221,9 @@
>>  // within the initialized memory.
>>  intptr_t InitializeNode::can_capture_store(StoreNode* st, PhaseTransform* phase, bool can_reshape) {
>>    const int FAIL = 0;
>> +  if (st->is_unaligned_access()) {
>> +    return FAIL;
>> +  }
>>    if (st->req() != MemNode::ValueIn + 1)
>>      return FAIL;                // an inscrutable StoreNode (card mark?)
>>    Node* ctl = st->in(MemNode::Control);
>> 
>> also missing from the 8140309?
>
> It wasn't missing from the 8u backport of 8140309. See:
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0ffee573412b
>
> It was removed later by JDK-8202414.

Ok.

> Aah, good catch. I didn't mean to include part of 8080289. Updated
> webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/02/webrev/

Looks good to me.

Roland.

From sgehwolf at redhat.com  Wed Nov  6 09:28:19 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 06 Nov 2019 10:28:19 +0100
Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() ||
 phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no
 mismatched stores, except on raw memory
In-Reply-To: <87r22le6pj.fsf@redhat.com>
References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
 <87tv7ie8xv.fsf@redhat.com>
 <66e485457444840d563685516765e31304691932.camel@redhat.com>
 <87r22le6pj.fsf@redhat.com>
Message-ID: <2e6ec654637b3ceac2af2d7cf02c72398bda0d11.camel@redhat.com>

On Wed, 2019-11-06 at 09:42 +0100, Roland Westrelin wrote:
> > > Isn't this:
> > > 
> > > @@ -3213,6 +3221,9 @@
> > >  // within the initialized memory.
> > >  intptr_t InitializeNode::can_capture_store(StoreNode* st, PhaseTransform* phase, bool can_reshape) {
> > >    const int FAIL = 0;
> > > +  if (st->is_unaligned_access()) {
> > > +    return FAIL;
> > > +  }
> > >    if (st->req() != MemNode::ValueIn + 1)
> > >      return FAIL;                // an inscrutable StoreNode (card mark?)
> > >    Node* ctl = st->in(MemNode::Control);
> > > 
> > > also missing from the 8140309?
> > 
> > It wasn't missing from the 8u backport of 8140309. See:
> > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0ffee573412b
> > 
> > It was removed later by JDK-8202414.
> 
> Ok.
> 
> > Aah, good catch. I didn't mean to include part of 8080289. Updated
> > webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/02/webrev/
> 
> Looks good to me.

Thanks again for the review, Roland.

Cheers,
Severin


From sakamoto.osamu at nttcom.co.jp  Wed Nov  6 12:59:44 2019
From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto)
Date: Wed, 06 Nov 2019 21:59:44 +0900
Subject: SEGV occurs when ClassLoader and Metaspace is released in JDK 8
In-Reply-To: <CAA-vtUwr0ndo6VkvBA9JdrfZDtXO0afMNVxY_XEmMTrZ4t5w5w@mail.gmail.com>
References: <6651ebd1-8384-06d8-e788-9af825aeed3e@nttcom.co.jp_1>
 <CAA-vtUwr0ndo6VkvBA9JdrfZDtXO0afMNVxY_XEmMTrZ4t5w5w@mail.gmail.com>
Message-ID: <8d9094aa-4c77-0536-a587-11ad5e3bb114@nttcom.co.jp_1>

Hi Thomas,

Thank you for advise.
I'm sorry but I can't send to Gmail Address, So I reply to this ML only.

 > Could be https://bugs.openjdk.java.net/browse/JDK-8016731?but that 
has never been solved.
This situation is similar, but native stack traces are different and I 
can't determine if it is the same.

 > Your best bet would be to obtain a debug (fastdebug) build of that 
JVM version and attempt to reproduce the bug. The hs-err file may be 
more helpful then.
This problem occurred a few time, but I haven't understood how to reproduce.
I have the hs-err file, could you tell me what I should check?

 > Also, does this error happen in jdk11 too?
I haven't try on jdk11.
Our system is running, so it is difficult to try to change JDK version.

This problem seems to occurs on CMS only. (Our System uses CMS GC.)
I checked native stack trace[1], 
ClassLoaderDataGraph::purge_if_needed()[2] was executed on frame #11.
purge_if_needed() is commented that "Only purge the CLDG for CMS if 
concurrent sweep is complete.",
so I think this method passes only when CMS GC is used.

[1]https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-October/027449.html
[2]http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/eed8e846c982/src/share/vm/classfile/classLoaderData.hpp#l100

Focusing on this strange ClassLoader, it is referenced from 
ClassLoaderDataGraph::_unloading[3] before crashed.
I understand as ClassLoaderDataGraph::_unloading is head address of 
purging ClassLoader list.
In this problem, It looks like that _unloading is also broken, not only 
metaspace middle chank.
So, I think this is a bug in combination of Metaspace and CMS.
[3]http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/eed8e846c982/src/share/vm/classfile/classLoaderData.hpp#l66

Could you let me know you thoughts about this?

Thanks,

Osamu
On 11/5/19 19:34, Thomas St?fe wrote:
> Hi Osamu,
>
> Strange and not easy to analyze. Looks too "deterministic" to be a 
> random memory overwrite. The first chunk of the medium chunk list is 
> 0x10, but the only place where this is set we immediately beforehand 
> dereference this pointer 
> (http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/b44df6c5942c/src/share/vm/memory/metaspace.cpp#l2423) 
> so that should have crashed.
>
> Could be https://bugs.openjdk.java.net/browse/JDK-8016731?but that has 
> never been solved.
>
> Your best bet would be to obtain a debug (fastdebug) build of that JVM 
> version and attempt to reproduce the bug. The hs-err file may be more 
> helpful then.
>
> Also, does this error happen in jdk11 too?
>
> Cheers Thomas
>
>
> On Tue, Nov 5, 2019 at 10:51 AM Osamu Sakamoto 
> <sakamoto.osamu at nttcom.co.jp <mailto:sakamoto.osamu at nttcom.co.jp>> wrote:
>
>     Hi all,
>
>     I have investigated the cause of SEGV occurring in CMS GC of
>     OpenJDK 8,
>     and I've not been able to clarify the cause.
>     Could you help me to solve the problem?
>
>     Our system uses OpenJDK 1.8.0.171 and crashed by SEGV when purging a
>     ClassLoader at safepoint.
>     I found 2 strange points,
>
>     1. SEGV occrred when the metaspace destructor maneged by that
>     Classloader is executed,
>     ??? because the metaspace has illegal chunk address(0x10).
>
>     2. That ClassLoader's oop address indicates a character array, not a
>     ClassLoader.
>
>     I think memory corruption was occurred, but I've not understood the
>     reason yet.
>
>     I also asked this problem to hotspot-gc-dev mailing list, and I
>     received
>     a comment that it might be a JDK bug.
>     Detailed Information is summarized in the following hotspot-gc-dev ML
>     thread.
>     <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-October/027583.html>
>
>     Does anyone know this problem?
>
>     Thanks,
>
>     Osamu
>
>
>
>

From martin.doerr at sap.com  Wed Nov  6 15:15:30 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 6 Nov 2019 15:15:30 +0000
Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
 generic vector CRC implementation (v2)
In-Reply-To: <b5e148b7-1493-24f2-ecf2-89ce72f6df38@linux.vnet.ibm.com>
References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com>
 <VI1PR0201MB2479B9E369C33E4D46B8F9149A680@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com>
 <VI1PR0201MB247951F074AA4A598CBF8B8B9A6A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <b5e148b7-1493-24f2-ecf2-89ce72f6df38@linux.vnet.ibm.com>
Message-ID: <HE1PR0201MB24752CF818A0E90380EB7C7E9A790@HE1PR0201MB2475.eurprd02.prod.outlook.com>

Hi Gustavo,

> [PPC64] More generic vector CRC implementation                           (1/4)
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8198894/

This seems to be the version I had already reviewed. I'm still ok with it.


> [PPC64] Possibly unreliable stack frame resizing in template interpreter (2/4)
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216376/

Normally, backports should get handled in separate backport RFRs, but the manual change in this version could be considered trivial, so I don't insist on separate RFR.
Looks good, now.


> [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216060/   (3/4)

Almost like above. I'd leave at least the CRC32C defines in the code (stubRoutines_ppc). They don't disturb. Why should we introduce additional diffs?


> [PPC64] Cleanup non-vector version of CRC32
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8217459/   (4/4)

This one contains a part of another shared code change. So I can't review it as part of this RFR.
Needs to get reviewed separately. Backport of the original change which introduced LITTLE_ENDIAN_ONLY etc. should get evaluated.


Best regards,
Martin


> -----Original Message-----
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Montag, 4. November 2019 23:33
> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
> dev at openjdk.java.net
> Cc: jdk8u-dev at openjdk.java.net
> Subject: Re: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
> generic vector CRC implementation (v2)
> 
> Hello Martin,
> 
> On 10/24/2019 07:17 AM, Doerr, Martin wrote:
> > Hi Gustavo,
> >
> > I think removing invertCRC is an unnecessary manual change.
> > We should minimize that as far as possible. They may create merge
> conflicts for future backports.
> 
> Thanks a lot for the review.
> 
> I agree I should minimize the changes as far as possible. I added back
> invertCRC
> and tried to follow your advice, so the final clean-up patch is almost similar
> to the one found on jdk/jdk, for instance.
> 
> Please find v2 for the patchset below. v2 changes affect only 3/4 and 4/4.
> 
> 
> [PPC64] More generic vector CRC implementation                           (1/4)
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8198894/
> 
> v2:
> - Adapt file names to OpenJDK 8u
> - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no
> CRC32C
> - Add Assembler::add_const_optimized() from "8077838: Recent
> developments for ppc" [0]
> - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by
> VPERMXOR_OPCODE,
>    accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1]
> - Adapt signatures for the following functions and their callers, accordingly to
>    "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2]:
>     a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC'
> parameter
>     b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter
> 
> 
> [PPC64] Possibly unreliable stack frame resizing in template interpreter (2/4)
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216376/
> 
> v2:
> - Adapt file names to OpenJDK 8u
> - Remove CRC32C code
> 
> 
> [PPC64] Vector CRC implementation should be used by interpreter and be
> faster for short arrays
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216060/
> (3/4)
> 
> v2:
> - Remove CRC32C code, keeping is_crc32c in crc32(), code related to is_crc32c
>    and invertCRC, like code in kernel_crc32_vpmsum(), and not touching stub
> code
>    mark in generate_CRC32_updateBytes() to avoid merge conflicts in future
>    backports.
> 
> 
> [PPC64] Cleanup non-vector version of CRC32
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8217459/
> (4/4)
> 
> v2:
> - Add {BIG,LITTLE}_ENDIAN_ONLY to src/share/vm/utilities/macros.hpp
> - Add kernel_crc32_singleByteReg from change 8175369 [2] as the clean-up
> uses it
>    in InterpreterGenerator::generate_CRC32_update_entry().
> 
> 
> --
> 
> Best regards,
> Gustavo
> 
> [0] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/88847a1b3718
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/5a69ba3a4fd1#l1.7
> [2] https://bugs.openjdk.java.net/browse/JDK-8175369

From gnu.andrew at redhat.com  Wed Nov  6 16:51:47 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 6 Nov 2019 16:51:47 +0000
Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() ||
 phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no
 mismatched stores, except on raw memory
In-Reply-To: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
Message-ID: <dff209ce-4356-25f0-1b2b-dab8a5f16dd5@redhat.com>

On 30/10/2019 09:41, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this 8u only issue? The reason a
> fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark
> of the renaissance suite is because the 8u backport of JDK-8140309 was
> missing this hunk from JDK 9[1]:
> 
> +             (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode
> +             (is_mismatched_access() || st->as_Store()->is_mismatched_access()),
> 
> I had a closer look and there doesn't seem to be missing anything else.
> The proposed fix is to amend the assert condition in the appropriate
> place, which brings 8u in line with JDK 9 code where the failure isn't
> observed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233023
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/
> 
> Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new
> failures. dec-tree benchmark now runs successfully on an 8u fastdebug
> build.
> 
> Thoughts?
> 
> Thanks,
> Severin
> 
> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c
> 

I compared the two patches and this missing hunk does stand out. So the
patch looks fine in that respect.

I notice they also didn't backport the testcase to 8u. Any thoughts on
including that?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From mbalao at redhat.com  Wed Nov  6 18:39:39 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 6 Nov 2019 15:39:39 -0300
Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding
 secmod.db when NSS uses sqlite
Message-ID: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com>

Hi,

I'd like to propose the 8u backport of 8165996 [1]. This have been
proposed long time ago but I've now rebased the work and bumped the
webrev version to 02.

Webrev.02:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.02/

Differences with JDK baseline patch [2]:

 * TestNssDbSqlite.java
  * @modules jtreg header removed
  * Added a check to avoid errors when initialization fails (proposed by
@coffeys)
  * Removed white space in "initializeProvider" method signature

 * PKCS11Test.java
  * Change does not apply to 8u: no "distro" function in PKCS11Test
   * This was apparently introduced by 8133318 to solve issues in
Solaris SPARC 11.1 and earlier

Testing:

 * No regression found in sun/security/pkcs11

Note: a followup fix (8195607) will be proposed after this one.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8165996
[2] - http://hg.openjdk.java.net/jdk/jdk/rev/55b9b1e184c6


From iris.clark at oracle.com  Wed Nov  6 21:54:18 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 6 Nov 2019 13:54:18 -0800 (PST)
Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8
Message-ID: <d372f069-7ef0-4551-819e-56112e802ccb@default>

The TLS 1.3 protocol is rapidly gaining adoption on the Internet, and thus is
important even for legacy applications running on JDK 8.

Backporting TLS 1.3 to JDK 8 would not, of itself, require API changes, but
API changes are required in order to backport two technologies necessary for
TLS 1.3, ALPN [1] and RSASSA-PSS [2]:

  - The TLS ALPN (Application-Layer Protocol Negotiation) extension was added
    to Java SE 9 with JEP 244 (TLS Application-Layer Protocol Negotiation
    Extension (ALPN)) [3].  It allows negotiation of an application-layer
    protocol value during the TLS handshake which may be used during the
    selection of other TLS protocol parameters.  HTTP/2 [4] and other modern
    network protocols use ALPN. [5,6]

  - Support for the RSASSA-PSS (RSA Signature Scheme with Appendix --
    Probabilistic Signature Scheme) algorithm was added to Java SE 11.  It is
    a cryptographic signature scheme used for secure data transmission which
    was initially standardized as part of PKCS#1 v2.1 [7].  An API is
    necessary to enable third-party provider support. [8,9]

To enable efforts to backport TLS 1.3 to JDK 8, I'll shortly propose a
Maintenance Release of the Java SE 8 Platform JSR [0] in the JCP to backport
the ALPN and RSASSA-PSS APIs.  This will require updates to the Specification,
the Reference Implementation (RI), and the TCK, which I and my colleagues at
Oracle will provide.  I expect the Maintenance Release process to complete by
February 2020, in time for these changes to be merged into the April security
releases of JDK 8.

In order to reduce risk we'd like to base the open-source RI on OpenJDK 8u40
[10], the RI for the previous two Maintenance Releases, rather than the most
recent OpenJDK 8 update release.  We propose to name this "8u41," which is a
bit odd but does convey the special nature of any RI build: It's not meant for
production use, since it's never updated with security fixes.

If it's not too much work then we'll also contribute the changes required by
the MR to the next appropriate OpenJDK 8 release, most likely 8u252.  We do
not plan to contribute a backport TLS 1.3 to OpenJDK 8.

Comments?

Iris

[0]: https://openjdk.java.net/projects/jdk8/spec/
[1]: https://bugs.openjdk.java.net/browse/JDK-8230977
[2]: https://bugs.openjdk.java.net/browse/JDK-8230978
[3]: https://openjdk.java.net/jeps/244
[4]: https://tools.ietf.org/html/rfc7540
[5]: https://bugs.openjdk.java.net/browse/JDK-8144093
[6]: https://bugs.openjdk.java.net/browse/JDK-8170282
[7]: https://tools.ietf.org/html/rfc3447
[8]: https://bugs.openjdk.java.net/browse/JDK-8190180
[9]: https://bugs.openjdk.java.net/browse/JDK-8206864
[10]: https://hg.openjdk.java.net/jdk8u/jdk8u40

From hohensee at amazon.com  Wed Nov  6 23:07:24 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 6 Nov 2019 23:07:24 +0000
Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with
 bad dump_len
In-Reply-To: <260788c0-207d-8cfd-5492-8750d02e42d7@redhat.com>
References: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com>
 <260788c0-207d-8cfd-5492-8750d02e42d7@redhat.com>
Message-ID: <D69D6C36-F4E0-41C0-9D1E-72D616540F4B@amazon.com>

I found http://jperfanal.sourceforge.net/java.hprof.txt, which is a thread stack dump that references 1.0.1, is dated Dec 30, 2001, and the dump output is copyright 1998. So 1.0.1 is probably from 1998.

I found a file format spec at http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/tip/src/share/demo/jvmti/hprof/manual.html#mozTocId848088. It's from Java 6, so 1.0.2 was supported then. I also found

https://bugs.openjdk.java.net/browse/JDK-6305542: HPROF binary format needs to support large dumps

for Java 6, and

https://bugs.openjdk.java.net/browse/JDK-6313381: HPROF: agent should generate version 1.0.2 for large heaps

which updated the hprof agent to generate 1.0.2 format files for heaps > 4gb in Java 6, and

https://bugs.openjdk.java.net/browse/JDK-6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2"

which was shipped in 8u25 in 2014.

So, JDKs/JREs starting with Java 6 can read 1.0.2 files, and the SA can read them starting with 8u25. I don't think we need to worry about using Java 5 to read files generated by Java 8, and the SA is good to go for 8.

Paul

?On 10/31/19, 6:27 AM, "jdk8u-dev on behalf of Andrew John Hughes" <jdk8u-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    
    
    On 25/09/2019 07:25, Denghui Dong wrote:
    > Hi all, 
    >   I'd like to request a backport of JDK-8144732.
    > 
    >   In our production environment, many application use large heap, and there are some
    > big arrays in the heap. When developers use jmap to dump heap, and use Eclipse MAT(mostly) 
    > or jhat to analyze the file, often got error. For example:
    > 
    > public class BigArray {
    >   public static void main(String[] args) throws Exception {
    >     long[] b = new long[1024 * 1024 * 1024 / 2];
    >     Object o = new Object();
    >     synchronized(o) {
    >       o.wait(60000);
    >     }
    >   }
    > }
    > 
    >   If you run the above code, and use jmap to generate a dump file, then use jhat to parse it,
    > you will got a warning message:
    > 
    > "WARNING: Error reading heap dump or heap dump segment:  Byte count is -4294967296 instead of 0"
    > 
    >   Eclipse MAT also can't parse the dump file correctly.
    > 
    >   The root cause is the length of the segment exceeds the limit.
    > 
    >   I found that JDK-8144732 can resolve this problem, because it can truncate the array whose
    > size is too large and ensure a segment length within limit.
    > 
    > The patch (from JDK9) doesn't apply cleanly.
    > 
    > Original bug: https://bugs.openjdk.java.net/browse/JDK-8150432
    > 
    > Original patch: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a26000bfb5
    > 
    > My webrev: http://cr.openjdk.java.net/~luchsh/8144732_8u/
    > 
    > Testing:
    >   jdk/test/demo/jvmti/hprof/HeapDumpTest.java passed.
    >   jdk/test/sun/tools/jhat/HatHeapDump1Test.java passed.
    > 
    >   What's your comments ?
    > 
    > Thanks
    > Denghui Dong
    > 
    
    I'm concerned that this alters the HPROF format used for dumps under 2GB
    [0] Is there no other way of fixing the bug without altering this, which
    may have an impact on tools expecting to parse HPROF 1.0.1 format data.
    
    I guess HPROF 1.0.2 support was already required for larger dumps, so
    I'm not sure how much of an issue this is, but it's definitely a
    compatibility change.
    
    [0] https://bugs.openjdk.java.net/browse/JDK-8174881
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew
    
    


From hohensee at amazon.com  Wed Nov  6 23:10:26 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 6 Nov 2019 23:10:26 +0000
Subject: Pending fix requests
In-Reply-To: <E2D9FD34-94AA-4BD1-A38F-F1B850E86597@amazon.com>
References: <E2D9FD34-94AA-4BD1-A38F-F1B850E86597@amazon.com>
Message-ID: <5D41625C-0074-4C95-8C3D-F38813DEABCF@amazon.com>

Ping. :) The JBS issue list I'm watching includes

https://bugs.openjdk.java.net/browse/JDK-8048556: Unnecessary GCLocker-initiated young GCs
	Fixed in 8u241 and 11.0.6.
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010447.html
https://bugs.openjdk.java.net/browse/JDK-8068736: Avoid synchronization on Executable/Field.declaredAnnotations
https://bugs.openjdk.java.net/browse/JDK-8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts
	Fixed in 8u221 and 11.0.6.
https://bugs.openjdk.java.net/browse/JDK-8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug.
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010179.html
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010379.html
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010477.html
https://bugs.openjdk.java.net/browse/JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010418.html
	The 2d folks haven't replied, but the patch is seems good to me.
https://bugs.openjdk.java.net/browse/JDK-8216401: Allow "file:" URLs in Class-Path of local JARs
	Fixed in 8u231 and 11.0.5.
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010023.html
	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010220.html

Thanks,

Paul

?On 10/24/19, 11:54 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    Gentle request to 8u maintainers. :)
    
    There are a number of reviewed backports waiting for maintainer approval/disapproval (i.e., to be tagged with jdk8u-fix-yes/no), e.g., 8144732.
    
    Thanks,
    
    Paul
    
    
    


From gromero at linux.vnet.ibm.com  Thu Nov  7 00:53:32 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 6 Nov 2019 21:53:32 -0300
Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
 generic vector CRC implementation (v2)
In-Reply-To: <HE1PR0201MB24752CF818A0E90380EB7C7E9A790@HE1PR0201MB2475.eurprd02.prod.outlook.com>
References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com>
 <VI1PR0201MB2479B9E369C33E4D46B8F9149A680@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com>
 <VI1PR0201MB247951F074AA4A598CBF8B8B9A6A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <b5e148b7-1493-24f2-ecf2-89ce72f6df38@linux.vnet.ibm.com>
 <HE1PR0201MB24752CF818A0E90380EB7C7E9A790@HE1PR0201MB2475.eurprd02.prod.outlook.com>
Message-ID: <db56f7b6-af33-de6b-3ecf-86447e42f228@linux.vnet.ibm.com>

Hi Martin,

On 11/06/2019 12:15 PM, Doerr, Martin wrote:
> Hi Gustavo,
> 
>> [PPC64] More generic vector CRC implementation                           (1/4)
>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8198894/
> 
> This seems to be the version I had already reviewed. I'm still ok with it.

Yes, nothing changed. I posted it again for completeness, but I see now
it can cause confusing. I'll avoid doing it in the future.


>> [PPC64] Possibly unreliable stack frame resizing in template interpreter (2/4)
>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216376/
> 
> Normally, backports should get handled in separate backport RFRs, but the manual change in this version could be considered trivial, so I don't insist on separate RFR.
> Looks good, now.

I see, initially I posted the patches separately. I should have kept them
separated.


>> [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays
>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216060/   (3/4)
> 
> Almost like above. I'd leave at least the CRC32C defines in the code (stubRoutines_ppc). They don't disturb. Why should we introduce additional diffs?
Got it. I'll send a separate RFR.


>> [PPC64] Cleanup non-vector version of CRC32
>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8217459/   (4/4)
> 
> This one contains a part of another shared code change. So I can't review it as part of this RFR.
> Needs to get reviewed separately. Backport of the original change which introduced LITTLE_ENDIAN_ONLY etc. should get evaluated.

Good point, Martin. I overlooked the original change. It's a fix from Volker to
consider big-endian function descriptors when walking the stack:

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

Fix applies cleanly (except for the path adjustment). It's shared code but in
effect it's PPC64-only. I'll take care of backporting it separate.

And a nit in the test pointed out by Volker:

http://hg.openjdk.java.net/jdk/jdk/file/5bc2e9c9604d/test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java#l39

It should read "function descriptors" instead of "file descriptors", right?

I'll send a patch to jdk/jdk fixing that comment too.

Thank you!

Best regards,
Gustavo

From martin.doerr at sap.com  Thu Nov  7 09:03:50 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 7 Nov 2019 09:03:50 +0000
Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
 generic vector CRC implementation (v2)
In-Reply-To: <db56f7b6-af33-de6b-3ecf-86447e42f228@linux.vnet.ibm.com>
References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com>
 <VI1PR0201MB2479B9E369C33E4D46B8F9149A680@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com>
 <VI1PR0201MB247951F074AA4A598CBF8B8B9A6A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <b5e148b7-1493-24f2-ecf2-89ce72f6df38@linux.vnet.ibm.com>
 <HE1PR0201MB24752CF818A0E90380EB7C7E9A790@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <db56f7b6-af33-de6b-3ecf-86447e42f228@linux.vnet.ibm.com>
Message-ID: <VI1PR0201MB24793F06D0989FB829AC09579A780@VI1PR0201MB2479.eurprd02.prod.outlook.com>

Hi Gustavo,

> Good point, Martin. I overlooked the original change. It's a fix from Volker to
> consider big-endian function descriptors when walking the stack:
> 
> https://bugs.openjdk.java.net/browse/JDK-8206173
> 
> Fix applies cleanly (except for the path adjustment). It's shared code but in
> effect it's PPC64-only. I'll take care of backporting it separate.
> 
> And a nit in the test pointed out by Volker:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/5bc2e9c9604d/test/hotspot/jtreg/ru
> ntime/ElfDecoder/TestElfDirectRead.java#l39
> 
> It should read "function descriptors" instead of "file descriptors", right?

Comment fixes should not be done in backports. If you would like to fix it, it should get fixed in jdk/jdk and then backported.

Please backport as it is. You won't need a review if you don't change anything except the trivial path adaptations.

Best regards,
Martin


> -----Original Message-----
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Donnerstag, 7. November 2019 01:54
> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
> dev at openjdk.java.net
> Cc: jdk8u-dev at openjdk.java.net
> Subject: Re: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
> generic vector CRC implementation (v2)
> 
> Hi Martin,
> 
> On 11/06/2019 12:15 PM, Doerr, Martin wrote:
> > Hi Gustavo,
> >
> >> [PPC64] More generic vector CRC implementation                           (1/4)
> >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-
> review/v2/8198894/
> >
> > This seems to be the version I had already reviewed. I'm still ok with it.
> 
> Yes, nothing changed. I posted it again for completeness, but I see now
> it can cause confusing. I'll avoid doing it in the future.
> 
> 
> >> [PPC64] Possibly unreliable stack frame resizing in template interpreter
> (2/4)
> >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-
> review/v2/8216376/
> >
> > Normally, backports should get handled in separate backport RFRs, but the
> manual change in this version could be considered trivial, so I don't insist on
> separate RFR.
> > Looks good, now.
> 
> I see, initially I posted the patches separately. I should have kept them
> separated.
> 
> 
> >> [PPC64] Vector CRC implementation should be used by interpreter and be
> faster for short arrays
> >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-
> review/v2/8216060/   (3/4)
> >
> > Almost like above. I'd leave at least the CRC32C defines in the code
> (stubRoutines_ppc). They don't disturb. Why should we introduce additional
> diffs?
> Got it. I'll send a separate RFR.
> 
> 
> >> [PPC64] Cleanup non-vector version of CRC32
> >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-
> review/v2/8217459/   (4/4)
> >
> > This one contains a part of another shared code change. So I can't review it
> as part of this RFR.
> > Needs to get reviewed separately. Backport of the original change which
> introduced LITTLE_ENDIAN_ONLY etc. should get evaluated.
> 
> Good point, Martin. I overlooked the original change. It's a fix from Volker to
> consider big-endian function descriptors when walking the stack:
> 
> https://bugs.openjdk.java.net/browse/JDK-8206173
> 
> Fix applies cleanly (except for the path adjustment). It's shared code but in
> effect it's PPC64-only. I'll take care of backporting it separate.
> 
> And a nit in the test pointed out by Volker:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/5bc2e9c9604d/test/hotspot/jtreg/ru
> ntime/ElfDecoder/TestElfDirectRead.java#l39
> 
> It should read "function descriptors" instead of "file descriptors", right?
> 
> I'll send a patch to jdk/jdk fixing that comment too.
> 
> Thank you!
> 
> Best regards,
> Gustavo

From sgehwolf at redhat.com  Thu Nov  7 15:02:36 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 07 Nov 2019 16:02:36 +0100
Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() ||
 phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no
 mismatched stores, except on raw memory
In-Reply-To: <dff209ce-4356-25f0-1b2b-dab8a5f16dd5@redhat.com>
References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com>
 <dff209ce-4356-25f0-1b2b-dab8a5f16dd5@redhat.com>
Message-ID: <7aaffb34ba9af2e5508f423f7f3dddf75e5ea9cc.camel@redhat.com>

On Wed, 2019-11-06 at 16:51 +0000, Andrew John Hughes wrote:
> On 30/10/2019 09:41, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review of this 8u only issue? The reason a
> > fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark
> > of the renaissance suite is because the 8u backport of JDK-8140309 was
> > missing this hunk from JDK 9[1]:
> > 
> > +             (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode
> > +             (is_mismatched_access() || st->as_Store()->is_mismatched_access()),
> > 
> > I had a closer look and there doesn't seem to be missing anything else.
> > The proposed fix is to amend the assert condition in the appropriate
> > place, which brings 8u in line with JDK 9 code where the failure isn't
> > observed.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8233023
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/
> > 
> > Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new
> > failures. dec-tree benchmark now runs successfully on an 8u fastdebug
> > build.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c
> > 
> 
> I compared the two patches and this missing hunk does stand out. So the
> patch looks fine in that respect.

Thanks.

> I notice they also didn't backport the testcase to 8u. Any thoughts on
> including that?

The test uses Unsafe.putXXXUnaligned() which aren't available in JDK 8.
So I'm not sure how the test would work. More thoughts?

Thanks,
Severin


From gromero at linux.vnet.ibm.com  Thu Nov  7 18:36:46 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 7 Nov 2019 15:36:46 -0300
Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More
 generic vector CRC implementation (v2)
In-Reply-To: <VI1PR0201MB24793F06D0989FB829AC09579A780@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com>
 <VI1PR0201MB2479B9E369C33E4D46B8F9149A680@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com>
 <VI1PR0201MB247951F074AA4A598CBF8B8B9A6A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <b5e148b7-1493-24f2-ecf2-89ce72f6df38@linux.vnet.ibm.com>
 <HE1PR0201MB24752CF818A0E90380EB7C7E9A790@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <db56f7b6-af33-de6b-3ecf-86447e42f228@linux.vnet.ibm.com>
 <VI1PR0201MB24793F06D0989FB829AC09579A780@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <26fba4a1-0d53-bf0c-42cd-09c724bf833b@linux.vnet.ibm.com>

Hello Martin,

On 11/07/2019 06:03 AM, Doerr, Martin wrote:
> Hi Gustavo,
> 
>> Good point, Martin. I overlooked the original change. It's a fix from Volker to
>> consider big-endian function descriptors when walking the stack:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8206173
>>
>> Fix applies cleanly (except for the path adjustment). It's shared code but in
>> effect it's PPC64-only. I'll take care of backporting it separate.
>>
>> And a nit in the test pointed out by Volker:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/5bc2e9c9604d/test/hotspot/jtreg/ru
>> ntime/ElfDecoder/TestElfDirectRead.java#l39
>>
>> It should read "function descriptors" instead of "file descriptors", right?
> 
> Comment fixes should not be done in backports. If you would like to fix it, it should get fixed in jdk/jdk and then backported.

Yeah, that's what I meant (implicitly at least). I'm aware of that. I plan to
fix it only in jdk/jdk, also the test is not part of Volker's fix, anyway I
think that nit is not worth a backport.


> Please backport as it is. You won't need a review if you don't change anything except the trivial path adaptations.

Yeah, that's why I mentioned it applied cleanly, except for path adaptations :)


Thanks.

Best regards,
Gustavo

From alvdavi at amazon.com  Fri Nov  8 01:32:14 2019
From: alvdavi at amazon.com (David Alvarez)
Date: Thu, 7 Nov 2019 17:32:14 -0800
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
 <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
 <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>
 <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>
Message-ID: <2778b8a8-2178-4f41-49c0-80475423bb47@amazon.com>

Hi,

We?ve run the TCK with Marlin enabled, certification passes. So far so good.

Then, in some of our additional testing we noticed small differences in
the rendering of some components.

The simplest example we?ve been able to find is the java.awt.Choice in
Windows 10. When using a JDK with the patches applied, this component
will be rendered with one extra height pixel.

I've uploaded some images for comparison. Here[1] is how the component
is displayed using 8u232, and here[2], how it looks when using a version
of 8u232 that contains your patches. The difference is noticeable when
we put the components side by side[3], more so if we zoom in[4].

This can also cause a one-pixel overlap when these components are
rendered on a vertical box layout[5].

The behavior persisted even when changing the rendering engine back to
Pisces, so it seems it is caused by changes outside Marlin, most likely
on AAShapePipeline.

The new behavior is consistent with JDK11, but it still worries me a
little. Any idea why this is happening? If you want, I can provide you
with a sample program and compared images.

For reference, I've also updated the code used during the images[6]

--
David Alvarez

[1] http://cr.openjdk.java.net/~alvdavi/emails/marlin/vanilla.png
[2] http://cr.openjdk.java.net/~alvdavi/emails/marlin/marlin.png
[3] http://cr.openjdk.java.net/~alvdavi/emails/marlin/comparison.png
[4] http://cr.openjdk.java.net/~alvdavi/emails/marlin/detail.png
[5] http://cr.openjdk.java.net/~alvdavi/emails/marlin/multiple.png
[6] http://cr.openjdk.java.net/~alvdavi/emails/marlin/MarlinTest.java



On 2019-11-05 02:40, Laurent Bourg?s wrote:
> Hi Paul
> 
> Le?lun. 4 nov. 2019 ??20:30, Hohensee, Paul <hohensee at amazon.com
> <mailto:hohensee at amazon.com>> a ?crit?:
> 
>     Also, we (Amazon) would like the Marlin renderer enabled by default,
>     just as it is for Zulu. It's been well-tested starting in 9, plus I
>     doubt it'll get much, if any, use in u242 if we e.g. disable it for
>     u242 and then enable it for u252.
> 
>     Please put the patches on cr.openjdk.java.net
>     <http://cr.openjdk.java.net> so we can go through a normal review
>     process.
> 
> 
> I uploaded all patch files (m01 to m21):
> http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/
> 
> Laurent


From hohensee at amazon.com  Fri Nov  8 16:13:36 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 8 Nov 2019 16:13:36 +0000
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
 <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
 <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>
 <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>
Message-ID: <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com>

Thank you, Laurent.

Paul

From: Laurent Bourg?s <bourges.laurent at gmail.com>
Date: Tuesday, November 5, 2019 at 2:41 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "Alvarez, David" <alvdavi at amazon.com>, Martijn Verburg <martijnverburg at gmail.com>, jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: Marlin renderer patches for jdk8u integration

Hi Paul

Le lun. 4 nov. 2019 ? 20:30, Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> a ?crit :
Also, we (Amazon) would like the Marlin renderer enabled by default, just as it is for Zulu. It's been well-tested starting in 9, plus I doubt it'll get much, if any, use in u242 if we e.g. disable it for u242 and then enable it for u252.

Please put the patches on cr.openjdk.java.net<http://cr.openjdk.java.net> so we can go through a normal review process.

I uploaded all patch files (m01 to m21):
http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/

Laurent

From verghese at amazon.com  Fri Nov  8 19:38:43 2019
From: verghese at amazon.com (Verghese, Clive)
Date: Fri, 8 Nov 2019 19:38:43 +0000
Subject: [8u] RFR 8044500: [1/2] Add kinit options and krb5.conf flags that
 allow users to obtain renewable tickets and specify ticket lifetimes
Message-ID: <6C857F22-5223-45A5-8A3A-E184431B59A8@amazon.com>

Hi,

Requesting review for backport of JDK-8044500,

JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8044500
Original Change : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fb5752b152d9
Webrev : http://cr.openjdk.java.net/~alvdavi/webrevs/8044500/webrev.8u.00/

This is backport is a dependency for backporting JDK-8186576.

Parts of this backport have already been backported into JDK-8044500.
The patch did not apply cleanly and the major difference were

  *   Variable name changes in KDC.java
  *   Imports in Config.java

Both Tier1 and Tier2 tests in Linux x64.

Regards,
Clive Verghese


From verghese at amazon.com  Fri Nov  8 19:38:57 2019
From: verghese at amazon.com (Verghese, Clive)
Date: Fri, 8 Nov 2019 19:38:57 +0000
Subject: [8u] RFR: 8186576: [2/2] KerberosTicket does not properly handle
 renewable tickets at the end of their lifetime
Message-ID: <B715FA19-9424-42EE-AFCC-B65E92F19720@amazon.com>

Hi,

Requesting review for backport of JDK-8186576.

JDK-8186576
JBS Issues : https://bugs.openjdk.java.net/browse/JDK-8186576
Original Change : http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/fa7582840977
Webrev : http://cr.openjdk.java.net/~alvdavi/webrevs/8186576/webrev.8u.00/


The backport did not apply cleanly, It required changes from JDK-804450. The test case written for JDK-8186576, specifically NullRenewUntil, was requesting renewable tickets, support for which was added in JDK-8044500.
Additionally parts of JDK-8044500 had already been backported.

We could

  1.  Add the required functions and update the tests. Or
  2.  Backport JDK-8044500

I have backported both JDK-8044500 and JDK-8186576.

Other than the usual changes to filenames and copyrights, The patches also needed minor modifications mentioned below.

JDK-8186576

  *   Variable name change in KDC.java
  *   Missing ?{? in the if blocks in KerberosTicket.java


Regards,
Clive Verghese

From alvdavi at amazon.com  Fri Nov  8 21:24:43 2019
From: alvdavi at amazon.com (David Alvarez)
Date: Fri, 8 Nov 2019 13:24:43 -0800
Subject: [8u] RFR: [TESTBUG] Some ssl jtreg tests fail due to usage of a
 secp256k1 ECDSA certificate
Message-ID: <ef50ab00-c31a-54db-db46-6554b9160f7a@amazon.com>

Hi,

Requesting review for:

JBS: https://bugs.openjdk.java.net/browse/JDK-8233864
Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8233864/webrev.8u.00/

After 8u232, certain Tier2 jtreg ssl tests started to fail as they were
relying on a certificate based on curve secp256k1. That curve is no
longer enabled for ssl (disabled by JDK-8228825 [1]).

The specific certificate is located in:
test/sun/security/ssl/etc/keystore
and
test/sun/security/ssl/etc/truststore

This patch fixes those tests by recreating the certificate stores with
new certificates. The generated ECDSA certificate uses secp256r1. These
certificates are v3 instead of v1 as the originals, but we have seen no
failures caused by this.

This change includes binary changes. A patch file with binary changes is
located here:
http://cr.openjdk.java.net/~alvdavi/patches/8233864.8u.00.patch

Thanks,
--
David Alvarez

[1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5456f24496f4#l1.18


From akashche at redhat.com  Mon Nov 11 13:46:15 2019
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 11 Nov 2019 13:46:15 +0000
Subject: [8u] RFR: 8221246: NullPointerException within Win32ShellFolder2
Message-ID: <c95e17db-9add-b46a-127e-10f39a3a0739@redhat.com>

Hi,

Please review the backport of JDK-8221246 to 8u:

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

Original review thread: 
https://mail.openjdk.java.net/pipermail/awt-dev/2019-June/015273.html

11u changeset: 
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2f95ca679634

8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8221246/webrev.00/

Patch does not apply cleanly because of the differences in import 
section, all other code changes, besides imports, are left the same.

-- 
-Alex


From akashche at redhat.com  Mon Nov 11 13:46:34 2019
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 11 Nov 2019 13:46:34 +0000
Subject: [8u] RFR: 8225505: ctrl-F1 does not show the tooltip of a menu item
 (JMenuItems)
Message-ID: <39e57dc1-e12a-30ce-93fb-e1bc48ee6dea@redhat.com>

Hi,

Please review the backport of JDK-8225505 to 8u:

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

Original review thread: 
http://mail.openjdk.java.net/pipermail/swing-dev/2019-August/009737.html

11u changeset: 
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/4de4abef5634

8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8225505/webrev.00/

Patch does not apply cleanly because of the differences in import 
section (and a year in copyright header), all other code changes are 
left the same.

-- 
-Alex


From hohensee at amazon.com  Mon Nov 11 17:17:46 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 11 Nov 2019 17:17:46 +0000
Subject: [8u] RFR: 8225505: ctrl-F1 does not show the tooltip of a menu
 item (JMenuItems)
In-Reply-To: <39e57dc1-e12a-30ce-93fb-e1bc48ee6dea@redhat.com>
References: <39e57dc1-e12a-30ce-93fb-e1bc48ee6dea@redhat.com>
Message-ID: <AA8C78BB-129D-4B72-B609-60CE20846B84@amazon.com>

Looks fine.

Paul

?On 11/11/19, 5:47 AM, "jdk8u-dev on behalf of Alex Kashchenko" <jdk8u-dev-bounces at openjdk.java.net on behalf of akashche at redhat.com> wrote:

    Hi,
    
    Please review the backport of JDK-8225505 to 8u:
    
    Bug: https://bugs.openjdk.java.net/browse/JDK-8225505
    
    Original review thread: 
    http://mail.openjdk.java.net/pipermail/swing-dev/2019-August/009737.html
    
    11u changeset: 
    https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/4de4abef5634
    
    8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8225505/webrev.00/
    
    Patch does not apply cleanly because of the differences in import 
    section (and a year in copyright header), all other code changes are 
    left the same.
    
    -- 
    -Alex
    
    


From gnu.andrew at redhat.com  Mon Nov 11 17:28:35 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Nov 2019 17:28:35 +0000
Subject: [8u] 8218558: NMT stack traces in output should show mt component
 for virtual memory allocations
In-Reply-To: <e07d3943-12ef-7470-30ad-341e2e7f870f@redhat.com>
References: <e07d3943-12ef-7470-30ad-341e2e7f870f@redhat.com>
Message-ID: <a44f162b-adc9-9c45-7852-f5f010c33278@redhat.com>



On 22/08/2019 12:40, Zhengyu Gu wrote:
> Hi,
> 
> I would like to backport this patch to 8u.
> 
> It is the counterpart of JDK-8139673, that improves usability of NMT
> detail tracking, by associating every virtual memory allocation site
> with its memory type.
> 
> 11u patch does not apply cleanly, but conflicts are minors. There are a
> couple of conflicts with copyright years, also a new include file in 11u
> patch that already added in 8u, and indents.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8218558
> Original code review thread:
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032428.html
> 
> 
> 8u Webrev:
> http://cr.openjdk.java.net/~zgu/JDK-8218558-8u/webrev.00/index.html
> 
> 
> Thanks,
> 
> -Zhengyu

There is another conflict you didn't mention, visible when comparing the
two patches:

@@ -160,15 +152,20 @@

  void MemDetailDiffReporter::diff_malloc_site(const MallocSite* early,
    const MallocSite* current)  const {
--  assert(early->flags() == current->flags(), "Must be the same memory
type");
-+  assert(early->flag() == current->flag(), "Must be the same memory
type");
-   diff_malloc_site(current->call_stack(), current->size(),
current->count(),
--    early->size(), early->count(), early->flags());
-+    early->size(), early->count(), early->flag());
+-  if (early->flags() != current->flags()) {
++  if (early->flag() != current->flag()) {
+     // If malloc site type changed, treat it as deallocation of old
type and
+     // allocation of new type.
+     old_malloc_site(early);
+     new_malloc_site(current);
+   } else {
+     diff_malloc_site(current->call_stack(), current->size(),
current->count(),
+-      early->size(), early->count(), early->flags());
++      early->size(), early->count(), early->flag());
+   }
  }

- void MemDetailDiffReporter::diff_malloc_site(const NativeCallStack*
stack, size_t current_size,

This is a sequencing issue. 8u already has '8200109: NMT:
diff_malloc_site assert(early->flags() == current->flags(), "Must be the
same memory type")', which was applied after 8218558. Once both patches
are applied to 8u, the function looks the same in both 8u & 13u.

Reviewed & approved.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From akashche at redhat.com  Mon Nov 11 20:58:52 2019
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 11 Nov 2019 20:58:52 +0000
Subject: [8u] RFR: 8225505: ctrl-F1 does not show the tooltip of a menu
 item (JMenuItems)
In-Reply-To: <AA8C78BB-129D-4B72-B609-60CE20846B84@amazon.com>
References: <39e57dc1-e12a-30ce-93fb-e1bc48ee6dea@redhat.com>
 <AA8C78BB-129D-4B72-B609-60CE20846B84@amazon.com>
Message-ID: <e7846f18-9dea-96db-4da2-bfd5d38edfd6@redhat.com>

On 11/11/2019 05:17 PM, Hohensee, Paul wrote:
> Looks fine.

Thanks for the review! I added 8u fix request for this issue.

> 
> Paul
> 
> ?On 11/11/19, 5:47 AM, "jdk8u-dev on behalf of Alex Kashchenko" <jdk8u-dev-bounces at openjdk.java.net on behalf of akashche at redhat.com> wrote:
> 
>      Hi,
>      
>      Please review the backport of JDK-8225505 to 8u:
>      
>      Bug: https://bugs.openjdk.java.net/browse/JDK-8225505
>      
>      Original review thread:
>      http://mail.openjdk.java.net/pipermail/swing-dev/2019-August/009737.html
>      
>      11u changeset:
>      https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/4de4abef5634
>      
>      8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8225505/webrev.00/
>      
>      Patch does not apply cleanly because of the differences in import
>      section (and a year in copyright header), all other code changes are
>      left the same.
>      
>      --
>      -Alex
>      
>      
> 


-- 
-Alex


From zgu at redhat.com  Mon Nov 11 21:12:18 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 11 Nov 2019 16:12:18 -0500
Subject: [8u] 8218558: NMT stack traces in output should show mt component
 for virtual memory allocations
In-Reply-To: <a44f162b-adc9-9c45-7852-f5f010c33278@redhat.com>
References: <e07d3943-12ef-7470-30ad-341e2e7f870f@redhat.com>
 <a44f162b-adc9-9c45-7852-f5f010c33278@redhat.com>
Message-ID: <15ad77f3-94da-58c1-ee42-8856812a2736@redhat.com>

Hi Andrew,

On 11/11/19 12:28 PM, Andrew John Hughes wrote:
> 
> 
> On 22/08/2019 12:40, Zhengyu Gu wrote:
>> Hi,
>>
>> I would like to backport this patch to 8u.
>>
>> It is the counterpart of JDK-8139673, that improves usability of NMT
>> detail tracking, by associating every virtual memory allocation site
>> with its memory type.
>>
>> 11u patch does not apply cleanly, but conflicts are minors. There are a
>> couple of conflicts with copyright years, also a new include file in 11u
>> patch that already added in 8u, and indents.
>>
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8218558
>> Original code review thread:
>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032428.html
>>
>>
>> 8u Webrev:
>> http://cr.openjdk.java.net/~zgu/JDK-8218558-8u/webrev.00/index.html
>>
>>
>> Thanks,
>>
>> -Zhengyu
> 
> There is another conflict you didn't mention, visible when comparing the
> two patches:
> 
>
As I mentioned above, this patch was not brought down from 13, but from 
11u (https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/adb14d5b965e).

I cannot remember the exact reason, probably because the conflicts 
already resolved there.

Thanks,

-Zhengyu


  @@ -160,15 +152,20 @@
> 
>    void MemDetailDiffReporter::diff_malloc_site(const MallocSite* early,
>      const MallocSite* current)  const {
> --  assert(early->flags() == current->flags(), "Must be the same memory
> type");
> -+  assert(early->flag() == current->flag(), "Must be the same memory
> type");
> -   diff_malloc_site(current->call_stack(), current->size(),
> current->count(),
> --    early->size(), early->count(), early->flags());
> -+    early->size(), early->count(), early->flag());
> +-  if (early->flags() != current->flags()) {
> ++  if (early->flag() != current->flag()) {
> +     // If malloc site type changed, treat it as deallocation of old
> type and
> +     // allocation of new type.
> +     old_malloc_site(early);
> +     new_malloc_site(current);
> +   } else {
> +     diff_malloc_site(current->call_stack(), current->size(),
> current->count(),
> +-      early->size(), early->count(), early->flags());
> ++      early->size(), early->count(), early->flag());
> +   }
>    }
> 
> - void MemDetailDiffReporter::diff_malloc_site(const NativeCallStack*
> stack, size_t current_size,
> 
> This is a sequencing issue. 8u already has '8200109: NMT:
> diff_malloc_site assert(early->flags() == current->flags(), "Must be the
> same memory type")', which was applied after 8218558. Once both patches
> are applied to 8u, the function looks the same in both 8u & 13u.
> 
> Reviewed & approved.
> 
> Thanks,
> 


From christoph.langer at sap.com  Tue Nov 12 13:01:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Nov 2019 13:01:23 +0000
Subject: RFR: 8233995: java.vm.vendor (and potentially other
 properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8
Message-ID: <AM6PR02MB48014BBA1F11354453D3F5208A770@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi,

please review and approve the following change that affects Windows builds of OpenJDK 8. It is an OpenJDK8 specific fix. In later JDKs, the build system was completely changed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8233995
Webrev (for hotspot): http://cr.openjdk.java.net/~clanger/webrevs/8233995.8u.0/

The problem is that for Windows builds the System property java.vm.vendor is empty. It doesn't matter whether the configure option --with-vendor-name is used or not. The problem is that the variables from configure don't get passed correctly to the hotspot build.

I fixed this by passing the needed variables in make/windows/makefiles/defs.make via MAKE_ARGS. Furthermore, in make/windows/makefiles/vm.make, the defines VENDOR, VENDOR_URL, VENDOR_URL_BUG and VENDOR_URL_VM_BUG for the C/C++ compilations will only be set if the variables have a value. This is because otherwise those would override expected default values from inside the hotspot code. With that change, the Windows build will behave more like the Unix/Linux builds do already.

BTW, the problem can be observed in the current AdoptOpenJDK builds. Amazon Corretto seems to have a workaround for this problem (a hard coded vendor string in the makefile).

Thanks
Christoph


From christoph.langer at sap.com  Tue Nov 12 13:44:17 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Nov 2019 13:44:17 +0000
Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses
 CREATE_NEW when no options specified
In-Reply-To: <113b720c-a178-c230-d8c1-7672ba2c5619@gmail.com>
References: <b1e521af-798f-cfa0-ba06-a3594c274226@gmail.com>
 <AM6PR02MB4801EA659FE3D65E7C8FD2068A610@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <113b720c-a178-c230-d8c1-7672ba2c5619@gmail.com>
Message-ID: <AM6PR02MB480161B433E6421A48F12BBC8A770@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Jaikiran,

I have updated the backport: http://cr.openjdk.java.net/~clanger/webrevs/8034773.8u.0/.

I restored the original copyright header changes and the author/reviewer attributions which conforms to what's usually done in backports. Once we have approval, this is what I'll push.
 
Cheers
Christoph

> -----Original Message-----
> From: Jaikiran Pai <jai.forums2013 at gmail.com>
> Sent: Samstag, 2. November 2019 13:18
> To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
> dev at openjdk.java.net
> Subject: Re: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses
> CREATE_NEW when no options specified
> 
> Thank you Christoph.
> 
> On 29/10/19 1:54 PM, Langer, Christoph wrote:
> > Hi Jaikiran,
> >
> > the backport looks good to me. I can sponsor it, once we get the approval
> label.
> 
> I'm guessing, I don't have to do anything specific to request it and it
> will be handled in due course?
> 
> -Jaikiran


From gnu.andrew at redhat.com  Wed Nov 13 19:33:13 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 13 Nov 2019 19:33:13 +0000
Subject: RFR: 8233995: java.vm.vendor (and potentially other
 properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8
In-Reply-To: <AM6PR02MB48014BBA1F11354453D3F5208A770@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <AM6PR02MB48014BBA1F11354453D3F5208A770@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <82775c10-59ed-4471-0ab3-99e995c00e11@redhat.com>



On 12/11/2019 13:01, Langer, Christoph wrote:
> Hi,
> 
> please review and approve the following change that affects Windows builds of OpenJDK 8. It is an OpenJDK8 specific fix. In later JDKs, the build system was completely changed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233995
> Webrev (for hotspot): http://cr.openjdk.java.net/~clanger/webrevs/8233995.8u.0/
> 
> The problem is that for Windows builds the System property java.vm.vendor is empty. It doesn't matter whether the configure option --with-vendor-name is used or not. The problem is that the variables from configure don't get passed correctly to the hotspot build.
> 
> I fixed this by passing the needed variables in make/windows/makefiles/defs.make via MAKE_ARGS. Furthermore, in make/windows/makefiles/vm.make, the defines VENDOR, VENDOR_URL, VENDOR_URL_BUG and VENDOR_URL_VM_BUG for the C/C++ compilations will only be set if the variables have a value. This is because otherwise those would override expected default values from inside the hotspot code. With that change, the Windows build will behave more like the Unix/Linux builds do already.
> 
> BTW, the problem can be observed in the current AdoptOpenJDK builds. Amazon Corretto seems to have a workaround for this problem (a hard coded vendor string in the makefile).
> 
> Thanks
> Christoph
> 

Indeed, the build system did change in OpenJDK 9 with "JDK-8150601:
Remove the old Hotspot build system". As JDK-8189761: COMPANY_NAME,
IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag" occurred
later than this, the HotSpot parts of the 8189761 had to be constructed
from scratch when I backported it. Not having access to Windows myself,
I'm reliant on others to test the changes there and report breakage.

Looking over this patch, and comparing with what we do for
AIX/Solaris/BSD/Linux in 8189761, I have two questions:

1. We echo the values of VENDOR, VENDOR_URL, VENDOR_URL_BUG and
VENDOR_URL_VM_BUG to local.make in build.make, in much the same way as
buildtree.make does for the other platforms. Any idea why that is not
sufficient and these need to be also added to defs.make? If the
build.make variables aren't being set, that has an impact for other
variables too. I notice ZIPEXE is in both places, with no checks in the
defs.make case:

hotspot/make/windows/build.make:        @ if "$(ZIPEXE)" NEQ "" echo
ZIPEXE=$(ZIPEXE)           >> $@
hotspot/make/windows/makefiles/defs.make:MAKE_ARGS += ZIPEXE=$(ZIPEXE)

If possible, it would be better to fix the underlying issue rather than
papering over it.

2. The checks added in vm.make are done by configure for the other
builds and assembled into VERSION_CFLAGS. To avoid duplication  in
vm.make, is it possible to just use VERSION_CFLAGS there as the other
systems do? If Windows can't handle the -D syntax that uses, maybe a
better solution is to setup VERSION_WINFLAGS in the same place with the
correct syntax?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From christoph.langer at sap.com  Wed Nov 13 22:39:30 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Nov 2019 22:39:30 +0000
Subject: RFR: 8233995: java.vm.vendor (and potentially other
 properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8
In-Reply-To: <82775c10-59ed-4471-0ab3-99e995c00e11@redhat.com>
References: <AM6PR02MB48014BBA1F11354453D3F5208A770@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <82775c10-59ed-4471-0ab3-99e995c00e11@redhat.com>
Message-ID: <AM6PR02MB48013C99B07ACFF47D74C82D8A760@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Andrew,

thanks for looking into my webrev.

> Indeed, the build system did change in OpenJDK 9 with "JDK-8150601:
> Remove the old Hotspot build system". As JDK-8189761: COMPANY_NAME,
> IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag" occurred
> later than this, the HotSpot parts of the 8189761 had to be constructed
> from scratch when I backported it. Not having access to Windows myself,
> I'm reliant on others to test the changes there and report breakage.

Ah, I didn't do that bug-archeology. Good to know.

> Looking over this patch, and comparing with what we do for
> AIX/Solaris/BSD/Linux in 8189761, I have two questions:
> 
> 1. We echo the values of VENDOR, VENDOR_URL, VENDOR_URL_BUG and
> VENDOR_URL_VM_BUG to local.make in build.make, in much the same way
> as
> buildtree.make does for the other platforms. Any idea why that is not
> sufficient and these need to be also added to defs.make? If the
> build.make variables aren't being set, that has an impact for other
> variables too. I notice ZIPEXE is in both places, with no checks in the
> defs.make case:
> 
> hotspot/make/windows/build.make:        @ if "$(ZIPEXE)" NEQ "" echo
> ZIPEXE=$(ZIPEXE)           >> $@
> hotspot/make/windows/makefiles/defs.make:MAKE_ARGS +=
> ZIPEXE=$(ZIPEXE)
> 
> If possible, it would be better to fix the underlying issue rather than
> papering over it.

Well, for Unix-ish builds, "make buildtree.make ..." gets called (e.g. from hotspot/make/linux/Makefile) and buildtree.mak includes spec.gmk and hence has access to all values.
For Windows, however, we hand over to nmake. "nmake build.make ..." gets called from hotspot/make/Makefile and build.make does not include spec.gmk - it probably can't since nmake/gnumake have different syntax. Hence, the only way to pass arguments to build.make is via MAKE_ARGS in defs.make.

I don't see an easy fix here...

The handling of ZIPEXE seems correct, too.

> 2. The checks added in vm.make are done by configure for the other
> builds and assembled into VERSION_CFLAGS. To avoid duplication  in
> vm.make, is it possible to just use VERSION_CFLAGS there as the other
> systems do? If Windows can't handle the -D syntax that uses, maybe a
> better solution is to setup VERSION_WINFLAGS in the same place with the
> correct syntax?

Hm, maybe we can try to pass VERSION_CFLAGS via MAKE_ARGS and use it in vm.make. I'll give it a try. Stay tuned...

Best regards
Christoph


From bradford.wetmore at oracle.com  Thu Nov 14 02:05:02 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 13 Nov 2019 18:05:02 -0800
Subject: RFR[8u41]: MR 3 - ALPN & RSASSA-PSS in Java SE 8
Message-ID: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>

Xuelei/Valerie (+ any other codereviewers),

As announced on jdk8u-dev[1], there is a Maintenance Release in progress 
for Java SE 8 (i.e. JSR 337) [2] to include two security features 
important for TLS 1.3:

1.  Application-Layer Protocol Negotiation (ALPN) [3][4]
2.  RSA Signature Scheme with Appendix: Probabilistic Signature Scheme 
(RSASSA-PSS) [5][6]

The Enhancement and CSR IDs are footnoted above/below.

To ensure compatibility across the active Java releases, we are 
backporting the APIs introduced in Java SE 9 and 11 respectively to Java 
SE 8.

This email is a Request For Review (RFR) of the two major pieces for 
this MR:

1.  ALPN:
     http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/ALPN

2.  RSASSA-PSS:
     http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/PSS

This includes the updates to the Specification and Reference 
Implementation (RI), which will be called JDK 8u41 [7].

Almost all of these changes are direct copies of the changesets applied 
in JDK 9+.

In addition to these features:

1.  The file ADDITIONAL_LICENSE_INFO was added, which is identical to 
the same file in later releases.

2.  Truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added 
to the SUN Provider to support the corresponding truncated RSASSA-PSS 
Signatures.

Thanks,

Brad

[1] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html
[2] https://www.jcp.org/en/jsr/detail?id=337
[3] https://bugs.openjdk.java.net/browse/JDK-8230977
[4] https://bugs.openjdk.java.net/browse/JDK-8233417
[5] https://bugs.openjdk.java.net/browse/JDK-8230978
[6] https://bugs.openjdk.java.net/browse/JDK-8233418
[7] http://hg.openjdk.java.net/jdk8u/jdk8u41/

From xuelei.fan at oracle.com  Thu Nov 14 03:24:04 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Nov 2019 19:24:04 -0800
Subject: RFR[8u41]: MR 3 - ALPN & RSASSA-PSS in Java SE 8
In-Reply-To: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
References: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
Message-ID: <0bebb0e4-84f3-e49e-7a08-4ab46e7ac1b2@oracle.com>

Hi Brad,

I would review the ALPN part only, which looks good to me.

Thanks,
Xuelei

On 11/13/2019 6:05 PM, Bradford Wetmore wrote:
> Xuelei/Valerie (+ any other codereviewers),
> 
> As announced on jdk8u-dev[1], there is a Maintenance Release in progress 
> for Java SE 8 (i.e. JSR 337) [2] to include two security features 
> important for TLS 1.3:
> 
> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4]
> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme 
> (RSASSA-PSS) [5][6]
> 
> The Enhancement and CSR IDs are footnoted above/below.
> 
> To ensure compatibility across the active Java releases, we are 
> backporting the APIs introduced in Java SE 9 and 11 respectively to Java 
> SE 8.
> 
> This email is a Request For Review (RFR) of the two major pieces for 
> this MR:
> 
> 1.? ALPN:
>  ??? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/ALPN
> 
> 2.? RSASSA-PSS:
>  ??? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/PSS
> 
> This includes the updates to the Specification and Reference 
> Implementation (RI), which will be called JDK 8u41 [7].
> 
> Almost all of these changes are direct copies of the changesets applied 
> in JDK 9+.
> 
> In addition to these features:
> 
> 1.? The file ADDITIONAL_LICENSE_INFO was added, which is identical to 
> the same file in later releases.
> 
> 2.? Truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added 
> to the SUN Provider to support the corresponding truncated RSASSA-PSS 
> Signatures.
> 
> Thanks,
> 
> Brad
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html
> [2] https://www.jcp.org/en/jsr/detail?id=337
> [3] https://bugs.openjdk.java.net/browse/JDK-8230977
> [4] https://bugs.openjdk.java.net/browse/JDK-8233417
> [5] https://bugs.openjdk.java.net/browse/JDK-8230978
> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/

From jai.forums2013 at gmail.com  Thu Nov 14 08:41:13 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 14 Nov 2019 14:11:13 +0530
Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses
 CREATE_NEW when no options specified
In-Reply-To: <AM6PR02MB480161B433E6421A48F12BBC8A770@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <b1e521af-798f-cfa0-ba06-a3594c274226@gmail.com>
 <AM6PR02MB4801EA659FE3D65E7C8FD2068A610@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <113b720c-a178-c230-d8c1-7672ba2c5619@gmail.com>
 <AM6PR02MB480161B433E6421A48F12BBC8A770@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <d67355ce-a823-4c92-ae1b-c0f9fdb1630e@gmail.com>

Hello Christoph,

On 12/11/19 7:14 PM, Langer, Christoph wrote:
> Hi Jaikiran,
>
> I have updated the backport: http://cr.openjdk.java.net/~clanger/webrevs/8034773.8u.0/.
>
> I restored the original copyright header changes and the author/reviewer attributions which conforms to what's usually done in backports. Once we have approval, this is what I'll push.

Thank you for doing that. I'll keep this in mind for any future backports.

-Jaikiran


From neugens at redhat.com  Thu Nov 14 11:12:24 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 14 Nov 2019 12:12:24 +0100
Subject: Result: New JDK8u Committer:
Message-ID: <da1ec86c163b829568d830e721a786c13e80c1c2.camel@redhat.com>

Voting for Denghui Dong [1] is now closed.

Yes: 11
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Thanks,
Mario Torre

[1] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010523.html

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From bourges.laurent at gmail.com  Thu Nov 14 12:54:18 2019
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 14 Nov 2019 13:54:18 +0100
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <2778b8a8-2178-4f41-49c0-80475423bb47@amazon.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
 <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
 <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>
 <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>
 <2778b8a8-2178-4f41-49c0-80475423bb47@amazon.com>
Message-ID: <CAKjRUT4w7UJFEGLLOtO6nSL0vXOG5Sn6=XSQP4fGw6bU_NiG0Q@mail.gmail.com>

Hi David,

Thanks for testing the Marlin renderer patches, it looks quite good.

Sorry for my late response, I expected to test myself on a windows machine,
but still not.

I wonder why the 1px difference on windows awt widgets has not been yet
reported.
Phil or Sergey, are you aware of such issue ? How are awt widgets rendered
? How can the java2d renderer interfere in such way ?
Is it related to fractional scaling factors ?

I will try using awt/2d debug settings to get more details...

Laurent

Le ven. 8 nov. 2019 ? 02:32, David Alvarez <alvdavi at amazon.com> a ?crit :

> Hi,
>
> We?ve run the TCK with Marlin enabled, certification passes. So far so
> good.
>
> Then, in some of our additional testing we noticed small differences in
> the rendering of some components.
>
> The simplest example we?ve been able to find is the java.awt.Choice in
> Windows 10. When using a JDK with the patches applied, this component
> will be rendered with one extra height pixel.
>
> I've uploaded some images for comparison. Here[1] is how the component
> is displayed using 8u232, and here[2], how it looks when using a version
> of 8u232 that contains your patches. The difference is noticeable when
> we put the components side by side[3], more so if we zoom in[4].
>
> This can also cause a one-pixel overlap when these components are
> rendered on a vertical box layout[5].
>
> The behavior persisted even when changing the rendering engine back to
> Pisces, so it seems it is caused by changes outside Marlin, most likely
> on AAShapePipeline.
>
> The new behavior is consistent with JDK11, but it still worries me a
> little. Any idea why this is happening? If you want, I can provide you
> with a sample program and compared images.
>
> For reference, I've also updated the code used during the images[6]
>
> --
> David Alvarez
>
> [1] http://cr.openjdk.java.net/~alvdavi/emails/marlin/vanilla.png
> [2] http://cr.openjdk.java.net/~alvdavi/emails/marlin/marlin.png
> [3] http://cr.openjdk.java.net/~alvdavi/emails/marlin/comparison.png
> [4] http://cr.openjdk.java.net/~alvdavi/emails/marlin/detail.png
> [5] http://cr.openjdk.java.net/~alvdavi/emails/marlin/multiple.png
> [6] http://cr.openjdk.java.net/~alvdavi/emails/marlin/MarlinTest.java
>
>
>
> On 2019-11-05 02:40, Laurent Bourg?s wrote:
> > Hi Paul
> >
> > Le lun. 4 nov. 2019 ? 20:30, Hohensee, Paul <hohensee at amazon.com
> > <mailto:hohensee at amazon.com>> a ?crit :
> >
> >     Also, we (Amazon) would like the Marlin renderer enabled by default,
> >     just as it is for Zulu. It's been well-tested starting in 9, plus I
> >     doubt it'll get much, if any, use in u242 if we e.g. disable it for
> >     u242 and then enable it for u252.
> >
> >     Please put the patches on cr.openjdk.java.net
> >     <http://cr.openjdk.java.net> so we can go through a normal review
> >     process.
> >
> >
> > I uploaded all patch files (m01 to m21):
> > http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/
> >
> > Laurent
>
>

From felix.yang at huawei.com  Fri Nov 15 03:14:11 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 15 Nov 2019 03:14:11 +0000
Subject: [8u] RFR 8182397: Race in field updates when creating ArrayKlasses
 can lead to crash
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED60373CE@dggeml527-mbx.china.huawei.com>

Hi,

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8182397
  http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/e4434fd96f08

Original patch does not apply cleanly to 8u due to line differences and code refactoring.

8u webrev:
  http://cr.openjdk.java.net/~fyang/8182397-8u-backport/webrev.00/

This updated Copyright years for all files changed.
Also removed one line from the newly added testcase in the original patch: @modules java.base/jdk.internal.misc

Testing: Run full jtreg test with a x86-64 release build.
    Newly add test case fail without the patch and pass with the patch.

Thanks,
Felix

From felix.yang at huawei.com  Fri Nov 15 07:04:32 2019
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 15 Nov 2019 07:04:32 +0000
Subject: [8u] RFR: fix inconsistency of backport of 8219677:
 "-XX:OnOutOfMemoryError" uses fork instead of vfork
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>

Hi,

  We found one inconsistency of backport of 8219677.
  The upstream patch set parameter use_vfork_if_available to true when call os::fork_and_exec in VM_ReportJavaOutOfMemory::doit().
  But looks like the 8u backport did something inconsistent: the change was not made in the correct place.
  The 8u backport patch: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/97d605522fcb

Patch for jdk8u-dev:

diff -r 775e2bf92114 src/share/vm/utilities/vmError.cpp
--- a/src/share/vm/utilities/vmError.cpp        Wed Aug 07 17:00:19 2019 +0800
+++ b/src/share/vm/utilities/vmError.cpp        Fri Nov 15 14:23:50 2019 +0800
@@ -1060,7 +1060,7 @@
       out.print_raw   (cmd);
       out.print_raw_cr("\" ...");

-      if (os::fork_and_exec(cmd, true) < 0) {
+      if (os::fork_and_exec(cmd) < 0) {
         out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
       }
     }
@@ -1147,7 +1147,7 @@
#endif
     tty->print_cr("\"%s\"...", cmd);

-    if (os::fork_and_exec(cmd) < 0) {
+    if (os::fork_and_exec(cmd, true) < 0) {
       tty->print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
     }
   }

Please confirm.

Thanks,
Felix

From Nikola.Grcevski at microsoft.com  Fri Nov 15 14:35:26 2019
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Fri, 15 Nov 2019 14:35:26 +0000
Subject: JDK-8221605 fix backport candidate (dup of JDK-8146792)
Message-ID: <BL0PR2101MB100906047F339B8F4E7E97EFF5700@BL0PR2101MB1009.namprd21.prod.outlook.com>

Hello jdk8u-dev,

I'm a VM engineer at Microsoft and new to this mailing list. After reproducing the error in "JDK-8221605: C2 crashed at PhaseIdealLoop::build_loop_late_post" (https://bugs.openjdk.java.net/browse/JDK-8221605) I was able to identify the root cause as a missing backport of a fix made in JDK9. The fix for the problem can be found in the following JDK9 revision: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f and it's covered by the bug report https://bugs.openjdk.java.net/browse/JDK-8146792 . I found that this backport has already been discussed under the following thread, but it was never finally committed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009947.html .

>From the original bug report in JDK-8221605, I was able to reduce the failing testcase to the following very simple program (which is very similar to the failing testcase as described by Felix Yang):

/**
* @summary Predicate moved after partial peel may lead to broken graph
 * @run main/othervm -XX:-TieredCompilation -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:CompileOnly=BadGraphAfterPeelAndPredicateTransform::m1 -XX:CompileCommand=quiet BadGraphAfterPeelAndPredicateTransform
*/
public class BadGraphAfterPeelAndPredicateTransform {
    public static final int SIZE = 40;
    public static final int RUN_TO_COMPILE = 200;

    private void m1() {
        /**
         * The arrays need to be allocated here to reproduce the problem
         * because we can prove the lengths for bound checks
         */
        int arr[] = new int[SIZE], arr2[][] = new int[SIZE][SIZE];

        /**
          * The loop induction variable needs to be float, double or long, so that we fail detection as a counted loop
        */
        for (float f = 0; f < SIZE; ++f) {
            arr[(int)(f)] = 1;
            for (int j = 0; j < 1; ++j) {
                arr = arr2[j];
            }
        }
    }

    public static void main(String[] args) {
        BadGraphAfterPeelAndPredicateTransform instance = new BadGraphAfterPeelAndPredicateTransform();
       
        for (int i = 0; i < RUN_TO_COMPILE; i++ ) {
            instance.m1();
        }
    }
}

After investigation into the root cause of the issue and I can confirm that the webrev (http://cr.openjdk.java.net/~fyang/8146792-backport/webrev.00/) as submitted by Felix Yang in the email thread above is the correct patch for JDK8, as the second change in src/share/vm/opto/loopPredicate.cpp (@@ -641,6 +665,7 @@) from the original JDK9 fix is already there in JDK8. I did some debugging to understand the issue better and I have made the following conclusions:

- The problem only happens if we perform loop peeling. In the testcase above (or in the one described by Felix in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009947.html) if one changes the loop variable to be of type int, the problem never happens because the loop is identified as a counted loop and peeling is never attempted.
- The original testcase supplied with the JDK9 fix in revision http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f never fails on JDK8 because peeling is never attempted on that testcase in JDK8.
- The root of the problem is related to computing invariance of certain nodes. Namely, when the test fails, a conditional's invariance is already computed on a given node (coming from the IdealLoopTree to Invariance class constructor) and then the loop is peeled. After peeling the computed invariance remains set on the node, however the set computed invariance may not hold true after loop peeling is performed. The fix in JDK9 prevents the loop predicate optimization on all nodes that might be pinned between the peeled predicates and the loop entry which prevents the invalid movement of a predicate. As an experiment, I forcibly re-computed the invariance on the predicate (in my case it was a null check) ahead of performing loop predication and this resolved the problem too, as the node was deemed as non loop invariant after freshly recomputing the invariance. The experiment is not a feasible fix, it was done only to prove the hypothesis.

Can we please backport the fix to JDK8 and perhaps make bug report JDK-8221605 a duplicate of JDK-8146792? While it's somewhat uncommon for a programmer to use an induction variable other than an int in a loop, it seems that if they choose to do so the problem occurs anytime the loop is peeled. Based on the original JDK9 bug report, this can occur with loops that use an int as an induction variable if the loop isn't deemed as counted. 

I also think it would be good to add these additional tests that use non-int loop induction variables as tests in all releases. I would really like to help with making these additional tests on top of the backport.

I would also like to perform some further performance testing on the change in JDK8 to ensure the fix doesn't cause performance regressions. Does anyone have any suggested benchmarks that might be a good choice for verifying the impact of this change in loop optimizations?

Cheers,
-Nikola

From hohensee at amazon.com  Fri Nov 15 16:33:06 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 15 Nov 2019 16:33:06 +0000
Subject: [8u] RFR: fix inconsistency of backport of 8219677:
 "-XX:OnOutOfMemoryError" uses fork instead of vfork
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>
Message-ID: <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com>

You are correct. I'll file an issue to fix it.

Thanks,

Paul

?On 11/14/19, 11:05 PM, "jdk8u-dev on behalf of Yangfei (Felix)" <jdk8u-dev-bounces at openjdk.java.net on behalf of felix.yang at huawei.com> wrote:

    Hi,
    
      We found one inconsistency of backport of 8219677.
      The upstream patch set parameter use_vfork_if_available to true when call os::fork_and_exec in VM_ReportJavaOutOfMemory::doit().
      But looks like the 8u backport did something inconsistent: the change was not made in the correct place.
      The 8u backport patch: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/97d605522fcb
    
    Patch for jdk8u-dev:
    
    diff -r 775e2bf92114 src/share/vm/utilities/vmError.cpp
    --- a/src/share/vm/utilities/vmError.cpp        Wed Aug 07 17:00:19 2019 +0800
    +++ b/src/share/vm/utilities/vmError.cpp        Fri Nov 15 14:23:50 2019 +0800
    @@ -1060,7 +1060,7 @@
           out.print_raw   (cmd);
           out.print_raw_cr("\" ...");
    
    -      if (os::fork_and_exec(cmd, true) < 0) {
    +      if (os::fork_and_exec(cmd) < 0) {
             out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
           }
         }
    @@ -1147,7 +1147,7 @@
    #endif
         tty->print_cr("\"%s\"...", cmd);
    
    -    if (os::fork_and_exec(cmd) < 0) {
    +    if (os::fork_and_exec(cmd, true) < 0) {
           tty->print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
         }
       }
    
    Please confirm.
    
    Thanks,
    Felix
    


From hohensee at amazon.com  Fri Nov 15 16:47:59 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 15 Nov 2019 16:47:59 +0000
Subject: [8u] RFR: fix inconsistency of backport of 8219677:
 "-XX:OnOutOfMemoryError" uses fork instead of vfork
In-Reply-To: <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>
 <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com>
Message-ID: <F50A3F95-A5EF-4372-86C6-9D6D35092F10@amazon.com>

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

?On 11/15/19, 8:33 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    You are correct. I'll file an issue to fix it.
    
    Thanks,
    
    Paul
    
    On 11/14/19, 11:05 PM, "jdk8u-dev on behalf of Yangfei (Felix)" <jdk8u-dev-bounces at openjdk.java.net on behalf of felix.yang at huawei.com> wrote:
    
        Hi,
        
          We found one inconsistency of backport of 8219677.
          The upstream patch set parameter use_vfork_if_available to true when call os::fork_and_exec in VM_ReportJavaOutOfMemory::doit().
          But looks like the 8u backport did something inconsistent: the change was not made in the correct place.
          The 8u backport patch: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/97d605522fcb
        
        Patch for jdk8u-dev:
        
        diff -r 775e2bf92114 src/share/vm/utilities/vmError.cpp
        --- a/src/share/vm/utilities/vmError.cpp        Wed Aug 07 17:00:19 2019 +0800
        +++ b/src/share/vm/utilities/vmError.cpp        Fri Nov 15 14:23:50 2019 +0800
        @@ -1060,7 +1060,7 @@
               out.print_raw   (cmd);
               out.print_raw_cr("\" ...");
        
        -      if (os::fork_and_exec(cmd, true) < 0) {
        +      if (os::fork_and_exec(cmd) < 0) {
                 out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
               }
             }
        @@ -1147,7 +1147,7 @@
        #endif
             tty->print_cr("\"%s\"...", cmd);
        
        -    if (os::fork_and_exec(cmd) < 0) {
        +    if (os::fork_and_exec(cmd, true) < 0) {
               tty->print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
             }
           }
        
        Please confirm.
        
        Thanks,
        Felix
        
    
    


From hohensee at amazon.com  Fri Nov 15 20:08:24 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 15 Nov 2019 20:08:24 +0000
Subject: [8u] RFR: fix inconsistency of backport of 8219677:
 "-XX:OnOutOfMemoryError" uses fork instead of vfork
In-Reply-To: <F50A3F95-A5EF-4372-86C6-9D6D35092F10@amazon.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>
 <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com>
 <F50A3F95-A5EF-4372-86C6-9D6D35092F10@amazon.com>
Message-ID: <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com>

May I have another review please?

Webrev: http://cr.openjdk.java.net/~phh/8234264/webrev.8u.00/

Thanks,

Paul

?On 11/15/19, 8:49 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    https://bugs.openjdk.java.net/browse/JDK-8234264
    
    On 11/15/19, 8:33 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:
    
        You are correct. I'll file an issue to fix it.
        
        Thanks,
        
        Paul
        
        On 11/14/19, 11:05 PM, "jdk8u-dev on behalf of Yangfei (Felix)" <jdk8u-dev-bounces at openjdk.java.net on behalf of felix.yang at huawei.com> wrote:
        
            Hi,
            
              We found one inconsistency of backport of 8219677.
              The upstream patch set parameter use_vfork_if_available to true when call os::fork_and_exec in VM_ReportJavaOutOfMemory::doit().
              But looks like the 8u backport did something inconsistent: the change was not made in the correct place.
              The 8u backport patch: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/97d605522fcb
            
            Patch for jdk8u-dev:
            
            diff -r 775e2bf92114 src/share/vm/utilities/vmError.cpp
            --- a/src/share/vm/utilities/vmError.cpp        Wed Aug 07 17:00:19 2019 +0800
            +++ b/src/share/vm/utilities/vmError.cpp        Fri Nov 15 14:23:50 2019 +0800
            @@ -1060,7 +1060,7 @@
                   out.print_raw   (cmd);
                   out.print_raw_cr("\" ...");
            
            -      if (os::fork_and_exec(cmd, true) < 0) {
            +      if (os::fork_and_exec(cmd) < 0) {
                     out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
                   }
                 }
            @@ -1147,7 +1147,7 @@
            #endif
                 tty->print_cr("\"%s\"...", cmd);
            
            -    if (os::fork_and_exec(cmd) < 0) {
            +    if (os::fork_and_exec(cmd, true) < 0) {
                   tty->print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
                 }
               }
            
            Please confirm.
            
            Thanks,
            Felix
            
        
        
    
    


From volker.simonis at gmail.com  Sun Nov 17 12:41:44 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sun, 17 Nov 2019 13:41:44 +0100
Subject: [8u] RFR: fix inconsistency of backport of 8219677:
 "-XX:OnOutOfMemoryError" uses fork instead of vfork
In-Reply-To: <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>
 <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com>
 <F50A3F95-A5EF-4372-86C6-9D6D35092F10@amazon.com>
 <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com>
Message-ID: <CA+3eh11Y1kyX=sx8Mp2vT1iOma3FYkYi7hLDwFsUuBtS-rOMhw@mail.gmail.com>

Hohensee, Paul <hohensee at amazon.com> schrieb am Fr., 15. Nov. 2019, 21:09:

> May I have another review please?
>
> Webrev: http://cr.openjdk.java.net/~phh/8234264/webrev.8u.00/
>
>
The fix is trivial and the change looks good. Thumbs up from me.

As a side note, I don't understand why the call to fork_and_exec() in void
VMError::report_and_die (which was wrongly patched by the downport) hasn't
been lifted by the initial change 8047434 to use vfork() as well? But
that's a question not relevant for this fix of the downport and should
probably be addressed in the head revision.

Best regards,
Volker

Thanks,
>
> Paul
>
> ?On 11/15/19, 8:49 AM, "jdk8u-dev on behalf of Hohensee, Paul" <
> jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com>
> wrote:
>
>     https://bugs.openjdk.java.net/browse/JDK-8234264
>
>     On 11/15/19, 8:33 AM, "jdk8u-dev on behalf of Hohensee, Paul" <
> jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com>
> wrote:
>
>         You are correct. I'll file an issue to fix it.
>
>         Thanks,
>
>         Paul
>
>         On 11/14/19, 11:05 PM, "jdk8u-dev on behalf of Yangfei (Felix)" <
> jdk8u-dev-bounces at openjdk.java.net on behalf of felix.yang at huawei.com>
> wrote:
>
>             Hi,
>
>               We found one inconsistency of backport of 8219677.
>               The upstream patch set parameter use_vfork_if_available to
> true when call os::fork_and_exec in VM_ReportJavaOutOfMemory::doit().
>               But looks like the 8u backport did something inconsistent:
> the change was not made in the correct place.
>               The 8u backport patch:
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/97d605522fcb
>
>             Patch for jdk8u-dev:
>
>             diff -r 775e2bf92114 src/share/vm/utilities/vmError.cpp
>             --- a/src/share/vm/utilities/vmError.cpp        Wed Aug 07
> 17:00:19 2019 +0800
>             +++ b/src/share/vm/utilities/vmError.cpp        Fri Nov 15
> 14:23:50 2019 +0800
>             @@ -1060,7 +1060,7 @@
>                    out.print_raw   (cmd);
>                    out.print_raw_cr("\" ...");
>
>             -      if (os::fork_and_exec(cmd, true) < 0) {
>             +      if (os::fork_and_exec(cmd) < 0) {
>                      out.print_cr("os::fork_and_exec failed: %s (%d)",
> strerror(errno), errno);
>                    }
>                  }
>             @@ -1147,7 +1147,7 @@
>             #endif
>                  tty->print_cr("\"%s\"...", cmd);
>
>             -    if (os::fork_and_exec(cmd) < 0) {
>             +    if (os::fork_and_exec(cmd, true) < 0) {
>                    tty->print_cr("os::fork_and_exec failed: %s (%d)",
> strerror(errno), errno);
>                  }
>                }
>
>             Please confirm.
>
>             Thanks,
>             Felix
>
>
>
>
>
>
>

From hohensee at amazon.com  Mon Nov 18 15:35:49 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 18 Nov 2019 15:35:49 +0000
Subject: [8u] RFR: fix inconsistency of backport of 8219677:
 "-XX:OnOutOfMemoryError" uses fork instead of vfork
In-Reply-To: <CA+3eh11Y1kyX=sx8Mp2vT1iOma3FYkYi7hLDwFsUuBtS-rOMhw@mail.gmail.com>
References: <DA41BE1DDCA941489001C7FBD7A8820ED603741B@dggeml527-mbx.china.huawei.com>
 <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com>
 <F50A3F95-A5EF-4372-86C6-9D6D35092F10@amazon.com>
 <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com>
 <CA+3eh11Y1kyX=sx8Mp2vT1iOma3FYkYi7hLDwFsUuBtS-rOMhw@mail.gmail.com>
Message-ID: <0FA73510-22C1-420E-B10F-B24EE9BAC308@amazon.com>

Thanks for the review, Volker.

Paul

From: Volker Simonis <volker.simonis at gmail.com>
Date: Sunday, November 17, 2019 at 4:43 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "Yangfei (Felix)" <felix.yang at huawei.com>, jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR: fix inconsistency of backport of 8219677: "-XX:OnOutOfMemoryError" uses fork instead of vfork

Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> schrieb am Fr., 15. Nov. 2019, 21:09:
May I have another review please?

Webrev: http://cr.openjdk.java.net/~phh/8234264/webrev.8u.00/

The fix is trivial and the change looks good. Thumbs up from me.

As a side note, I don't understand why the call to fork_and_exec() in void VMError::report_and_die (which was wrongly patched by the downport) hasn't been lifted by the initial change 8047434 to use vfork() as well? But that's a question not relevant for this fix of the downport and should probably be addressed in the head revision.

Best regards,
Volker

Thanks,

Paul

On 11/15/19, 8:49 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net> on behalf of hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:

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

    On 11/15/19, 8:33 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net> on behalf of hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:

        You are correct. I'll file an issue to fix it.

        Thanks,

        Paul

        On 11/14/19, 11:05 PM, "jdk8u-dev on behalf of Yangfei (Felix)" <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net> on behalf of felix.yang at huawei.com<mailto:felix.yang at huawei.com>> wrote:

            Hi,

              We found one inconsistency of backport of 8219677.
              The upstream patch set parameter use_vfork_if_available to true when call os::fork_and_exec in VM_ReportJavaOutOfMemory::doit().
              But looks like the 8u backport did something inconsistent: the change was not made in the correct place.
              The 8u backport patch: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/97d605522fcb

            Patch for jdk8u-dev:

            diff -r 775e2bf92114 src/share/vm/utilities/vmError.cpp
            --- a/src/share/vm/utilities/vmError.cpp        Wed Aug 07 17:00:19 2019 +0800
            +++ b/src/share/vm/utilities/vmError.cpp        Fri Nov 15 14:23:50 2019 +0800
            @@ -1060,7 +1060,7 @@
                   out.print_raw   (cmd);
                   out.print_raw_cr("\" ...");

            -      if (os::fork_and_exec(cmd, true) < 0) {
            +      if (os::fork_and_exec(cmd) < 0) {
                     out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
                   }
                 }
            @@ -1147,7 +1147,7 @@
            #endif
                 tty->print_cr("\"%s\"...", cmd);

            -    if (os::fork_and_exec(cmd) < 0) {
            +    if (os::fork_and_exec(cmd, true) < 0) {
                   tty->print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno);
                 }
               }

            Please confirm.

            Thanks,
            Felix






From mbalao at redhat.com  Mon Nov 18 18:08:40 2019
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 18 Nov 2019 15:08:40 -0300
Subject: [8u] RFR 8133489: Better messaging for PKIX path validation matching
Message-ID: <2c1600cb-106f-684b-6f15-ec7136121e31@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8133489 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8133489/8133489.8u.jdk.webrev.00/

Changes for 8u:

 * KeyUsageMatters.java
  * 1st hook does not apply cleanly because "* @modules
java.base/sun.security.util" line (from the hook context) is not present
in 8u.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8133489


From sgehwolf at redhat.com  Mon Nov 18 18:11:39 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 18 Nov 2019 19:11:39 +0100
Subject: [8u] RFR: 8204290: Add check to limit number of capture groups
Message-ID: <6b5dd7bcb18aba515511d23c095663fcdbd626ef.camel@redhat.com>

Hi,

Could I please get a review of this OpenJDK 8u backport of JDK-8204290
for Oracle JDK 8u24x parity? The JDK 11 patch is the same exept for
these test changes (and modulo path changes):

This:

    new RegExp("()".repeat(0x8001));
    fail("Expected exception");

became:

    var captureGroups = "";
    for (i=0; i < 0x8001; i++) { captureGroups = captureGroups + "()"; }
    new RegExp(captureGroups);
    fail("Expected exception");

String.repeat() is a JDK 11 feature. Results in:

<shell>:1 TypeError: "()".repeat is not a function

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

Testing: nashorn tests. New regresstion test passes. Manual testing with jjs.

Thoughts?

Thanks,
Severin


From hohensee at amazon.com  Mon Nov 18 18:14:53 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 18 Nov 2019 18:14:53 +0000
Subject: [8u] RFR 8133489: Better messaging for PKIX path validation
 matching
In-Reply-To: <2c1600cb-106f-684b-6f15-ec7136121e31@redhat.com>
References: <2c1600cb-106f-684b-6f15-ec7136121e31@redhat.com>
Message-ID: <FC2A5597-EB0B-42DD-A428-30C41DAF8F8B@amazon.com>

Lgtm.

Paul

?On 11/18/19, 10:09 AM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces at openjdk.java.net on behalf of mbalao at redhat.com> wrote:

    Hi,
    
    I'd like to request a review for the 8u backport of 8133489 [1].
    
    Webrev.00:
    
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8133489/8133489.8u.jdk.webrev.00/
    
    Changes for 8u:
    
     * KeyUsageMatters.java
      * 1st hook does not apply cleanly because "* @modules
    java.base/sun.security.util" line (from the hook context) is not present
    in 8u.
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8133489
    
    


From hohensee at amazon.com  Mon Nov 18 19:36:02 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 18 Nov 2019 19:36:02 +0000
Subject: Pending fix requests
In-Reply-To: <5D41625C-0074-4C95-8C3D-F38813DEABCF@amazon.com>
References: <E2D9FD34-94AA-4BD1-A38F-F1B850E86597@amazon.com>
 <5D41625C-0074-4C95-8C3D-F38813DEABCF@amazon.com>
Message-ID: <5D6E1F59-A985-4338-BB84-8E0F06267DD0@amazon.com>

Thanks, Andrew, for approving JDK-8068736. Would you take a look at the others please? Also, clarification: "8u241", etc., are JBS tags and thus mean Oracle's 8u releases.

Paul

?On 11/6/19, 3:11 PM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    Ping. :) The JBS issue list I'm watching includes
    
    https://bugs.openjdk.java.net/browse/JDK-8048556: Unnecessary GCLocker-initiated young GCs
    	Fixed in 8u241 and 11.0.6.
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010447.html
    https://bugs.openjdk.java.net/browse/JDK-8068736: Avoid synchronization on Executable/Field.declaredAnnotations
    https://bugs.openjdk.java.net/browse/JDK-8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts
    	Fixed in 8u221 and 11.0.6.
    https://bugs.openjdk.java.net/browse/JDK-8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug.
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010179.html
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010379.html
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010477.html
    https://bugs.openjdk.java.net/browse/JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010418.html
    	The 2d folks haven't replied, but the patch is seems good to me.
    https://bugs.openjdk.java.net/browse/JDK-8216401: Allow "file:" URLs in Class-Path of local JARs
    	Fixed in 8u231 and 11.0.5.
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010023.html
    	https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010220.html
    
    Thanks,
    
    Paul
    
    On 10/24/19, 11:54 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:
    
        Gentle request to 8u maintainers. :)
        
        There are a number of reviewed backports waiting for maintainer approval/disapproval (i.e., to be tagged with jdk8u-fix-yes/no), e.g., 8144732.
        
        Thanks,
        
        Paul
        
        
        
    
    


From valerie.peng at oracle.com  Mon Nov 18 21:18:37 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 18 Nov 2019 13:18:37 -0800
Subject: RFR[8u41]: MR 3 - ALPN & RSASSA-PSS in Java SE 8
In-Reply-To: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
References: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
Message-ID: <8a0706a3-640d-1954-d08d-e6ea76253df2@oracle.com>

Hi Brad,

Most changes look good. Just a nit and a question (please see below):

- src/share/classes/java/security/Signature.java: line 596 has @since 13
- As a side effect of this, I noticed that the default key size for RSA is
bumped up from 1024 to 2048 (see sun/security/util/SecurityProviderConstants.java
and src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java). I wonder if
we may need to adjust the value in SecurityProviderConstrants.java back to 1024
for RSA and maybe use 2048 for RSASSA-PSS? Or, maybe can we bump RSA default
to 2048 as well?

Thanks,
Valerie

On 11/13/2019 6:05 PM, Bradford Wetmore wrote:
> Xuelei/Valerie (+ any other codereviewers),
>
> As announced on jdk8u-dev[1], there is a Maintenance Release in 
> progress for Java SE 8 (i.e. JSR 337) [2] to include two security 
> features important for TLS 1.3:
>
> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4]
> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme 
> (RSASSA-PSS) [5][6]
>
> The Enhancement and CSR IDs are footnoted above/below.
>
> To ensure compatibility across the active Java releases, we are 
> backporting the APIs introduced in Java SE 9 and 11 respectively to 
> Java SE 8.
>
> This email is a Request For Review (RFR) of the two major pieces for 
> this MR:
>
> 1.? ALPN:
> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/ALPN
>
> 2.? RSASSA-PSS:
> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/PSS
>
> This includes the updates to the Specification and Reference 
> Implementation (RI), which will be called JDK 8u41 [7].
>
> Almost all of these changes are direct copies of the changesets 
> applied in JDK 9+.
>
> In addition to these features:
>
> 1.? The file ADDITIONAL_LICENSE_INFO was added, which is identical to 
> the same file in later releases.
>
> 2.? Truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were 
> added to the SUN Provider to support the corresponding truncated 
> RSASSA-PSS Signatures.
>
> Thanks,
>
> Brad
>
> [1] 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html
> [2] https://www.jcp.org/en/jsr/detail?id=337
> [3] https://bugs.openjdk.java.net/browse/JDK-8230977
> [4] https://bugs.openjdk.java.net/browse/JDK-8233417
> [5] https://bugs.openjdk.java.net/browse/JDK-8230978
> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/

From hohensee at amazon.com  Mon Nov 18 23:40:06 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 18 Nov 2019 23:40:06 +0000
Subject: [8u] RFR 8044500: [1/2] Add kinit options and krb5.conf flags
 that allow users to obtain renewable tickets and specify ticket lifetimes
In-Reply-To: <6C857F22-5223-45A5-8A3A-E184431B59A8@amazon.com>
References: <6C857F22-5223-45A5-8A3A-E184431B59A8@amazon.com>
Message-ID: <61F3E89F-8B2E-47B2-BAB4-915967FC0C8E@amazon.com>

Lgtm, but would another reviewer also take a look please?

Thanks,

Paul

?On 11/8/19, 11:39 AM, "jdk8u-dev on behalf of Verghese, Clive" <jdk8u-dev-bounces at openjdk.java.net on behalf of verghese at amazon.com> wrote:

    Hi,
    
    Requesting review for backport of JDK-8044500,
    
    JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8044500
    Original Change : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fb5752b152d9
    Webrev : http://cr.openjdk.java.net/~alvdavi/webrevs/8044500/webrev.8u.00/
    
    This is backport is a dependency for backporting JDK-8186576.
    
    Parts of this backport have already been backported into JDK-8044500.
    The patch did not apply cleanly and the major difference were
    
      *   Variable name changes in KDC.java
      *   Imports in Config.java
    
    Both Tier1 and Tier2 tests in Linux x64.
    
    Regards,
    Clive Verghese
    
    


From hohensee at amazon.com  Mon Nov 18 23:47:00 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 18 Nov 2019 23:47:00 +0000
Subject: [8u] RFR: 8186576: [2/2] KerberosTicket does not properly handle
 renewable tickets at the end of their lifetime
In-Reply-To: <B715FA19-9424-42EE-AFCC-B65E92F19720@amazon.com>
References: <B715FA19-9424-42EE-AFCC-B65E92F19720@amazon.com>
Message-ID: <A38F5F26-0BD1-4EFD-ABD0-1CE3962FE8C3@amazon.com>

Lgtm. I looked at [1/2] JDK-8044500 first, and same request applies: would another reviewer also take a look please?

Thanks,

Paul

?On 11/8/19, 11:39 AM, "jdk8u-dev on behalf of Verghese, Clive" <jdk8u-dev-bounces at openjdk.java.net on behalf of verghese at amazon.com> wrote:

    Hi,
    
    Requesting review for backport of JDK-8186576.
    
    JDK-8186576
    JBS Issues : https://bugs.openjdk.java.net/browse/JDK-8186576
    Original Change : http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/fa7582840977
    Webrev : http://cr.openjdk.java.net/~alvdavi/webrevs/8186576/webrev.8u.00/
    
    
    The backport did not apply cleanly, It required changes from JDK-804450. The test case written for JDK-8186576, specifically NullRenewUntil, was requesting renewable tickets, support for which was added in JDK-8044500.
    Additionally parts of JDK-8044500 had already been backported.
    
    We could
    
      1.  Add the required functions and update the tests. Or
      2.  Backport JDK-8044500
    
    I have backported both JDK-8044500 and JDK-8186576.
    
    Other than the usual changes to filenames and copyrights, The patches also needed minor modifications mentioned below.
    
    JDK-8186576
    
      *   Variable name change in KDC.java
      *   Missing ?{? in the if blocks in KerberosTicket.java
    
    
    Regards,
    Clive Verghese
    


From hohensee at amazon.com  Mon Nov 18 23:56:06 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 18 Nov 2019 23:56:06 +0000
Subject: [8u] RFR: 8218580: endpoint identification algorithm should be
 case-insensitive
In-Reply-To: <7B408184-7E67-4185-A595-8C92303D2B0D@amazon.com>
References: <7B408184-7E67-4185-A595-8C92303D2B0D@amazon.com>
Message-ID: <A4E5FBC3-35A2-4AC4-BC7F-35FB55889333@amazon.com>

If the code in the hunk that didn't apply is ever backported, context will be lost and incompatible code will result. Better to find the patch referenced by that hunk and backport it.

Thanks,

Paul

?On 10/31/19, 10:00 AM, "jdk8u-dev on behalf of Verghese, Clive" <jdk8u-dev-bounces at openjdk.java.net on behalf of verghese at amazon.com> wrote:

    Hi,
    
    I am requesting review for backport of JDK-8218580
    
    Webrev : http://cr.openjdk.java.net/~phh/8218580/webrev.8u.00/
    
    JBS Bug : https://bugs.openjdk.java.net/browse/JDK-8218580
    Original Change : http://hg.openjdk.java.net/jdk/jdk/rev/c34acb3a3330
    Change Set for JDK 11 : http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/148957581f5c
    
    The JBS Bug marks the issue as Introduced in 11. But checking the 8u code, it looks like the bug is effecting 8u as well.
    
    The backport to 8u did not apply cleanly. Other than the filename changes and line number changes, one of the notable changes is that only 2 of the 3 hunks applied in ClientHandshaker.java.
    
    The patch has passed tier-1 in Linux and no new regressions were found.
    
    Regards,
    Clive Verghese
    


From gnu.andrew at redhat.com  Tue Nov 19 01:28:23 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 19 Nov 2019 01:28:23 +0000
Subject: RFR[8u41]: MR 3 - ALPN & RSASSA-PSS in Java SE 8
In-Reply-To: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
References: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
Message-ID: <de23fd34-acd1-9967-0926-b301868d3a56@redhat.com>



On 14/11/2019 02:05, Bradford Wetmore wrote:
> Xuelei/Valerie (+ any other codereviewers),
> 
> As announced on jdk8u-dev[1], there is a Maintenance Release in progress
> for Java SE 8 (i.e. JSR 337) [2] to include two security features
> important for TLS 1.3:
> 
> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4]
> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme
> (RSASSA-PSS) [5][6]
> 
> The Enhancement and CSR IDs are footnoted above/below.
> 
> To ensure compatibility across the active Java releases, we are
> backporting the APIs introduced in Java SE 9 and 11 respectively to Java
> SE 8.
> 
> This email is a Request For Review (RFR) of the two major pieces for
> this MR:
> 
> 1.? ALPN:
> ??? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/ALPN
> 
> 2.? RSASSA-PSS:
> ??? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/PSS
> 
> This includes the updates to the Specification and Reference
> Implementation (RI), which will be called JDK 8u41 [7].
> 
> Almost all of these changes are direct copies of the changesets applied
> in JDK 9+.
> 
> In addition to these features:
> 
> 1.? The file ADDITIONAL_LICENSE_INFO was added, which is identical to
> the same file in later releases.
> 
> 2.? Truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added
> to the SUN Provider to support the corresponding truncated RSASSA-PSS
> Signatures.
> 
> Thanks,
> 
> Brad
> 
> [1]
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html
> [2] https://www.jcp.org/en/jsr/detail?id=337
> [3] https://bugs.openjdk.java.net/browse/JDK-8230977
> [4] https://bugs.openjdk.java.net/browse/JDK-8233417
> [5] https://bugs.openjdk.java.net/browse/JDK-8230978
> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/
> 

It's not clear which bug IDs these two webrevs apply to.

Note that changes for OpenJDK 8u require approval using the
jdk8u-fix-request label, as described at
https://wiki.openjdk.java.net/display/jdk8u/Main.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From rkennke at redhat.com  Tue Nov 19 11:56:48 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 19 Nov 2019 12:56:48 +0100
Subject: RFR: 8234096: Mutex rank ordering problem JVMTI LoadedClassesClosure
 and G1 SATB queue
Message-ID: <fc761a48-8224-0654-5813-e3120505d5b1@redhat.com>

A user reported a mutex rank ordering problem between JVMTI 
LoadedClassesClosure and G1's SATB queues. As far as I can tell, this is 
caused by JDK-8187577:

ClassLoaderData::loaded_classes_do() acquires the "Metaspace allocation 
lock/5" and LoadedClassesClosure tries to enqueue it into G1's SATB 
queue, thus attempts to acquire "SATB_Q_CBL_mon/16"

See bug report for more details and discussion.
https://bugs.openjdk.java.net/browse/JDK-8234096

The bug is 8u-specific. I forward-ported the testcase to 11 and 14 (will 
post that under different bug-ID asap), and could not reproduce it 
there. I also analyzed the code path, and confirmed that the bug is 
really not present there.

The fix that I want to propose is simple: instead of enqueueing the oops 
during loaded_classes_do() (and thus under lock), we can enqueue it 
during extraction of same class-mirrors into the target array. This is 
ok because there is no safepoint between the two phases.

Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8234096/webrev.02/

Testing: The new test fails without the fix, and passes with it. 
hotspot_all doesn't show regressions

Can I please get a review for this change?

Thanks, Roman


From mbalao at redhat.com  Tue Nov 19 19:55:24 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 19 Nov 2019 16:55:24 -0300
Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
Message-ID: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8080462 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.00/

Differences from 11u patch [2]:

 * src/share/legal/pkcs11cryptotoken.md
  * Does not apply because "8169925: Organize licenses by module in
source, JMOD file, and run-time image" [3] is not in 8u.

 * src/share/classes/sun/security/pkcs11/SunPKCS11.java
  * 6th and 11th hook do not apply cleanly because ECParameters location
is "sun.security.ec.ECParameters" in 8u instead of
"sun.security.util.ECParameters"
  * 8th hook does not apply cleanly because 8042967 [4] is not in 8u.

 * src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java
  * 5th hook does not apply cleanly because toString method uses a
StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).

 * src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java
  * 1st hook does not apply cleanly because toString method uses a
StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).

 * src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
  * 13th hook does no apply cleanly because 8074580 [6] is not in 8u.
Manually applied change.

 * src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
  * Copyright date.

 * src/share/native/sun/security/pkcs11/wrapper/p11_util.c
  * Copyright date.

 * src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
  * 4th hook does not apply cleanly because 6913047 was backported to 8u
without the "//#define P11_DEBUG" line.

 * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java
  * 1th hook does not apply cleanly because of copyright date.
  * 2nd hook do not apply cleanly because 8164639 [7], 8078334 [8],
8172527 [9], 8144539 [10] are not in 8u. Manually applied changes.

 * src/share/classes/sun/security/util/GCMParameters.java
  * HexDumpEncoder is sun.misc.HexDumpEncoder in 8u (instead of
sun.security.util.HexDumpEncoder)

 * src/share/classes/sun/security/pkcs11/P11PSSSignature.java
  * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
8146293 [11] has not been backported. Added a private field in
P11PSSSignature with the constant.

 * test/sun/security/pkcs11/Cipher/TestKATForGCM.java
 * test/sun/security/pkcs11/Cipher/Test4512704.java
 * test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java
 * test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java
 * test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java
 * test/sun/security/pkcs11/Signature/InitAgainPSS.java
 * test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
 * test/sun/security/pkcs11/Signature/SigInteropPSS.java
 * test/sun/security/pkcs11/Signature/SignatureTestPSS.java
 * test/sun/security/pkcs11/Signature/TestDSA2.java
  * @library jtreg header modified to remove "/test/lib"
  * 8144539 [12] is not in 8u. Given that the test uses no arguments, I
discarded the parameter when calling PKCS11Test::main method.

 * test/sun/security/pkcs11/Signature/InitAgainPSS.java
  * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
8146293 [11] has not been backported. Added a private field in
InitAgainPSS with the constant.

 * make/mapfiles/libj2pkcs11/mapfile-vers
  * Added Java_sun_security_pkcs11_wrapper_PKCS11_freeMechanism native
method

 * test/sun/security/pkcs11/Signature/SigInteropPSS.java
  * "java.security.NoSuchAlgorithmException: no such algorithm:
RSASSA-PSS for provider SunRsaSign" error.
   * This test cannot properly execute because 8146293 [11] is not in
8u. Manually modified to skip unless 8146293 [11] is available.


Testing

 * No regressions have been observed in sun/security/pkcs11 category

 * All new tests (introduced by this enhancement) pass
  * Note: SigInteropPSS is skipped for the reasons previously stated

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8080462
[2] - https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8bac0ba1d5ce
[3] - https://bugs.openjdk.java.net/browse/JDK-8169925
[4] - https://bugs.openjdk.java.net/browse/JDK-8042967
[5] - https://bugs.openjdk.java.net/browse/JDK-8041679
[6] - https://bugs.openjdk.java.net/browse/JDK-8074580
[7] - https://bugs.openjdk.java.net/browse/JDK-8164639
[8] - https://bugs.openjdk.java.net/browse/JDK-8078334
[9] - https://bugs.openjdk.java.net/browse/JDK-8172527
[10] - https://bugs.openjdk.java.net/browse/JDK-8144539
[11] - https://bugs.openjdk.java.net/browse/JDK-8146293
[12] - https://bugs.openjdk.java.net/browse/JDK-8144539


From ebaron at redhat.com  Wed Nov 20 01:21:25 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Tue, 19 Nov 2019 20:21:25 -0500
Subject: [8u] RFR 8046044: Fix raw and unchecked lint warnings in XML
 Signature Impl
Message-ID: <6d2da520-f1f6-a46b-e863-0a2b7fa0f259@redhat.com>

Hi,

I'd like to request a review to backport 8046044 to 8u. The motivation 
for this change is to facilitate backporting "8177334: Update xmldsig 
implementation to Apache Santuario 2.1.1" [1][2].

Original fix:
https://bugs.openjdk.java.net/browse/JDK-8046044
https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7d6154df328c

The patch did not apply cleanly to 8u. The rejects were mainly cosmetic, 
with parts of this patch being superseded by 8151893 [3]. Aside from 
fixing file paths, the changes to the original patch are as follows:

src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java:
src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java:
src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java:
- Copyright header already updated from 8151893.
src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java:
- Copyright header already updated from 8149029.
- Change already applied by 8149029, then later modified by 8151893 [4].
src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java:
- Had to modify one line of context affected by 8032733 missing in 8u.
-- 8032733 is fairly large and wide reaching, a backport was previously 
considered and rejected [5].
src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java:
- Copyright header already updated from 8151893.
- One line of context modified due to change in 8151893.

8u webrev:
http://cr.openjdk.java.net/~ebaron/JDK-8046044/webrev.00/

Testing: x86_64 build, jdk_tier1, jdk_security tests

Thanks,
Elliott

[1] https://bugs.openjdk.java.net/browse/JDK-8177334
[2] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010175.html
[3] https://bugs.openjdk.java.net/browse/JDK-8151893
[4] 
https://hg.openjdk.java.net/jdk/jdk/diff/094bfaa699c3/jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java#l1.12
[5] https://bugs.openjdk.java.net/browse/JDK-8040729


From neugens at redhat.com  Wed Nov 20 15:29:24 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 20 Nov 2019 16:29:24 +0100
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
Message-ID: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>

Hi all,

I would like to backport 8231991 and 8234107 all the way down to 8u.

The backport is identical for all versions (except the paths in 8u
obviously), but is slightly different than the patch for 14dev, first
of all because the two changes have been merged into one, but most
importantly because I decided against introducing the two new constants
in sun/awt/X11/XConstants.java and instead went to have those values
directly copied in the code where they are used.

http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From hohensee at amazon.com  Wed Nov 20 16:20:50 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Nov 2019 16:20:50 +0000
Subject: [8u] RFR 8046044: Fix raw and unchecked lint warnings in XML
 Signature Impl
In-Reply-To: <6d2da520-f1f6-a46b-e863-0a2b7fa0f259@redhat.com>
References: <6d2da520-f1f6-a46b-e863-0a2b7fa0f259@redhat.com>
Message-ID: <873EBAB4-1FA1-4686-891E-4487EF93C81C@amazon.com>

DOMURIDereferencer.java isn't in the webrev. Otherwise good.

Thanks,
Paul

?On 11/19/19, 5:22 PM, "jdk8u-dev on behalf of Elliott Baron" <jdk8u-dev-bounces at openjdk.java.net on behalf of ebaron at redhat.com> wrote:

    Hi,
    
    I'd like to request a review to backport 8046044 to 8u. The motivation 
    for this change is to facilitate backporting "8177334: Update xmldsig 
    implementation to Apache Santuario 2.1.1" [1][2].
    
    Original fix:
    https://bugs.openjdk.java.net/browse/JDK-8046044
    https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7d6154df328c
    
    The patch did not apply cleanly to 8u. The rejects were mainly cosmetic, 
    with parts of this patch being superseded by 8151893 [3]. Aside from 
    fixing file paths, the changes to the original patch are as follows:
    
    src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java:
    src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java:
    src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java:
    - Copyright header already updated from 8151893.
    src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java:
    - Copyright header already updated from 8149029.
    - Change already applied by 8149029, then later modified by 8151893 [4].
    src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java:
    - Had to modify one line of context affected by 8032733 missing in 8u.
    -- 8032733 is fairly large and wide reaching, a backport was previously 
    considered and rejected [5].
    src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java:
    - Copyright header already updated from 8151893.
    - One line of context modified due to change in 8151893.
    
    8u webrev:
    http://cr.openjdk.java.net/~ebaron/JDK-8046044/webrev.00/
    
    Testing: x86_64 build, jdk_tier1, jdk_security tests
    
    Thanks,
    Elliott
    
    [1] https://bugs.openjdk.java.net/browse/JDK-8177334
    [2] 
    https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010175.html
    [3] https://bugs.openjdk.java.net/browse/JDK-8151893
    [4] 
    https://hg.openjdk.java.net/jdk/jdk/diff/094bfaa699c3/jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java#l1.12
    [5] https://bugs.openjdk.java.net/browse/JDK-8040729
    
    


From hohensee at amazon.com  Wed Nov 20 16:07:00 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Nov 2019 16:07:00 +0000
Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40
 support
In-Reply-To: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
Message-ID: <2FF9CDD6-9142-4828-B2A5-3302C1356078@amazon.com>

You define TRAILER_FIELD_BC in two places which may result in future version skew (i.e., one gets updated but the other doesn't). I'd put the 11u PSSParameterSpec definition in 8u instead. That'll be an obvious overlay if 8146293 is backported, imo likely given it seems to be needed for TLS 1.3.

Otherwise good.

Paul

?On 11/19/19, 11:57 AM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces at openjdk.java.net on behalf of mbalao at redhat.com> wrote:

    Hi,
    
    I'd like to request a review for the 8u backport of 8080462 [1].
    
    Webrev.00:
    
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.00/
    
    Differences from 11u patch [2]:
    
     * src/share/legal/pkcs11cryptotoken.md
      * Does not apply because "8169925: Organize licenses by module in
    source, JMOD file, and run-time image" [3] is not in 8u.
    
     * src/share/classes/sun/security/pkcs11/SunPKCS11.java
      * 6th and 11th hook do not apply cleanly because ECParameters location
    is "sun.security.ec.ECParameters" in 8u instead of
    "sun.security.util.ECParameters"
      * 8th hook does not apply cleanly because 8042967 [4] is not in 8u.
    
     * src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java
      * 5th hook does not apply cleanly because toString method uses a
    StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).
    
     * src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java
      * 1st hook does not apply cleanly because toString method uses a
    StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).
    
     * src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
      * 13th hook does no apply cleanly because 8074580 [6] is not in 8u.
    Manually applied change.
    
     * src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
      * Copyright date.
    
     * src/share/native/sun/security/pkcs11/wrapper/p11_util.c
      * Copyright date.
    
     * src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
      * 4th hook does not apply cleanly because 6913047 was backported to 8u
    without the "//#define P11_DEBUG" line.
    
     * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java
      * 1th hook does not apply cleanly because of copyright date.
      * 2nd hook do not apply cleanly because 8164639 [7], 8078334 [8],
    8172527 [9], 8144539 [10] are not in 8u. Manually applied changes.
    
     * src/share/classes/sun/security/util/GCMParameters.java
      * HexDumpEncoder is sun.misc.HexDumpEncoder in 8u (instead of
    sun.security.util.HexDumpEncoder)
    
     * src/share/classes/sun/security/pkcs11/P11PSSSignature.java
      * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
    8146293 [11] has not been backported. Added a private field in
    P11PSSSignature with the constant.
    
     * test/sun/security/pkcs11/Cipher/TestKATForGCM.java
     * test/sun/security/pkcs11/Cipher/Test4512704.java
     * test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java
     * test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java
     * test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java
     * test/sun/security/pkcs11/Signature/InitAgainPSS.java
     * test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
     * test/sun/security/pkcs11/Signature/SigInteropPSS.java
     * test/sun/security/pkcs11/Signature/SignatureTestPSS.java
     * test/sun/security/pkcs11/Signature/TestDSA2.java
      * @library jtreg header modified to remove "/test/lib"
      * 8144539 [12] is not in 8u. Given that the test uses no arguments, I
    discarded the parameter when calling PKCS11Test::main method.
    
     * test/sun/security/pkcs11/Signature/InitAgainPSS.java
      * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
    8146293 [11] has not been backported. Added a private field in
    InitAgainPSS with the constant.
    
     * make/mapfiles/libj2pkcs11/mapfile-vers
      * Added Java_sun_security_pkcs11_wrapper_PKCS11_freeMechanism native
    method
    
     * test/sun/security/pkcs11/Signature/SigInteropPSS.java
      * "java.security.NoSuchAlgorithmException: no such algorithm:
    RSASSA-PSS for provider SunRsaSign" error.
       * This test cannot properly execute because 8146293 [11] is not in
    8u. Manually modified to skip unless 8146293 [11] is available.
    
    
    Testing
    
     * No regressions have been observed in sun/security/pkcs11 category
    
     * All new tests (introduced by this enhancement) pass
      * Note: SigInteropPSS is skipped for the reasons previously stated
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8080462
    [2] - https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8bac0ba1d5ce
    [3] - https://bugs.openjdk.java.net/browse/JDK-8169925
    [4] - https://bugs.openjdk.java.net/browse/JDK-8042967
    [5] - https://bugs.openjdk.java.net/browse/JDK-8041679
    [6] - https://bugs.openjdk.java.net/browse/JDK-8074580
    [7] - https://bugs.openjdk.java.net/browse/JDK-8164639
    [8] - https://bugs.openjdk.java.net/browse/JDK-8078334
    [9] - https://bugs.openjdk.java.net/browse/JDK-8172527
    [10] - https://bugs.openjdk.java.net/browse/JDK-8144539
    [11] - https://bugs.openjdk.java.net/browse/JDK-8146293
    [12] - https://bugs.openjdk.java.net/browse/JDK-8144539
    
    


From gnu.andrew at redhat.com  Wed Nov 20 16:22:44 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 20 Nov 2019 16:22:44 +0000
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
Message-ID: <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>



On 20/11/2019 15:29, Mario Torre wrote:
> Hi all,
> 
> I would like to backport 8231991 and 8234107 all the way down to 8u.
> 
> The backport is identical for all versions (except the paths in 8u
> obviously), but is slightly different than the patch for 14dev, first
> of all because the two changes have been merged into one, but most
> importantly because I decided against introducing the two new constants
> in sun/awt/X11/XConstants.java and instead went to have those values
> directly copied in the code where they are used.
> 
> http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> 
> Cheers,
> Mario
> 

I'd prefer we just did clean backports of the two bugs. That's what I
already did for 8u locally for our RPMs. I don't see that not adding the
two constants does anything but make the fix more obscure. The class is
internal and adds new constants, rather than modifying anything that
exists and users would rely on.

You could make them package private, but I'd suggest again doing that in
all versions.

If you just backport the two as is, they apply down to 8u, with only
path changes. That makes this review unnecessary.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From hohensee at amazon.com  Wed Nov 20 17:31:51 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Nov 2019 17:31:51 +0000
Subject: [8u] RFR: [TESTBUG] Some ssl jtreg tests fail due to usage of a
 secp256k1 ECDSA certificate
In-Reply-To: <ef50ab00-c31a-54db-db46-6554b9160f7a@amazon.com>
References: <ef50ab00-c31a-54db-db46-6554b9160f7a@amazon.com>
Message-ID: <AD450B1F-54E8-4A3C-B14F-FC410E42CAC0@amazon.com>

Lgtm.

Paul

?On 11/8/19, 1:25 PM, "jdk8u-dev on behalf of David Alvarez" <jdk8u-dev-bounces at openjdk.java.net on behalf of alvdavi at amazon.com> wrote:

    Hi,
    
    Requesting review for:
    
    JBS: https://bugs.openjdk.java.net/browse/JDK-8233864
    Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8233864/webrev.8u.00/
    
    After 8u232, certain Tier2 jtreg ssl tests started to fail as they were
    relying on a certificate based on curve secp256k1. That curve is no
    longer enabled for ssl (disabled by JDK-8228825 [1]).
    
    The specific certificate is located in:
    test/sun/security/ssl/etc/keystore
    and
    test/sun/security/ssl/etc/truststore
    
    This patch fixes those tests by recreating the certificate stores with
    new certificates. The generated ECDSA certificate uses secp256r1. These
    certificates are v3 instead of v1 as the originals, but we have seen no
    failures caused by this.
    
    This change includes binary changes. A patch file with binary changes is
    located here:
    http://cr.openjdk.java.net/~alvdavi/patches/8233864.8u.00.patch
    
    Thanks,
    --
    David Alvarez
    
    [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5456f24496f4#l1.18
    
    


From neugens at redhat.com  Wed Nov 20 17:53:40 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 20 Nov 2019 18:53:40 +0100
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
 <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
Message-ID: <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>

Hi Andrew,

Thanks, this makes sense. I've probably been overly conservative.

If approved, I'll commit the patches as they are from 14-dev then.

Cheers,
Mario

On Wed, Nov 20, 2019 at 5:22 PM Andrew John Hughes
<gnu.andrew at redhat.com> wrote:
>
>
>
> On 20/11/2019 15:29, Mario Torre wrote:
> > Hi all,
> >
> > I would like to backport 8231991 and 8234107 all the way down to 8u.
> >
> > The backport is identical for all versions (except the paths in 8u
> > obviously), but is slightly different than the patch for 14dev, first
> > of all because the two changes have been merged into one, but most
> > importantly because I decided against introducing the two new constants
> > in sun/awt/X11/XConstants.java and instead went to have those values
> > directly copied in the code where they are used.
> >
> > http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> >
> > Cheers,
> > Mario
> >
>
> I'd prefer we just did clean backports of the two bugs. That's what I
> already did for 8u locally for our RPMs. I don't see that not adding the
> two constants does anything but make the fix more obscure. The class is
> internal and adds new constants, rather than modifying anything that
> exists and users would rely on.
>
> You could make them package private, but I'd suggest again doing that in
> all versions.
>
> If you just backport the two as is, they apply down to 8u, with only
> path changes. That makes this review unnecessary.
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From ebaron at redhat.com  Wed Nov 20 18:05:10 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Wed, 20 Nov 2019 13:05:10 -0500
Subject: [8u] RFR 8046044: Fix raw and unchecked lint warnings in XML
 Signature Impl
In-Reply-To: <873EBAB4-1FA1-4686-891E-4487EF93C81C@amazon.com>
References: <6d2da520-f1f6-a46b-e863-0a2b7fa0f259@redhat.com>
 <873EBAB4-1FA1-4686-891E-4487EF93C81C@amazon.com>
Message-ID: <d6ee4686-4272-76bb-d958-0ad2d16db458@redhat.com>

Hi Paul,

On 2019-11-20 11:20 a.m., Hohensee, Paul wrote:
> DOMURIDereferencer.java isn't in the webrev. Otherwise good.
> 

Thanks for the review. I should have clarified that both 
DOMURIDereferencer hunks from the original patch no longer apply for 8u, 
thus there is nothing to do for that file in the backport.

The copyright hunk was already done by 8149029 and the ResourceResolver 
hunk superseded by 8151893.

Thanks,
Elliott

> 
> ?On 11/19/19, 5:22 PM, "jdk8u-dev on behalf of Elliott Baron" <jdk8u-dev-bounces at openjdk.java.net on behalf of ebaron at redhat.com> wrote:
> 
>      Hi,
>      
>      I'd like to request a review to backport 8046044 to 8u. The motivation
>      for this change is to facilitate backporting "8177334: Update xmldsig
>      implementation to Apache Santuario 2.1.1" [1][2].
>      
>      Original fix:
>      https://bugs.openjdk.java.net/browse/JDK-8046044
>      https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7d6154df328c
>      
>      The patch did not apply cleanly to 8u. The rejects were mainly cosmetic,
>      with parts of this patch being superseded by 8151893 [3]. Aside from
>      fixing file paths, the changes to the original patch are as follows:
>      
>      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java:
>      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java:
>      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java:
>      - Copyright header already updated from 8151893.
>      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java:
>      - Copyright header already updated from 8149029.
>      - Change already applied by 8149029, then later modified by 8151893 [4].
>      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java:
>      - Had to modify one line of context affected by 8032733 missing in 8u.
>      -- 8032733 is fairly large and wide reaching, a backport was previously
>      considered and rejected [5].
>      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java:
>      - Copyright header already updated from 8151893.
>      - One line of context modified due to change in 8151893.
>      
>      8u webrev:
>      http://cr.openjdk.java.net/~ebaron/JDK-8046044/webrev.00/
>      
>      Testing: x86_64 build, jdk_tier1, jdk_security tests
>      
>      Thanks,
>      Elliott
>      
>      [1] https://bugs.openjdk.java.net/browse/JDK-8177334
>      [2]
>      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010175.html
>      [3] https://bugs.openjdk.java.net/browse/JDK-8151893
>      [4]
>      https://hg.openjdk.java.net/jdk/jdk/diff/094bfaa699c3/jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java#l1.12
>      [5] https://bugs.openjdk.java.net/browse/JDK-8040729
>      
>      
> 


From mbalao at redhat.com  Wed Nov 20 19:32:16 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 20 Nov 2019 16:32:16 -0300
Subject: [8u] RFR 8055351:
 sun/security/provider/DSA/TestAlgParameterGenerator.java failed with
 interrupted! (timed out?)
Message-ID: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8055351 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8055351/8055351.8u.jdk.webrev.00/

Differences from JDK baseline patch:

 * test/sun/security/provider/DSA/TestAlgParameterGenerator.java
  * Copyright date
  * 1st and 2nd hooks do not apply cleanly because 8u already has
8181048 [2] [3] affecting the same file. Note: 8181048 was backported
before 8055351 to 8u, even though it's a newer patch. Manually applied
changes without further conflicts.

Testing:

 *  sun/security/provider/DSA/TestAlgParameterGenerator.java passes

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8055351
[2] - https://bugs.openjdk.java.net/browse/JDK-8181048
[3] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/65f4af74c8b1


From hohensee at amazon.com  Wed Nov 20 20:36:30 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Nov 2019 20:36:30 +0000
Subject: [8u] RFR 8046044: Fix raw and unchecked lint warnings in XML
 Signature Impl
In-Reply-To: <d6ee4686-4272-76bb-d958-0ad2d16db458@redhat.com>
References: <6d2da520-f1f6-a46b-e863-0a2b7fa0f259@redhat.com>
 <873EBAB4-1FA1-4686-891E-4487EF93C81C@amazon.com>
 <d6ee4686-4272-76bb-d958-0ad2d16db458@redhat.com>
Message-ID: <F018DB87-E37A-4E35-B5B0-AB562B3045B3@amazon.com>

Thanks for the explanation. All good then.

Paul

?On 11/20/19, 10:05 AM, "Elliott Baron" <ebaron at redhat.com> wrote:

    Hi Paul,
    
    On 2019-11-20 11:20 a.m., Hohensee, Paul wrote:
    > DOMURIDereferencer.java isn't in the webrev. Otherwise good.
    > 
    
    Thanks for the review. I should have clarified that both 
    DOMURIDereferencer hunks from the original patch no longer apply for 8u, 
    thus there is nothing to do for that file in the backport.
    
    The copyright hunk was already done by 8149029 and the ResourceResolver 
    hunk superseded by 8151893.
    
    Thanks,
    Elliott
    
    > 
    > On 11/19/19, 5:22 PM, "jdk8u-dev on behalf of Elliott Baron" <jdk8u-dev-bounces at openjdk.java.net on behalf of ebaron at redhat.com> wrote:
    > 
    >      Hi,
    >      
    >      I'd like to request a review to backport 8046044 to 8u. The motivation
    >      for this change is to facilitate backporting "8177334: Update xmldsig
    >      implementation to Apache Santuario 2.1.1" [1][2].
    >      
    >      Original fix:
    >      https://bugs.openjdk.java.net/browse/JDK-8046044
    >      https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7d6154df328c
    >      
    >      The patch did not apply cleanly to 8u. The rejects were mainly cosmetic,
    >      with parts of this patch being superseded by 8151893 [3]. Aside from
    >      fixing file paths, the changes to the original patch are as follows:
    >      
    >      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java:
    >      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java:
    >      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java:
    >      - Copyright header already updated from 8151893.
    >      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java:
    >      - Copyright header already updated from 8149029.
    >      - Change already applied by 8149029, then later modified by 8151893 [4].
    >      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java:
    >      - Had to modify one line of context affected by 8032733 missing in 8u.
    >      -- 8032733 is fairly large and wide reaching, a backport was previously
    >      considered and rejected [5].
    >      src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java:
    >      - Copyright header already updated from 8151893.
    >      - One line of context modified due to change in 8151893.
    >      
    >      8u webrev:
    >      http://cr.openjdk.java.net/~ebaron/JDK-8046044/webrev.00/
    >      
    >      Testing: x86_64 build, jdk_tier1, jdk_security tests
    >      
    >      Thanks,
    >      Elliott
    >      
    >      [1] https://bugs.openjdk.java.net/browse/JDK-8177334
    >      [2]
    >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010175.html
    >      [3] https://bugs.openjdk.java.net/browse/JDK-8151893
    >      [4]
    >      https://hg.openjdk.java.net/jdk/jdk/diff/094bfaa699c3/jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java#l1.12
    >      [5] https://bugs.openjdk.java.net/browse/JDK-8040729
    >      
    >      
    > 
    
    


From hohensee at amazon.com  Wed Nov 20 20:49:43 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Nov 2019 20:49:43 +0000
Subject: [8u] RFR 8055351:
 sun/security/provider/DSA/TestAlgParameterGenerator.java failed with
 interrupted! (timed out?)
In-Reply-To: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com>
References: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com>
Message-ID: <BA05E20D-C319-4A18-8844-305B5637E0B3@amazon.com>

Lgtm.

Paul

?On 11/20/19, 11:33 AM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces at openjdk.java.net on behalf of mbalao at redhat.com> wrote:

    Hi,
    
    I'd like to request a review for the 8u backport of 8055351 [1].
    
    Webrev.00:
    
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8055351/8055351.8u.jdk.webrev.00/
    
    Differences from JDK baseline patch:
    
     * test/sun/security/provider/DSA/TestAlgParameterGenerator.java
      * Copyright date
      * 1st and 2nd hooks do not apply cleanly because 8u already has
    8181048 [2] [3] affecting the same file. Note: 8181048 was backported
    before 8055351 to 8u, even though it's a newer patch. Manually applied
    changes without further conflicts.
    
    Testing:
    
     *  sun/security/provider/DSA/TestAlgParameterGenerator.java passes
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8055351
    [2] - https://bugs.openjdk.java.net/browse/JDK-8181048
    [3] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/65f4af74c8b1
    
    


From mbalao at redhat.com  Wed Nov 20 22:34:07 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 20 Nov 2019 19:34:07 -0300
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
Message-ID: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8073108 [1].

Webrev.00:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8073108/8073108.8u.webrev.00/

Differences from JDK patch:

Hotspot
--

 * Path changes

 * src/cpu/aarch64/vm/vm_version_aarch64.cpp
  * AArch64 changes do not apply to 8u
   * Will be proposed for
http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/

 * src/cpu/ppc/vm/vm_version_ppc.cpp
  * 1st hook does not apply cleanly because 8u has 8185979 [2] [3]
already (8185979 is newer than 8073108 but was backported first).
Manually applied change without further conflicts.

 * src/cpu/x86/vm/assembler_x86.cpp
  * 1st hook does not apply cleanly because 8u does not have 8076276
[4]. Manually applied changes without further conflicts.

 * src/share/vm/runtime/globals.hpp
  * 1st hook does not apply cleanly because 8u does not have 8074459
[5]. Manually applied changes without further conflicts.

JDK
--

 * Path changes

Testing:

 * com/sun/crypto/provider/Cipher/AES/TestGHASH.java
  * Passes

 * hotspot/test/compiler/7184394
  * Passes

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8073108
[2] - https://bugs.openjdk.java.net/browse/JDK-8185979
[3] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c4567d28f31f
[4] - https://bugs.openjdk.java.net/browse/JDK-8076276
[5] - https://bugs.openjdk.java.net/browse/JDK-8074459


From hohensee at amazon.com  Wed Nov 20 23:37:58 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Nov 2019 23:37:58 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
Message-ID: <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>

Patch looks good. Have you run the tests on sparc?

Thanks,
Paul

?On 11/20/19, 2:35 PM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces at openjdk.java.net on behalf of mbalao at redhat.com> wrote:

    Hi,
    
    I'd like to request a review for the 8u backport of 8073108 [1].
    
    Webrev.00:
    
     * http://cr.openjdk.java.net/~mbalao/webrevs/8073108/8073108.8u.webrev.00/
    
    Differences from JDK patch:
    
    Hotspot
    --
    
     * Path changes
    
     * src/cpu/aarch64/vm/vm_version_aarch64.cpp
      * AArch64 changes do not apply to 8u
       * Will be proposed for
    http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/
    
     * src/cpu/ppc/vm/vm_version_ppc.cpp
      * 1st hook does not apply cleanly because 8u has 8185979 [2] [3]
    already (8185979 is newer than 8073108 but was backported first).
    Manually applied change without further conflicts.
    
     * src/cpu/x86/vm/assembler_x86.cpp
      * 1st hook does not apply cleanly because 8u does not have 8076276
    [4]. Manually applied changes without further conflicts.
    
     * src/share/vm/runtime/globals.hpp
      * 1st hook does not apply cleanly because 8u does not have 8074459
    [5]. Manually applied changes without further conflicts.
    
    JDK
    --
    
     * Path changes
    
    Testing:
    
     * com/sun/crypto/provider/Cipher/AES/TestGHASH.java
      * Passes
    
     * hotspot/test/compiler/7184394
      * Passes
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8073108
    [2] - https://bugs.openjdk.java.net/browse/JDK-8185979
    [3] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c4567d28f31f
    [4] - https://bugs.openjdk.java.net/browse/JDK-8076276
    [5] - https://bugs.openjdk.java.net/browse/JDK-8074459
    
    


From bradford.wetmore at oracle.com  Wed Nov 20 23:48:00 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 20 Nov 2019 15:48:00 -0800
Subject: RFR[8u41]: MR 3 - ALPN & RSASSA-PSS in Java SE 8
In-Reply-To: <de23fd34-acd1-9967-0926-b301868d3a56@redhat.com>
References: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
 <de23fd34-acd1-9967-0926-b301868d3a56@redhat.com>
Message-ID: <6417bf7c-eecd-7994-1e1f-309802cd3789@oracle.com>

Hi Andrew,

There are two phases for the MR:

1.  We must show the API/changes are implementable by providing a 
Reference Implementation (RI) and corresponding TCK tests.  These 
codereviews are for the RI.

2.  From Iris' email [1]:

     If it's not too much work then we'll also contribute the changes
     required by the MR to the next appropriate OpenJDK 8 release, most
     likely 8u252...

If we can contribute these changes to OpenJDK, we will use the 
jdk8u-fix-request label at that time.

 >>
 >> [4] https://bugs.openjdk.java.net/browse/JDK-8233417

 >> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
 >> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/
 >>
 >
 > It's not clear which bug IDs these two webrevs apply to.

ALPN:  https://bugs.openjdk.java.net/browse/JDK-8230977
PSS:   https://bugs.openjdk.java.net/browse/JDK-8230978

Thanks,

Brad

[1] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html



On 11/18/2019 5:28 PM, Andrew John Hughes wrote:
> 
> 
> On 14/11/2019 02:05, Bradford Wetmore wrote:
>> Xuelei/Valerie (+ any other codereviewers),
>>
>> As announced on jdk8u-dev[1], there is a Maintenance Release in progress
>> for Java SE 8 (i.e. JSR 337) [2] to include two security features
>> important for TLS 1.3:
>>
>> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4]
>> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme
>> (RSASSA-PSS) [5][6]
>>
>> The Enhancement and CSR IDs are footnoted above/below.
>>
>> To ensure compatibility across the active Java releases, we are
>> backporting the APIs introduced in Java SE 9 and 11 respectively to Java
>> SE 8.
>>
>> This email is a Request For Review (RFR) of the two major pieces for
>> this MR:
>>
>> 1.? ALPN:
>>  ??? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/ALPN
>>
>> 2.? RSASSA-PSS:
>>  ??? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/PSS
>>
>> This includes the updates to the Specification and Reference
>> Implementation (RI), which will be called JDK 8u41 [7].
>>
>> Almost all of these changes are direct copies of the changesets applied
>> in JDK 9+.
>>
>> In addition to these features:
>>
>> 1.? The file ADDITIONAL_LICENSE_INFO was added, which is identical to
>> the same file in later releases.
>>
>> 2.? Truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added
>> to the SUN Provider to support the corresponding truncated RSASSA-PSS
>> Signatures.
>>
>> Thanks,
>>
>> Brad
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html
>> [2] https://www.jcp.org/en/jsr/detail?id=337
>> [3] https://bugs.openjdk.java.net/browse/JDK-8230977
>> [4] https://bugs.openjdk.java.net/browse/JDK-8233417
>> [5] https://bugs.openjdk.java.net/browse/JDK-8230978
>> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
>> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/
>>
> 
> It's not clear which bug IDs these two webrevs apply to.
> 
> Note that changes for OpenJDK 8u require approval using the
> jdk8u-fix-request label, as described at
> https://wiki.openjdk.java.net/display/jdk8u/Main.
> 
> Thanks,
> 

From mbalao at redhat.com  Thu Nov 21 03:50:30 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 00:50:30 -0300
Subject: [8u] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc
Message-ID: <273b3a83-f3e5-2bc0-d7da-da3774a57287@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8131778 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8131778/8131778.8u.hotspot.webrev.00/

Differences from JDK baseline patch:

 * src/cpu/x86/vm/vm_version_x86.cpp
  * 2nd hook does not apply cleanly because 8134553 [2] and 8073108 [3]
are not in 8u. Note: 8073108 [3] backport to 8u is in progress [4].
Manually applied change without further conflicts.

This backport is necessary for feature parity between OpenJDK and Oracle
JDK.

Testing:

I could verify there are no regressions in x86_64:

[martin at vmhost bin]$ ./java -XX:+UseAES -XX:UseSSE=2
-XX:+PrintFlagsFinal -version| grep UseAES
     bool UseAES                                   := true
                 {product}
     bool UseAESIntrinsics                          = false
                 {product}
openjdk version "1.8.0-internal-debug"
OpenJDK Runtime Environment (build
1.8.0-internal-debug-martin_2019_11_20_15_40-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode)

I don't have infrastructure to build and test on SPARC; but given that
there were no conflicts on SPARC part of the patch, I assume it's likely
to be okay.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8131778
[2] - https://bugs.openjdk.java.net/browse/JDK-8134553
[3] - https://bugs.openjdk.java.net/browse/JDK-8073108
[4] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010630.html


From mbalao at redhat.com  Thu Nov 21 03:56:47 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 00:56:47 -0300
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
Message-ID: <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>

Hi Paul,

Thanks for having a look at this backport.

On 11/20/19 8:37 PM, Hohensee, Paul wrote:
> Patch looks good. Have you run the tests on sparc?
> 

I should have clarified that tests were run on x86_64. I don't have
SPARC hardware to test unfortunately.

Regards,
Martin.-


From bradford.wetmore at oracle.com  Thu Nov 21 07:02:45 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 20 Nov 2019 23:02:45 -0800
Subject: RFR[8u41]: MR 3 - ALPN & RSASSA-PSS in Java SE 8
In-Reply-To: <6417bf7c-eecd-7994-1e1f-309802cd3789@oracle.com>
References: <e3a062c9-a3c6-166c-3dad-0a34c15e1fc2@oracle.com>
 <de23fd34-acd1-9967-0926-b301868d3a56@redhat.com>
 <6417bf7c-eecd-7994-1e1f-309802cd3789@oracle.com>
Message-ID: <f57d080f-3d1b-a4a3-c250-7a0f7817244b@oracle.com>

Andrew,

On second thought, we will use the jdk8u-fix-request as requested.? 
Thanks for pointing this out.

I've added the relevant tags and comments,? can you or Andrew Haley 
please approve?

ALPN:? https://bugs.openjdk.java.net/browse/JDK-8230977

PSS:?? https://bugs.openjdk.java.net/browse/JDK-8230978

Brad


On 11/20/2019 3:48 PM, Bradford Wetmore wrote:
> Hi Andrew,
>
> There are two phases for the MR:
>
> 1.? We must show the API/changes are implementable by providing a 
> Reference Implementation (RI) and corresponding TCK tests.? These 
> codereviews are for the RI.
>
> 2.? From Iris' email [1]:
>
> ??? If it's not too much work then we'll also contribute the changes
> ??? required by the MR to the next appropriate OpenJDK 8 release, most
> ??? likely 8u252...
>
> If we can contribute these changes to OpenJDK, we will use the 
> jdk8u-fix-request label at that time.
>
> >>
> >> [4] https://bugs.openjdk.java.net/browse/JDK-8233417
>
> >> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
> >> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/
> >>
> >
> > It's not clear which bug IDs these two webrevs apply to.
>
> ALPN:? https://bugs.openjdk.java.net/browse/JDK-8230977
> PSS:?? https://bugs.openjdk.java.net/browse/JDK-8230978
>
> Thanks,
>
> Brad
>
> [1] 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html
>
>
>
> On 11/18/2019 5:28 PM, Andrew John Hughes wrote:
>>
>>
>> On 14/11/2019 02:05, Bradford Wetmore wrote:
>>> Xuelei/Valerie (+ any other codereviewers),
>>>
>>> As announced on jdk8u-dev[1], there is a Maintenance Release in 
>>> progress
>>> for Java SE 8 (i.e. JSR 337) [2] to include two security features
>>> important for TLS 1.3:
>>>
>>> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4]
>>> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme
>>> (RSASSA-PSS) [5][6]
>>>
>>> The Enhancement and CSR IDs are footnoted above/below.
>>>
>>> To ensure compatibility across the active Java releases, we are
>>> backporting the APIs introduced in Java SE 9 and 11 respectively to 
>>> Java
>>> SE 8.
>>>
>>> This email is a Request For Review (RFR) of the two major pieces for
>>> this MR:
>>>
>>> 1.? ALPN:
>>> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/ALPN
>>>
>>> 2.? RSASSA-PSS:
>>> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u41/open/PSS
>>>
>>> This includes the updates to the Specification and Reference
>>> Implementation (RI), which will be called JDK 8u41 [7].
>>>
>>> Almost all of these changes are direct copies of the changesets applied
>>> in JDK 9+.
>>>
>>> In addition to these features:
>>>
>>> 1.? The file ADDITIONAL_LICENSE_INFO was added, which is identical to
>>> the same file in later releases.
>>>
>>> 2.? Truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added
>>> to the SUN Provider to support the corresponding truncated RSASSA-PSS
>>> Signatures.
>>>
>>> Thanks,
>>>
>>> Brad
>>>
>>> [1]
>>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html 
>>>
>>> [2] https://www.jcp.org/en/jsr/detail?id=337
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230977
>>> [4] https://bugs.openjdk.java.net/browse/JDK-8233417
>>> [5] https://bugs.openjdk.java.net/browse/JDK-8230978
>>> [6] https://bugs.openjdk.java.net/browse/JDK-8233418
>>> [7] http://hg.openjdk.java.net/jdk8u/jdk8u41/
>>>
>>
>> It's not clear which bug IDs these two webrevs apply to.
>>
>> Note that changes for OpenJDK 8u require approval using the
>> jdk8u-fix-request label, as described at
>> https://wiki.openjdk.java.net/display/jdk8u/Main.
>>
>> Thanks,
>>

From xxinliu at amazon.com  Thu Nov 21 07:29:12 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Thu, 21 Nov 2019 07:29:12 +0000
Subject: JDK-8221605 fix backport candidate (dup of JDK-8146792)
In-Reply-To: <BL0PR2101MB100906047F339B8F4E7E97EFF5700@BL0PR2101MB1009.namprd21.prod.outlook.com>
References: <BL0PR2101MB100906047F339B8F4E7E97EFF5700@BL0PR2101MB1009.namprd21.prod.outlook.com>
Message-ID: <048F30F9-75D2-4E95-B5F1-7F794D5B3C9B@amazon.com>

Hi, Nikola and Felix, 

?I marked it dup. It is kind of duplication. The attached file of JDK-8221605 is closer to your program. It crashes for the same reason as yours. 
The description of JDK-8146792 is about partial peel. Actually, peeling could cause broken graph. Roland's testcase prevents  general peeling on purpose. 
I think It's a good idea to file a new JBS issue to amend a new testcase.  We backport it as well. 

Thanks,
--lx
 

?On 11/15/19, 6:36 AM, "jdk8u-dev on behalf of Nikola Grcevski" <jdk8u-dev-bounces at openjdk.java.net on behalf of Nikola.Grcevski at microsoft.com> wrote:

    Hello jdk8u-dev,
    
    I'm a VM engineer at Microsoft and new to this mailing list. After reproducing the error in "JDK-8221605: C2 crashed at PhaseIdealLoop::build_loop_late_post" (https://bugs.openjdk.java.net/browse/JDK-8221605) I was able to identify the root cause as a missing backport of a fix made in JDK9. The fix for the problem can be found in the following JDK9 revision: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f and it's covered by the bug report https://bugs.openjdk.java.net/browse/JDK-8146792 . I found that this backport has already been discussed under the following thread, but it was never finally committed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009947.html .
    
    From the original bug report in JDK-8221605, I was able to reduce the failing testcase to the following very simple program (which is very similar to the failing testcase as described by Felix Yang):
    
    /**
    * @summary Predicate moved after partial peel may lead to broken graph
     * @run main/othervm -XX:-TieredCompilation -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:CompileOnly=BadGraphAfterPeelAndPredicateTransform::m1 -XX:CompileCommand=quiet BadGraphAfterPeelAndPredicateTransform
    */
    public class BadGraphAfterPeelAndPredicateTransform {
        public static final int SIZE = 40;
        public static final int RUN_TO_COMPILE = 200;
    
        private void m1() {
            /**
             * The arrays need to be allocated here to reproduce the problem
             * because we can prove the lengths for bound checks
             */
            int arr[] = new int[SIZE], arr2[][] = new int[SIZE][SIZE];
    
            /**
              * The loop induction variable needs to be float, double or long, so that we fail detection as a counted loop
            */
            for (float f = 0; f < SIZE; ++f) {
                arr[(int)(f)] = 1;
                for (int j = 0; j < 1; ++j) {
                    arr = arr2[j];
                }
            }
        }
    
        public static void main(String[] args) {
            BadGraphAfterPeelAndPredicateTransform instance = new BadGraphAfterPeelAndPredicateTransform();
           
            for (int i = 0; i < RUN_TO_COMPILE; i++ ) {
                instance.m1();
            }
        }
    }
    
    After investigation into the root cause of the issue and I can confirm that the webrev (http://cr.openjdk.java.net/~fyang/8146792-backport/webrev.00/) as submitted by Felix Yang in the email thread above is the correct patch for JDK8, as the second change in src/share/vm/opto/loopPredicate.cpp (@@ -641,6 +665,7 @@) from the original JDK9 fix is already there in JDK8. I did some debugging to understand the issue better and I have made the following conclusions:
    
    - The problem only happens if we perform loop peeling. In the testcase above (or in the one described by Felix in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009947.html) if one changes the loop variable to be of type int, the problem never happens because the loop is identified as a counted loop and peeling is never attempted.
    - The original testcase supplied with the JDK9 fix in revision http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f never fails on JDK8 because peeling is never attempted on that testcase in JDK8.
    - The root of the problem is related to computing invariance of certain nodes. Namely, when the test fails, a conditional's invariance is already computed on a given node (coming from the IdealLoopTree to Invariance class constructor) and then the loop is peeled. After peeling the computed invariance remains set on the node, however the set computed invariance may not hold true after loop peeling is performed. The fix in JDK9 prevents the loop predicate optimization on all nodes that might be pinned between the peeled predicates and the loop entry which prevents the invalid movement of a predicate. As an experiment, I forcibly re-computed the invariance on the predicate (in my case it was a null check) ahead of performing loop predication and this resolved the problem too, as the node was deemed as non loop invariant after freshly recomputing the invariance. The experiment is not a feasible fix, it was done only to prove the hypothesis.
   
    Can we please backport the fix to JDK8 and perhaps make bug report JDK-8221605 a duplicate of JDK-8146792? While it's somewhat uncommon for a programmer to use an induction variable other than an int in a loop, it seems that if they choose to do so the problem occurs anytime the loop is peeled. Based on the original JDK9 bug report, this can occur with loops that use an int as an induction variable if the loop isn't deemed as counted. 

    I also think it would be good to add these additional tests that use non-int loop induction variables as tests in all releases. I would really like to help with making these additional tests on top of the backport.
    
    I would also like to perform some further performance testing on the change in JDK8 to ensure the fix doesn't cause performance regressions. Does anyone have any suggested benchmarks that might be a good choice for verifying the impact of this change in loop optimizations?
    
    Cheers,
    -Nikola
    


From aph at redhat.com  Thu Nov 21 10:10:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Nov 2019 10:10:27 +0000
Subject: New JDK 8u Maintainer
Message-ID: <1c999bff-f112-002c-ec0f-d25ef47c560d@redhat.com>

We have a new Maintainer: Severin Gehwolf <sgehwolf at redhat.com>.

He's a very experienced engineer and has been working on updates
for some time. I'm sure he'll do an excellent job.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From ygaevsky at azul.com  Thu Nov 21 10:38:45 2019
From: ygaevsky at azul.com (Yuri Gaevsky)
Date: Thu, 21 Nov 2019 10:38:45 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
Message-ID: <2b4eeccd689049cfaed69e80523e720e@azul.com>

Hi Martin,

Could you please clarify how is your patch different from the similar patch for JDK-8073108 [1] (or [2])?

NB:  another follow-up patch [3] is required to make that acceleration fully functional.

Thanks,
-Yuri

[1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010493.html
[2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010409.html
[3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010437.html


-----Original Message-----
From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf Of Martin Balao
Sent: Thursday, November 21, 2019 01:34 AM
To: jdk8u-dev at openjdk.java.net
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration

Hi,

I'd like to request a review for the 8u backport of 8073108 [1].

Webrev.00:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8073108/8073108.8u.webrev.00/

Differences from JDK patch:

Hotspot
--

 * Path changes

 * src/cpu/aarch64/vm/vm_version_aarch64.cpp
  * AArch64 changes do not apply to 8u
   * Will be proposed for
http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/

 * src/cpu/ppc/vm/vm_version_ppc.cpp
  * 1st hook does not apply cleanly because 8u has 8185979 [2] [3]
already (8185979 is newer than 8073108 but was backported first).
Manually applied change without further conflicts.

 * src/cpu/x86/vm/assembler_x86.cpp
  * 1st hook does not apply cleanly because 8u does not have 8076276
[4]. Manually applied changes without further conflicts.

 * src/share/vm/runtime/globals.hpp
  * 1st hook does not apply cleanly because 8u does not have 8074459
[5]. Manually applied changes without further conflicts.

JDK
--

 * Path changes

Testing:

 * com/sun/crypto/provider/Cipher/AES/TestGHASH.java
  * Passes

 * hotspot/test/compiler/7184394
  * Passes

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8073108
[2] - https://bugs.openjdk.java.net/browse/JDK-8185979
[3] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c4567d28f31f
[4] - https://bugs.openjdk.java.net/browse/JDK-8076276
[5] - https://bugs.openjdk.java.net/browse/JDK-8074459

From christoph.langer at sap.com  Thu Nov 21 10:59:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Nov 2019 10:59:14 +0000
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
 <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
 <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>
Message-ID: <AM6PR02MB4801EAA159691735F2E2E7FA8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Mario,

I completely agree with Andrew here: Please commit the patches as is, without folding.

Approving for 11u ??

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Mario Torre
> Sent: Mittwoch, 20. November 2019 18:54
> To: Andrew John Hughes <gnu.andrew at redhat.com>
> Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u
> 
> Hi Andrew,
> 
> Thanks, this makes sense. I've probably been overly conservative.
> 
> If approved, I'll commit the patches as they are from 14-dev then.
> 
> Cheers,
> Mario
> 
> On Wed, Nov 20, 2019 at 5:22 PM Andrew John Hughes
> <gnu.andrew at redhat.com> wrote:
> >
> >
> >
> > On 20/11/2019 15:29, Mario Torre wrote:
> > > Hi all,
> > >
> > > I would like to backport 8231991 and 8234107 all the way down to 8u.
> > >
> > > The backport is identical for all versions (except the paths in 8u
> > > obviously), but is slightly different than the patch for 14dev, first
> > > of all because the two changes have been merged into one, but most
> > > importantly because I decided against introducing the two new constants
> > > in sun/awt/X11/XConstants.java and instead went to have those values
> > > directly copied in the code where they are used.
> > >
> > > http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> > >
> > > Cheers,
> > > Mario
> > >
> >
> > I'd prefer we just did clean backports of the two bugs. That's what I
> > already did for 8u locally for our RPMs. I don't see that not adding the
> > two constants does anything but make the fix more obscure. The class is
> > internal and adds new constants, rather than modifying anything that
> > exists and users would rely on.
> >
> > You could make them package private, but I'd suggest again doing that in
> > all versions.
> >
> > If you just backport the two as is, they apply down to 8u, with only
> > path changes. That makes this review unnecessary.
> >
> > Thanks,
> > --
> > Andrew :)
> >
> > Senior Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> >
> > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> > Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> > https://keybase.io/gnu_andrew
> >
> 
> 
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From neugens at redhat.com  Thu Nov 21 11:54:44 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 21 Nov 2019 12:54:44 +0100
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <AM6PR02MB4801EAA159691735F2E2E7FA8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
 <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
 <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>
 <AM6PR02MB4801EAA159691735F2E2E7FA8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <CAJwKKmZE3vmbYNOZ5v2byU5eTDBFLQO7qNhxAeobsp6nCzgTHg@mail.gmail.com>

Hi Christoph,

Sure thing, thanks!

I'll consider those as approvals for 8u and 11u but I suppose I still need
approval for 13u before proceeding with those?

Cheers,
Mario

On Thu, Nov 21, 2019 at 11:59 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Mario,
>
> I completely agree with Andrew here: Please commit the patches as is,
> without folding.
>
> Approving for 11u ??
>
> Cheers
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Mario Torre
> > Sent: Mittwoch, 20. November 2019 18:54
> > To: Andrew John Hughes <gnu.andrew at redhat.com>
> > Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u
> >
> > Hi Andrew,
> >
> > Thanks, this makes sense. I've probably been overly conservative.
> >
> > If approved, I'll commit the patches as they are from 14-dev then.
> >
> > Cheers,
> > Mario
> >
> > On Wed, Nov 20, 2019 at 5:22 PM Andrew John Hughes
> > <gnu.andrew at redhat.com> wrote:
> > >
> > >
> > >
> > > On 20/11/2019 15:29, Mario Torre wrote:
> > > > Hi all,
> > > >
> > > > I would like to backport 8231991 and 8234107 all the way down to 8u.
> > > >
> > > > The backport is identical for all versions (except the paths in 8u
> > > > obviously), but is slightly different than the patch for 14dev, first
> > > > of all because the two changes have been merged into one, but most
> > > > importantly because I decided against introducing the two new
> constants
> > > > in sun/awt/X11/XConstants.java and instead went to have those values
> > > > directly copied in the code where they are used.
> > > >
> > > > http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> > > >
> > > > Cheers,
> > > > Mario
> > > >
> > >
> > > I'd prefer we just did clean backports of the two bugs. That's what I
> > > already did for 8u locally for our RPMs. I don't see that not adding
> the
> > > two constants does anything but make the fix more obscure. The class is
> > > internal and adds new constants, rather than modifying anything that
> > > exists and users would rely on.
> > >
> > > You could make them package private, but I'd suggest again doing that
> in
> > > all versions.
> > >
> > > If you just backport the two as is, they apply down to 8u, with only
> > > path changes. That makes this review unnecessary.
> > >
> > > Thanks,
> > > --
> > > Andrew :)
> > >
> > > Senior Free Java Software Engineer
> > > Red Hat, Inc. (http://www.redhat.com)
> > >
> > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> > > Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> > > https://keybase.io/gnu_andrew
> > >
> >
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From christoph.langer at sap.com  Thu Nov 21 13:22:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Nov 2019 13:22:27 +0000
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <CAJwKKmZE3vmbYNOZ5v2byU5eTDBFLQO7qNhxAeobsp6nCzgTHg@mail.gmail.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
 <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
 <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>
 <AM6PR02MB4801EAA159691735F2E2E7FA8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <CAJwKKmZE3vmbYNOZ5v2byU5eTDBFLQO7qNhxAeobsp6nCzgTHg@mail.gmail.com>
Message-ID: <AM6PR02MB480110D03C124AA0E9FC7F478A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>

Hi Mario,

as for the approvals, you definitely need to monitor the labels in the bug.

I can only approve for 11u (which I have). JDK13u is processed by Oracle (Rob McKenna) and also for 8u I don?t have the powers. You need to wait until one of the Andrews labels the bugs accordingly.

Cheers
Christoph

From: Mario Torre <neugens at redhat.com>
Sent: Donnerstag, 21. November 2019 12:55
To: Langer, Christoph <christoph.langer at sap.com>
Cc: Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u

Hi Christoph,

Sure thing, thanks!

I'll consider those as approvals for 8u and 11u but I suppose I still need approval for 13u before proceeding with those?

Cheers,
Mario

On Thu, Nov 21, 2019 at 11:59 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Mario,

I completely agree with Andrew here: Please commit the patches as is, without folding.

Approving for 11u ??

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> Behalf Of Mario Torre
> Sent: Mittwoch, 20. November 2019 18:54
> To: Andrew John Hughes <gnu.andrew at redhat.com<mailto:gnu.andrew at redhat.com>>
> Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>; jdk-updates-
> dev at openjdk.java.net<mailto:dev at openjdk.java.net>
> Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u
>
> Hi Andrew,
>
> Thanks, this makes sense. I've probably been overly conservative.
>
> If approved, I'll commit the patches as they are from 14-dev then.
>
> Cheers,
> Mario
>
> On Wed, Nov 20, 2019 at 5:22 PM Andrew John Hughes
> <gnu.andrew at redhat.com<mailto:gnu.andrew at redhat.com>> wrote:
> >
> >
> >
> > On 20/11/2019 15:29, Mario Torre wrote:
> > > Hi all,
> > >
> > > I would like to backport 8231991 and 8234107 all the way down to 8u.
> > >
> > > The backport is identical for all versions (except the paths in 8u
> > > obviously), but is slightly different than the patch for 14dev, first
> > > of all because the two changes have been merged into one, but most
> > > importantly because I decided against introducing the two new constants
> > > in sun/awt/X11/XConstants.java and instead went to have those values
> > > directly copied in the code where they are used.
> > >
> > > http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> > >
> > > Cheers,
> > > Mario
> > >
> >
> > I'd prefer we just did clean backports of the two bugs. That's what I
> > already did for 8u locally for our RPMs. I don't see that not adding the
> > two constants does anything but make the fix more obscure. The class is
> > internal and adds new constants, rather than modifying anything that
> > exists and users would rely on.
> >
> > You could make them package private, but I'd suggest again doing that in
> > all versions.
> >
> > If you just backport the two as is, they apply down to 8u, with only
> > path changes. That makes this review unnecessary.
> >
> > Thanks,
> > --
> > Andrew :)
> >
> > Senior Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> >
> > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net<http://keys.gnupg.net>)
> > Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> > https://keybase.io/gnu_andrew
> >
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From christoph.langer at sap.com  Thu Nov 21 13:27:50 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Nov 2019 13:27:50 +0000
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <AM6PR02MB480110D03C124AA0E9FC7F478A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
 <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
 <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>
 <AM6PR02MB4801EAA159691735F2E2E7FA8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <CAJwKKmZE3vmbYNOZ5v2byU5eTDBFLQO7qNhxAeobsp6nCzgTHg@mail.gmail.com>
 <AM6PR02MB480110D03C124AA0E9FC7F478A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4801E18124FEFA13779287AB8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>

One addition: With the approval for 11 you can push to jdk11u-dev now. No need to wait for 13u approval ??

From: Langer, Christoph
Sent: Donnerstag, 21. November 2019 14:22
To: Mario Torre <neugens at redhat.com>
Cc: Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: RE: Backport of 8231991 & 8234107 to 13u, 11u and 8u

Hi Mario,

as for the approvals, you definitely need to monitor the labels in the bug.

I can only approve for 11u (which I have). JDK13u is processed by Oracle (Rob McKenna) and also for 8u I don?t have the powers. You need to wait until one of the Andrews labels the bugs accordingly.

Cheers
Christoph

From: Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>
Sent: Donnerstag, 21. November 2019 12:55
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: Andrew John Hughes <gnu.andrew at redhat.com<mailto:gnu.andrew at redhat.com>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>; jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u

Hi Christoph,

Sure thing, thanks!

I'll consider those as approvals for 8u and 11u but I suppose I still need approval for 13u before proceeding with those?

Cheers,
Mario

On Thu, Nov 21, 2019 at 11:59 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Mario,

I completely agree with Andrew here: Please commit the patches as is, without folding.

Approving for 11u ??

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> Behalf Of Mario Torre
> Sent: Mittwoch, 20. November 2019 18:54
> To: Andrew John Hughes <gnu.andrew at redhat.com<mailto:gnu.andrew at redhat.com>>
> Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>; jdk-updates-
> dev at openjdk.java.net<mailto:dev at openjdk.java.net>
> Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u
>
> Hi Andrew,
>
> Thanks, this makes sense. I've probably been overly conservative.
>
> If approved, I'll commit the patches as they are from 14-dev then.
>
> Cheers,
> Mario
>
> On Wed, Nov 20, 2019 at 5:22 PM Andrew John Hughes
> <gnu.andrew at redhat.com<mailto:gnu.andrew at redhat.com>> wrote:
> >
> >
> >
> > On 20/11/2019 15:29, Mario Torre wrote:
> > > Hi all,
> > >
> > > I would like to backport 8231991 and 8234107 all the way down to 8u.
> > >
> > > The backport is identical for all versions (except the paths in 8u
> > > obviously), but is slightly different than the patch for 14dev, first
> > > of all because the two changes have been merged into one, but most
> > > importantly because I decided against introducing the two new constants
> > > in sun/awt/X11/XConstants.java and instead went to have those values
> > > directly copied in the code where they are used.
> > >
> > > http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> > >
> > > Cheers,
> > > Mario
> > >
> >
> > I'd prefer we just did clean backports of the two bugs. That's what I
> > already did for 8u locally for our RPMs. I don't see that not adding the
> > two constants does anything but make the fix more obscure. The class is
> > internal and adds new constants, rather than modifying anything that
> > exists and users would rely on.
> >
> > You could make them package private, but I'd suggest again doing that in
> > all versions.
> >
> > If you just backport the two as is, they apply down to 8u, with only
> > path changes. That makes this review unnecessary.
> >
> > Thanks,
> > --
> > Andrew :)
> >
> > Senior Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> >
> > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net<http://keys.gnupg.net>)
> > Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> > https://keybase.io/gnu_andrew
> >
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens at redhat.com  Thu Nov 21 15:05:12 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 21 Nov 2019 16:05:12 +0100
Subject: Backport of 8231991 & 8234107 to 13u, 11u and 8u
In-Reply-To: <AM6PR02MB4801E18124FEFA13779287AB8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
References: <ac5ecf8e5116b2d2ae65bb1b77a8e431556226bb.camel@redhat.com>
 <a6361aac-db85-1a33-eedc-721c504d9a2c@redhat.com>
 <CAJwKKmbeOC2rF8jo0E5PGqJd318rchddR9h9Zs+fQf7DAoUP3g@mail.gmail.com>
 <AM6PR02MB4801EAA159691735F2E2E7FA8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <CAJwKKmZE3vmbYNOZ5v2byU5eTDBFLQO7qNhxAeobsp6nCzgTHg@mail.gmail.com>
 <AM6PR02MB480110D03C124AA0E9FC7F478A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <AM6PR02MB4801E18124FEFA13779287AB8A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
Message-ID: <CAJwKKmZ_6gGYrLq7_pwO=NdeFZoYqC01L1UO8ZCX-Vhqo1Sn8g@mail.gmail.com>

Thanks Christoph,

I pushed them on 11u.

Cheers,
Mario

On Thu, Nov 21, 2019 at 2:28 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> One addition: With the approval for 11 you can push to jdk11u-dev now. No
> need to wait for 13u approval ??
>
>
>
> *From:* Langer, Christoph
> *Sent:* Donnerstag, 21. November 2019 14:22
> *To:* Mario Torre <neugens at redhat.com>
> *Cc:* Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u-dev <
> jdk8u-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> *Subject:* RE: Backport of 8231991 & 8234107 to 13u, 11u and 8u
>
>
>
> Hi Mario,
>
>
>
> as for the approvals, you definitely need to monitor the labels in the bug.
>
>
>
> I can only approve for 11u (which I have). JDK13u is processed by Oracle
> (Rob McKenna) and also for 8u I don?t have the powers. You need to wait
> until one of the Andrews labels the bugs accordingly.
>
>
>
> Cheers
>
> Christoph
>
>
>
> *From:* Mario Torre <neugens at redhat.com>
> *Sent:* Donnerstag, 21. November 2019 12:55
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u-dev <
> jdk8u-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> *Subject:* Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u
>
>
>
> Hi Christoph,
>
>
>
> Sure thing, thanks!
>
>
>
> I'll consider those as approvals for 8u and 11u but I suppose I still need
> approval for 13u before proceeding with those?
>
>
>
> Cheers,
>
> Mario
>
>
>
> On Thu, Nov 21, 2019 at 11:59 AM Langer, Christoph <
> christoph.langer at sap.com> wrote:
>
> Hi Mario,
>
> I completely agree with Andrew here: Please commit the patches as is,
> without folding.
>
> Approving for 11u ??
>
> Cheers
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Mario Torre
> > Sent: Mittwoch, 20. November 2019 18:54
> > To: Andrew John Hughes <gnu.andrew at redhat.com>
> > Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: Re: Backport of 8231991 & 8234107 to 13u, 11u and 8u
> >
> > Hi Andrew,
> >
> > Thanks, this makes sense. I've probably been overly conservative.
> >
> > If approved, I'll commit the patches as they are from 14-dev then.
> >
> > Cheers,
> > Mario
> >
> > On Wed, Nov 20, 2019 at 5:22 PM Andrew John Hughes
> > <gnu.andrew at redhat.com> wrote:
> > >
> > >
> > >
> > > On 20/11/2019 15:29, Mario Torre wrote:
> > > > Hi all,
> > > >
> > > > I would like to backport 8231991 and 8234107 all the way down to 8u.
> > > >
> > > > The backport is identical for all versions (except the paths in 8u
> > > > obviously), but is slightly different than the patch for 14dev, first
> > > > of all because the two changes have been merged into one, but most
> > > > importantly because I decided against introducing the two new
> constants
> > > > in sun/awt/X11/XConstants.java and instead went to have those values
> > > > directly copied in the code where they are used.
> > > >
> > > > http://cr.openjdk.java.net/~neugens/8231991-backport/webrev.00/
> > > >
> > > > Cheers,
> > > > Mario
> > > >
> > >
> > > I'd prefer we just did clean backports of the two bugs. That's what I
> > > already did for 8u locally for our RPMs. I don't see that not adding
> the
> > > two constants does anything but make the fix more obscure. The class is
> > > internal and adds new constants, rather than modifying anything that
> > > exists and users would rely on.
> > >
> > > You could make them package private, but I'd suggest again doing that
> in
> > > all versions.
> > >
> > > If you just backport the two as is, they apply down to 8u, with only
> > > path changes. That makes this review unnecessary.
> > >
> > > Thanks,
> > > --
> > > Andrew :)
> > >
> > > Senior Free Java Software Engineer
> > > Red Hat, Inc. (http://www.redhat.com)
> > >
> > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> > > Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> > > https://keybase.io/gnu_andrew
> > >
> >
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>
>
> --
>
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From hohensee at amazon.com  Thu Nov 21 15:44:59 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Nov 2019 15:44:59 +0000
Subject: New JDK 8u Maintainer
In-Reply-To: <1c999bff-f112-002c-ec0f-d25ef47c560d@redhat.com>
References: <1c999bff-f112-002c-ec0f-d25ef47c560d@redhat.com>
Message-ID: <10646E3E-F992-4F4B-936D-B1ED3F5CB11F@amazon.com>

The backport volume has been growing, so this is very good news!

Paul

?On 11/21/19, 2:12 AM, "jdk8u-dev on behalf of jdk8u-dev-bounces at openjdk.java.net" <jdk8u-dev-bounces at openjdk.java.net> wrote:

    We have a new Maintainer: Severin Gehwolf <sgehwolf at redhat.com>.
    
    He's a very experienced engineer and has been working on updates
    for some time. I'm sure he'll do an excellent job.
    
    -- 
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
    
    


From hohensee at amazon.com  Thu Nov 21 15:48:42 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Nov 2019 15:48:42 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
Message-ID: <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>

You should be able to build a 32-bit linux jdk and test it on x32.

Does anyone on the list have access to a sparc box? I'm very hesitant to approve an untested backport. I'd be fine with just the x32/64 part though.

Thanks,
Paul

?On 11/20/19, 7:57 PM, "Martin Balao" <mbalao at redhat.com> wrote:

    Hi Paul,
    
    Thanks for having a look at this backport.
    
    On 11/20/19 8:37 PM, Hohensee, Paul wrote:
    > Patch looks good. Have you run the tests on sparc?
    > 
    
    I should have clarified that tests were run on x86_64. I don't have
    SPARC hardware to test unfortunately.
    
    Regards,
    Martin.-
    
    


From sgehwolf at redhat.com  Thu Nov 21 16:08:58 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 21 Nov 2019 17:08:58 +0100
Subject: New JDK 8u Maintainer
In-Reply-To: <1c999bff-f112-002c-ec0f-d25ef47c560d@redhat.com>
References: <1c999bff-f112-002c-ec0f-d25ef47c560d@redhat.com>
Message-ID: <9b4d297b1584f53e43d162f8fd38b97ce3b24cd7.camel@redhat.com>

On Thu, 2019-11-21 at 10:10 +0000, Andrew Haley wrote:
> We have a new Maintainer: Severin Gehwolf <sgehwolf at redhat.com>.
> 
> He's a very experienced engineer and has been working on updates
> for some time. I'm sure he'll do an excellent job.

Thank you!

With great power comes great responibility. I'll give my best to do it
justice.

Cheers,
Severin


From mbalao at redhat.com  Thu Nov 21 16:10:33 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 13:10:33 -0300
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <2b4eeccd689049cfaed69e80523e720e@azul.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <2b4eeccd689049cfaed69e80523e720e@azul.com>
Message-ID: <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>

Hi Yuri,

I didn't know you have already proposed a backport for this bug. I
assumed nobody did because the ticket was not flagged with
"jdk8u-fix-request". Sorry.

I've not found significant differences between your backport and mine.
The only minor comment I have is that you missed the word "left" in "//
Shift left 128 bit value in xmm register by number of bytes." line
(src/cpu/sparc/vm/vm_version_sparc.cpp).

On 11/21/19 7:38 AM, Yuri Gaevsky wrote:
> Could you please clarify how is your patch different from the similar patch for JDK-8073108 [1] (or [2])?
> 

What's the difference between [1] and [2]?

> NB:  another follow-up patch [3] is required to make that acceleration fully functional.
> 

This one was on my list too. I'll not abstain from duplicating the work.
Thanks for letting me know.

Regards,
Martin.-

> Thanks,
> -Yuri
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010493.html
> [2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010409.html
> [3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010437.html
> 


From mbalao at redhat.com  Thu Nov 21 16:13:19 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 13:13:19 -0300
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
Message-ID: <d790d4a8-9aa2-cf85-53d2-7299339d061e@redhat.com>

On 11/21/19 12:48 PM, Hohensee, Paul wrote:
> You should be able to build a 32-bit linux jdk and test it on x32.
> 

Yes, I'll test on 32-bit.

> Does anyone on the list have access to a sparc box? I'm very hesitant to approve an untested backport. I'd be fine with just the x32/64 part though.
> 

I'm okay with removing the SPARC part if nobody is able to test there.


From mbalao at redhat.com  Thu Nov 21 16:16:06 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 13:16:06 -0300
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <2b4eeccd689049cfaed69e80523e720e@azul.com>
 <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
Message-ID: <381390f8-f090-6fb4-6a01-0a6fb51b7009@redhat.com>

On 11/21/19 1:10 PM, Martin Balao wrote:
> This one was on my list too. I'll not abstain from duplicating the work.

* "I'll abstain from..." (I should have written)


From mbalao at redhat.com  Thu Nov 21 16:26:08 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 13:26:08 -0300
Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40
 support
In-Reply-To: <2FF9CDD6-9142-4828-B2A5-3302C1356078@amazon.com>
References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
 <2FF9CDD6-9142-4828-B2A5-3302C1356078@amazon.com>
Message-ID: <0d1fe4d9-b544-bbec-098f-f88df5a6c94f@redhat.com>

Hi Paul,

On 11/20/19 1:07 PM, Hohensee, Paul wrote:
> You define TRAILER_FIELD_BC in two places which may result in future version skew (i.e., one gets updated but the other doesn't). I'd put the 11u PSSParameterSpec definition in 8u instead. That'll be an obvious overlay if 8146293 is backported, imo likely given it seems to be needed for TLS 1.3.

I've thought about this when doing the backport. My understanding was
that adding a public TRAILER_FIELD_BC field in PSSParameterSpec would
change the API/spec without a CSR. 8146293 is likely to be backported in
a few months for TLS 1.3 as you said. Can we leave the TRAILER_FIELD_BC
local for now until 8146293 is backported and we then synchronize the
constants? If you agree with this compromise solution, I'll keep this in
my backlog.

Thanks,
Martin.-


From hohensee at amazon.com  Thu Nov 21 16:32:19 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Nov 2019 16:32:19 +0000
Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40
 support
In-Reply-To: <0d1fe4d9-b544-bbec-098f-f88df5a6c94f@redhat.com>
References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
 <2FF9CDD6-9142-4828-B2A5-3302C1356078@amazon.com>
 <0d1fe4d9-b544-bbec-098f-f88df5a6c94f@redhat.com>
Message-ID: <87DE613B-E278-41D3-9FE8-C8154FC7BAB3@amazon.com>

As long as it's in your backlog, I'm ok with it.

Thanks,
Paul

?On 11/21/19, 8:26 AM, "Martin Balao" <mbalao at redhat.com> wrote:

    Hi Paul,
    
    On 11/20/19 1:07 PM, Hohensee, Paul wrote:
    > You define TRAILER_FIELD_BC in two places which may result in future version skew (i.e., one gets updated but the other doesn't). I'd put the 11u PSSParameterSpec definition in 8u instead. That'll be an obvious overlay if 8146293 is backported, imo likely given it seems to be needed for TLS 1.3.
    
    I've thought about this when doing the backport. My understanding was
    that adding a public TRAILER_FIELD_BC field in PSSParameterSpec would
    change the API/spec without a CSR. 8146293 is likely to be backported in
    a few months for TLS 1.3 as you said. Can we leave the TRAILER_FIELD_BC
    local for now until 8146293 is backported and we then synchronize the
    constants? If you agree with this compromise solution, I'll keep this in
    my backlog.
    
    Thanks,
    Martin.-
    
    


From martin.doerr at sap.com  Thu Nov 21 16:52:45 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 21 Nov 2019 16:52:45 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <d790d4a8-9aa2-cf85-53d2-7299339d061e@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <d790d4a8-9aa2-cf85-53d2-7299339d061e@redhat.com>
Message-ID: <VI1PR0201MB24799B6B427759166B3A2EDC9A4E0@VI1PR0201MB2479.eurprd02.prod.outlook.com>

Hi,

let me see if I can run it on SPARC.

Best regards,
Martin


> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Martin Balao
> Sent: Donnerstag, 21. November 2019 17:13
> To: Hohensee, Paul <hohensee at amazon.com>; jdk8u-
> dev at openjdk.java.net
> Subject: Re: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for
> GHASH acceleration
> 
> On 11/21/19 12:48 PM, Hohensee, Paul wrote:
> > You should be able to build a 32-bit linux jdk and test it on x32.
> >
> 
> Yes, I'll test on 32-bit.
> 
> > Does anyone on the list have access to a sparc box? I'm very hesitant to
> approve an untested backport. I'd be fine with just the x32/64 part though.
> >
> 
> I'm okay with removing the SPARC part if nobody is able to test there.


From mbalao at redhat.com  Thu Nov 21 19:02:23 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 16:02:23 -0300
Subject: [8u] RFR 8170641:
 sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails with
 timeout
Message-ID: <aa4fcf00-6fef-614a-fb85-2ac7a7b5655d@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8170641 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8170641/8170641.8u.jdk.webrev.00/

Differences from JDK baseline patch:

 * Path changes

 *
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
 *
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
  * Hooks do not apply cleanly because 8142968 [2] is not in 8u.
Manually applied the changes (which was removing the files)

 *
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
 *
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
  * Removed "@modules" and "@library" from jtreg headers
   * @library has to be /lib/testlibrary in 8u
  * Set correct imports for OutputAnalyzer and ProcessTools (which are
located in jdk.testlibrary instead of jdk.test.lib.process)

Testing:

 *
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
  * Passes

 *
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
  * Passes

This backport would bring parity between OpenJDK and Oracle JDK.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8170641
[2] - https://bugs.openjdk.java.net/browse/JDK-8142968


From mbalao at redhat.com  Thu Nov 21 21:30:11 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Nov 2019 18:30:11 -0300
Subject: [8u] RFR 8173956: KeyStore regression due to default keystore being
 changed to PKCS12
Message-ID: <9069972c-26ab-07e9-c16f-d8dc7c40cb72@redhat.com>

Hi,

I'd like to request a review for the 8u backport of 8173956 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8173956/8173956.8u.jdk.webrev.00/

Differences from JDK baseline patch:

 * Path changes

 * src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
  * Copyright date. 2017 year is already there because 8181692 [2] is in
8u already (despite being older than 8173956).

Testing:

 * sun/security/pkcs12/MixedcaseAlias.java
  * Passed

This backport would bring parity between OpenJDK and Oracle JDK.

Thanks,
Martin.-
--
[1] - https://bugs.openjdk.java.net/browse/JDK-8173956
[2] - https://bugs.openjdk.java.net/browse/JDK-8181692


From hohensee at amazon.com  Fri Nov 22 00:20:17 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Nov 2019 00:20:17 +0000
Subject: [8u] RFR 8170641:
 sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails with
 timeout
In-Reply-To: <aa4fcf00-6fef-614a-fb85-2ac7a7b5655d@redhat.com>
References: <aa4fcf00-6fef-614a-fb85-2ac7a7b5655d@redhat.com>
Message-ID: <2E93712F-7D81-4FB4-8830-E0BE45D49F7E@amazon.com>

Patch looks fine. Note that this is just a code review, not an approval (also of course the case for my previous reviews). I'm not a maintainer, not do I wish to be one. :)

Paul

?On 11/21/19, 11:03 AM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces at openjdk.java.net on behalf of mbalao at redhat.com> wrote:

    Hi,
    
    I'd like to request a review for the 8u backport of 8170641 [1].
    
    Webrev.00:
    
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8170641/8170641.8u.jdk.webrev.00/
    
    Differences from JDK baseline patch:
    
     * Path changes
    
     *
    test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
     *
    test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
      * Hooks do not apply cleanly because 8142968 [2] is not in 8u.
    Manually applied the changes (which was removing the files)
    
     *
    test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
     *
    test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
      * Removed "@modules" and "@library" from jtreg headers
       * @library has to be /lib/testlibrary in 8u
      * Set correct imports for OutputAnalyzer and ProcessTools (which are
    located in jdk.testlibrary instead of jdk.test.lib.process)
    
    Testing:
    
     *
    test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
      * Passes
    
     *
    test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
      * Passes
    
    This backport would bring parity between OpenJDK and Oracle JDK.
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8170641
    [2] - https://bugs.openjdk.java.net/browse/JDK-8142968
    
    


From mbalao at redhat.com  Fri Nov 22 05:04:06 2019
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 22 Nov 2019 02:04:06 -0300
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
Message-ID: <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>

Hi Paul,

On 11/21/19 12:48 PM, Hohensee, Paul wrote:
> You should be able to build a 32-bit linux jdk and test it on x32.

The following tests are passing in x86 32 bits (Linux):

 * jdk/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java

The following tests are failing in x86 32 bits (Linux):

 * hotspot/test/compiler/7184394/TestAESMain.java

The reason why TestAESMain fails is that there is a known bug fixed by
8130341 [1]. I've applied my 8u backport of 8130341 [1] and can confirm
that the test passes. So I suggest not to block the 8u backport of
8073108 and proceed with a 8u backport of 8130341 thereafter.

Note: a 8u backport of 8130341 has been proposed by Yuri Gaevsky here:
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010437.html This
backport is identical to mine (except for the commit headers which were
not included in Yuri's patch).

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8130341


From ygaevsky at azul.com  Fri Nov 22 13:30:07 2019
From: ygaevsky at azul.com (Yuri Gaevsky)
Date: Fri, 22 Nov 2019 13:30:07 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <2b4eeccd689049cfaed69e80523e720e@azul.com>
 <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
Message-ID: <1bcabbd834f443ad957abf93d92568d1@azul.com>

Hi Martin,

> I didn't know you have already proposed a backport for this bug. I
> assumed nobody did because the ticket was not flagged with
> "jdk8u-fix-request". Sorry.

There is no need to apologise, it's great to finally see the review for JDK-8073108
is progressing. :-)

IIUC, the marking of the appropriate JBS issue with 'jdk8u-fix-request' is the *next step*
in the backporting process. 

In summary, my reading  of  the related OpenJDK documents (see below) is that:
  (a) the formal review should be done *before* setting 'jdk8u-fix-request' label in JBS;
  (b) 'review request for backport' and 'push approval for backport' are different things.

[1] https://wiki.openjdk.java.net/display/jdk8u/Main
  --- cut ---
    If the backport requires more than just cosmetic changes (file location changes, copyright
  header updates) to apply to the 8u tree, *it should first be submitted for review*.
  Push approval for a fix is *then requested by setting the jdk8u-fix-request label* on
  the original JBS bug.
  --- cut ---

[2] https://wiki.openjdk.java.net/display/jdk8u/Guidelines+for+working+on+jdk8u
  --- cut ---
  In general we'll use the process in https://openjdk.java.net/projects/jdk-updates/approval.html.
  ...
  To request maintainer *approval* for a backport, tag your entry in the bug
  database with "jdk8u-fix-request".
  --- cut ---

[3] https://openjdk.java.net/projects/jdk-updates/approval.html
  --- cut ---
  JDK Updates: Requesting *push* approval for fixes
  Rule 0
  ...
  An OpenJDK JDK Updates Author, Committer or Reviewer requesting their fix in a JDK Updates
  repo MUST label the corresponding master/parent issue with jdk<release>u-fix-request
  (where <release> denotes the feature release version, e.g. jdk10u-fix-request) in the JDK Bug System.
  --- cut ---

[4] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
  --- cut ---
  If (and only if) the original patch was modified, *get the change reviewed*
    Note: *the change review is not the approval, which you would get at the next step*
  --- cut ---


> I've not found significant differences between your backport and mine.
> The only minor comment I have is that you missed the word "left" in "//
> Shift left 128 bit value in xmm register by number of bytes." line
> (src/cpu/sparc/vm/vm_version_sparc.cpp).

Great, thank you for re-checking.

You are right, during addition of 'pslldq' instruction into 'assembler_x86.cpp' I haven't
included it just because the corresponding 'psrldq' above in the sources doesn't have it.
I should have explicitly stated that difference in my request.

> What's the difference between [1] and [2]?

There is no difference, the last one is just a "resending" copy.

Best regards,
-Yuri

-----Original Message-----
From: Martin Balao [mailto:mbalao at redhat.com] 
Sent: Thursday, November 21, 2019 07:11 PM
To: Yuri Gaevsky <ygaevsky at azul.com>; jdk8u-dev at openjdk.java.net
Subject: Re: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration

Hi Yuri,

I didn't know you have already proposed a backport for this bug. I
assumed nobody did because the ticket was not flagged with
"jdk8u-fix-request". Sorry.

I've not found significant differences between your backport and mine.
The only minor comment I have is that you missed the word "left" in "//
Shift left 128 bit value in xmm register by number of bytes." line
(src/cpu/sparc/vm/vm_version_sparc.cpp).

On 11/21/19 7:38 AM, Yuri Gaevsky wrote:
> Could you please clarify how is your patch different from the similar patch for JDK-8073108 [1] (or [2])?
> 

What's the difference between [1] and [2]?

> NB:  another follow-up patch [3] is required to make that acceleration fully functional.
> 

This one was on my list too. I'll not abstain from duplicating the work.
Thanks for letting me know.

Regards,
Martin.-

> Thanks,
> -Yuri
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010493.html
> [2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010409.html
> [3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010437.html
> 

From hohensee at amazon.com  Fri Nov 22 16:07:09 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Nov 2019 16:07:09 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>
Message-ID: <9435D6B0-AB58-4181-9C97-5AAACE857B71@amazon.com>

I'm fine with your proposal to go ahead with 8073108 and do 8130341 next. Now we just need sparc verification. If we don't get that in the next day or two, then I'm ok with pushing just x32/64. Sparc can be done later.

Thanks,
Paul

?On 11/21/19, 9:04 PM, "Martin Balao" <mbalao at redhat.com> wrote:

    Hi Paul,
    
    On 11/21/19 12:48 PM, Hohensee, Paul wrote:
    > You should be able to build a 32-bit linux jdk and test it on x32.
    
    The following tests are passing in x86 32 bits (Linux):
    
     * jdk/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java
    
    The following tests are failing in x86 32 bits (Linux):
    
     * hotspot/test/compiler/7184394/TestAESMain.java
    
    The reason why TestAESMain fails is that there is a known bug fixed by
    8130341 [1]. I've applied my 8u backport of 8130341 [1] and can confirm
    that the test passes. So I suggest not to block the 8u backport of
    8073108 and proceed with a 8u backport of 8130341 thereafter.
    
    Note: a 8u backport of 8130341 has been proposed by Yuri Gaevsky here:
    http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010437.html This
    backport is identical to mine (except for the commit headers which were
    not included in Yuri's patch).
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8130341
    
    


From martin.doerr at sap.com  Fri Nov 22 16:15:28 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 22 Nov 2019 16:15:28 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <9435D6B0-AB58-4181-9C97-5AAACE857B71@amazon.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>
 <9435D6B0-AB58-4181-9C97-5AAACE857B71@amazon.com>
Message-ID: <VI1PR0201MB2479535F33371F8F7984325A9A490@VI1PR0201MB2479.eurprd02.prod.outlook.com>

Hi Paul,

I've put the patches into our nightly tests. Jdk8u tests are supposed to run over the weekend.
I'll check if I can get a result from SPARC on Monday morning.

Best regards,
Martin


> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Hohensee, Paul
> Sent: Freitag, 22. November 2019 17:07
> To: Martin Balao <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
> Subject: [DMARC FAILURE] Re: [8u] RFR 8073108: Use x86 and SPARC CPU
> instructions for GHASH acceleration
> 
> I'm fine with your proposal to go ahead with 8073108 and do 8130341 next.
> Now we just need sparc verification. If we don't get that in the next day or
> two, then I'm ok with pushing just x32/64. Sparc can be done later.
> 
> Thanks,
> Paul
> 
> ?On 11/21/19, 9:04 PM, "Martin Balao" <mbalao at redhat.com> wrote:
> 
>     Hi Paul,
> 
>     On 11/21/19 12:48 PM, Hohensee, Paul wrote:
>     > You should be able to build a 32-bit linux jdk and test it on x32.
> 
>     The following tests are passing in x86 32 bits (Linux):
> 
>      * jdk/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java
> 
>     The following tests are failing in x86 32 bits (Linux):
> 
>      * hotspot/test/compiler/7184394/TestAESMain.java
> 
>     The reason why TestAESMain fails is that there is a known bug fixed by
>     8130341 [1]. I've applied my 8u backport of 8130341 [1] and can confirm
>     that the test passes. So I suggest not to block the 8u backport of
>     8073108 and proceed with a 8u backport of 8130341 thereafter.
> 
>     Note: a 8u backport of 8130341 has been proposed by Yuri Gaevsky here:
>     http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> October/010437.html This
>     backport is identical to mine (except for the commit headers which were
>     not included in Yuri's patch).
> 
>     Thanks,
>     Martin.-
> 
>     --
>     [1] - https://bugs.openjdk.java.net/browse/JDK-8130341
> 
> 


From hohensee at amazon.com  Fri Nov 22 17:31:30 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Nov 2019 17:31:30 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <VI1PR0201MB2479535F33371F8F7984325A9A490@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>
 <9435D6B0-AB58-4181-9C97-5AAACE857B71@amazon.com>
 <VI1PR0201MB2479535F33371F8F7984325A9A490@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <C425677D-6C6F-4705-8509-45F3B369B526@amazon.com>

Thanks, Martin. Looking forward to the result.

?On 11/22/19, 8:16 AM, "Doerr, Martin" <martin.doerr at sap.com> wrote:

    Hi Paul,
    
    I've put the patches into our nightly tests. Jdk8u tests are supposed to run over the weekend.
    I'll check if I can get a result from SPARC on Monday morning.
    
    Best regards,
    Martin
    
    
    > -----Original Message-----
    > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
    > Hohensee, Paul
    > Sent: Freitag, 22. November 2019 17:07
    > To: Martin Balao <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
    > Subject: [DMARC FAILURE] Re: [8u] RFR 8073108: Use x86 and SPARC CPU
    > instructions for GHASH acceleration
    > 
    > I'm fine with your proposal to go ahead with 8073108 and do 8130341 next.
    > Now we just need sparc verification. If we don't get that in the next day or
    > two, then I'm ok with pushing just x32/64. Sparc can be done later.
    > 
    > Thanks,
    > Paul
    > 
    > On 11/21/19, 9:04 PM, "Martin Balao" <mbalao at redhat.com> wrote:
    > 
    >     Hi Paul,
    > 
    >     On 11/21/19 12:48 PM, Hohensee, Paul wrote:
    >     > You should be able to build a 32-bit linux jdk and test it on x32.
    > 
    >     The following tests are passing in x86 32 bits (Linux):
    > 
    >      * jdk/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java
    > 
    >     The following tests are failing in x86 32 bits (Linux):
    > 
    >      * hotspot/test/compiler/7184394/TestAESMain.java
    > 
    >     The reason why TestAESMain fails is that there is a known bug fixed by
    >     8130341 [1]. I've applied my 8u backport of 8130341 [1] and can confirm
    >     that the test passes. So I suggest not to block the 8u backport of
    >     8073108 and proceed with a 8u backport of 8130341 thereafter.
    > 
    >     Note: a 8u backport of 8130341 has been proposed by Yuri Gaevsky here:
    >     http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
    > October/010437.html This
    >     backport is identical to mine (except for the commit headers which were
    >     not included in Yuri's patch).
    > 
    >     Thanks,
    >     Martin.-
    > 
    >     --
    >     [1] - https://bugs.openjdk.java.net/browse/JDK-8130341
    > 
    > 
    
    


From bourges.laurent at gmail.com  Fri Nov 22 20:14:57 2019
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 22 Nov 2019 21:14:57 +0100
Subject: Marlin renderer patches for jdk8u integration
In-Reply-To: <CAKjRUT4w7UJFEGLLOtO6nSL0vXOG5Sn6=XSQP4fGw6bU_NiG0Q@mail.gmail.com>
References: <CAKjRUT5icDxqgoccXo7mKoOPaNHbPzr=k6VnSpnXZV9CXE5UXA@mail.gmail.com>
 <CAP7YuAQqqSESZOBWnM8OGigwxHtvMtsa95kGzrVVgTWRf9QhTw@mail.gmail.com>
 <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com>
 <E87553A0-E753-4B2C-A067-2F19BA2A14C4@amazon.com>
 <CAKjRUT6x_DK1QVa9zF+UQKVoOvjX=j_soWvew2YPKfwOd01eaw@mail.gmail.com>
 <2778b8a8-2178-4f41-49c0-80475423bb47@amazon.com>
 <CAKjRUT4w7UJFEGLLOtO6nSL0vXOG5Sn6=XSQP4fGw6bU_NiG0Q@mail.gmail.com>
Message-ID: <CAKjRUT5raVm1EeFqd8Ea9UuSZUGXy1M8EtZmpWsNSVuchgobvA@mail.gmail.com>

Hi David,

I tested on my windows 10 machine but the given MarlinTest looks the same
either with Pisces or with latest Marlin 0.9.4 (github).
I enabled tracing with -Dsun.java2d.trace=log
-Dsun.java2d.renderer.trace=true but it shows no call to the Marlin
renderer, only:

OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)

sun.java2d.pisces.PiscesRenderingEngine.getMinimumAAPenSize()
D3DFillRect
D3DFillRect

echo "Original"
java -Dsun.java2d.trace=log -Dsun.java2d.renderer.trace=true -cp .
MarlinTest 11

echo "Marlin 0.9.4"
REM -Dsun.java2d.dpiaware=false
java -Dsun.java2d.trace=log -Dsun.java2d.renderer.trace=true
-Xbootclasspath/a:./marlin-0.9.4.2-Unsafe.jar
-Xbootclasspath/p:./:marlin-0.9.4.2-Unsafe-sun-java2d.jar
-Dsun.java2d.renderer=org.marlin.pisces.DMarlinRenderingEngine -cp .
MarlinTest 11

It seems Choice widgets are adjusted to the available window height, so it
fills the space accordingly.
According to me, it is not related to the Marlin renderer by this patch.

PS: If anybody else has another opinion or test case, it would be great.

Regards,
Laurent

Le jeu. 14 nov. 2019 ? 13:54, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Hi David,
>
> Thanks for testing the Marlin renderer patches, it looks quite good.
>
> Sorry for my late response, I expected to test myself on a windows
> machine, but still not.
>
> I wonder why the 1px difference on windows awt widgets has not been yet
> reported.
> Phil or Sergey, are you aware of such issue ? How are awt widgets rendered
> ? How can the java2d renderer interfere in such way ?
> Is it related to fractional scaling factors ?
>
> I will try using awt/2d debug settings to get more details...
>
> Laurent
>
> Le ven. 8 nov. 2019 ? 02:32, David Alvarez <alvdavi at amazon.com> a ?crit :
>
>> Hi,
>>
>> We?ve run the TCK with Marlin enabled, certification passes. So far so
>> good.
>>
>> Then, in some of our additional testing we noticed small differences in
>> the rendering of some components.
>>
>> The simplest example we?ve been able to find is the java.awt.Choice in
>> Windows 10. When using a JDK with the patches applied, this component
>> will be rendered with one extra height pixel.
>>
>> I've uploaded some images for comparison. Here[1] is how the component
>> is displayed using 8u232, and here[2], how it looks when using a version
>> of 8u232 that contains your patches. The difference is noticeable when
>> we put the components side by side[3], more so if we zoom in[4].
>>
>> This can also cause a one-pixel overlap when these components are
>> rendered on a vertical box layout[5].
>>
>> The behavior persisted even when changing the rendering engine back to
>> Pisces, so it seems it is caused by changes outside Marlin, most likely
>> on AAShapePipeline.
>>
>> The new behavior is consistent with JDK11, but it still worries me a
>> little. Any idea why this is happening? If you want, I can provide you
>> with a sample program and compared images.
>>
>> For reference, I've also updated the code used during the images[6]
>>
>> --
>> David Alvarez
>>
>> [1] http://cr.openjdk.java.net/~alvdavi/emails/marlin/vanilla.png
>> [2] http://cr.openjdk.java.net/~alvdavi/emails/marlin/marlin.png
>> [3] http://cr.openjdk.java.net/~alvdavi/emails/marlin/comparison.png
>> [4] http://cr.openjdk.java.net/~alvdavi/emails/marlin/detail.png
>> [5] http://cr.openjdk.java.net/~alvdavi/emails/marlin/multiple.png
>> [6] http://cr.openjdk.java.net/~alvdavi/emails/marlin/MarlinTest.java
>>
>>
>>
>> On 2019-11-05 02:40, Laurent Bourg?s wrote:
>> > Hi Paul
>> >
>> > Le lun. 4 nov. 2019 ? 20:30, Hohensee, Paul <hohensee at amazon.com
>> > <mailto:hohensee at amazon.com>> a ?crit :
>> >
>> >     Also, we (Amazon) would like the Marlin renderer enabled by default,
>> >     just as it is for Zulu. It's been well-tested starting in 9, plus I
>> >     doubt it'll get much, if any, use in u242 if we e.g. disable it for
>> >     u242 and then enable it for u252.
>> >
>> >     Please put the patches on cr.openjdk.java.net
>> >     <http://cr.openjdk.java.net> so we can go through a normal review
>> >     process.
>> >
>> >
>> > I uploaded all patch files (m01 to m21):
>> > http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/
>> >
>> > Laurent
>>
>>

From verghese at amazon.com  Fri Nov 22 22:04:36 2019
From: verghese at amazon.com (Verghese, Clive)
Date: Fri, 22 Nov 2019 22:04:36 +0000
Subject: [8u] RFR: 8218580: endpoint identification algorithm should be
 case-insensitive
In-Reply-To: <A4E5FBC3-35A2-4AC4-BC7F-35FB55889333@amazon.com>
References: <7B408184-7E67-4185-A595-8C92303D2B0D@amazon.com>
 <A4E5FBC3-35A2-4AC4-BC7F-35FB55889333@amazon.com>
Message-ID: <B1F2622D-084A-4303-B2AD-71F8D5CE6C9D@amazon.com>

Hi Paul,

Thank you for reviewing the change. 

The hunks in the TIP were added by JBS-Issue JDK-8208209 [rev 52170].
8208209: Improve TLS connection stability again
Reviewed-by: xuelei

Though the same JBS issue was not backported,
similar changeset exists in JDK-8 (JDK-8202613) [rev 13244].
8202613: Improve TLS connections stability
Reviewed-by: xuelei, wetmore

It looks like the hunks on line 1036 does not apply to JDK-8

Regards,
Clive Verghese

?On 11/18/19, 3:56 PM, "Hohensee, Paul" <hohensee at amazon.com> wrote:

    If the code in the hunk that didn't apply is ever backported, context will be lost and incompatible code will result. Better to find the patch referenced by that hunk and backport it.
    
    Thanks,
    
    Paul
    
    On 10/31/19, 10:00 AM, "jdk8u-dev on behalf of Verghese, Clive" <jdk8u-dev-bounces at openjdk.java.net on behalf of verghese at amazon.com> wrote:
    
        Hi,
        
        I am requesting review for backport of JDK-8218580
        
        Webrev : http://cr.openjdk.java.net/~phh/8218580/webrev.8u.00/
        
        JBS Bug : https://bugs.openjdk.java.net/browse/JDK-8218580
        Original Change : http://hg.openjdk.java.net/jdk/jdk/rev/c34acb3a3330
        Change Set for JDK 11 : http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/148957581f5c
        
        The JBS Bug marks the issue as Introduced in 11. But checking the 8u code, it looks like the bug is effecting 8u as well.
        
        The backport to 8u did not apply cleanly. Other than the filename changes and line number changes, one of the notable changes is that only 2 of the 3 hunks applied in ClientHandshaker.java.
        
        The patch has passed tier-1 in Linux and no new regressions were found.
        
        Regards,
        Clive Verghese
        
    
    


From mbalao at redhat.com  Fri Nov 22 22:46:00 2019
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 22 Nov 2019 19:46:00 -0300
Subject: [8u] RFR 8233404: System property to set the number of PBE iterations
 in JCEKS keystores
Message-ID: <54410068-9232-771a-238f-1e7ca1f56c6e@redhat.com>

Hi,

I'd like to have a review for the 8u backport of 8233404 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8233404/8233404.8u.jdk.webrev.00/

Changes from JDK baseline patch:

 * Path changes

 * test/com/sun/crypto/provider/KeyProtector/IterationCount.java
  * Changed "OutputAnalyzer" and "ProcessTools" imports to
"jdk.testlibrary..."
  * Changed @library tag to "/lib/testlibrary"

 * Populated java.security change to java.security-<OS> files

Testing:

 * test/com/sun/crypto/provider/KeyProtector/IterationCount.java
  * Passes

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8233404


From hohensee at amazon.com  Fri Nov 22 23:25:37 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Nov 2019 23:25:37 +0000
Subject: [8u] RFR 8233404: System property to set the number of PBE
 iterations in JCEKS keystores
In-Reply-To: <54410068-9232-771a-238f-1e7ca1f56c6e@redhat.com>
References: <54410068-9232-771a-238f-1e7ca1f56c6e@redhat.com>
Message-ID: <3B1595A2-DFFF-4FB9-A957-753B6BFA261A@amazon.com>

Looks good.

Thanks,
Paul

?On 11/22/19, 2:47 PM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces at openjdk.java.net on behalf of mbalao at redhat.com> wrote:

    Hi,
    
    I'd like to have a review for the 8u backport of 8233404 [1].
    
    Webrev.00:
    
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8233404/8233404.8u.jdk.webrev.00/
    
    Changes from JDK baseline patch:
    
     * Path changes
    
     * test/com/sun/crypto/provider/KeyProtector/IterationCount.java
      * Changed "OutputAnalyzer" and "ProcessTools" imports to
    "jdk.testlibrary..."
      * Changed @library tag to "/lib/testlibrary"
    
     * Populated java.security change to java.security-<OS> files
    
    Testing:
    
     * test/com/sun/crypto/provider/KeyProtector/IterationCount.java
      * Passes
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8233404
    
    


From martin.doerr at sap.com  Mon Nov 25 10:48:18 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 25 Nov 2019 10:48:18 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <VI1PR0201MB2479535F33371F8F7984325A9A490@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>
 <9435D6B0-AB58-4181-9C97-5AAACE857B71@amazon.com>
 <VI1PR0201MB2479535F33371F8F7984325A9A490@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <VI1PR0201MB2479DF8DD01267B8F0210CD79A4A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>

Tests on SPARC were successful. No issues found.

Best regards,
Martin


> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Doerr, Martin
> Sent: Freitag, 22. November 2019 17:15
> To: Hohensee, Paul <hohensee at amazon.com>; Martin Balao
> <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
> Subject: [CAUTION] RE: [8u] RFR 8073108: Use x86 and SPARC CPU
> instructions for GHASH acceleration
> 
> Hi Paul,
> 
> I've put the patches into our nightly tests. Jdk8u tests are supposed to run
> over the weekend.
> I'll check if I can get a result from SPARC on Monday morning.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> > Hohensee, Paul
> > Sent: Freitag, 22. November 2019 17:07
> > To: Martin Balao <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
> > Subject: [DMARC FAILURE] Re: [8u] RFR 8073108: Use x86 and SPARC CPU
> > instructions for GHASH acceleration
> >
> > I'm fine with your proposal to go ahead with 8073108 and do 8130341 next.
> > Now we just need sparc verification. If we don't get that in the next day or
> > two, then I'm ok with pushing just x32/64. Sparc can be done later.
> >
> > Thanks,
> > Paul
> >
> > ?On 11/21/19, 9:04 PM, "Martin Balao" <mbalao at redhat.com> wrote:
> >
> >     Hi Paul,
> >
> >     On 11/21/19 12:48 PM, Hohensee, Paul wrote:
> >     > You should be able to build a 32-bit linux jdk and test it on x32.
> >
> >     The following tests are passing in x86 32 bits (Linux):
> >
> >      * jdk/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java
> >
> >     The following tests are failing in x86 32 bits (Linux):
> >
> >      * hotspot/test/compiler/7184394/TestAESMain.java
> >
> >     The reason why TestAESMain fails is that there is a known bug fixed by
> >     8130341 [1]. I've applied my 8u backport of 8130341 [1] and can confirm
> >     that the test passes. So I suggest not to block the 8u backport of
> >     8073108 and proceed with a 8u backport of 8130341 thereafter.
> >
> >     Note: a 8u backport of 8130341 has been proposed by Yuri Gaevsky here:
> >     http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> > October/010437.html This
> >     backport is identical to mine (except for the commit headers which were
> >     not included in Yuri's patch).
> >
> >     Thanks,
> >     Martin.-
> >
> >     --
> >     [1] - https://bugs.openjdk.java.net/browse/JDK-8130341
> >
> >


From hohensee at amazon.com  Mon Nov 25 16:54:29 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 25 Nov 2019 16:54:29 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <VI1PR0201MB2479DF8DD01267B8F0210CD79A4A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <e9dc2b5d-67d9-2cdf-992e-7b0023e695dc@redhat.com>
 <9435D6B0-AB58-4181-9C97-5AAACE857B71@amazon.com>
 <VI1PR0201MB2479535F33371F8F7984325A9A490@VI1PR0201MB2479.eurprd02.prod.outlook.com>
 <VI1PR0201MB2479DF8DD01267B8F0210CD79A4A0@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <7E5BFC01-AD11-4791-8ACB-30422B54E5BD@amazon.com>

Then we're good to go!

?On 11/25/19, 2:48 AM, "Doerr, Martin" <martin.doerr at sap.com> wrote:

    Tests on SPARC were successful. No issues found.
    
    Best regards,
    Martin
    
    
    > -----Original Message-----
    > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
    > Doerr, Martin
    > Sent: Freitag, 22. November 2019 17:15
    > To: Hohensee, Paul <hohensee at amazon.com>; Martin Balao
    > <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
    > Subject: [CAUTION] RE: [8u] RFR 8073108: Use x86 and SPARC CPU
    > instructions for GHASH acceleration
    > 
    > Hi Paul,
    > 
    > I've put the patches into our nightly tests. Jdk8u tests are supposed to run
    > over the weekend.
    > I'll check if I can get a result from SPARC on Monday morning.
    > 
    > Best regards,
    > Martin
    > 
    > 
    > > -----Original Message-----
    > > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
    > > Hohensee, Paul
    > > Sent: Freitag, 22. November 2019 17:07
    > > To: Martin Balao <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
    > > Subject: [DMARC FAILURE] Re: [8u] RFR 8073108: Use x86 and SPARC CPU
    > > instructions for GHASH acceleration
    > >
    > > I'm fine with your proposal to go ahead with 8073108 and do 8130341 next.
    > > Now we just need sparc verification. If we don't get that in the next day or
    > > two, then I'm ok with pushing just x32/64. Sparc can be done later.
    > >
    > > Thanks,
    > > Paul
    > >
    > > On 11/21/19, 9:04 PM, "Martin Balao" <mbalao at redhat.com> wrote:
    > >
    > >     Hi Paul,
    > >
    > >     On 11/21/19 12:48 PM, Hohensee, Paul wrote:
    > >     > You should be able to build a 32-bit linux jdk and test it on x32.
    > >
    > >     The following tests are passing in x86 32 bits (Linux):
    > >
    > >      * jdk/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java
    > >
    > >     The following tests are failing in x86 32 bits (Linux):
    > >
    > >      * hotspot/test/compiler/7184394/TestAESMain.java
    > >
    > >     The reason why TestAESMain fails is that there is a known bug fixed by
    > >     8130341 [1]. I've applied my 8u backport of 8130341 [1] and can confirm
    > >     that the test passes. So I suggest not to block the 8u backport of
    > >     8073108 and proceed with a 8u backport of 8130341 thereafter.
    > >
    > >     Note: a 8u backport of 8130341 has been proposed by Yuri Gaevsky here:
    > >     http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
    > > October/010437.html This
    > >     backport is identical to mine (except for the commit headers which were
    > >     not included in Yuri's patch).
    > >
    > >     Thanks,
    > >     Martin.-
    > >
    > >     --
    > >     [1] - https://bugs.openjdk.java.net/browse/JDK-8130341
    > >
    > >
    
    


From maoliang.ml at alibaba-inc.com  Tue Nov 26 08:19:21 2019
From: maoliang.ml at alibaba-inc.com (Liang Mao)
Date: Tue, 26 Nov 2019 16:19:21 +0800
Subject: =?UTF-8?B?Wzh1XSBSRlIgZm9yIGJhY2twb3J0IG9mIDgxNTYwMjg6IEcxWW91bmdHZW5TaXplciBfYWRh?=
 =?UTF-8?B?cHRpdmVfc2l6ZSBub3QgY29ycmVjdCB3aGVuIHNldHRpbmcgTmV3U2l6ZSBhbmQgTWF4TmV3?=
 =?UTF-8?B?U2l6ZSB0byB0aGUgc2FtZSB2YWx1ZQ==?=
In-Reply-To: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.>
References: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.>
Message-ID: <a30001c8-4c54-4726-810e-fbcbf1a24448.maoliang.ml@alibaba-inc.com>

Hi,
Original bug:
 https://bugs.openjdk.java.net/browse/JDK-8156028
 http://hg.openjdk.java.net/jdk/jdk/rev/ba8be1a71dec

Original patch does not apply cleanly to 8u, because class G1YoungGenSizer has been
moved to seperated file.

Since G1 is already a stable feature in JDK8U, the obvious bug that the young gen size
cannot be adaptive with different NewSize and MaxNewSize makes users confused. The
alternative way to use experimental option *G1NewSizePercent* is not intuitive and formal.

8u webrev:
 http://cr.openjdk.java.net/~ddong/8156028/webrev.00/
Testing: x86_64 build, affected tests, tier1
Thanks,
Liang


From ygaevsky at azul.com  Tue Nov 26 10:24:54 2019
From: ygaevsky at azul.com (Yuri Gaevsky)
Date: Tue, 26 Nov 2019 10:24:54 +0000
Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
 AEADBadTagException"
In-Reply-To: <23a785bdd5604f33b2b2c1fb54ea3547@azul.com>
References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com>
 <23a785bdd5604f33b2b2c1fb54ea3547@azul.com>
Message-ID: <8791ec11a0134598b7e7d40b9e46ba1a@azul.com>

Since SPARC testing for 8073108 (thanks a lot, Martin!) is now completed,
can we have the 8130341 backport reviewed too?

Thanks,
-Yuri

-----Original Message-----
From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf Of Yuri Gaevsky
Sent: Monday, October 28, 2019 05:13 PM
To: jdk8u-dev at openjdk.java.net
Subject: FW: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException"

ping.

-----Original Message-----
From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf Of Yuri Gaevsky
Sent: Thursday, October 10, 2019 12:52 PM
To: jdk8u-dev at openjdk.java.net
Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException"

Hello,

Please approve backport of JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException"
to jdk8u which is a required follow-up fix for the issue mentioned in [1].

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

JDK9 review thread:
  http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018402.html
JDK9 changeset:
  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/36fd5d1982b0

Webrev:
  http://cr.openjdk.java.net/~ygaevsky/8130341.8u/webrev.hotspot/
  NB: The original change for JDK9 does apply cleanly to jdk8u codebase w/
  minor correction to the test path (test/compiler/codegen/7184394/ -->
  test/compiler/7184394/).

Testing:
  windows-i586: (known failures mentioned in [1] are gone)
  windows-x64:
    JTREG tests: 
      (jdk8u) hotspot/test/compiler/7184394/
      (jdk8u) jdk/test/com/sun/crypto/provider/Cipher/AES/
    (also checked the output from TestAESMain for performance improvements w/
     -XX:+UseGHASHIntrinsics)
    
Thank you,
-Yuri Gaevsky, Azul Systems, Inc.

[1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010409.html


From yan at azul.com  Tue Nov 26 12:46:34 2019
From: yan at azul.com (Yuri Nesterenko)
Date: Tue, 26 Nov 2019 15:46:34 +0300
Subject: [8u] RFR 8185898: setRequestProperty(key, null) results in HTTP
 header without colon in request
Message-ID: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com>

Hi,

please review this request for a backport to 8u.

Original issue:

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

??? https://hg.openjdk.java.net/jdk/jdk/rev/0211b062843d

The patch itself applied good enough; I had to adapt the test for JDK8.

Look for webrev here:

??? http://cr.openjdk.java.net/~yan/8185898/webrev.0/

Thank you!

--yan



From martin.doerr at sap.com  Tue Nov 26 13:55:57 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 26 Nov 2019 13:55:57 +0000
Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
 AEADBadTagException"
In-Reply-To: <8791ec11a0134598b7e7d40b9e46ba1a@azul.com>
References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com>
 <23a785bdd5604f33b2b2c1fb54ea3547@azul.com>
 <8791ec11a0134598b7e7d40b9e46ba1a@azul.com>
Message-ID: <VI1PR0201MB247974863DF96B6A2BBB71969A450@VI1PR0201MB2479.eurprd02.prod.outlook.com>

Hi Yuri,

reviewed and added jdk8u-fix-request.

Best regards,
Martin


> -----Original Message-----
> From: Yuri Gaevsky <ygaevsky at azul.com>
> Sent: Dienstag, 26. November 2019 11:25
> To: jdk8u-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> Subject: RE: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> 
> Since SPARC testing for 8073108 (thanks a lot, Martin!) is now completed,
> can we have the 8130341 backport reviewed too?
> 
> Thanks,
> -Yuri
> 
> -----Original Message-----
> From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf
> Of Yuri Gaevsky
> Sent: Monday, October 28, 2019 05:13 PM
> To: jdk8u-dev at openjdk.java.net
> Subject: FW: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> 
> ping.
> 
> -----Original Message-----
> From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf
> Of Yuri Gaevsky
> Sent: Thursday, October 10, 2019 12:52 PM
> To: jdk8u-dev at openjdk.java.net
> Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> 
> Hello,
> 
> Please approve backport of JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> to jdk8u which is a required follow-up fix for the issue mentioned in [1].
> 
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8130341
> 
> JDK9 review thread:
>   http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-
> July/018402.html
> JDK9 changeset:
>   http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/36fd5d1982b0
> 
> Webrev:
>   http://cr.openjdk.java.net/~ygaevsky/8130341.8u/webrev.hotspot/
>   NB: The original change for JDK9 does apply cleanly to jdk8u codebase w/
>   minor correction to the test path (test/compiler/codegen/7184394/ -->
>   test/compiler/7184394/).
> 
> Testing:
>   windows-i586: (known failures mentioned in [1] are gone)
>   windows-x64:
>     JTREG tests:
>       (jdk8u) hotspot/test/compiler/7184394/
>       (jdk8u) jdk/test/com/sun/crypto/provider/Cipher/AES/
>     (also checked the output from TestAESMain for performance
> improvements w/
>      -XX:+UseGHASHIntrinsics)
> 
> Thank you,
> -Yuri Gaevsky, Azul Systems, Inc.
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> October/010409.html


From hohensee at amazon.com  Tue Nov 26 14:20:47 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Nov 2019 14:20:47 +0000
Subject: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size
 not correct when setting NewSize and MaxNewSize to the same value
In-Reply-To: <a30001c8-4c54-4726-810e-fbcbf1a24448.maoliang.ml@alibaba-inc.com>
References: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.>
 <a30001c8-4c54-4726-810e-fbcbf1a24448.maoliang.ml@alibaba-inc.com>
Message-ID: <8025BB5B-2F5D-42F2-A075-FB30782E4205@amazon.com>

This looks fine, except that it would be good to add a newline after the declaration of _adaptive_size to match the original patch.

Thanks,
Paul

?On 11/26/19, 12:20 AM, "jdk8u-dev on behalf of Liang Mao" <jdk8u-dev-bounces at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote:

    Hi,
    Original bug:
     https://bugs.openjdk.java.net/browse/JDK-8156028
     http://hg.openjdk.java.net/jdk/jdk/rev/ba8be1a71dec
    
    Original patch does not apply cleanly to 8u, because class G1YoungGenSizer has been
    moved to seperated file.
    
    Since G1 is already a stable feature in JDK8U, the obvious bug that the young gen size
    cannot be adaptive with different NewSize and MaxNewSize makes users confused. The
    alternative way to use experimental option *G1NewSizePercent* is not intuitive and formal.
    
    8u webrev:
     http://cr.openjdk.java.net/~ddong/8156028/webrev.00/
    Testing: x86_64 build, affected tests, tier1
    Thanks,
    Liang
    
    


From ygaevsky at azul.com  Tue Nov 26 14:28:18 2019
From: ygaevsky at azul.com (Yuri Gaevsky)
Date: Tue, 26 Nov 2019 14:28:18 +0000
Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
 AEADBadTagException"
In-Reply-To: <VI1PR0201MB247974863DF96B6A2BBB71969A450@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com>
 <23a785bdd5604f33b2b2c1fb54ea3547@azul.com>
 <8791ec11a0134598b7e7d40b9e46ba1a@azul.com>
 <VI1PR0201MB247974863DF96B6A2BBB71969A450@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <b453767295d947c4ac047f00bf9f7b61@azul.com>

Thank you very much, Martin.

-Yuri

-----Original Message-----
From: Doerr, Martin [mailto:martin.doerr at sap.com] 
Sent: Tuesday, November 26, 2019 04:56 PM
To: Yuri Gaevsky <ygaevsky at azul.com>; jdk8u-dev at openjdk.java.net
Subject: RE: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException"

Hi Yuri,

reviewed and added jdk8u-fix-request.

Best regards,
Martin


> -----Original Message-----
> From: Yuri Gaevsky <ygaevsky at azul.com>
> Sent: Dienstag, 26. November 2019 11:25
> To: jdk8u-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> Subject: RE: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> 
> Since SPARC testing for 8073108 (thanks a lot, Martin!) is now completed,
> can we have the 8130341 backport reviewed too?
> 
> Thanks,
> -Yuri
> 
> -----Original Message-----
> From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf
> Of Yuri Gaevsky
> Sent: Monday, October 28, 2019 05:13 PM
> To: jdk8u-dev at openjdk.java.net
> Subject: FW: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> 
> ping.
> 
> -----Original Message-----
> From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf
> Of Yuri Gaevsky
> Sent: Thursday, October 10, 2019 12:52 PM
> To: jdk8u-dev at openjdk.java.net
> Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> 
> Hello,
> 
> Please approve backport of JDK-8130341 "GHASH 32bit intrinsics has
> AEADBadTagException"
> to jdk8u which is a required follow-up fix for the issue mentioned in [1].
> 
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8130341
> 
> JDK9 review thread:
>   http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-
> July/018402.html
> JDK9 changeset:
>   http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/36fd5d1982b0
> 
> Webrev:
>   http://cr.openjdk.java.net/~ygaevsky/8130341.8u/webrev.hotspot/
>   NB: The original change for JDK9 does apply cleanly to jdk8u codebase w/
>   minor correction to the test path (test/compiler/codegen/7184394/ -->
>   test/compiler/7184394/).
> 
> Testing:
>   windows-i586: (known failures mentioned in [1] are gone)
>   windows-x64:
>     JTREG tests:
>       (jdk8u) hotspot/test/compiler/7184394/
>       (jdk8u) jdk/test/com/sun/crypto/provider/Cipher/AES/
>     (also checked the output from TestAESMain for performance
> improvements w/
>      -XX:+UseGHASHIntrinsics)
> 
> Thank you,
> -Yuri Gaevsky, Azul Systems, Inc.
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> October/010409.html


From sgehwolf at redhat.com  Tue Nov 26 14:37:48 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 26 Nov 2019 15:37:48 +0100
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <1bcabbd834f443ad957abf93d92568d1@azul.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <2b4eeccd689049cfaed69e80523e720e@azul.com>
 <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
 <1bcabbd834f443ad957abf93d92568d1@azul.com>
Message-ID: <dec01a50124089580f1c89521e323330ccf0c172.camel@redhat.com>

Hi,

On Fri, 2019-11-22 at 13:30 +0000, Yuri Gaevsky wrote:
> Hi Martin,
> 
> > I didn't know you have already proposed a backport for this bug. I
> > assumed nobody did because the ticket was not flagged with
> > "jdk8u-fix-request". Sorry.

If somebody is working on a backport it should be noted as such in the
bug comments. jdk8u-fix-request is for flagging the bug to maintainers
for approval.

> There is no need to apologise, it's great to finally see the review for JDK-8073108
> is progressing. :-)
> 
> IIUC, the marking of the appropriate JBS issue with 'jdk8u-fix-request' is the *next step*
> in the backporting process. 

Yes, that's the process which should be followed in general.

If unsure whether it's worth backporting a fix, due to it being large
and/or risky, feedback can be solicited on the mailing list. Consider
CC'ing maintainers once a consensus has been reached.

Thanks,
Severin


From ygaevsky at azul.com  Tue Nov 26 14:46:29 2019
From: ygaevsky at azul.com (Yuri Gaevsky)
Date: Tue, 26 Nov 2019 14:46:29 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <dec01a50124089580f1c89521e323330ccf0c172.camel@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <2b4eeccd689049cfaed69e80523e720e@azul.com>
 <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
 <1bcabbd834f443ad957abf93d92568d1@azul.com>
 <dec01a50124089580f1c89521e323330ccf0c172.camel@redhat.com>
Message-ID: <45f81c95c67946bf9c5fe14f8a299b01@azul.com>

Thank you for the clarifications, Severin.

-Yuri

-----Original Message-----
From: Severin Gehwolf [mailto:sgehwolf at redhat.com] 
Sent: Tuesday, November 26, 2019 05:38 PM
To: Yuri Gaevsky <ygaevsky at azul.com>; Martin Balao <mbalao at redhat.com>; jdk8u-dev at openjdk.java.net
Subject: Re: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration

Hi,

On Fri, 2019-11-22 at 13:30 +0000, Yuri Gaevsky wrote:
> Hi Martin,
> 
> > I didn't know you have already proposed a backport for this bug. I
> > assumed nobody did because the ticket was not flagged with
> > "jdk8u-fix-request". Sorry.

If somebody is working on a backport it should be noted as such in the
bug comments. jdk8u-fix-request is for flagging the bug to maintainers
for approval.

> There is no need to apologise, it's great to finally see the review for JDK-8073108
> is progressing. :-)
> 
> IIUC, the marking of the appropriate JBS issue with 'jdk8u-fix-request' is the *next step*
> in the backporting process. 

Yes, that's the process which should be followed in general.

If unsure whether it's worth backporting a fix, due to it being large
and/or risky, feedback can be solicited on the mailing list. Consider
CC'ing maintainers once a consensus has been reached.

Thanks,
Severin

From hohensee at amazon.com  Tue Nov 26 16:40:27 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Nov 2019 16:40:27 +0000
Subject: [8u] RFR 8185898: setRequestProperty(key, null) results in HTTP
 header without colon in request
In-Reply-To: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com>
References: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com>
Message-ID: <30DE2ACB-3E4E-43C2-AEFD-54D396303B8D@amazon.com>

Looks fine, except remove the @modules comment from the test, because there are no modules in 8.

Thanks,
Paul

?On 11/26/19, 4:47 AM, "jdk8u-dev on behalf of Yuri Nesterenko" <jdk8u-dev-bounces at openjdk.java.net on behalf of yan at azul.com> wrote:

    Hi,
    
    please review this request for a backport to 8u.
    
    Original issue:
    
        https://bugs.openjdk.java.net/browse/JDK-8185898
    
        https://hg.openjdk.java.net/jdk/jdk/rev/0211b062843d
    
    The patch itself applied good enough; I had to adapt the test for JDK8.
    
    Look for webrev here:
    
        http://cr.openjdk.java.net/~yan/8185898/webrev.0/
    
    Thank you!
    
    --yan
    
    
    


From yan at azul.com  Wed Nov 27 06:35:54 2019
From: yan at azul.com (Yuri Nesterenko)
Date: Wed, 27 Nov 2019 09:35:54 +0300
Subject: [8u] RFR 8185898: setRequestProperty(key, null) results in HTTP
 header without colon in request
In-Reply-To: <30DE2ACB-3E4E-43C2-AEFD-54D396303B8D@amazon.com>
References: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com>
 <30DE2ACB-3E4E-43C2-AEFD-54D396303B8D@amazon.com>
Message-ID: <5bbf2515-34eb-7e82-1b5e-492191bf8fcf@azul.com>

Oops, indeed. Thank you Paul!

For consistency, resent
http://cr.openjdk.java.net/~yan/8185898/webrev.1/ without that comment.

--yan

On 26.11.2019 19:40, Hohensee, Paul wrote:
> Looks fine, except remove the @modules comment from the test, because there are no modules in 8.
>
> Thanks,
> Paul
>
> ?On 11/26/19, 4:47 AM, "jdk8u-dev on behalf of Yuri Nesterenko" <jdk8u-dev-bounces at openjdk.java.net on behalf of yan at azul.com> wrote:
>
>     Hi,
>     
>     please review this request for a backport to 8u.
>     
>     Original issue:
>     
>         https://bugs.openjdk.java.net/browse/JDK-8185898
>     
>         https://hg.openjdk.java.net/jdk/jdk/rev/0211b062843d
>     
>     The patch itself applied good enough; I had to adapt the test for JDK8.
>     
>     Look for webrev here:
>     
>         http://cr.openjdk.java.net/~yan/8185898/webrev.0/
>     
>     Thank you!
>     
>     --yan
>     
>     
>     
>


From maoliang.ml at alibaba-inc.com  Wed Nov 27 07:33:40 2019
From: maoliang.ml at alibaba-inc.com (Liang Mao)
Date: Wed, 27 Nov 2019 15:33:40 +0800
Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGZvciBiYWNrcG9ydCBvZiA4MTU2MDI4OiBHMVlvdW5nR2VuU2l6ZXIg?=
 =?UTF-8?B?X2FkYXB0aXZlX3NpemUgbm90IGNvcnJlY3Qgd2hlbiBzZXR0aW5nIE5ld1NpemUgYW5kIE1h?=
 =?UTF-8?B?eE5ld1NpemUgdG8gdGhlIHNhbWUgdmFsdWU=?=
In-Reply-To: <8025BB5B-2F5D-42F2-A075-FB30782E4205@amazon.com>
References: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.>
 <a30001c8-4c54-4726-810e-fbcbf1a24448.maoliang.ml@alibaba-inc.com>,
 <8025BB5B-2F5D-42F2-A075-FB30782E4205@amazon.com>
Message-ID: <b459d133-617c-4410-9a6a-89da4c2fada2.maoliang.ml@alibaba-inc.com>

Hi Paul,

The webrev is updated. Since I'm not a committer, could you please help to push?
http://cr.openjdk.java.net/~ddong/8156028/webrev.00/

Thanks,
Liang


------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2019 Nov. 26 (Tue.) 22:20
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value

This looks fine, except that it would be good to add a newline after the declaration of _adaptive_size to match the original patch.

Thanks,
Paul

 On 11/26/19, 12:20 AM, "jdk8u-dev on behalf of Liang Mao" <jdk8u-dev-bounces at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote:

    Hi,
    Original bug:
https://bugs.openjdk.java.net/browse/JDK-8156028
http://hg.openjdk.java.net/jdk/jdk/rev/ba8be1a71dec

    Original patch does not apply cleanly to 8u, because class G1YoungGenSizer has been
    moved to seperated file.

    Since G1 is already a stable feature in JDK8U, the obvious bug that the young gen size
    cannot be adaptive with different NewSize and MaxNewSize makes users confused. The
    alternative way to use experimental option *G1NewSizePercent* is not intuitive and formal.

    8u webrev:
http://cr.openjdk.java.net/~ddong/8156028/webrev.00/
    Testing: x86_64 build, affected tests, tier1
    Thanks,
    Liang





From hohensee at amazon.com  Wed Nov 27 16:00:55 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 27 Nov 2019 16:00:55 +0000
Subject: [8u] RFR 8185898: setRequestProperty(key, null) results in HTTP
 header without colon in request
In-Reply-To: <5bbf2515-34eb-7e82-1b5e-492191bf8fcf@azul.com>
References: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com>
 <30DE2ACB-3E4E-43C2-AEFD-54D396303B8D@amazon.com>
 <5bbf2515-34eb-7e82-1b5e-492191bf8fcf@azul.com>
Message-ID: <3FF909F9-54E9-46A2-B9B0-CC33E540280D@amazon.com>

Looks good. :)

?On 11/26/19, 10:36 PM, "Yuri Nesterenko" <yan at azul.com> wrote:

    Oops, indeed. Thank you Paul!
    
    For consistency, resent
    http://cr.openjdk.java.net/~yan/8185898/webrev.1/ without that comment.
    
    --yan
    
    On 26.11.2019 19:40, Hohensee, Paul wrote:
    > Looks fine, except remove the @modules comment from the test, because there are no modules in 8.
    >
    > Thanks,
    > Paul
    >
    > On 11/26/19, 4:47 AM, "jdk8u-dev on behalf of Yuri Nesterenko" <jdk8u-dev-bounces at openjdk.java.net on behalf of yan at azul.com> wrote:
    >
    >     Hi,
    >     
    >     please review this request for a backport to 8u.
    >     
    >     Original issue:
    >     
    >         https://bugs.openjdk.java.net/browse/JDK-8185898
    >     
    >         https://hg.openjdk.java.net/jdk/jdk/rev/0211b062843d
    >     
    >     The patch itself applied good enough; I had to adapt the test for JDK8.
    >     
    >     Look for webrev here:
    >     
    >         http://cr.openjdk.java.net/~yan/8185898/webrev.0/
    >     
    >     Thank you!
    >     
    >     --yan
    >     
    >     
    >     
    >
    
    


From hohensee at amazon.com  Wed Nov 27 16:02:40 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 27 Nov 2019 16:02:40 +0000
Subject: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size
 not correct when setting NewSize and MaxNewSize to the same value
In-Reply-To: <b459d133-617c-4410-9a6a-89da4c2fada2.maoliang.ml@alibaba-inc.com>
References: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.>
 <a30001c8-4c54-4726-810e-fbcbf1a24448.maoliang.ml@alibaba-inc.com>
 <8025BB5B-2F5D-42F2-A075-FB30782E4205@amazon.com>
 <b459d133-617c-4410-9a6a-89da4c2fada2.maoliang.ml@alibaba-inc.com>
Message-ID: <17BE74B3-7CD5-4441-83F4-22EF3C210ED7@amazon.com>

I?d be happy to, but https://bugs.openjdk.java.net/browse/JDK-8156028 must be tagged with ?jdk8u-fix-yes? before I can do so.

Paul

From: Liang Mao <maoliang.ml at alibaba-inc.com>
Reply-To: Liang Mao <maoliang.ml at alibaba-inc.com>
Date: Tuesday, November 26, 2019 at 11:34 PM
To: "Hohensee, Paul" <hohensee at amazon.com>, jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value

Hi Paul,

The webrev is updated. Since I'm not a committer, could you please help to push?
http://cr.openjdk.java.net/~ddong/8156028/webrev.00/

Thanks,
Liang

------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2019 Nov. 26 (Tue.) 22:20
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value

This looks fine, except that it would be good to add a newline after the declaration of _adaptive_size to match the original patch.

Thanks,
Paul

 On 11/26/19, 12:20 AM, "jdk8u-dev on behalf of Liang Mao" <jdk8u-dev-bounces at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote:

    Hi,
    Original bug:
     https://bugs.openjdk.java.net/browse/JDK-8156028
     http://hg.openjdk.java.net/jdk/jdk/rev/ba8be1a71dec

    Original patch does not apply cleanly to 8u, because class G1YoungGenSizer has been
    moved to seperated file.

    Since G1 is already a stable feature in JDK8U, the obvious bug that the young gen size
    cannot be adaptive with different NewSize and MaxNewSize makes users confused. The
    alternative way to use experimental option *G1NewSizePercent* is not intuitive and formal.

    8u webrev:
     http://cr.openjdk.java.net/~ddong/8156028/webrev.00/
    Testing: x86_64 build, affected tests, tier1
    Thanks,
    Liang




From gnu.andrew at redhat.com  Wed Nov 27 23:46:54 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 27 Nov 2019 23:46:54 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <1bcabbd834f443ad957abf93d92568d1@azul.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <2b4eeccd689049cfaed69e80523e720e@azul.com>
 <9e4b2962-820f-29e7-c0e9-6be6b7415d38@redhat.com>
 <1bcabbd834f443ad957abf93d92568d1@azul.com>
Message-ID: <8091277c-5cd1-438c-2ed3-dba94d965b70@redhat.com>



On 22/11/2019 13:30, Yuri Gaevsky wrote:
> Hi Martin,
> 
>> I didn't know you have already proposed a backport for this bug. I
>> assumed nobody did because the ticket was not flagged with
>> "jdk8u-fix-request". Sorry.
> 
> There is no need to apologise, it's great to finally see the review for JDK-8073108
> is progressing. :-)
> 
> IIUC, the marking of the appropriate JBS issue with 'jdk8u-fix-request' is the *next step*
> in the backporting process. 
> 
> In summary, my reading  of  the related OpenJDK documents (see below) is that:
>   (a) the formal review should be done *before* setting 'jdk8u-fix-request' label in JBS;
>   (b) 'review request for backport' and 'push approval for backport' are different things.
> 
> [1] https://wiki.openjdk.java.net/display/jdk8u/Main
>   --- cut ---
>     If the backport requires more than just cosmetic changes (file location changes, copyright
>   header updates) to apply to the 8u tree, *it should first be submitted for review*.
>   Push approval for a fix is *then requested by setting the jdk8u-fix-request label* on
>   the original JBS bug.
>   --- cut ---
> 
> [2] https://wiki.openjdk.java.net/display/jdk8u/Guidelines+for+working+on+jdk8u
>   --- cut ---
>   In general we'll use the process in https://openjdk.java.net/projects/jdk-updates/approval.html.
>   ...
>   To request maintainer *approval* for a backport, tag your entry in the bug
>   database with "jdk8u-fix-request".
>   --- cut ---
> 
> [3] https://openjdk.java.net/projects/jdk-updates/approval.html
>   --- cut ---
>   JDK Updates: Requesting *push* approval for fixes
>   Rule 0
>   ...
>   An OpenJDK JDK Updates Author, Committer or Reviewer requesting their fix in a JDK Updates
>   repo MUST label the corresponding master/parent issue with jdk<release>u-fix-request
>   (where <release> denotes the feature release version, e.g. jdk10u-fix-request) in the JDK Bug System.
>   --- cut ---
> 
> [4] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
>   --- cut ---
>   If (and only if) the original patch was modified, *get the change reviewed*
>     Note: *the change review is not the approval, which you would get at the next step*
>   --- cut ---
> 
> 

This is correct; a patch should be in a commit-ready state before
flagging for approval. I intend to comment on this in a separate thread
as it does seem to have caused some confusion.

If there are elements of the documentation that you think would benefit
from greater clarification, please let us know.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Thu Nov 28 00:27:48 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Nov 2019 00:27:48 +0000
Subject: [8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH
 acceleration
In-Reply-To: <d790d4a8-9aa2-cf85-53d2-7299339d061e@redhat.com>
References: <d0edfbfd-6293-311c-86fe-b2b324757335@redhat.com>
 <F0E721A0-70FE-49FD-A043-34024BACA70B@amazon.com>
 <27c69006-b288-a020-71f0-67f996ba02e0@redhat.com>
 <DF722DC9-0CC4-4FFD-BFF9-34557D1D7FBC@amazon.com>
 <d790d4a8-9aa2-cf85-53d2-7299339d061e@redhat.com>
Message-ID: <a747e5a7-215d-69cb-9bfa-1b1d5a9facf1@redhat.com>

On 21/11/2019 16:13, Martin Balao wrote:
> On 11/21/19 12:48 PM, Hohensee, Paul wrote:
>> You should be able to build a 32-bit linux jdk and test it on x32.
>>
> 
> Yes, I'll test on 32-bit.
> 
>> Does anyone on the list have access to a sparc box? I'm very hesitant to approve an untested backport. I'd be fine with just the x32/64 part though.
>>
> 
> I'm okay with removing the SPARC part if nobody is able to test there.
> 

While I see this has now been tested on SPARC, I think the general issue
is worth commenting on, as this is something I've often encountered with
OpenJDK 7 as well.

In the event that a particular OS or hardware can not be tested, I would
tend towards still including the changes. For OS or architecture support
to be fully supported, it needs active maintenance. It is perfectly
possible for things to break even without changes to specific code being
altered.  So what we're really looking at here is the potential outcome
when someone does try to build on that platform at some later date.
There are four potential outcomes, reducing to two depending on whether
the changes are included or not:

A.1. The changes are included and nothing is broken. No maintenance work
is required.

A.2. The changes are included, causing breakage because adaptations
needed to be made for the earlier OpenJDK version. The maintainer has to
make the necessary changes to fix the backport.

B.1. The changes are not included and nothing is broken. However, the
maintainer has to then find and complete such backports to bring the
platform in sync with others.

B.2. The changes are not included but breakage is caused by other
changes. The maintainer has to fix the breakage, and then work through
the backport backlog.

Looking at these alternatives from a potential maintainer perspective,
A.1 & A.2 are a preferable pair to B.1 & B.2. If we're lucky, nothing
needs to be done. If we're unlucky, the same work as would have been
needed at the time of the backport review needs to be done. Both are
preferable to not including the changes, where the maintainer has to
hunt down such changes and apply them, and may not have avoided breakage
by other means.

In short, platform support requires active maintenance and omitting such
changes just creates a greater burden for any future maintainer, with no
guarantee of avoiding breakage.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Thu Nov 28 01:44:20 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Nov 2019 01:44:20 +0000
Subject: [8u] RFR: 8204290: Add check to limit number of capture groups
In-Reply-To: <6b5dd7bcb18aba515511d23c095663fcdbd626ef.camel@redhat.com>
References: <6b5dd7bcb18aba515511d23c095663fcdbd626ef.camel@redhat.com>
Message-ID: <fe345b95-b40a-4f5c-310b-a20e2f74b5cb@redhat.com>



On 18/11/2019 18:11, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this OpenJDK 8u backport of JDK-8204290
> for Oracle JDK 8u24x parity? The JDK 11 patch is the same exept for
> these test changes (and modulo path changes):
> 
> This:
> 
>     new RegExp("()".repeat(0x8001));
>     fail("Expected exception");
> 
> became:
> 
>     var captureGroups = "";
>     for (i=0; i < 0x8001; i++) { captureGroups = captureGroups + "()"; }
>     new RegExp(captureGroups);
>     fail("Expected exception");
> 
> String.repeat() is a JDK 11 feature. Results in:
> 
> <shell>:1 TypeError: "()".repeat is not a function
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204290
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204290/01/webrev/
> 
> Testing: nashorn tests. New regresstion test passes. Manual testing with jjs.
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

Could '+=' not be used here i.e.

for (i=0; i < 0x8001; i++) { captureGroups += "()"; }

Otherwise looks good.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Thu Nov 28 04:12:36 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Nov 2019 04:12:36 +0000
Subject: [8u] RFR 8055351:
 sun/security/provider/DSA/TestAlgParameterGenerator.java failed with
 interrupted! (timed out?)
In-Reply-To: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com>
References: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com>
Message-ID: <d89dfbac-0b84-cab2-e5aa-ccc516118b5c@redhat.com>



On 20/11/2019 19:32, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for the 8u backport of 8055351 [1].
> 
> Webrev.00:
> 
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8055351/8055351.8u.jdk.webrev.00/
> 
> Differences from JDK baseline patch:
> 
>  * test/sun/security/provider/DSA/TestAlgParameterGenerator.java
>   * Copyright date
>   * 1st and 2nd hooks do not apply cleanly because 8u already has
> 8181048 [2] [3] affecting the same file. Note: 8181048 was backported
> before 8055351 to 8u, even though it's a newer patch. Manually applied
> changes without further conflicts.
> 
> Testing:
> 
>  *  sun/security/provider/DSA/TestAlgParameterGenerator.java passes
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8055351
> [2] - https://bugs.openjdk.java.net/browse/JDK-8181048
> [3] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/65f4af74c8b1
> 

Why is the copyright being changed here? The 8u version is already later
than the change in this patch (presumably from 8181048), so can just be
left alone. By changing it to 2019, you're creating a change unique to
8u which will has the potential to cause problems for other backports.

Otherwise looks fine.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Thu Nov 28 05:16:30 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Nov 2019 05:16:30 +0000
Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40
 support
In-Reply-To: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
Message-ID: <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com>



On 19/11/2019 19:55, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for the 8u backport of 8080462 [1].
> 
> Webrev.00:
> 
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.00/
> 
> Differences from 11u patch [2]:
> 
>  * src/share/legal/pkcs11cryptotoken.md
>   * Does not apply because "8169925: Organize licenses by module in
> source, JMOD file, and run-time image" [3] is not in 8u.
> 
>  * src/share/classes/sun/security/pkcs11/SunPKCS11.java
>   * 6th and 11th hook do not apply cleanly because ECParameters location
> is "sun.security.ec.ECParameters" in 8u instead of
> "sun.security.util.ECParameters"
>   * 8th hook does not apply cleanly because 8042967 [4] is not in 8u.
> 
>  * src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java
>   * 5th hook does not apply cleanly because toString method uses a
> StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).
> 
>  * src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java
>   * 1st hook does not apply cleanly because toString method uses a
> StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).
> 
>  * src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
>   * 13th hook does no apply cleanly because 8074580 [6] is not in 8u.
> Manually applied change.
> 
>  * src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
>   * Copyright date.
> 
>  * src/share/native/sun/security/pkcs11/wrapper/p11_util.c
>   * Copyright date.
> 
>  * src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
>   * 4th hook does not apply cleanly because 6913047 was backported to 8u
> without the "//#define P11_DEBUG" line.
> 
>  * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java
>   * 1th hook does not apply cleanly because of copyright date.
>   * 2nd hook do not apply cleanly because 8164639 [7], 8078334 [8],
> 8172527 [9], 8144539 [10] are not in 8u. Manually applied changes.
> 
>  * src/share/classes/sun/security/util/GCMParameters.java
>   * HexDumpEncoder is sun.misc.HexDumpEncoder in 8u (instead of
> sun.security.util.HexDumpEncoder)
> 
>  * src/share/classes/sun/security/pkcs11/P11PSSSignature.java
>   * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
> 8146293 [11] has not been backported. Added a private field in
> P11PSSSignature with the constant.
> 
>  * test/sun/security/pkcs11/Cipher/TestKATForGCM.java
>  * test/sun/security/pkcs11/Cipher/Test4512704.java
>  * test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java
>  * test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java
>  * test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java
>  * test/sun/security/pkcs11/Signature/InitAgainPSS.java
>  * test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
>  * test/sun/security/pkcs11/Signature/SigInteropPSS.java
>  * test/sun/security/pkcs11/Signature/SignatureTestPSS.java
>  * test/sun/security/pkcs11/Signature/TestDSA2.java
>   * @library jtreg header modified to remove "/test/lib"
>   * 8144539 [12] is not in 8u. Given that the test uses no arguments, I
> discarded the parameter when calling PKCS11Test::main method.
> 
>  * test/sun/security/pkcs11/Signature/InitAgainPSS.java
>   * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
> 8146293 [11] has not been backported. Added a private field in
> InitAgainPSS with the constant.
> 
>  * make/mapfiles/libj2pkcs11/mapfile-vers
>   * Added Java_sun_security_pkcs11_wrapper_PKCS11_freeMechanism native
> method
> 
>  * test/sun/security/pkcs11/Signature/SigInteropPSS.java
>   * "java.security.NoSuchAlgorithmException: no such algorithm:
> RSASSA-PSS for provider SunRsaSign" error.
>    * This test cannot properly execute because 8146293 [11] is not in
> 8u. Manually modified to skip unless 8146293 [11] is available.
> 
> 
> Testing
> 
>  * No regressions have been observed in sun/security/pkcs11 category
> 
>  * All new tests (introduced by this enhancement) pass
>   * Note: SigInteropPSS is skipped for the reasons previously stated
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8080462
> [2] - https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8bac0ba1d5ce
> [3] - https://bugs.openjdk.java.net/browse/JDK-8169925
> [4] - https://bugs.openjdk.java.net/browse/JDK-8042967
> [5] - https://bugs.openjdk.java.net/browse/JDK-8041679
> [6] - https://bugs.openjdk.java.net/browse/JDK-8074580
> [7] - https://bugs.openjdk.java.net/browse/JDK-8164639
> [8] - https://bugs.openjdk.java.net/browse/JDK-8078334
> [9] - https://bugs.openjdk.java.net/browse/JDK-8172527
> [10] - https://bugs.openjdk.java.net/browse/JDK-8144539
> [11] - https://bugs.openjdk.java.net/browse/JDK-8146293
> [12] - https://bugs.openjdk.java.net/browse/JDK-8144539
> 

* The home of legal notices in 8u is the THIRD_PARTY_README file in each
repository, so the changes should go there, not simply be dropped. This
one actually seems to be missing at present (it suddenly appears with
JDK-8169925), so even more reason to add it above the section for the
PKCS#11 wrapper.
* The original patch removes pkcs-11v2-20a3.h while the 8u backport doesn't.
* The change to TRAILER_FIELD_BC is correct, as altering
PSSParameterSpec would alter the Java 8 API. However, it may be worth
waiting for JDK-8146293, which has now been proposed for backport via
JDK-8230978, which will also initiate a spec change via the reference
implementation, jdk8u41.
* I'm seeing a lot of noise when comparing the 8u and 11u patches for
CK_RSA_PKCS_PSS_PARAMS.java, PKCS11Constants.java, p11_convert.c,
p11_digest.c, p11_sign.c & pkcs11t.h, though the changes look the same.
Have you checked that the patched files in 8u compare to those in 8u as
expected?
* Please don't alter the SigInteropPSS.java test without comments
explaining why. As JDK-8146293 is imminent, I'd say just leave this as
it is and it will be automatically resolved.
* Why is the args argument dropped from the tests? Is this another
missing fix?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Thu Nov 28 05:43:46 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Nov 2019 05:43:46 +0000
Subject: 8u Approvals and Rampdown
Message-ID: <1bd0d090-3647-2ecc-fc90-8e1ddf80b97b@redhat.com>

Hi all,

You will have noticed that we have developed a backlog of approvals
recently and this is in part due to some apparent confusion over the
approval process.

Approval should be requested once the patch is ready to be committed to
the appropriate 8u repository (8u-dev for jdk8u-fix-request, 8u for
jdk8u-critical-request).

With 8u, patches often need substantial backport work before they reach
this point. To keep things moving at a good pace for everyone, it is
important not to use up the relatively low bandwidth we have for
approvals with queries and reviews that would be better targeted at the
mailing list as a whole.

So:

* If you want to know if something is worth backporting, start a
discussion on the mailing list. Feel free to add your own label to the
bug for reference, but don't flag for approval at this early point.

* If you find a bug you believe is 8u only, then please file a bug and
discuss it on the mailing list, but don't flag the bug for approval
until you have a reviewed patch for it.

* If backporting a patch requires anything more than path changes (which
should be able to be automated using the scripts in the repositories),
then post a request for review to the mailing list. Once a 8u reviewer
is ok with it, then proceed to flagging for approval.

This should mean that everything in the 8u approval queue is then either:

a) A clean backport (sans path changes)

or:

b) A reviewed backport with corresponding mailing list thread

This will make life easier for both maintainers and those waiting on
approvals.

At present, we are seeing a mix of bugs in all states in the approval
queue, which ends up turning what should be a rubber-stamping process
into one where the maintainer ends up also doing a lengthy review or
even trying to determine the validity of a new patch from scratch. This
makes each approval take longer, meaning everyone has to wait longer to
get their patch approved. In many cases, the issue will end up staying
in the queue because further feedback is needed from the author.

Such issues are to be expected in the early days of maintaining 8u, but
as we all get used to the process, things should get better. If you
think things like this can be clarified better in the documentation,
please let us know.

I have just finished reviewing the list of 8u242 bugs to see our current
status as we begin rampdown. I'll post at length on this tomorrow when
I've reviewed a final few patches,  but please be prepared for the
switch to 8u252 development and the need to consider whether your bug
still needs to make 8u242 or not.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From sgehwolf at redhat.com  Thu Nov 28 13:13:25 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 28 Nov 2019 14:13:25 +0100
Subject: [8u] RFR: 8204290: Add check to limit number of capture groups
In-Reply-To: <fe345b95-b40a-4f5c-310b-a20e2f74b5cb@redhat.com>
References: <6b5dd7bcb18aba515511d23c095663fcdbd626ef.camel@redhat.com>
 <fe345b95-b40a-4f5c-310b-a20e2f74b5cb@redhat.com>
Message-ID: <627d15e70bcbcb87ecbaea93b44acecf545256eb.camel@redhat.com>

Hi Andrew,

Thanks for the review!

On Thu, 2019-11-28 at 01:44 +0000, Andrew John Hughes wrote:
> 
> On 18/11/2019 18:11, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review of this OpenJDK 8u backport of JDK-8204290
> > for Oracle JDK 8u24x parity? The JDK 11 patch is the same exept for
> > these test changes (and modulo path changes):
> > 
> > This:
> > 
> >     new RegExp("()".repeat(0x8001));
> >     fail("Expected exception");
> > 
> > became:
> > 
> >     var captureGroups = "";
> >     for (i=0; i < 0x8001; i++) { captureGroups = captureGroups + "()"; }
> >     new RegExp(captureGroups);
> >     fail("Expected exception");
> > 
> > String.repeat() is a JDK 11 feature. Results in:
> > 
> > <shell>:1 TypeError: "()".repeat is not a function
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8204290
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204290/01/webrev/
> > 
> > Testing: nashorn tests. New regresstion test passes. Manual testing with jjs.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> 
> Could '+=' not be used here i.e.
> 
> for (i=0; i < 0x8001; i++) { captureGroups += "()"; }
> 
> Otherwise looks good.

Sure. Done:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204290/02/webrev/

Thanks,
Severin


From yan at azul.com  Thu Nov 28 13:43:42 2019
From: yan at azul.com (Yuri Nesterenko)
Date: Thu, 28 Nov 2019 16:43:42 +0300
Subject: [8u] RFR 8134424: BlockDataInputStream.readUTFBody: size local
 StringBuffer with the given length
Message-ID: <81afcfba-aa7b-6803-2a4f-bc47a3b87e47@azul.com>

Hi,

please take a look at this request for review for OpenJDK 8 backport of
8134424 [1].

Webrev is

http://cr.openjdk.java.net/~yan/8134424/webrev.0

Patch applied cleanly with jdk8 specifics: path was changed. Also,
copyright date was set to 2019.

The patch itself was discussed in
https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038684.html

Thank you!

--yan

[1] https://bugs.openjdk.java.net/browse/JDK-8134424



From sgehwolf at redhat.com  Thu Nov 28 13:48:29 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 28 Nov 2019 14:48:29 +0100
Subject: [8u] RFR: 8196969: JTreg Failure:
 serviceability/sa/ClhsdbJstack.java causes NPE
Message-ID: <cac7c8ed961774a0edbc4ece5a16e26dfae42bac.camel@redhat.com>

Hi,

Could I please get a review of this OpenJDK 8u backport of 8196969
which fixes a potential NPE when attaching to a Java process via jstack
-F <pid> and observing compiled frames with a null debug offset. The
patch is the same as for JDK 11 and JDK 14 (modulo path changes), but
I've dropped the tests since the SA test infra doesn't exist in 8u.

I've verified manually that the fix works.

Bug: https://bugs.openjdk.java.net/browse/JDK-8196969
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196969/jdk8/01/webrev/
original change: https://hg.openjdk.java.net/jdk/jdk/rev/516db52daad6

Thoughts?

Thanks,
Severin


From gnu.andrew at redhat.com  Thu Nov 28 18:09:30 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Nov 2019 18:09:30 +0000
Subject: [8u] RFR: 8204290: Add check to limit number of capture groups
In-Reply-To: <627d15e70bcbcb87ecbaea93b44acecf545256eb.camel@redhat.com>
References: <6b5dd7bcb18aba515511d23c095663fcdbd626ef.camel@redhat.com>
 <fe345b95-b40a-4f5c-310b-a20e2f74b5cb@redhat.com>
 <627d15e70bcbcb87ecbaea93b44acecf545256eb.camel@redhat.com>
Message-ID: <6052c117-7e97-3c58-f702-4e0900545623@redhat.com>



On 28/11/2019 13:13, Severin Gehwolf wrote:
> Hi Andrew,
> 
> Thanks for the review!
> 
> On Thu, 2019-11-28 at 01:44 +0000, Andrew John Hughes wrote:
>>
>> On 18/11/2019 18:11, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could I please get a review of this OpenJDK 8u backport of JDK-8204290
>>> for Oracle JDK 8u24x parity? The JDK 11 patch is the same exept for
>>> these test changes (and modulo path changes):
>>>
>>> This:
>>>
>>>     new RegExp("()".repeat(0x8001));
>>>     fail("Expected exception");
>>>
>>> became:
>>>
>>>     var captureGroups = "";
>>>     for (i=0; i < 0x8001; i++) { captureGroups = captureGroups + "()"; }
>>>     new RegExp(captureGroups);
>>>     fail("Expected exception");
>>>
>>> String.repeat() is a JDK 11 feature. Results in:
>>>
>>> <shell>:1 TypeError: "()".repeat is not a function
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204290
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204290/01/webrev/
>>>
>>> Testing: nashorn tests. New regresstion test passes. Manual testing with jjs.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>
>> Could '+=' not be used here i.e.
>>
>> for (i=0; i < 0x8001; i++) { captureGroups += "()"; }
>>
>> Otherwise looks good.
> 
> Sure. Done:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204290/02/webrev/
> 
> Thanks,
> Severin
> 

Thanks. All reviewed, approved and good to go.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From sgehwolf at redhat.com  Fri Nov 29 10:56:47 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 29 Nov 2019 11:56:47 +0100
Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40
 support
In-Reply-To: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com>
Message-ID: <0810bedd3dcfcfa4913c8f2bfb4e62b88e4d5daa.camel@redhat.com>

Hi,

On Tue, 2019-11-19 at 16:55 -0300, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for the 8u backport of 8080462 [1].
> 
> Webrev.00:
> 
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.00/

Since this backport broke 32-bit builds in jdk/jdk, could you please
also look at backporting JDK-8225695 to 8u, please?

Thanks,
Severin

> Differences from 11u patch [2]:
> 
>  * src/share/legal/pkcs11cryptotoken.md
>   * Does not apply because "8169925: Organize licenses by module in
> source, JMOD file, and run-time image" [3] is not in 8u.
> 
>  * src/share/classes/sun/security/pkcs11/SunPKCS11.java
>   * 6th and 11th hook do not apply cleanly because ECParameters location
> is "sun.security.ec.ECParameters" in 8u instead of
> "sun.security.util.ECParameters"
>   * 8th hook does not apply cleanly because 8042967 [4] is not in 8u.
> 
>  * src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java
>   * 5th hook does not apply cleanly because toString method uses a
> StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).
> 
>  * src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java
>   * 1st hook does not apply cleanly because toString method uses a
> StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u).
> 
>  * src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
>   * 13th hook does no apply cleanly because 8074580 [6] is not in 8u.
> Manually applied change.
> 
>  * src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
>   * Copyright date.
> 
>  * src/share/native/sun/security/pkcs11/wrapper/p11_util.c
>   * Copyright date.
> 
>  * src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
>   * 4th hook does not apply cleanly because 6913047 was backported to 8u
> without the "//#define P11_DEBUG" line.
> 
>  * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java
>   * 1th hook does not apply cleanly because of copyright date.
>   * 2nd hook do not apply cleanly because 8164639 [7], 8078334 [8],
> 8172527 [9], 8144539 [10] are not in 8u. Manually applied changes.
> 
>  * src/share/classes/sun/security/util/GCMParameters.java
>   * HexDumpEncoder is sun.misc.HexDumpEncoder in 8u (instead of
> sun.security.util.HexDumpEncoder)
> 
>  * src/share/classes/sun/security/pkcs11/P11PSSSignature.java
>   * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
> 8146293 [11] has not been backported. Added a private field in
> P11PSSSignature with the constant.
> 
>  * test/sun/security/pkcs11/Cipher/TestKATForGCM.java
>  * test/sun/security/pkcs11/Cipher/Test4512704.java
>  * test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java
>  * test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java
>  * test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java
>  * test/sun/security/pkcs11/Signature/InitAgainPSS.java
>  * test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
>  * test/sun/security/pkcs11/Signature/SigInteropPSS.java
>  * test/sun/security/pkcs11/Signature/SignatureTestPSS.java
>  * test/sun/security/pkcs11/Signature/TestDSA2.java
>   * @library jtreg header modified to remove "/test/lib"
>   * 8144539 [12] is not in 8u. Given that the test uses no arguments, I
> discarded the parameter when calling PKCS11Test::main method.
> 
>  * test/sun/security/pkcs11/Signature/InitAgainPSS.java
>   * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because
> 8146293 [11] has not been backported. Added a private field in
> InitAgainPSS with the constant.
> 
>  * make/mapfiles/libj2pkcs11/mapfile-vers
>   * Added Java_sun_security_pkcs11_wrapper_PKCS11_freeMechanism native
> method
> 
>  * test/sun/security/pkcs11/Signature/SigInteropPSS.java
>   * "java.security.NoSuchAlgorithmException: no such algorithm:
> RSASSA-PSS for provider SunRsaSign" error.
>    * This test cannot properly execute because 8146293 [11] is not in
> 8u. Manually modified to skip unless 8146293 [11] is available.
> 
> 
> Testing
> 
>  * No regressions have been observed in sun/security/pkcs11 category
> 
>  * All new tests (introduced by this enhancement) pass
>   * Note: SigInteropPSS is skipped for the reasons previously stated
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8080462
> [2] - https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8bac0ba1d5ce
> [3] - https://bugs.openjdk.java.net/browse/JDK-8169925
> [4] - https://bugs.openjdk.java.net/browse/JDK-8042967
> [5] - https://bugs.openjdk.java.net/browse/JDK-8041679
> [6] - https://bugs.openjdk.java.net/browse/JDK-8074580
> [7] - https://bugs.openjdk.java.net/browse/JDK-8164639
> [8] - https://bugs.openjdk.java.net/browse/JDK-8078334
> [9] - https://bugs.openjdk.java.net/browse/JDK-8172527
> [10] - https://bugs.openjdk.java.net/browse/JDK-8144539
> [11] - https://bugs.openjdk.java.net/browse/JDK-8146293
> [12] - https://bugs.openjdk.java.net/browse/JDK-8144539
> 


From sgehwolf at redhat.com  Fri Nov 29 13:08:53 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 29 Nov 2019 14:08:53 +0100
Subject: [8u] RFR(xs): 8229515: [macos] access to window property of NSView
 on wrong thread
Message-ID: <ca62fb98af5292ebed97a2e1b9472265ff8d50ce.camel@redhat.com>

Hi,

Please review this OpenJDK 8u backport of 8229515. The patch does not
apply cleanly due to minor context differences (e.g indent of
JNF_COCOA_ENTER). Otherwise, the patch is the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8229515
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8229515/01/webrev/
JDK 11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a716aabed866

Thoughts?

Thanks,
Severin


From sgehwolf at redhat.com  Fri Nov 29 13:53:39 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 29 Nov 2019 14:53:39 +0100
Subject: [8u] RFR(xs): 8232984: Upgrading Joni License version to 2.1.16
Message-ID: <785fafa7ca16286bfbe8b57667a1dc4296ad60b1.camel@redhat.com>

Hi,

Please review this Oracle JDK feature parity patch for 8u242. Since
licenses are dealt with in 8u differently than in later releases the
JDK 11 patch didn't apply. I've manually ported it to
THIRD_PARTY_README. The intention is to push this to all 8 repositories
once reviewed. Webrev below is for top repo only.

Pre-requisite of this patch going in is JDK-8204288[1] also getting
approved. Note: JDK-8204290 is already in jdk8u.

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

Thoughts?

Thanks,
Severin

[1] https://bugs.openjdk.java.net/browse/JDK-8204288


From hohensee at amazon.com  Fri Nov 29 16:09:22 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 29 Nov 2019 16:09:22 +0000
Subject: [8u] RFR: 8196969: JTreg Failure:
 serviceability/sa/ClhsdbJstack.java causes NPE
In-Reply-To: <cac7c8ed961774a0edbc4ece5a16e26dfae42bac.camel@redhat.com>
References: <cac7c8ed961774a0edbc4ece5a16e26dfae42bac.camel@redhat.com>
Message-ID: <9FDC0DA0-10A8-4603-97BF-AB85F4954389@amazon.com>

Looks good.

Separately, how difficult would it be to backport the SA test infra? Should we consider doing it?

Thanks,
Paul

?On 11/28/19, 5:49 AM, "jdk8u-dev on behalf of Severin Gehwolf" <jdk8u-dev-bounces at openjdk.java.net on behalf of sgehwolf at redhat.com> wrote:

    Hi,
    
    Could I please get a review of this OpenJDK 8u backport of 8196969
    which fixes a potential NPE when attaching to a Java process via jstack
    -F <pid> and observing compiled frames with a null debug offset. The
    patch is the same as for JDK 11 and JDK 14 (modulo path changes), but
    I've dropped the tests since the SA test infra doesn't exist in 8u.
    
    I've verified manually that the fix works.
    
    Bug: https://bugs.openjdk.java.net/browse/JDK-8196969
    webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196969/jdk8/01/webrev/
    original change: https://hg.openjdk.java.net/jdk/jdk/rev/516db52daad6
    
    Thoughts?
    
    Thanks,
    Severin
    
    


From sgehwolf at redhat.com  Fri Nov 29 16:42:14 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 29 Nov 2019 17:42:14 +0100
Subject: [8u] RFR: 8196969: JTreg Failure:
 serviceability/sa/ClhsdbJstack.java causes NPE
In-Reply-To: <9FDC0DA0-10A8-4603-97BF-AB85F4954389@amazon.com>
References: <cac7c8ed961774a0edbc4ece5a16e26dfae42bac.camel@redhat.com>
 <9FDC0DA0-10A8-4603-97BF-AB85F4954389@amazon.com>
Message-ID: <5b6eb7c0facc02856ef72ca8d941f95ae2c4c041.camel@redhat.com>

On Fri, 2019-11-29 at 16:09 +0000, Hohensee, Paul wrote:
> Looks good.

Thanks for the review, Paul!

> Separately, how difficult would it be to backport the SA test infra? Should we consider doing it?

I haven't looked at it in detail, but it may be something we should
consider doing. I doubt it's difficult, but it'll be a chunk of work.

It basically amounts to looking at
test/hotspot/jtreg/serviceability/sa/ and checking what functionality
exists in 8u then porting it over. Not sure how much of the other test
support libraries would need to get backported too.

Thanks,
Severin

> Thanks,
> Paul
> 
> ?On 11/28/19, 5:49 AM, "jdk8u-dev on behalf of Severin Gehwolf" <jdk8u-dev-bounces at openjdk.java.net on behalf of sgehwolf at redhat.com> wrote:
> 
>     Hi,
>     
>     Could I please get a review of this OpenJDK 8u backport of 8196969
>     which fixes a potential NPE when attaching to a Java process via jstack
>     -F <pid> and observing compiled frames with a null debug offset. The
>     patch is the same as for JDK 11 and JDK 14 (modulo path changes), but
>     I've dropped the tests since the SA test infra doesn't exist in 8u.
>     
>     I've verified manually that the fix works.
>     
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8196969
>     webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196969/jdk8/01/webrev/
>     original change: https://hg.openjdk.java.net/jdk/jdk/rev/516db52daad6
>     
>     Thoughts?
>     
>     Thanks,
>     Severin
>     
>     
>