From guangyu.zhu at aliyun.com  Fri Feb  1 02:15:39 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Fri, 01 Feb 2019 10:15:39 +0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsIGZvciBiYWNrLXBvcnRpbmcgSkZSIHRvIE9wZW5KREs4dQ==?=
In-Reply-To: <CABi63P6oGXbHt_rXVzHLnPc8ZwA4VZ8vE1YmEKHmJoK-OUn42g@mail.gmail.com>
References: <00f801d4960b$4f322500$ed966f00$@alibaba-inc.com>
 <b535ad51-1d7d-46b9-a21a-44f7629fbe8e.guangyu.zhu@aliyun.com>
 <CAJwKKmb_HbUywq=rqjh8BHhyHkb18b2dTMBPhY3faLVDi-YfqQ@mail.gmail.com>
 <CAJwKKmYd4JjcbM3YZe88gvVqyNoRPFxAt3rKf+V1B0e2TiwnWQ@mail.gmail.com>
 <9fa34102-4117-49cc-a08f-f42f85a5b478.guangyu.zhu@aliyun.com>
 <CAJwKKmYK_a+ff9pYpQPRWuEB9N0uix5ao-BWm2uSX3Lw24dk-w@mail.gmail.com>
 <ad325393-8960-4134-8539-14de843ee84c.guangyu.zhu@aliyun.com>
 <FC79C0AB-0A22-4F8B-A3F0-5D9D4CA12F4F@amazon.com>
 <4f874fd7-cd58-47a1-b2c2-ea76658aa5ef.guangyu.zhu@aliyun.com>
 <CAJwKKma8FaO9OjyqA-diA8MxO=oyaZnwftbNS7A0eYPuGa__kQ@mail.gmail.com>
 <CABi63P5oAY+THs1U+AL=xZDQnLdGVA=P7cQe+EkNK3mFEJR17Q@mail.gmail.com>
 <F715B982-1D2C-413C-8F93-CC144B59F476@amazon.com>
 <16d283d5-db92-4a24-b61f-fde7389a3632.guangyu.zhu@aliyun.com>,
 <CABi63P6oGXbHt_rXVzHLnPc8ZwA4VZ8vE1YmEKHmJoK-OUn42g@mail.gmail.com>
Message-ID: <0e29eb15-a370-4273-a432-bce95687e607.guangyu.zhu@aliyun.com>

Hi Andrew,

This patch was only tested on linux/x86_64, and has not been tested on bsd, windows or mac. The non-(linux/x86-64) platform lacks some platform-dependent functions. That is what Ao Qi mentioned in the previous message. 

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrew Hughes <gnu.andrew at redhat.com>
Sent At:2019 Feb. 1 (Fri.) 00:40
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:Mario Torre <neugens at redhat.com>; jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

On Thu, 31 Jan 2019 at 04:31, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>
> The risk lies in other non-linux/x86-64 platforms. We have never built on them.
>
> Thanks,
> Guangyu
>

To clarify; do you mean you've only tested on Linux & x86_64? Or are
you referring
only to non-Linux platforms (*BSD, Windows, Mac, Solaris)?

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From rwestrel at redhat.com  Fri Feb  1 10:50:54 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 01 Feb 2019 11:50:54 +0100
Subject: [8u] RFR + RFA: 8145096: Undefined behaviour in HotSpot
Message-ID: <87h8dn3hpt.fsf@redhat.com>


I'd like to backport 8145096 to 8u as we've seen it cause a failure with
newer version of gcc:

hotspot/test/compiler/5091921/Test6890943.java crashes with:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f314142d48c, pid=1380, tid=0x00007f31548e8700
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-roland_2019_02_01_10_38-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J 143 C2 Test6890943.calcWalkingRange(IIII)I (205 bytes) @ 0x00007f314142d48c [0x00007f314142cfa0+0x4ec]
#
# Core dump written. Default location: /home/roland/tmp/JTwork/scratch/0/core or core.1380
#
# An error report file with more information is saved as:
# /home/roland/tmp/JTwork/scratch/0/hs_err_pid1380.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 139849848751872
Dumping core ...

with gcc 8.2.1

The change doesn't apply cleanly so here is a webrev for 8u:

http://cr.openjdk.java.net/~roland/8145096.8u/webrev.00/

Initial change:

https://bugs.openjdk.java.net/browse/JDK-8145096
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/867bdec7c8c5

Roland.

From sean.coffey at oracle.com  Fri Feb  1 11:27:41 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 1 Feb 2019 11:27:41 +0000
Subject: [8u-communication] JDK 8 Updates Project Lead Resignation
Message-ID: <9d69199e-6bfa-efd5-1504-f3e13b94ef66@oracle.com>

With this message I resign as a maintainer and Project Lead of
the JDK 8 Updates Project. The Project's wiki page will be
updated accordingly. 



A new Project Lead will be registered in the Census once the
Group Lead of the Build Group nominates one, notifying this
mailing list and the Registrar. 


Regards,
Sean.

From tim.bell at oracle.com  Fri Feb  1 14:28:35 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 01 Feb 2019 06:28:35 -0800
Subject: New lead for the JDK 8 Update Releases Project: Andrew Haley
Message-ID: <5C545793.2000905@oracle.com>

Se?n Coffey has resigned as lead for the JDK 8 Updates Project [1].

Under the bylaws for Project Roles [2], a new Project Lead may be
nominated by the Group Leads of the Project's sponsoring groups.

The Build Infrastructure Group is sponsor of the project.  As Group
Lead, I would like to nominate Andrew Haley as the new Project Lead.

As the Build Infrastructure Group is the only sponsoring group for
this project, I believe that the nomination is automatically approved.

-Tim

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

[2] http://openjdk.java.net/bylaws#project-lead

From hohensee at amazon.com  Fri Feb  1 17:27:07 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 1 Feb 2019 17:27:07 +0000
Subject: [8u] RFR + RFA: 8145096: Undefined behaviour in HotSpot
In-Reply-To: <87h8dn3hpt.fsf@redhat.com>
References: <87h8dn3hpt.fsf@redhat.com>
Message-ID: <BC09B5A4-E0BD-4B52-9C0B-0DB5931C040F@amazon.com>

Lgtm. Thanks for doing this: we've made these changes locally, but haven't got round to upstreaming.

Paul

?On 2/1/19, 2:51 AM, "jdk8u-dev on behalf of Roland Westrelin" <jdk8u-dev-bounces at openjdk.java.net on behalf of rwestrel at redhat.com> wrote:

    
    I'd like to backport 8145096 to 8u as we've seen it cause a failure with
    newer version of gcc:
    
    hotspot/test/compiler/5091921/Test6890943.java crashes with:
    
    #
    # A fatal error has been detected by the Java Runtime Environment:
    #
    #  SIGSEGV (0xb) at pc=0x00007f314142d48c, pid=1380, tid=0x00007f31548e8700
    #
    # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-roland_2019_02_01_10_38-b00)
    # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-amd64 compressed oops)
    # Problematic frame:
    # J 143 C2 Test6890943.calcWalkingRange(IIII)I (205 bytes) @ 0x00007f314142d48c [0x00007f314142cfa0+0x4ec]
    #
    # Core dump written. Default location: /home/roland/tmp/JTwork/scratch/0/core or core.1380
    #
    # An error report file with more information is saved as:
    # /home/roland/tmp/JTwork/scratch/0/hs_err_pid1380.log
    #
    # If you would like to submit a bug report, please visit:
    #   http://bugreport.java.com/bugreport/crash.jsp
    #
    Current thread is 139849848751872
    Dumping core ...
    
    with gcc 8.2.1
    
    The change doesn't apply cleanly so here is a webrev for 8u:
    
    http://cr.openjdk.java.net/~roland/8145096.8u/webrev.00/
    
    Initial change:
    
    https://bugs.openjdk.java.net/browse/JDK-8145096
    http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/867bdec7c8c5
    
    Roland.
    


From yasuenag at gmail.com  Sat Feb  2 04:43:25 2019
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sat, 2 Feb 2019 13:43:25 +0900
Subject: [8u-dev] RFA: 8217432: MetaspaceGC::_capacity_until_GC exceeds
 MaxMetaspaceSize
Message-ID: <018b1835-e2c4-a4fd-90a3-ec882c066da1@gmail.com>

Hi all,

Please approve jdk8u backport of JDK-8217432.

   JBS: https://bugs.openjdk.java.net/browse/JDK-8217432
   webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/jdk8u/webrev.00/


This change fixes HWM for Metaspace GC does not exceed MaxMetaspaceSize.
Thus we don't see unexpected Full GC which causes by Metaspace after this change.


This change has been merged to jdk/jdk, and I'm requesting backport it to jdk 11.
Original patch has a change for vmTestbase, but it does not contain in this
approve request because jdk8u does not have it.


I've checked this change works fine on gc/metaspace jtreg tests on Linux x64.
Please approve it.


Thanks,

Yasumasa

From mark.reinhold at oracle.com  Sat Feb  2 05:10:13 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 01 Feb 2019 21:10:13 -0800
Subject: New lead for the JDK 8 Update Releases Project: Andrew Haley
In-Reply-To: <5C545793.2000905@oracle.com>
References: <5C545793.2000905@oracle.com>
Message-ID: <20190201211013.615113060@eggemoggin.niobe.net>

2019/2/1 6:28:35 -0800, tim.bell at oracle.com:
> Se?n Coffey has resigned as lead for the JDK 8 Updates Project [1].
> 
> Under the bylaws for Project Roles [2], a new Project Lead may be
> nominated by the Group Leads of the Project's sponsoring groups.
> 
> The Build Infrastructure Group is sponsor of the project.  As Group
> Lead, I would like to nominate Andrew Haley as the new Project Lead.
> 
> As the Build Infrastructure Group is the only sponsoring group for
> this project, I believe that the nomination is automatically approved.

That?s correct.

So recorded.

- Mark

From sean.coffey at oracle.com  Sat Feb  2 08:24:48 2019
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Sat, 02 Feb 2019 08:24:48 +0000
Subject: New lead for the JDK 8 Update Releases Project: Andrew Haley
In-Reply-To: <5C545793.2000905@oracle.com>
References: <5C545793.2000905@oracle.com>
Message-ID: <0A9B666F-0537-4137-AFBE-802E66654288@oracle.com>

Congratulations on your new role Andrew!

There's still a question around committer rights to the Project's master forest[0]. You can decide how best to manage the Project repositories. When you took over the Lead role in the JDK 7 Updates Project, I believe all Project committers/reviewers received commit rights to the master forest. You can email the OpenJDK ops team regarding any adjustments to be made on that front.

[0] https://hg.openjdk.java.net/jdk8u/jdk8u/

Regards,
Sean.

On 1 February 2019 14:28:35 GMT, Tim Bell <tim.bell at oracle.com> wrote:
>Se?n Coffey has resigned as lead for the JDK 8 Updates Project [1].
>
>Under the bylaws for Project Roles [2], a new Project Lead may be
>nominated by the Group Leads of the Project's sponsoring groups.
>
>The Build Infrastructure Group is sponsor of the project.  As Group
>Lead, I would like to nominate Andrew Haley as the new Project Lead.
>
>As the Build Infrastructure Group is the only sponsoring group for
>this project, I believe that the nomination is automatically approved.
>
>-Tim
>
>[1] 
>http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008502.html
>
>[2] http://openjdk.java.net/bylaws#project-lead

From aph at redhat.com  Sat Feb  2 13:40:58 2019
From: aph at redhat.com (Andrew Haley)
Date: Sat, 2 Feb 2019 13:40:58 +0000
Subject: [8u] RFR + RFA: 8145096: Undefined behaviour in HotSpot
In-Reply-To: <87h8dn3hpt.fsf@redhat.com>
References: <87h8dn3hpt.fsf@redhat.com>
Message-ID: <243d6e9c-83f2-7eed-3fdf-20ebb66a7ed6@redhat.com>

On 2/1/19 10:50 AM, Roland Westrelin wrote:
> The change doesn't apply cleanly so here is a webrev for 8u:
> 
> http://cr.openjdk.java.net/~roland/8145096.8u/webrev.00/

OK, thanks.

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

From gnu.andrew at redhat.com  Mon Feb  4 02:49:00 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 4 Feb 2019 02:49:00 +0000
Subject: New lead for the JDK 8 Update Releases Project: Andrew Haley
In-Reply-To: <0A9B666F-0537-4137-AFBE-802E66654288@oracle.com>
References: <5C545793.2000905@oracle.com>
 <0A9B666F-0537-4137-AFBE-802E66654288@oracle.com>
Message-ID: <CABi63P7xhNHBoVPopkJJXEHS58URt0J5RBLLjGF1rBbwcVU6Rg@mail.gmail.com>

On Sat, 2 Feb 2019 at 08:25, Se?n Coffey <sean.coffey at oracle.com> wrote:
>
> Congratulations on your new role Andrew!
>
> There's still a question around committer rights to the Project's master forest[0]. You can decide how best to manage the Project repositories. When you took over the Lead role in the JDK 7 Updates Project, I believe all Project committers/reviewers received commit rights to the master forest. You can email the OpenJDK ops team regarding any adjustments to be made on that front.
>
> [0] https://hg.openjdk.java.net/jdk8u/jdk8u/
>
> Regards,
> Sean.
>

With OpenJDK 7, we did work with just the one forest. However, I'd
expect OpenJDK 8u to see a wider
range of contributions over a longer time period than 7, as it is more
widely used than 7 was at the same
point in its lifespan.

With that in mind, I'd suggest retaining both forests and keeping the
master (jdk8u) with a more restricted
set of committers. My own thinking is that changes from 8u-dev should
only be promoted to 8u periodically
and after sufficient testing. During the period surrounding a security
update, I would suggest 8u is frozen,
so there is a known base for the upcoming release.

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb  4 04:52:12 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 4 Feb 2019 04:52:12 +0000
Subject: Result: New OpenJDK 8 Updates Committer: Gustavo Romero
Message-ID: <CABi63P56V6LUQ0ftb3T0L+OfVbPbHKo0An8XC6nOKvOC77t=RQ@mail.gmail.com>

Voting for Gustavo Romero [0] is now closed.

Yes: 9
Veto: 0
Abstain: 0
Invalid: 0

Turnout: 4% (9/217)

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

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008396.html
[1] https://openjdk.java.net/bylaws#lazy-consensus
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From rwestrel at redhat.com  Mon Feb  4 08:26:49 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 04 Feb 2019 09:26:49 +0100
Subject: [8u] RFR + RFA: 8145096: Undefined behaviour in HotSpot
In-Reply-To: <BC09B5A4-E0BD-4B52-9C0B-0DB5931C040F@amazon.com>
References: <87h8dn3hpt.fsf@redhat.com>
 <BC09B5A4-E0BD-4B52-9C0B-0DB5931C040F@amazon.com>
Message-ID: <87bm3s2c3a.fsf@redhat.com>


> Lgtm. Thanks for doing this: we've made these changes locally, but haven't got round to upstreaming.

Thanks for the review, Paul.

Roland.

From rwestrel at redhat.com  Mon Feb  4 08:27:49 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 04 Feb 2019 09:27:49 +0100
Subject: [8u] RFR + RFA: 8145096: Undefined behaviour in HotSpot
In-Reply-To: <243d6e9c-83f2-7eed-3fdf-20ebb66a7ed6@redhat.com>
References: <87h8dn3hpt.fsf@redhat.com>
 <243d6e9c-83f2-7eed-3fdf-20ebb66a7ed6@redhat.com>
Message-ID: <878syw2c1m.fsf@redhat.com>


>> The change doesn't apply cleanly so here is a webrev for 8u:
>> 
>> http://cr.openjdk.java.net/~roland/8145096.8u/webrev.00/
>
> OK, thanks.

Thanks. That's an approval and I can push this, right?

Roland.

From aph at redhat.com  Mon Feb  4 13:21:38 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 4 Feb 2019 13:21:38 +0000
Subject: New lead for the JDK 8 Update Releases Project: Andrew Haley
In-Reply-To: <CABi63P7xhNHBoVPopkJJXEHS58URt0J5RBLLjGF1rBbwcVU6Rg@mail.gmail.com>
References: <5C545793.2000905@oracle.com>
 <0A9B666F-0537-4137-AFBE-802E66654288@oracle.com>
 <CABi63P7xhNHBoVPopkJJXEHS58URt0J5RBLLjGF1rBbwcVU6Rg@mail.gmail.com>
Message-ID: <a47ce511-cde5-e9bd-4d42-599a88c642b1@redhat.com>

On 2/4/19 2:49 AM, Andrew Hughes wrote:

> With OpenJDK 7, we did work with just the one forest. However, I'd
> expect OpenJDK 8u to see a wider range of contributions over a
> longer time period than 7, as it is more widely used than 7 was at
> the same point in its lifespan.
> 
> With that in mind, I'd suggest retaining both forests and keeping
> the master (jdk8u) with a more restricted set of committers. My own
> thinking is that changes from 8u-dev should only be promoted to 8u
> periodically and after sufficient testing. During the period
> surrounding a security update, I would suggest 8u is frozen, so
> there is a known base for the upcoming release.

Yes, we should do that.

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

From aph at redhat.com  Mon Feb  4 17:31:10 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 4 Feb 2019 17:31:10 +0000
Subject: [8u] RFR + RFA: 8145096: Undefined behaviour in HotSpot
In-Reply-To: <878syw2c1m.fsf@redhat.com>
References: <87h8dn3hpt.fsf@redhat.com>
 <243d6e9c-83f2-7eed-3fdf-20ebb66a7ed6@redhat.com> <878syw2c1m.fsf@redhat.com>
Message-ID: <a05b3a0a-38dc-51c9-4a48-fb254dfb0964@redhat.com>

On 2/4/19 8:27 AM, Roland Westrelin wrote:
> 
>>> The change doesn't apply cleanly so here is a webrev for 8u:
>>>
>>> http://cr.openjdk.java.net/~roland/8145096.8u/webrev.00/
>>
>> OK, thanks.
> 
> Thanks. That's an approval and I can push this, right?

Absolutely, yes.

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

From yasuenag at gmail.com  Tue Feb  5 00:39:58 2019
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 5 Feb 2019 09:39:58 +0900
Subject: [8u-dev] RFA: 8217432: MetaspaceGC::_capacity_until_GC exceeds
 MaxMetaspaceSize
In-Reply-To: <018b1835-e2c4-a4fd-90a3-ec882c066da1@gmail.com>
References: <018b1835-e2c4-a4fd-90a3-ec882c066da1@gmail.com>
Message-ID: <CAGFVN2Ccakfsb=ejo8Hqy4bu=O+UWWh63ztCZS3FoVwvoF1YAw@mail.gmail.com>

This change has been merged to jdk11u:
  http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/606182671211

Please approve it!

>    JBS: https://bugs.openjdk.java.net/browse/JDK-8217432
>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/jdk8u/webrev.00/


Thanks,

Yasumasa


2019?2?2?(?) 13:43 Yasumasa Suenaga <yasuenag at gmail.com>:
>
> Hi all,
>
> Please approve jdk8u backport of JDK-8217432.
>
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8217432
>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/jdk8u/webrev.00/
>
>
> This change fixes HWM for Metaspace GC does not exceed MaxMetaspaceSize.
> Thus we don't see unexpected Full GC which causes by Metaspace after this change.
>
>
> This change has been merged to jdk/jdk, and I'm requesting backport it to jdk 11.
> Original patch has a change for vmTestbase, but it does not contain in this
> approve request because jdk8u does not have it.
>
>
> I've checked this change works fine on gc/metaspace jtreg tests on Linux x64.
> Please approve it.
>
>
> Thanks,
>
> Yasumasa

From gnu.andrew at redhat.com  Wed Feb  6 05:47:31 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 6 Feb 2019 05:47:31 +0000
Subject: [8u-dev] RFA: 8217432: MetaspaceGC::_capacity_until_GC exceeds
 MaxMetaspaceSize
In-Reply-To: <CAGFVN2Ccakfsb=ejo8Hqy4bu=O+UWWh63ztCZS3FoVwvoF1YAw@mail.gmail.com>
References: <018b1835-e2c4-a4fd-90a3-ec882c066da1@gmail.com>
 <CAGFVN2Ccakfsb=ejo8Hqy4bu=O+UWWh63ztCZS3FoVwvoF1YAw@mail.gmail.com>
Message-ID: <CABi63P5V_dLMOprioGw442eh=Aabs6cSu=U5+-vXrOkCrJKP_Q@mail.gmail.com>

On Tue, 5 Feb 2019 at 00:42, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>
> This change has been merged to jdk11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/606182671211
>
> Please approve it!
>
> >    JBS: https://bugs.openjdk.java.net/browse/JDK-8217432
> >    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/jdk8u/webrev.00/
>
>
> Thanks,
>
> Yasumasa
>
>

Approved.

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Feb  6 05:48:09 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 6 Feb 2019 05:48:09 +0000
Subject: [8u] Request for approval for bulk integration of fixes from
 8u202 to 8u
In-Reply-To: <3dd2724c-6a06-3d26-699f-f2673c687f5b@oracle.com>
References: <3d813bb9-e227-2256-e940-79d9085ad5de@oracle.com>
 <CABi63P7ixkLpUEJP8ByYOxoHW2ACRdaY=S05rQMziUUVEy7hSg@mail.gmail.com>
 <BE06EC09-9418-4B27-8F51-A4DF42CC7DAA@oracle.com>
 <CABi63P5GgLrhTvtm_NrdXapbyeGkD6UB9Yz+GVzLSvW5sdJpCQ@mail.gmail.com>
 <3dd2724c-6a06-3d26-699f-f2673c687f5b@oracle.com>
Message-ID: <CABi63P5e+NALZyAeYk=fNAF=hJmePfdFQhQHjF=CmcbfaArUAQ@mail.gmail.com>

On Thu, 31 Jan 2019 at 17:02, Se?n Coffey <sean.coffey at oracle.com> wrote:
>
> Thanks. Yes, that makes sense. No other activity should
> have occurred in the master forest since the recent CPU push.
>
> regards,
> Sean.
>

All done.

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Wed Feb  6 14:37:05 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 6 Feb 2019 15:37:05 +0100
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
Message-ID: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>

Please review and approve the 8u backport for SoftReference race fix.

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8212178
      Reporter: Roman Kennke
      Assignee: Aleksey Shipilev
      Priority: P4
      Components: xml

  Original Fix:
        12: JDK-8212178, http://hg.openjdk.java.net/jdk/jdk/rev/c83ba72377fc, 114 day(s) ago

  Backports and Forwardports:
        11: 11.0.2, JDK-8212685, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/5978954e1d74, 110
day(s) ago
         8: MISSING

The patch does not apply cleanly to 8u even after reshuffling, because 8u code does not have
subsequent patch that migrated JAXP to use generics [*]. The bug in question can be fixed by
copy-pasting the entire code block from 11u to 8u. Here is the webrev:
   http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/

Testing: 8u build, xml benchmarks

Thanks,
-Aleksey

[*] https://bugs.openjdk.java.net/browse/JDK-8181150


From sean.mullan at oracle.com  Wed Feb  6 16:06:21 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 6 Feb 2019 11:06:21 -0500
Subject: [8u] Request for approval for CR 8215318 - Amend the Standard
 Algorithm Names specification to clarify that names can be defined in later
 versions
In-Reply-To: <CABi63P4rKTjnaDu7-jxugJ_zXUc_hbtpErTArPWvJLcMJDbGZw@mail.gmail.com>
References: <27d7c7a7-4550-9fce-0e6d-8a4f9313a70f@oracle.com>
 <CABi63P706Vkt=7hs3bjHJXxRuOy79ddj-BaLsnLj955uvM8UDg@mail.gmail.com>
 <630acfdc-2be4-bd4b-894e-4599bb57d392@oracle.com>
 <CABi63P4rKTjnaDu7-jxugJ_zXUc_hbtpErTArPWvJLcMJDbGZw@mail.gmail.com>
Message-ID: <b6b450b5-a831-bab5-af76-80d8732fa1af@oracle.com>

On 1/31/19 1:26 AM, Andrew Hughes wrote:
> On Wed, 30 Jan 2019 at 20:35, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 1/30/19 11:00 AM, Andrew Hughes wrote:
 >>
>> The current JDK 8 version is
>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html
>>
>> The changes that are proposed are the following:
>>
>> Add the following sentence to the first section ("Standard Names") of
>> the Java Security Standard Algorithm Names specification:
>>
>>       Note that an SE implementation may support additional algorithms
>>       that are not defined in this specification.  As a best practice, if an
>>       algorithm is defined in a subsequent version of this specification and
>>       an implementation of an earlier specification supports that algorithm,
>>       the implementation should use the standard name of the algorithm
>>       that is defined in the subsequent specification.  Each SE
>> implementation
>>       should also document the algorithms that it supports or adds support
>>       for in subsequent update releases.  The algorithms may be documented
>>       in release notes or in a separate document such as the JDK Security
>>       Providers document.
>>
>> Also, the words "JDK Security API" in this section will be changed to
>> "Java SE Security API" (this change has already been made in later SE
>> releases).
>>
>> With these changes added, the beginning of the first section is now the
>> following:
>>
>>       The Java SE Security API requires and uses a set of standard
>>       names for algorithms, certificate and keystore types. This
>>       specification establishes the following names as standard names.
>>
>>       Note that an SE implementation may support additional algorithms
>>       that are not defined in this specification.  As a best practice, if an
>>       algorithm is defined in a subsequent version of this specification and
>>       an implementation of an earlier specification supports that algorithm,
>>       the implementation should use the standard name of the algorithm
>>       that is defined in the subsequent specification.  Each SE
>> implementation
>>       should also document the algorithms that it supports or adds support
>>       for in subsequent update releases.  The algorithms may be documented
>>       in release notes or in a separate document such as the JDK Security
>>       Providers document.
>>
>>       In some cases naming conventions are given for forming names
>>       that are not explicitly listed, to facilitate name consistency
>>       across provider implementations. Items in angle brackets (such as
>>       <digest> and <encryption>) are placeholders to be replaced by a
>>       specific message digest, encryption algorithm, or other name.
>>
>>       Note: Standard names are not case-sensitive.
>>
>> Thanks,
>> Sean
>>
> 
> The changes seem relatively uncontroversial (though I fail to see
> the difference between "JDK Security API" and "Java SE Security API").

JDK APIs are often used to describe public or exported APIs that are 
part of the JDK, but not standard SE APIs. For example, the CSR process 
uses this term for the Scope field [1]. The APIs referenced in this 
specification are all standard SE APIs.

> However, I don't see how I can approve something which is not
> even part of OpenJDK and thus, can't even see.

It is not part of the OpenJDK source code, but this specification is 
referenced as a standard document from various Java SE Security APIs. 
For an example, see [2].

Thanks,
Sean

[1] https://wiki.openjdk.java.net/display/csr/Fields+of+a+CSR+Request
[2] 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/b6dcf8ae496c/src/share/classes/java/security/MessageDigest.java#l150

From shade at redhat.com  Wed Feb  6 16:40:20 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 6 Feb 2019 17:40:20 +0100
Subject: [8u] RFR + RFA 8211926: Catastrophic size_t underflow in
 BitMap::*_large methods
Message-ID: <cb09ed80-c085-b758-c69c-1547e09073f4@redhat.com>

Please review and approve the backport of catastrophic underflow fix in BitMap:

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8211926
      Reporter: Aleksey Shipilev
      Assignee: Aleksey Shipilev
      Priority: P4
      Components: hotspot

  Original Fix:
        12: JDK-8211926, http://hg.openjdk.java.net/jdk/jdk/rev/e5534cc91a10, 88 day(s) ago

  Backports and Forwardports:
        11: 11.0.3, JDK-8214860, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6c90d1d1a03b, 63
day(s) ago
         8: MISSING

8u fix does not apply cleanly, because Bitmap is cleaned up a bit in subsequent releases. There is
also no support for gtest, which means we cannot backport the relevant regression test. Instead, we
have to rely on assert to fire if code is broken. 8u webrev:
  http://cr.openjdk.java.net/~shade/8211926/webrev.8u.01/

Testing: Linux x86_64 build and all jtreg tests (with some unrelated failures)

Thanks,
-Aleksey


From rwestrel at redhat.com  Wed Feb  6 16:54:52 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 06 Feb 2019 17:54:52 +0100
Subject: [8u] RFR + RFA: 8213419: "C2 may hang in
 MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1" and follow up 8214206
Message-ID: <8736p0x3fn.fsf@redhat.com>


I'd like to backport 8213419 and follow up 8214206 to 8u as they can
cause c2 to enter an infinite loop in some corner cases when compiled
with a recent version of gcc.

Neither changes apply cleanly. In particular I dropped the
STATIC_ASSERT() from the globalDefinitions.hpp function. My
understanding is that keeping them requires a backport of 8181449: "Fix
debug.hpp / globalDefinitions.hpp dependency inversion", a big and
complicated change.

Webrevs:

http://cr.openjdk.java.net/~roland/8213419.8u/webrev.00/
http://cr.openjdk.java.net/~roland/8214206.8u/webrev.00/

Initial changes:

https://bugs.openjdk.java.net/browse/JDK-8213419
http://hg.openjdk.java.net/jdk/jdk/rev/1089e8fd8439

https://bugs.openjdk.java.net/browse/JDK-8214206
http://hg.openjdk.java.net/jdk/jdk/rev/7d3cde494494

Roland.

From rkennke at redhat.com  Wed Feb  6 22:29:29 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 6 Feb 2019 23:29:29 +0100
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
In-Reply-To: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
References: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
Message-ID: <c86ab3d6-e514-a5dd-a117-be629e0b640f@redhat.com>

Hi Aleksey,

This change looks good to me. I am not a reviewer in and -updates
project though.

Roman

> Please review and approve the 8u backport for SoftReference race fix.
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8212178
>       Reporter: Roman Kennke
>       Assignee: Aleksey Shipilev
>       Priority: P4
>       Components: xml
> 
>   Original Fix:
>         12: JDK-8212178, http://hg.openjdk.java.net/jdk/jdk/rev/c83ba72377fc, 114 day(s) ago
> 
>   Backports and Forwardports:
>         11: 11.0.2, JDK-8212685, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/5978954e1d74, 110
> day(s) ago
>          8: MISSING
> 
> The patch does not apply cleanly to 8u even after reshuffling, because 8u code does not have
> subsequent patch that migrated JAXP to use generics [*]. The bug in question can be fixed by
> copy-pasting the entire code block from 11u to 8u. Here is the webrev:
>    http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/
> 
> Testing: 8u build, xml benchmarks
> 
> Thanks,
> -Aleksey
> 
> [*] https://bugs.openjdk.java.net/browse/JDK-8181150
> 

From zgu at redhat.com  Thu Feb  7 00:40:59 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Wed, 06 Feb 2019 19:40:59 -0500
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
In-Reply-To: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
References: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
Message-ID: <1549500059.31327.222.camel@redhat.com>

Backport looks accurate, good to me.

-Zhengyu

On Wed, 2019-02-06 at 15:37 +0100, Aleksey Shipilev wrote:
> Please review and approve the 8u backport for SoftReference race fix.
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8212178
>       Reporter: Roman Kennke
>       Assignee: Aleksey Shipilev
>       Priority: P4
>       Components: xml
> 
>   Original Fix:
>         12: JDK-8212178, http://hg.openjdk.java.net/jdk/jdk/rev/c83ba
> 72377fc, 114 day(s) ago
> 
>   Backports and Forwardports:
>         11: 11.0.2, JDK-8212685, http://hg.openjdk.java.net/jdk-updat
> es/jdk11u/rev/5978954e1d74, 110
> day(s) ago
>          8: MISSING
> 
> The patch does not apply cleanly to 8u even after reshuffling,
> because 8u code does not have
> subsequent patch that migrated JAXP to use generics [*]. The bug in
> question can be fixed by
> copy-pasting the entire code block from 11u to 8u. Here is the
> webrev:
>    http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/
> 
> Testing: 8u build, xml benchmarks
> 
> Thanks,
> -Aleksey
> 
> [*] https://bugs.openjdk.java.net/browse/JDK-8181150
> 

From aph at redhat.com  Thu Feb  7 09:35:29 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 7 Feb 2019 09:35:29 +0000
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
In-Reply-To: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
References: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
Message-ID: <d2a21655-9b5d-0a05-04b9-5cc1a03ad9d0@redhat.com>

On 2/6/19 2:37 PM, Aleksey Shipilev wrote:
> Please review and approve the 8u backport for SoftReference race fix.
> 

>    http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/
OK, thanks.

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

From shade at redhat.com  Thu Feb  7 11:28:57 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 12:28:57 +0100
Subject: [8u] RFA 8214059: Undefined behaviour in ADLC
Message-ID: <332e373c-5d94-3d16-2d0d-4d9d89af91b8@redhat.com>

Please approve the push of another UB fix to 8u.

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8214059
      Reporter: Severin Gehwolf
      Assignee: Severin Gehwolf
      Priority: P4
      Components: hotspot

  Original Fix:
        12: JDK-8214059, http://hg.openjdk.java.net/jdk/jdk/rev/e017d2f176d0, 73 day(s) ago

  Backports and Forwardports:
       11: 11.0.3, JDK-8215214, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9e179e01882d, 58
day(s) ago
         8: MISSING


The patch requires reshuffling, but otherwise applies without problems. The webrev, for the record:
  http://cr.openjdk.java.net/~shade/8214059/webrev.8u.01/

Testing: Linux x86_64 fastdebug, all hotspot jtreg tests (some unrelated failures)

Thanks,
-Aleksey

From shade at redhat.com  Thu Feb  7 11:30:00 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 12:30:00 +0100
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
In-Reply-To: <d2a21655-9b5d-0a05-04b9-5cc1a03ad9d0@redhat.com>
References: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
 <d2a21655-9b5d-0a05-04b9-5cc1a03ad9d0@redhat.com>
Message-ID: <fa3068d0-b757-a554-5e28-a9c8e95b59fb@redhat.com>

On 2/7/19 10:35 AM, Andrew Haley wrote:
> On 2/6/19 2:37 PM, Aleksey Shipilev wrote:
>> Please review and approve the 8u backport for SoftReference race fix.
>>
> 
>>    http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/
> OK, thanks.

That means "Approved", right?

Thanks,
-Aleksey


From shade at redhat.com  Thu Feb  7 11:52:18 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 12:52:18 +0100
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
Message-ID: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>

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

This is botched backport to 8u, which fails the jtreg tests now in 8u. Note the fix is not the
backport, but the actual 8u-specific fix.

Fix:

diff -r 1d64329dec0a -r 38c789c8c590 test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java
--- a/test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java       Thu Feb 07 10:59:56 2019 +0100
+++ b/test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java       Thu Feb 07 12:50:38 2019 +0100
@@ -25,7 +25,7 @@
  * @test TestCrashOnOutOfMemoryError
  * @summary Test using -XX:+CrashOnOutOfMemoryError
  * @library /testlibrary
- * @build jdk.test.lib.*
+ * @build com.oracle.java.testlibrary.*
  * @run driver TestCrashOnOutOfMemoryError
  * @bug 8138745
  */
diff -r 1d64329dec0a -r 38c789c8c590 test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java
--- a/test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java        Thu Feb 07 10:59:56 2019 +0100
+++ b/test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java        Thu Feb 07 12:50:38 2019 +0100
@@ -25,7 +25,7 @@
  * @test TestExitOnOutOfMemoryError
  * @summary Test using -XX:ExitOnOutOfMemoryError
  * @library /testlibrary
- * @build jdk.test.lib.*
+ * @build com.oracle.java.testlibrary.*
  * @run driver TestExitOnOutOfMemoryError
  * @bug 8138745
  */

Testing: Linux x86_64 fastdebug, jtreg runtime/ErrorHandling

Thanks,
-Aleksey


From shade at redhat.com  Thu Feb  7 12:21:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 13:21:22 +0100
Subject: [8u] RFA (XS) 8076274: [TESTBUG] Remove @ignore from
 runtime\NMT\JcmdDetailDiff.java
Message-ID: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>

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

Patch applies with reshuffling. Here it is:

diff -r d26d58ed7520 -r 30cbce176b67 test/runtime/NMT/JcmdDetailDiff.java
--- a/test/runtime/NMT/JcmdDetailDiff.java      Thu Feb 07 12:57:24 2019 +0100
+++ b/test/runtime/NMT/JcmdDetailDiff.java      Thu Feb 07 13:18:15 2019 +0100
@@ -26,7 +26,6 @@
  * @summary run NMT baseline, allocate memory and verify output from detail.diff
  * @key nmt jcmd
  * @library /testlibrary /testlibrary/whitebox
- * @ignore
  * @build JcmdDetailDiff
  * @run main ClassFileInstaller sun.hotspot.WhiteBox
  * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
-XX:NativeMemoryTracking=detail JcmdDetailDiff

Zhengyu, can you confirm this is okay for 8u? It seems like an innocious overlook, but maybe the bug
was ignored awaiting some other NMT fix? If so, the testbug issue should have linked NMT bugs
issues, and there is none.

Testing: Linux x86_64 fastdebug, jtreg test/runtime/NMT/JcmdDetailDiff.java

Thanks,
-Aleksey


From david.holmes at oracle.com  Thu Feb  7 12:31:09 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Feb 2019 22:31:09 +1000
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
Message-ID: <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>

On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8218613
> 
> This is botched backport to 8u, which fails the jtreg tests now in 8u. Note the fix is not the
> backport, but the actual 8u-specific fix.

IIRC the incorrect @build is not a fatal error for earlier jtreg 
version. AFAICS we still use jtreg 4.1 for testing 8u internally.

David

> Fix:
> 
> diff -r 1d64329dec0a -r 38c789c8c590 test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java
> --- a/test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java       Thu Feb 07 10:59:56 2019 +0100
> +++ b/test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java       Thu Feb 07 12:50:38 2019 +0100
> @@ -25,7 +25,7 @@
>    * @test TestCrashOnOutOfMemoryError
>    * @summary Test using -XX:+CrashOnOutOfMemoryError
>    * @library /testlibrary
> - * @build jdk.test.lib.*
> + * @build com.oracle.java.testlibrary.*
>    * @run driver TestCrashOnOutOfMemoryError
>    * @bug 8138745
>    */
> diff -r 1d64329dec0a -r 38c789c8c590 test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java
> --- a/test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java        Thu Feb 07 10:59:56 2019 +0100
> +++ b/test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java        Thu Feb 07 12:50:38 2019 +0100
> @@ -25,7 +25,7 @@
>    * @test TestExitOnOutOfMemoryError
>    * @summary Test using -XX:ExitOnOutOfMemoryError
>    * @library /testlibrary
> - * @build jdk.test.lib.*
> + * @build com.oracle.java.testlibrary.*
>    * @run driver TestExitOnOutOfMemoryError
>    * @bug 8138745
>    */
> 
> Testing: Linux x86_64 fastdebug, jtreg runtime/ErrorHandling
> 
> Thanks,
> -Aleksey
> 

From aph at redhat.com  Thu Feb  7 13:10:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 7 Feb 2019 13:10:50 +0000
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
In-Reply-To: <fa3068d0-b757-a554-5e28-a9c8e95b59fb@redhat.com>
References: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
 <d2a21655-9b5d-0a05-04b9-5cc1a03ad9d0@redhat.com>
 <fa3068d0-b757-a554-5e28-a9c8e95b59fb@redhat.com>
Message-ID: <6c1b2596-679c-5d49-7bdd-16be187f4b09@redhat.com>

On 2/7/19 11:30 AM, Aleksey Shipilev wrote:
> On 2/7/19 10:35 AM, Andrew Haley wrote:
>> On 2/6/19 2:37 PM, Aleksey Shipilev wrote:
>>> Please review and approve the 8u backport for SoftReference race fix.
>>>
>>
>>>    http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/
>> OK, thanks.
> 
> That means "Approved", right?

Yes.

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

From zgu at redhat.com  Thu Feb  7 14:33:05 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Thu, 07 Feb 2019 09:33:05 -0500
Subject: [8u] RFA (XS) 8076274: [TESTBUG] Remove @ignore from
 runtime\NMT\JcmdDetailDiff.java
In-Reply-To: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>
References: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>
Message-ID: <1549549985.31327.231.camel@redhat.com>

Hi Aleksey,

> Zhengyu, can you confirm this is okay for 8u? It seems like an
> innocious overlook, but maybe the bug
> was ignored awaiting some other NMT fix? If so, the testbug issue
> should have linked NMT bugs
> issues, and there is none.
I don't see any problem, so looks good.

A bunch of NMT were added here [1], all annotated with "ignore". Maybe
this is the changeset to re-enable it.

[1] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/017b0145f20c

Thanks,

-Zhengyu

> 
> Testing: Linux x86_64 fastdebug, jtreg
> test/runtime/NMT/JcmdDetailDiff.java
> 
> Thanks,
> -Aleksey
> 

From shade at redhat.com  Thu Feb  7 14:42:42 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 15:42:42 +0100
Subject: [8u] RFR + RFA (S) 8212178: Soft reference reclamation race in
 com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator
In-Reply-To: <6c1b2596-679c-5d49-7bdd-16be187f4b09@redhat.com>
References: <f42c3c6e-b44b-0189-57dd-fc6ea076c6e2@redhat.com>
 <d2a21655-9b5d-0a05-04b9-5cc1a03ad9d0@redhat.com>
 <fa3068d0-b757-a554-5e28-a9c8e95b59fb@redhat.com>
 <6c1b2596-679c-5d49-7bdd-16be187f4b09@redhat.com>
Message-ID: <af7ff5ef-1754-c735-f0cf-2c5dd9950d0e@redhat.com>

On 2/7/19 2:10 PM, Andrew Haley wrote:
> On 2/7/19 11:30 AM, Aleksey Shipilev wrote:
>> On 2/7/19 10:35 AM, Andrew Haley wrote:
>>> On 2/6/19 2:37 PM, Aleksey Shipilev wrote:
>>>> Please review and approve the 8u backport for SoftReference race fix.
>>>>
>>>
>>>>    http://cr.openjdk.java.net/~shade/8212178/webrev.8u.01/
>>> OK, thanks.
>>
>> That means "Approved", right?
> 
> Yes.

Thank you, pushed.

-Aleksey


From shade at redhat.com  Thu Feb  7 14:44:06 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Feb 2019 15:44:06 +0100
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
Message-ID: <a65e512a-fd30-b9b5-81de-f92685f49962@redhat.com>

On 2/7/19 1:31 PM, David Holmes wrote:
> On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
>> Bug:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8218613
>>
>> This is botched backport to 8u, which fails the jtreg tests now in 8u. Note the fix is not the
>> backport, but the actual 8u-specific fix.
> 
> IIRC the incorrect @build is not a fatal error for earlier jtreg version. AFAICS we still use jtreg
> 4.1 for testing 8u internally.

Looks like it. I am testing with latest jtreg on all JDK versions, so these tests fail for me.

-Aleksey


From zgu at redhat.com  Thu Feb  7 16:02:21 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Thu, 07 Feb 2019 11:02:21 -0500
Subject: [8u] RFA (XS) 8076274: [TESTBUG] Remove @ignore from
 runtime\NMT\JcmdDetailDiff.java
In-Reply-To: <1549549985.31327.231.camel@redhat.com>
References: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>
 <1549549985.31327.231.camel@redhat.com>
Message-ID: <1549555341.31327.239.camel@redhat.com>

Hi Aleksey,

Just found this: https://bugs.openjdk.java.net/browse/JDK-8200109

But it was filed against JDK11.

-Zhengyu

On Thu, 2019-02-07 at 09:33 -0500, zgu at redhat.com wrote:
> Hi Aleksey,
> 
> > Zhengyu, can you confirm this is okay for 8u? It seems like an
> > innocious overlook, but maybe the bug
> > was ignored awaiting some other NMT fix? If so, the testbug issue
> > should have linked NMT bugs
> > issues, and there is none.
> 
> I don't see any problem, so looks good.
> 
> A bunch of NMT were added here [1], all annotated with "ignore".
> Maybe
> this is the changeset to re-enable it.
> 
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/017b0145f20c
> 
> Thanks,
> 
> -Zhengyu
> 
> > 
> > Testing: Linux x86_64 fastdebug, jtreg
> > test/runtime/NMT/JcmdDetailDiff.java
> > 
> > Thanks,
> > -Aleksey
> > 

From martinrb at google.com  Thu Feb  7 17:28:21 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 7 Feb 2019 09:28:21 -0800
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
Message-ID: <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>

On Thu, Feb 7, 2019 at 4:33 AM David Holmes <david.holmes at oracle.com> wrote:

> On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
> > Bug:
> >    https://bugs.openjdk.java.net/browse/JDK-8218613
> >
> > This is botched backport to 8u, which fails the jtreg tests now in 8u.
> Note the fix is not the
> > backport, but the actual 8u-specific fix.
>
> IIRC the incorrect @build is not a fatal error for earlier jtreg
> version. AFAICS we still use jtreg 4.1 for testing 8u internally.
>

This surprised me.  Of course, the incentive to update to new jtreg
versions is generally because jdk-latest needs it, but we've always
successfully adopted any newer jtreg to test older jdks as well.
(but we don't run as many tests as you do)

From iris.clark at oracle.com  Thu Feb  7 17:34:07 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 7 Feb 2019 17:34:07 +0000 (UTC)
Subject: Maintenance Draft Reviews for Java SE 8 (JSR 337) and Java SE 11 (JSR
 384) posted to jcp.org
Message-ID: <ecd1c556-87ac-4d42-ba23-be1af7048e22@default>

The Maintenance Draft Review [0] contents for the Java SE 8 (JSR 337) and
Java SE 11 (JSR 384) Platforms were posted to jcp.org on 5 February 2019 [1,2].
The contents correspond to the updates outlined in the announcement [3,4] of
our intention to conduct the Review.  The Review ends on 7 March 2019 with the
Ballot running from 12-18 March 2019.

Assuming that the Maintenance Review Ballot succeeds, Oracle will produce
Maintenance Releases [5] of JSR 337 and JSR 384 in late March 2019.

Thanks,
iris

[0] https://jcp.org/en/procedures/jcp2#3.6.2
[1] https://jcp.org/en/jsr/detail?id=337
[2] https://jcp.org/en/jsr/detail?id=384
[3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008324.html
[4] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html
[5] https://jcp.org/en/procedures/jcp2#3.6.4

From aph at redhat.com  Thu Feb  7 18:01:55 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 7 Feb 2019 18:01:55 +0000
Subject: RFD: Draft guidelines for working on jdk8u
Message-ID: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>

OpenJDK 8 is a long-term stable release of OpenJDK. Our primary goal
is to maintain it, fixing significant bugs and especially security
problems as we go along. The "first, do no harm" principle applies: we
must not break things.

We do not yet have much experience with our test systems, so for the
first couple of quarters we should be very cautious. Later on we can
be more adventurous, but for now it's "bug fixes only".

All fixes for significant bugs that do not change behavioural
compatibility [1] may be applied to jdk8u. To use the language of the
JDK 6 project, by default such fixes are assumed to be applicable to
jdk8u, especially if having "soaked" in later JDK releases for a time
without incident.

By "significant" I mean any bug that affects runtime behaviour in a
way that either produces incorrect results or crashes the VM,
especially TCK failures. Failures that are due solely to bizarre or
unreasonable combinations of -XX: command-line parameters probably
don't reach the bar of significance, and fixing them will carry a
non-zero risk of breaking something, so we should err on the size of
caution.

Build failures on all platforms, including 32-bit ones, are assumed to
be applicable. Also, there is a good deal of C++ code with Undefined
Behaviour in HotSpot, and such bugs tend to cause failures with more
recent C++ compilers. While all UB fixes may be applied to jdk8u, they
should be submitted to the current development tree first.

Occasionally we might have to make changes which raise compatibility
issues. We will liase with the Compatibility & Specification Review
(CSR) Group.

Once a quarter, we will snapshot the jdk8u development tree and
prepare a Critical Patch Update (CPU) release. Once the snapshot has
been taken the engineers working on the CPU will work in the dark,
sharing the patches with only the OpenJDK Vulnerability Group. Any
patches not committed to jdk8u at the time of the snapshot will
probably have to wait for a later release. I don't propose to make any
non-CPU releases: one release a quarter should be quite enough for
jdk8u. However, if an urgent problem arises we might need to do make
an intermediate release.

Having said all of that, there is considerable customer demand for
backports of features from later OpenJDK releases. I don't intend to
forbid such backports, but strict rules will apply. Features which
apply to ports in jdk8u must have the property that they can be
disabled altogether by the use of a command-line switch. This switch
should turn the feature into a NOP, so that it does not affect the
rest of the system in any way. Reviewers should ensure that every hunk
in such a changeset is guarded by an if (Feature_enabled) statement or
something similar. This will also allow Feature_enabled to be made a
compile-time constant, and if set to false this will allow images to
be created without the feature.

With regard to the likely feature backports, there are several
possibilities, in particular the Java Flight Recorder (JFR).  It'll
take a while to produce the JFR backport, so we should perhaps create
a tree for it now by cloning the jdk8u-dev tree. Patches should be
reviewed, but it's obviously a work in progress.

[1] https://blogs.oracle.com/darcy/kinds-of-compatibility:-source,-binary,-and-behavioral

Comments welcome.

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

From mbalao at redhat.com  Thu Feb  7 21:07:15 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 7 Feb 2019 18:07:15 -0300
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
Message-ID: <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>

On 2/7/19 3:01 PM, Andrew Haley wrote:
> 
> Comments welcome.
> 

I'd like to propose that for trivial backports/changes (i.e.: typos,
copyright fixes, etc.), a jdk8u reviewer approval is enough to have the
patch in. In case that a reviewer is not sure about the triviality of a
backport/change, other reviewers or maintainer approval may be required.
This would reduce unnecessary overhead I believe.

From aph at redhat.com  Fri Feb  8 09:10:03 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 09:10:03 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
Message-ID: <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>

On 2/7/19 9:07 PM, Martin Balao wrote:
> On 2/7/19 3:01 PM, Andrew Haley wrote:
>
>> Comments welcome.
> 
> I'd like to propose that for trivial backports/changes (i.e.: typos,
> copyright fixes, etc.), a jdk8u reviewer approval is enough to have the
> patch in. In case that a reviewer is not sure about the triviality of a
> backport/change, other reviewers or maintainer approval may be required.
> This would reduce unnecessary overhead I believe.

I'm not at all convinced that we need to use the double-review system. Once
people are aware of the rules, any qualified jdk8u reviewer should be able
to apply them.

Having said that, we must tag the bugs chosen to be applied to 8u in the
bug database. I don't think I mentioned that in my posting.

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

From christoph.langer at sap.com  Fri Feb  8 10:25:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 8 Feb 2019 10:25:34 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
Message-ID: <c537e8b745b04652831141dadb87a2e3@sap.com>

Hi Andrew,

> > I'd like to propose that for trivial backports/changes (i.e.: typos,
> > copyright fixes, etc.), a jdk8u reviewer approval is enough to have the
> > patch in. In case that a reviewer is not sure about the triviality of a
> > backport/change, other reviewers or maintainer approval may be required.
> > This would reduce unnecessary overhead I believe.
> 
> I'm not at all convinced that we need to use the double-review system. Once
> people are aware of the rules, any qualified jdk8u reviewer should be able
> to apply them.
> 
> Having said that, we must tag the bugs chosen to be applied to 8u in the
> bug database. I don't think I mentioned that in my posting.

You mean that we install something like a "jdk8u-fix-request" labeling procedure where the maintainer will approve each fix by "jdk8u-fix-yes" before it can be pushed to 8u, no matter how trivial the fix is?
Essentially the same as we handle jdk11 and higher backports? I'd be very much for that...

Best regards
Christoph


From aph at redhat.com  Fri Feb  8 13:49:38 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 13:49:38 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <c537e8b745b04652831141dadb87a2e3@sap.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
Message-ID: <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>

On 2/8/19 10:25 AM, Langer, Christoph wrote:
> Hi Andrew,
> 
>>> I'd like to propose that for trivial backports/changes (i.e.: typos,
>>> copyright fixes, etc.), a jdk8u reviewer approval is enough to have the
>>> patch in. In case that a reviewer is not sure about the triviality of a
>>> backport/change, other reviewers or maintainer approval may be required.
>>> This would reduce unnecessary overhead I believe.
>>
>> I'm not at all convinced that we need to use the double-review system. Once
>> people are aware of the rules, any qualified jdk8u reviewer should be able
>> to apply them.
>>
>> Having said that, we must tag the bugs chosen to be applied to 8u in the
>> bug database. I don't think I mentioned that in my posting.
> 
> You mean that we install something like a "jdk8u-fix-request"
> labeling procedure where the maintainer will approve each fix by
> "jdk8u-fix-yes" before it can be pushed to 8u, no matter how trivial
> the fix is?

I see. That does sound sensible, but perhaps we should have an
"obvious, trivial" exception, especially for the times when the build
is broken.

> Essentially the same as we handle jdk11 and higher backports? I'd be
> very much for that...

I'm not sure. I welcome further input.

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

From aph at redhat.com  Fri Feb  8 13:50:59 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 13:50:59 +0000
Subject: [8u] RFA (XS) 8076274: [TESTBUG] Remove @ignore from
 runtime\NMT\JcmdDetailDiff.java
In-Reply-To: <1549555341.31327.239.camel@redhat.com>
References: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>
 <1549549985.31327.231.camel@redhat.com>
 <1549555341.31327.239.camel@redhat.com>
Message-ID: <ccbaa893-6ba3-b953-db1c-110f3b25ab47@redhat.com>

On 2/7/19 4:02 PM, zgu at redhat.com wrote:
> Just found this: https://bugs.openjdk.java.net/browse/JDK-8200109
> 
> But it was filed against JDK11.

When you two have finished your discussion, please ping me with what
you'd like me to approve.

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

From aph at redhat.com  Fri Feb  8 13:52:14 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 13:52:14 +0000
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
 <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>
Message-ID: <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>

On 2/7/19 5:28 PM, Martin Buchholz wrote:
> On Thu, Feb 7, 2019 at 4:33 AM David Holmes <david.holmes at oracle.com> wrote:
> 
>> On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
>>> Bug:
>>>    https://bugs.openjdk.java.net/browse/JDK-8218613
>>>
>>> This is botched backport to 8u, which fails the jtreg tests now in 8u.
>> Note the fix is not the
>>> backport, but the actual 8u-specific fix.
>>
>> IIRC the incorrect @build is not a fatal error for earlier jtreg
>> version. AFAICS we still use jtreg 4.1 for testing 8u internally.
>>
> 
> This surprised me.  Of course, the incentive to update to new jtreg
> versions is generally because jdk-latest needs it, but we've always
> successfully adopted any newer jtreg to test older jdks as well.
> (but we don't run as many tests as you do)

I want to use the current jtreg for everything if at all possible.

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

From aph at redhat.com  Fri Feb  8 13:54:07 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 13:54:07 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
Message-ID: <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>

On 2/8/19 1:49 PM, Andrew Haley wrote:
> I'm not sure. I welcome further input.

Just to be clear: we must have tags in the bug database for 8u backports,
I'm just ruminating on whether we must have maintainer approval for every
little patch. IMO, anyone who is a jdk8u reviewer should be able to apply
the rules for minor changes, and it's only for changes with significant
risk where we need multiple reviews.

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

From shade at redhat.com  Fri Feb  8 13:54:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 14:54:22 +0100
Subject: [8u] RFA (XS) 8076274: [TESTBUG] Remove @ignore from
 runtime\NMT\JcmdDetailDiff.java
In-Reply-To: <ccbaa893-6ba3-b953-db1c-110f3b25ab47@redhat.com>
References: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>
 <1549549985.31327.231.camel@redhat.com>
 <1549555341.31327.239.camel@redhat.com>
 <ccbaa893-6ba3-b953-db1c-110f3b25ab47@redhat.com>
Message-ID: <eae980a0-cbbf-21f5-7d8d-6db9cf433b8b@redhat.com>

On 2/8/19 2:50 PM, Andrew Haley wrote:
> On 2/7/19 4:02 PM, zgu at redhat.com wrote:
>> Just found this: https://bugs.openjdk.java.net/browse/JDK-8200109
>>
>> But it was filed against JDK11.
> 
> When you two have finished your discussion, please ping me with what
> you'd like me to approve.

I think we should backport both un-ignoring the test case (8076274, this one) and the rare assertion
failure that Zhengyu has the fix for for dev (8200109). 8200109 would trickle down quite a bit
later, so we can either wait for it to arrive, or commit the test fix right away. I am leaning
towards un-ignoring the test today, so that we can catch other problems early, at the cost of
potential intermittent "false" positive.

-Aleksey


From shade at redhat.com  Fri Feb  8 14:02:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 15:02:22 +0100
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
Message-ID: <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>

On 2/8/19 2:54 PM, Andrew Haley wrote:
> On 2/8/19 1:49 PM, Andrew Haley wrote:
>> I'm not sure. I welcome further input.
> 
> Just to be clear: we must have tags in the bug database for 8u backports,
> I'm just ruminating on whether we must have maintainer approval for every
> little patch. IMO, anyone who is a jdk8u reviewer should be able to apply
> the rules for minor changes, and it's only for changes with significant
> risk where we need multiple reviews.

I think _maintainers_ have to approve every patch, no matter how little it looks like. "JDK 8u
reviewer" is too broad of the group [1], and we cannot expect them to have cached understanding of
how the 8u updates project works. With JBS tagging, the work for maintainers to approve the fixes
should be small. And, we can also have more maintainers, right? (ducks)

Thanks,
-Aleksey

[1] http://openjdk.java.net/census#jdk8u


From aph at redhat.com  Fri Feb  8 14:04:09 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 14:04:09 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
Message-ID: <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>

On 2/8/19 2:02 PM, Aleksey Shipilev wrote:
> On 2/8/19 2:54 PM, Andrew Haley wrote:
>> On 2/8/19 1:49 PM, Andrew Haley wrote:
>>> I'm not sure. I welcome further input.
>>
>> Just to be clear: we must have tags in the bug database for 8u backports,
>> I'm just ruminating on whether we must have maintainer approval for every
>> little patch. IMO, anyone who is a jdk8u reviewer should be able to apply
>> the rules for minor changes, and it's only for changes with significant
>> risk where we need multiple reviews.
> 
> I think _maintainers_ have to approve every patch, no matter how
> little it looks like. "JDK 8u reviewer" is too broad of the group
> [1], and we cannot expect them to have cached understanding of how
> the 8u updates project works.

Hmph. Should they really be reviewers, then?

> With JBS tagging, the work for maintainers to approve the fixes
> should be small. And, we can also have more maintainers, right?
> (ducks)

You'll be ideal, I imagine.

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

From shade at redhat.com  Fri Feb  8 14:08:35 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 15:08:35 +0100
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
 <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
Message-ID: <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>

On 2/8/19 3:04 PM, Andrew Haley wrote:
> On 2/8/19 2:02 PM, Aleksey Shipilev wrote:
>> On 2/8/19 2:54 PM, Andrew Haley wrote:
>>> On 2/8/19 1:49 PM, Andrew Haley wrote:
>>>> I'm not sure. I welcome further input.
>>>
>>> Just to be clear: we must have tags in the bug database for 8u backports,
>>> I'm just ruminating on whether we must have maintainer approval for every
>>> little patch. IMO, anyone who is a jdk8u reviewer should be able to apply
>>> the rules for minor changes, and it's only for changes with significant
>>> risk where we need multiple reviews.
>>
>> I think _maintainers_ have to approve every patch, no matter how
>> little it looks like. "JDK 8u reviewer" is too broad of the group
>> [1], and we cannot expect them to have cached understanding of how
>> the 8u updates project works.
> 
> Hmph. Should they really be reviewers, then?

Yes, once project moves into "Updates", the reviewer designation becomes less important. I think it
still matters if you have a patch to actually review code-wise, for example the code that does not
apply cleanly to 8u at all. But maintainers have to accept the patch for inclusion to 8u anyway,
assessing it from maintainers' perspective: risks, importance, etc.

So, maintainers have to ack. Maintainers can defer to actual reviewers to judge if code is sound, if
needed. Therefore, for simple/clean patches, (single) maintainer ack should be enough. I think
that's the way it worked before, and I don't see why we should change that.

>> With JBS tagging, the work for maintainers to approve the fixes
>> should be small. And, we can also have more maintainers, right?
>> (ducks)
> 
> You'll be ideal, I imagine.

I see what you did there!

-Aleksey



From aph at redhat.com  Fri Feb  8 14:12:43 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 14:12:43 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
 <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
 <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>
Message-ID: <9e11801a-4c64-517b-2bdf-a384ad99c64a@redhat.com>

On 2/8/19 2:08 PM, Aleksey Shipilev wrote:

> So, maintainers have to ack. Maintainers can defer to actual
> reviewers to judge if code is sound, if needed. Therefore, for
> simple/clean patches, (single) maintainer ack should be enough. I
> think that's the way it worked before, and I don't see why we should
> change that.

OK,as long as there really is a good reason and it's not just
inherited baggage.

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

From zgu at redhat.com  Fri Feb  8 14:14:52 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Fri, 08 Feb 2019 09:14:52 -0500
Subject: [8u] RFA (XS) 8076274: [TESTBUG] Remove @ignore from
 runtime\NMT\JcmdDetailDiff.java
In-Reply-To: <eae980a0-cbbf-21f5-7d8d-6db9cf433b8b@redhat.com>
References: <be14229d-6b04-e515-eae2-f5d475a5fb85@redhat.com>
 <1549549985.31327.231.camel@redhat.com>
 <1549555341.31327.239.camel@redhat.com>
 <ccbaa893-6ba3-b953-db1c-110f3b25ab47@redhat.com>
 <eae980a0-cbbf-21f5-7d8d-6db9cf433b8b@redhat.com>
Message-ID: <1549635292.31327.265.camel@redhat.com>

On Fri, 2019-02-08 at 14:54 +0100, Aleksey Shipilev wrote:
> On 2/8/19 2:50 PM, Andrew Haley wrote:
> > On 2/7/19 4:02 PM, zgu at redhat.com wrote:
> > > Just found this: https://bugs.openjdk.java.net/browse/JDK-8200109
> > > 
> > > But it was filed against JDK11.
> > 
> > When you two have finished your discussion, please ping me with
> > what
> > you'd like me to approve.
> 
> I think we should backport both un-ignoring the test case (8076274,
> this one) and the rare assertion
> failure that Zhengyu has the fix for for dev (8200109). 8200109 would
> trickle down quite a bit
> later, so we can either wait for it to arrive, or commit the test fix
> right away. I am leaning
> towards un-ignoring the test today, so that we can catch other
> problems early, at the cost of
> potential intermittent "false" positive.

Agree. 8076274 seems to happen rare enough to cause concerns. I will
backport 8200109 ASAP it lands in JDK13.

Thanks,

-Zhengyu

> 
> -Aleksey
> 

From christoph.langer at sap.com  Fri Feb  8 14:17:43 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 8 Feb 2019 14:17:43 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <9e11801a-4c64-517b-2bdf-a384ad99c64a@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
 <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
 <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>
 <9e11801a-4c64-517b-2bdf-a384ad99c64a@redhat.com>
Message-ID: <54f5c203b09b485cbe187d5924dbe28f@sap.com>

Hi,

> Subject: Re: RFD: Draft guidelines for working on jdk8u
> 
> On 2/8/19 2:08 PM, Aleksey Shipilev wrote:
> 
> > So, maintainers have to ack. Maintainers can defer to actual
> > reviewers to judge if code is sound, if needed. Therefore, for
> > simple/clean patches, (single) maintainer ack should be enough. I
> > think that's the way it worked before, and I don't see why we should
> > change that.
> 
> OK,as long as there really is a good reason and it's not just
> inherited baggage.

I'm completely with Aleksey in this discussion.

The maintainers duty should be shared on multiple shoulders probably and maintainers should have a common understanding about the criteria that apply to the approval decision.

Best regards
Christoph


From shade at redhat.com  Fri Feb  8 14:26:49 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 15:26:49 +0100
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <54f5c203b09b485cbe187d5924dbe28f@sap.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
 <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
 <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>
 <9e11801a-4c64-517b-2bdf-a384ad99c64a@redhat.com>
 <54f5c203b09b485cbe187d5924dbe28f@sap.com>
Message-ID: <fefc0e53-814d-fd9c-161c-5bf0d57a6b3e@redhat.com>

On 2/8/19 3:17 PM, Langer, Christoph wrote:
> The maintainers duty should be shared on multiple shoulders probably and maintainers should have
> a common understanding about the criteria that apply to the approval decision.

Yes.

Leftover wrinkle here is to codify that if a maintainer (like maybe myself in the future) submits
the RFA, it has to be acked by _another_ maintainer :) This rule is obvious, but obvious rules need
to be spelled out anyway.

Changing the process to jdk8u-fix-requests would be a nice addition, from both backporter and
maintainer perspective. It also allows to manage and track backporting work [1][2] without going
certifiably insane. I am glad it is on the table.

-Aleksey

[1] https://bugs.openjdk.java.net/issues/?filter=34346
[2] https://builds.shipilev.net/backports-monitor/redhat-openjdk.txt


From aph at redhat.com  Fri Feb  8 14:29:35 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 14:29:35 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <fefc0e53-814d-fd9c-161c-5bf0d57a6b3e@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
 <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
 <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>
 <9e11801a-4c64-517b-2bdf-a384ad99c64a@redhat.com>
 <54f5c203b09b485cbe187d5924dbe28f@sap.com>
 <fefc0e53-814d-fd9c-161c-5bf0d57a6b3e@redhat.com>
Message-ID: <f53fc446-1044-9b0c-d54d-e1624f354378@redhat.com>

On 2/8/19 2:26 PM, Aleksey Shipilev wrote:
> Changing the process to jdk8u-fix-requests would be a nice addition, from both backporter and
> maintainer perspective. It also allows to manage and track backporting work [1][2] without going
> certifiably insane.

Please be precise about exactly what you mean by "Changing the process
to jdk8u-fix-requests". Is it simply that we have to have one
maintainer ack and appropriate fix requests in the database. If I'm
going to write this up I have to know.

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

From shade at redhat.com  Fri Feb  8 14:41:30 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 15:41:30 +0100
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <f53fc446-1044-9b0c-d54d-e1624f354378@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <fe1dde60-e487-6016-63d9-8ba632e23893@redhat.com>
 <8cdd3fbd-bfcf-90df-8d9f-f558e3c02e6a@redhat.com>
 <c537e8b745b04652831141dadb87a2e3@sap.com>
 <bf85128e-0c04-265d-59e7-037d3736b1f4@redhat.com>
 <acb30d59-af0c-03b2-6df2-92b701053238@redhat.com>
 <2ca2c856-7dd6-42fa-9cef-1558be8677db@redhat.com>
 <a6f28217-7089-17e7-9749-fab7021c8de8@redhat.com>
 <3d647dbc-687f-b9b2-ab6c-4d869f20648a@redhat.com>
 <9e11801a-4c64-517b-2bdf-a384ad99c64a@redhat.com>
 <54f5c203b09b485cbe187d5924dbe28f@sap.com>
 <fefc0e53-814d-fd9c-161c-5bf0d57a6b3e@redhat.com>
 <f53fc446-1044-9b0c-d54d-e1624f354378@redhat.com>
Message-ID: <55c8b62b-d4ec-17cc-6480-d0690a1cffa2@redhat.com>

On 2/8/19 3:29 PM, Andrew Haley wrote:
> On 2/8/19 2:26 PM, Aleksey Shipilev wrote:
>> Changing the process to jdk8u-fix-requests would be a nice addition, from both backporter and
>> maintainer perspective. It also allows to manage and track backporting work [1][2] without going
>> certifiably insane.
> 
> Please be precise about exactly what you mean by "Changing the process
> to jdk8u-fix-requests". Is it simply that we have to have one
> maintainer ack and appropriate fix requests in the database. If I'm
> going to write this up I have to know.

I would prefer to copy 11/12u process to 8u:
  https://openjdk.java.net/projects/jdk-updates/approval.html

In that process, the "maintainer ack" is setting "jdkX-fix-yes" in relevant JIRA issue there. Once
you get that on the JIRA issue, you are good to push. When, how, and what issues actually get the
"jdkX-fix-yes" tag is solely at maintainers' discretion.

This would be an improvement over the current need to send the RFA to jdk8u-dev for every little
patch, every time copypasting lots of bug metadata that is already present in the bug tracker.

-Aleksey


From shade at redhat.com  Fri Feb  8 15:40:12 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 16:40:12 +0100
Subject: [8u] RFR + RFA: 8213419: "C2 may hang in
 MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1" and follow up 8214206
In-Reply-To: <8736p0x3fn.fsf@redhat.com>
References: <8736p0x3fn.fsf@redhat.com>
Message-ID: <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com>

On 2/6/19 5:54 PM, Roland Westrelin wrote:
> 
> I'd like to backport 8213419 and follow up 8214206 to 8u as they can
> cause c2 to enter an infinite loop in some corner cases when compiled
> with a recent version of gcc.
> 
> Neither changes apply cleanly. In particular I dropped the
> STATIC_ASSERT() from the globalDefinitions.hpp function. My
> understanding is that keeping them requires a backport of 8181449: "Fix
> debug.hpp / globalDefinitions.hpp dependency inversion", a big and
> complicated change.
> 
> Webrevs:
> 
> http://cr.openjdk.java.net/~roland/8213419.8u/webrev.00/

Changes look good.

Where's the regression test? MultiplyByIntegerMinHang.java is in original change.

> http://cr.openjdk.java.net/~roland/8214206.8u/webrev.00/

Changes look good.

Let me build it on a few platforms (e.g. 32-bits) to check everything is fine.

Thanks,
-Aleksey


From shade at redhat.com  Fri Feb  8 16:47:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 8 Feb 2019 17:47:27 +0100
Subject: [8u] RFR + RFA: 8213419: "C2 may hang in
 MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1" and follow up 8214206
In-Reply-To: <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com>
References: <8736p0x3fn.fsf@redhat.com>
 <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com>
Message-ID: <f1965488-96f6-de05-fac6-3e985b134113@redhat.com>

On 2/8/19 4:40 PM, Aleksey Shipilev wrote:
> On 2/6/19 5:54 PM, Roland Westrelin wrote:
>>
>> I'd like to backport 8213419 and follow up 8214206 to 8u as they can
>> cause c2 to enter an infinite loop in some corner cases when compiled
>> with a recent version of gcc.
>>
>> Neither changes apply cleanly. In particular I dropped the
>> STATIC_ASSERT() from the globalDefinitions.hpp function. My
>> understanding is that keeping them requires a backport of 8181449: "Fix
>> debug.hpp / globalDefinitions.hpp dependency inversion", a big and
>> complicated change.
>>
>> Webrevs:
>>
>> http://cr.openjdk.java.net/~roland/8213419.8u/webrev.00/
> 
> Changes look good.
> 
> Where's the regression test? MultiplyByIntegerMinHang.java is in original change.
> 
>> http://cr.openjdk.java.net/~roland/8214206.8u/webrev.00/
> 
> Changes look good.
> 
> Let me build it on a few platforms (e.g. 32-bits) to check everything is fine.

Builds fine on:
 * linux-x86-normal-minimal1-fastdebug
 * linux-x86_64-normal-server-fastdebug
 * linux-arm-normal-zero-fastdebug
 * linux-x86-normal-server-fastdebug
 * linux-x86_64-normal-zero-fastdebug

-Aleksey


From rwestrel at redhat.com  Fri Feb  8 16:49:39 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 08 Feb 2019 17:49:39 +0100
Subject: [8u] RFR + RFA: 8213419: "C2 may hang in
 MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1" and follow up 8214206
In-Reply-To: <f1965488-96f6-de05-fac6-3e985b134113@redhat.com>
References: <8736p0x3fn.fsf@redhat.com>
 <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com>
 <f1965488-96f6-de05-fac6-3e985b134113@redhat.com>
Message-ID: <87o97mtecc.fsf@redhat.com>


> Builds fine on:
>  * linux-x86-normal-minimal1-fastdebug
>  * linux-x86_64-normal-server-fastdebug
>  * linux-arm-normal-zero-fastdebug
>  * linux-x86-normal-server-fastdebug
>  * linux-x86_64-normal-zero-fastdebug

Thanks!

Roland.

From rwestrel at redhat.com  Fri Feb  8 16:49:16 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 08 Feb 2019 17:49:16 +0100
Subject: [8u] RFR + RFA: 8213419: "C2 may hang in
 MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1" and follow up 8214206
In-Reply-To: <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com>
References: <8736p0x3fn.fsf@redhat.com>
 <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com>
Message-ID: <87r2citecz.fsf@redhat.com>


> Changes look good.

Thanks for the reviews.

> Where's the regression test? MultiplyByIntegerMinHang.java is in original change.

Good catch. I forgot to "hg add" the test:

http://cr.openjdk.java.net/~roland/8213419.8u/webrev.01/

Roland.

From aph at redhat.com  Fri Feb  8 17:22:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 17:22:27 +0000
Subject: [8u] RFR + RFA: 8213419: "C2 may hang in
 MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1" and follow up 8214206
In-Reply-To: <87r2citecz.fsf@redhat.com>
References: <8736p0x3fn.fsf@redhat.com>
 <9392cfb1-04dd-0e39-922d-eb0fd65e2ffb@redhat.com> <87r2citecz.fsf@redhat.com>
Message-ID: <fb681dd7-f196-f19d-8432-45e840b3be19@redhat.com>

On 2/8/19 4:49 PM, Roland Westrelin wrote:
> 
>> Changes look good.
> 
> Thanks for the reviews.
> 
>> Where's the regression test? MultiplyByIntegerMinHang.java is in original change.
> 
> Good catch. I forgot to "hg add" the test:
> 
> http://cr.openjdk.java.net/~roland/8213419.8u/webrev.01/

Approved.

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

From aph at redhat.com  Fri Feb  8 18:20:16 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Feb 2019 18:20:16 +0000
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
Message-ID: <2d990c8b-142b-3030-7145-b93e982488e2@redhat.com>

On 2/8/19 5:39 PM, Andrey Petushkov wrote:

> BTW, related question to RedHat, I see that aarch64-port/jdk8u repos
> are stale for ~5 months, and latest update level is u181. Does that
> mean that OpenJDK aarch64-jdk8u mainline is considered to be hosted
> in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos
> (where 8u192 is propagated for some time already)?

Yes. We need to disable some dead source trees.

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

From zgu at redhat.com  Fri Feb  8 21:50:21 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Fri, 08 Feb 2019 16:50:21 -0500
Subject: [8u] RFR+RFA 8200109: NMT: diff_malloc_site assert(early->flags()
 == current->flags(), "Must be the same memory type")
Message-ID: <1549662621.31327.279.camel@redhat.com>

Hi,

I would like to backport 8200109, as it could result intermittent
assertion failures of runtime/NMT/JcmdDetailDiff.java test.

The fix has pushed to JDK13.
JDK13 Bug:    https://bugs.openjdk.java.net/browse/JDK-8200109
JDK13 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109/webrev.00/
Code review: https://mail.openjdk.java.net/pipermail/hotspot-runtime-de
v/2019-February/032463.html


JDK13 patch did not apply cleanly, there are minor conflicts in
memReporter.cpp and whitebox.java. There are also changes in new test,
due to test library changes between 8 and 13.

JDK8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109-8u/webrev.00/

Test:
  runtime/NMT on Linux x64 (fastdebug and release)

Thanks,

-Zhengyu

From gil at azul.com  Sat Feb  9 03:57:20 2019
From: gil at azul.com (Gil Tene)
Date: Sat, 9 Feb 2019 03:57:20 +0000
Subject: Numbering of updates in future 8u quarterly releases
Message-ID: <3ED351C9-484D-41ED-943A-045AFDCB9DD8@azul.com>

In the thread on "RFD: Draft guidelines for working on jdk8u", Andrew
discusses doing one release per quarter in 8u going forward. I'd like
to discuss the numbering of those expected update  releases, so that
downstream builds will have an opportunity to align on a common
meaning, and the consumers of various downstream builds would be
able to tell what they are looking at?

The relevant paragraph in the RFD e-mail is:

> On Feb 7, 2019, at 10:01 AM, Andrew Haley <aph at redhat.com> wrote:
> ...
> Once a quarter, we will snapshot the jdk8u development tree and
> prepare a Critical Patch Update (CPU) release. Once the snapshot has
> been taken the engineers working on the CPU will work in the dark,
> sharing the patches with only the OpenJDK Vulnerability Group. Any
> patches not committed to jdk8u at the time of the snapshot will
> probably have to wait for a later release. I don't propose to make any
> non-CPU releases: one release a quarter should be quite enough for
> jdk8u. However, if an urgent problem arises we might need to do make
> an intermediate release.
> ...

AFAICT the closest things to the description above in past 8u update
release are "PSU" releases with update numbers 8uXX2. For example
8u172, 8u182, 8u192, 8u202, ? Those updates included both the
latest security related patches (all the stuff included in the "CPU"
8uXX1 update releases such as 8u171, 8u181, 8u191, ...) as well as
additional changes (bug fixes, minor features, etc.) accumulated since
the previous 8uXX2 "PSU" release.

Going forward (for everything after the current 8u202), what will these
once-per-quarter updates be called?

I see three main options:

1. Keep going with the existing convention, and use the 8uXX2 for the
quarterly releases described in Andrew RFD e-mail. Continuing from
where the January CPU/PSU versions (8u201 and 8u202) left off. So
this coming April would be 8u212.

2. Do some sort of "skip" to denote the change from two (8uXX1 and
8uXX2) to one (8uXX2) quarterly release cadence. E.g. 8u302 for
this coming April.

3. Go with some other, different-than-past cadence, and different
meaning for the Y in 8uXXY going forward. (I'll use 8u777 as
a placeholder example for this).

My vote would be #1 above, for simplicity and continuity. I.e. 8u212
for April, 8u222 for July, 8u232 for October, etc. etc. etc.

? Gil.




From volker.simonis at gmail.com  Mon Feb 11 11:04:54 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 11 Feb 2019 12:04:54 +0100
Subject: Numbering of updates in future 8u quarterly releases
In-Reply-To: <3ED351C9-484D-41ED-943A-045AFDCB9DD8@azul.com>
References: <3ED351C9-484D-41ED-943A-045AFDCB9DD8@azul.com>
Message-ID: <CA+3eh11qkDEidqSZQqzFxH6xbT8h_F5Ruyn6Nd8pOzS5QZ6FQg@mail.gmail.com>

On Sat, Feb 9, 2019 at 4:57 AM Gil Tene <gil at azul.com> wrote:
>
> In the thread on "RFD: Draft guidelines for working on jdk8u", Andrew
> discusses doing one release per quarter in 8u going forward. I'd like
> to discuss the numbering of those expected update  releases, so that
> downstream builds will have an opportunity to align on a common
> meaning, and the consumers of various downstream builds would be
> able to tell what they are looking at?
>
> The relevant paragraph in the RFD e-mail is:
>
> > On Feb 7, 2019, at 10:01 AM, Andrew Haley <aph at redhat.com> wrote:
> > ...
> > Once a quarter, we will snapshot the jdk8u development tree and
> > prepare a Critical Patch Update (CPU) release. Once the snapshot has
> > been taken the engineers working on the CPU will work in the dark,
> > sharing the patches with only the OpenJDK Vulnerability Group. Any
> > patches not committed to jdk8u at the time of the snapshot will
> > probably have to wait for a later release. I don't propose to make any
> > non-CPU releases: one release a quarter should be quite enough for
> > jdk8u. However, if an urgent problem arises we might need to do make
> > an intermediate release.
> > ...
>
> AFAICT the closest things to the description above in past 8u update
> release are "PSU" releases with update numbers 8uXX2. For example
> 8u172, 8u182, 8u192, 8u202, ? Those updates included both the
> latest security related patches (all the stuff included in the "CPU"
> 8uXX1 update releases such as 8u171, 8u181, 8u191, ...) as well as
> additional changes (bug fixes, minor features, etc.) accumulated since
> the previous 8uXX2 "PSU" release.
>
> Going forward (for everything after the current 8u202), what will these
> once-per-quarter updates be called?
>
> I see three main options:
>
> 1. Keep going with the existing convention, and use the 8uXX2 for the
> quarterly releases described in Andrew RFD e-mail. Continuing from
> where the January CPU/PSU versions (8u201 and 8u202) left off. So
> this coming April would be 8u212.
>
> 2. Do some sort of "skip" to denote the change from two (8uXX1 and
> 8uXX2) to one (8uXX2) quarterly release cadence. E.g. 8u302 for
> this coming April.
>
> 3. Go with some other, different-than-past cadence, and different
> meaning for the Y in 8uXXY going forward. (I'll use 8u777 as
> a placeholder example for this).
>
> My vote would be #1 above, for simplicity and continuity. I.e. 8u212
> for April, 8u222 for July, 8u232 for October, etc. etc. etc.
>

For now, #1 seems to be the most natural and reasonable choice.

This may change if we get update releases with considerable feature
updates like for example JFR/JMC. In that case #2 may be a good choice
as well.

And the same reasoning actually also applies to 11 updates. We should
continue to increase the Update number for now (i.e. 11.0.3, 11.0.4,
etc.) but may consider also increasing the "Interim" number for bigger
feature downports in the future (e.g 11.1 11.1.1, etc.)

> ? Gil.
>
>
>

From gnu.andrew at redhat.com  Mon Feb 11 15:06:59 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 11 Feb 2019 15:06:59 +0000
Subject: Numbering of updates in future 8u quarterly releases
In-Reply-To: <3ED351C9-484D-41ED-943A-045AFDCB9DD8@azul.com>
References: <3ED351C9-484D-41ED-943A-045AFDCB9DD8@azul.com>
Message-ID: <CABi63P700giadwiG6TvsLfmY8aoNiyR5uUEJMg6env6z0vz0gg@mail.gmail.com>

On Sat, 9 Feb 2019 at 03:58, Gil Tene <gil at azul.com> wrote:
>
> In the thread on "RFD: Draft guidelines for working on jdk8u", Andrew
> discusses doing one release per quarter in 8u going forward. I'd like
> to discuss the numbering of those expected update  releases, so that
> downstream builds will have an opportunity to align on a common
> meaning, and the consumers of various downstream builds would be
> able to tell what they are looking at?
>
> The relevant paragraph in the RFD e-mail is:
>
> > On Feb 7, 2019, at 10:01 AM, Andrew Haley <aph at redhat.com> wrote:
> > ...
> > Once a quarter, we will snapshot the jdk8u development tree and
> > prepare a Critical Patch Update (CPU) release. Once the snapshot has
> > been taken the engineers working on the CPU will work in the dark,
> > sharing the patches with only the OpenJDK Vulnerability Group. Any
> > patches not committed to jdk8u at the time of the snapshot will
> > probably have to wait for a later release. I don't propose to make any
> > non-CPU releases: one release a quarter should be quite enough for
> > jdk8u. However, if an urgent problem arises we might need to do make
> > an intermediate release.
> > ...
>
> AFAICT the closest things to the description above in past 8u update
> release are "PSU" releases with update numbers 8uXX2. For example
> 8u172, 8u182, 8u192, 8u202, ? Those updates included both the
> latest security related patches (all the stuff included in the "CPU"
> 8uXX1 update releases such as 8u171, 8u181, 8u191, ...) as well as
> additional changes (bug fixes, minor features, etc.) accumulated since
> the previous 8uXX2 "PSU" release.
>
> Going forward (for everything after the current 8u202), what will these
> once-per-quarter updates be called?
>
> I see three main options:
>
> 1. Keep going with the existing convention, and use the 8uXX2 for the
> quarterly releases described in Andrew RFD e-mail. Continuing from
> where the January CPU/PSU versions (8u201 and 8u202) left off. So
> this coming April would be 8u212.
>
> 2. Do some sort of "skip" to denote the change from two (8uXX1 and
> 8uXX2) to one (8uXX2) quarterly release cadence. E.g. 8u302 for
> this coming April.
>
> 3. Go with some other, different-than-past cadence, and different
> meaning for the Y in 8uXXY going forward. (I'll use 8u777 as
> a placeholder example for this).
>
> My vote would be #1 above, for simplicity and continuity. I.e. 8u212
> for April, 8u222 for July, 8u232 for October, etc. etc. etc.
>
> ? Gil.
>
>
>

This is an interesting point and one which also came up for OpenJDK 7
(the proprietary JDK 6 from Oracle was unrelated to OpenJDK 6, so the
problem didn't exist there). With 7, we have followed the CPU release numbering
of the proprietary Oracle JDK releases, so 7u201, etc.

With 8, that would effectively be a 4th option, as your #1 proposes following
the PSU numbering rather than the CPU. The obvious problem I see with
both is that there is a possibility of a proprietary Oracle variant existing
with the same version, and confusingly, having entries in the OpenJDK
bug system. 8u211 is already present in the OpenJDK bug system, I see.

It's not clear to me whether Oracle intend to continue doing both. As it seems
more likely that the PSU version is unused by Oracle, rather than the CPU
version, I'd say we go with #1 to reduce the risk of overlap.

Given how much more active 8 & 11 may be than 6 & 7 ever were, we may
have to consider further divergence at a later date. I think that's inevitable
and something to be embraced. We should encourage people to use the
OpenJDK versions of 8 & 11 where possible.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb 11 15:08:36 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 11 Feb 2019 15:08:36 +0000
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <2d990c8b-142b-3030-7145-b93e982488e2@redhat.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <2d990c8b-142b-3030-7145-b93e982488e2@redhat.com>
Message-ID: <CABi63P6N-c+TgGt=2JM=33f+w5-FeC6+WyWxx9O0Ux-U3YHu1Q@mail.gmail.com>

On Fri, 8 Feb 2019 at 18:21, Andrew Haley <aph at redhat.com> wrote:
>
> On 2/8/19 5:39 PM, Andrey Petushkov wrote:
>
> > BTW, related question to RedHat, I see that aarch64-port/jdk8u repos
> > are stale for ~5 months, and latest update level is u181. Does that
> > mean that OpenJDK aarch64-jdk8u mainline is considered to be hosted
> > in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos
> > (where 8u192 is propagated for some time already)?
>
> Yes. We need to disable some dead source trees.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

"This is the last time I plan to update the aarch64/jdk8u tree. From
the October CPU, changes will go to the aarch64/shenandoah-jdk8u tree
only, which should soon be buildable on all architectures." [0]

[0] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-August/006265.html
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb 11 15:11:07 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 11 Feb 2019 15:11:07 +0000
Subject: [8u] RFA 8214059: Undefined behaviour in ADLC
In-Reply-To: <332e373c-5d94-3d16-2d0d-4d9d89af91b8@redhat.com>
References: <332e373c-5d94-3d16-2d0d-4d9d89af91b8@redhat.com>
Message-ID: <CABi63P50Fa--Gv1C8Lt68gnHQvFzfL_Tx89k=+J4=6GH6gQUmw@mail.gmail.com>

On Thu, 7 Feb 2019 at 11:29, Aleksey Shipilev <shade at redhat.com> wrote:
>
> Please approve the push of another UB fix to 8u.
>
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8214059
>       Reporter: Severin Gehwolf
>       Assignee: Severin Gehwolf
>       Priority: P4
>       Components: hotspot
>
>   Original Fix:
>         12: JDK-8214059, http://hg.openjdk.java.net/jdk/jdk/rev/e017d2f176d0, 73 day(s) ago
>
>   Backports and Forwardports:
>        11: 11.0.3, JDK-8215214, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9e179e01882d, 58
> day(s) ago
>          8: MISSING
>
>
> The patch requires reshuffling, but otherwise applies without problems. The webrev, for the record:
>   http://cr.openjdk.java.net/~shade/8214059/webrev.8u.01/
>
> Testing: Linux x86_64 fastdebug, all hotspot jtreg tests (some unrelated failures)
>
> Thanks,
> -Aleksey

Approved.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb 11 15:15:58 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 11 Feb 2019 15:15:58 +0000
Subject: [8u] Request for approval for CR 8215318 - Amend the Standard
 Algorithm Names specification to clarify that names can be defined in later
 versions
In-Reply-To: <b6b450b5-a831-bab5-af76-80d8732fa1af@oracle.com>
References: <27d7c7a7-4550-9fce-0e6d-8a4f9313a70f@oracle.com>
 <CABi63P706Vkt=7hs3bjHJXxRuOy79ddj-BaLsnLj955uvM8UDg@mail.gmail.com>
 <630acfdc-2be4-bd4b-894e-4599bb57d392@oracle.com>
 <CABi63P4rKTjnaDu7-jxugJ_zXUc_hbtpErTArPWvJLcMJDbGZw@mail.gmail.com>
 <b6b450b5-a831-bab5-af76-80d8732fa1af@oracle.com>
Message-ID: <CABi63P5jzbw-2FekpzYMGKSWSu-LU4RiECRpOr6my5C9LT0shA@mail.gmail.com>

On Wed, 6 Feb 2019 at 16:08, Sean Mullan <sean.mullan at oracle.com> wrote:
>
> On 1/31/19 1:26 AM, Andrew Hughes wrote:
> > On Wed, 30 Jan 2019 at 20:35, Sean Mullan <sean.mullan at oracle.com> wrote:
> >>
> >> On 1/30/19 11:00 AM, Andrew Hughes wrote:
>  >>
> >> The current JDK 8 version is
> >> https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html
> >>
> >> The changes that are proposed are the following:
> >>
> >> Add the following sentence to the first section ("Standard Names") of
> >> the Java Security Standard Algorithm Names specification:
> >>
> >>       Note that an SE implementation may support additional algorithms
> >>       that are not defined in this specification.  As a best practice, if an
> >>       algorithm is defined in a subsequent version of this specification and
> >>       an implementation of an earlier specification supports that algorithm,
> >>       the implementation should use the standard name of the algorithm
> >>       that is defined in the subsequent specification.  Each SE
> >> implementation
> >>       should also document the algorithms that it supports or adds support
> >>       for in subsequent update releases.  The algorithms may be documented
> >>       in release notes or in a separate document such as the JDK Security
> >>       Providers document.
> >>
> >> Also, the words "JDK Security API" in this section will be changed to
> >> "Java SE Security API" (this change has already been made in later SE
> >> releases).
> >>
> >> With these changes added, the beginning of the first section is now the
> >> following:
> >>
> >>       The Java SE Security API requires and uses a set of standard
> >>       names for algorithms, certificate and keystore types. This
> >>       specification establishes the following names as standard names.
> >>
> >>       Note that an SE implementation may support additional algorithms
> >>       that are not defined in this specification.  As a best practice, if an
> >>       algorithm is defined in a subsequent version of this specification and
> >>       an implementation of an earlier specification supports that algorithm,
> >>       the implementation should use the standard name of the algorithm
> >>       that is defined in the subsequent specification.  Each SE
> >> implementation
> >>       should also document the algorithms that it supports or adds support
> >>       for in subsequent update releases.  The algorithms may be documented
> >>       in release notes or in a separate document such as the JDK Security
> >>       Providers document.
> >>
> >>       In some cases naming conventions are given for forming names
> >>       that are not explicitly listed, to facilitate name consistency
> >>       across provider implementations. Items in angle brackets (such as
> >>       <digest> and <encryption>) are placeholders to be replaced by a
> >>       specific message digest, encryption algorithm, or other name.
> >>
> >>       Note: Standard names are not case-sensitive.
> >>
> >> Thanks,
> >> Sean
> >>
> >
> > The changes seem relatively uncontroversial (though I fail to see
> > the difference between "JDK Security API" and "Java SE Security API").
>
> JDK APIs are often used to describe public or exported APIs that are
> part of the JDK, but not standard SE APIs. For example, the CSR process
> uses this term for the Scope field [1]. The APIs referenced in this
> specification are all standard SE APIs.
>
> > However, I don't see how I can approve something which is not
> > even part of OpenJDK and thus, can't even see.
>
> It is not part of the OpenJDK source code, but this specification is
> referenced as a standard document from various Java SE Security APIs.
> For an example, see [2].
>
> Thanks,
> Sean
>
> [1] https://wiki.openjdk.java.net/display/csr/Fields+of+a+CSR+Request
> [2]
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/b6dcf8ae496c/src/share/classes/java/security/MessageDigest.java#l150

Yes, I get that.

Well, you have my approval for what it's worth for something that's
not an OpenJDK change :)
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gromero at linux.vnet.ibm.com  Mon Feb 11 15:53:24 2019
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 11 Feb 2019 13:53:24 -0200
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
Message-ID: <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>

Hello Andrew,

On 02/07/2019 04:01 PM, Andrew Haley wrote:
> OpenJDK 8 is a long-term stable release of OpenJDK. Our primary goal
> is to maintain it, fixing significant bugs and especially security
> problems as we go along. The "first, do no harm" principle applies: we
> must not break things.
> 
> We do not yet have much experience with our test systems, so for the
> first couple of quarters we should be very cautious. Later on we can
> be more adventurous, but for now it's "bug fixes only".

As we've briefly discussed, we planned to backport some PPC64-only
enhancements, like for AES BE, SHA2, and CRC32 intrinsics to jdk8u.

Thus I would like to know if we can have a different policy for
such a kind of changes confined to a single port and hence add a
text about it in the draft guidelines for working on jdk8u.

Thank you.

Best regards,
Gustavo


From shade at redhat.com  Mon Feb 11 16:11:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 11 Feb 2019 17:11:32 +0100
Subject: [8u] RFR+RFA 8200109: NMT: diff_malloc_site assert(early->flags()
 == current->flags(), "Must be the same memory type")
In-Reply-To: <1549662621.31327.279.camel@redhat.com>
References: <1549662621.31327.279.camel@redhat.com>
Message-ID: <91fd8e49-ca00-5691-1da9-086ea7000b04@redhat.com>

On 2/8/19 10:50 PM, zgu at redhat.com wrote:
> JDK8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109-8u/webrev.00/

The code change looks good. (...and I cannot give approvals to push). However, we should probably
wait a few weeks before considering it for 8u, looking more testing in jdk/jdk. Also, jdk11u
backport should happen first?

Thanks,
-Aleksey


From zgu at redhat.com  Mon Feb 11 17:27:48 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Mon, 11 Feb 2019 12:27:48 -0500
Subject: [8u] RFR+RFA 8200109: NMT: diff_malloc_site
 assert(early->flags() == current->flags(), "Must be the same memory type")
In-Reply-To: <91fd8e49-ca00-5691-1da9-086ea7000b04@redhat.com>
References: <1549662621.31327.279.camel@redhat.com>
 <91fd8e49-ca00-5691-1da9-086ea7000b04@redhat.com>
Message-ID: <1549906068.20944.21.camel@redhat.com>

On Mon, 2019-02-11 at 17:11 +0100, Aleksey Shipilev wrote:
> On 2/8/19 10:50 PM, zgu at redhat.com wrote:
> > JDK8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8200109-8u/webrev
> > .00/
> 
> The code change looks good. (...and I cannot give approvals to push).
> However, we should probably
> wait a few weeks before considering it for 8u, looking more testing
> in jdk/jdk. Also, jdk11u
> backport should happen first?
I have no problem with delaying backport. This patch is mainly to avoid
false-positive scenario of NMT/JcmdDetailDiff.java. 

JDK13 and JDK11  all have the test enabled, I did not find additional
bug report related it, so I guess it should not be a problem for JDK8u
neither.

-Zhengyu


> 
> Thanks,
> -Aleksey
> 

From hohensee at amazon.com  Mon Feb 11 19:41:57 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 11 Feb 2019 19:41:57 +0000
Subject: [8u] RFR + RFA 8211926: Catastrophic size_t underflow in
 BitMap::*_large methods
In-Reply-To: <cb09ed80-c085-b758-c69c-1547e09073f4@redhat.com>
References: <cb09ed80-c085-b758-c69c-1547e09073f4@redhat.com>
Message-ID: <47DB41C9-0F88-4C85-845A-8ECA6B164A0A@amazon.com>

The 8u patch looks good to me, as in, inspection says it does the same thing in 8u as in 11u.

Paul

?On 2/6/19, 8:41 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:

    Please review and approve the backport of catastrophic underflow fix in BitMap:
    
      Original Bug:
          URL: https://bugs.openjdk.java.net/browse/JDK-8211926
          Reporter: Aleksey Shipilev
          Assignee: Aleksey Shipilev
          Priority: P4
          Components: hotspot
    
      Original Fix:
            12: JDK-8211926, http://hg.openjdk.java.net/jdk/jdk/rev/e5534cc91a10, 88 day(s) ago
    
      Backports and Forwardports:
            11: 11.0.3, JDK-8214860, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6c90d1d1a03b, 63
    day(s) ago
             8: MISSING
    
    8u fix does not apply cleanly, because Bitmap is cleaned up a bit in subsequent releases. There is
    also no support for gtest, which means we cannot backport the relevant regression test. Instead, we
    have to rely on assert to fire if code is broken. 8u webrev:
      http://cr.openjdk.java.net/~shade/8211926/webrev.8u.01/
    
    Testing: Linux x86_64 build and all jtreg tests (with some unrelated failures)
    
    Thanks,
    -Aleksey
    
    


From aph at redhat.com  Mon Feb 11 20:48:54 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Feb 2019 20:48:54 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
Message-ID: <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>

On 2/11/19 3:53 PM, Gustavo Romero wrote:
> As we've briefly discussed, we planned to backport some PPC64-only
> enhancements, like for AES BE, SHA2, and CRC32 intrinsics to jdk8u.
> 
> Thus I would like to know if we can have a different policy for
> such a kind of changes confined to a single port and hence add a
> text about it in the draft guidelines for working on jdk8u.

That seems reasonable to me. My intention is to minimize risk, not to
minimize performance.

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

From gnu.andrew at redhat.com  Mon Feb 11 23:16:06 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 11 Feb 2019 23:16:06 +0000
Subject: [8u] RFR + RFA 8211926: Catastrophic size_t underflow in
 BitMap::*_large methods
In-Reply-To: <47DB41C9-0F88-4C85-845A-8ECA6B164A0A@amazon.com>
References: <cb09ed80-c085-b758-c69c-1547e09073f4@redhat.com>
 <47DB41C9-0F88-4C85-845A-8ECA6B164A0A@amazon.com>
Message-ID: <CABi63P4UdCZbmSistV9sffwedn3irhvKe2-G8T3GbutH22-Viw@mail.gmail.com>

On Mon, 11 Feb 2019 at 19:43, Hohensee, Paul <hohensee at amazon.com> wrote:
>
> The 8u patch looks good to me, as in, inspection says it does the same thing in 8u as in 11u.
>
> Paul
>
> ?On 2/6/19, 8:41 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:
>
>     Please review and approve the backport of catastrophic underflow fix in BitMap:
>
>       Original Bug:
>           URL: https://bugs.openjdk.java.net/browse/JDK-8211926
>           Reporter: Aleksey Shipilev
>           Assignee: Aleksey Shipilev
>           Priority: P4
>           Components: hotspot
>
>       Original Fix:
>             12: JDK-8211926, http://hg.openjdk.java.net/jdk/jdk/rev/e5534cc91a10, 88 day(s) ago
>
>       Backports and Forwardports:
>             11: 11.0.3, JDK-8214860, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6c90d1d1a03b, 63
>     day(s) ago
>              8: MISSING
>
>     8u fix does not apply cleanly, because Bitmap is cleaned up a bit in subsequent releases. There is
>     also no support for gtest, which means we cannot backport the relevant regression test. Instead, we
>     have to rely on assert to fire if code is broken. 8u webrev:
>       http://cr.openjdk.java.net/~shade/8211926/webrev.8u.01/
>
>     Testing: Linux x86_64 build and all jtreg tests (with some unrelated failures)
>
>     Thanks,
>     -Aleksey
>
>
>

Looks good to me too. Approved.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From martijnverburg at gmail.com  Tue Feb 12 12:13:24 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 12 Feb 2019 12:13:24 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
Message-ID: <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>

Hi all,

Assuming we've got a rough consensus I'm happy to try and write this up in
the wiki - I'll need someone to give me access (not a committer).

Cheers,
Martijn


On Mon, 11 Feb 2019 at 20:49, Andrew Haley <aph at redhat.com> wrote:

> On 2/11/19 3:53 PM, Gustavo Romero wrote:
> > As we've briefly discussed, we planned to backport some PPC64-only
> > enhancements, like for AES BE, SHA2, and CRC32 intrinsics to jdk8u.
> >
> > Thus I would like to know if we can have a different policy for
> > such a kind of changes confined to a single port and hence add a
> > text about it in the draft guidelines for working on jdk8u.
>
> That seems reasonable to me. My intention is to minimize risk, not to
> minimize performance.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

From aph at redhat.com  Tue Feb 12 11:41:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 12 Feb 2019 11:41:50 +0000
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
Message-ID: <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>

On 2/11/19 1:01 PM, Mario Torre wrote:
> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>>
>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>>> Andrew, do you think we can have a repository created for this
>>> purpose?
>>
>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>> discussed. Perhaps that would fit the bill for this backport in a more
>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
> 
> My understanding was that this was dismissed, but I'm happy either way.
> 
> If we have an agreement on how to call the repository then Andrew will
> create one right away.
> 
> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> sure if we will want to coordinate this effort on a separate mailing
> list though, what do you think?

I think it would be cleaner to have multiple repositories: having to deal
with branches make things pointlessly difficult. Maybe we should give this
some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
of this is that a casual visitor is less likely to be confused.

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

From andrey at azul.com  Fri Feb  8 17:39:06 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Fri, 8 Feb 2019 17:39:06 +0000
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
Message-ID: <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>

Dear team!

It happened that in the meanwhile Azul was also working on preparing the backport of JFR to jdk8 codebase. We as well have finished the implementation recently and would like to contribute it to the community. Our approach and platform coverage is a bit different so patches are definitely not the same. One might want to compare and merge somehow to get most of both. We are performing difference analysis but not yet finished. Will update once we have full information.
The following is different to your approach:
- We did not add EnableJFR flag, JFR could be used in the same way as in jdk11
- we have added ?enable-jfr parameter to configure script to control inclusion of JFR into binary
- -XX:+/-LogJFR VM parameter to control JFR logging (analogous to -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
- we have removed the ?trace*? build files while adding ?jfr*? files. We believe such approach makes it easier to backport further jfr fixes from jdk11+
- we have the following platforms supported: Linux x86, ppc, arm, all in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64 are supported (Solaris on x86 and sparc have some bugs which are not resolved yet)
We as well have JFR test suite passed with some limitations coming from missing VM features (we did not add some missing WhiteBox APIs so test coverage is a bit smaller than yours)
There might be as well difference in data being supported, e.g. Azul implementation does not support G1 memory types, while Alibaba seem to have added missing G1 functionality to get this data

The webrev is at
http://cr.openjdk.java.net/~apetushkov/jfr8/
Baseline is 8u202.
The changes to aarch64- and aarch32-port projects are delta on top of generic hotspot patch.
Shenandoah GC is not integrated with JFR. BTW, related question to RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months, and latest update level is u181. Does that mean that OpenJDK aarch64-jdk8u mainline is considered to be hosted in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos (where 8u192 is propagated for some time already)? Just in case I?ve posted integration patches for both repos

Regards,
Andrey


Begin forwarded message:

From: "guangyu.zhu" <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>
Subject: Re: Proposal for back-porting JFR to OpenJDK8u
Date: January 29, 2019 at 3:41:35 AM PST
To: "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "Mario Torre" <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>, "jdk8u-dev" <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net>>
Cc: yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>, kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>, jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>, denghui.ddh <denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com>>
Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>

Hi there,

JFR backport patch has been uploaded to cr.openjdk. Please have a review for the patch.

Webrev:
http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/

The original patch comes from webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html . We ported it to jdk8u192-b26 and passed most of the jfr jtreg tests on Linux/x86-64 platform. Some features related to Module, AOT and log level are removed because jdk8 does not support them.

We have added a new option ?EnableJFR? to enable or disable the JFR feature. It?s disabled by default. To enable it, you can start java with ?-XX:+EnableJFR?.  For example:
java -XX:+EnableJFR -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp

When running the jtreg test, please add the extra option '-vmoption:-XX:+EnableJFR'. Otherwise the test case will not execute correctly. Here is an example of running jfr jtreg test:
make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR TEST=jdk_jfr

There is one more thing worth noting, please use jmc version 7.0 or later to open the jfr record file.

Your suggestions and comments are welcome.

Thanks,
Guangyu Zhu
------------------------------------------------------------------
Sender:???(??) <sanhong.lsh at alibaba-inc.com<mailto:sanhong.lsh at alibaba-inc.com>>
Sent At:2018 Dec. 17 (Mon.) 21:21
Recipient:Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>
Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

Thanks for comments, we are preparing our internal patches for webrev.
In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to produce technical preview build.
Would like to know this... can Martijn point us some guide somewhere?

Thanks!
Sanhong
-----????-----
???: Andrew Haley [mailto:aph at redhat.com]
????: 2018?12?13? 3:03
???: Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>; ???(??) <sanhong.lsh at alibaba-inc.com<mailto:sanhong.lsh at alibaba-inc.com>>
??: Volker Simonis <volker.simonis at gmail.com<mailto:volker.simonis at gmail.com>>; jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>
??: Re: Proposal for back-porting JFR to OpenJDK8u

On 12/12/18 1:44 PM, Mario Torre wrote:
I think the first thing to do would be to post the patch for review, a
shared repository would make the review process a bit more complex I
think, and only makes sense if there is a need to work further on the
patch collectively.

Yes, exactly. That's the normal process, and it's the best place to start.

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






From neugens.limasoftware at gmail.com  Fri Feb  8 18:00:47 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 8 Feb 2019 19:00:47 +0100
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
Message-ID: <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>

Hi Andrey,

Thanks for the patch!

As we discussed during the Committer Workshop I'll be happy to help
coordinate the efforts to integrate this work into 8. I think at this
point the best approach would be to create a separate jdk8u-jfr
repository and proceed from there. We need to be absolutely sure that
when disabled JFR is fully disabled, as in no code path ever touches
JFR.

Then I think we would start with your patch since it support more
platforms, but I would like to add G1 support as in the Alibaba patch.
We then need to discuss about testing, this is most likely something
to do with the AdoptOpenJDK team. Long term maintenance is also of
critical importance, we need to be sure that the patch is alive for
the time a maintainer is leading 8u, so I hope Azul and Alibaba will
contribute fix and help maintaining the port for a reasonable amount
of time.

Andrew, do you think we can have a repository created for this purpose?

Cheers,
Mario

Il giorno ven 8 feb 2019 alle ore 18:39 Andrey Petushkov
<andrey at azul.com> ha scritto:
>
> Dear team!
>
> It happened that in the meanwhile Azul was also working on preparing the backport of JFR to jdk8 codebase. We as well have finished the implementation recently and would like to contribute it to the community. Our approach and platform coverage is a bit different so patches are definitely not the same. One might want to compare and merge somehow to get most of both. We are performing difference analysis but not yet finished. Will update once we have full information.
> The following is different to your approach:
> - We did not add EnableJFR flag, JFR could be used in the same way as in jdk11
> - we have added ?enable-jfr parameter to configure script to control inclusion of JFR into binary
> - -XX:+/-LogJFR VM parameter to control JFR logging (analogous to -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
> - we have removed the ?trace*? build files while adding ?jfr*? files. We believe such approach makes it easier to backport further jfr fixes from jdk11+
> - we have the following platforms supported: Linux x86, ppc, arm, all in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64 are supported (Solaris on x86 and sparc have some bugs which are not resolved yet)
> We as well have JFR test suite passed with some limitations coming from missing VM features (we did not add some missing WhiteBox APIs so test coverage is a bit smaller than yours)
> There might be as well difference in data being supported, e.g. Azul implementation does not support G1 memory types, while Alibaba seem to have added missing G1 functionality to get this data
>
> The webrev is at
> http://cr.openjdk.java.net/~apetushkov/jfr8/
> Baseline is 8u202.
> The changes to aarch64- and aarch32-port projects are delta on top of generic hotspot patch.
> Shenandoah GC is not integrated with JFR. BTW, related question to RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months, and latest update level is u181. Does that mean that OpenJDK aarch64-jdk8u mainline is considered to be hosted in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos (where 8u192 is propagated for some time already)? Just in case I?ve posted integration patches for both repos
>
> Regards,
> Andrey
>
>
> Begin forwarded message:
>
> From: "guangyu.zhu" <guangyu.zhu at aliyun.com>
> Subject: Re: Proposal for back-porting JFR to OpenJDK8u
> Date: January 29, 2019 at 3:41:35 AM PST
> To: "Andrew Haley" <aph at redhat.com>, "Mario Torre" <neugens.limasoftware at gmail.com>, "jdk8u-dev" <jdk8u-dev-bounces at openjdk.java.net>
> Cc: yumin qi <yumin.qi at gmail.com>, kingsum.chow <kingsum.chow at gmail.com>, jdk8u-dev <jdk8u-dev at openjdk.java.net>, denghui.ddh <denghui.ddh at antfin.com>
> Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com>
>
> Hi there,
>
> JFR backport patch has been uploaded to cr.openjdk. Please have a review for the patch.
>
> Webrev:
> http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
> http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/
>
> The original patch comes from webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html . We ported it to jdk8u192-b26 and passed most of the jfr jtreg tests on Linux/x86-64 platform. Some features related to Module, AOT and log level are removed because jdk8 does not support them.
>
> We have added a new option ?EnableJFR? to enable or disable the JFR feature. It?s disabled by default. To enable it, you can start java with ?-XX:+EnableJFR?.  For example:
> java -XX:+EnableJFR -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp
>
> When running the jtreg test, please add the extra option '-vmoption:-XX:+EnableJFR'. Otherwise the test case will not execute correctly. Here is an example of running jfr jtreg test:
> make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR TEST=jdk_jfr
>
> There is one more thing worth noting, please use jmc version 7.0 or later to open the jfr record file.
>
> Your suggestions and comments are welcome.
>
> Thanks,
> Guangyu Zhu
> ------------------------------------------------------------------
> Sender:???(??) <sanhong.lsh at alibaba-inc.com>
> Sent At:2018 Dec. 17 (Mon.) 21:21
> Recipient:Andrew Haley <aph at redhat.com>; Mario Torre <neugens.limasoftware at gmail.com>
> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
>
> Thanks for comments, we are preparing our internal patches for webrev.
> In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to produce technical preview build.
> Would like to know this... can Martijn point us some guide somewhere?
>
> Thanks!
> Sanhong
> -----????-----
> ???: Andrew Haley [mailto:aph at redhat.com]
> ????: 2018?12?13? 3:03
> ???: Mario Torre <neugens.limasoftware at gmail.com>; ???(??) <sanhong.lsh at alibaba-inc.com>
> ??: Volker Simonis <volker.simonis at gmail.com>; jdk8u-dev at openjdk.java.net
> ??: Re: Proposal for back-porting JFR to OpenJDK8u
>
> On 12/12/18 1:44 PM, Mario Torre wrote:
>
> I think the first thing to do would be to post the patch for review, a
> shared repository would make the review process a bit more complex I
> think, and only makes sense if there is a need to work further on the
> patch collectively.
>
>
> Yes, exactly. That's the normal process, and it's the best place to start.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
>
>
>


-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From sgehwolf at redhat.com  Mon Feb 11 11:01:17 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Feb 2019 12:01:17 +0100
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
Message-ID: <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>

On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
> Andrew, do you think we can have a repository created for this
> purpose?

At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
discussed. Perhaps that would fit the bill for this backport in a more
generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?

Thanks,
Severin


From neugens at redhat.com  Mon Feb 11 13:01:00 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 11 Feb 2019 14:01:00 +0100
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
Message-ID: <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>

On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
> > Andrew, do you think we can have a repository created for this
> > purpose?
>
> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
> discussed. Perhaps that would fit the bill for this backport in a more
> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?

My understanding was that this was dismissed, but I'm happy either way.

If we have an agreement on how to call the repository then Andrew will
create one right away.

Btw, I think the discussion should move to jdk8u-dev alone. I'm not
sure if we will want to coordinate this effort on a separate mailing
list though, what do you think?

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 shade at redhat.com  Tue Feb 12 13:43:01 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Feb 2019 14:43:01 +0100
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
 <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>
 <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>
Message-ID: <ead53ffb-3405-47c9-8e5d-2f697f63523c@redhat.com>

On 2/8/19 2:52 PM, Andrew Haley wrote:
> On 2/7/19 5:28 PM, Martin Buchholz wrote:
>> On Thu, Feb 7, 2019 at 4:33 AM David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
>>>> Bug:
>>>>    https://bugs.openjdk.java.net/browse/JDK-8218613
>>>>
>>>> This is botched backport to 8u, which fails the jtreg tests now in 8u.
>>> Note the fix is not the
>>>> backport, but the actual 8u-specific fix.
>>>
>>> IIRC the incorrect @build is not a fatal error for earlier jtreg
>>> version. AFAICS we still use jtreg 4.1 for testing 8u internally.
>>>
>>
>> This surprised me.  Of course, the incentive to update to new jtreg
>> versions is generally because jdk-latest needs it, but we've always
>> successfully adopted any newer jtreg to test older jdks as well.
>> (but we don't run as many tests as you do)
> 
> I want to use the current jtreg for everything if at all possible.

That is my goal as well. Can I have the push approval, please?

-Aleksey



From aph at redhat.com  Tue Feb 12 14:13:41 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 12 Feb 2019 14:13:41 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
Message-ID: <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>

On 2/12/19 12:13 PM, Martijn Verburg wrote:
> Assuming we've got a rough consensus I'm happy to try and write this up in
> the wiki - I'll need someone to give me access (not a committer).

Sorry, that's my job.

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

From aph at redhat.com  Tue Feb 12 14:21:52 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 12 Feb 2019 14:21:52 +0000
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <ead53ffb-3405-47c9-8e5d-2f697f63523c@redhat.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
 <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>
 <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>
 <ead53ffb-3405-47c9-8e5d-2f697f63523c@redhat.com>
Message-ID: <d307bcb3-072d-3492-2743-939208526612@redhat.com>

On 2/12/19 1:43 PM, Aleksey Shipilev wrote:
> On 2/8/19 2:52 PM, Andrew Haley wrote:
>> On 2/7/19 5:28 PM, Martin Buchholz wrote:
>>> On Thu, Feb 7, 2019 at 4:33 AM David Holmes <david.holmes at oracle.com> wrote:
>>>
>>>> On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
>>>>> Bug:
>>>>>    https://bugs.openjdk.java.net/browse/JDK-8218613
>>>>>
>>>>> This is botched backport to 8u, which fails the jtreg tests now in 8u.
>>>> Note the fix is not the
>>>>> backport, but the actual 8u-specific fix.
>>>>
>>>> IIRC the incorrect @build is not a fatal error for earlier jtreg
>>>> version. AFAICS we still use jtreg 4.1 for testing 8u internally.
>>>>
>>>
>>> This surprised me.  Of course, the incentive to update to new jtreg
>>> versions is generally because jdk-latest needs it, but we've always
>>> successfully adopted any newer jtreg to test older jdks as well.
>>> (but we don't run as many tests as you do)
>>
>> I want to use the current jtreg for everything if at all possible.
> 
> That is my goal as well. Can I have the push approval, please?

OK.

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

From martijnverburg at gmail.com  Tue Feb 12 14:25:39 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 12 Feb 2019 14:25:39 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
Message-ID: <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>

On Tue, 12 Feb 2019 at 14:13, Andrew Haley <aph at redhat.com> wrote:

> On 2/12/19 12:13 PM, Martijn Verburg wrote:
> > Assuming we've got a rough consensus I'm happy to try and write this up
> in
> > the wiki - I'll need someone to give me access (not a committer).
>
> Sorry, that's my job.
>

Fair enough, LMK if there are other documentation tasks we can take off
your hands though.

Cheers,
Martijn


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

From shade at redhat.com  Tue Feb 12 14:35:55 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Feb 2019 15:35:55 +0100
Subject: [8u] RFR (XS) 8214061: Buffer written into itself
Message-ID: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>

Please approve the push of trivial fix that makes the code correct and also resolves a compiler warning.

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8214061
      Reporter: Severin Gehwolf
      Assignee: Severin Gehwolf
      Priority: P4
      Components: core-svc

  Original Fix:
        12: JDK-8214061, http://hg.openjdk.java.net/jdk/jdk/rev/8527b6100a59, 70 day(s) ago

  Backports and Forwardports:
        11: 11.0.3, JDK-8217003, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/4f3e66062582, 29
day(s) ago
         8: MISSING

Patch applies to 8u with reshuffling and fuzz. Here it is, for reference:

diff -r b6dcf8ae496c src/share/back/debugInit.c
--- a/src/share/back/debugInit.c        Wed Feb 06 04:09:08 2019 +0000
+++ b/src/share/back/debugInit.c        Tue Feb 12 15:25:48 2019 +0100
@@ -1,7 +1,7 @@
 /*
- * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.  Oracle designates this
@@ -663,11 +663,11 @@
     }
     if ( error != JVMTI_ERROR_NONE ) {
         (void)snprintf(buf, sizeof(buf), "JDWP %s, jvmtiError=%s(%d)",
                     msg, jvmtiErrorText(error), error);
     } else {
-        (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
+        (void)snprintf(buf, sizeof(buf), "JDWP %s", msg);
     }
     if (env != NULL) {
         (*((*env)->FatalError))(env, buf);
     } else {
         /* Should rarely ever reach here, means VM is really dead */


Testing: Linux x86_64 build, hotspot jtregs (some unrelated failures)

Thanks,
-Aleksey


From shade at redhat.com  Tue Feb 12 14:53:48 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Feb 2019 15:53:48 +0100
Subject: [8u] RFA+RFR (S) 8211231: BarrierSetC1::generate_referent_check()
 confuses register allocator
Message-ID: <4f0649f6-a472-0e1e-00e0-f93574013dff@redhat.com>

Please review and approve the push for the C1 compiler fix that can corrupt heap.

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8211231
      Reporter: Roland Westrelin
      Assignee: Roland Westrelin
      Priority: P3
      Components: hotspot

  Original Fix:
        12: JDK-8211231, http://hg.openjdk.java.net/jdk/jdk/rev/2a12a3865916, 133 day(s) ago

  Backports and Forwardports:
        11: 11.0.2, JDK-8212688, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd967d588882, 116
day(s) ago
         8: MISSING

Fix does not apply to 8u cleanly, because BarrierSetC1 move happened in 10. However, 8u code is
still susceptible to the same trouble. 8u version of the fix:
   http://cr.openjdk.java.net/~shade/8211231/webrev.8u.01/

Testing: Linux x86_64 fastdebug build, hotspot all jtregs (some unrelated failures)

Thanks,
-Aleksey


From shade at redhat.com  Tue Feb 12 14:54:41 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Feb 2019 15:54:41 +0100
Subject: [8u] RFA (XS) 8214061: Buffer written into itself
In-Reply-To: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>
References: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>
Message-ID: <bcc3a15f-4201-3aae-b939-9f42adcac2b4@redhat.com>

This should be "RFA", because fix applies without conflicts, fixed header.

-Aleksey

On 2/12/19 3:35 PM, Aleksey Shipilev wrote:
> Please approve the push of trivial fix that makes the code correct and also resolves a compiler warning.
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8214061
>       Reporter: Severin Gehwolf
>       Assignee: Severin Gehwolf
>       Priority: P4
>       Components: core-svc
> 
>   Original Fix:
>         12: JDK-8214061, http://hg.openjdk.java.net/jdk/jdk/rev/8527b6100a59, 70 day(s) ago
> 
>   Backports and Forwardports:
>         11: 11.0.3, JDK-8217003, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/4f3e66062582, 29
> day(s) ago
>          8: MISSING
> 
> Patch applies to 8u with reshuffling and fuzz. Here it is, for reference:
> 
> diff -r b6dcf8ae496c src/share/back/debugInit.c
> --- a/src/share/back/debugInit.c        Wed Feb 06 04:09:08 2019 +0000
> +++ b/src/share/back/debugInit.c        Tue Feb 12 15:25:48 2019 +0100
> @@ -1,7 +1,7 @@
>  /*
> - * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License version 2 only, as
>   * published by the Free Software Foundation.  Oracle designates this
> @@ -663,11 +663,11 @@
>      }
>      if ( error != JVMTI_ERROR_NONE ) {
>          (void)snprintf(buf, sizeof(buf), "JDWP %s, jvmtiError=%s(%d)",
>                      msg, jvmtiErrorText(error), error);
>      } else {
> -        (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
> +        (void)snprintf(buf, sizeof(buf), "JDWP %s", msg);
>      }
>      if (env != NULL) {
>          (*((*env)->FatalError))(env, buf);
>      } else {
>          /* Should rarely ever reach here, means VM is really dead */
> 
> 
> Testing: Linux x86_64 build, hotspot jtregs (some unrelated failures)
> 
> Thanks,
> -Aleksey
> 



From rwestrel at redhat.com  Tue Feb 12 15:23:07 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 12 Feb 2019 16:23:07 +0100
Subject: [8u] RFA+RFR (S) 8211231: BarrierSetC1::generate_referent_check()
 confuses register allocator
In-Reply-To: <4f0649f6-a472-0e1e-00e0-f93574013dff@redhat.com>
References: <4f0649f6-a472-0e1e-00e0-f93574013dff@redhat.com>
Message-ID: <87d0nxt4is.fsf@redhat.com>


>    http://cr.openjdk.java.net/~shade/8211231/webrev.8u.01/

8u change looks good.

Roland.

From jonathan.gibbons at oracle.com  Wed Feb 13 00:38:37 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 12 Feb 2019 16:38:37 -0800
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
 <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>
 <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>
Message-ID: <629ca322-dcd7-52ed-6840-32c3cad27151@oracle.com>


On 2/8/19 5:52 AM, Andrew Haley wrote:
> On 2/7/19 5:28 PM, Martin Buchholz wrote:
>> On Thu, Feb 7, 2019 at 4:33 AM David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 7/02/2019 9:52 pm, Aleksey Shipilev wrote:
>>>> Bug:
>>>>     https://bugs.openjdk.java.net/browse/JDK-8218613
>>>>
>>>> This is botched backport to 8u, which fails the jtreg tests now in 8u.
>>> Note the fix is not the
>>>> backport, but the actual 8u-specific fix.
>>> IIRC the incorrect @build is not a fatal error for earlier jtreg
>>> version. AFAICS we still use jtreg 4.1 for testing 8u internally.
>>>
>> This surprised me.  Of course, the incentive to update to new jtreg
>> versions is generally because jdk-latest needs it, but we've always
>> successfully adopted any newer jtreg to test older jdks as well.
>> (but we don't run as many tests as you do)
> I want to use the current jtreg for everything if at all possible.
>

Folk,

It is a general goal for jtreg to support use on older systems, so I 
have a question regarding that aspect ... what is the oldest JDK for 
which you want to use jtreg (jdk7u?, jdk8u etc) and how do you run jtreg 
... using the Makefiles, or in some custom setup? There's a hidden 
aspect to that last question, which is, what JDK do you use to run jtreg 
when testing these older platforms?

-- Jon


From volker.simonis at gmail.com  Wed Feb 13 09:05:32 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 Feb 2019 10:05:32 +0100
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
Message-ID: <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>

Hi Andrew,

I've wrote up a detailed proposal for the jdk11u update process and
posted it on jdk-updates-dev yesterday [1]. In that mail I propose to
have two repositories, jdk11u-dev as "always-open" development
repository and jdk11u as consolidation repository for the upcoming
update release. The main reason for having such a setup is that
everybody can see (and test) all the non-security changes which will
be in the next update release and members of the Vulenrability Group
will even have the possibility to easily create (and test) a version
of the upcoming update release which is very close to if not equal to
the version Red Hat will be working on "in the dark". I think this is
important not only to get a broader test coverage for upcoming update
releases, but also to simplify the process of producing update
releases for other down-stream distributors.

The OpenJDK 8u project already has these two repositories (i.e.
jdk8u/jdk8u and jdk8u/jdk8u-dev) so it would be trivial to implement
my proposal for the 8u updates project. What do you think?

Thank you and best regards,
Volker

[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000411.html

On Tue, Feb 12, 2019 at 3:27 PM Martijn Verburg
<martijnverburg at gmail.com> wrote:
>
> On Tue, 12 Feb 2019 at 14:13, Andrew Haley <aph at redhat.com> wrote:
>
> > On 2/12/19 12:13 PM, Martijn Verburg wrote:
> > > Assuming we've got a rough consensus I'm happy to try and write this up
> > in
> > > the wiki - I'll need someone to give me access (not a committer).
> >
> > Sorry, that's my job.
> >
>
> Fair enough, LMK if there are other documentation tasks we can take off
> your hands though.
>
> Cheers,
> Martijn
>
>
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >

From shade at redhat.com  Wed Feb 13 09:10:12 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 13 Feb 2019 10:10:12 +0100
Subject: [8u] RFR (XS) 8218613: [TESTBUG] runtime/ErrorHandling tests are
 building incorrect testlibrary classes
In-Reply-To: <629ca322-dcd7-52ed-6840-32c3cad27151@oracle.com>
References: <12824be8-7d91-f832-51e5-491c7b06b9a8@redhat.com>
 <cb15dd09-bdc4-c0eb-8b7f-17a7adff8c19@oracle.com>
 <CA+kOe09kHzi8u_m13qwqKabcwDBNy+beJmgffWjWa1pxoXaqew@mail.gmail.com>
 <224a577d-cd12-73e7-75c6-069972b97211@redhat.com>
 <629ca322-dcd7-52ed-6840-32c3cad27151@oracle.com>
Message-ID: <79b48687-691c-81cf-c2ac-74b175bbf730@redhat.com>

On 2/13/19 1:38 AM, Jonathan Gibbons wrote:
> It is a general goal for jtreg to support use on older systems, so I have a question regarding that
> aspect ... what is the oldest JDK for which you want to use jtreg (jdk7u?, jdk8u etc) and how do you
> run jtreg ... using the Makefiles, or in some custom setup? There's a hidden aspect to that last
> question, which is, what JDK do you use to run jtreg when testing these older platforms?

I run "make test", "make run-test" with whatever boot jdk is accepted in jdk9+. jdk8u does not have
lots of test definitions in TEST.groups (we would rectify that hopefully soon), so executing the
jtreg as standalone binary with system Java (8u), passing the $repo/test directory to it.

I think the minimal supported version should be jdk7u.

-Aleksey



From martijnverburg at gmail.com  Wed Feb 13 10:06:47 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 13 Feb 2019 10:06:47 +0000
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
Message-ID: <CAP7YuATB0Fmuuy+PsvzLTMKnkT-m-FpyEm0tQh=0y8QH5=Rhvg@mail.gmail.com>

Hi All,

Absolutely happy to help with the build and test, let us know when there's
a repo up and what the expected working platforms are and we'll get
building and testing :-).

I'd recommend folks who want to get an early understanding of our build
infra etc to join adoptopenjdk.net/slack.htm and look at our AdoptOpenJDK
repos on GitHub (start with TSC, infrastructure, build and then test).

Cheers,
Martijn


On Tue, 12 Feb 2019 at 18:55, Mario Torre <neugens at redhat.com> wrote:

> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> >
> > On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
> > > Andrew, do you think we can have a repository created for this
> > > purpose?
> >
> > At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
> > discussed. Perhaps that would fit the bill for this backport in a more
> > generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>
> My understanding was that this was dismissed, but I'm happy either way.
>
> If we have an agreement on how to call the repository then Andrew will
> create one right away.
>
> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> sure if we will want to coordinate this effort on a separate mailing
> list though, what do you think?
>
> 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 gnu.andrew at redhat.com  Wed Feb 13 16:50:05 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 13 Feb 2019 16:50:05 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
 <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
Message-ID: <CABi63P4gNURFa78UOPHobN6LMqw0QRU9t6b7doTyWVUwu_gApA@mail.gmail.com>

On Wed, 13 Feb 2019 at 09:06, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> Hi Andrew,
>
> I've wrote up a detailed proposal for the jdk11u update process and
> posted it on jdk-updates-dev yesterday [1]. In that mail I propose to
> have two repositories, jdk11u-dev as "always-open" development
> repository and jdk11u as consolidation repository for the upcoming
> update release. The main reason for having such a setup is that
> everybody can see (and test) all the non-security changes which will
> be in the next update release and members of the Vulenrability Group
> will even have the possibility to easily create (and test) a version
> of the upcoming update release which is very close to if not equal to
> the version Red Hat will be working on "in the dark". I think this is
> important not only to get a broader test coverage for upcoming update
> releases, but also to simplify the process of producing update
> releases for other down-stream distributors.
>
> The OpenJDK 8u project already has these two repositories (i.e.
> jdk8u/jdk8u and jdk8u/jdk8u-dev) so it would be trivial to implement
> my proposal for the 8u updates project. What do you think?
>
> Thank you and best regards,
> Volker
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000411.html

+1.

I'd like to see 11u & 8u working in a similar way to minimise confusion. That
means 8u adopting the tagging process from 11u, and 11 having two trees
so we can separate release-ready sources from development sources.

I've been thinking over a few things, but being too caught up with the
last lingering
parts of the CPU to post. My current idea is:

1. Changes are pushed to jdkxxu-dev after review and approval.

2. At regular periods (fortnightly?), changes are promoted to jdkxxu and tagged.

3. At a point before the CPU (basically when we have the patches, which is
usually at most a month before), jdkxxu is declared frozen so we have a base
for the update.

4. When the CPU is unembargoed, the changes are pushed to both trees and
a release made. jdkxxu is unfrozen and #2 resumes.

We will need something more involved if there are changes in jdkxxu-dev which
may need longer to soak. I would suggest they use a project tree or a new tree
within jdkxxu, then they are promoted to jdkxxu-dev when ready. This is much
like the way the AArch64 & PPC ports were added and is essentially a third
level below jdkxxu-dev.

I think we need to stick to a restricted set of maintainers for jdkxx, as I said
before [0]. The lead should obviously be one of those. I'll
additionally nominate
myself as someone who has a lot of experience of doing such merges and
releases, e.g with OpenJDK 6 & 7. But we should aim for more people so we
have some redundancy.

I think that's broadly along similar lines to what you posted to the
updates list earlier.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008509.html
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From aph at redhat.com  Wed Feb 13 16:59:08 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 13 Feb 2019 16:59:08 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
 <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
Message-ID: <88c8a130-961f-7a3b-39e4-a9980fa592c3@redhat.com>

On 2/13/19 9:05 AM, Volker Simonis wrote:

> I've wrote up a detailed proposal for the jdk11u update process and
> posted it on jdk-updates-dev yesterday [1]. In that mail I propose to
> have two repositories, jdk11u-dev as "always-open" development
> repository and jdk11u as consolidation repository for the upcoming
> update release. The main reason for having such a setup is that
> everybody can see (and test) all the non-security changes which will
> be in the next update release and members of the Vulenrability Group
> will even have the possibility to easily create (and test) a version
> of the upcoming update release which is very close to if not equal to
> the version Red Hat will be working on "in the dark".

We can share that information with VG members.

> I think this is important not only to get a broader test coverage
> for upcoming update releases, but also to simplify the process of
> producing update releases for other down-stream distributors.
> 
> The OpenJDK 8u project already has these two repositories (i.e.
> jdk8u/jdk8u and jdk8u/jdk8u-dev) so it would be trivial to implement
> my proposal for the 8u updates project. What do you think?

What you say above doesn't sound hugely different from what I have
proposed for jdk8u. Can you explain in what ways you believe it to be
different? Your jdk11 does seem to be rather over-prescriptive, but
not in any sense completely wrong.

I'll ask Andrew Hughes to comment on the precide details of what the
trees and branches are named.

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

From aph at redhat.com  Wed Feb 13 17:19:29 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 13 Feb 2019 17:19:29 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
 <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
Message-ID: <cf38b096-c3b0-ecda-e891-5b9cec82afcb@redhat.com>

On 2/13/19 9:05 AM, Volker Simonis wrote:
> The OpenJDK 8u project already has these two repositories (i.e.
> jdk8u/jdk8u and jdk8u/jdk8u-dev) so it would be trivial to implement
> my proposal for the 8u updates project. What do you think?

That's what we're going to do.

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

From christoph.langer at sap.com  Wed Feb 13 22:06:43 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Feb 2019 22:06:43 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CABi63P4gNURFa78UOPHobN6LMqw0QRU9t6b7doTyWVUwu_gApA@mail.gmail.com>
References: <119c5824-262e-b0d9-8a33-ceac24b7a8ab@redhat.com>
 <09404bec-476f-8191-1319-60266a4f9631@linux.vnet.ibm.com>
 <963bb29b-7f90-6744-ddb4-132609d1d689@redhat.com>
 <CAP7YuAQAURsncaLZn=fJQ2N=h1EaMSMp2+aNNVkaT9vvsrKESg@mail.gmail.com>
 <29e286ca-013b-023d-1cee-5938f551ceb7@redhat.com>
 <CAP7YuATnZA3ie9mLAj2w7U9Q1TuS1ao+fKx6rQcwYBrd=-vL6g@mail.gmail.com>
 <CA+3eh11FXBFBfUyesMroqozUmTrUeJunoGk7ON3cKpt-4-bedA@mail.gmail.com>
 <CABi63P4gNURFa78UOPHobN6LMqw0QRU9t6b7doTyWVUwu_gApA@mail.gmail.com>
Message-ID: <9939e07c22e8495c8cacf4e04b9ae6ab@sap.com>

Hi,

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Andrew Hughes
> Sent: Mittwoch, 13. Februar 2019 17:50
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFD: Draft guidelines for working on jdk8u
> 
> I'd like to see 11u & 8u working in a similar way to minimise confusion. That
> means 8u adopting the tagging process from 11u, and 11 having two trees
> so we can separate release-ready sources from development sources.
> 
> I've been thinking over a few things, but being too caught up with the
> last lingering
> parts of the CPU to post. My current idea is:
> 
> 1. Changes are pushed to jdkxxu-dev after review and approval.
> 
> 2. At regular periods (fortnightly?), changes are promoted to jdkxxu and
> tagged.
> 
> 3. At a point before the CPU (basically when we have the patches, which is
> usually at most a month before), jdkxxu is declared frozen so we have a base
> for the update.
> 
> 4. When the CPU is unembargoed, the changes are pushed to both trees and
> a release made. jdkxxu is unfrozen and #2 resumes.
> 
> We will need something more involved if there are changes in jdkxxu-dev
> which
> may need longer to soak. I would suggest they use a project tree or a new
> tree
> within jdkxxu, then they are promoted to jdkxxu-dev when ready. This is
> much
> like the way the AArch64 & PPC ports were added and is essentially a third
> level below jdkxxu-dev.

+1

> I think we need to stick to a restricted set of maintainers for jdkxx, as I said
> before [0]. The lead should obviously be one of those. I'll
> additionally nominate
> myself as someone who has a lot of experience of doing such merges and
> releases, e.g with OpenJDK 6 & 7. But we should aim for more people so we
> have some redundancy.

Right. The team at SAP volunteers for being involved as co-maintainers of jdk11u. ??

> I think that's broadly along similar lines to what you posted to the
> updates list earlier.

Yes, it looks to me as there is some common understanding here...
 
Best regards
Christoph


From hohensee at amazon.com  Thu Feb 14 22:22:39 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 14 Feb 2019 22:22:39 +0000
Subject: [8u] RFR (XS) 8214061: Buffer written into itself
In-Reply-To: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>
References: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>
Message-ID: <64DB1D4F-FF07-40AF-A5CA-9939D0DD9620@amazon.com>

Lgtm, need a Maintainer approval.

Paul

?On 2/12/19, 6:37 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:

    Please approve the push of trivial fix that makes the code correct and also resolves a compiler warning.
    
      Original Bug:
          URL: https://bugs.openjdk.java.net/browse/JDK-8214061
          Reporter: Severin Gehwolf
          Assignee: Severin Gehwolf
          Priority: P4
          Components: core-svc
    
      Original Fix:
            12: JDK-8214061, http://hg.openjdk.java.net/jdk/jdk/rev/8527b6100a59, 70 day(s) ago
    
      Backports and Forwardports:
            11: 11.0.3, JDK-8217003, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/4f3e66062582, 29
    day(s) ago
             8: MISSING
    
    Patch applies to 8u with reshuffling and fuzz. Here it is, for reference:
    
    diff -r b6dcf8ae496c src/share/back/debugInit.c
    --- a/src/share/back/debugInit.c        Wed Feb 06 04:09:08 2019 +0000
    +++ b/src/share/back/debugInit.c        Tue Feb 12 15:25:48 2019 +0100
    @@ -1,7 +1,7 @@
     /*
    - * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
      *
      * This code is free software; you can redistribute it and/or modify it
      * under the terms of the GNU General Public License version 2 only, as
      * published by the Free Software Foundation.  Oracle designates this
    @@ -663,11 +663,11 @@
         }
         if ( error != JVMTI_ERROR_NONE ) {
             (void)snprintf(buf, sizeof(buf), "JDWP %s, jvmtiError=%s(%d)",
                         msg, jvmtiErrorText(error), error);
         } else {
    -        (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
    +        (void)snprintf(buf, sizeof(buf), "JDWP %s", msg);
         }
         if (env != NULL) {
             (*((*env)->FatalError))(env, buf);
         } else {
             /* Should rarely ever reach here, means VM is really dead */
    
    
    Testing: Linux x86_64 build, hotspot jtregs (some unrelated failures)
    
    Thanks,
    -Aleksey
    
    


From christoph.langer at sap.com  Fri Feb 15 14:23:01 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 14:23:01 +0000
Subject: Fix version tags in JBS for jdk8u
Message-ID: <60bd9617ea464910a3009e8d849e8a27@sap.com>

Hi,

while looking around in JIRA, I noticed that changes pushed to the jdk8u-dev repo currently generate backport issues in JBS marked as ?Fix version: openjdk8u?. When Oracle was still maintaining the JDK8 updates project, there would be fix versions like ?8u212? eventually, which indicated the update version where the fixes went in. I guess Oracle will keep up with these version tags for their 8 updates in the future.
So, my question is: Will there be any such tagging for OpenJDK 8u updates? Has somebody already spent thoughts on this? It would probably be a nice thing, especially when somebody that is not too deep in the mercurial repos of OpenJDK wants to figure out whether a fix is in his OpenJDK version or where he?d have to go to? But it could be complicated to set it up, though.

Just asking ??

Best regards
Christoph


From shade at redhat.com  Fri Feb 15 14:27:15 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Feb 2019 15:27:15 +0100
Subject: Fix version tags in JBS for jdk8u
In-Reply-To: <60bd9617ea464910a3009e8d849e8a27@sap.com>
References: <60bd9617ea464910a3009e8d849e8a27@sap.com>
Message-ID: <f71f9ecd-6ffe-3d28-24bf-12d02b8986bf@redhat.com>

On 2/15/19 3:23 PM, Langer, Christoph wrote:
> while looking around in JIRA, I noticed that changes pushed to the jdk8u-dev repo currently
> generate backport issues in JBS marked as ?Fix version: openjdk8u?. When Oracle was still
> maintaining the JDK8 updates project, there would be fix versions like ?8u212? eventually, which
> indicated the update version where the fixes went in.

I think openjdk8u is the tag that is set for jdk8u/jdk8u-dev -- IIRC, it was this way before as
well. I expect proper tags to appear after jdk8u/jdk8u-dev -> jdk8u/jdk8u merge.

-Aleksey



From christoph.langer at sap.com  Fri Feb 15 15:43:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 15:43:41 +0000
Subject: Fix version tags in JBS for jdk8u
In-Reply-To: <f71f9ecd-6ffe-3d28-24bf-12d02b8986bf@redhat.com>
References: <60bd9617ea464910a3009e8d849e8a27@sap.com>
 <f71f9ecd-6ffe-3d28-24bf-12d02b8986bf@redhat.com>
Message-ID: <63cb58bc5b2449d6a6e1ab7dbe954638@sap.com>

Hi Aleksey,

> I think openjdk8u is the tag that is set for jdk8u/jdk8u-dev -- IIRC, it was this
> way before as
> well. I expect proper tags to appear after jdk8u/jdk8u-dev -> jdk8u/jdk8u
> merge.

Look at this guy [1]. This illustrates the process it had been so far quite good.

I pushed the change to jdk8u-dev when it was open for 8u192. So it fixed version "8u192". Then Oracle internally brought the fix to several other versions, e.g. 8u191. Andrew also brought the change to OpenJDK 7 - but there it only got the "openjdk7u" version tag. I guess that's what it would be for openjdk8u from now on as well - no "proper tags" if we don't take action.

Best regards
Christoph

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


From gnu.andrew at redhat.com  Fri Feb 15 16:33:16 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 15 Feb 2019 16:33:16 +0000
Subject: Fix version tags in JBS for jdk8u
In-Reply-To: <63cb58bc5b2449d6a6e1ab7dbe954638@sap.com>
References: <60bd9617ea464910a3009e8d849e8a27@sap.com>
 <f71f9ecd-6ffe-3d28-24bf-12d02b8986bf@redhat.com>
 <63cb58bc5b2449d6a6e1ab7dbe954638@sap.com>
Message-ID: <CABi63P6bXhi9dGuyyUa=PUQTLzHuVBzh3CpD7g=0gCweLgzuBw@mail.gmail.com>

On Fri, 15 Feb 2019 at 15:44, Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Aleksey,
>
> > I think openjdk8u is the tag that is set for jdk8u/jdk8u-dev -- IIRC, it was this
> > way before as
> > well. I expect proper tags to appear after jdk8u/jdk8u-dev -> jdk8u/jdk8u
> > merge.
>
> Look at this guy [1]. This illustrates the process it had been so far quite good.
>
> I pushed the change to jdk8u-dev when it was open for 8u192. So it fixed version "8u192". Then Oracle internally brought the fix to several other versions, e.g. 8u191. Andrew also brought the change to OpenJDK 7 - but there it only got the "openjdk7u" version tag. I guess that's what it would be for openjdk8u from now on as well - no "proper tags" if we don't take action.
>
> Best regards
> Christoph
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8197943
>

Indeed, I'm still not happy with the 7u situation. It seems that doing something
better means contacting the ops team at Oracle to get them to add more versions
and fix their hgupdater [0].

I would make most sense to me that they created an openjdk8ux version when
they created jdk8ux, but I don't know if that's possible.

Similar for 11u, I imagine.

[0] https://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-July/010333.html
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From christoph.langer at sap.com  Fri Feb 15 22:09:54 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Feb 2019 22:09:54 +0000
Subject: Fix version tags in JBS for jdk8u
In-Reply-To: <CABi63P6bXhi9dGuyyUa=PUQTLzHuVBzh3CpD7g=0gCweLgzuBw@mail.gmail.com>
References: <60bd9617ea464910a3009e8d849e8a27@sap.com>
 <f71f9ecd-6ffe-3d28-24bf-12d02b8986bf@redhat.com>
 <63cb58bc5b2449d6a6e1ab7dbe954638@sap.com>
 <CABi63P6bXhi9dGuyyUa=PUQTLzHuVBzh3CpD7g=0gCweLgzuBw@mail.gmail.com>
Message-ID: <e9b2b9189f3c4bed8a415d572fcb9917@sap.com>

Hi,

> > Look at this guy [1]. This illustrates the process it had been so far quite
> good.
> >
> > I pushed the change to jdk8u-dev when it was open for 8u192. So it fixed
> version "8u192". Then Oracle internally brought the fix to several other
> versions, e.g. 8u191. Andrew also brought the change to OpenJDK 7 - but
> there it only got the "openjdk7u" version tag. I guess that's what it would be
> for openjdk8u from now on as well - no "proper tags" if we don't take action.
> >
> > Best regards
> > Christoph
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8197943
> >
> 
> Indeed, I'm still not happy with the 7u situation. It seems that doing
> something
> better means contacting the ops team at Oracle to get them to add more
> versions
> and fix their hgupdater [0].
> 
> I would make most sense to me that they created an openjdk8ux version
> when
> they created jdk8ux, but I don't know if that's possible.

Interesting. Thanks for the history. Yes, then we should get in contact with the ops team to check out what's feasible. Hopefully times have changed a bit and it's easy to configure hgupdater for new versions.

> Similar for 11u, I imagine.

Yes. They have done that stuff for several updates (e.g. 11.0.1, 11.0.2, 11.0.3) already, so it should be possible that they'll help with further OpenJDK 11 updates.

/Christoph

> 
> [0] https://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-
> July/010333.html

From gnu.andrew at redhat.com  Mon Feb 18 22:25:14 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 18 Feb 2019 22:25:14 +0000
Subject: [8u] RFR (XS) 8214061: Buffer written into itself
In-Reply-To: <64DB1D4F-FF07-40AF-A5CA-9939D0DD9620@amazon.com>
References: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>
 <64DB1D4F-FF07-40AF-A5CA-9939D0DD9620@amazon.com>
Message-ID: <CABi63P5aCmz+Dub3fau7vTN4m0Kk83qy2+rzX2V6KeN2UPVsjQ@mail.gmail.com>

On Thu, 14 Feb 2019 at 22:24, Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Lgtm, need a Maintainer approval.
>
> Paul
>
> ?On 2/12/19, 6:37 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:
>
>     Please approve the push of trivial fix that makes the code correct and also resolves a compiler warning.
>
>       Original Bug:
>           URL: https://bugs.openjdk.java.net/browse/JDK-8214061
>           Reporter: Severin Gehwolf
>           Assignee: Severin Gehwolf
>           Priority: P4
>           Components: core-svc
>
>       Original Fix:
>             12: JDK-8214061, http://hg.openjdk.java.net/jdk/jdk/rev/8527b6100a59, 70 day(s) ago
>
>       Backports and Forwardports:
>             11: 11.0.3, JDK-8217003, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/4f3e66062582, 29
>     day(s) ago
>              8: MISSING
>
>     Patch applies to 8u with reshuffling and fuzz. Here it is, for reference:
>
>     diff -r b6dcf8ae496c src/share/back/debugInit.c
>     --- a/src/share/back/debugInit.c        Wed Feb 06 04:09:08 2019 +0000
>     +++ b/src/share/back/debugInit.c        Tue Feb 12 15:25:48 2019 +0100
>     @@ -1,7 +1,7 @@
>      /*
>     - * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
>     + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
>       * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>       *
>       * This code is free software; you can redistribute it and/or modify it
>       * under the terms of the GNU General Public License version 2 only, as
>       * published by the Free Software Foundation.  Oracle designates this
>     @@ -663,11 +663,11 @@
>          }
>          if ( error != JVMTI_ERROR_NONE ) {
>              (void)snprintf(buf, sizeof(buf), "JDWP %s, jvmtiError=%s(%d)",
>                          msg, jvmtiErrorText(error), error);
>          } else {
>     -        (void)snprintf(buf, sizeof(buf), "JDWP %s", buf);
>     +        (void)snprintf(buf, sizeof(buf), "JDWP %s", msg);
>          }
>          if (env != NULL) {
>              (*((*env)->FatalError))(env, buf);
>          } else {
>              /* Should rarely ever reach here, means VM is really dead */
>
>
>     Testing: Linux x86_64 build, hotspot jtregs (some unrelated failures)
>
>     Thanks,
>     -Aleksey
>
>
>

Approved.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb 18 22:29:54 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 18 Feb 2019 22:29:54 +0000
Subject: [8u] RFA+RFR (S) 8211231: BarrierSetC1::generate_referent_check()
 confuses register allocator
In-Reply-To: <87d0nxt4is.fsf@redhat.com>
References: <4f0649f6-a472-0e1e-00e0-f93574013dff@redhat.com>
 <87d0nxt4is.fsf@redhat.com>
Message-ID: <CABi63P4v7oVdJ_DJixzMTPMy1Ynihvvj4KGft2-ZYP4XuXCqRg@mail.gmail.com>

On Tue, 12 Feb 2019 at 15:24, Roland Westrelin <rwestrel at redhat.com> wrote:
>
>
> >    http://cr.openjdk.java.net/~shade/8211231/webrev.8u.01/
>
> 8u change looks good.
>
> Roland.

Approved.

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From christoph.langer at sap.com  Tue Feb 19 10:06:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Feb 2019 10:06:53 +0000
Subject: Open issues for backporting to 8u211/8u212
Message-ID: <330eec23f3604f02933c48ffae6962ea@sap.com>

Hi,

I created a filter showing issues that Oracle has brought to their 8u211/8u212 releases [0]. You need to be logged in to JBS, otherwise it won't work. No guarantee for completeness or bugs in the query. It currently shows 24 items.

I won't work on these, but maybe the filter is useful for some people on this list.

Best regards
Christoph

[0] https://bugs.openjdk.java.net/issues/?filter=36394


From shade at redhat.com  Tue Feb 19 11:07:11 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 12:07:11 +0100
Subject: [8u] RFR (XS) 8214061: Buffer written into itself
In-Reply-To: <CABi63P5aCmz+Dub3fau7vTN4m0Kk83qy2+rzX2V6KeN2UPVsjQ@mail.gmail.com>
References: <27fc8406-690c-294f-5ec4-15bd7c50e849@redhat.com>
 <64DB1D4F-FF07-40AF-A5CA-9939D0DD9620@amazon.com>
 <CABi63P5aCmz+Dub3fau7vTN4m0Kk83qy2+rzX2V6KeN2UPVsjQ@mail.gmail.com>
Message-ID: <9699bea9-aad0-4d05-4c85-e46078fe5eee@redhat.com>

On 2/18/19 11:25 PM, Andrew Hughes wrote:
> Approved.

Thanks, pushed.

-Aleksey




From shade at redhat.com  Tue Feb 19 11:07:26 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 19 Feb 2019 12:07:26 +0100
Subject: [8u] RFA+RFR (S) 8211231: BarrierSetC1::generate_referent_check()
 confuses register allocator
In-Reply-To: <CABi63P4v7oVdJ_DJixzMTPMy1Ynihvvj4KGft2-ZYP4XuXCqRg@mail.gmail.com>
References: <4f0649f6-a472-0e1e-00e0-f93574013dff@redhat.com>
 <87d0nxt4is.fsf@redhat.com>
 <CABi63P4v7oVdJ_DJixzMTPMy1Ynihvvj4KGft2-ZYP4XuXCqRg@mail.gmail.com>
Message-ID: <319def2d-38db-1c18-14a8-2595c4cc078a@redhat.com>

On 2/18/19 11:29 PM, Andrew Hughes wrote:
> On Tue, 12 Feb 2019 at 15:24, Roland Westrelin <rwestrel at redhat.com> wrote:
>>
>>
>>>    http://cr.openjdk.java.net/~shade/8211231/webrev.8u.01/
>>
>> 8u change looks good.
>>
>> Roland.
> 
> Approved.

Thanks, pushed.

-Aleksey


From deepak.kejriwal at oracle.com  Tue Feb 19 13:55:01 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Tue, 19 Feb 2019 05:55:01 -0800 (PST)
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
Message-ID: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>

Hi All,

Please review the backport of the following bug fixes to jdk8u-dev:

HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era 
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era 
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX

Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.00/

These code changes are made possible thanks to specification changes already pushed:
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7

Regards,
Deepak

 

 

 

From sean.coffey at oracle.com  Tue Feb 19 15:24:20 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 19 Feb 2019 15:24:20 +0000
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
Message-ID: <73e6114c-bea8-ee6e-7294-ada06abc19b6@oracle.com>

Looks fine to me.

some minor comments on formatting :

space after "//" style comments in your new tests :

e.g

> //List of new code points are not present in Unicode 6.2.
>    39                                          add(0x20BB); //NORDIC MARK SIGN
>    40                                          add(0x20BC); //MANAT SIGN
>    41                                          add(0x20BD); //RUBLE SIGN
>    42                                          add(0x20BE); //LARI SIGN
>    43                                          add(0x20BF); //BITCOIN SIGN
>    44                                          add(0x32FF); //SQUARE ERA NAME NEWERA

>    77             //Since Character.isJavaIdentifierPart(int) strictly conforms to
>    78             //character information from version 6.2 of the Unicode Standard,
>    79             //check if code point is new code point. If the code point is new
>    80             //code point, value of variable expected is considered false.
this looks like a typo in one of your new tests :

>   268     public static void testIsJavaLetterOrDigit() {
>   269         for (int i = 0; i <= Character.MAX_VALUE; ++i) {
>   270             char ch = (char) i;
>   271             boolean expected = false;
>   272             //Since Character.isIdentifierIgnorable(char) strictly conforms to
regards,
Sean.

On 19/02/2019 13:55, Deepak Kejriwal wrote:
> Hi All,
>
> Please review the backport of the following bug fixes to jdk8u-dev:
>
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX
>
> Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.00/
>
> These code changes are made possible thanks to specification changes already pushed:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
>
> Regards,
> Deepak
>
>   
>
>   
>
>   

From naoto.sato at oracle.com  Tue Feb 19 17:10:14 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 19 Feb 2019 09:10:14 -0800
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
Message-ID: <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>

Hi Deepak,

Almost all the comments for the 11u changes [1] applies here, except the 
"newCodePoint" comment. For this one, I'd suggest renaming 
"newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2"

Naoto

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058610.html

On 2/19/19 5:55 AM, Deepak Kejriwal wrote:
> Hi All,
> 
> Please review the backport of the following bug fixes to jdk8u-dev:
> 
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX
> 
> Webrev:  http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.00/
> 
> These code changes are made possible thanks to specification changes already pushed:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
> 
> Regards,
> Deepak
> 
>   
> 
>   
> 
>   
> 

From aph at redhat.com  Tue Feb 19 17:51:23 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Feb 2019 17:51:23 +0000
Subject: RFD: Draft guidelines for working on jdk8u
Message-ID: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>

[ I've amended this in response to the feedback I received. It's
different in two significant ways. Firstly, I am convinced that we
should run jdk11u and jdk8u in the same way, so I've amended the
wording to make that clear. Secondly, I was too strict in my "bug
fixes only" diktat: we should allow significant performance
improvements or we'll fall badly behind Oracle's proprietary jdk8
releases. ]

OpenJDK 8 is a long-term stable release of OpenJDK. Our primary goal
is to maintain it, fixing significant bugs and especially security
problems as we go along. The "first, do no harm" principle applies: we
must not break things.

In general we'll use the process in
https://openjdk.java.net/projects/jdk-updates/approval.html.

We do not yet have much experience with our test systems, so for the
first couple of quarters we should be fairly cautious. Later on we can
be more adventurous, but for now it's mostly "bug fixes only".

All fixes that significantly improve stability, security or
performance and do not change behavioural compatibility [1] will be
considered for jdk8u. To use the language of the JDK 6 project, by
default such fixes are assumed to be applicable to jdk8u, especially
if having "soaked" in later JDK releases for a time without incident.

By "significant" I mean any bug that affects runtime behaviour in a
way that either produces incorrect results, poor performance, or
crashes the VM, especially TCK failures. Failures that are due solely
to bizarre or unreasonable combinations of -XX: command-line
parameters probably don't reach the bar of significance, and fixing
them will carry a non-zero risk of breaking something, so we should
err on the size of caution.

Build failures on all platforms, including 32-bit ones, are assumed to
be applicable. Also, there is a good deal of C++ code with Undefined
Behaviour in HotSpot, and such bugs tend to cause failures with more
recent C++ compilers. While all UB fixes may be applied to jdk8u, they
should be submitted to the current jdk development tree first.

Occasionally we might have to make changes which raise compatibility
issues. We will liase with the Compatibility & Specification Review
(CSR) Group.

We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
contributors, and that's where everyone should push their patches
after maintainer approval. When the time comes for an update release,
jdk8u-dev will be copied to jdk8u for testing and stabilization. From
that point onwards only critical bug fixes may be applied to jdk8u, at
the discretion of the maintainers.

Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
Patch Update (CPU) release. Once the snapshot has been taken the
engineers working on the CPU will work in the dark, sharing the
patches with only the OpenJDK Vulnerability Group. Any patches not
committed to jdk8u at the time of the snapshot will probably have to
wait for a later release. [ I don't propose to make any non-CPU
releases: one release a quarter should be quite enough for
jdk8u. However, if an urgent problem arises we might need to make an
intermediate release. ]

Having said all of that, there is considerable customer demand for
backports of features from later OpenJDK releases. I don't intend to
forbid such backports, but strict rules will apply. Features which
apply to ports in jdk8u must have the property that they can be
disabled altogether by the use of a command-line switch. This switch
should turn the feature into a NOP, so that it does not affect the
rest of the system in any way. Reviewers should ensure that every hunk
in such a changeset is guarded by an if (Feature_enabled) statement or
something similar. This will also allow Feature_enabled to be made a
compile-time constant, and if set to false this will allow images to
be created without the feature.

With regard to the likely feature backports, there are several
possibilities, in particular the Java Flight Recorder (JFR).  It'll
take a while to produce the JFR backport, so we should perhaps create
a tree for it now by cloning the jdk8u-dev tree. Patches should be
reviewed, but it's obviously a work in progress.

[1] https://blogs.oracle.com/darcy/kinds-of-compatibility:-source,-binary,-and-behavioral

Comments welcome.

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

From gnu.andrew at redhat.com  Wed Feb 20 00:32:11 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Feb 2019 00:32:11 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
Message-ID: <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>

On Tue, 19 Feb 2019 at 17:52, Andrew Haley <aph at redhat.com> wrote:
>
snip...

> We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
> hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
> contributors, and that's where everyone should push their patches
> after maintainer approval. When the time comes for an update release,
> jdk8u-dev will be copied to jdk8u for testing and stabilization. From
> that point onwards only critical bug fixes may be applied to jdk8u, at
> the discretion of the maintainers.

I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
with jdk8ux-by style tags.

Also, in the spirit of 11u, are we intending to adopt its process of using
bug labels to request backports rather than e-mails i.e. jdk8u-fix-request? [0]

[0] https://openjdk.java.net/projects/jdk-updates/approval.html
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From martinrb at google.com  Wed Feb 20 04:50:33 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 19 Feb 2019 20:50:33 -0800
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
Message-ID: <CA+kOe0-EMt0fK_aQSz2v6cw_CZm6ofdSUH-tFOHc5ESw02CW9w@mail.gmail.com>

On Tue, Feb 19, 2019 at 4:34 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:

>
> I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
>

I agree.  The whole point of keeping separate repos is that jdk8u ("the
master") never regresses, yet is also fairly up to date.

jdk8u-dev is always open for developer changes, but may occasionally
regress.  It's one of the maintainers' jobs to ensure that such breakage
doesn't make it into jdk8u (it's never-ever-broken), and that jdk8u-dev
returns to health promptly.

From christoph.langer at sap.com  Wed Feb 20 10:08:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 10:08:16 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
Message-ID: <b1c217e93bd843fd947ac972c478658e@sap.com>

Hi,

> snip...
> 
> > We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
> > hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
> > contributors, and that's where everyone should push their patches
> > after maintainer approval. When the time comes for an update release,
> > jdk8u-dev will be copied to jdk8u for testing and stabilization. From
> > that point onwards only critical bug fixes may be applied to jdk8u, at
> > the discretion of the maintainers.
> 
> I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
> with jdk8ux-by style tags.

As per my last mail in jdk-updates-dev [1], I think there should be exactly one sync jdk8u-dev->jdk8u per quarterly release (e.g. RDP2)

But the other way round (jdk8u->jdk8u-dev), we should have regular syncs.

> Also, in the spirit of 11u, are we intending to adopt its process of using
> bug labels to request backports rather than e-mails i.e. jdk8u-fix-request? [0]
> 
> [0] https://openjdk.java.net/projects/jdk-updates/approval.html

I think that would be good. Then it's the same process for developers in any update release.

> Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
> Patch Update (CPU) release. Once the snapshot has been taken the
> engineers working on the CPU will work in the dark, sharing the
> patches with only the OpenJDK Vulnerability Group. Any patches not
> committed to jdk8u at the time of the snapshot will probably have to
> wait for a later release. [ I don't propose to make any non-CPU
> releases: one release a quarter should be quite enough for
> jdk8u. However, if an urgent problem arises we might need to make an
> intermediate release. ]

I'd rather prefer if the repository in the dark will regularly be refreshed from jdk8u and at the end of the CPU release be merged back to the open.

Best regards
Christoph


[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000542.html


From aph at redhat.com  Wed Feb 20 10:46:25 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 20 Feb 2019 10:46:25 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
Message-ID: <873530ba-f044-ebff-535c-ee739c0dae15@redhat.com>

On 2/20/19 12:32 AM, Andrew Hughes wrote:
> On Tue, 19 Feb 2019 at 17:52, Andrew Haley <aph at redhat.com> wrote:
>>
> snip...
> 
>> We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
>> hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
>> contributors, and that's where everyone should push their patches
>> after maintainer approval. When the time comes for an update release,
>> jdk8u-dev will be copied to jdk8u for testing and stabilization. From
>> that point onwards only critical bug fixes may be applied to jdk8u, at
>> the discretion of the maintainers.
> 
> I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
> with jdk8ux-by style tags.

Yes. Once a week has been suggested. So I should fix this para with

>> We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
>> hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
>> contributors, and that's where everyone should push their patches
>> after maintainer approval.
>> [ Patches pushed to jdk8u-dev will be copied to jdk8u at regular intervals.]
>> When the time comes for an update release,
>> jdk8u-dev will closed for testing and stabilization. From
>> that point onwards only critical bug fixes may be applied to jdk8u, at
>> the discretion of the maintainers.

OK?

> Also, in the spirit of 11u, are we intending to adopt its process of using
> bug labels to request backports rather than e-mails i.e. jdk8u-fix-request? [0]
> 
> [0] https://openjdk.java.net/projects/jdk-updates/approval.html

Yes. I didn't spell it out because it's in that reference:
>> In general we'll use the process in
>> https://openjdk.java.net/projects/jdk-updates/approval.html.

It would be hopelessly confusing to do it differently.

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

From christoph.langer at sap.com  Wed Feb 20 13:11:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 13:11:47 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <873530ba-f044-ebff-535c-ee739c0dae15@redhat.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <873530ba-f044-ebff-535c-ee739c0dae15@redhat.com>
Message-ID: <c7d1575d503d4143bf4d0014ac9c923f@sap.com>

Hi Andrew,

did you already read my last mail [0] ?

> > snip...
> >
> >> We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
> >> hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
> >> contributors, and that's where everyone should push their patches
> >> after maintainer approval. When the time comes for an update release,
> >> jdk8u-dev will be copied to jdk8u for testing and stabilization. From
> >> that point onwards only critical bug fixes may be applied to jdk8u, at
> >> the discretion of the maintainers.
> >
> > I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
> > with jdk8ux-by style tags.
> 
> Yes. Once a week has been suggested. So I should fix this para with
> 
> >> We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
> >> hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
> >> contributors, and that's where everyone should push their patches
> >> after maintainer approval.
> >> [ Patches pushed to jdk8u-dev will be copied to jdk8u at regular intervals.]
> >> When the time comes for an update release,
> >> jdk8u-dev will closed for testing and stabilization. From
> >> that point onwards only critical bug fixes may be applied to jdk8u, at
> >> the discretion of the maintainers.
> 
> OK?

My proposal would rather be like this:

We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
contributors, and that's where everyone should push their patches
after maintainer approval.
When the time comes for an update release (e.g. once per quarter),
jdk8u-dev will be copied to jdk8u to build the base for an update release.
jdk8u will be dedicated to testing and stabilization. Only critical bug fixes
may be applied to jdk8u, at the discretion of the maintainers.
[ The fixes done in jdk8u will be merged into jdk8u-dev at regular intervals.]

Isn't that what we want to do?

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008613.html


From aph at redhat.com  Wed Feb 20 13:45:23 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 20 Feb 2019 13:45:23 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <c7d1575d503d4143bf4d0014ac9c923f@sap.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <873530ba-f044-ebff-535c-ee739c0dae15@redhat.com>
 <c7d1575d503d4143bf4d0014ac9c923f@sap.com>
Message-ID: <23670c4b-5a9b-d01c-0ca0-38679710a266@redhat.com>

On 2/20/19 1:11 PM, Langer, Christoph wrote:
> Isn't that what we want to do?

I made a mistake. I meant to say

> Patches pushed to jdk8u-dev will be copied to jdk8u at regular intervals.
> When the time comes for an update release,
> jdk8u [not jdk8u-dev] will closed for testing and stabilization. From
> that point onwards only critical bug fixes may be applied to jdk8u, at
> the discretion of the maintainers.

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

From christoph.langer at sap.com  Wed Feb 20 14:12:38 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Feb 2019 14:12:38 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <23670c4b-5a9b-d01c-0ca0-38679710a266@redhat.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <873530ba-f044-ebff-535c-ee739c0dae15@redhat.com>
 <c7d1575d503d4143bf4d0014ac9c923f@sap.com>
 <23670c4b-5a9b-d01c-0ca0-38679710a266@redhat.com>
Message-ID: <e7600f94ac374a4f8039970b6257480d@sap.com>

> I made a mistake. I meant to say
> 
> > Patches pushed to jdk8u-dev will be copied to jdk8u at regular intervals.
> > When the time comes for an update release,
> > jdk8u [not jdk8u-dev] will closed for testing and stabilization. From
> > that point onwards only critical bug fixes may be applied to jdk8u, at
> > the discretion of the maintainers.

OK, that's better ?? Effectively, jdk8u will always be closed for testing and stabilization...

/Christoph


From aph at redhat.com  Wed Feb 20 14:26:45 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 20 Feb 2019 14:26:45 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <e7600f94ac374a4f8039970b6257480d@sap.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <873530ba-f044-ebff-535c-ee739c0dae15@redhat.com>
 <c7d1575d503d4143bf4d0014ac9c923f@sap.com>
 <23670c4b-5a9b-d01c-0ca0-38679710a266@redhat.com>
 <e7600f94ac374a4f8039970b6257480d@sap.com>
Message-ID: <a4258c96-8d68-9278-8997-cb4b757f4843@redhat.com>

On 2/20/19 2:12 PM, Langer, Christoph wrote:
> OK, that's better ?? Effectively, jdk8u will always be closed for testing and stabilization...

Except to a few blessed (cursed? ;-) people, yes.

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

From neugens at redhat.com  Thu Feb 14 11:20:03 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 14 Feb 2019 12:20:03 +0100
Subject: [Zulu-eng] Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
Message-ID: <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>

On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com> wrote:

> On 2/11/19 1:01 PM, Mario Torre wrote:
> > On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> >>
> >> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
> >>> Andrew, do you think we can have a repository created for this
> >>> purpose?
> >>
> >> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
> >> discussed. Perhaps that would fit the bill for this backport in a more
> >> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
> >
> > My understanding was that this was dismissed, but I'm happy either way.
> >
> > If we have an agreement on how to call the repository then Andrew will
> > create one right away.
> >
> > Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> > sure if we will want to coordinate this effort on a separate mailing
> > list though, what do you think?
>
> I think it would be cleaner to have multiple repositories: having to deal
> with branches make things pointlessly difficult. Maybe we should give this
> some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
> of this is that a casual visitor is less likely to be confused.
>

I like this proposal, it is future proof as it would make it clear also if
we ever had to add more of such repositories what they are for.

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 andrey at azul.com  Fri Feb 15 16:22:17 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Fri, 15 Feb 2019 16:22:17 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
Message-ID: <6E79B93A-A764-4263-9420-753E747343A2@azul.com>

[fixed subject, removed jfr-dev maillist]

In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284

Regards,
Andrey

On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>> wrote:



On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:
On 2/11/19 1:01 PM, Mario Torre wrote:
> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>> wrote:
>>
>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>>> Andrew, do you think we can have a repository created for this
>>> purpose?
>>
>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>> discussed. Perhaps that would fit the bill for this backport in a more
>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>
> My understanding was that this was dismissed, but I'm happy either way.
>
> If we have an agreement on how to call the repository then Andrew will
> create one right away.
>
> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> sure if we will want to coordinate this effort on a separate mailing
> list though, what do you think?

I think it would be cleaner to have multiple repositories: having to deal
with branches make things pointlessly difficult. Maybe we should give this
some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
of this is that a casual visitor is less likely to be confused.

I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.

Cheers,
Mario

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


From neugens at redhat.com  Tue Feb 19 11:33:58 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 19 Feb 2019 12:33:58 +0100
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
Message-ID: <CAJwKKmatQX4VZyXKfvFiW62_RbgGvniBJ4671vvhWK_6x+dj=Q@mail.gmail.com>

Awesome, thanks!

Cheers,
Mario

On Fri, Feb 15, 2019 at 5:22 PM Andrey Petushkov <andrey at azul.com> wrote:
>
> [fixed subject, removed jfr-dev maillist]
>
> In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284
>
> Regards,
> Andrey
>
> On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com> wrote:
>
>
>
> On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com> wrote:
>>
>> On 2/11/19 1:01 PM, Mario Torre wrote:
>> > On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>> >>
>> >> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>> >>> Andrew, do you think we can have a repository created for this
>> >>> purpose?
>> >>
>> >> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>> >> discussed. Perhaps that would fit the bill for this backport in a more
>> >> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>> >
>> > My understanding was that this was dismissed, but I'm happy either way.
>> >
>> > If we have an agreement on how to call the repository then Andrew will
>> > create one right away.
>> >
>> > Btw, I think the discussion should move to jdk8u-dev alone. I'm not
>> > sure if we will want to coordinate this effort on a separate mailing
>> > list though, what do you think?
>>
>> I think it would be cleaner to have multiple repositories: having to deal
>> with branches make things pointlessly difficult. Maybe we should give this
>> some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
>> of this is that a casual visitor is less likely to be confused.
>
>
> I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.
>
> 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
>
>


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

From guangyu.zhu at aliyun.com  Wed Feb 20 12:44:26 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Wed, 20 Feb 2019 20:44:26 +0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsIGZvciBiYWNrLXBvcnRpbmcgSkZSIHRvIE9wZW5KREs4dQ==?=
In-Reply-To: <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>,
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
Message-ID: <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>

Hi Andrey,

I'm just coming back from the Spring Festival holiday and sorry for the late response. I am very happy that Azul has ported jfr to multiple platforms. Are there any further updates to your difference analysis? I quickly studied the patch and found some differences:

- Your patch does not support thread sampling, and it looks like some code in jfrThreadSampler.cpp is commented out.
- Your patch does not support the gc event on g1, Alibaba's patch supports g1 events, which you have already mentioned.
- Alibaba divides the test into two parts. The test relies on the hotspot whitebox being moved to the hotspot directory, while Azul saves all tests under jdk dircetory and adds the hotspot whitebox to the test library.

I will spend more time comparing these two patches. Anyway, it seems that the jfr patch will enter jdk8u faster than we originally expected.

Thanks,
Guangyu

------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Feb. 16 (Sat.) 00:41
Recipient:Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>; Severin Gehwolf <sgehwolf at redhat.com>; Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net>; yumin qi <yumin.qi at gmail.com>; kingsum.chow <kingsum.chow at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>; guangyu.zhu <guangyu.zhu at aliyun.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

[fixed subject, removed jfr-dev maillist]

 In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284 

Regards,
Andrey

On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com> wrote:


On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com> wrote:
 On 2/11/19 1:01 PM, Mario Torre wrote:
 > On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
 >>
 >> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
 >>> Andrew, do you think we can have a repository created for this
 >>> purpose?
 >>
 >> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
 >> discussed. Perhaps that would fit the bill for this backport in a more
 >> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
 > 
 > My understanding was that this was dismissed, but I'm happy either way.
 > 
 > If we have an agreement on how to call the repository then Andrew will
 > create one right away.
 > 
 > Btw, I think the discussion should move to jdk8u-dev alone. I'm not
 > sure if we will want to coordinate this effort on a separate mailing
 > list though, what do you think?

 I think it would be cleaner to have multiple repositories: having to deal
 with branches make things pointlessly difficult. Maybe we should give this
 some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
 of this is that a casual visitor is less likely to be confused.

I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.

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 andrey at azul.com  Wed Feb 20 13:35:57 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 20 Feb 2019 13:35:57 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
Message-ID: <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>

Dear Guangyu,

On 20 Feb 2019, at 15:44, guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>> wrote:

Hi Andrey,

I'm just coming back from the Spring Festival holiday and sorry for the late response. I am very happy that Azul has ported jfr to multiple platforms. Are there any further updates to your difference analysis?
Not yet, sorry. Was distracted to do some other stuff
I quickly studied the patch and found some differences:

- Your patch does not support thread sampling, and it looks like some code in jfrThreadSampler.cpp is commented out.
Absolutely. It's great you have implemented that in absence of threadSMR
- Your patch does not support the gc event on g1, Alibaba's patch supports g1 events, which you have already mentioned.
Not exactly. Azul code supports GC events for G1 however we miss some important information, like region types, heap occupancy etc
- Alibaba divides the test into two parts. The test relies on the hotspot whitebox being moved to the hotspot directory, while Azul saves all tests under jdk dircetory and adds the hotspot whitebox to the test library.
Right. I'm not sure what's the best way

I will spend more time comparing these two patches. Anyway, it seems that the jfr patch will enter jdk8u faster than we originally expected.
Well, at least some jdk8u incubator repos ;)

Regards,
Andrey

Thanks,
Guangyu

------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>
Sent At:2019 Feb. 16 (Sat.) 00:41
Recipient:Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>; Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>; jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net>>; yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>; kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>; denghui.ddh <denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

[fixed subject, removed jfr-dev maillist]

In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284

Regards,
Andrey

On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>> wrote:



On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:
On 2/11/19 1:01 PM, Mario Torre wrote:
> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>> wrote:
>>
>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>>> Andrew, do you think we can have a repository created for this
>>> purpose?
>>
>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>> discussed. Perhaps that would fit the bill for this backport in a more
>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>
> My understanding was that this was dismissed, but I'm happy either way.
>
> If we have an agreement on how to call the repository then Andrew will
> create one right away.
>
> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> sure if we will want to coordinate this effort on a separate mailing
> list though, what do you think?

I think it would be cleaner to have multiple repositories: having to deal
with branches make things pointlessly difficult. Maybe we should give this
some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
of this is that a casual visitor is less likely to be confused.

I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.

Cheers,
Mario

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




From deepak.kejriwal at oracle.com  Wed Feb 20 16:57:14 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Wed, 20 Feb 2019 08:57:14 -0800 (PST)
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
 <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>
Message-ID: <f54e21e0-bd21-45d6-bbf5-94caf7d5f38c@default>

Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :-

http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.01/

Regards,
Deepak

-----Original Message-----
From: Naoto Sato 
Sent: Tuesday, February 19, 2019 10:40 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

Hi Deepak,

Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2"

Naoto

[1]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058610.html

On 2/19/19 5:55 AM, Deepak Kejriwal wrote:
> Hi All,
> 
> Please review the backport of the following bug fixes to jdk8u-dev:
> 
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
> HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square 
> character support for the Japanese new era HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong 
> short form text for supplemental Japanese era HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add 
> test cases for lenient Japanese era parsing HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change 
> isJavaIdentifierStart and isJavaIdentifierPart to handle new code 
> points HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 
> currency code points to Java SE 8uX
> 
> Webrev:  
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u
> /webrev.00/
> 
> These code changes are made possible thanks to specification changes already pushed:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
> 
> Regards,
> Deepak
> 
>   
> 
>   
> 
>   
> 

From naoto.sato at oracle.com  Wed Feb 20 17:37:08 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 20 Feb 2019 09:37:08 -0800
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <f54e21e0-bd21-45d6-bbf5-94caf7d5f38c@default>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
 <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>
 <f54e21e0-bd21-45d6-bbf5-94caf7d5f38c@default>
Message-ID: <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com>

Hi Deepak,

The same comment for 11u can be applied here too:

 > - Line 163,198: Exception messages are incorrect. they are for 
isJavaIdentifierStart().

Naoto

On 2/20/19 8:57 AM, Deepak Kejriwal wrote:
> Thanks Naoto San and Sean for review. I have incorporate all the comments. Please find below updated version of webrev :-
> 
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, February 19, 2019 10:40 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
> 
> Hi Deepak,
> 
> Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2"
> 
> Naoto
> 
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058610.html
> 
> On 2/19/19 5:55 AM, Deepak Kejriwal wrote:
>> Hi All,
>>
>> Please review the backport of the following bug fixes to jdk8u-dev:
>>
>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
>> HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square
>> character support for the Japanese new era HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong
>> short form text for supplemental Japanese era HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add
>> test cases for lenient Japanese era parsing HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change
>> isJavaIdentifierStart and isJavaIdentifierPart to handle new code
>> points HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5
>> currency code points to Java SE 8uX
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u
>> /webrev.00/
>>
>> These code changes are made possible thanks to specification changes already pushed:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
>>
>> Regards,
>> Deepak
>>
>>    
>>
>>    
>>
>>    
>>

From gnu.andrew at redhat.com  Wed Feb 20 17:39:18 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Feb 2019 17:39:18 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <b1c217e93bd843fd947ac972c478658e@sap.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <b1c217e93bd843fd947ac972c478658e@sap.com>
Message-ID: <CABi63P4oa4ErVYkG6jyRpF+Edb52AJ0WdPiS1F7j7Gkw6Fw-hA@mail.gmail.com>

On Wed, 20 Feb 2019 at 10:08, Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi,
>
> > snip...
> >
> > > We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
> > > hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
> > > contributors, and that's where everyone should push their patches
> > > after maintainer approval. When the time comes for an update release,
> > > jdk8u-dev will be copied to jdk8u for testing and stabilization. From
> > > that point onwards only critical bug fixes may be applied to jdk8u, at
> > > the discretion of the maintainers.
> >
> > I think jdk8u-dev -> jdk8u syncs need to be done at more regular intervals
> > with jdk8ux-by style tags.
>
> As per my last mail in jdk-updates-dev [1], I think there should be exactly one sync jdk8u-dev->jdk8u per quarterly release (e.g. RDP2)
>
> But the other way round (jdk8u->jdk8u-dev), we should have regular syncs.

But what is being synced from jdk8u->jdk8u-dev?
This seems to be suggesting that they are developed separately for a long
period of time. It also seems to be pretty risky to put changes directly
into jdk8u first before they have soaked in jdk8u-dev.

>
> > Also, in the spirit of 11u, are we intending to adopt its process of using
> > bug labels to request backports rather than e-mails i.e. jdk8u-fix-request? [0]
> >
> > [0] https://openjdk.java.net/projects/jdk-updates/approval.html
>
> I think that would be good. Then it's the same process for developers in any update release.
>
> > Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
> > Patch Update (CPU) release. Once the snapshot has been taken the
> > engineers working on the CPU will work in the dark, sharing the
> > patches with only the OpenJDK Vulnerability Group. Any patches not
> > committed to jdk8u at the time of the snapshot will probably have to
> > wait for a later release. [ I don't propose to make any non-CPU
> > releases: one release a quarter should be quite enough for
> > jdk8u. However, if an urgent problem arises we might need to make an
> > intermediate release. ]
>
> I'd rather prefer if the repository in the dark will regularly be refreshed from jdk8u and at the end of the CPU release be merged back to the open.

I don't think that's practical. Those working on the CPU have enough work
to do with backporting and testing without having to continually do integration
work from jdk8u. It should be frozen at the time the snapshot is taken and only
explicit exceptions pushed after that point.

>
> Best regards
> Christoph
>
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000542.html
>


-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From mbalao at redhat.com  Wed Feb 20 20:02:32 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 20 Feb 2019 17:02:32 -0300
Subject: [8u] RFA 8211435: Exception in thread "AWT-EventQueue-1"
 java.lang.IllegalArgumentException: null source
Message-ID: <02352f2c-a9ba-7069-92b9-e80364f268ba@redhat.com>

Hi,

I'd like to request an approval for the backport of "8211435 - Exception
in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null
source" [1] to jdk8u.

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

We need this patch in jdk8u because I'm planning to backport 8204142 bug
fix [2] to jdk8u and it may randomly expose the bug fixed by 8211435.

Risk introduced is very low. Backport was trivial. Patch applies
cleanly; I just enabled the test for all platforms.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8211435
[2] - https://bugs.openjdk.java.net/browse/JDK-8204142

From hohensee at amazon.com  Wed Feb 20 20:42:45 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Feb 2019 20:42:45 +0000
Subject: 8u202 BPR
Message-ID: <47AD29D0-D9F5-456E-991A-F3B21D6843F6@amazon.com>

Oracle just released a BPR for 8u202, see https://www.oracle.com/technetwork/java/javaseproducts/documentation/8u202-revision-builds-relnotes-5243968.html.

The BPR has 3 backports.

https://bugs.openjdk.java.net/browse/JDK-8213583
https://bugs.openjdk.java.net/browse/JDK-8207070
https://bugs.openjdk.java.net/browse/JDK-8027434

I?d like to backport these to 8u. Shall I use the jdk-updates process? I.e., tag the bugs with jdk8u-fix-request, wait for them to be tagged with jdk8u-fix-yes, then push?

Thanks,

Paul


From hohensee at amazon.com  Wed Feb 20 21:50:11 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 20 Feb 2019 21:50:11 +0000
Subject: Open issues for backporting to 8u211/8u212
In-Reply-To: <330eec23f3604f02933c48ffae6962ea@sap.com>
References: <330eec23f3604f02933c48ffae6962ea@sap.com>
Message-ID: <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>

Is anyone tackling these? If so, I and Xin Liu can help, if not, we volunteer to start.

Thanks,

Paul

?On 2/19/19, 2:08 AM, "jdk8u-dev on behalf of Langer, Christoph" <jdk8u-dev-bounces at openjdk.java.net on behalf of christoph.langer at sap.com> wrote:

    Hi,
    
    I created a filter showing issues that Oracle has brought to their 8u211/8u212 releases [0]. You need to be logged in to JBS, otherwise it won't work. No guarantee for completeness or bugs in the query. It currently shows 24 items.
    
    I won't work on these, but maybe the filter is useful for some people on this list.
    
    Best regards
    Christoph
    
    [0] https://bugs.openjdk.java.net/issues/?filter=36394
    
    


From gnu.andrew at redhat.com  Wed Feb 20 22:56:51 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Feb 2019 22:56:51 +0000
Subject: Open issues for backporting to 8u211/8u212
In-Reply-To: <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>
References: <330eec23f3604f02933c48ffae6962ea@sap.com>
 <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>
Message-ID: <CABi63P7td1Apgy+PVd=srxp81vjY6p+yeJqfM+nFwvS6eYEyMQ@mail.gmail.com>

On Wed, 20 Feb 2019 at 21:51, Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Is anyone tackling these? If so, I and Xin Liu can help, if not, we volunteer to start.
>
> Thanks,
>
> Paul
>

Not yet, as I've been finishing up on 7.

We could split the work between the three of us if you like. I should probably
take those that are also listed as applying to 7.

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Feb 20 22:59:18 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Feb 2019 22:59:18 +0000
Subject: 8u202 BPR
In-Reply-To: <47AD29D0-D9F5-456E-991A-F3B21D6843F6@amazon.com>
References: <47AD29D0-D9F5-456E-991A-F3B21D6843F6@amazon.com>
Message-ID: <CABi63P7VhOr4FqQNLiY4V+k-MT9_4Fz5GMy9=VcD+0Vs4C5KdQ@mail.gmail.com>

On Wed, 20 Feb 2019 at 20:43, Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Oracle just released a BPR for 8u202, see https://www.oracle.com/technetwork/java/javaseproducts/documentation/8u202-revision-builds-relnotes-5243968.html.
>
> The BPR has 3 backports.
>
> https://bugs.openjdk.java.net/browse/JDK-8213583
> https://bugs.openjdk.java.net/browse/JDK-8207070
> https://bugs.openjdk.java.net/browse/JDK-8027434
>
> I?d like to backport these to 8u. Shall I use the jdk-updates process? I.e., tag the bugs with jdk8u-fix-request, wait for them to be tagged with jdk8u-fix-yes, then push?
>
> Thanks,
>
> Paul
>

Yes please.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Wed Feb 20 23:44:05 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 00:44:05 +0100
Subject: Open issues for backporting to 8u211/8u212
In-Reply-To: <CABi63P7td1Apgy+PVd=srxp81vjY6p+yeJqfM+nFwvS6eYEyMQ@mail.gmail.com>
References: <330eec23f3604f02933c48ffae6962ea@sap.com>
 <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>
 <CABi63P7td1Apgy+PVd=srxp81vjY6p+yeJqfM+nFwvS6eYEyMQ@mail.gmail.com>
Message-ID: <218ef2c1-73c4-e27e-b9df-ab195eea7ca6@redhat.com>

On 2/20/19 11:56 PM, Andrew Hughes wrote:
> On Wed, 20 Feb 2019 at 21:51, Hohensee, Paul <hohensee at amazon.com> wrote:
>>
>> Is anyone tackling these? If so, I and Xin Liu can help, if not, we volunteer to start.
>>
>> Thanks,
>>
>> Paul
>>
> 
> Not yet, as I've been finishing up on 7.

And we have just finished with 11.

> We could split the work between the three of us if you like. I should probably
> take those that are also listed as applying to 7.

I can take a few. Our (Red Hat) thing is to mark issues we are working on with "redhat-openjdk"
label. There are some that were marked during 11 backporting, those we can take on for 8 too. And
some additional things, time permitting.

-Aleksey



From christoph.langer at sap.com  Thu Feb 21 00:58:44 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 00:58:44 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <CABi63P4oa4ErVYkG6jyRpF+Edb52AJ0WdPiS1F7j7Gkw6Fw-hA@mail.gmail.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <b1c217e93bd843fd947ac972c478658e@sap.com>
 <CABi63P4oa4ErVYkG6jyRpF+Edb52AJ0WdPiS1F7j7Gkw6Fw-hA@mail.gmail.com>
Message-ID: <107bdcfc1bc4413f899092dd04fd4617@sap.com>

Hi Andrew,

> > > I think jdk8u-dev -> jdk8u syncs need to be done at more regular
> intervals
> > > with jdk8ux-by style tags.
> >
> > As per my last mail in jdk-updates-dev [1], I think there should be exactly
> one sync jdk8u-dev->jdk8u per quarterly release (e.g. RDP2)
> >
> > But the other way round (jdk8u->jdk8u-dev), we should have regular
> syncs.
> 
> But what is being synced from jdk8u->jdk8u-dev?
> This seems to be suggesting that they are developed separately for a long
> period of time. It also seems to be pretty risky to put changes directly
> into jdk8u first before they have soaked in jdk8u-dev.

Well, how long separate development occurs is something that we can decide. Oracle creates release branches quite soon after a CPU has been shipped. We can branch later.

Generally, I don't think we should see lots of changes in the stabilization repository. We have to restrict activity to real P1 issues, cherry-picks of changes that Oracle has picked into their equivalent CPU update and test fixes. Apart from the Oracle replays, which we'll have to do, all other changes in the stabilization repository shall only fix things and not bear high risk of introducing regressions.

> > > Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
> > > Patch Update (CPU) release. Once the snapshot has been taken the
> > > engineers working on the CPU will work in the dark, sharing the
> > > patches with only the OpenJDK Vulnerability Group. Any patches not
> > > committed to jdk8u at the time of the snapshot will probably have to
> > > wait for a later release. [ I don't propose to make any non-CPU
> > > releases: one release a quarter should be quite enough for
> > > jdk8u. However, if an urgent problem arises we might need to make an
> > > intermediate release. ]
> >
> > I'd rather prefer if the repository in the dark will regularly be refreshed
> from jdk8u and at the end of the CPU release be merged back to the open.
> 
> I don't think that's practical. Those working on the CPU have enough work
> to do with backporting and testing without having to continually do
> integration
> work from jdk8u. It should be frozen at the time the snapshot is taken and
> only
> explicit exceptions pushed after that point.

The stabilization repository will always be virtually frozen. Only explicit exceptions of the types I have named above will ever be allowed in the release repository. So I would not expect too much of integration issues. You can also start considerably later with the CPU compared to the time of the fork from dev to stabilization.

Best regards
Christoph


From gnu.andrew at redhat.com  Thu Feb 21 03:47:46 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 21 Feb 2019 03:47:46 +0000
Subject: Open issues for backporting to 8u211/8u212
In-Reply-To: <218ef2c1-73c4-e27e-b9df-ab195eea7ca6@redhat.com>
References: <330eec23f3604f02933c48ffae6962ea@sap.com>
 <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>
 <CABi63P7td1Apgy+PVd=srxp81vjY6p+yeJqfM+nFwvS6eYEyMQ@mail.gmail.com>
 <218ef2c1-73c4-e27e-b9df-ab195eea7ca6@redhat.com>
Message-ID: <CABi63P5-xZJVgk6EVOjYuwob=xPXHO=F5Yia8sioBP1hUapO5g@mail.gmail.com>

On Wed, 20 Feb 2019 at 23:44, Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/20/19 11:56 PM, Andrew Hughes wrote:
> > On Wed, 20 Feb 2019 at 21:51, Hohensee, Paul <hohensee at amazon.com> wrote:
> >>
> >> Is anyone tackling these? If so, I and Xin Liu can help, if not, we volunteer to start.
> >>
> >> Thanks,
> >>
> >> Paul
> >>
> >
> > Not yet, as I've been finishing up on 7.
>
> And we have just finished with 11.
>
> > We could split the work between the three of us if you like. I should probably
> > take those that are also listed as applying to 7.
>
> I can take a few. Our (Red Hat) thing is to mark issues we are working on with "redhat-openjdk"
> label. There are some that were marked during 11 backporting, those we can take on for 8 too. And
> some additional things, time permitting.
>
> -Aleksey
>
>

We need to know if the fix version has been sorted first, otherwise
we'll have to go and manually
alter all the bugs. Have we had any feedback from ops?

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From christoph.langer at sap.com  Thu Feb 21 05:43:43 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Feb 2019 05:43:43 +0000
Subject: Open issues for backporting to 8u211/8u212
In-Reply-To: <CABi63P5-xZJVgk6EVOjYuwob=xPXHO=F5Yia8sioBP1hUapO5g@mail.gmail.com>
References: <330eec23f3604f02933c48ffae6962ea@sap.com>
 <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>
 <CABi63P7td1Apgy+PVd=srxp81vjY6p+yeJqfM+nFwvS6eYEyMQ@mail.gmail.com>
 <218ef2c1-73c4-e27e-b9df-ab195eea7ca6@redhat.com>
 <CABi63P5-xZJVgk6EVOjYuwob=xPXHO=F5Yia8sioBP1hUapO5g@mail.gmail.com>
Message-ID: <955619953fb24554983edff286452fd6@sap.com>

Hi,

> We need to know if the fix version has been sorted first, otherwise
> we'll have to go and manually
> alter all the bugs. Have we had any feedback from ops?

I think aph needs to send the mail to ops to request them, still.

/Christoph


From deepak.kejriwal at oracle.com  Thu Feb 21 08:54:43 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Thu, 21 Feb 2019 00:54:43 -0800 (PST)
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
 <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>
 <f54e21e0-bd21-45d6-bbf5-94caf7d5f38c@default>
 <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com>
Message-ID: <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default>

Hi Naoto,

Corrected the exception message. Please find below updated version of webrev:-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/


Thanks for review.

Regards,
Deepak

-----Original Message-----
From: Naoto Sato 
Sent: Wednesday, February 20, 2019 11:07 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Sean Coffey <sean.coffey at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

Hi Deepak,

The same comment for 11u can be applied here too:

 > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().

Naoto

On 2/20/19 8:57 AM, Deepak Kejriwal wrote:
> Thanks Naoto San and Sean for review. I have incorporate all the 
> comments. Please find below updated version of webrev :-
> 
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u
> /webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, February 19, 2019 10:40 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev 
> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, 
> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
> 
> Hi Deepak,
> 
> Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2"
> 
> Naoto
> 
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/05
> 8610.html
> 
> On 2/19/19 5:55 AM, Deepak Kejriwal wrote:
>> Hi All,
>>
>> Please review the backport of the following bug fixes to jdk8u-dev:
>>
>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
>> HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : 
>> Square character support for the Japanese new era HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong 
>> short form text for supplemental Japanese era HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add 
>> test cases for lenient Japanese era parsing HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : 
>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new 
>> code points HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 
>> currency code points to Java SE 8uX
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8
>> u
>> /webrev.00/
>>
>> These code changes are made possible thanks to specification changes already pushed:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
>>
>> Regards,
>> Deepak
>>
>>    
>>
>>    
>>
>>    
>>

From aph at redhat.com  Thu Feb 21 09:15:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Feb 2019 09:15:27 +0000
Subject: Open issues for backporting to 8u211/8u212
In-Reply-To: <955619953fb24554983edff286452fd6@sap.com>
References: <330eec23f3604f02933c48ffae6962ea@sap.com>
 <499A7BAA-CCBF-450D-86B9-0EE560532DE4@amazon.com>
 <CABi63P7td1Apgy+PVd=srxp81vjY6p+yeJqfM+nFwvS6eYEyMQ@mail.gmail.com>
 <218ef2c1-73c4-e27e-b9df-ab195eea7ca6@redhat.com>
 <CABi63P5-xZJVgk6EVOjYuwob=xPXHO=F5Yia8sioBP1hUapO5g@mail.gmail.com>
 <955619953fb24554983edff286452fd6@sap.com>
Message-ID: <f6ad121e-4a22-2e4a-ba0b-3ff0215b8933@redhat.com>

On 2/21/19 5:43 AM, Langer, Christoph wrote:
>> We need to know if the fix version has been sorted first, otherwise
>> we'll have to go and manually
>> alter all the bugs. Have we had any feedback from ops?
> I think aph needs to send the mail to ops to request them, still.

That's done some time ago. ops@ sent the request to add openjdk8u211
to JBS.  Once that exists, ops will set hgupdater to openjdk8u211 for
jdk8u

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

From aph at redhat.com  Thu Feb 21 09:23:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Feb 2019 09:23:27 +0000
Subject: RFD: Draft guidelines for working on jdk8u
In-Reply-To: <107bdcfc1bc4413f899092dd04fd4617@sap.com>
References: <d4b6cee5-8fd6-d8a7-6175-bf90686f8b02@redhat.com>
 <CABi63P7c3NTwhZ=NPPm+XLvhHHYc=yudZoJbbsCf03j5qsfR+A@mail.gmail.com>
 <b1c217e93bd843fd947ac972c478658e@sap.com>
 <CABi63P4oa4ErVYkG6jyRpF+Edb52AJ0WdPiS1F7j7Gkw6Fw-hA@mail.gmail.com>
 <107bdcfc1bc4413f899092dd04fd4617@sap.com>
Message-ID: <e42cf7fb-36fe-d4de-3dc9-bdcea4231249@redhat.com>

On 2/21/19 12:58 AM, Langer, Christoph wrote:

>>> I'd rather prefer if the repository in the dark will regularly be
>>> refreshed from jdk8u and at the end of the CPU release be merged
>>> back to the open.

>> I don't think that's practical. Those working on the CPU have
>> enough work to do with backporting and testing without having to
>> continually do integration work from jdk8u. It should be frozen at
>> the time the snapshot is taken and only explicit exceptions pushed
>> after that point.

> The stabilization repository will always be virtually frozen. Only
> explicit exceptions of the types I have named above will ever be
> allowed in the release repository. So I would not expect too much of
> integration issues.

If the repo is virtually frozen, then there's nothing to be gained by
regularly refereshing from it. It's risking occasional breakage for no
signitificant gain.

> You can also start considerably later with the CPU compared to the
> time of the fork from dev to stabilization.

I don't think it does much good to specualte about possible future
needs. If we have problems that we need to solve with automation we'll
do that.

Andrew.

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

From sean.coffey at oracle.com  Thu Feb 21 10:27:04 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 21 Feb 2019 10:27:04 +0000
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
 <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>
 <f54e21e0-bd21-45d6-bbf5-94caf7d5f38c@default>
 <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com>
 <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default>
Message-ID: <a1db41a1-cd33-2da2-f732-bf6cbd2d9b90@oracle.com>

Looks good.

regards,
Sean.

On 21/02/2019 08:54, Deepak Kejriwal wrote:
> Hi Naoto,
>
> Corrected the exception message. Please find below updated version of webrev:-
> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/
>
>
> Thanks for review.
>
> Regards,
> Deepak
>
> -----Original Message-----
> From: Naoto Sato
> Sent: Wednesday, February 20, 2019 11:07 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Sean Coffey <sean.coffey at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
>
> Hi Deepak,
>
> The same comment for 11u can be applied here too:
>
>   > - Line 163,198: Exception messages are incorrect. they are for isJavaIdentifierStart().
>
> Naoto
>
> On 2/20/19 8:57 AM, Deepak Kejriwal wrote:
>> Thanks Naoto San and Sean for review. I have incorporate all the
>> comments. Please find below updated version of webrev :-
>>
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u
>> /webrev.01/
>>
>> Regards,
>> Deepak
>>
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Tuesday, February 19, 2019 10:40 PM
>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev
>> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
>> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398,
>> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
>>
>> Hi Deepak,
>>
>> Almost all the comments for the 11u changes [1] applies here, except the "newCodePoint" comment. For this one, I'd suggest renaming "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2"
>>
>> Naoto
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/05
>> 8610.html
>>
>> On 2/19/19 5:55 AM, Deepak Kejriwal wrote:
>>> Hi All,
>>>
>>> Please review the backport of the following bug fixes to jdk8u-dev:
>>>
>>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation.
>>> HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters.
>>> HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 :
>>> Square character support for the Japanese new era HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong
>>> short form text for supplemental Japanese era HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add
>>> test cases for lenient Japanese era parsing HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 :
>>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new
>>> code points HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5
>>> currency code points to Java SE 8uX
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8
>>> u
>>> /webrev.00/
>>>
>>> These code changes are made possible thanks to specification changes already pushed:
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
>>>
>>> Regards,
>>> Deepak
>>>
>>>     
>>>
>>>     
>>>
>>>     
>>>

From naoto.sato at oracle.com  Thu Feb 21 15:48:51 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 21 Feb 2019 07:48:51 -0800
Subject: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469,
 JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <a1db41a1-cd33-2da2-f732-bf6cbd2d9b90@oracle.com>
References: <1baa71ac-4a38-4a00-8fe1-0aea85315f1c@default>
 <8e49cca4-0fca-a158-1cad-9590cc187add@oracle.com>
 <f54e21e0-bd21-45d6-bbf5-94caf7d5f38c@default>
 <6a3ff77d-ac17-b072-83e5-7b91c4163be4@oracle.com>
 <87fb7fb1-eb11-4b5a-a026-b0bf0da57327@default>
 <a1db41a1-cd33-2da2-f732-bf6cbd2d9b90@oracle.com>
Message-ID: <32827b53-a6eb-0f1b-7781-5addef2598b4@oracle.com>

+1

Please follow the appropriate process to push the changeset.

Naoto

On 2/21/19 2:27 AM, Se?n Coffey wrote:
> Looks good.
> 
> regards,
> Sean.
> 
> On 21/02/2019 08:54, Deepak Kejriwal wrote:
>> Hi Naoto,
>>
>> Corrected the exception message. Please find below updated version of 
>> webrev:-
>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ 
>>
>>
>>
>> Thanks for review.
>>
>> Regards,
>> Deepak
>>
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Wednesday, February 20, 2019 11:07 PM
>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Sean Coffey 
>> <sean.coffey at oracle.com>; core-libs-dev 
>> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
>> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, 
>> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
>>
>> Hi Deepak,
>>
>> The same comment for 11u can be applied here too:
>>
>> ? > - Line 163,198: Exception messages are incorrect. they are for 
>> isJavaIdentifierStart().
>>
>> Naoto
>>
>> On 2/20/19 8:57 AM, Deepak Kejriwal wrote:
>>> Thanks Naoto San and Sean for review. I have incorporate all the
>>> comments. Please find below updated version of webrev :-
>>>
>>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u
>>> /webrev.01/
>>>
>>> Regards,
>>> Deepak
>>>
>>> -----Original Message-----
>>> From: Naoto Sato
>>> Sent: Tuesday, February 19, 2019 10:40 PM
>>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; core-libs-dev
>>> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
>>> Subject: Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398,
>>> JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
>>>
>>> Hi Deepak,
>>>
>>> Almost all the comments for the 11u changes [1] applies here, except 
>>> the "newCodePoint" comment. For this one, I'd suggest renaming 
>>> "newCodePoints" to "UNASSIGNED_CODEPOINTS_IN_6_2"
>>>
>>> Naoto
>>>
>>> [1]
>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/05
>>> 8610.html
>>>
>>> On 2/19/19 5:55 AM, Deepak Kejriwal wrote:
>>>> Hi All,
>>>>
>>>> Please review the backport of the following bug fixes to jdk8u-dev:
>>>>
>>>> HYPERLINK 
>>>> "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: 
>>>> Japanese new era implementation.
>>>> HYPERLINK 
>>>> "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: 
>>>> Placeholder for Japanese new era should be two characters.
>>>> HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 :
>>>> Square character support for the Japanese new era HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong
>>>> short form text for supplemental Japanese era HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add
>>>> test cases for lenient Japanese era parsing HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 :
>>>> Change isJavaIdentifierStart and isJavaIdentifierPart to handle new
>>>> code points HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5
>>>> currency code points to Java SE 8uX
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8
>>>> u
>>>> /webrev.00/
>>>>
>>>> These code changes are made possible thanks to specification changes 
>>>> already pushed:
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7
>>>>
>>>> Regards,
>>>> Deepak
>>>>
>>>>
>>>>
>>>>

From shade at redhat.com  Thu Feb 21 15:52:29 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 16:52:29 +0100
Subject: [8u] RFA+RFR (M) 8213952: Relax DNSName restriction as per RFC 1123
Message-ID: <66395f26-d00c-2eb9-7fe1-e1ca14d6c8f3@redhat.com>

Please review and approve 8u backport:

  Original Bug:
      URL: https://bugs.openjdk.java.net/browse/JDK-8213952
      Reporter: Sean Coffey
      Assignee: Sean Coffey
      Priority: P4
      Components: security-libs

  Original Fix:
        12: JDK-8213952, http://hg.openjdk.java.net/jdk/jdk/rev/5f3b9b633731, 78 day(s) ago

  Backports and Forwardports:
        11: 11.0.3, JDK-8219240, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/56d673a2ff47, 3
day(s) ago
         8: MISSING

The patch does not apply cleanly to jdk8u-dev, because it needs reshuffling and merges in comments.
Please review carefully. I eyeballed the original change vs. 8u version myself, but could use
another careful look.

8u webrev:
  http://cr.openjdk.java.net/~shade/8213952/webrev.01.8u/

Testing: new regression test, sun/security/tools/keytool tests, sun/security/x509/GeneralName tests

Thanks,
-Aleksey


From shade at redhat.com  Thu Feb 21 18:03:10 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 19:03:10 +0100
Subject: JDK-8191948, 8u211 and push confusion
Message-ID: <0e69917b-a874-24fe-a5d6-8fd252e5340b@redhat.com>

Hi,

I am so confused how do 8u tags correspond with actual fixes delivered.

Sifting through Christoph list:
  https://bugs.openjdk.java.net/issues/?filter=36394

Look at this bug:
  https://bugs.openjdk.java.net/browse/JDK-8191948

It has a single backport with fix version "8u211":
  https://bugs.openjdk.java.net/browse/JDK-8214637

...which is apparently Oracle-internal 8u branch? The backport issue indeed has no hgupdater comment
that goes with pushes to repositories, which seems to be usual for these internal pushes. Yet, here
is the push:
  http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b88f126a9690

...which apparently got into jdk8u202-b01?!

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/jdk8u202-b01/src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java#l1114

How so? Is it the hgupdater bug? Was 8191948 backport pushed accidentally to the 8u202?

-Aleksey



From hohensee at amazon.com  Thu Feb 21 18:02:52 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Feb 2019 18:02:52 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser when
 desktop contains shortcuts pointing to deleted files
Message-ID: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>

Please approve this 8u backport which is part of Oracle?s recent 8u202 BPR.

Original Bug:
URL: https://bugs.openjdk.java.net/browse/JDK-8213583
Reporter: Shadow Bug
Assignee: Dmitry Markov
Priority: P2
Components: client-libs

Original Fix:
12: JDK-8213583, http://hg.openjdk.java.net/jdk/jdk/rev/c8071863df80, 2 months ago

Backports and Forwardports:
11: 11.0.3:, JDK-8213583, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/93f4a52e6c8e, 2 months ago
8: MISSING

A trivial patch that applies cleanly.

Thanks,

Paul


From hohensee at amazon.com  Thu Feb 21 18:39:37 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Feb 2019 18:39:37 +0000
Subject: [8u-dev] RFA + RFR (S): 8207070:Webstart app popup on wrong screen in
 a one-screen setup changing to multi-monitor
Message-ID: <7BE4730C-8CB6-4057-A91F-4C6E85FDD136@amazon.com>

Please review and approve this 8u backport which is part of Oracle?s recent 8u202 BPR.

Original Bug:
URL: https://bugs.openjdk.java.net/browse/JDK-8207070
Reporter: Shadow Bug
Assignee: Dmitry Markov
Priority: P3
Components: client-libs

Original Fix:
12: JDK-8207070, http://hg.openjdk.java.net/jdk/jdk/rev/6cf31480d3a3, 3 months ago

Backports and Forwardports:
11: 11.0.3:, JDK-8213583, http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/09456a6d05fb, 3 months ago
8: MISSING

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

The patch applies cleanly net of two small pieces of code in WToolkit.java and WWindowPeer.java replaced by the patch that were slightly changed between jdk8 and jdk11. Included regression test passes.

Thanks,

Paul



From shade at redhat.com  Thu Feb 21 18:45:04 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 21 Feb 2019 19:45:04 +0100
Subject: [8u-dev] RFA + RFR (S): 8207070:Webstart app popup on wrong
 screen in a one-screen setup changing to multi-monitor
In-Reply-To: <7BE4730C-8CB6-4057-A91F-4C6E85FDD136@amazon.com>
References: <7BE4730C-8CB6-4057-A91F-4C6E85FDD136@amazon.com>
Message-ID: <77161eb7-fced-597b-18ff-d34314021c42@redhat.com>

On 2/21/19 7:39 PM, Hohensee, Paul wrote:
> 8u backport webrev: http://cr.openjdk.java.net/~phh/webrev.8u.00/

Backport change looks good.

-Aleksey


From mbalao at redhat.com  Thu Feb 21 19:07:15 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Feb 2019 16:07:15 -0300
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive out of
 sequence in multiple AppContexts
Message-ID: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>

Hi,

I'd like to propose the backport of 8204142 [1] to jdk8u.

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.jdk8u/
 *
http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.jdk8u.zip

This patch is already included in mainline [2] and in jdk11u [3].
Backport was trivial.

No regressions found in "java/awt/event" test category.

Can I have an approval?

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8204142
[2] - http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd
[3] - http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f05fb1cc6882

From hohensee at amazon.com  Thu Feb 21 20:12:51 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Feb 2019 20:12:51 +0000
Subject: [8u-dev] RFA + RFR (S): 8207070:Webstart app popup on wrong
 screen in a one-screen setup changing to multi-monitor
In-Reply-To: <77161eb7-fced-597b-18ff-d34314021c42@redhat.com>
References: <7BE4730C-8CB6-4057-A91F-4C6E85FDD136@amazon.com>
 <77161eb7-fced-597b-18ff-d34314021c42@redhat.com>
Message-ID: <88C5EBBA-DD08-4C96-B4C6-4D9BCEAE23A0@amazon.com>

Thanks, Aleksey!

Are you a Maintainer? If not, would one of you who are please approve?

Paul

?On 2/21/19, 10:46 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    On 2/21/19 7:39 PM, Hohensee, Paul wrote:
    > 8u backport webrev: http://cr.openjdk.java.net/~phh/webrev.8u.00/
    
    Backport change looks good.
    
    -Aleksey
    
    


From hohensee at amazon.com  Thu Feb 21 20:37:48 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 21 Feb 2019 20:37:48 +0000
Subject: [8u-dev] RFA (S): 8027434: "-XX:OnOutOfMemoryError" uses fork instead
 of vfork
Message-ID: <5FF8FBB4-D97A-4BF8-9108-886DAC081DF8@amazon.com>

(I?m going back to the old request format).

Please approve this 8u backport which is part of Oracle?s recent 8u202 BPR.

JBS: https://bugs.openjdk.java.net/browse/JDK-8027434
Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/101c2b6eacbe
Webrev: http://cr.openjdk.java.net/~phh/8027434/webrev.8u.00/
Review thread: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030361.html

The patch applies cleanly net of line number changes and file locations.

Thanks,

Paul



From hohensee at amazon.com  Fri Feb 22 01:33:56 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 01:33:56 +0000
Subject: [8u-dev] RFA + RFR (M): 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is
 disabled after 8211883
Message-ID: <F0D81BC8-E544-4E50-87B9-E61E86890720@amazon.com>

Please review/approve this backport to 8u that is tagged by Oracle for 8u211.

JBS: https://bugs.openjdk.java.net/browse/JDK-8217579
Webrev: http://cr.openjdk.java.net/~phh/8217579/webrev.8u.00/
jdk11u backport patch: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd764f251274
Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/ad3438957ff5

jdk11u backport review thread: https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019271.html
Original review thread: https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019256.html



There are 3 differences between this patch and the jdk11u patch.



The first is that the 8u change in SSLAlgorithmDecomposer.java compares against CipherSuite.C_SCSV rather than CipherSuite.TLS_EMPTY_RENEGOTIATION_INFO_SCSV. C_SCSV appears to be the 8u equivalent of 11u?s TLS_EMPTY_RENEGOTIATION_INFO_SCSV.



The second is that the TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 ciphers do not appear to be supported by 8u.



Finally, the cipher dump order in CheckCipherSuites.java is different in 8u compared to 11u, though the number and names of the ciphers are the same (other than the two above).



Thanks,



Paul




From hohensee at amazon.com  Fri Feb 22 02:32:27 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 02:32:27 +0000
Subject: [8u-dev] RFA (XS): JDK-8215364: JavaFX crashes on Ubuntu 18.04 with
 Wayland while using Swing-FX interop
Message-ID: <15800131-3C30-4745-A0DC-49C23399534F@amazon.com>

Please approve this backport to 8u that is tagged by Oracle for 8u212.

JBS: https://bugs.openjdk.java.net/browse/JDK-8215364
Webrev: http://cr.openjdk.java.net/~phh/8215634/webrev.8u.01/
Original patch: http://hg.openjdk.java.net/jdk/jdk12/rev/6e8c8d16ecb4
Original review thread: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014872.html

The patch is trivial and applies cleanly net of line number changes and file locations.

Thanks,

Paul



From david.holmes at oracle.com  Fri Feb 22 02:34:30 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Feb 2019 12:34:30 +1000
Subject: JDK-8191948, 8u211 and push confusion
In-Reply-To: <0e69917b-a874-24fe-a5d6-8fd252e5340b@redhat.com>
References: <0e69917b-a874-24fe-a5d6-8fd252e5340b@redhat.com>
Message-ID: <4a0a8c26-5d81-3657-11b4-d27648c7f425@oracle.com>

Hi Aleksey,

On 22/02/2019 4:03 am, Aleksey Shipilev wrote:
> Hi,
> 
> I am so confused how do 8u tags correspond with actual fixes delivered.
> 
> Sifting through Christoph list:
>    https://bugs.openjdk.java.net/issues/?filter=36394
> 
> Look at this bug:
>    https://bugs.openjdk.java.net/browse/JDK-8191948
> 
> It has a single backport with fix version "8u211":
>    https://bugs.openjdk.java.net/browse/JDK-8214637

It actually has multiple backports but most of them are not public.

> ...which is apparently Oracle-internal 8u branch? The backport issue indeed has no hgupdater comment
> that goes with pushes to repositories, which seems to be usual for these internal pushes. 

The hgupdater comment is non-public hence you can't see it.

> Yet, here is the push:
>    http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b88f126a9690
> 
> ...which apparently got into jdk8u202-b01?!
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/jdk8u202-b01/src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java#l1114
> 
> How so? Is it the hgupdater bug? Was 8191948 backport pushed accidentally to the 8u202?

For some reason the 8u202 backport issue is non-public, despite the 
changesets going to the OpenJDK 8u forests. I'm querying that to see if 
it can be changed.

At the same time the 8u211 Oracle backport is a public issue for a 
non-public push.

Both were created by hgupdater but I have no idea why it chose the 
settings it did. There may be a glitch there that needs to be looked into.

HTH,
David

> -Aleksey
> 
> 

From david.holmes at oracle.com  Fri Feb 22 03:18:25 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Feb 2019 13:18:25 +1000
Subject: JDK-8191948, 8u211 and push confusion
In-Reply-To: <4a0a8c26-5d81-3657-11b4-d27648c7f425@oracle.com>
References: <0e69917b-a874-24fe-a5d6-8fd252e5340b@redhat.com>
 <4a0a8c26-5d81-3657-11b4-d27648c7f425@oracle.com>
Message-ID: <b234be7d-e4af-2b73-9f7c-c813998a9d02@oracle.com>

I've now switched the public/not-public settings on the two backports. 
Seems it relates to the setting on the main issue (which was non-public 
initially then much later changed) and the time at which the backport 
items were created.

David

On 22/02/2019 12:34 pm, David Holmes wrote:
> Hi Aleksey,
> 
> On 22/02/2019 4:03 am, Aleksey Shipilev wrote:
>> Hi,
>>
>> I am so confused how do 8u tags correspond with actual fixes delivered.
>>
>> Sifting through Christoph list:
>> ?? https://bugs.openjdk.java.net/issues/?filter=36394
>>
>> Look at this bug:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8191948
>>
>> It has a single backport with fix version "8u211":
>> ?? https://bugs.openjdk.java.net/browse/JDK-8214637
> 
> It actually has multiple backports but most of them are not public.
> 
>> ...which is apparently Oracle-internal 8u branch? The backport issue 
>> indeed has no hgupdater comment
>> that goes with pushes to repositories, which seems to be usual for 
>> these internal pushes. 
> 
> The hgupdater comment is non-public hence you can't see it.
> 
>> Yet, here is the push:
>> ?? http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b88f126a9690
>>
>> ...which apparently got into jdk8u202-b01?!
>>
>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/jdk8u202-b01/src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java#l1114 
>>
>>
>> How so? Is it the hgupdater bug? Was 8191948 backport pushed 
>> accidentally to the 8u202?
> 
> For some reason the 8u202 backport issue is non-public, despite the 
> changesets going to the OpenJDK 8u forests. I'm querying that to see if 
> it can be changed.
> 
> At the same time the 8u211 Oracle backport is a public issue for a 
> non-public push.
> 
> Both were created by hgupdater but I have no idea why it chose the 
> settings it did. There may be a glitch there that needs to be looked into.
> 
> HTH,
> David
> 
>> -Aleksey
>>
>>

From aph at redhat.com  Fri Feb 22 09:08:55 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 Feb 2019 09:08:55 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
Message-ID: <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>

On 2/21/19 6:02 PM, Hohensee, Paul wrote:
> Please approve this 8u backport which is part of Oracle?s recent 8u202 BPR.

I approve.
Do you want me to create the jdk8u-fix-request tags as well?

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

From shade at redhat.com  Fri Feb 22 10:32:09 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 11:32:09 +0100
Subject: JDK-8191948, 8u211 and push confusion
In-Reply-To: <b234be7d-e4af-2b73-9f7c-c813998a9d02@oracle.com>
References: <0e69917b-a874-24fe-a5d6-8fd252e5340b@redhat.com>
 <4a0a8c26-5d81-3657-11b4-d27648c7f425@oracle.com>
 <b234be7d-e4af-2b73-9f7c-c813998a9d02@oracle.com>
Message-ID: <2a0ea18d-908c-a360-2ebe-eb24e96e0058@redhat.com>

On 2/22/19 4:18 AM, David Holmes wrote:
> I've now switched the public/not-public settings on the two backports. Seems it relates to the
> setting on the main issue (which was non-public initially then much later changed) and the time at
> which the backport items were created.

Okay, thanks for looking into this!

Indeed, 8u202 makes sense, and I see there is a proper hgupdater link now.

Eh, this was a head-scratcher for outsiders.

-Aleksey



From shade at redhat.com  Fri Feb 22 10:40:25 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 11:40:25 +0100
Subject: [8u-dev] RFA + RFR (S): 8207070:Webstart app popup on wrong
 screen in a one-screen setup changing to multi-monitor
In-Reply-To: <88C5EBBA-DD08-4C96-B4C6-4D9BCEAE23A0@amazon.com>
References: <7BE4730C-8CB6-4057-A91F-4C6E85FDD136@amazon.com>
 <77161eb7-fced-597b-18ff-d34314021c42@redhat.com>
 <88C5EBBA-DD08-4C96-B4C6-4D9BCEAE23A0@amazon.com>
Message-ID: <063f5aca-3e6e-fcaf-1e58-6510ffce80a6@redhat.com>

Not a Maintainer, need either of Andrew's ack [1].

-Aleksey

[1] https://wiki.openjdk.java.net/display/jdk8u/Main

On 2/21/19 9:12 PM, Hohensee, Paul wrote:
> Thanks, Aleksey!
> 
> Are you a Maintainer? If not, would one of you who are please approve?
> 
> Paul
> 
> ?On 2/21/19, 10:46 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:
> 
>     On 2/21/19 7:39 PM, Hohensee, Paul wrote:
>     > 8u backport webrev: http://cr.openjdk.java.net/~phh/webrev.8u.00/
>     
>     Backport change looks good.
>     
>     -Aleksey
>     
>     
> 



From shade at redhat.com  Fri Feb 22 13:15:09 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 14:15:09 +0100
Subject: [8u] RFA+RFR (S) 8214189:
 test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java
 fails on Windows x64 when run with -XX:-TieredCompilation
Message-ID: <2c29fa02-5935-9811-00c0-59f6be593f35@redhat.com>

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8214189

Original fix:
  http://hg.openjdk.java.net/jdk/jdk/rev/0037ea3c7322

Patch does not apply to 8u cleanly and needs manual merge. It seems 8u code has "unsigned int"
instead of "unsigned long" in modified locations. New test does not fail with unfixed 8u, so I
wonder if this patch is needed in 8u, Roland?

Test also moved to proper location in 8u. ProblemList change does not apply to 8u as well. Christoph
handles 11u backport.

8u webrev:
  http://cr.openjdk.java.net/~shade/8214189/webrev.8u.01/

Testing: {Windows, Linux} x86_64 build, test/compiler/integerArithmetic/

Thanks,
-Aleksey


From rwestrel at redhat.com  Fri Feb 22 13:32:08 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 22 Feb 2019 14:32:08 +0100
Subject: [8u] RFA+RFR (S) 8214189:
 test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java
 fails on Windows x64 when run with -XX:-TieredCompilation
In-Reply-To: <2c29fa02-5935-9811-00c0-59f6be593f35@redhat.com>
References: <2c29fa02-5935-9811-00c0-59f6be593f35@redhat.com>
Message-ID: <877edst0dj.fsf@redhat.com>


Thanks for taking of that one. I missed when I backported related patches.

> Patch does not apply to 8u cleanly and needs manual merge. It seems 8u code has "unsigned int"
> instead of "unsigned long" in modified locations. New test does not fail with unfixed 8u, so I
> wonder if this patch is needed in 8u, Roland?

It seems you applied the patch to the wrong method: MulINode::Ideal()
instead of MulLNode::Ideal()

Roland.

From christoph.langer at sap.com  Fri Feb 22 14:42:57 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 14:42:57 +0000
Subject: [8u] RFA+RFR (M) 8213952: Relax DNSName restriction as per RFC
 1123
In-Reply-To: <66395f26-d00c-2eb9-7fe1-e1ca14d6c8f3@redhat.com>
References: <66395f26-d00c-2eb9-7fe1-e1ca14d6c8f3@redhat.com>
Message-ID: <a3a7def0e9584e0faffd44804ed875b9@sap.com>

Hi Aleksey,

I eyeballed your webrev and it looks good to me.

I've also labelled JDK-8213952 with jdk8u-fix-request to start this type of process, as it seems that's what we want in jdk8 as well.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Aleksey Shipilev
> Sent: Donnerstag, 21. Februar 2019 16:52
> To: jdk8u-dev at openjdk.java.net
> Subject: [8u] RFA+RFR (M) 8213952: Relax DNSName restriction as per RFC
> 1123
> 
> Please review and approve 8u backport:
> 
>   Original Bug:
>       URL: https://bugs.openjdk.java.net/browse/JDK-8213952
>       Reporter: Sean Coffey
>       Assignee: Sean Coffey
>       Priority: P4
>       Components: security-libs
> 
>   Original Fix:
>         12: JDK-8213952, http://hg.openjdk.java.net/jdk/jdk/rev/5f3b9b633731,
> 78 day(s) ago
> 
>   Backports and Forwardports:
>         11: 11.0.3, JDK-8219240, http://hg.openjdk.java.net/jdk-
> updates/jdk11u/rev/56d673a2ff47, 3
> day(s) ago
>          8: MISSING
> 
> The patch does not apply cleanly to jdk8u-dev, because it needs reshuffling
> and merges in comments.
> Please review carefully. I eyeballed the original change vs. 8u version myself,
> but could use
> another careful look.
> 
> 8u webrev:
>   http://cr.openjdk.java.net/~shade/8213952/webrev.01.8u/
> 
> Testing: new regression test, sun/security/tools/keytool tests,
> sun/security/x509/GeneralName tests
> 
> Thanks,
> -Aleksey


From christoph.langer at sap.com  Fri Feb 22 14:49:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 14:49:45 +0000
Subject: [8u-dev] RFA + RFR (M): 8217579:
 TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
In-Reply-To: <F0D81BC8-E544-4E50-87B9-E61E86890720@amazon.com>
References: <F0D81BC8-E544-4E50-87B9-E61E86890720@amazon.com>
Message-ID: <30efef92b58841d79c9eceb94f46b5ab@sap.com>

Hi Paul,

the backport change looks good to me. I've labeled JDK-8217579 with jdk8u-fix-request.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Hohensee, Paul
> Sent: Freitag, 22. Februar 2019 02:34
> To: jdk8u-dev at openjdk.java.net
> Subject: [8u-dev] RFA + RFR (M): 8217579:
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
> 
> Please review/approve this backport to 8u that is tagged by Oracle for 8u211.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8217579
> Webrev: http://cr.openjdk.java.net/~phh/8217579/webrev.8u.00/
> jdk11u backport patch: http://hg.openjdk.java.net/jdk-
> updates/jdk11u/rev/dd764f251274
> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/ad3438957ff5
> 
> jdk11u backport review thread:
> https://mail.openjdk.java.net/pipermail/security-dev/2019-
> January/019271.html
> Original review thread: https://mail.openjdk.java.net/pipermail/security-
> dev/2019-January/019256.html
> 
> 
> 
> There are 3 differences between this patch and the jdk11u patch.
> 
> 
> 
> The first is that the 8u change in SSLAlgorithmDecomposer.java compares
> against CipherSuite.C_SCSV rather than
> CipherSuite.TLS_EMPTY_RENEGOTIATION_INFO_SCSV. C_SCSV appears to
> be the 8u equivalent of 11u?s TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
> 
> 
> 
> The second is that the TLS_AES_128_GCM_SHA256 and
> TLS_AES_256_GCM_SHA384 ciphers do not appear to be supported by 8u.
> 
> 
> 
> Finally, the cipher dump order in CheckCipherSuites.java is different in 8u
> compared to 11u, though the number and names of the ciphers are the same
> (other than the two above).
> 
> 
> 
> Thanks,
> 
> 
> 
> Paul
> 
> 


From christoph.langer at sap.com  Fri Feb 22 14:52:38 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 14:52:38 +0000
Subject: [8u-dev] RFA (XS): JDK-8215364: JavaFX crashes on Ubuntu 18.04
 with Wayland while using Swing-FX interop
In-Reply-To: <15800131-3C30-4745-A0DC-49C23399534F@amazon.com>
References: <15800131-3C30-4745-A0DC-49C23399534F@amazon.com>
Message-ID: <5adee07e0ebc49569461e8c4e74f02f8@sap.com>

Hi,

I can't comment on the purpose/content of this patch. But shouldn't it be relevant to jdk11, too (@Aleksey)?

I've also set the jdk8u-fix-request label.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Hohensee, Paul
> Sent: Freitag, 22. Februar 2019 03:32
> To: jdk8u-dev at openjdk.java.net
> Subject: [8u-dev] RFA (XS): JDK-8215364: JavaFX crashes on Ubuntu 18.04
> with Wayland while using Swing-FX interop
> 
> Please approve this backport to 8u that is tagged by Oracle for 8u212.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8215364
> Webrev: http://cr.openjdk.java.net/~phh/8215634/webrev.8u.01/
> Original patch: http://hg.openjdk.java.net/jdk/jdk12/rev/6e8c8d16ecb4
> Original review thread: https://mail.openjdk.java.net/pipermail/awt-
> dev/2018-December/014872.html
> 
> The patch is trivial and applies cleanly net of line number changes and file
> locations.
> 
> Thanks,
> 
> Paul
> 


From christoph.langer at sap.com  Fri Feb 22 14:56:18 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 14:56:18 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
Message-ID: <7c26347bc1e84a7e981a10f4eafa7331@sap.com>

Hi Andrew,

I've set the jdk8u-fix-request label (here and on all the other requests that came in today).

This is the filter showing all unapproved items: https://bugs.openjdk.java.net/issues/?filter=36415

So, please go and set the jdk8u-fix-yes tags as appropriate.

Best regards
Christoph


> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Andrew Haley
> Sent: Freitag, 22. Februar 2019 10:09
> To: jdk8u-dev at openjdk.java.net
> Subject: Re: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
> when desktop contains shortcuts pointing to deleted files
> 
> On 2/21/19 6:02 PM, Hohensee, Paul wrote:
> > Please approve this 8u backport which is part of Oracle?s recent 8u202 BPR.
> 
> I approve.
> Do you want me to create the jdk8u-fix-request tags as well?
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Fri Feb 22 15:28:43 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 16:28:43 +0100
Subject: [8u] RFA+RFR (S) 8214189:
 test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java
 fails on Windows x64 when run with -XX:-TieredCompilation
In-Reply-To: <877edst0dj.fsf@redhat.com>
References: <2c29fa02-5935-9811-00c0-59f6be593f35@redhat.com>
 <877edst0dj.fsf@redhat.com>
Message-ID: <5b81e7bc-52a4-a798-e21c-19dd99010a9e@redhat.com>

On 2/22/19 2:32 PM, Roland Westrelin wrote:
>> Patch does not apply to 8u cleanly and needs manual merge. It seems 8u code has "unsigned int"
>> instead of "unsigned long" in modified locations. New test does not fail with unfixed 8u, so I
>> wonder if this patch is needed in 8u, Roland?
> 
> It seems you applied the patch to the wrong method: MulINode::Ideal()
> instead of MulLNode::Ideal()

Oh, for the love of God. Good catch!

New webrev:
  http://cr.openjdk.java.net/~shade/8214189/webrev.8u.02/

-Aleksey


From christoph.langer at sap.com  Fri Feb 22 15:31:24 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 15:31:24 +0000
Subject: JDK 8 updates process: jdk8u-dev and jdk8u forests, fix versions, fix
 approval process
Message-ID: <b1c02227a8af4b89b3b2186401a92476@sap.com>

Hi Andrew,

it seems the OpenJDK 8u211 backporting works have begun. But I feel the communication about some process details has not been clear enough. It?s about repositories, fix versions and labels. So, I?d like you to have a look at my questions below and give some guidance/confirmation/correction.

We?ll use the jdk8u-fix-request/jdk8u-fix-yes (or no?) process as in jdk11, correct? I thought so by reading the previous mail threads and hence added the request label to all items where push approval has been asked for in the last 2 days. Hope that was ok ??

The latest pushes to jdk8u-dev (which date back a few days) indicate that the fix version that hgupdater uses when handling pushes to jdk8u-dev is ?openjdk8u?. I understand that the request has been made to add the fix version ?openjdk8u211? to JBS and to use it for jd8u-dev by hgupdater. Is that correct?

Can you please communicate once ?openjdk8u211? is available?

If you agree, I would fix the existing ?openjdk8u? backport issues to set their fix version to ?openjdk8u211? once the latter is available. That way it?ll be clearer for people that search in the JBS system in which OpenJDK update they should expect their fixes. Ok?

Furthermore, I have the understanding that all open fixes should now be pushed to jdk8u-dev until we reach a state when all is in and we can merge/copy into jdk8u. Correct?

Thanks & Best regards
Christoph


From rwestrel at redhat.com  Fri Feb 22 15:31:29 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 22 Feb 2019 16:31:29 +0100
Subject: [8u] RFA+RFR (S) 8214189:
 test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java
 fails on Windows x64 when run with -XX:-TieredCompilation
In-Reply-To: <5b81e7bc-52a4-a798-e21c-19dd99010a9e@redhat.com>
References: <2c29fa02-5935-9811-00c0-59f6be593f35@redhat.com>
 <877edst0dj.fsf@redhat.com> <5b81e7bc-52a4-a798-e21c-19dd99010a9e@redhat.com>
Message-ID: <874l8vu9f2.fsf@redhat.com>


>   http://cr.openjdk.java.net/~shade/8214189/webrev.8u.02/

Looks good.

Roland.

From shade at redhat.com  Fri Feb 22 15:35:45 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 16:35:45 +0100
Subject: [8u-dev] RFA (XS): JDK-8215364: JavaFX crashes on Ubuntu 18.04
 with Wayland while using Swing-FX interop
In-Reply-To: <5adee07e0ebc49569461e8c4e74f02f8@sap.com>
References: <15800131-3C30-4745-A0DC-49C23399534F@amazon.com>
 <5adee07e0ebc49569461e8c4e74f02f8@sap.com>
Message-ID: <d2b81b07-6109-aa5d-fded-f334d4982f67@redhat.com>

On 2/22/19 3:52 PM, Langer, Christoph wrote:
> I can't comment on the purpose/content of this patch. But shouldn't it be relevant to jdk11, too (@Aleksey)?

Quite probably so. Marked to get it on our radar.

-Aleksey


From aph at redhat.com  Fri Feb 22 16:04:41 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 Feb 2019 16:04:41 +0000
Subject: JDK 8 updates process: jdk8u-dev and jdk8u forests, fix versions, 
 fix approval process
In-Reply-To: <b1c02227a8af4b89b3b2186401a92476@sap.com>
References: <b1c02227a8af4b89b3b2186401a92476@sap.com>
Message-ID: <9b2531ae-9f76-e438-ec86-70f02237b03b@redhat.com>

On 2/22/19 3:31 PM, Langer, Christoph wrote:

> We?ll use the jdk8u-fix-request/jdk8u-fix-yes (or no?) process as in
> jdk11, correct? I thought so by reading the previous mail threads
> and hence added the request label to all items where push approval
> has been asked for in the last 2 days. Hope that was ok ??

Yes. As we discussed, there should be no difference in this process
from later updates.

> The latest pushes to jdk8u-dev (which date back a few days) indicate
> that the fix version that hgupdater uses when handling pushes to
> jdk8u-dev is ?openjdk8u?. I understand that the request has been
> made to add the fix version ?openjdk8u211? to JBS and to use it for
> jd8u-dev by hgupdater. Is that correct?

Yes.

> Can you please communicate once ?openjdk8u211? is available?

As soon as I get the message.

> If you agree, I would fix the existing ?openjdk8u? backport issues
> to set their fix version to ?openjdk8u211? once the latter is
> available. That way it?ll be clearer for people that search in the
> JBS system in which OpenJDK update they should expect their
> fixes. Ok?

OK.

> Furthermore, I have the understanding that all open fixes should now
> be pushed to jdk8u-dev until we reach a state when all is in and we
> can merge/copy into jdk8u. Correct?

For now, yes. I'll let the list know when the time has come to close
jdk8u.

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

From hohensee at amazon.com  Fri Feb 22 16:18:46 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 16:18:46 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
 <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
Message-ID: <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>

I'll start applying the jdk8u-fix-request labels. Thanks for doing that on my approval request so far.

Paul

?On 2/22/19, 6:58 AM, "jdk8u-dev on behalf of Langer, Christoph" <jdk8u-dev-bounces at openjdk.java.net on behalf of christoph.langer at sap.com> wrote:

    Hi Andrew,
    
    I've set the jdk8u-fix-request label (here and on all the other requests that came in today).
    
    This is the filter showing all unapproved items: https://bugs.openjdk.java.net/issues/?filter=36415
    
    So, please go and set the jdk8u-fix-yes tags as appropriate.
    
    Best regards
    Christoph
    
    
    > -----Original Message-----
    > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
    > Andrew Haley
    > Sent: Freitag, 22. Februar 2019 10:09
    > To: jdk8u-dev at openjdk.java.net
    > Subject: Re: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
    > when desktop contains shortcuts pointing to deleted files
    > 
    > On 2/21/19 6:02 PM, Hohensee, Paul wrote:
    > > Please approve this 8u backport which is part of Oracle?s recent 8u202 BPR.
    > 
    > I approve.
    > Do you want me to create the jdk8u-fix-request tags as well?
    > 
    > --
    > Andrew Haley
    > Java Platform Lead Engineer
    > Red Hat UK Ltd. <https://www.redhat.com>
    > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
    


From hohensee at amazon.com  Fri Feb 22 16:46:04 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 16:46:04 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
 <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
 <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>
Message-ID: <F8E24153-AA51-4B76-A39A-F00CB83D3DA0@amazon.com>

Also, it would be good to have a way to tag an issue with "I'm starting work on a backport to <>". The current tag, e.g., jdk8u-fix-request, seems to me to assume that you already have a patch.

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

    I'll start applying the jdk8u-fix-request labels. Thanks for doing that on my approval request so far.
    
    Paul
    
    On 2/22/19, 6:58 AM, "jdk8u-dev on behalf of Langer, Christoph" <jdk8u-dev-bounces at openjdk.java.net on behalf of christoph.langer at sap.com> wrote:
    
        Hi Andrew,
        
        I've set the jdk8u-fix-request label (here and on all the other requests that came in today).
        
        This is the filter showing all unapproved items: https://bugs.openjdk.java.net/issues/?filter=36415
        
        So, please go and set the jdk8u-fix-yes tags as appropriate.
        
        Best regards
        Christoph
        
        
        > -----Original Message-----
        > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
        > Andrew Haley
        > Sent: Freitag, 22. Februar 2019 10:09
        > To: jdk8u-dev at openjdk.java.net
        > Subject: Re: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
        > when desktop contains shortcuts pointing to deleted files
        > 
        > On 2/21/19 6:02 PM, Hohensee, Paul wrote:
        > > Please approve this 8u backport which is part of Oracle?s recent 8u202 BPR.
        > 
        > I approve.
        > Do you want me to create the jdk8u-fix-request tags as well?
        > 
        > --
        > Andrew Haley
        > Java Platform Lead Engineer
        > Red Hat UK Ltd. <https://www.redhat.com>
        > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
        
    
    


From shade at redhat.com  Fri Feb 22 16:52:35 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 17:52:35 +0100
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <F8E24153-AA51-4B76-A39A-F00CB83D3DA0@amazon.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
 <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
 <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>
 <F8E24153-AA51-4B76-A39A-F00CB83D3DA0@amazon.com>
Message-ID: <ed8232ec-326d-0d68-168f-b785e2463d3c@redhat.com>

On 2/22/19 5:46 PM, Hohensee, Paul wrote:
> Also, it would be good to have a way to tag an issue with "I'm starting work on a backport to
> <>". The current tag, e.g., jdk8u-fix-request, seems to me to assume that you already have a
> patch.

We (some Red Hat people) have the "redhat-openjdk" tag that we use to track the issues we are taking
care of. It does not mean that somebody is working at the issue right now, though. Expanding jdk8u-*
tag space would mean we deviate from 11u and 12u processes, which would be confusing, I think.

-Aleksey


From christoph.langer at sap.com  Fri Feb 22 17:06:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Feb 2019 17:06:21 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <ed8232ec-326d-0d68-168f-b785e2463d3c@redhat.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
 <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
 <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>
 <F8E24153-AA51-4B76-A39A-F00CB83D3DA0@amazon.com>
 <ed8232ec-326d-0d68-168f-b785e2463d3c@redhat.com>
Message-ID: <fff56a492ec0472aaa5ba57bd3fda2b5@sap.com>

I usually add a comment to the issue, stating that I'm starting to work on a backport. Once I have the change ready, I change the comment to "Fix Request" which is required by the process anyway. I think that should be quite sufficient to sync the work on backports given that usually not hundreds of folks start working on an issue at the same time.

/Christoph



> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Freitag, 22. Februar 2019 17:53
> To: Hohensee, Paul <hohensee at amazon.com>; Langer, Christoph
> <christoph.langer at sap.com>; Andrew Haley <aph at redhat.com>; jdk8u-
> dev at openjdk.java.net
> Subject: Re: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
> when desktop contains shortcuts pointing to deleted files
> 
> On 2/22/19 5:46 PM, Hohensee, Paul wrote:
> > Also, it would be good to have a way to tag an issue with "I'm starting work
> on a backport to
> > <>". The current tag, e.g., jdk8u-fix-request, seems to me to assume that
> you already have a
> > patch.
> 
> We (some Red Hat people) have the "redhat-openjdk" tag that we use to
> track the issues we are taking
> care of. It does not mean that somebody is working at the issue right now,
> though. Expanding jdk8u-*
> tag space would mean we deviate from 11u and 12u processes, which would
> be confusing, I think.
> 
> -Aleksey


From shade at redhat.com  Fri Feb 22 17:09:51 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 22 Feb 2019 18:09:51 +0100
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <fff56a492ec0472aaa5ba57bd3fda2b5@sap.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
 <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
 <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>
 <F8E24153-AA51-4B76-A39A-F00CB83D3DA0@amazon.com>
 <ed8232ec-326d-0d68-168f-b785e2463d3c@redhat.com>
 <fff56a492ec0472aaa5ba57bd3fda2b5@sap.com>
Message-ID: <50b5f6f4-4d7b-c85a-4403-bbcc22cf4980@redhat.com>

On 2/22/19 6:06 PM, Langer, Christoph wrote:
> I usually add a comment to the issue, stating that I'm starting to work on a backport. Once I
> have the change ready, I change the comment to "Fix Request" which is required by the process
> anyway. I think that should be quite sufficient to sync the work on backports given that usually
> not hundreds of folks start working on an issue at the same time.

Yes, a placeholder comment that is then replaced with "Fix Request" sounds good. The only wrinkle is
that I cannot atomically put the jdkXXu-fix-request tag in "edit comment" action, but that's a
really minor thing.

-Aleksey


From hohensee at amazon.com  Fri Feb 22 18:54:26 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 18:54:26 +0000
Subject: [8u-dev] RFA (XS) 8213583: Error while opening the JFileChooser
 when desktop contains shortcuts pointing to deleted files
In-Reply-To: <50b5f6f4-4d7b-c85a-4403-bbcc22cf4980@redhat.com>
References: <AFDB4EDB-6A02-480B-9588-F3876A142AFF@amazon.com>
 <ee2c5003-8bed-0749-0b1d-12b5b19387ac@redhat.com>
 <7c26347bc1e84a7e981a10f4eafa7331@sap.com>
 <ADA68DEE-2167-452D-8876-E097192C84C0@amazon.com>
 <F8E24153-AA51-4B76-A39A-F00CB83D3DA0@amazon.com>
 <ed8232ec-326d-0d68-168f-b785e2463d3c@redhat.com>
 <fff56a492ec0472aaa5ba57bd3fda2b5@sap.com>
 <50b5f6f4-4d7b-c85a-4403-bbcc22cf4980@redhat.com>
Message-ID: <C2A63918-7384-4056-B881-F7EBFC28A18D@amazon.com>

Sounds good, I'll start following that process.

?On 2/22/19, 9:10 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    On 2/22/19 6:06 PM, Langer, Christoph wrote:
    > I usually add a comment to the issue, stating that I'm starting to work on a backport. Once I
    > have the change ready, I change the comment to "Fix Request" which is required by the process
    > anyway. I think that should be quite sufficient to sync the work on backports given that usually
    > not hundreds of folks start working on an issue at the same time.
    
    Yes, a placeholder comment that is then replaced with "Fix Request" sounds good. The only wrinkle is
    that I cannot atomically put the jdkXXu-fix-request tag in "edit comment" action, but that's a
    really minor thing.
    
    -Aleksey
    
    


From hohensee at amazon.com  Fri Feb 22 19:01:58 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 19:01:58 +0000
Subject: [8u-dev] RFA (XS): 8129822: Define "headful" jtreg keyword
Message-ID: <CC412FF3-77BD-4C55-9445-BB4D727B8068@amazon.com>

A trivial backport that?s a pre-requisite for the JDK-8207070 backport. I added the jdk8u-fix-request to the JBS issue, but am posting here in the hope of a quick response. :)

JBS: https://bugs.openjdk.java.net/browse/JDK-8129822
Webrev: http://cr.openjdk.java.net/~phh/8129822/webrev.8u.00/
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/65f38133842d
Original review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2015-June/005522.html

Patch applies cleanly.

Thanks,

Paul


From hohensee at amazon.com  Fri Feb 22 22:48:35 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 22:48:35 +0000
Subject: [8u-dev] RFA + RFR (M): 8217579:
 TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
In-Reply-To: <30efef92b58841d79c9eceb94f46b5ab@sap.com>
References: <F0D81BC8-E544-4E50-87B9-E61E86890720@amazon.com>
 <30efef92b58841d79c9eceb94f46b5ab@sap.com>
Message-ID: <D8552436-6FB8-453D-A18E-3EAB1A6C1077@amazon.com>

Thank you for your review, Christoph.

Paul

?On 2/22/19, 6:51 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi Paul,
    
    the backport change looks good to me. I've labeled JDK-8217579 with jdk8u-fix-request.
    
    Best regards
    Christoph
    
    > -----Original Message-----
    > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
    > Hohensee, Paul
    > Sent: Freitag, 22. Februar 2019 02:34
    > To: jdk8u-dev at openjdk.java.net
    > Subject: [8u-dev] RFA + RFR (M): 8217579:
    > TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
    > 
    > Please review/approve this backport to 8u that is tagged by Oracle for 8u211.
    > 
    > JBS: https://bugs.openjdk.java.net/browse/JDK-8217579
    > Webrev: http://cr.openjdk.java.net/~phh/8217579/webrev.8u.00/
    > jdk11u backport patch: http://hg.openjdk.java.net/jdk-
    > updates/jdk11u/rev/dd764f251274
    > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/ad3438957ff5
    > 
    > jdk11u backport review thread:
    > https://mail.openjdk.java.net/pipermail/security-dev/2019-
    > January/019271.html
    > Original review thread: https://mail.openjdk.java.net/pipermail/security-
    > dev/2019-January/019256.html
    > 
    > 
    > 
    > There are 3 differences between this patch and the jdk11u patch.
    > 
    > 
    > 
    > The first is that the 8u change in SSLAlgorithmDecomposer.java compares
    > against CipherSuite.C_SCSV rather than
    > CipherSuite.TLS_EMPTY_RENEGOTIATION_INFO_SCSV. C_SCSV appears to
    > be the 8u equivalent of 11u?s TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
    > 
    > 
    > 
    > The second is that the TLS_AES_128_GCM_SHA256 and
    > TLS_AES_256_GCM_SHA384 ciphers do not appear to be supported by 8u.
    > 
    > 
    > 
    > Finally, the cipher dump order in CheckCipherSuites.java is different in 8u
    > compared to 11u, though the number and names of the ciphers are the same
    > (other than the two above).
    > 
    > 
    > 
    > Thanks,
    > 
    > 
    > 
    > Paul
    > 
    > 
    
    


From hohensee at amazon.com  Fri Feb 22 23:04:09 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 22 Feb 2019 23:04:09 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
Message-ID: <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>

H, Martin.

The "jdk8u-fix-yes" tag has been attached to the JBS issue, so it's been approved and you can push your patch.

Thanks,

Paul

?On 2/21/19, 11: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 propose the backport of 8204142 [1] to jdk8u.
    
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.jdk8u/
     *
    http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.jdk8u.zip
    
    This patch is already included in mainline [2] and in jdk11u [3].
    Backport was trivial.
    
    No regressions found in "java/awt/event" test category.
    
    Can I have an approval?
    
    Thanks,
    Martin.-
    
    --
    [1] - https://bugs.openjdk.java.net/browse/JDK-8204142
    [2] - http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd
    [3] - http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f05fb1cc6882
    


From shade at redhat.com  Mon Feb 25 09:50:23 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 10:50:23 +0100
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
Message-ID: <7facdc10-0883-7f5f-c6ca-11fce52ba398@redhat.com>

Martin is not 8u committer. I will sponsor this for him.

-Aleksey

On 2/23/19 12:04 AM, Hohensee, Paul wrote:
> The "jdk8u-fix-yes" tag has been attached to the JBS issue, so it's been approved and you can push your patch.
> 
> Thanks,
> Paul
> 
> ?On 2/21/19, 11:09 AM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces@
>     http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.jdk8u/



From hohensee at amazon.com  Mon Feb 25 10:02:03 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 25 Feb 2019 10:02:03 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <7facdc10-0883-7f5f-c6ca-11fce52ba398@redhat.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <7facdc10-0883-7f5f-c6ca-11fce52ba398@redhat.com>
Message-ID: <8A058C6C-7FFE-4684-B4DF-4D4A248A55B0@amazon.com>

Thank you, Aleksey.

Paul

?On 2/25/19, 1:51 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    Martin is not 8u committer. I will sponsor this for him.
    
    -Aleksey
    
    On 2/23/19 12:04 AM, Hohensee, Paul wrote:
    > The "jdk8u-fix-yes" tag has been attached to the JBS issue, so it's been approved and you can push your patch.
    > 
    > Thanks,
    > Paul
    > 
    > ?On 2/21/19, 11:09 AM, "jdk8u-dev on behalf of Martin Balao" <jdk8u-dev-bounces@
    >     http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.jdk8u/
    
    
    


From shade at redhat.com  Mon Feb 25 11:22:44 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 12:22:44 +0100
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
Message-ID: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>

This is 8u-specific bug (build failure):
  https://bugs.openjdk.java.net/browse/JDK-8219636

Fix:

diff -r 3a37ebd8c506 src/windows/classes/sun/awt/windows/WToolkit.java
--- a/src/windows/classes/sun/awt/windows/WToolkit.java Mon Jan 21 19:04:19 2019 -0300
+++ b/src/windows/classes/sun/awt/windows/WToolkit.java Mon Feb 25 12:16:46 2019 +0100
@@ -43,10 +43,11 @@
 import javax.swing.text.JTextComponent;

 import sun.awt.AppContext;
 import sun.awt.AWTAccessor;
 import sun.awt.AWTAutoShutdown;
+import sun.awt.DisplayChangedListener;
 import sun.awt.LightweightFrame;
 import sun.awt.SunToolkit;
 import sun.misc.ThreadGroupUtils;
 import sun.awt.Win32GraphicsDevice;
 import sun.awt.Win32GraphicsEnvironment;

Testing: {Linux,Windows} x86_64 build

Separately: Paul, have you tested the backport patch builds with 8u on Windows?

Let me propose/reiterate the ground rule for requesters: before doing Fix Request, you need to
actually apply the patch, test it, make sure it works, and then Fix Request it, mentioning the
testing you have done and changes you needed to make it work. If the patch touches the OS you don't
have access to, _do not_ take the backport in the works.

Maintainers have to cross-check that testing is adequate for the backport being proposed. Yes, that
is more work, but that is why non-rubber-stamping reviews are needed: they routinely catch simple
mistakes.

-Aleksey


From gnu.andrew at redhat.com  Mon Feb 25 16:01:44 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 25 Feb 2019 16:01:44 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
Message-ID: <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>

On Fri, 22 Feb 2019 at 23:05, Hohensee, Paul <hohensee at amazon.com> wrote:
>
> H, Martin.
>
> The "jdk8u-fix-yes" tag has been attached to the JBS issue, so it's been approved and you can push your patch.
>
> Thanks,
>
> Paul
>

As I said previously [0], can you please wait until the fix version is
updated [1]
before pushing more fixes? This is creating a bunch of issues with a fix version
of 'openjdk8u' which will have to be fixed again later.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008634.html
[1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008666.html
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb 25 16:12:16 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 25 Feb 2019 16:12:16 +0000
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
In-Reply-To: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
Message-ID: <CABi63P5focKPjD2t1kFD3GmxQ=MDUvqtAFvvRhJVhQT3wSa0CQ@mail.gmail.com>

On Mon, 25 Feb 2019 at 11:23, Aleksey Shipilev <shade at redhat.com> wrote:
>
> This is 8u-specific bug (build failure):
>   https://bugs.openjdk.java.net/browse/JDK-8219636
>
> Fix:
>
> diff -r 3a37ebd8c506 src/windows/classes/sun/awt/windows/WToolkit.java
> --- a/src/windows/classes/sun/awt/windows/WToolkit.java Mon Jan 21 19:04:19 2019 -0300
> +++ b/src/windows/classes/sun/awt/windows/WToolkit.java Mon Feb 25 12:16:46 2019 +0100
> @@ -43,10 +43,11 @@
>  import javax.swing.text.JTextComponent;
>
>  import sun.awt.AppContext;
>  import sun.awt.AWTAccessor;
>  import sun.awt.AWTAutoShutdown;
> +import sun.awt.DisplayChangedListener;
>  import sun.awt.LightweightFrame;
>  import sun.awt.SunToolkit;
>  import sun.misc.ThreadGroupUtils;
>  import sun.awt.Win32GraphicsDevice;
>  import sun.awt.Win32GraphicsEnvironment;
>
> Testing: {Linux,Windows} x86_64 build
>
> Separately: Paul, have you tested the backport patch builds with 8u on Windows?
>
> Let me propose/reiterate the ground rule for requesters: before doing Fix Request, you need to
> actually apply the patch, test it, make sure it works, and then Fix Request it, mentioning the
> testing you have done and changes you needed to make it work. If the patch touches the OS you don't
> have access to, _do not_ take the backport in the works.
>
> Maintainers have to cross-check that testing is adequate for the backport being proposed. Yes, that
> is more work, but that is why non-rubber-stamping reviews are needed: they routinely catch simple
> mistakes.
>
> -Aleksey
>

Moreover, it should be possible to build the WIndows and Mac OS X Java
classes manually to check
they still build. That's what I do for 6 & 7 [0]

Going forward, it is also the responsibility of those who want to
continue support for these platforms
to ensure the build doesn't break on them. I don't think it's
practical to expect every contributor to
build on GNU/Linux, Windows, Mac OS X and Solaris. I certainly don't
have the means to do so.
Not backporting code that touches platform-specific code is one thing.
Not backporting anything
that might break an untested platform is another.

[0] https://bitbucket.org/gnu_andrew/bin/raw/becd42b57bec0f8f193677e5dde34575b9d5dca5/compile_windows.sh
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Mon Feb 25 16:16:26 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 17:16:26 +0100
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
Message-ID: <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>

On 2/25/19 5:01 PM, Andrew Hughes wrote:
> As I said previously [0], can you please wait until the fix version is updated [1] before pushing
> more fixes? This is creating a bunch of issues with a fix version of 'openjdk8u' which will have
> to be fixed again later.

I don't see that as the problem. The time we win testing pushed patches ahead of time is larger than
the time we need to spend fixing the versions after ops@ react. Even assuming hgupdater would not do
this for us, and we would need to do it by hand. I volunteer to rewrite Fix Versions myself, if it
comes to that :)

-Aleksey


From gnu.andrew at redhat.com  Mon Feb 25 16:30:29 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 25 Feb 2019 16:30:29 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
Message-ID: <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>

On Mon, 25 Feb 2019 at 16:16, Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/25/19 5:01 PM, Andrew Hughes wrote:
> > As I said previously [0], can you please wait until the fix version is updated [1] before pushing
> > more fixes? This is creating a bunch of issues with a fix version of 'openjdk8u' which will have
> > to be fixed again later.
>
> I don't see that as the problem. The time we win testing pushed patches ahead of time is larger than
> the time we need to spend fixing the versions after ops@ react. Even assuming hgupdater would not do
> this for us, and we would need to do it by hand. I volunteer to rewrite Fix Versions myself, if it
> comes to that :)
>
> -Aleksey
>

Ok, thanks for volunteering :P
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From aph at redhat.com  Mon Feb 25 16:32:56 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 25 Feb 2019 16:32:56 +0000
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
In-Reply-To: <CABi63P5focKPjD2t1kFD3GmxQ=MDUvqtAFvvRhJVhQT3wSa0CQ@mail.gmail.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
 <CABi63P5focKPjD2t1kFD3GmxQ=MDUvqtAFvvRhJVhQT3wSa0CQ@mail.gmail.com>
Message-ID: <136a39cc-159a-4dc0-c0dc-0c7b9a26cfb9@redhat.com>

On 2/25/19 4:12 PM, Andrew Hughes wrote:

> I don't think it's practical to expect every contributor to build on
> GNU/Linux, Windows, Mac OS X and Solaris. I certainly don't have the
> means to do so.  Not backporting code that touches platform-specific
> code is one thing.  Not backporting anything that might break an
> untested platform is another.

Yes, exactly. Until we have some sort of submission test system,
post-commit testing will have to do.

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

From shade at redhat.com  Mon Feb 25 16:46:08 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 17:46:08 +0100
Subject: [8u] RFR (S) 8211382: ISO2022JP and GB18030 NIO converter issues
Message-ID: <63b080a1-5c6a-3ecc-8afd-8157b64a567f@redhat.com>

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8211382

Original fix:
  http://hg.openjdk.java.net/jdk/jdk/rev/fb71a4bc010d

The patch does not apply cleanly to 8u and needs some manual merging. Toshio and/or Ichiron, can you
please take a look, and maybe even run the tests on current 8u?

8u webrev:
  http://cr.openjdk.java.net/~shade/8211382/webrev.8u.01/

Testing: Linux x86_64 fastdebug, sun/nio/cs jtregs (failures without product fix and new tests,
passes with the complete fix)

Thanks,
-Aleksey


From christoph.langer at sap.com  Mon Feb 25 16:46:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Feb 2019 16:46:27 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
Message-ID: <e168e0c037b843b3a108b96add4445bb@sap.com>

Hi,

> I volunteer to rewrite Fix Versions myself, if it comes to that :)
> >
> > -Aleksey
> >
> 
> Ok, thanks for volunteering :P
> --
And I had already volunteered on Friday [0] ??

But, @Paul, there are 2 things I noticed with the latest pushes:
a) your pushes, like [1] have exchanged the original author of the fix with your name. Usually, for downports, unless you don't completely rewrite the original change, the author should be kept the original author. Probably it's a bit more difficult to get this fixed with all the reshuffling that has to be done for 8u patches. But I think we should stick to that procedure. Or what do other folks say here?
And there is
b) You introduced merge patches like [2]. I think it would look cleaner if such a thing could be avoided when pushing simple changesets. Ok, after all, this one is rather cosmetical, though...

Thanks and best regards
Christoph


[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008663.html
[1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/a854158a2c94
[2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/aa5e4bedfa82 



From gnu.andrew at redhat.com  Mon Feb 25 16:55:58 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 25 Feb 2019 16:55:58 +0000
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
In-Reply-To: <136a39cc-159a-4dc0-c0dc-0c7b9a26cfb9@redhat.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
 <CABi63P5focKPjD2t1kFD3GmxQ=MDUvqtAFvvRhJVhQT3wSa0CQ@mail.gmail.com>
 <136a39cc-159a-4dc0-c0dc-0c7b9a26cfb9@redhat.com>
Message-ID: <CABi63P4f3DgNJW=aw_+4+x2RsMVjSanRW2WRUXk1N+EFRUmPgA@mail.gmail.com>

On Mon, 25 Feb 2019 at 16:33, Andrew Haley <aph at redhat.com> wrote:
>
> On 2/25/19 4:12 PM, Andrew Hughes wrote:
>
> > I don't think it's practical to expect every contributor to build on
> > GNU/Linux, Windows, Mac OS X and Solaris. I certainly don't have the
> > means to do so.  Not backporting code that touches platform-specific
> > code is one thing.  Not backporting anything that might break an
> > untested platform is another.
>
> Yes, exactly. Until we have some sort of submission test system,
> post-commit testing will have to do.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

I think it's really the only practical solution, especially when
you add in architectures and build configurations like
product/debug/zero.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Mon Feb 25 16:59:04 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 25 Feb 2019 16:59:04 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <e168e0c037b843b3a108b96add4445bb@sap.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
Message-ID: <CABi63P5L3+DwHA0p08zo3Qz=qC06J9+HnfNHJ7pTOxKog=dDqA@mail.gmail.com>

On Mon, 25 Feb 2019 at 16:47, Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi,
>
> > I volunteer to rewrite Fix Versions myself, if it comes to that :)
> > >
> > > -Aleksey
> > >
> >
> > Ok, thanks for volunteering :P
> > --
> And I had already volunteered on Friday [0]
>

Ah, thanks :) Sorry, still catching up on e-mails.

> But, @Paul, there are 2 things I noticed with the latest pushes:
> a) your pushes, like [1] have exchanged the original author of the fix with your name. Usually, for downports, unless you don't completely rewrite the original change, the author should be kept the original author. Probably it's a bit more difficult to get this fixed with all the reshuffling that has to be done for 8u patches. But I think we should stick to that procedure. Or what do other folks say here?

I agree. That's the way I've always done backports in 6 & 7.
It's a simple matter of hg commit -u <USER>.

> And there is
> b) You introduced merge patches like [2]. I think it would look cleaner if such a thing could be avoided when pushing simple changesets. Ok, after all, this one is rather cosmetical, though...

I'm in two minds about this. If there's a delay between request and
approval, it may be better to separate the original tested push and
the merge with the current state, so the original testing isn't lost.
Best to avoid it if possible though.

>
> Thanks and best regards
> Christoph
>
>
> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008663.html
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/a854158a2c94
> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/aa5e4bedfa82
>
>


-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Mon Feb 25 17:05:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 18:05:37 +0100
Subject: 8u processes discussions
Message-ID: <26ab374b-ed7a-80b5-b549-53afda0409ab@redhat.com>

Hi,

Can we, for archival and sanity reasons, do the process discussions and follow ups in separate
threads, and _not_ in RFR/RFA threads that better to be focused discussing the particular issues
mentioned in _that thread_ subject?

The list is busy as it is, let's not make it worse by hijacking RFR threads for non-RFR discussions.

Thanks,
-Aleksey


From shade at redhat.com  Mon Feb 25 17:34:18 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 18:34:18 +0100
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
In-Reply-To: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
Message-ID: <70dcfc1d-a156-8021-9d10-173960246d73@redhat.com>

On 2/25/19 12:22 PM, Aleksey Shipilev wrote:
> This is 8u-specific bug (build failure):
>   https://bugs.openjdk.java.net/browse/JDK-8219636
> 
> Fix:
> 
> diff -r 3a37ebd8c506 src/windows/classes/sun/awt/windows/WToolkit.java
> --- a/src/windows/classes/sun/awt/windows/WToolkit.java Mon Jan 21 19:04:19 2019 -0300
> +++ b/src/windows/classes/sun/awt/windows/WToolkit.java Mon Feb 25 12:16:46 2019 +0100
> @@ -43,10 +43,11 @@
>  import javax.swing.text.JTextComponent;
> 
>  import sun.awt.AppContext;
>  import sun.awt.AWTAccessor;
>  import sun.awt.AWTAutoShutdown;
> +import sun.awt.DisplayChangedListener;
>  import sun.awt.LightweightFrame;
>  import sun.awt.SunToolkit;
>  import sun.misc.ThreadGroupUtils;
>  import sun.awt.Win32GraphicsDevice;
>  import sun.awt.Win32GraphicsEnvironment;
> 
> Testing: {Linux,Windows} x86_64 build

Still asking for 8u Reviewer ack, because it is a new patch, not a backport (that would have been
reviewed before).

Thanks,
-Aleksey


From zgu at redhat.com  Mon Feb 25 18:10:52 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Mon, 25 Feb 2019 13:10:52 -0500
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070
 8u backport
In-Reply-To: <70dcfc1d-a156-8021-9d10-173960246d73@redhat.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
 <70dcfc1d-a156-8021-9d10-173960246d73@redhat.com>
Message-ID: <1551118252.18805.23.camel@redhat.com>

Good to me.

-Zhengyu

On Mon, 2019-02-25 at 18:34 +0100, Aleksey Shipilev wrote:
> On 2/25/19 12:22 PM, Aleksey Shipilev wrote:
> > This is 8u-specific bug (build failure):
> >   https://bugs.openjdk.java.net/browse/JDK-8219636
> > 
> > Fix:
> > 
> > diff -r 3a37ebd8c506
> > src/windows/classes/sun/awt/windows/WToolkit.java
> > --- a/src/windows/classes/sun/awt/windows/WToolkit.java Mon Jan 21
> > 19:04:19 2019 -0300
> > +++ b/src/windows/classes/sun/awt/windows/WToolkit.java Mon Feb 25
> > 12:16:46 2019 +0100
> > @@ -43,10 +43,11 @@
> >  import javax.swing.text.JTextComponent;
> > 
> >  import sun.awt.AppContext;
> >  import sun.awt.AWTAccessor;
> >  import sun.awt.AWTAutoShutdown;
> > +import sun.awt.DisplayChangedListener;
> >  import sun.awt.LightweightFrame;
> >  import sun.awt.SunToolkit;
> >  import sun.misc.ThreadGroupUtils;
> >  import sun.awt.Win32GraphicsDevice;
> >  import sun.awt.Win32GraphicsEnvironment;
> > 
> > Testing: {Linux,Windows} x86_64 build
> 
> Still asking for 8u Reviewer ack, because it is a new patch, not a
> backport (that would have been
> reviewed before).
> 
> Thanks,
> -Aleksey
> 

From shade at redhat.com  Mon Feb 25 18:20:55 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 25 Feb 2019 19:20:55 +0100
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
In-Reply-To: <1551118252.18805.23.camel@redhat.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
 <70dcfc1d-a156-8021-9d10-173960246d73@redhat.com>
 <1551118252.18805.23.camel@redhat.com>
Message-ID: <62d6b8be-d1bf-e89b-321a-92013035e2f9@redhat.com>

Thank you, recorded.

Anyone else wants in?

-Aleksey

On 2/25/19 7:10 PM, zgu at redhat.com wrote:
> Good to me.
> 
> -Zhengyu
> 
> On Mon, 2019-02-25 at 18:34 +0100, Aleksey Shipilev wrote:
>> On 2/25/19 12:22 PM, Aleksey Shipilev wrote:
>>> This is 8u-specific bug (build failure): https://bugs.openjdk.java.net/browse/JDK-8219636
>>> 
>>> Fix:
>>> 
>>> diff -r 3a37ebd8c506 src/windows/classes/sun/awt/windows/WToolkit.java ---
>>> a/src/windows/classes/sun/awt/windows/WToolkit.java Mon Jan 21 19:04:19 2019 -0300 +++
>>> b/src/windows/classes/sun/awt/windows/WToolkit.java Mon Feb 25 12:16:46 2019 +0100 @@ -43,10
>>> +43,11 @@ import javax.swing.text.JTextComponent;
>>> 
>>> import sun.awt.AppContext; import sun.awt.AWTAccessor; import sun.awt.AWTAutoShutdown; 
>>> +import sun.awt.DisplayChangedListener; import sun.awt.LightweightFrame; import
>>> sun.awt.SunToolkit; import sun.misc.ThreadGroupUtils; import sun.awt.Win32GraphicsDevice; 
>>> import sun.awt.Win32GraphicsEnvironment;
>>> 
>>> Testing: {Linux,Windows} x86_64 build
>> 
>> Still asking for 8u Reviewer ack, because it is a new patch, not a backport (that would have
>> been reviewed before).
>> 
>> Thanks, -Aleksey
>> 



From aph at redhat.com  Mon Feb 25 18:39:16 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 25 Feb 2019 18:39:16 +0000
Subject: RFD: Draft guidelines for working on jdk8u
Message-ID: <9250f7a4-8bc7-94e7-ad25-6808070d7d38@redhat.com>

[ Take three. Please let this be the last one. ]

OpenJDK 8 is a long-term stable release of OpenJDK. Our primary goal
is to maintain it, fixing significant bugs and especially security
problems as we go along. The "first, do no harm" principle applies: we
must not break things.

In general we'll use the process in
https://openjdk.java.net/projects/jdk-updates/approval.html.

We do not yet have much experience with our test systems, so for the
first couple of quarters we should be fairly cautious. Later on we can
be more adventurous, but for now it's mostly "bug fixes only".

All fixes that significantly improve stability, security or
performance and do not change behavioural compatibility [1] will be
considered for jdk8u. To use the language of the JDK 6 project, by
default such fixes are assumed to be applicable to jdk8u, especially
if having "soaked" in later JDK releases for a time without incident.

By "significant" I mean any bug that affects runtime behaviour in a
way that either produces incorrect results, poor performance, or
crashes the VM, especially TCK failures. Failures that are due solely
to bizarre or unreasonable combinations of -XX: command-line
parameters probably don't reach the bar of significance, and fixing
them will carry a non-zero risk of breaking something, so we should
err on the size of caution.

Build failures on all platforms, including 32-bit ones, are assumed to
be applicable. Also, there is a good deal of C++ code with Undefined
Behaviour in HotSpot, and such bugs tend to cause failures with more
recent C++ compilers. While all UB fixes may be applied to jdk8u, they
should be submitted to the current jdk development tree first.

Occasionally we might have to make changes which raise compatibility
issues. We will liase with the Compatibility & Specification Review
(CSR) Group.

We have two active trees, hg.openjdk.java.net/jdk8u/jdk8u/ and
hg.openjdk.java.net/jdk8u/jdk8u-dev/. jdk8u-dev is always open to all
contributors, and that's where everyone should push their patches
after maintainer approval. Patches pushed to jdk8u-dev will be copied
to jdk8u at regular intervals. When the time comes for an update
release, jdk8u will be closed for testing and stabilization. From that
point onward only critical bug fixes may be applied to jdk8u, at the
discretion of the maintainers.

To request maintainer approval for a backport, tag your entry in the
bug database with "jdk8u-fix-request". A maintainer will reply by
either tagging the bug entry with "jdk8u-fix-yes" or "jdk8u-fix-no".

Once a quarter, we will snapshot the jdk8u tree and prepare a Critical
Patch Update (CPU) release. Once the snapshot has been taken the
engineers working on the CPU will work in the dark, sharing the
patches with only the OpenJDK Vulnerability Group. Any patches not
committed to jdk8u at the time of the snapshot will probably have to
wait for a later release. [ I don't propose to make any non-CPU
releases: one release a quarter should be quite enough for
jdk8u. However, if an urgent problem arises we might need to make an
intermediate release. ]

Having said all of that, there is considerable customer demand for
backports of features from later OpenJDK releases. I don't intend to
forbid such backports, but strict rules will apply. Features which
apply to ports in jdk8u must have the property that they can be
disabled altogether by the use of a command-line switch. This switch
should turn the feature into a NOP, so that it does not affect the
rest of the system in any way. Reviewers should ensure that every hunk
in such a changeset is guarded by an if (Feature_enabled) statement or
something similar. This will also allow Feature_enabled to be made a
compile-time constant, and if set to false this will allow images to
be created without the feature.

With regard to the likely feature backports, there are several
possibilities, in particular the Java Flight Recorder (JFR).  It'll
take a while to produce the JFR backport, so we should perhaps create
a tree for it now by cloning the jdk8u-dev tree. Patches should be
reviewed, but it's obviously a work in progress.

[1] https://blogs.oracle.com/darcy/kinds-of-compatibility:-source,-binary,-and-behavioral

Comments welcome.

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

From christoph.langer at sap.com  Mon Feb 25 19:06:19 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Feb 2019 19:06:19 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <CABi63P5L3+DwHA0p08zo3Qz=qC06J9+HnfNHJ7pTOxKog=dDqA@mail.gmail.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <CABi63P5L3+DwHA0p08zo3Qz=qC06J9+HnfNHJ7pTOxKog=dDqA@mail.gmail.com>
Message-ID: <00196097117e4b1f9e0473a76b1cdfca@sap.com>

> > b) You introduced merge patches like [2]. I think it would look cleaner if
> such a thing could be avoided when pushing simple changesets. Ok, after all,
> this one is rather cosmetical, though...
> 
> I'm in two minds about this. If there's a delay between request and
> approval, it may be better to separate the original tested push and
> the merge with the current state, so the original testing isn't lost.
> Best to avoid it if possible though.

I agree, there might be situation where merges appeal reasonable.
Also, maybe when you push 2 dependent changsets.
But looking at the graph of jdk8u-dev/jdk, I guess the merges could have been avoided.

/Christoph

> > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/aa5e4bedfa82

From hohensee at amazon.com  Mon Feb 25 23:06:45 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 25 Feb 2019 23:06:45 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <00196097117e4b1f9e0473a76b1cdfca@sap.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <CABi63P5L3+DwHA0p08zo3Qz=qC06J9+HnfNHJ7pTOxKog=dDqA@mail.gmail.com>
 <00196097117e4b1f9e0473a76b1cdfca@sap.com>
Message-ID: <6FEE26CD-D6B5-4CA1-AC5A-96052C7DE201@amazon.com>

My apologies for the merges. Didn't think it was an issue, but will avoid them in the future (but just pushed one before I read this: sigh).

Paul

?On 2/25/19, 11:07 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    > > b) You introduced merge patches like [2]. I think it would look cleaner if
    > such a thing could be avoided when pushing simple changesets. Ok, after all,
    > this one is rather cosmetical, though...
    > 
    > I'm in two minds about this. If there's a delay between request and
    > approval, it may be better to separate the original tested push and
    > the merge with the current state, so the original testing isn't lost.
    > Best to avoid it if possible though.
    
    I agree, there might be situation where merges appeal reasonable.
    Also, maybe when you push 2 dependent changsets.
    But looking at the graph of jdk8u-dev/jdk, I guess the merges could have been avoided.
    
    /Christoph
    
    > > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/aa5e4bedfa82
    


From hohensee at amazon.com  Mon Feb 25 23:07:49 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 25 Feb 2019 23:07:49 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <e168e0c037b843b3a108b96add4445bb@sap.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
Message-ID: <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>

How does one get the original author's name into the backport? Is there a way to override 'hg push'?

Thanks,

Paul

?On 2/25/19, 8:47 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi,
    
    > I volunteer to rewrite Fix Versions myself, if it comes to that :)
    > >
    > > -Aleksey
    > >
    > 
    > Ok, thanks for volunteering :P
    > --
    And I had already volunteered on Friday [0] ??
    
    But, @Paul, there are 2 things I noticed with the latest pushes:
    a) your pushes, like [1] have exchanged the original author of the fix with your name. Usually, for downports, unless you don't completely rewrite the original change, the author should be kept the original author. Probably it's a bit more difficult to get this fixed with all the reshuffling that has to be done for 8u patches. But I think we should stick to that procedure. Or what do other folks say here?
    And there is
    b) You introduced merge patches like [2]. I think it would look cleaner if such a thing could be avoided when pushing simple changesets. Ok, after all, this one is rather cosmetical, though...
    
    Thanks and best regards
    Christoph
    
    
    [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008663.html
    [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/a854158a2c94
    [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/aa5e4bedfa82 
    
    
    


From hohensee at amazon.com  Mon Feb 25 23:09:14 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 25 Feb 2019 23:09:14 +0000
Subject: [8u] RFR (XS) 8219636: Windows build failure after JDK-8207070 8u
 backport
In-Reply-To: <62d6b8be-d1bf-e89b-321a-92013035e2f9@redhat.com>
References: <43c31dd4-abdd-8637-90f7-9bdad09e25e8@redhat.com>
 <70dcfc1d-a156-8021-9d10-173960246d73@redhat.com>
 <1551118252.18805.23.camel@redhat.com>
 <62d6b8be-d1bf-e89b-321a-92013035e2f9@redhat.com>
Message-ID: <08996BCA-565F-4024-90B4-230AD1361832@amazon.com>

My apologies again: doing rather too much of that :(. We'd built it on Windows, but a typo got through.

Paul

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

    Thank you, recorded.
    
    Anyone else wants in?
    
    -Aleksey
    
    On 2/25/19 7:10 PM, zgu at redhat.com wrote:
    > Good to me.
    > 
    > -Zhengyu
    > 
    > On Mon, 2019-02-25 at 18:34 +0100, Aleksey Shipilev wrote:
    >> On 2/25/19 12:22 PM, Aleksey Shipilev wrote:
    >>> This is 8u-specific bug (build failure): https://bugs.openjdk.java.net/browse/JDK-8219636
    >>> 
    >>> Fix:
    >>> 
    >>> diff -r 3a37ebd8c506 src/windows/classes/sun/awt/windows/WToolkit.java ---
    >>> a/src/windows/classes/sun/awt/windows/WToolkit.java Mon Jan 21 19:04:19 2019 -0300 +++
    >>> b/src/windows/classes/sun/awt/windows/WToolkit.java Mon Feb 25 12:16:46 2019 +0100 @@ -43,10
    >>> +43,11 @@ import javax.swing.text.JTextComponent;
    >>> 
    >>> import sun.awt.AppContext; import sun.awt.AWTAccessor; import sun.awt.AWTAutoShutdown; 
    >>> +import sun.awt.DisplayChangedListener; import sun.awt.LightweightFrame; import
    >>> sun.awt.SunToolkit; import sun.misc.ThreadGroupUtils; import sun.awt.Win32GraphicsDevice; 
    >>> import sun.awt.Win32GraphicsEnvironment;
    >>> 
    >>> Testing: {Linux,Windows} x86_64 build
    >> 
    >> Still asking for 8u Reviewer ack, because it is a new patch, not a backport (that would have
    >> been reviewed before).
    >> 
    >> Thanks, -Aleksey
    >> 
    
    
    


From shade at redhat.com  Mon Feb 25 23:53:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 00:53:22 +0100
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
Message-ID: <39113bdc-2417-72d9-5d80-90f341be99c0@redhat.com>

On 2/26/19 12:07 AM, Hohensee, Paul wrote:
> How does one get the original author's name into the backport? Is there a way to override 'hg push'?

I import original patches to mq, that allows me to pick up all metadata at once, including author,
Reviewed-by: lines, etc. It can be modified until the patch is finalized. Something like:

 $ wget http://hg.openjdk.java.net/jdk/jdk/raw-rev/c8071863df80
 $ hg qimport c8071863df80
 $ hg qpush
 <aaaaaah, so many conflicts, resolve>
 $ hg qrefresh
 $ hg qfinish -a

Additionally, this allows to temporarily stack the changeset that cannot be pushed, if it requires
merge:

 $ hg qimport -r "last(all(), 1)"  // no more outstanding pushes!
 $ hg qpop
 $ hg pull -u
 $ hg qpush
 $ hg qfinish -a // et voila, no merge required

-Aleksey



From hohensee at amazon.com  Tue Feb 26 02:49:24 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Feb 2019 02:49:24 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <39113bdc-2417-72d9-5d80-90f341be99c0@redhat.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
 <39113bdc-2417-72d9-5d80-90f341be99c0@redhat.com>
Message-ID: <56B31A97-2355-4BA4-B244-2B9A0B275B63@amazon.com>

Thanks for the info. Not sure the author convention is being followed by Oracle now though, see https://bugs.openjdk.java.net/browse/JDK-8027434 and https://bugs.openjdk.java.net/browse/JDK-8207070 for examples where it's not. Shall I assign the backport issues I pushed to the original authors?

Paul

?On 2/25/19, 3:55 PM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    On 2/26/19 12:07 AM, Hohensee, Paul wrote:
    > How does one get the original author's name into the backport? Is there a way to override 'hg push'?
    
    I import original patches to mq, that allows me to pick up all metadata at once, including author,
    Reviewed-by: lines, etc. It can be modified until the patch is finalized. Something like:
    
     $ wget http://hg.openjdk.java.net/jdk/jdk/raw-rev/c8071863df80
     $ hg qimport c8071863df80
     $ hg qpush
     <aaaaaah, so many conflicts, resolve>
     $ hg qrefresh
     $ hg qfinish -a
    
    Additionally, this allows to temporarily stack the changeset that cannot be pushed, if it requires
    merge:
    
     $ hg qimport -r "last(all(), 1)"  // no more outstanding pushes!
     $ hg qpop
     $ hg pull -u
     $ hg qpush
     $ hg qfinish -a // et voila, no merge required
    
    -Aleksey
    
    
    


From TOSHIONA at jp.ibm.com  Tue Feb 26 04:56:22 2019
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 26 Feb 2019 13:56:22 +0900
Subject: [8u] RFR (S) 8211382: ISO2022JP and GB18030 NIO converter issues
In-Reply-To: <63b080a1-5c6a-3ecc-8afd-8157b64a567f@redhat.com>
References: <63b080a1-5c6a-3ecc-8afd-8157b64a567f@redhat.com>
Message-ID: <OFB3A9DEFF.7BC1F97D-ON002583AD.001B007F-492583AD.001B224A@notes.na.collabserv.com>

Hi Aleksey,

Yes, I verified and agreed the 8u webrev as an requester (not reviewer).

Thanks,
Toshio Nakamura

Aleksey Shipilev <shade at redhat.com> wrote on 2019/02/26 01:46:08:

> From: Aleksey Shipilev <shade at redhat.com>
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Cc: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>, Ichiroh Takiguchi
> <takiguc at linux.vnet.ibm.com>
> Date: 2019/02/26 01:46
> Subject: [8u] RFR (S) 8211382: ISO2022JP and GB18030 NIO converter issues
>
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8211382
>
> Original fix:
>   http://hg.openjdk.java.net/jdk/jdk/rev/fb71a4bc010d
>
> The patch does not apply cleanly to 8u and needs some manual
> merging. Toshio and/or Ichiron, can you
> please take a look, and maybe even run the tests on current 8u?
>
> 8u webrev:
>   http://cr.openjdk.java.net/~shade/8211382/webrev.8u.01/
>
> Testing: Linux x86_64 fastdebug, sun/nio/cs jtregs (failures without
> product fix and new tests,
> passes with the complete fix)
>
> Thanks,
> -Aleksey
>
> [attachment "signature.asc" deleted by Toshio 5 Nakamura/Japan/IBM]

From andrey at azul.com  Tue Feb 26 09:12:09 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 26 Feb 2019 09:12:09 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
Message-ID: <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>

Hi Guangyu,

So ultimately there are the following things missing in Azul code which are present in Alibaba one:
- thread sampling
- G1 heap summary and region types
- biased locking events
- -XX:+/-EnableJFR run time flag

I'll proceed with integration of thread sampling functionality into Azul's baseline. Will update the webrev once finished. We are carrying analysis of what following JFR-related code changes to bring from jdk12+ (currently have identified ~80 candidate patches) so we think that having code laid out in jdk11-ish way will simplify that process. Hence choosing Azul's code as a baseline as opposed to other way around. 

Thanks,
Andrey

On 20 Feb 2019, at 14:35, Andrey Petushkov <andrey at azul.com> wrote:
> 
> Dear Guangyu,
> 
> On 20 Feb 2019, at 15:44, guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>> wrote:
> 
> Hi Andrey,
> 
> I'm just coming back from the Spring Festival holiday and sorry for the late response. I am very happy that Azul has ported jfr to multiple platforms. Are there any further updates to your difference analysis?
> Not yet, sorry. Was distracted to do some other stuff
> I quickly studied the patch and found some differences:
> 
> - Your patch does not support thread sampling, and it looks like some code in jfrThreadSampler.cpp is commented out.
> Absolutely. It's great you have implemented that in absence of threadSMR
> - Your patch does not support the gc event on g1, Alibaba's patch supports g1 events, which you have already mentioned.
> Not exactly. Azul code supports GC events for G1 however we miss some important information, like region types, heap occupancy etc
> - Alibaba divides the test into two parts. The test relies on the hotspot whitebox being moved to the hotspot directory, while Azul saves all tests under jdk dircetory and adds the hotspot whitebox to the test library.
> Right. I'm not sure what's the best way
> 
> I will spend more time comparing these two patches. Anyway, it seems that the jfr patch will enter jdk8u faster than we originally expected.
> Well, at least some jdk8u incubator repos ;)
> 
> Regards,
> Andrey
> 
> Thanks,
> Guangyu
> 
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>
> Sent At:2019 Feb. 16 (Sat.) 00:41
> Recipient:Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>; Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>; jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net>>; yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>; kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>; denghui.ddh <denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> 
> [fixed subject, removed jfr-dev maillist]
> 
> In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284
> 
> Regards,
> Andrey
> 
> On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>> wrote:
> 
> 
> 
> On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:
> On 2/11/19 1:01 PM, Mario Torre wrote:
>> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>> wrote:
>>> 
>>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>>>> Andrew, do you think we can have a repository created for this
>>>> purpose?
>>> 
>>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>>> discussed. Perhaps that would fit the bill for this backport in a more
>>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>> 
>> My understanding was that this was dismissed, but I'm happy either way.
>> 
>> If we have an agreement on how to call the repository then Andrew will
>> create one right away.
>> 
>> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
>> sure if we will want to coordinate this effort on a separate mailing
>> list though, what do you think?
> 
> I think it would be cleaner to have multiple repositories: having to deal
> with branches make things pointlessly difficult. Maybe we should give this
> some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
> of this is that a casual visitor is less likely to be confused.
> 
> I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.
> 
> Cheers,
> Mario
> 
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com<https://www.redhat.com/>>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 
> 
> 


From xxinliu at amazon.com  Mon Feb 25 21:43:10 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Mon, 25 Feb 2019 21:43:10 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
Message-ID: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>

Hi, jdk8u maintainers,

We backport two patches about distrust policy to jdk8u-dev.  It will distrust all certificates from Symantec except for 2 from Apple?s.
They are straight-forward, but we do minor changes for java8.

JDK-8207258<https://bugs.openjdk.java.net/browse/JDK-8207258>: Distrust TLS server certificates anchored by Symantec Root CAs
http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/

JDK-8216280<https://bugs.openjdk.java.net/browse/JDK-8216280%5d>: Allow later Symantec Policy distrust date for two Apple SubCAs
http://cr.openjdk.java.net/~phh/8216280/webrev.8u.00/

We verify Jtreg and JCK8b internally. Could you mailist review it?

Thanks,
--lx



From aph at redhat.com  Tue Feb 26 09:44:53 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 09:44:53 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
Message-ID: <c7c08ad2-7a65-739a-75d4-fa7496a1b611@redhat.com>

On 2/25/19 9:43 PM, Liu, Xin wrote:

> We backport two patches about distrust policy to jdk8u-dev.  It will distrust all certificates from Symantec except for 2 from Apple?s.
> They are straight-forward, but we do minor changes for java8.
> 
> JDK-8207258<https://bugs.openjdk.java.net/browse/JDK-8207258>: Distrust TLS server certificates anchored by Symantec Root CAs
> http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/
> 
> JDK-8216280<https://bugs.openjdk.java.net/browse/JDK-8216280%5d>: Allow later Symantec Policy distrust date for two Apple SubCAs
> http://cr.openjdk.java.net/~phh/8216280/webrev.8u.00/
> 
> We verify Jtreg and JCK8b internally. Could you mailist review it?

These are already marked with CPU19 04-critical-approved and redhat-openjdk.

In other words: we're on it.

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

From shade at redhat.com  Tue Feb 26 10:32:41 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 11:32:41 +0100
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <c7c08ad2-7a65-739a-75d4-fa7496a1b611@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <c7c08ad2-7a65-739a-75d4-fa7496a1b611@redhat.com>
Message-ID: <9fa5b4f1-e0cc-197b-0285-2442a2bb326b@redhat.com>

On 2/26/19 10:44 AM, Andrew Haley wrote:
> On 2/25/19 9:43 PM, Liu, Xin wrote:
>> We backport two patches about distrust policy to jdk8u-dev.  It will distrust all certificates from Symantec except for 2 from Apple?s.
>> They are straight-forward, but we do minor changes for java8.
>>
>> JDK-8207258<https://bugs.openjdk.java.net/browse/JDK-8207258>: Distrust TLS server certificates anchored by Symantec Root CAs
>> http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/
>>
>> JDK-8216280<https://bugs.openjdk.java.net/browse/JDK-8216280%5d>: Allow later Symantec Policy distrust date for two Apple SubCAs
>> http://cr.openjdk.java.net/~phh/8216280/webrev.8u.00/
>>
>> We verify Jtreg and JCK8b internally. Could you mailist review it?
> 
> These are already marked with CPU19 04-critical-approved and redhat-openjdk.
> 
> In other words: we're on it.

I have already handed over these to Liu. Liu provides the backport for these.

-Aleksey


From christoph.langer at sap.com  Tue Feb 26 10:52:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 10:52:23 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <56B31A97-2355-4BA4-B244-2B9A0B275B63@amazon.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
 <39113bdc-2417-72d9-5d80-90f341be99c0@redhat.com>
 <56B31A97-2355-4BA4-B244-2B9A0B275B63@amazon.com>
Message-ID: <e396558c68dc46b580210c748c8ab345@sap.com>

Hi Paul,

> Thanks for the info. Not sure the author convention is being followed by
> Oracle now though, see https://bugs.openjdk.java.net/browse/JDK-8027434
> and https://bugs.openjdk.java.net/browse/JDK-8207070 for examples
> where it's not. Shall I assign the backport issues I pushed to the original
> authors?

Hm, for these bugs, the author field looks fine in the Oracle downports, at least in the public ones that we can see. JDK-8027434 is authored by mchinnathamb and JDK-8027434 by serb. The users that submitted the backports are different though, which is fine. Maybe you're confusing these?

/Christoph


From guangyu.zhu at aliyun.com  Tue Feb 26 11:01:04 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Tue, 26 Feb 2019 19:01:04 +0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsIGZvciBiYWNrLXBvcnRpbmcgSkZSIHRvIE9wZW5KREs4dQ==?=
In-Reply-To: <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>,
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
Message-ID: <7307372e-d539-4941-a91a-37809c8256dd.guangyu.zhu@aliyun.com>

Hi Andrey,

I can understand that you chose Azul's code as the baseline. Please let me know if you need help while merge the listed functions.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Feb. 26 (Tue.) 17:12
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net>; yumin qi <yumin.qi at gmail.com>; kingsum.chow <kingsum.chow at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

Hi Guangyu,

So ultimately there are the following things missing in Azul code which are present in Alibaba one:
- thread sampling
- G1 heap summary and region types
- biased locking events
- -XX:+/-EnableJFR run time flag

I'll proceed with integration of thread sampling functionality into Azul's baseline. Will update the webrev once finished. We are carrying analysis of what following JFR-related code changes to bring from jdk12+ (currently have identified ~80 candidate patches) so we think that having code laid out in jdk11-ish way will simplify that process. Hence choosing Azul's code as a baseline as opposed to other way around. 

Thanks,
Andrey

On 20 Feb 2019, at 14:35, Andrey Petushkov <andrey at azul.com> wrote:
> 
> Dear Guangyu,
> 
> On 20 Feb 2019, at 15:44, guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>> wrote:
> 
> Hi Andrey,
> 
> I'm just coming back from the Spring Festival holiday and sorry for the late response. I am very happy that Azul has ported jfr to multiple platforms. Are there any further updates to your difference analysis?
> Not yet, sorry. Was distracted to do some other stuff
> I quickly studied the patch and found some differences:
> 
> - Your patch does not support thread sampling, and it looks like some code in jfrThreadSampler.cpp is commented out.
> Absolutely. It's great you have implemented that in absence of threadSMR
> - Your patch does not support the gc event on g1, Alibaba's patch supports g1 events, which you have already mentioned.
> Not exactly. Azul code supports GC events for G1 however we miss some important information, like region types, heap occupancy etc
> - Alibaba divides the test into two parts. The test relies on the hotspot whitebox being moved to the hotspot directory, while Azul saves all tests under jdk dircetory and adds the hotspot whitebox to the test library.
> Right. I'm not sure what's the best way
> 
> I will spend more time comparing these two patches. Anyway, it seems that the jfr patch will enter jdk8u faster than we originally expected.
> Well, at least some jdk8u incubator repos ;)
> 
> Regards,
> Andrey
> 
> Thanks,
> Guangyu
> 
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>
> Sent At:2019 Feb. 16 (Sat.) 00:41
> Recipient:Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>; Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>; jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net>>; yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>; kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>; denghui.ddh <denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> 
> [fixed subject, removed jfr-dev maillist]
> 
> In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284
> 
> Regards,
> Andrey
> 
> On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>> wrote:
> 
> 
> 
> On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:
> On 2/11/19 1:01 PM, Mario Torre wrote:
>> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>> wrote:
>>> 
>>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>>>> Andrew, do you think we can have a repository created for this
>>>> purpose?
>>> 
>>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>>> discussed. Perhaps that would fit the bill for this backport in a more
>>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>> 
>> My understanding was that this was dismissed, but I'm happy either way.
>> 
>> If we have an agreement on how to call the repository then Andrew will
>> create one right away.
>> 
>> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
>> sure if we will want to coordinate this effort on a separate mailing
>> list though, what do you think?
> 
> I think it would be cleaner to have multiple repositories: having to deal
> with branches make things pointlessly difficult. Maybe we should give this
> some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
> of this is that a casual visitor is less likely to be confused.
> 
> I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.
> 
> Cheers,
> Mario
> 
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com<https://www.redhat.com/>>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 
> 
> 



From neugens at redhat.com  Tue Feb 26 11:13:28 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 26 Feb 2019 12:13:28 +0100
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
Message-ID: <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>

> We are carrying analysis of what following JFR-related code changes to
bring from jdk12+

I don't think we should do that for every new baseline, I think integrating
the platform changes from 11 to 8 is already a really big step, without
endlessly backporting features from every other release down the line.

I also would like to proceed with the current patches before adding more to
the table as this is already a quite difficult patch to properly review and
test without thinking about changes in further releases.

Cheers,
Mario


On Tue, Feb 26, 2019 at 10:12 AM Andrey Petushkov <andrey at azul.com> wrote:

> Hi Guangyu,
>
> So ultimately there are the following things missing in Azul code which
> are present in Alibaba one:
> - thread sampling
> - G1 heap summary and region types
> - biased locking events
> - -XX:+/-EnableJFR run time flag
>
> I'll proceed with integration of thread sampling functionality into Azul's
> baseline. Will update the webrev once finished. We are carrying analysis of
> what following JFR-related code changes to bring from jdk12+ (currently
> have identified ~80 candidate patches) so we think that having code laid
> out in jdk11-ish way will simplify that process. Hence choosing Azul's code
> as a baseline as opposed to other way around.
>
> Thanks,
> Andrey
>
> On 20 Feb 2019, at 14:35, Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Dear Guangyu,
> >
> > On 20 Feb 2019, at 15:44, guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
> guangyu.zhu at aliyun.com>> wrote:
> >
> > Hi Andrey,
> >
> > I'm just coming back from the Spring Festival holiday and sorry for the
> late response. I am very happy that Azul has ported jfr to multiple
> platforms. Are there any further updates to your difference analysis?
> > Not yet, sorry. Was distracted to do some other stuff
> > I quickly studied the patch and found some differences:
> >
> > - Your patch does not support thread sampling, and it looks like some
> code in jfrThreadSampler.cpp is commented out.
> > Absolutely. It's great you have implemented that in absence of threadSMR
> > - Your patch does not support the gc event on g1, Alibaba's patch
> supports g1 events, which you have already mentioned.
> > Not exactly. Azul code supports GC events for G1 however we miss some
> important information, like region types, heap occupancy etc
> > - Alibaba divides the test into two parts. The test relies on the
> hotspot whitebox being moved to the hotspot directory, while Azul saves all
> tests under jdk dircetory and adds the hotspot whitebox to the test library.
> > Right. I'm not sure what's the best way
> >
> > I will spend more time comparing these two patches. Anyway, it seems
> that the jfr patch will enter jdk8u faster than we originally expected.
> > Well, at least some jdk8u incubator repos ;)
> >
> > Regards,
> > Andrey
> >
> > Thanks,
> > Guangyu
> >
> > ------------------------------------------------------------------
> > Sender:Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>
> > Sent At:2019 Feb. 16 (Sat.) 00:41
> > Recipient:Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>;
> Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Severin Gehwolf <
> sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>; Mario Torre <
> neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>;
> jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net<mailto:
> jdk8u-dev-bounces at openjdk.java.net>>; yumin qi <yumin.qi at gmail.com<mailto:
> yumin.qi at gmail.com>>; kingsum.chow <kingsum.chow at gmail.com<mailto:
> kingsum.chow at gmail.com>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
> jdk8u-dev at openjdk.java.net>>; denghui.ddh <denghui.ddh at antfin.com<mailto:
> denghui.ddh at antfin.com>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
> guangyu.zhu at aliyun.com>>
> > Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> >
> > [fixed subject, removed jfr-dev maillist]
> >
> > In the meanwhile I?ve updated webrev with a backports of JDK-8207392
> (JFR profiling for PPC) and shared part of (necessary for the latter)
> JDK-8159284
> >
> > Regards,
> > Andrey
> >
> > On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:
> neugens at redhat.com>> wrote:
> >
> >
> >
> > On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:
> aph at redhat.com>> wrote:
> > On 2/11/19 1:01 PM, Mario Torre wrote:
> >> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com
> <mailto:sgehwolf at redhat.com>> wrote:
> >>>
> >>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
> >>>> Andrew, do you think we can have a repository created for this
> >>>> purpose?
> >>>
> >>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
> >>> discussed. Perhaps that would fit the bill for this backport in a more
> >>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
> >>
> >> My understanding was that this was dismissed, but I'm happy either way.
> >>
> >> If we have an agreement on how to call the repository then Andrew will
> >> create one right away.
> >>
> >> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
> >> sure if we will want to coordinate this effort on a separate mailing
> >> list though, what do you think?
> >
> > I think it would be cleaner to have multiple repositories: having to deal
> > with branches make things pointlessly difficult. Maybe we should give
> this
> > some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
> > of this is that a casual visitor is less likely to be confused.
> >
> > I like this proposal, it is future proof as it would make it clear also
> if we ever had to add more of such repositories what they are for.
> >
> > Cheers,
> > Mario
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com<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 shade at redhat.com  Tue Feb 26 11:28:11 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 12:28:11 +0100
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
Message-ID: <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>

On 2/25/19 10:43 PM, Liu, Xin wrote:
> JDK-8207258 <https://bugs.openjdk.java.net/browse/JDK-8207258>: Distrust TLS server certificates
> anchored by Symantec Root CAs
> http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/

*) So this patch adds changes the keystore acquisition code in
test/lib/security/CheckBlacklistedCerts.java, and it is not present in original change. Why?

   44         final KeyStore ks = SecurityUtils.getCacertsKeyStore();


> JDK-8216280 <https://bugs.openjdk.java.net/browse/JDK-8216280%5d>: Allow later Symantec Policy
> distrust date for two Apple SubCAs
> 
> http://cr.openjdk.java.net/~phh/8216280/webrev.8u.00/

*) Indenting in SymantecTLSPolicy.java seems off at L193-195. Also superfluous newline at L196.

 190         if (notBeforeDate.isAfter(distrustDate)) {
 191             throw new ValidatorException
 192                     ("TLS Server certificate issued after " + distrustDate +
 193                             " and anchored by a distrusted legacy Symantec root CA: "
 194                             + anchor.getSubjectX500Principal(),
 195                             ValidatorException.T_UNTRUSTED_CERT, anchor);
 196
 197         }

Seems fine otherwise.

-Aleksey


From shade at redhat.com  Tue Feb 26 12:26:51 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 13:26:51 +0100
Subject: [8u] RFR (XS) 8028254: gc/arguments/TestMinInitialErgonomics.java
 failed with unexpected initial heap size
Message-ID: <d31aa7c6-17c6-1c61-f0d4-b5c876faeb50@redhat.com>

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8028254

Original fix:
  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6827d470020d

This fixes the false negative test failure in current 8u. The patch does not apply cleanly to 8u, it
has minor conflicts in whitebox.cpp, therefore requesting review.

8u webrev:
  http://cr.openjdk.java.net/~shade/8028254/webrev.8u.01/

Testing: jtreg hotspot/gc

Thanks,
-Aleksey


From andrey at azul.com  Tue Feb 26 13:41:47 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 26 Feb 2019 13:41:47 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
Message-ID: <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>



On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>> wrote:

> We are carrying analysis of what following JFR-related code changes to bring from jdk12+

I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed

I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take

Regards,
Andrey

Cheers,
Mario


On Tue, Feb 26, 2019 at 10:12 AM Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>> wrote:
Hi Guangyu,

So ultimately there are the following things missing in Azul code which are present in Alibaba one:
- thread sampling
- G1 heap summary and region types
- biased locking events
- -XX:+/-EnableJFR run time flag

I'll proceed with integration of thread sampling functionality into Azul's baseline. Will update the webrev once finished. We are carrying analysis of what following JFR-related code changes to bring from jdk12+ (currently have identified ~80 candidate patches) so we think that having code laid out in jdk11-ish way will simplify that process. Hence choosing Azul's code as a baseline as opposed to other way around.

Thanks,
Andrey

On 20 Feb 2019, at 14:35, Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>> wrote:
>
> Dear Guangyu,
>
> On 20 Feb 2019, at 15:44, guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com><mailto:guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>> wrote:
>
> Hi Andrey,
>
> I'm just coming back from the Spring Festival holiday and sorry for the late response. I am very happy that Azul has ported jfr to multiple platforms. Are there any further updates to your difference analysis?
> Not yet, sorry. Was distracted to do some other stuff
> I quickly studied the patch and found some differences:
>
> - Your patch does not support thread sampling, and it looks like some code in jfrThreadSampler.cpp is commented out.
> Absolutely. It's great you have implemented that in absence of threadSMR
> - Your patch does not support the gc event on g1, Alibaba's patch supports g1 events, which you have already mentioned.
> Not exactly. Azul code supports GC events for G1 however we miss some important information, like region types, heap occupancy etc
> - Alibaba divides the test into two parts. The test relies on the hotspot whitebox being moved to the hotspot directory, while Azul saves all tests under jdk dircetory and adds the hotspot whitebox to the test library.
> Right. I'm not sure what's the best way
>
> I will spend more time comparing these two patches. Anyway, it seems that the jfr patch will enter jdk8u faster than we originally expected.
> Well, at least some jdk8u incubator repos ;)
>
> Regards,
> Andrey
>
> Thanks,
> Guangyu
>
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com><mailto:andrey at azul.com<mailto:andrey at azul.com>>>
> Sent At:2019 Feb. 16 (Sat.) 00:41
> Recipient:Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com><mailto:neugens at redhat.com<mailto:neugens at redhat.com>>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com<mailto:aph at redhat.com>>>; Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com><mailto:sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>>; Mario Torre <neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com><mailto:neugens.limasoftware at gmail.com<mailto:neugens.limasoftware at gmail.com>>>; jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net><mailto:jdk8u-dev-bounces at openjdk.java.net<mailto:jdk8u-dev-bounces at openjdk.java.net>>>; yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com><mailto:yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>>; kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com><mailto:kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>>; jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net><mailto:jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>>; denghui.ddh <denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com><mailto:denghui.ddh at antfin.com<mailto:denghui.ddh at antfin.com>>>; guangyu.zhu <guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com><mailto:guangyu.zhu at aliyun.com<mailto:guangyu.zhu at aliyun.com>>>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
>
> [fixed subject, removed jfr-dev maillist]
>
> In the meanwhile I?ve updated webrev with a backports of JDK-8207392 (JFR profiling for PPC) and shared part of (necessary for the latter) JDK-8159284
>
> Regards,
> Andrey
>
> On 14 Feb 2019, at 14:20, Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com><mailto:neugens at redhat.com<mailto:neugens at redhat.com>>> wrote:
>
>
>
> On Tue, Feb 12, 2019 at 12:41 PM Andrew Haley <aph at redhat.com<mailto:aph at redhat.com><mailto:aph at redhat.com<mailto:aph at redhat.com>>> wrote:
> On 2/11/19 1:01 PM, Mario Torre wrote:
>> On Mon, Feb 11, 2019 at 12:29 PM Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com><mailto:sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>> wrote:
>>>
>>> On Fri, 2019-02-08 at 19:00 +0100, Mario Torre wrote:
>>>> Andrew, do you think we can have a repository created for this
>>>> purpose?
>>>
>>> At the OpenJDK Committers Workshop a JDK 8u sandbox repository was
>>> discussed. Perhaps that would fit the bill for this backport in a more
>>> generic way?  "jfr-8u" branch in a jdk8u-dev/sandbox forest, perhaps?
>>
>> My understanding was that this was dismissed, but I'm happy either way.
>>
>> If we have an agreement on how to call the repository then Andrew will
>> create one right away.
>>
>> Btw, I think the discussion should move to jdk8u-dev alone. I'm not
>> sure if we will want to coordinate this effort on a separate mailing
>> list though, what do you think?
>
> I think it would be cleaner to have multiple repositories: having to deal
> with branches make things pointlessly difficult. Maybe we should give this
> some structure with subdirectories, so jdk8u/incubator/jfr. The advantage
> of this is that a casual visitor is less likely to be confused.
>
> I like this proposal, it is future proof as it would make it clear also if we ever had to add more of such repositories what they are for.
>
> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com<https://www.redhat.com/><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<https://www.redhat.com/>>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From neugens at redhat.com  Tue Feb 26 13:59:27 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 26 Feb 2019 14:59:27 +0100
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
Message-ID: <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>

On Tue, Feb 26, 2019 at 2:42 PM Andrey Petushkov <andrey at azul.com> wrote:
>
>
>
> On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com> wrote:
>
> > We are carrying analysis of what following JFR-related code changes to bring from jdk12+
>
> I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
>
> We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed


Yes, watching the changes is certainly good in the optic of searching
for bug (and security) fixes, I didn't mean to stop this effort, I'm
worried about backport features (like new events and perhaps APIs) to
8 however.
>
>
> I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
>
> No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take

Yes, exactly!

I would suggest to wait for your patch with the integrated
functionality and then we can proceed with a proper review cycle and
push into the incubator repository [1].

Cheers,
Mario

[1] https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/

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

From zgu at redhat.com  Tue Feb 26 14:15:17 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Tue, 26 Feb 2019 09:15:17 -0500
Subject: [8u] RFR (XS) 8028254:
 gc/arguments/TestMinInitialErgonomics.java failed with unexpected initial
 heap size
In-Reply-To: <d31aa7c6-17c6-1c61-f0d4-b5c876faeb50@redhat.com>
References: <d31aa7c6-17c6-1c61-f0d4-b5c876faeb50@redhat.com>
Message-ID: <1551190517.18805.48.camel@redhat.com>

Looks good.

-Zhengyu

On Tue, 2019-02-26 at 13:26 +0100, Aleksey Shipilev wrote:
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8028254
> 
> Original fix:
>   http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6827d470020d
> 
> This fixes the false negative test failure in current 8u. The patch
> does not apply cleanly to 8u, it
> has minor conflicts in whitebox.cpp, therefore requesting review.
> 
> 8u webrev:
>   http://cr.openjdk.java.net/~shade/8028254/webrev.8u.01/
> 
> Testing: jtreg hotspot/gc
> 
> Thanks,
> -Aleksey
> 

From aph at redhat.com  Tue Feb 26 15:10:59 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 15:10:59 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
Message-ID: <5894f6dd-b665-f9e1-833d-904738f8c135@redhat.com>

Andrey, please fix your quoting. When you quote Mario, his messages should be
preceded by

>

on every line.

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

From andrey at azul.com  Tue Feb 26 15:49:10 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 26 Feb 2019 15:49:10 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <5894f6dd-b665-f9e1-833d-904738f8c135@redhat.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <5894f6dd-b665-f9e1-833d-904738f8c135@redhat.com>
Message-ID: <ACC64638-3D63-4369-9103-96191E5DF0A1@azul.com>

I'm apologising for that. Unfortunately it looks like this has something to do with compatibility of Mac Mail app with OpenJDK mail backend (or Mario's mail client): my replies still look fine in my Sent folder but are broken when I receive them. I'll try to use different client for this purpose

Andrey

> On 26 Feb 2019, at 16:10, Andrew Haley <aph at redhat.com> wrote:
> 
> Andrey, please fix your quoting. When you quote Mario, his messages should be
> preceded by
> 
>> 
> 
> on every line.
> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at redhat.com  Tue Feb 26 16:06:10 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 16:06:10 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
Message-ID: <f5387873-271e-c5e9-06b1-021321c92d6f@redhat.com>

On 2/26/19 1:59 PM, Mario Torre wrote:
> 
> Yes, watching the changes is certainly good in the optic of searching
> for bug (and security) fixes, I didn't mean to stop this effort, I'm
> worried about backport features (like new events and perhaps APIs) to
> 8 however.

I agree. This is potentially problematic for getting JFR accepted into
mainline.


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

From aph at redhat.com  Tue Feb 26 16:25:36 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 16:25:36 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <9fa5b4f1-e0cc-197b-0285-2442a2bb326b@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <c7c08ad2-7a65-739a-75d4-fa7496a1b611@redhat.com>
 <9fa5b4f1-e0cc-197b-0285-2442a2bb326b@redhat.com>
Message-ID: <1ef8b778-d7c4-88c0-a44c-e49f2f702a2f@redhat.com>

On 2/26/19 10:32 AM, Aleksey Shipilev wrote:
> I have already handed over these to Liu. Liu provides the backport for these.

OK, so somebody really should put in the jdk8u-fix-request, then.

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

From shade at redhat.com  Tue Feb 26 17:10:19 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 18:10:19 +0100
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <1ef8b778-d7c4-88c0-a44c-e49f2f702a2f@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <c7c08ad2-7a65-739a-75d4-fa7496a1b611@redhat.com>
 <9fa5b4f1-e0cc-197b-0285-2442a2bb326b@redhat.com>
 <1ef8b778-d7c4-88c0-a44c-e49f2f702a2f@redhat.com>
Message-ID: <ee0eb6f5-072c-ff91-1fab-bb8656cff57f@redhat.com>

On 2/26/19 5:25 PM, Andrew Haley wrote:
> On 2/26/19 10:32 AM, Aleksey Shipilev wrote:
>> I have already handed over these to Liu. Liu provides the backport for these.
> 
> OK, so somebody really should put in the jdk8u-fix-request, then.

Ah.

Liu, do it please.

-Aleksey



From gnu.andrew at redhat.com  Tue Feb 26 17:22:18 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 26 Feb 2019 17:22:18 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
Message-ID: <CABi63P7pOUkeBkjKQJkXjVd11eLKFabd2CXp7Rvr5+sA08wNnA@mail.gmail.com>

On Mon, 25 Feb 2019 at 23:07, Hohensee, Paul <hohensee at amazon.com> wrote:
>
> How does one get the original author's name into the backport? Is there a way to override 'hg push'?
>
> Thanks,
>
> Paul
>

It's part of the commit, not the push.

$ hg commit -u ${USER}
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Feb 26 17:44:57 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 26 Feb 2019 17:44:57 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
Message-ID: <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>

snip...

>
> *) Indenting in SymantecTLSPolicy.java seems off at L193-195. Also superfluous newline at L196.
>
>  190         if (notBeforeDate.isAfter(distrustDate)) {
>  191             throw new ValidatorException
>  192                     ("TLS Server certificate issued after " + distrustDate +
>  193                             " and anchored by a distrusted legacy Symantec root CA: "
>  194                             + anchor.getSubjectX500Principal(),
>  195                             ValidatorException.T_UNTRUSTED_CERT, anchor);
>  196
>  197         }
>
> Seems fine otherwise.
>
> -Aleksey
>

I presume you're all running jcheck locally? It tends to catch some of
this stuff at commit
that will otherwise fail to push.
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Tue Feb 26 18:12:21 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 19:12:21 +0100
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <054C7878-C666-4F14-8620-765643B7D456@amazon.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
 <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
 <054C7878-C666-4F14-8620-765643B7D456@amazon.com>
Message-ID: <d20774e2-d996-d716-2f4f-6c5395e5cd3e@redhat.com>

On 2/26/19 7:04 PM, Liu, Xin wrote:
> When I backport , I always wonder if I shall keep backport patch as intact as possible or piggyback tide-up code?

Keep it intact as much as possible.

Cleanups can and should follow up as the patch in dev, and then trickle down as backports, if needed.

-Aleksey



From aph at redhat.com  Tue Feb 26 18:21:50 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 18:21:50 +0000
Subject: 8u/11u repo access and Jira changes
Message-ID: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>

https://hg.openjdk.java.net/jdk8u/jdk8u is now writable by all JDK 8u
Reviewers and Committers. HOWEVER, don't commit anything to
it. Instead, commit to jdk8u-dev.

hgupdater is set to openjdk8u211 for jdk8u.

jdk-updates/jdk11u-dev now exists, and it's the commit repo for
jdk11u.

jdk8u/jdk8u-jfr-incubator/ now exists for JFR integration. As far as I
can see, dicussion is still in progress.  Right now, a bugid and
review is required. Do we want that for JFR? We could relax the
requirement while work is in progress, and commit the JFR port as a
single change later.

hgupdater is not set for jdk8u-jfr-incubator. I think that's probably
the right for the time being.

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

From xxinliu at amazon.com  Tue Feb 26 18:04:20 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Tue, 26 Feb 2019 18:04:20 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
 <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
Message-ID: <054C7878-C666-4F14-8620-765643B7D456@amazon.com>

Hi, Andrew and Aleksey, 

Thanks for catch up these. I will modify it.  I didn't know jcheck. I will set it up and put it in our CI.
 
For this change,  http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/test/lib/security/CheckBlacklistedCerts.java.udiff.html
It's because newly introduced SecurityUtils::getCacertsKeyStore() can simplify original code. Further, original code defines fis but never use it. 
When I backport , I always wonder if I shall keep backport patch as intact as possible or piggyback tide-up code?

Thanks,
--lx

?On 2/26/19, 9:45 AM, "Andrew Hughes" <gnu.andrew at redhat.com> wrote:

    snip...
    
    >
    > *) Indenting in SymantecTLSPolicy.java seems off at L193-195. Also superfluous newline at L196.
    >
    >  190         if (notBeforeDate.isAfter(distrustDate)) {
    >  191             throw new ValidatorException
    >  192                     ("TLS Server certificate issued after " + distrustDate +
    >  193                             " and anchored by a distrusted legacy Symantec root CA: "
    >  194                             + anchor.getSubjectX500Principal(),
    >  195                             ValidatorException.T_UNTRUSTED_CERT, anchor);
    >  196
    >  197         }
    >
    > Seems fine otherwise.
    >
    > -Aleksey
    >
    
    I presume you're all running jcheck locally? It tends to catch some of
    this stuff at commit
    that will otherwise fail to push.
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    Web Site: http://fuseyism.com
    Twitter: https://twitter.com/gnu_andrew_java
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    


From shade at redhat.com  Tue Feb 26 18:30:18 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 19:30:18 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
Message-ID: <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>

On 2/26/19 7:21 PM, Andrew Haley wrote:
> https://hg.openjdk.java.net/jdk8u/jdk8u is now writable by all JDK 8u
> Reviewers and Committers. HOWEVER, don't commit anything to
> it. Instead, commit to jdk8u-dev.

Wait, can't we limit the push privileges to jdk8u/jdk8u to avoid surprises? I would prefer computers
do things for us for a change. No matter how we try to follow the processes, mistakes would happen,
and we better catch them mechanically. Ditto for jdk-updates/jdk11u.

-Aleksey


From aph at redhat.com  Tue Feb 26 18:46:57 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 18:46:57 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
Message-ID: <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>

On 2/26/19 6:30 PM, Aleksey Shipilev wrote:
> On 2/26/19 7:21 PM, Andrew Haley wrote:
>> https://hg.openjdk.java.net/jdk8u/jdk8u is now writable by all JDK 8u
>> Reviewers and Committers. HOWEVER, don't commit anything to
>> it. Instead, commit to jdk8u-dev.
> 
> Wait, can't we limit the push privileges to jdk8u/jdk8u to avoid
> surprises?

We could, but...

> I would prefer computers do things for us for a change. No matter
> how we try to follow the processes, mistakes would happen, and we
> better catch them mechanically. Ditto for jdk-updates/jdk11u.

As I said in
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000446.html,

  The problem is that we've been conflating two roles in the
  "maintainer". One is someone whose role is essentially judgmental:
  they decide whether a patch is suitable for a particular
  release. The other role is integrative: they merge a patch into a
  release branch and make sure the result works by testing it. These
  two roles are not the same thing, and require different skills.

  We are likely to encounter scaling problems as we work on the
  updates projects and we will do ourselves no favours by creating
  bottlenecks to efficient parallel working. A mature updates project
  would allow many people, with different skills, to work together on
  a release branch. Not all of these people would have the authority
  (or even the desire) to approve patches.

We have a group responsible for managing the release branch, and these
could be the people with commit access to that tree. But I
don't want to restrict that group necessarily to be the maintainers.

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

From aph at redhat.com  Tue Feb 26 18:48:11 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 18:48:11 +0000
Subject: Fwd: openjdk8u211 tag
In-Reply-To: <CF22A74F-DE9D-4A52-BB93-9BEA210798C2@amazon.com>
References: <CF22A74F-DE9D-4A52-BB93-9BEA210798C2@amazon.com>
Message-ID: <80e2aa52-47ec-1297-3eca-55cc072ae721@redhat.com>

Comments?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An embedded message was scrubbed...
From: "Hohensee, Paul" <hohensee at amazon.com>
Subject: openjdk8u211 tag
Date: Tue, 26 Feb 2019 18:17:51 +0000
Size: 4306
URL: <https://mail.openjdk.java.net/pipermail/jdk8u-dev/attachments/20190226/dd256b0b/openjdk8u211tag-0001.eml>

From shade at redhat.com  Tue Feb 26 18:54:50 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 19:54:50 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
Message-ID: <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>

On 2/26/19 7:46 PM, Andrew Haley wrote:
> We have a group responsible for managing the release branch, and these
> could be the people with commit access to that tree. But I
> don't want to restrict that group necessarily to be the maintainers.

I do want it, though.

We would have lots of committers that come and push changesets to update projects. I would very much
prefer that machines prohibit us from committing (pun intended) mistakes that can be mechanically
checked. Regular Reviewers and Committers have no business pushing into stable tree, and this should
be mechanically forbidden. There is no need to restrict the push privileges to stable tree to
maintainers only, but it should be restricted to some subset of users who have the need to modify it.

In other needs, trust people, but also set up processes so that they cannot make simple mistakes.

-Aleksey



From hohensee at amazon.com  Tue Feb 26 19:03:01 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Feb 2019 19:03:01 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <ee0eb6f5-072c-ff91-1fab-bb8656cff57f@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <c7c08ad2-7a65-739a-75d4-fa7496a1b611@redhat.com>
 <9fa5b4f1-e0cc-197b-0285-2442a2bb326b@redhat.com>
 <1ef8b778-d7c4-88c0-a44c-e49f2f702a2f@redhat.com>
 <ee0eb6f5-072c-ff91-1fab-bb8656cff57f@redhat.com>
Message-ID: <6104DB87-E5CB-4741-830A-F6E9F5A1824A@amazon.com>

Xin isn't an Author (yet), so I've added jdk8u-fix-request to both 8216280 and 8207258.

Paul

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

    On 2/26/19 5:25 PM, Andrew Haley wrote:
    > On 2/26/19 10:32 AM, Aleksey Shipilev wrote:
    >> I have already handed over these to Liu. Liu provides the backport for these.
    > 
    > OK, so somebody really should put in the jdk8u-fix-request, then.
    
    Ah.
    
    Liu, do it please.
    
    -Aleksey
    
    
    


From hohensee at amazon.com  Tue Feb 26 19:03:39 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Feb 2019 19:03:39 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <CABi63P7pOUkeBkjKQJkXjVd11eLKFabd2CXp7Rvr5+sA08wNnA@mail.gmail.com>
References: <dd646213-11a2-f79a-501b-9d3b2c4920b6@redhat.com>
 <269CD3FA-FDB6-433A-A68B-B996EC7C8274@amazon.com>
 <CABi63P6qs6v+jrLmepSehp8X2Yx_5cJ5yhUMM+qUoKjnWe6QNg@mail.gmail.com>
 <eb60cd2b-d1ab-3ca8-6c81-9524fcb8b23c@redhat.com>
 <CABi63P66EoTgHafd+vzFRR0dDhANJpqzW4CktdJJOHSD+ZKvFQ@mail.gmail.com>
 <e168e0c037b843b3a108b96add4445bb@sap.com>
 <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
 <CABi63P7pOUkeBkjKQJkXjVd11eLKFabd2CXp7Rvr5+sA08wNnA@mail.gmail.com>
Message-ID: <A81F67B4-5351-4968-B26D-3A22AB7D471B@amazon.com>

Thank you, I'll do that from now on.

Paul

?On 2/26/19, 9:23 AM, "Andrew Hughes" <gnu.andrew at redhat.com> wrote:

    On Mon, 25 Feb 2019 at 23:07, Hohensee, Paul <hohensee at amazon.com> wrote:
    >
    > How does one get the original author's name into the backport? Is there a way to override 'hg push'?
    >
    > Thanks,
    >
    > Paul
    >
    
    It's part of the commit, not the push.
    
    $ hg commit -u ${USER}
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    Web Site: http://fuseyism.com
    Twitter: https://twitter.com/gnu_andrew_java
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    


From aph at redhat.com  Tue Feb 26 19:06:40 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 19:06:40 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
Message-ID: <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>

On 2/26/19 6:54 PM, Aleksey Shipilev wrote:
> On 2/26/19 7:46 PM, Andrew Haley wrote:
>> We have a group responsible for managing the release branch, and these
>> could be the people with commit access to that tree. But I
>> don't want to restrict that group necessarily to be the maintainers.
> 
> I do want it, though.

I am aware of that. However, I disgree, and I explained why, but this
response does not address my reasons.

> We would have lots of committers that come and push changesets to
> update projects.

I don't quite understand this sentence.

> I would very much prefer that machines prohibit us from committing
> (pun intended) mistakes that can be mechanically checked. Regular
> Reviewers and Committers have no business pushing into stable tree,
> and this should be mechanically forbidden. There is no need to
> restrict the push privileges to stable tree to maintainers only, but
> it should be restricted to some subset of users who have the need to
> modify it.

I don't object to that, as long as it's flexible enough to allow us
quickly to authorize people to work on the release tree.

> In other needs, trust people, but also set up processes so that they
> cannot make simple mistakes.

This seems to contradict your earlier statement. blocking access
to only allow maintainers doesn't only prevent mistakes.

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

From gil at azul.com  Tue Feb 26 19:22:07 2019
From: gil at azul.com (Gil Tene)
Date: Tue, 26 Feb 2019 19:22:07 +0000
Subject: openjdk8u211 tag
In-Reply-To: <80e2aa52-47ec-1297-3eca-55cc072ae721@redhat.com>
References: <CF22A74F-DE9D-4A52-BB93-9BEA210798C2@amazon.com>
 <80e2aa52-47ec-1297-3eca-55cc072ae721@redhat.com>
Message-ID: <C3E7D0FB-DA21-479B-9553-B6527EE9A4EF@azul.com>

Given the proposed process for the 8u quarterly releases going forward, I think that 8u212 would we the proper
tag for the actual April release under such a process. [See separate discussion under "Numbering of updates in
future 8u quarterly releases" (e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008564.html)
where we seem to have a quiet consensus that using the 8uXX2 numbers is the least-bad choice for now]

I guess we could have two tags (8u211 and 8u212) to distinguish the presumably security-related stuff from other
things as has been done traditionally, and just assume that everything tagged 8u211 is also included in the 8u212
release.

Or just one for both, which should probably be 8u212.

Which will be more confusing?

> On Feb 26, 2019, at 10:48 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> Comments?
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> <openjdk8u211 tag.eml>

> Begin forwarded message:
> 
> From: "Hohensee, Paul" <hohensee at amazon.com>
> Subject: openjdk8u211 tag
> Date: February 26, 2019 at 10:17:51 AM PST
> To: Andrew Haley <aph at redhat.com>
> 
> Noticed it replacing the openjdk8u tag. I thought there wasn?t going to be an OpenJDK 8u211, only a u212?
> 
> Paul


From christoph.langer at sap.com  Tue Feb 26 19:41:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 19:41:39 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
Message-ID: <3c1178e962ac45448349d6d4f56ba976@sap.com>

Hi,

I'd rather second Andrew in this discussion.

Initially I also thought it might be more sensible to restrict the subset of people with commit permissions to jdk8u/jdk11u. But if I think more about it I rather think we should keep it open. At least try to get some experiences.

Here are my reasons:
- Look at how it works with the jdk/jdk12 repositories for upstream development. There, jdk12 got more and more restrictions applied and in fact it's virtually closed now at release candidate phase. But the repository is not closed, theoretically everybody could push
- If somebody pushes by mistake to the non dev repository, this can always be backouted
- I think some changes can/will still need to go to jdk11u first (e.g. certain test fixes, changes that Oracle promotes to 11.0.3-oracle, P1 issues that we approve). For these scenarios it would be beneficial if no restrictions apply to the set of allowed committers.
- process wise it's easier to handle

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Dienstag, 26. Februar 2019 20:07
> To: Aleksey Shipilev <shade at redhat.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: 8u/11u repo access and Jira changes
> 
> On 2/26/19 6:54 PM, Aleksey Shipilev wrote:
> > On 2/26/19 7:46 PM, Andrew Haley wrote:
> >> We have a group responsible for managing the release branch, and these
> >> could be the people with commit access to that tree. But I
> >> don't want to restrict that group necessarily to be the maintainers.
> >
> > I do want it, though.
> 
> I am aware of that. However, I disgree, and I explained why, but this
> response does not address my reasons.
> 
> > We would have lots of committers that come and push changesets to
> > update projects.
> 
> I don't quite understand this sentence.
> 
> > I would very much prefer that machines prohibit us from committing
> > (pun intended) mistakes that can be mechanically checked. Regular
> > Reviewers and Committers have no business pushing into stable tree,
> > and this should be mechanically forbidden. There is no need to
> > restrict the push privileges to stable tree to maintainers only, but
> > it should be restricted to some subset of users who have the need to
> > modify it.
> 
> I don't object to that, as long as it's flexible enough to allow us
> quickly to authorize people to work on the release tree.
> 
> > In other needs, trust people, but also set up processes so that they
> > cannot make simple mistakes.
> 
> This seems to contradict your earlier statement. blocking access
> to only allow maintainers doesn't only prevent mistakes.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Feb 26 19:43:27 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 19:43:27 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3c1178e962ac45448349d6d4f56ba976@sap.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <3c1178e962ac45448349d6d4f56ba976@sap.com>
Message-ID: <667c6c9e-fbe1-0474-8ad7-3f30130a4761@redhat.com>

On 2/26/19 7:41 PM, Langer, Christoph wrote:
> I'd rather second Andrew in this discussion.

Well, thank you. I wasn't expecting that. :-)

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

From shade at redhat.com  Tue Feb 26 19:46:34 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 20:46:34 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
Message-ID: <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>

On 2/26/19 8:06 PM, Andrew Haley wrote:
> On 2/26/19 6:54 PM, Aleksey Shipilev wrote:
>> We would have lots of committers that come and push changesets to
>> update projects.
> 
> I don't quite understand this sentence.

Trying again: in update projects, we have lots of committers that are not intimately aware of all
the codified rules and conventions of the update project, no matter in how many words it is written
somewhere. The newcomer can just push to jdk8u/jdk8u without thinking twice. The experienced
committer can push to jdk8u/jdk8u by mistake. I do expect accidental pushes to jdk-updates/jdk11u
just because somebody forgot to switch to jdk-updates/jdk11u-dev.


>> I would very much prefer that machines prohibit us from committing
>> (pun intended) mistakes that can be mechanically checked. Regular
>> Reviewers and Committers have no business pushing into stable tree,
>> and this should be mechanically forbidden. There is no need to
>> restrict the push privileges to stable tree to maintainers only, but
>> it should be restricted to some subset of users who have the need to
>> modify it.
> 
> I don't object to that, as long as it's flexible enough to allow us
> quickly to authorize people to work on the release tree.

I think that: a) traffic to stable release should be small; b) traffic that goes to stable release
is probably coming through the maintainers anyway; c) ops@ are pretty responsive.

>> In other needs, trust people, but also set up processes so that they
>> cannot make simple mistakes.
> 
> This seems to contradict your earlier statement. blocking access
> to only allow maintainers doesn't only prevent mistakes.

Yes, that introduces barriers, friction, and more work. That is actually a good thing: good systems
provide barriers that prevent the majority of people from making simple mistakes at the cost of some
friction and making a few people lives a bit harder.

Maintainers basically subscribe themselves for maintenance chores. There are two ways to deal with
the additional work: a) Elect/designate more maintainers; b) Authorize _someone else_, not
necessarily a maintainer, to push to stable tree; this gets us out of this maintainer-committer
dichotomy to begin with.

I have no energy to fight it, though. If you want to keep stable tree pushable for everyone, fine. I
do reserve the right to say "told you so" every time the "Oops, I pushed to the wrong tree, sorry"
thread appears, requiring the backout, cleaning up the hgupdater mess in JIRA (I don't even want to
think how backouts work with backports...), and perhaps invalidating the testing done for the stable
release (which are also time-sensitive, tick-tock...) ;)

-Aleksey



From shade at redhat.com  Tue Feb 26 19:57:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 20:57:27 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3c1178e962ac45448349d6d4f56ba976@sap.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <3c1178e962ac45448349d6d4f56ba976@sap.com>
Message-ID: <12aded5c-c2c6-8ac4-41b8-cca7a740fc12@redhat.com>

On 2/26/19 8:41 PM, Langer, Christoph wrote:
> - Look at how it works with the jdk/jdk12 repositories for upstream development. There, jdk12 got more and more restrictions applied and in fact it's virtually closed now at release candidate phase. But the repository is not closed, theoretically everybody could push

Yes, and jdk/jdk12 is the interesting example.

First, jdk/jdk12 is really a separate repository that you would not have on your machine, unless you
had the intent to push to jdk12 at least once. The majority of committers don't, which makes the
mistakes less frequent. It is one of the very good process moves to have jdk/jdk that is always
catch-all, and any stabilization forests fork off separately, requiring separate action to work with
it. Note it is exactly the opposite of jdk-updates/jdk11u and jdk-updates/jdk11u-dev situation: most
people have the _wrong_ repository locally.

Second, people (experienced people!) who have both jdk/jdk and jdk/jdk12 trees routinely mix them up
and push the change designated to one repository, into the other one. I did it at least once. People
around me did it at least twice. The saving grace there is pushing to "wrong" repository does not
require the backout there, so these mistakes are rectified cleanly.

> - If somebody pushes by mistake to the non dev repository, this can always be backouted

Right. Do we know how hgupdater and backports backouts work? Do we really want to test it during the
maintainership takeover? Do we need to modify reports to avoid backouted backports too?

-Aleksey


From aph at redhat.com  Tue Feb 26 20:04:17 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 20:04:17 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
Message-ID: <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>

On 2/26/19 7:46 PM, Aleksey Shipilev wrote:

> Maintainers basically subscribe themselves for maintenance
> chores. There are two ways to deal with the additional work: a)
> Elect/designate more maintainers; b) Authorize _someone else_, not
> necessarily a maintainer, to push to stable tree; this gets us out
> of this maintainer-committer dichotomy to begin with.

I would prefer b), at least in theory.

> I have no energy to fight it, though. If you want to keep stable
> tree pushable for everyone, fine. I do reserve the right to say
> "told you so" every time the

Oh, sure, it'll probably happen.

> "Oops, I pushed to the wrong tree, sorry" thread appears, requiring
> the backout, cleaning up the hgupdater mess in JIRA (I don't even
> want to think how backouts work with backports...), and perhaps
> invalidating the testing done for the stable release (which are also
> time-sensitive, tick-tock...) ;)

I'm prepared to be proved wrong.

Maybe it's a cultural thing. I've worked on other large-scale free
software projects (GCC, in particular) where it just wasn't an issue
because people knew when they should be working on a release branch
and it simply wasn't an issue, but equally it was obvious which were
the release branches. Perhaps people working on OpenJDK aren't up to
it. :-)

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

From aph at redhat.com  Tue Feb 26 20:05:20 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Feb 2019 20:05:20 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <12aded5c-c2c6-8ac4-41b8-cca7a740fc12@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <3c1178e962ac45448349d6d4f56ba976@sap.com>
 <12aded5c-c2c6-8ac4-41b8-cca7a740fc12@redhat.com>
Message-ID: <26796f51-2eb8-7a9c-825c-24fa544220fd@redhat.com>

On 2/26/19 7:57 PM, Aleksey Shipilev wrote:
>> - If somebody pushes by mistake to the non dev repository, this can always be backouted
> Right. Do we know how hgupdater and backports backouts work? Do we really want to test it during the
> maintainership takeover? Do we need to modify reports to avoid backouted backports too?

Well, hold on. If we can't back out backports on the release branch
because of hgupdater problems then that's a problem we need to fix.

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

From shade at redhat.com  Tue Feb 26 20:23:04 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 26 Feb 2019 21:23:04 +0100
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>
Message-ID: <0a0ac28e-438f-7a07-56c3-664b8cd3a97e@redhat.com>

On 2/26/19 9:04 PM, Andrew Haley wrote:
> On 2/26/19 7:46 PM, Aleksey Shipilev wrote:
> Maybe it's a cultural thing. I've worked on other large-scale free
> software projects (GCC, in particular) where it just wasn't an issue
> because people knew when they should be working on a release branch
> and it simply wasn't an issue, but equally it was obvious which were
> the release branches. Perhaps people working on OpenJDK aren't up to
> it. :-)

It partially is a cultural thing. I grew up in the culture that assigned all the responsibility to
the individual workers, and no fault was ever systemic; I saw how devastating that is for both the
workers and the system. I understand the reverse side of this: when everything is system fault,
there is no personal responsibility; equally devastating.

So, the limited set of power users that can push to the stable tree is a happy amalgamation of both
approaches: stable tree is "free for all, but not for everybody". ;)

Speaking of large software projects, I think Linux gets it right: maintainers "pull" changes into
upper repositories rather than technically allowing anyone from downstream to push on their own. For
all the perfect people who are working on Linux, that is a saner approach for a responsible
maintainer, in my mind. I think this basically happened with jdk8u/jdk8u and jdk8u/jdk8u-dev split,
and once again I question why do we need to deviate...

-Aleksey



From gnu.andrew at redhat.com  Tue Feb 26 20:58:13 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 26 Feb 2019 20:58:13 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <d20774e2-d996-d716-2f4f-6c5395e5cd3e@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
 <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
 <054C7878-C666-4F14-8620-765643B7D456@amazon.com>
 <d20774e2-d996-d716-2f4f-6c5395e5cd3e@redhat.com>
Message-ID: <CABi63P7BU3YpDJqbDJ6r0Ayw+pZQAk3L7QDFZou+ZVN2ZvF-_A@mail.gmail.com>

On Tue, 26 Feb 2019 at 18:12, Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/26/19 7:04 PM, Liu, Xin wrote:
> > When I backport , I always wonder if I shall keep backport patch as intact as possible or piggyback tide-up code?
>
> Keep it intact as much as possible.
>
> Cleanups can and should follow up as the patch in dev, and then trickle down as backports, if needed.
>
> -Aleksey
>
>

For backports, apply the patch as is. If you find it depends on
changes in earlier fixes, backport those
first. Unless they are trivial, this should be in their own
changesets. Either way, make sure to include
the bug IDs of all changes backported for tracking purposes. Some of
the more annoying cases I've
found when backporting are where you are trying to apply a fix which
doesn't appear to be there, and it
fails, only to find that this is because the changes are there, but
under the auspices of a completely
different bug.

In short, hg log -k <bug ID> should work for every backported bug.

As to jcheck, it hooks into your Mercurial setup and runs during
commit. You can use this to catch
issues at the stage, rather than when you push and the server runs
jcheck, rejecting your push.

https://openjdk.java.net/projects/code-tools/jcheck/
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Feb 26 21:10:47 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 26 Feb 2019 21:10:47 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
Message-ID: <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>

On Tue, 26 Feb 2019 at 19:47, Aleksey Shipilev <shade at redhat.com> wrote:

snip...

> I have no energy to fight it, though. If you want to keep stable tree pushable for everyone, fine. I
> do reserve the right to say "told you so" every time the "Oops, I pushed to the wrong tree, sorry"
> thread appears, requiring the backout, cleaning up the hgupdater mess in JIRA (I don't even want to
> think how backouts work with backports...), and perhaps invalidating the testing done for the stable
> release (which are also time-sensitive, tick-tock...) ;)
>
> -Aleksey
>
>

Yeah, I really have no energy to argue about this further either, and
I can see both sides;
I've worked on projects, like aph, where the release branch is only
socially restricted, and it works,
but having it done technically does add a bit of peace of mind to
those of us trying to cut releases.

The questions I really need answers to are:

1. Who is going to push from jdk8u-dev -> jdk8u?

2. What is the frequency of these pushes going to be?

3. What testing is going to be performed prior to these pushes?

I'd prefer regular pushes with tags, because that would help us
downstream (aarch64-port/jdk8u-shenandoah,
shenandoah/jdk11) in being able to integrate changes more frequently.
Under Oracle, we've had to do that
at GA time only.

Thanks,
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From christoph.langer at sap.com  Tue Feb 26 21:16:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 21:16:53 +0000
Subject: openjdk8u211 tag
In-Reply-To: <C3E7D0FB-DA21-479B-9553-B6527EE9A4EF@azul.com>
References: <CF22A74F-DE9D-4A52-BB93-9BEA210798C2@amazon.com>
 <80e2aa52-47ec-1297-3eca-55cc072ae721@redhat.com>
 <C3E7D0FB-DA21-479B-9553-B6527EE9A4EF@azul.com>
Message-ID: <5162804693b44ae99d90e34b7f9edfa4@sap.com>

Hi,

I agree, openjdk8u212 would be the more appropriate tag, given that we said we won't do an 8u211 in openjdk.

Maybe we should request an openjdk8u212 version from ops and change hgupdater again for both, jdk8u-dev and jdk8u. As I have "fixed" all the openjdk8u issues to be "openjdk8u211" today, I could do that again for 8u212 ??

/Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of Gil
> Tene
> Sent: Dienstag, 26. Februar 2019 20:22
> To: Andrew Haley <aph at redhat.com>
> Cc: jdk8u-dev at openjdk.java.net
> Subject: Re: openjdk8u211 tag
> 
> Given the proposed process for the 8u quarterly releases going forward, I
> think that 8u212 would we the proper
> tag for the actual April release under such a process. [See separate discussion
> under "Numbering of updates in
> future 8u quarterly releases" (e.g.
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> February/008564.html)
> where we seem to have a quiet consensus that using the 8uXX2 numbers is
> the least-bad choice for now]
> 
> I guess we could have two tags (8u211 and 8u212) to distinguish the
> presumably security-related stuff from other
> things as has been done traditionally, and just assume that everything tagged
> 8u211 is also included in the 8u212
> release.
> 
> Or just one for both, which should probably be 8u212.
> 
> Which will be more confusing?
> 
> > On Feb 26, 2019, at 10:48 AM, Andrew Haley <aph at redhat.com> wrote:
> >
> > Comments?
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> > <openjdk8u211 tag.eml>
> 
> > Begin forwarded message:
> >
> > From: "Hohensee, Paul" <hohensee at amazon.com>
> > Subject: openjdk8u211 tag
> > Date: February 26, 2019 at 10:17:51 AM PST
> > To: Andrew Haley <aph at redhat.com>
> >
> > Noticed it replacing the openjdk8u tag. I thought there wasn?t going to be
> an OpenJDK 8u211, only a u212?
> >
> > Paul


From christoph.langer at sap.com  Tue Feb 26 21:40:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Feb 2019 21:40:34 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
Message-ID: <3f49543e8bd14cf5b3ed7381abaad339@sap.com>

Hi Andrew,

> The questions I really need answers to are:
> 
> 1. Who is going to push from jdk8u-dev -> jdk8u?

The maintainers (you, Aleksey, me, Goetz, ...)

> 2. What is the frequency of these pushes going to be?

Ok, again, here's our proposal (from the SAP folks):

We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to jdk8u once all open Oracle backports were integrated.
Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly (by those who set the tags, that is, the maintainers).
At the release day, you'll sync your security work on top of jdk8u/jdk11u and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to the same change). And this will be integrated back to jdk11u-dev.

What do you think of that?

> 3. What testing is going to be performed prior to these pushes?

Good question, currently I guess it's our quality testing at SAP plus whatever you have at RedHat. We should eventually get to something better, e.g. have some open test results from AdoptOpenJDK...??

> I'd prefer regular pushes with tags, because that would help us
> downstream (aarch64-port/jdk8u-shenandoah,
> shenandoah/jdk11) in being able to integrate changes more frequently.
> Under Oracle, we've had to do that at GA time only.

That should be helped with our concept.

Best regards
Christoph


From gnu.andrew at redhat.com  Tue Feb 26 22:07:35 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 26 Feb 2019 22:07:35 +0000
Subject: openjdk8u211 tag
In-Reply-To: <C3E7D0FB-DA21-479B-9553-B6527EE9A4EF@azul.com>
References: <CF22A74F-DE9D-4A52-BB93-9BEA210798C2@amazon.com>
 <80e2aa52-47ec-1297-3eca-55cc072ae721@redhat.com>
 <C3E7D0FB-DA21-479B-9553-B6527EE9A4EF@azul.com>
Message-ID: <CABi63P48c__FVS3rxuYt1FHW726ALKS38G2z6fhjGpQ1-kyuWQ@mail.gmail.com>

On Tue, 26 Feb 2019 at 19:22, Gil Tene <gil at azul.com> wrote:
>
> Given the proposed process for the 8u quarterly releases going forward, I think that 8u212 would we the proper
> tag for the actual April release under such a process. [See separate discussion under "Numbering of updates in
> future 8u quarterly releases" (e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008564.html)
> where we seem to have a quiet consensus that using the 8uXX2 numbers is the least-bad choice for now]
>
> I guess we could have two tags (8u211 and 8u212) to distinguish the presumably security-related stuff from other
> things as has been done traditionally, and just assume that everything tagged 8u211 is also included in the 8u212
> release.
>
> Or just one for both, which should probably be 8u212.
>
> Which will be more confusing?
>
> > On Feb 26, 2019, at 10:48 AM, Andrew Haley <aph at redhat.com> wrote:
> >
> > Comments?
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> > <openjdk8u211 tag.eml>
>
> > Begin forwarded message:
> >
> > From: "Hohensee, Paul" <hohensee at amazon.com>
> > Subject: openjdk8u211 tag
> > Date: February 26, 2019 at 10:17:51 AM PST
> > To: Andrew Haley <aph at redhat.com>
> >
> > Noticed it replacing the openjdk8u tag. I thought there wasn?t going to be an OpenJDK 8u211, only a u212?
> >
> > Paul
>

I guess this is my fault, because I'm still used to only really
thinking about the odd releases. We've
never shipped even releases because they simply weren't available to
do so until after embargo.
Also, I believe the position from Oracle was that "PSU" releases
should only be used if a specific
bug fix was needed early.

I don't think it really makes a great difference. The perception I had
that Oracle were only using 8u211
in the referenced e-mail has since been proved wrong;
https://bugs.openjdk.java.net/browse/JDK-8217579
shows 8u211, 8u212, 8u221 and 8u222 all in use (goodness knows why
they need backports to all of those!)
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Feb 27 01:05:56 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Feb 2019 01:05:56 +0000
Subject: Results: New OpenJDK 8u Reviewer: Goetz Lindenmaier
Message-ID: <CABi63P55NeovEux0evpdDgh_Mkt9dvRPGWwXc2WU0Vx9+o5NNA@mail.gmail.com>

Voting for Goetz Lindenmaier [0] is now closed.

Yes: 9
Veto: 0
Abstain: 0

Turnout: 9.5% (9/94)

According to the Bylaws definition of Three-Vote Consensus [1], this is
sufficient to approve the nomination.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008414.html
[1] http://openjdk.java.net/bylaws#three-vote-consensus
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Feb 27 01:08:32 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Feb 2019 01:08:32 +0000
Subject: Results: New OpenJDK 8u Reviewer: Martin Doerr
Message-ID: <CABi63P4n4TnkH_qiCJcHg1sN9DcGDxJZ0ghBY+LatG5M15+LdQ@mail.gmail.com>

Voting for Martin Doerr [0] is now closed.

Yes: 9
Veto: 0
Abstain: 0

Turnout: 9.5% (9/94)

According to the Bylaws definition of Three-Vote Consensus [1], this is
sufficient to approve the nomination.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008412.html
[1] http://openjdk.java.net/bylaws#three-vote-consensus
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Feb 27 01:18:55 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Feb 2019 01:18:55 +0000
Subject: CFV: New OpenJDK 8u Reviewer: Mario Torre
Message-ID: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>

I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.

Mario already has reviewership in OpenJDK 7 and his experience
when it comes to JFR (thanks to his work on Thermostat [1]) will be
invaluable on OpenJDK 8u. He does also have a sizeable number
of OpenJDK commits, particularly in the AWT and graphics area [2][3].

Votes are due by the 13th of March, 2019, at 16h00 UTC.

Only current OpenJDK 8u Reviewers [4] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.

For Three-Vote Consensus voting instructions, see [5].

[0] https://openjdk.java.net/census#neugens
[1] https://icedtea.classpath.org/wiki/Thermostat
[2] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
[3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
[4] http://openjdk.java.net/census#jdk8u
[5] http://openjdk.java.net/bylaws#three-vote-consensus
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Feb 27 01:19:16 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Feb 2019 01:19:16 +0000
Subject: CFV: New OpenJDK 8u Reviewer: Mario Torre
In-Reply-To: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
References: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
Message-ID: <CABi63P4B_tmnEZdQCoWsMCjnCSBcKJ=2Sv6-2-WiKV7jvrzY2g@mail.gmail.com>

On Wed, 27 Feb 2019 at 01:18, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
>
> Mario already has reviewership in OpenJDK 7 and his experience
> when it comes to JFR (thanks to his work on Thermostat [1]) will be
> invaluable on OpenJDK 8u. He does also have a sizeable number
> of OpenJDK commits, particularly in the AWT and graphics area [2][3].
>
> Votes are due by the 13th of March, 2019, at 16h00 UTC.
>
> Only current OpenJDK 8u Reviewers [4] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [5].
>
> [0] https://openjdk.java.net/census#neugens
> [1] https://icedtea.classpath.org/wiki/Thermostat
> [2] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [4] http://openjdk.java.net/census#jdk8u
> [5] http://openjdk.java.net/bylaws#three-vote-consensus
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Vote: Yes
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From guangyu.zhu at aliyun.com  Wed Feb 27 02:33:08 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Wed, 27 Feb 2019 10:33:08 +0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsIGZvciBiYWNrLXBvcnRpbmcgSkZSIHRvIE9wZW5KREs4dQ==?=
In-Reply-To: <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>,
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
Message-ID: <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>

Hi Andrey,

Now that Mario has created the repo, I suggest that you commit the basline patch as soon as possible, and then Alibaba will merge the missing features including thread sampling, G1 heap summary and region types, biased locking events and so on...this will speed up the backport process. What do you think?

Thanks,
Guangyu



------------------------------------------------------------------
Sender:Mario Torre <neugens at redhat.com>
Sent At:2019 Feb. 26 (Tue.) 22:00
Recipient:Andrey Petushkov <andrey at azul.com>
Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

On Tue, Feb 26, 2019 at 2:42 PM Andrey Petushkov <andrey at azul.com> wrote:
>
>
>
> On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com> wrote:
>
> > We are carrying analysis of what following JFR-related code changes to bring from jdk12+
>
> I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
>
> We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed


Yes, watching the changes is certainly good in the optic of searching
for bug (and security) fixes, I didn't mean to stop this effort, I'm
worried about backport features (like new events and perhaps APIs) to
8 however.
>
>
> I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
>
> No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take

Yes, exactly!

I would suggest to wait for your patch with the integrated
functionality and then we can proceed with a proper review cycle and
push into the incubator repository [1].

Cheers,
Mario

[1] https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/

-- 
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 Feb 27 03:10:58 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 27 Feb 2019 03:10:58 +0000
Subject: New OpenJDK 8u Reviewer: Mario Torre
In-Reply-To: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
References: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
Message-ID: <EB741563-3A40-42F5-AB2A-CD936789A152@amazon.com>

Vote: yes.

?On 2/26/19, 5:19 PM, "jdk8u-dev on behalf of Andrew Hughes" <jdk8u-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.
    
    Mario already has reviewership in OpenJDK 7 and his experience
    when it comes to JFR (thanks to his work on Thermostat [1]) will be
    invaluable on OpenJDK 8u. He does also have a sizeable number
    of OpenJDK commits, particularly in the AWT and graphics area [2][3].
    
    Votes are due by the 13th of March, 2019, at 16h00 UTC.
    
    Only current OpenJDK 8u Reviewers [4] are eligible to vote on this
    nomination. Votes must be cast in the open by replying to this mailing
    list.
    
    For Three-Vote Consensus voting instructions, see [5].
    
    [0] https://openjdk.java.net/census#neugens
    [1] https://icedtea.classpath.org/wiki/Thermostat
    [2] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
    [3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
    [4] http://openjdk.java.net/census#jdk8u
    [5] http://openjdk.java.net/bylaws#three-vote-consensus
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    Web Site: http://fuseyism.com
    Twitter: https://twitter.com/gnu_andrew_java
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    


From goetz.lindenmaier at sap.com  Wed Feb 27 08:09:40 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 27 Feb 2019 08:09:40 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
Message-ID: <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>

Hi,



Two points to this lengthy mail thread ??



Rights to push to jdk11u:



I also see that there are a lot of people that may push to jdk11u,

which might be a problem. On the census page, there are 140

reviewers and 155 committers listed for the jdk-updates project.

But so far very few people actually pushed to jdk11u, so I don't

think it's a unbearable risk to keep general push rights.

The people in committer and reviewer roles have proven to

act responsible in this matter.

And it keeps things simple. After all, it is possible to backout

a change that was pushed wrongly.

If we make bad experience, we still can change the policy.



Merging to jdk11u-dev



> Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a

> while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly

> (by those who set the tags, that is, the maintainers).

> At the release day, you'll sync your security work on top of jdk8u/jdk11u and

> add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to

> the same change). And this will be integrated back to jdk11u-dev.

I think there should be one single person dedicated to do this job. It should

be someone that has backup to keep the job up if on vacation etc.



I (backed up by Christoph and the rest of the SAP team)  would volunteer to

 1. tag jdk11u on a weekly basis after running our tests (if there was a change)

2. merge the tag to jdk11u-dev and run tests on the merged repo

3. push the changes to jdk11u-dev the day after.



I would propose to tag the change that is built by our infrastructure on

the night Tuesday-Wednesday,  which is usually pulled on Tuesday 18:00 CET.

In the night Wednesday-Thursday, the tests would run on jdk11u-dev including

the changes merged from jdk11u.  Test results will pop up during the day (Thursday),

the merged changes could be pushed on Thursday evening or Friday morning.



Our testing currently covers the following:



We build the following platforms:

  Aix

 Linux ppc64

 Linux ppc64le

 Linux s390x

 Linux x86_64

  mac

 Solaris sparc

  Windows x86_64

  Windows x86_32

We finally got an aarch64 machine, we could add that to the tests.



We run the following tests every night:

  A big part of the jck tests (excluding those requiring  manual testing, and a list of shaky tests)

  The jck tests with -Xcomp and C1, and with -Xcomp and C2.

  The hotspot and jdk jtreg tests, excluding those marked with key "headful", "printer" and "intermittent"

  Jvm2008, jbb2015, jvm98

  And finally some SAP applications.



But I'm also fine with leaving this task to RedHat, Aleksey or Andrew Hughes or whoever

would be available on your side.



For the move jdk11u-dev-->jdk11u, which happens only once a release, we should

do this by communication on the mailing list.



Best regards,

  Goetz.







> -----Original Message-----

> From: Langer, Christoph

> Sent: Tuesday, February 26, 2019 10:41 PM

> To: Andrew Hughes <gnu.andrew at redhat.com>

> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net;

> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Aleksey Shipilev

> <shade at redhat.com>

> Subject: RE: 8u/11u repo access and Jira changes

>

> Hi Andrew,

>

> > The questions I really need answers to are:

> >

> > 1. Who is going to push from jdk8u-dev -> jdk8u?

>

> The maintainers (you, Aleksey, me, Goetz, ...)

>

> > 2. What is the frequency of these pushes going to be?

>

> Ok, again, here's our proposal (from the SAP folks):

>

> We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively

> from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the

> creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to

> jdk8u once all open Oracle backports were integrated.

> Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a

> while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly

> (by those who set the tags, that is, the maintainers).

> At the release day, you'll sync your security work on top of jdk8u/jdk11u and

> add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to

> the same change). And this will be integrated back to jdk11u-dev.

>

> What do you think of that?

>

> > 3. What testing is going to be performed prior to these pushes?

>

> Good question, currently I guess it's our quality testing at SAP plus whatever

> you have at RedHat. We should eventually get to something better, e.g. have

> some open test results from AdoptOpenJDK...??

>

> > I'd prefer regular pushes with tags, because that would help us

> > downstream (aarch64-port/jdk8u-shenandoah,

> > shenandoah/jdk11) in being able to integrate changes more frequently.

> > Under Oracle, we've had to do that at GA time only.

>

> That should be helped with our concept.

>

> Best regards

> Christoph



From andrey at azul.com  Wed Feb 27 08:26:31 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 27 Feb 2019 08:26:31 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
 <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>
Message-ID: <2766123F-6DAB-4E88-8BBA-1A919CC0CD85@azul.com>

Hi Guangyu,

Yes, that would be of course easier to collaborate if the basis is in the common repo. However I assume some governing entity (Andrew H?) should approve the commit, 
as well as somebody should execute that. I'm not a committer, cannot do that

Regards,
Andrey

> On 27 Feb 2019, at 03:33, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> Hi Andrey,
> 
> Now that Mario has created the repo, I suggest that you commit the basline patch as soon as possible, and then Alibaba will merge the missing features including thread sampling, G1 heap summary and region types, biased locking events and so on...this will speed up the backport process. What do you think?
> 
> Thanks,
> Guangyu
> 
> 
> ------------------------------------------------------------------
> Sender:Mario Torre <neugens at redhat.com>
> Sent At:2019 Feb. 26 (Tue.) 22:00
> Recipient:Andrey Petushkov <andrey at azul.com>
> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> 
> On Tue, Feb 26, 2019 at 2:42 PM Andrey Petushkov <andrey at azul.com> wrote:
> >
> >
> >
> > On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com> wrote:
> >
> > > We are carrying analysis of what following JFR-related code changes to bring from jdk12+
> >
> > I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
> >
> > We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed
> 
> 
> Yes, watching the changes is certainly good in the optic of searching
> for bug (and security) fixes, I didn't mean to stop this effort, I'm
> worried about backport features (like new events and perhaps APIs) to
> 8 however.
> >
> >
> > I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
> >
> > No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take
> 
> Yes, exactly!
> 
> I would suggest to wait for your patch with the integrated
> functionality and then we can proceed with a proper review cycle and
> push into the incubator repository [1].
> 
> Cheers,
> Mario
> 
> [1] https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/
> 
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 


From sean.coffey at oracle.com  Wed Feb 27 08:41:47 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 27 Feb 2019 08:41:47 +0000
Subject: openjdk8u211 tag
In-Reply-To: <CABi63P48c__FVS3rxuYt1FHW726ALKS38G2z6fhjGpQ1-kyuWQ@mail.gmail.com>
References: <CF22A74F-DE9D-4A52-BB93-9BEA210798C2@amazon.com>
 <80e2aa52-47ec-1297-3eca-55cc072ae721@redhat.com>
 <C3E7D0FB-DA21-479B-9553-B6527EE9A4EF@azul.com>
 <CABi63P48c__FVS3rxuYt1FHW726ALKS38G2z6fhjGpQ1-kyuWQ@mail.gmail.com>
Message-ID: <262c2501-c0c7-8f70-aef2-c68e20b5d56d@oracle.com>

JBS records with the 'hgupdate-sync' label can normally be ignored for 
record purposes.

https://wiki.openjdk.java.net/display/general/JBS+Overview

regards,
Sean.

On 26/02/2019 22:07, Andrew Hughes wrote:
> On Tue, 26 Feb 2019 at 19:22, Gil Tene <gil at azul.com> wrote:
>> Given the proposed process for the 8u quarterly releases going forward, I think that 8u212 would we the proper
>> tag for the actual April release under such a process. [See separate discussion under "Numbering of updates in
>> future 8u quarterly releases" (e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008564.html)
>> where we seem to have a quiet consensus that using the 8uXX2 numbers is the least-bad choice for now]
>>
>> I guess we could have two tags (8u211 and 8u212) to distinguish the presumably security-related stuff from other
>> things as has been done traditionally, and just assume that everything tagged 8u211 is also included in the 8u212
>> release.
>>
>> Or just one for both, which should probably be 8u212.
>>
>> Which will be more confusing?
>>
>>> On Feb 26, 2019, at 10:48 AM, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> Comments?
>>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>> <openjdk8u211 tag.eml>
>>> Begin forwarded message:
>>>
>>> From: "Hohensee, Paul" <hohensee at amazon.com>
>>> Subject: openjdk8u211 tag
>>> Date: February 26, 2019 at 10:17:51 AM PST
>>> To: Andrew Haley <aph at redhat.com>
>>>
>>> Noticed it replacing the openjdk8u tag. I thought there wasn?t going to be an OpenJDK 8u211, only a u212?
>>>
>>> Paul
> I guess this is my fault, because I'm still used to only really
> thinking about the odd releases. We've
> never shipped even releases because they simply weren't available to
> do so until after embargo.
> Also, I believe the position from Oracle was that "PSU" releases
> should only be used if a specific
> bug fix was needed early.
>
> I don't think it really makes a great difference. The perception I had
> that Oracle were only using 8u211
> in the referenced e-mail has since been proved wrong;
> https://bugs.openjdk.java.net/browse/JDK-8217579
> shows 8u211, 8u212, 8u221 and 8u222 all in use (goodness knows why
> they need backports to all of those!)

From guangyu.zhu at aliyun.com  Wed Feb 27 08:46:36 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Wed, 27 Feb 2019 16:46:36 +0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsIGZvciBiYWNrLXBvcnRpbmcgSkZSIHRvIE9wZW5KREs4dQ==?=
In-Reply-To: <2766123F-6DAB-4E88-8BBA-1A919CC0CD85@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
 <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>,
 <2766123F-6DAB-4E88-8BBA-1A919CC0CD85@azul.com>
Message-ID: <6a0c704b-90cf-44b1-9cbf-d9ef684781dc.guangyu.zhu@aliyun.com>

Hi Andrey,

I am not sure if Andrew H can assign us permission to submit patches to jdk8u-jfr-incubator repo. Maybe Mario can help clarify. I am not a submitter either. Usually my colleague will help me submit a patch. I think you can do the same.

Thanks,
Guangyu


------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Feb. 27 (Wed.) 16:26
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:Mario Torre <neugens at redhat.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

Hi Guangyu,

Yes, that would be of course easier to collaborate if the basis is in the common repo. However I assume some governing entity (Andrew H?) should approve the commit, 
as well as somebody should execute that. I'm not a committer, cannot do that

Regards,
Andrey

> On 27 Feb 2019, at 03:33, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> Hi Andrey,
> 
> Now that Mario has created the repo, I suggest that you commit the basline patch as soon as possible, and then Alibaba will merge the missing features including thread sampling, G1 heap summary and region types, biased locking events and so on...this will speed up the backport process. What do you think?
> 
> Thanks,
> Guangyu
> 
> 
> ------------------------------------------------------------------
> Sender:Mario Torre <neugens at redhat.com>
> Sent At:2019 Feb. 26 (Tue.) 22:00
> Recipient:Andrey Petushkov <andrey at azul.com>
> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> 
> On Tue, Feb 26, 2019 at 2:42 PM Andrey Petushkov <andrey at azul.com> wrote:
> >
> >
> >
> > On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com> wrote:
> >
> > > We are carrying analysis of what following JFR-related code changes to bring from jdk12+
> >
> > I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
> >
> > We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed
> 
> 
> Yes, watching the changes is certainly good in the optic of searching
> for bug (and security) fixes, I didn't mean to stop this effort, I'm
> worried about backport features (like new events and perhaps APIs) to
> 8 however.
> >
> >
> > I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
> >
> > No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take
> 
> Yes, exactly!
> 
> I would suggest to wait for your patch with the integrated
> functionality and then we can proceed with a proper review cycle and
> push into the incubator repository [1].
> 
> Cheers,
> Mario
> 
> [1] https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/
> 
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 


From andrey at azul.com  Wed Feb 27 09:12:25 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 27 Feb 2019 09:12:25 +0000
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <6a0c704b-90cf-44b1-9cbf-d9ef684781dc.guangyu.zhu@aliyun.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
 <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>
 <2766123F-6DAB-4E88-8BBA-1A919CC0CD85@azul.com>
 <6a0c704b-90cf-44b1-9cbf-d9ef684781dc.guangyu.zhu@aliyun.com>
Message-ID: <AB1EBD06-AD97-4480-8258-951777592F42@azul.com>

In another thread Andrew is talking and asking questions regarding JFR integration. IMHO the status looks like:
- both Alibaba and Azul has reached understanding that current Azul's patch should be pushed as a basis for further work
- no one else has volunteered to formally review the patch
- apparently both Alibaba and Azul will review and further improve the code while working on missing features
with all above in mind, do we still need a formal review? (Andrew, what's your opinion?)

And yes, I've got a colleague with committer permission for jdk8u, so if jdk8u-incubator repos have inherited access list from jdk8u (Andrew, could you please suggest?) he can do that

Thanks,
Andrey

> On 27 Feb 2019, at 09:46, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> Hi Andrey,
> 
> I am not sure if Andrew H can assign us permission to submit patches to jdk8u-jfr-incubator repo. Maybe Mario can help clarify. I am not a submitter either. Usually my colleague will help me submit a patch. I think you can do the same.
> 
> Thanks,
> Guangyu
> 
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Feb. 27 (Wed.) 16:26
> Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> Cc:Mario Torre <neugens at redhat.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Guangyu,
> 
> Yes, that would be of course easier to collaborate if the basis is in the common repo. However I assume some governing entity (Andrew H?) should approve the commit, 
> as well as somebody should execute that. I'm not a committer, cannot do that
> 
> Regards,
> Andrey
> 
> > On 27 Feb 2019, at 03:33, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> > 
> > Hi Andrey,
> > 
> > Now that Mario has created the repo, I suggest that you commit the basline patch as soon as possible, and then Alibaba will merge the missing features including thread sampling, G1 heap summary and region types, biased locking events and so on...this will speed up the backport process. What do you think?
> > 
> > Thanks,
> > Guangyu
> > 
> > 
> > ------------------------------------------------------------------
> > Sender:Mario Torre <neugens at redhat.com>
> > Sent At:2019 Feb. 26 (Tue.) 22:00
> > Recipient:Andrey Petushkov <andrey at azul.com>
> > Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
> > Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> > 
> > On Tue, Feb 26, 2019 at 2:42 PM Andrey Petushkov <andrey at azul.com> wrote:
> > >
> > >
> > >
> > > On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com> wrote:
> > >
> > > > We are carrying analysis of what following JFR-related code changes to bring from jdk12+
> > >
> > > I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
> > >
> > > We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed
> > 
> > 
> > Yes, watching the changes is certainly good in the optic of searching
> > for bug (and security) fixes, I didn't mean to stop this effort, I'm
> > worried about backport features (like new events and perhaps APIs) to
> > 8 however.
> > >
> > >
> > > I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
> > >
> > > No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take
> > 
> > Yes, exactly!
> > 
> > I would suggest to wait for your patch with the integrated
> > functionality and then we can proceed with a proper review cycle and
> > push into the incubator repository [1].
> > 
> > Cheers,
> > Mario
> > 
> > [1] https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/
> > 
> > -- 
> > 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  Wed Feb 27 09:18:08 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 27 Feb 2019 10:18:08 +0100
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <6a0c704b-90cf-44b1-9cbf-d9ef684781dc.guangyu.zhu@aliyun.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
 <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>
 <2766123F-6DAB-4E88-8BBA-1A919CC0CD85@azul.com>
 <6a0c704b-90cf-44b1-9cbf-d9ef684781dc.guangyu.zhu@aliyun.com>
Message-ID: <CAJwKKmYQSQ_HJtOsDj9_+f6FysnfWF6oBe9S2A3-iNqSue7PRQ@mail.gmail.com>

I think the contribution should be submitted following the usual rules
I'm assuming you all have the OCA signed, then a reviewer needs to
approve the patch.

The process for me to become official reviewer just started, and while
Andrew or some of the other reviewers for 8 can approve the push
already I would like to spend this extra bit of time on you patches
myself, there are some differences between the two versions I want to
fully understand.

I think Andrew Haley is in the position to clarify the process,
however, please let's refer to his email on this topic "RFD: Draft
guidelines for working on jdk8u":

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008692.html

Cheers,
Mario

On Wed, Feb 27, 2019 at 9:46 AM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>
> Hi Andrey,
>
> I am not sure if Andrew H can assign us permission to submit patches to jdk8u-jfr-incubator repo. Maybe Mario can help clarify. I am not a submitter either. Usually my colleague will help me submit a patch. I think you can do the same.
>
> Thanks,
> Guangyu
>
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Feb. 27 (Wed.) 16:26
> Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> Cc:Mario Torre <neugens at redhat.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
>
> Hi Guangyu,
>
> Yes, that would be of course easier to collaborate if the basis is in the common repo. However I assume some governing entity (Andrew H?) should approve the commit,
> as well as somebody should execute that. I'm not a committer, cannot do that
>
> Regards,
> Andrey
>
> > On 27 Feb 2019, at 03:33, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >
> > Hi Andrey,
> >
> > Now that Mario has created the repo, I suggest that you commit the basline patch as soon as possible, and then Alibaba will merge the missing features including thread sampling, G1 heap summary and region types, biased locking events and so on...this will speed up the backport process. What do you think?
> >
> > Thanks,
> > Guangyu
> >
> >
> > ------------------------------------------------------------------
> > Sender:Mario Torre <neugens at redhat.com>
> > Sent At:2019 Feb. 26 (Tue.) 22:00
> > Recipient:Andrey Petushkov <andrey at azul.com>
> > Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
> > Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> >
> > On Tue, Feb 26, 2019 at 2:42 PM Andrey Petushkov <andrey at azul.com> wrote:
> > >
> > >
> > >
> > > On 26 Feb 2019, at 12:13, Mario Torre <neugens at redhat.com> wrote:
> > >
> > > > We are carrying analysis of what following JFR-related code changes to bring from jdk12+
> > >
> > > I don't think we should do that for every new baseline, I think integrating the platform changes from 11 to 8 is already a really big step, without endlessly backporting features from every other release down the line.
> > >
> > > We thought that it is a good idea to at watch them, at least to don't miss anything important. And given the number of such fixes happened in last 10 months it looks like having the JFR implementation open-sourced brought significant interest which possibly indicates there were number of bugs which deserve to be fixed
> >
> >
> > Yes, watching the changes is certainly good in the optic of searching
> > for bug (and security) fixes, I didn't mean to stop this effort, I'm
> > worried about backport features (like new events and perhaps APIs) to
> > 8 however.
> > >
> > >
> > > I also would like to proceed with the current patches before adding more to the table as this is already a quite difficult patch to properly review and test without thinking about changes in further releases.
> > >
> > > No problem, we can submit additional changes as a separate review requests so community can decide whether and what to take
> >
> > Yes, exactly!
> >
> > I would suggest to wait for your patch with the integrated
> > functionality and then we can proceed with a proper review cycle and
> > push into the incubator repository [1].
> >
> > Cheers,
> > Mario
> >
> > [1] https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/
> >
> > --
> > 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  Wed Feb 27 09:21:48 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 27 Feb 2019 10:21:48 +0100
Subject: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
 <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>
Message-ID: <CAJwKKmbvgMMuhFMVnuBw9jqxo0aftViEw6vic9Rs_r7rLvi0Vw@mail.gmail.com>

On Wed, Feb 27, 2019 at 3:33 AM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>
> Hi Andrey,
>
> Now that Mario has created the repo

Andrew Haley did.

> I suggest that you commit the basline patch as soon as possible
> and then Alibaba will merge the missing features including thread
> sampling, G1 heap summary and region types, biased locking
> events and so on...this will speed up the backport process.
> What do you think?

Seems like a good idea, it still needs a formal reviewer approval. As
I mentioned in another reply, the process for me just started and will
take about two weeks, I think this is reasonable time to work out the
details.

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 guangyu.zhu at aliyun.com  Wed Feb 27 09:32:00 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Wed, 27 Feb 2019 17:32:00 +0800
Subject: =?UTF-8?B?UmU6IFByb3Bvc2FsIGZvciBiYWNrLXBvcnRpbmcgSkZSIHRvIE9wZW5KREs4dQ==?=
In-Reply-To: <CAJwKKmbvgMMuhFMVnuBw9jqxo0aftViEw6vic9Rs_r7rLvi0Vw@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <CAGUMyaQ14oSqbFp8_=vTRUZa1vCfFzWg+vohbp8NSvVJKfZELw@mail.gmail.com>
 <00e1c854299484e2d5ada653ef1d011e2bbfdbd7.camel@redhat.com>
 <CAJwKKmZbJs8CxgYrTANRjrq_jpmZcZqbQtmFQgWKLtoHuPni5g@mail.gmail.com>
 <c83cd830-35ac-2fa8-47bb-583abbe270f4@redhat.com>
 <CAJwKKmbyk0=Mhy_Mpm+jB19zMTwks_Rznh4A-Uag+ktGZLo_dA@mail.gmail.com>
 <6E79B93A-A764-4263-9420-753E747343A2@azul.com>
 <b42c1511-1b40-4ace-8840-48efea7824de.guangyu.zhu@aliyun.com>
 <02581683-D07F-4DF4-8D25-23994CF0AA36@azul.com>
 <977615D3-CFDA-4A0B-AA8F-C5FF61FF66E3@azul.com>
 <CAJwKKmZGbZur8KaGi64tgzT6i1Xa3kyXd0rB_Pe03JKyQ_rC+g@mail.gmail.com>
 <8EF95A05-B8BF-4CDF-914D-81DCDC684402@azul.com>
 <CAJwKKmZ8oFcxC8JS1OBrAGeJPKeD_wGEh-KMLsaQ30c7HRKtTQ@mail.gmail.com>
 <743e6a44-d42b-4690-af9e-53c51ba59aae.guangyu.zhu@aliyun.com>,
 <CAJwKKmbvgMMuhFMVnuBw9jqxo0aftViEw6vic9Rs_r7rLvi0Vw@mail.gmail.com>
Message-ID: <a6ee27be-6c95-45f5-aa68-810b1e2375a3.guangyu.zhu@aliyun.com>

oh, thank you for pointing out my mistake. Yes, each patch need a formal review.

thanks,
Guangyu
------------------------------------------------------------------
Sender:Mario Torre <neugens at redhat.com>
Sent At:2019 Feb. 27 (Wed.) 17:22
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:Andrey Petushkov <andrey at azul.com>; yumin qi <yumin.qi at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; kingsum.chow <kingsum.chow at gmail.com>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u

On Wed, Feb 27, 2019 at 3:33 AM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>
> Hi Andrey,
>
> Now that Mario has created the repo

Andrew Haley did.

> I suggest that you commit the basline patch as soon as possible
> and then Alibaba will merge the missing features including thread
> sampling, G1 heap summary and region types, biased locking
> events and so on...this will speed up the backport process.
> What do you think?

Seems like a good idea, it still needs a formal reviewer approval. As
I mentioned in another reply, the process for me just started and will
take about two weeks, I think this is reasonable time to work out the
details.

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 aph at redhat.com  Wed Feb 27 09:46:14 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 Feb 2019 09:46:14 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <0a0ac28e-438f-7a07-56c3-664b8cd3a97e@redhat.com>
References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com>
 <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com>
 <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com>
 <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com>
 <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com>
 <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com>
 <8bba13dc-53f6-90c1-a379-d43adc528d97@redhat.com>
 <0a0ac28e-438f-7a07-56c3-664b8cd3a97e@redhat.com>
Message-ID: <23cb5d83-f43b-69ee-84f3-4cd3fc0d94fb@redhat.com>

On 2/26/19 8:23 PM, Aleksey Shipilev wrote:

> Speaking of large software projects, I think Linux gets it right:
> maintainers "pull" changes into upper repositories rather than
> technically allowing anyone from downstream to push on their
> own. For all the perfect people who are working on Linux, that is a
> saner approach for a responsible maintainer, in my mind.

OMG, I cannot find words adequate to tell you how much I hate that:
pull requests are the worst part of the GitHub process. Firstly, it is
far too much of a bottleneck. Better to distribute the workload, with
people testing and pushing their own patches. It also reinforces the
power and status of the high priesthood, leading to an unhealthy
culture of insiders and outsiders. Some of this is inevitable in that
we must not break stuff, of course, but I believe we should do
everything to break down those insider/outsider barriers short of
introducing extra risk. That's why things like automated testing
available to everyone are so good.

Individual responsibility FTW!

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

From shade at redhat.com  Wed Feb 27 11:59:30 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 12:59:30 +0100
Subject: JDK-8141421 and 8u
Message-ID: <800a573d-a5dd-d676-1b75-79947926b161@redhat.com>

Hi,

It seems another issue does not have public record of being backported.

See:
  https://bugs.openjdk.java.net/browse/JDK-8141421

...mentions the backport to 8u211. Yet, here is the change in current 8u-dev:
  http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3fa12c91c20a

...which I think ended up in 8u202.

David, could you please check this one too?

-Aleksey


From david.holmes at oracle.com  Wed Feb 27 12:50:49 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Feb 2019 22:50:49 +1000
Subject: JDK-8141421 and 8u
In-Reply-To: <800a573d-a5dd-d676-1b75-79947926b161@redhat.com>
References: <800a573d-a5dd-d676-1b75-79947926b161@redhat.com>
Message-ID: <019a38e6-364e-60de-d4d5-9468ad1e6ec5@oracle.com>

Hi Aleksey,

On 27/02/2019 9:59 pm, Aleksey Shipilev wrote:
> Hi,
> 
> It seems another issue does not have public record of being backported.
> 
> See:
>    https://bugs.openjdk.java.net/browse/JDK-8141421
> 
> ...mentions the backport to 8u211. Yet, here is the change in current 8u-dev:
>    http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3fa12c91c20a
> 
> ...which I think ended up in 8u202.
> 
> David, could you please check this one too?

Same scenario. The 8u202 backport went to the public repo but is a 
Confidential issue for some reason. The 8u211 backport is a public issue 
but went to a non-public repo. Not sure I can correct in this case but 
will try.

David

> -Aleksey
> 

From zgu at redhat.com  Wed Feb 27 13:21:27 2019
From: zgu at redhat.com (zgu at redhat.com)
Date: Wed, 27 Feb 2019 08:21:27 -0500
Subject: CFV: New OpenJDK 8u Reviewer: Mario Torre
In-Reply-To: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
References: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
Message-ID: <1551273687.18805.85.camel@redhat.com>

Vote: yes

-Zhengyu

On Wed, 2019-02-27 at 01:18 +0000, Andrew Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u
> Reviewer.
> 
> Mario already has reviewership in OpenJDK 7 and his experience
> when it comes to JFR (thanks to his work on Thermostat [1]) will be
> invaluable on OpenJDK 8u. He does also have a sizeable number
> of OpenJDK commits, particularly in the AWT and graphics area [2][3].
> 
> Votes are due by the 13th of March, 2019, at 16h00 UTC.
> 
> Only current OpenJDK 8u Reviewers [4] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing
> list.
> 
> For Three-Vote Consensus voting instructions, see [5].
> 
> [0] https://openjdk.java.net/census#neugens
> [1] https://icedtea.classpath.org/wiki/Thermostat
> [2] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&
> rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+mer
> ge()
> [3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=
> (author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge()
> [4] http://openjdk.java.net/census#jdk8u
> [5] http://openjdk.java.net/bylaws#three-vote-consensus

From christoph.langer at sap.com  Wed Feb 27 14:34:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Feb 2019 14:34:45 +0000
Subject: JBS Filters for JDK update work
Message-ID: <3fa6de91b4c44736a6570256851c52d3@sap.com>

Hi all,

after putting some more efforts into my issue filters for jdk-updates projects, here is a current list of the available ones. It might be of value to some folks? As always: You need to be logged in to JBS, otherwise these won?t work. If you find bugs, please report to me.

Unapproved requests (for the maintainers/approvers):
8u: https://bugs.openjdk.java.net/issues/?filter=36415
11u: https://bugs.openjdk.java.net/issues/?filter=36358
12u: https://bugs.openjdk.java.net/issues/?filter=36359

Approved requests without push (?orphans?):
8u: https://bugs.openjdk.java.net/issues/?filter=36427
11u: https://bugs.openjdk.java.net/issues/?filter=36412
12u: https://bugs.openjdk.java.net/issues/?filter=36425

Open Downports Oracle -> OpenJDK:
8u212: https://bugs.openjdk.java.net/issues/?filter=36394
8u222: https://bugs.openjdk.java.net/issues/?filter=36456
11.0.3: https://bugs.openjdk.java.net/issues/?filter=36366
11.0.4: https://bugs.openjdk.java.net/issues/?filter=36409

Additional commits in OpenJDK vs. the equivalent Oracle release
8u212: https://bugs.openjdk.java.net/issues/?filter=36458
8u222: https://bugs.openjdk.java.net/issues/?filter=36459
11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457

To sort out some issues that are not relevant to OpenJDK, I introduced a new label ?openjdk-na?. If you flag a bug with this, it?ll fall out of my views.
If you want to check whether I flagged something wrongly (where?s my bug?), you can check here: https://bugs.openjdk.java.net/issues/?jql=labels+%3D+openjdk-na

For jdk8u I filter issues which have originally been fixed in openjfx12 or openjfx13 as those probably don?t affect OpenJDK. Maybe we should check the list of openjdkfx bugs for an 8u release at some time during the cycle manually to check that nothing slipped through.

Have fun backporting ??
Christoph


From shade at redhat.com  Wed Feb 27 15:21:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 16:21:37 +0100
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <53101fe3-08f5-5728-dc74-6853e52fd32f@redhat.com>

On 2/27/19 3:34 PM, Langer, Christoph wrote:
> Hi all,
> 
> after putting some more efforts into my issue filters for jdk-updates projects, here is a current list of the available ones. It might be of value to some folks? As always: You need to be logged in to JBS, otherwise these won?t work. If you find bugs, please report to me.
> 
> Unapproved requests (for the maintainers/approvers):
> 8u: https://bugs.openjdk.java.net/issues/?filter=36415
> 11u: https://bugs.openjdk.java.net/issues/?filter=36358
> 12u: https://bugs.openjdk.java.net/issues/?filter=36359
> 
> Approved requests without push (?orphans?):
> 8u: https://bugs.openjdk.java.net/issues/?filter=36427
> 11u: https://bugs.openjdk.java.net/issues/?filter=36412
> 12u: https://bugs.openjdk.java.net/issues/?filter=36425
> 
> Open Downports Oracle -> OpenJDK:
> 8u212: https://bugs.openjdk.java.net/issues/?filter=36394
> 8u222: https://bugs.openjdk.java.net/issues/?filter=36456
> 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36366
> 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36409
> 
> Additional commits in OpenJDK vs. the equivalent Oracle release
> 8u212: https://bugs.openjdk.java.net/issues/?filter=36458
> 8u222: https://bugs.openjdk.java.net/issues/?filter=36459
> 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
> 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457

These are excellent. We need to put them on Wiki.

-Aleksey


From neugens at redhat.com  Wed Feb 27 16:00:43 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 27 Feb 2019 17:00:43 +0100
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
Message-ID: <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>

On Fri, 2019-02-08 at 17:39 +0000, Andrey Petushkov wrote:
> Dear team!

Hello Andrey (and everyone else),

Some notes first :)

I gave a look at both Azul and Alibaba patches, they are obviously very
similar so I went with the latest consensus that is to integrate Azul
patch first and then add some of the missing functionality from what
Alibaba did, I also believe this makes it a tiny bit easier since it
can be considered a progressive delta, however if the opposite is
desired, please let me know.

I changed the subject line and cleaned the recipient list to make it a
bit easier to follow the discussion, I expect people interested in this
patch to be subscribed to jdk8u-dev mailing list anyway.

I will file a bug report to track the back porting effort, I think we
will need to include the CSR at some point in the process, however I'll
leave this to Andrew Haley as project maintainer, I think for the time
being we can experiment on the incubator branch.

Also, we will need to keep this branch updated with latest changes from
the primary repository, it is appreciated if other committers can
participate in this task.

Finally, I take this opportunity to thank you and Guangyu and everyone
else involved for those patches and for your patience as well as
understanding regarding the process.

Ok, now on with the interesting bits ;)

I applied the patch from http://cr.openjdk.java.net/~apetushkov/jfr8/
as described in you email below and compiled everything, --enable-jfr is enabled by default I think this should be disabled by default instead, however, when compiling even if I pass --disable-jfr I still see that the jfr files gets compiled and everything, so the option doesn't appear to do anything. What is the proper way to disable it?

Cheers,
Mario


> It happened that in the meanwhile Azul was also working on preparing
> the backport of JFR to jdk8 codebase. We as well have finished the
> implementation recently and would like to contribute it to the
> community. Our approach and platform coverage is a bit different so
> patches are definitely not the same. One might want to compare and
> merge somehow to get most of both. We are performing difference
> analysis but not yet finished. Will update once we have full
> information.
> The following is different to your approach:
> - We did not add EnableJFR flag, JFR could be used in the same way as
> in jdk11
> - we have added ?enable-jfr parameter to configure script to control
> inclusion of JFR into binary
> - -XX:+/-LogJFR VM parameter to control JFR logging (analogous to
> -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
> - we have removed the ?trace*? build files while adding ?jfr*? files.
> We believe such approach makes it easier to backport further jfr
> fixes from jdk11+
> - we have the following platforms supported: Linux x86, ppc, arm, all
> in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64
> are supported (Solaris on x86 and sparc have some bugs which are not
> resolved yet)
> We as well have JFR test suite passed with some limitations coming
> from missing VM features (we did not add some missing WhiteBox APIs
> so test coverage is a bit smaller than yours)
> There might be as well difference in data being supported, e.g. Azul
> implementation does not support G1 memory types, while Alibaba seem
> to have added missing G1 functionality to get this data
> 
> The webrev is at
> http://cr.openjdk.java.net/~apetushkov/jfr8/
> Baseline is 8u202.
> The changes to aarch64- and aarch32-port projects are delta on top of
> generic hotspot patch.
> Shenandoah GC is not integrated with JFR. BTW, related question to
> RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months,
> and latest update level is u181. Does that mean that OpenJDK aarch64-
> jdk8u mainline is considered to be hosted in 
> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos
> (where 8u192 is propagated for some time already)? Just in case I?ve
> posted integration patches for both repos
> 
> Regards,
> Andrey
> 
> 
> Begin forwarded message:
> 
> From: "guangyu.zhu" <guangyu.zhu at aliyun.com<mailto:
> guangyu.zhu at aliyun.com>>
> Subject: Re: Proposal for back-porting JFR to OpenJDK8u
> Date: January 29, 2019 at 3:41:35 AM PST
> To: "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "Mario
> Torre" <neugens.limasoftware at gmail.com<mailto:
> neugens.limasoftware at gmail.com>>, "jdk8u-dev" <
> jdk8u-dev-bounces at openjdk.java.net<mailto:
> jdk8u-dev-bounces at openjdk.java.net>>
> Cc: yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>,
> kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>,
> jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
> jdk8u-dev at openjdk.java.net>>, denghui.ddh <denghui.ddh at antfin.com<mai
> lto:denghui.ddh at antfin.com>>
> Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
> guangyu.zhu at aliyun.com>>
> 
> Hi there,
> 
> JFR backport patch has been uploaded to cr.openjdk. Please have a
> review for the patch.
> 
> Webrev:
> http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
> http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/
> 
> The original patch comes from webrev: 
> http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
>  . We ported it to jdk8u192-b26 and passed most of the jfr jtreg
> tests on Linux/x86-64 platform. Some features related to Module, AOT
> and log level are removed because jdk8 does not support them.
> 
> We have added a new option ?EnableJFR? to enable or disable the JFR
> feature. It?s disabled by default. To enable it, you can start java
> with ?-XX:+EnableJFR?.  For example:
> java -XX:+EnableJFR
> -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp
> 
> When running the jtreg test, please add the extra option '-vmoption:-
> XX:+EnableJFR'. Otherwise the test case will not execute correctly.
> Here is an example of running jfr jtreg test:
> make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR
> TEST=jdk_jfr
> 
> There is one more thing worth noting, please use jmc version 7.0 or
> later to open the jfr record file.
> 
> Your suggestions and comments are welcome.
> 
> Thanks,
> Guangyu Zhu
> ------------------------------------------------------------------
> Sender:???(??) <sanhong.lsh at alibaba-inc.com<mailto:
> sanhong.lsh at alibaba-inc.com>>
> Sent At:2018 Dec. 17 (Mon.) 21:21
> Recipient:Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Mario
> Torre <neugens.limasoftware at gmail.com<mailto:
> neugens.limasoftware at gmail.com>>
> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
> jdk8u-dev at openjdk.java.net>>
> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> 
> Thanks for comments, we are preparing our internal patches for
> webrev.
> In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to
> produce technical preview build.
> Would like to know this... can Martijn point us some guide somewhere?
> 
> Thanks!
> Sanhong
> -----????-----
> ???: Andrew Haley [mailto:aph at redhat.com]
> ????: 2018?12?13? 3:03
> ???: Mario Torre <neugens.limasoftware at gmail.com<mailto:
> neugens.limasoftware at gmail.com>>; ???(??) <
> sanhong.lsh at alibaba-inc.com<mailto:sanhong.lsh at alibaba-inc.com>>
> ??: Volker Simonis <volker.simonis at gmail.com<mailto:
> volker.simonis at gmail.com>>; jdk8u-dev at openjdk.java.net<mailto:
> jdk8u-dev at openjdk.java.net>
> ??: Re: Proposal for back-porting JFR to OpenJDK8u
> 
> On 12/12/18 1:44 PM, Mario Torre wrote:
> I think the first thing to do would be to post the patch for review,
> a
> shared repository would make the review process a bit more complex I
> think, and only makes sense if there is a need to work further on the
> patch collectively.
> 
> Yes, exactly. That's the normal process, and it's the best place to
> start.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> 
> 
> 
> 
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From andrey at azul.com  Wed Feb 27 16:45:27 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 27 Feb 2019 16:45:27 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
Message-ID: <AC9DA9CC-F6E6-404C-93A6-A50752669BB9@azul.com>

Hi Mario,

First of all great thank you for the interest and such immediate involvement into this effort.
I'm sure it will help to move it faster towards having done and adopted into jdk8u mainline :)

To your particular question, what are the evidence that jfr files get compiled? It's a bit tricky thing hence the question.
There are in fact two processes which might or might not happen:
- jfr*.cpp files get compiled and linked into libjvm.so. Also JFR classes get compiled and put into jfr.jar. 
This should happen only when --enable-jfr is turned on (and yes, it's on by default)
- jfr metadata is processed and respective java and c++ classes are generated (into hotspot/linux_amd64_compiler2/generated/tools/jfr, 
hotspot/linux_amd64_compiler2/generated/jfrfiles and jdk/lib/jfr under the build directory). This in fact happens regardless of whether 
JFR is enabled or not

So if you only see the latter but don't see any jfr*.o or jfr.jar files that is normal (and that's what I observe with the code I've used to generate webrev from). 
Otherwise something is wrong. Please let me know what is the case for you

Regarding why it works that way, it's not something I've invented. It's exactly the way JFR gets built in jdk11 codebase. If it's unacceptable I'll work to change it, 
but please be aware that in order to avoid generation of jfr*.hpp files one would need to put a lot of extra #ifdefs into non-jfr specific files. Which I tried to avoid 
to keep the code as close to the original as possible (and seeing no value in doing such change, in fact).

Re default value for --enable-jfr, thank you, I've noted that. Will fix

Thanks,
Andrey

> On 27 Feb 2019, at 17:00, Mario Torre <neugens at redhat.com> wrote:
> 
> On Fri, 2019-02-08 at 17:39 +0000, Andrey Petushkov wrote:
>> Dear team!
> 
> Hello Andrey (and everyone else),
> 
> Some notes first :)
> 
> I gave a look at both Azul and Alibaba patches, they are obviously very
> similar so I went with the latest consensus that is to integrate Azul
> patch first and then add some of the missing functionality from what
> Alibaba did, I also believe this makes it a tiny bit easier since it
> can be considered a progressive delta, however if the opposite is
> desired, please let me know.
> 
> I changed the subject line and cleaned the recipient list to make it a
> bit easier to follow the discussion, I expect people interested in this
> patch to be subscribed to jdk8u-dev mailing list anyway.
> 
> I will file a bug report to track the back porting effort, I think we
> will need to include the CSR at some point in the process, however I'll
> leave this to Andrew Haley as project maintainer, I think for the time
> being we can experiment on the incubator branch.
> 
> Also, we will need to keep this branch updated with latest changes from
> the primary repository, it is appreciated if other committers can
> participate in this task.
> 
> Finally, I take this opportunity to thank you and Guangyu and everyone
> else involved for those patches and for your patience as well as
> understanding regarding the process.
> 
> Ok, now on with the interesting bits ;)
> 
> I applied the patch from http://cr.openjdk.java.net/~apetushkov/jfr8/
> as described in you email below and compiled everything, --enable-jfr is enabled by default I think this should be disabled by default instead, however, when compiling even if I pass --disable-jfr I still see that the jfr files gets compiled and everything, so the option doesn't appear to do anything. What is the proper way to disable it?
> 
> Cheers,
> Mario
> 
> 
>> It happened that in the meanwhile Azul was also working on preparing
>> the backport of JFR to jdk8 codebase. We as well have finished the
>> implementation recently and would like to contribute it to the
>> community. Our approach and platform coverage is a bit different so
>> patches are definitely not the same. One might want to compare and
>> merge somehow to get most of both. We are performing difference
>> analysis but not yet finished. Will update once we have full
>> information.
>> The following is different to your approach:
>> - We did not add EnableJFR flag, JFR could be used in the same way as
>> in jdk11
>> - we have added ?enable-jfr parameter to configure script to control
>> inclusion of JFR into binary
>> - -XX:+/-LogJFR VM parameter to control JFR logging (analogous to
>> -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
>> - we have removed the ?trace*? build files while adding ?jfr*? files.
>> We believe such approach makes it easier to backport further jfr
>> fixes from jdk11+
>> - we have the following platforms supported: Linux x86, ppc, arm, all
>> in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64
>> are supported (Solaris on x86 and sparc have some bugs which are not
>> resolved yet)
>> We as well have JFR test suite passed with some limitations coming
>> from missing VM features (we did not add some missing WhiteBox APIs
>> so test coverage is a bit smaller than yours)
>> There might be as well difference in data being supported, e.g. Azul
>> implementation does not support G1 memory types, while Alibaba seem
>> to have added missing G1 functionality to get this data
>> 
>> The webrev is at
>> http://cr.openjdk.java.net/~apetushkov/jfr8/
>> Baseline is 8u202.
>> The changes to aarch64- and aarch32-port projects are delta on top of
>> generic hotspot patch.
>> Shenandoah GC is not integrated with JFR. BTW, related question to
>> RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months,
>> and latest update level is u181. Does that mean that OpenJDK aarch64-
>> jdk8u mainline is considered to be hosted in 
>> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos
>> (where 8u192 is propagated for some time already)? Just in case I?ve
>> posted integration patches for both repos
>> 
>> Regards,
>> Andrey
>> 
>> 
>> Begin forwarded message:
>> 
>> From: "guangyu.zhu" <guangyu.zhu at aliyun.com<mailto:
>> guangyu.zhu at aliyun.com>>
>> Subject: Re: Proposal for back-porting JFR to OpenJDK8u
>> Date: January 29, 2019 at 3:41:35 AM PST
>> To: "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "Mario
>> Torre" <neugens.limasoftware at gmail.com<mailto:
>> neugens.limasoftware at gmail.com>>, "jdk8u-dev" <
>> jdk8u-dev-bounces at openjdk.java.net<mailto:
>> jdk8u-dev-bounces at openjdk.java.net>>
>> Cc: yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>,
>> kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>,
>> jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
>> jdk8u-dev at openjdk.java.net>>, denghui.ddh <denghui.ddh at antfin.com<mai
>> lto:denghui.ddh at antfin.com>>
>> Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
>> guangyu.zhu at aliyun.com>>
>> 
>> Hi there,
>> 
>> JFR backport patch has been uploaded to cr.openjdk. Please have a
>> review for the patch.
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
>> http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/
>> 
>> The original patch comes from webrev: 
>> http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
>> . We ported it to jdk8u192-b26 and passed most of the jfr jtreg
>> tests on Linux/x86-64 platform. Some features related to Module, AOT
>> and log level are removed because jdk8 does not support them.
>> 
>> We have added a new option ?EnableJFR? to enable or disable the JFR
>> feature. It?s disabled by default. To enable it, you can start java
>> with ?-XX:+EnableJFR?.  For example:
>> java -XX:+EnableJFR
>> -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp
>> 
>> When running the jtreg test, please add the extra option '-vmoption:-
>> XX:+EnableJFR'. Otherwise the test case will not execute correctly.
>> Here is an example of running jfr jtreg test:
>> make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR
>> TEST=jdk_jfr
>> 
>> There is one more thing worth noting, please use jmc version 7.0 or
>> later to open the jfr record file.
>> 
>> Your suggestions and comments are welcome.
>> 
>> Thanks,
>> Guangyu Zhu
>> ------------------------------------------------------------------
>> Sender:???(??) <sanhong.lsh at alibaba-inc.com<mailto:
>> sanhong.lsh at alibaba-inc.com>>
>> Sent At:2018 Dec. 17 (Mon.) 21:21
>> Recipient:Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Mario
>> Torre <neugens.limasoftware at gmail.com<mailto:
>> neugens.limasoftware at gmail.com>>
>> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
>> jdk8u-dev at openjdk.java.net>>
>> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
>> 
>> Thanks for comments, we are preparing our internal patches for
>> webrev.
>> In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to
>> produce technical preview build.
>> Would like to know this... can Martijn point us some guide somewhere?
>> 
>> Thanks!
>> Sanhong
>> -----????-----
>> ???: Andrew Haley [mailto:aph at redhat.com]
>> ????: 2018?12?13? 3:03
>> ???: Mario Torre <neugens.limasoftware at gmail.com<mailto:
>> neugens.limasoftware at gmail.com>>; ???(??) <
>> sanhong.lsh at alibaba-inc.com<mailto:sanhong.lsh at alibaba-inc.com>>
>> ??: Volker Simonis <volker.simonis at gmail.com<mailto:
>> volker.simonis at gmail.com>>; jdk8u-dev at openjdk.java.net<mailto:
>> jdk8u-dev at openjdk.java.net>
>> ??: Re: Proposal for back-porting JFR to OpenJDK8u
>> 
>> On 12/12/18 1:44 PM, Mario Torre wrote:
>> I think the first thing to do would be to post the patch for review,
>> a
>> shared repository would make the review process a bit more complex I
>> think, and only makes sense if there is a need to work further on the
>> patch collectively.
>> 
>> Yes, exactly. That's the normal process, and it's the best place to
>> start.
>> 
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> 
>> 
>> 
>> 
>> 
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From shade at redhat.com  Wed Feb 27 18:42:15 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 19:42:15 +0100
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <ED4F2C50-FF5A-4589-B135-2B1CBC96FD0E@amazon.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
 <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
 <054C7878-C666-4F14-8620-765643B7D456@amazon.com>
 <d20774e2-d996-d716-2f4f-6c5395e5cd3e@redhat.com>
 <CABi63P7BU3YpDJqbDJ6r0Ayw+pZQAk3L7QDFZou+ZVN2ZvF-_A@mail.gmail.com>
 <ED4F2C50-FF5A-4589-B135-2B1CBC96FD0E@amazon.com>
Message-ID: <66bc6229-c5b4-5045-e181-2254a7b5060e@redhat.com>

On 2/27/19 3:46 AM, Liu, Xin wrote:
> Thanks! Here is a new revision of two backport patches. 
> http://cr.openjdk.java.net/~phh/8207258/webrev.8u.01/

A minor thing left: webrev seems to overwrite the original metadata.

The original changes have it like below:

  # User mullan
  8207258: Distrust TLS server certificates anchored by Symantec Root CAs
  Reviewed-by: weijun

  # User mullan
  8216280: Allow later Symantec Policy distrust date for two Apple SubCAs
  Reviewed-by: coffeys

Your change has it as:

  # User phh
  8207258: Distrust TLS server certificates anchored by Symantec Root CAs
  Reviewed-by: shade

  # User phh
  8216280: Allow later Symantec Policy distrust date for two Apple SubCAs
  Reviewed-by: shade

Please make sure you don't drop the reviewers and original author ("User").

-Aleksey


From shade at redhat.com  Wed Feb 27 18:43:40 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 19:43:40 +0100
Subject: JDK-8141421 and 8u
In-Reply-To: <019a38e6-364e-60de-d4d5-9468ad1e6ec5@oracle.com>
References: <800a573d-a5dd-d676-1b75-79947926b161@redhat.com>
 <019a38e6-364e-60de-d4d5-9468ad1e6ec5@oracle.com>
Message-ID: <569e197c-f7c9-7172-611c-5e35024af50e@redhat.com>

On 2/27/19 1:50 PM, David Holmes wrote:
> On 27/02/2019 9:59 pm, Aleksey Shipilev wrote:
>> It seems another issue does not have public record of being backported.
>>
>> See:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8141421
>>
>> ...mentions the backport to 8u211. Yet, here is the change in current 8u-dev:
>> ?? http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3fa12c91c20a
>>
>> ...which I think ended up in 8u202.
>>
>> David, could you please check this one too?
> 
> Same scenario. The 8u202 backport went to the public repo but is a Confidential issue for some
> reason. The 8u211 backport is a public issue but went to a non-public repo. Not sure I can correct
> in this case but will try.

Thank you! I see the backport link with 8u202 now. That matches what is going on in the repository,
I think.

-Aleksey


From shade at redhat.com  Wed Feb 27 18:44:00 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 19:44:00 +0100
Subject: CFV: New OpenJDK 8u Reviewer: Mario Torre
In-Reply-To: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
References: <CABi63P5OwzhrVEEZ=usqAiXg7rG1qz9xcQaX5J+Q-sqUdKHk7Q@mail.gmail.com>
Message-ID: <1f4b21cf-5c15-3c9a-18c5-43e77c9000a1@redhat.com>

Vote: yes

On 2/27/19 2:18 AM, Andrew Hughes wrote:
> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer.



From neugens at redhat.com  Wed Feb 27 19:12:47 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 27 Feb 2019 20:12:47 +0100
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <AC9DA9CC-F6E6-404C-93A6-A50752669BB9@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <AC9DA9CC-F6E6-404C-93A6-A50752669BB9@azul.com>
Message-ID: <CAJwKKmZLtzyv5=vEs0TPCmbwC5-ZFMwYukY_uAeDOcv5YSs48A@mail.gmail.com>

On Wed, Feb 27, 2019 at 5:45 PM Andrey Petushkov <andrey at azul.com> wrote:
>
> Hi Mario,
>
> First of all great thank you for the interest and such immediate involvement into this effort.
> I'm sure it will help to move it faster towards having done and adopted into jdk8u mainline :)
>
> To your particular question, what are the evidence that jfr files get compiled? It's a bit tricky thing hence the question.
> There are in fact two processes which might or might not happen:
> - jfr*.cpp files get compiled and linked into libjvm.so. Also JFR classes get compiled and put into jfr.jar.

Well, the thing is that I tried passing  --disable-jfr and I can dump
a perfercly functioning JFR file.

I think the option to not build JFR is not working properly, I can see
in the config.log that is being registered correctly:

configure:19778: checking whether to build jfr
configure:19794: result: false

However then the same build can produce a JFR file.

Cheers,
Mario


> This should happen only when --enable-jfr is turned on (and yes, it's on by default)
> - jfr metadata is processed and respective java and c++ classes are generated (into hotspot/linux_amd64_compiler2/generated/tools/jfr,
> hotspot/linux_amd64_compiler2/generated/jfrfiles and jdk/lib/jfr under the build directory). This in fact happens regardless of whether
> JFR is enabled or not
>
> So if you only see the latter but don't see any jfr*.o or jfr.jar files that is normal (and that's what I observe with the code I've used to generate webrev from).
> Otherwise something is wrong. Please let me know what is the case for you
>
> Regarding why it works that way, it's not something I've invented. It's exactly the way JFR gets built in jdk11 codebase. If it's unacceptable I'll work to change it,
> but please be aware that in order to avoid generation of jfr*.hpp files one would need to put a lot of extra #ifdefs into non-jfr specific files. Which I tried to avoid
> to keep the code as close to the original as possible (and seeing no value in doing such change, in fact).
>
> Re default value for --enable-jfr, thank you, I've noted that. Will fix
>
> Thanks,
> Andrey
>
> > On 27 Feb 2019, at 17:00, Mario Torre <neugens at redhat.com> wrote:
> >
> > On Fri, 2019-02-08 at 17:39 +0000, Andrey Petushkov wrote:
> >> Dear team!
> >
> > Hello Andrey (and everyone else),
> >
> > Some notes first :)
> >
> > I gave a look at both Azul and Alibaba patches, they are obviously very
> > similar so I went with the latest consensus that is to integrate Azul
> > patch first and then add some of the missing functionality from what
> > Alibaba did, I also believe this makes it a tiny bit easier since it
> > can be considered a progressive delta, however if the opposite is
> > desired, please let me know.
> >
> > I changed the subject line and cleaned the recipient list to make it a
> > bit easier to follow the discussion, I expect people interested in this
> > patch to be subscribed to jdk8u-dev mailing list anyway.
> >
> > I will file a bug report to track the back porting effort, I think we
> > will need to include the CSR at some point in the process, however I'll
> > leave this to Andrew Haley as project maintainer, I think for the time
> > being we can experiment on the incubator branch.
> >
> > Also, we will need to keep this branch updated with latest changes from
> > the primary repository, it is appreciated if other committers can
> > participate in this task.
> >
> > Finally, I take this opportunity to thank you and Guangyu and everyone
> > else involved for those patches and for your patience as well as
> > understanding regarding the process.
> >
> > Ok, now on with the interesting bits ;)
> >
> > I applied the patch from http://cr.openjdk.java.net/~apetushkov/jfr8/
> > as described in you email below and compiled everything, --enable-jfr is enabled by default I think this should be disabled by default instead, however, when compiling even if I pass --disable-jfr I still see that the jfr files gets compiled and everything, so the option doesn't appear to do anything. What is the proper way to disable it?
> >
> > Cheers,
> > Mario
> >
> >
> >> It happened that in the meanwhile Azul was also working on preparing
> >> the backport of JFR to jdk8 codebase. We as well have finished the
> >> implementation recently and would like to contribute it to the
> >> community. Our approach and platform coverage is a bit different so
> >> patches are definitely not the same. One might want to compare and
> >> merge somehow to get most of both. We are performing difference
> >> analysis but not yet finished. Will update once we have full
> >> information.
> >> The following is different to your approach:
> >> - We did not add EnableJFR flag, JFR could be used in the same way as
> >> in jdk11
> >> - we have added ?enable-jfr parameter to configure script to control
> >> inclusion of JFR into binary
> >> - -XX:+/-LogJFR VM parameter to control JFR logging (analogous to
> >> -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
> >> - we have removed the ?trace*? build files while adding ?jfr*? files.
> >> We believe such approach makes it easier to backport further jfr
> >> fixes from jdk11+
> >> - we have the following platforms supported: Linux x86, ppc, arm, all
> >> in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64
> >> are supported (Solaris on x86 and sparc have some bugs which are not
> >> resolved yet)
> >> We as well have JFR test suite passed with some limitations coming
> >> from missing VM features (we did not add some missing WhiteBox APIs
> >> so test coverage is a bit smaller than yours)
> >> There might be as well difference in data being supported, e.g. Azul
> >> implementation does not support G1 memory types, while Alibaba seem
> >> to have added missing G1 functionality to get this data
> >>
> >> The webrev is at
> >> http://cr.openjdk.java.net/~apetushkov/jfr8/
> >> Baseline is 8u202.
> >> The changes to aarch64- and aarch32-port projects are delta on top of
> >> generic hotspot patch.
> >> Shenandoah GC is not integrated with JFR. BTW, related question to
> >> RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months,
> >> and latest update level is u181. Does that mean that OpenJDK aarch64-
> >> jdk8u mainline is considered to be hosted in
> >> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos
> >> (where 8u192 is propagated for some time already)? Just in case I?ve
> >> posted integration patches for both repos
> >>
> >> Regards,
> >> Andrey
> >>
> >>
> >> Begin forwarded message:
> >>
> >> From: "guangyu.zhu" <guangyu.zhu at aliyun.com<mailto:
> >> guangyu.zhu at aliyun.com>>
> >> Subject: Re: Proposal for back-porting JFR to OpenJDK8u
> >> Date: January 29, 2019 at 3:41:35 AM PST
> >> To: "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "Mario
> >> Torre" <neugens.limasoftware at gmail.com<mailto:
> >> neugens.limasoftware at gmail.com>>, "jdk8u-dev" <
> >> jdk8u-dev-bounces at openjdk.java.net<mailto:
> >> jdk8u-dev-bounces at openjdk.java.net>>
> >> Cc: yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>,
> >> kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>,
> >> jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
> >> jdk8u-dev at openjdk.java.net>>, denghui.ddh <denghui.ddh at antfin.com<mai
> >> lto:denghui.ddh at antfin.com>>
> >> Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
> >> guangyu.zhu at aliyun.com>>
> >>
> >> Hi there,
> >>
> >> JFR backport patch has been uploaded to cr.openjdk. Please have a
> >> review for the patch.
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
> >> http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/
> >>
> >> The original patch comes from webrev:
> >> http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
> >> . We ported it to jdk8u192-b26 and passed most of the jfr jtreg
> >> tests on Linux/x86-64 platform. Some features related to Module, AOT
> >> and log level are removed because jdk8 does not support them.
> >>
> >> We have added a new option ?EnableJFR? to enable or disable the JFR
> >> feature. It?s disabled by default. To enable it, you can start java
> >> with ?-XX:+EnableJFR?.  For example:
> >> java -XX:+EnableJFR
> >> -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp
> >>
> >> When running the jtreg test, please add the extra option '-vmoption:-
> >> XX:+EnableJFR'. Otherwise the test case will not execute correctly.
> >> Here is an example of running jfr jtreg test:
> >> make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR
> >> TEST=jdk_jfr
> >>
> >> There is one more thing worth noting, please use jmc version 7.0 or
> >> later to open the jfr record file.
> >>
> >> Your suggestions and comments are welcome.
> >>
> >> Thanks,
> >> Guangyu Zhu
> >> ------------------------------------------------------------------
> >> Sender:???(??) <sanhong.lsh at alibaba-inc.com<mailto:
> >> sanhong.lsh at alibaba-inc.com>>
> >> Sent At:2018 Dec. 17 (Mon.) 21:21
> >> Recipient:Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Mario
> >> Torre <neugens.limasoftware at gmail.com<mailto:
> >> neugens.limasoftware at gmail.com>>
> >> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
> >> jdk8u-dev at openjdk.java.net>>
> >> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
> >>
> >> Thanks for comments, we are preparing our internal patches for
> >> webrev.
> >> In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to
> >> produce technical preview build.
> >> Would like to know this... can Martijn point us some guide somewhere?
> >>
> >> Thanks!
> >> Sanhong
> >> -----????-----
> >> ???: Andrew Haley [mailto:aph at redhat.com]
> >> ????: 2018?12?13? 3:03
> >> ???: Mario Torre <neugens.limasoftware at gmail.com<mailto:
> >> neugens.limasoftware at gmail.com>>; ???(??) <
> >> sanhong.lsh at alibaba-inc.com<mailto:sanhong.lsh at alibaba-inc.com>>
> >> ??: Volker Simonis <volker.simonis at gmail.com<mailto:
> >> volker.simonis at gmail.com>>; jdk8u-dev at openjdk.java.net<mailto:
> >> jdk8u-dev at openjdk.java.net>
> >> ??: Re: Proposal for back-porting JFR to OpenJDK8u
> >>
> >> On 12/12/18 1:44 PM, Mario Torre wrote:
> >> I think the first thing to do would be to post the patch for review,
> >> a
> >> shared repository would make the review process a bit more complex I
> >> think, and only makes sense if there is a need to work further on the
> >> patch collectively.
> >>
> >> Yes, exactly. That's the normal process, and it's the best place to
> >> start.
> >>
> >> --
> >> Andrew Haley
> >> Java Platform Lead Engineer
> >> Red Hat UK Ltd. <https://www.redhat.com>
> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >>
> >>
> >>
> >>
> >>
> > --
> > 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 shade at redhat.com  Wed Feb 27 22:46:13 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 27 Feb 2019 23:46:13 +0100
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <88c187ec-0884-9e49-9d81-64be8f356254@redhat.com>

On 2/27/19 3:34 PM, Langer, Christoph wrote:
> 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
> 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457

I think these filters are showing issues that are in 11.0.2 -- those are likely in the base for
11.0.3-oracle? See for example this one: https://bugs.openjdk.java.net/browse/JDK-8208350

-Aleksey



From christoph.langer at sap.com  Wed Feb 27 22:57:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 27 Feb 2019 22:57:41 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <88c187ec-0884-9e49-9d81-64be8f356254@redhat.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <88c187ec-0884-9e49-9d81-64be8f356254@redhat.com>
Message-ID: <b34bdbab58c54f68ad47e8dce67a7ef4@sap.com>

> On 2/27/19 3:34 PM, Langer, Christoph wrote:
> > 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414
> > 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457
> 
> I think these filters are showing issues that are in 11.0.2 -- those are likely in
> the base for
> 11.0.3-oracle? See for example this one:
> https://bugs.openjdk.java.net/browse/JDK-8208350

Good catch. Fixed ??

/Christoph

From xxinliu at amazon.com  Thu Feb 28 00:46:24 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Thu, 28 Feb 2019 00:46:24 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <66bc6229-c5b4-5045-e181-2254a7b5060e@redhat.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
 <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
 <054C7878-C666-4F14-8620-765643B7D456@amazon.com>
 <d20774e2-d996-d716-2f4f-6c5395e5cd3e@redhat.com>
 <CABi63P7BU3YpDJqbDJ6r0Ayw+pZQAk3L7QDFZou+ZVN2ZvF-_A@mail.gmail.com>
 <ED4F2C50-FF5A-4589-B135-2B1CBC96FD0E@amazon.com>
 <66bc6229-c5b4-5045-e181-2254a7b5060e@redhat.com>
Message-ID: <E7BA7700-E3CF-44BF-9BEA-CE4253B3D236@amazon.com>

Thanks for the head-up.

I made new commits which keep original authors and carry-over original reviewers. 
Here it is:
http://cr.openjdk.java.net/~phh/8207258/webrev.8u.02/

Thanks,
--lx


?On 2/27/19, 10:43 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    On 2/27/19 3:46 AM, Liu, Xin wrote:
    > Thanks! Here is a new revision of two backport patches. 
    > http://cr.openjdk.java.net/~phh/8207258/webrev.8u.01/
    
    A minor thing left: webrev seems to overwrite the original metadata.
    
    The original changes have it like below:
    
      # User mullan
      8207258: Distrust TLS server certificates anchored by Symantec Root CAs
      Reviewed-by: weijun
    
      # User mullan
      8216280: Allow later Symantec Policy distrust date for two Apple SubCAs
      Reviewed-by: coffeys
    
    Your change has it as:
    
      # User phh
      8207258: Distrust TLS server certificates anchored by Symantec Root CAs
      Reviewed-by: shade
    
      # User phh
      8216280: Allow later Symantec Policy distrust date for two Apple SubCAs
      Reviewed-by: shade
    
    Please make sure you don't drop the reviewers and original author ("User").
    
    -Aleksey
    
    


From andrey at azul.com  Thu Feb 28 10:10:03 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Thu, 28 Feb 2019 10:10:03 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZLtzyv5=vEs0TPCmbwC5-ZFMwYukY_uAeDOcv5YSs48A@mail.gmail.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <AC9DA9CC-F6E6-404C-93A6-A50752669BB9@azul.com>
 <CAJwKKmZLtzyv5=vEs0TPCmbwC5-ZFMwYukY_uAeDOcv5YSs48A@mail.gmail.com>
Message-ID: <745A09DE-A22B-4887-8C58-247108D4246D@azul.com>

Sorry, no matter how hard I try I cannot repeat this problem :(
If I configure with --disable-jfr there are no JFR-related VM flags, diagnostic commands or beans (checked with command line and JMC). 
So I see no means to initiate JFR dump.
Could you please elaborate what target platform you're building for (I've checked on x86_64) and your exact configure parameters

Andrey

> On 27 Feb 2019, at 20:12, Mario Torre <neugens at redhat.com> wrote:
> 
> On Wed, Feb 27, 2019 at 5:45 PM Andrey Petushkov <andrey at azul.com> wrote:
>> 
>> Hi Mario,
>> 
>> First of all great thank you for the interest and such immediate involvement into this effort.
>> I'm sure it will help to move it faster towards having done and adopted into jdk8u mainline :)
>> 
>> To your particular question, what are the evidence that jfr files get compiled? It's a bit tricky thing hence the question.
>> There are in fact two processes which might or might not happen:
>> - jfr*.cpp files get compiled and linked into libjvm.so. Also JFR classes get compiled and put into jfr.jar.
> 
> Well, the thing is that I tried passing  --disable-jfr and I can dump
> a perfercly functioning JFR file.
> 
> I think the option to not build JFR is not working properly, I can see
> in the config.log that is being registered correctly:
> 
> configure:19778: checking whether to build jfr
> configure:19794: result: false
> 
> However then the same build can produce a JFR file.
> 
> Cheers,
> Mario
> 
> 
>> This should happen only when --enable-jfr is turned on (and yes, it's on by default)
>> - jfr metadata is processed and respective java and c++ classes are generated (into hotspot/linux_amd64_compiler2/generated/tools/jfr,
>> hotspot/linux_amd64_compiler2/generated/jfrfiles and jdk/lib/jfr under the build directory). This in fact happens regardless of whether
>> JFR is enabled or not
>> 
>> So if you only see the latter but don't see any jfr*.o or jfr.jar files that is normal (and that's what I observe with the code I've used to generate webrev from).
>> Otherwise something is wrong. Please let me know what is the case for you
>> 
>> Regarding why it works that way, it's not something I've invented. It's exactly the way JFR gets built in jdk11 codebase. If it's unacceptable I'll work to change it,
>> but please be aware that in order to avoid generation of jfr*.hpp files one would need to put a lot of extra #ifdefs into non-jfr specific files. Which I tried to avoid
>> to keep the code as close to the original as possible (and seeing no value in doing such change, in fact).
>> 
>> Re default value for --enable-jfr, thank you, I've noted that. Will fix
>> 
>> Thanks,
>> Andrey
>> 
>>> On 27 Feb 2019, at 17:00, Mario Torre <neugens at redhat.com> wrote:
>>> 
>>> On Fri, 2019-02-08 at 17:39 +0000, Andrey Petushkov wrote:
>>>> Dear team!
>>> 
>>> Hello Andrey (and everyone else),
>>> 
>>> Some notes first :)
>>> 
>>> I gave a look at both Azul and Alibaba patches, they are obviously very
>>> similar so I went with the latest consensus that is to integrate Azul
>>> patch first and then add some of the missing functionality from what
>>> Alibaba did, I also believe this makes it a tiny bit easier since it
>>> can be considered a progressive delta, however if the opposite is
>>> desired, please let me know.
>>> 
>>> I changed the subject line and cleaned the recipient list to make it a
>>> bit easier to follow the discussion, I expect people interested in this
>>> patch to be subscribed to jdk8u-dev mailing list anyway.
>>> 
>>> I will file a bug report to track the back porting effort, I think we
>>> will need to include the CSR at some point in the process, however I'll
>>> leave this to Andrew Haley as project maintainer, I think for the time
>>> being we can experiment on the incubator branch.
>>> 
>>> Also, we will need to keep this branch updated with latest changes from
>>> the primary repository, it is appreciated if other committers can
>>> participate in this task.
>>> 
>>> Finally, I take this opportunity to thank you and Guangyu and everyone
>>> else involved for those patches and for your patience as well as
>>> understanding regarding the process.
>>> 
>>> Ok, now on with the interesting bits ;)
>>> 
>>> I applied the patch from http://cr.openjdk.java.net/~apetushkov/jfr8/
>>> as described in you email below and compiled everything, --enable-jfr is enabled by default I think this should be disabled by default instead, however, when compiling even if I pass --disable-jfr I still see that the jfr files gets compiled and everything, so the option doesn't appear to do anything. What is the proper way to disable it?
>>> 
>>> Cheers,
>>> Mario
>>> 
>>> 
>>>> It happened that in the meanwhile Azul was also working on preparing
>>>> the backport of JFR to jdk8 codebase. We as well have finished the
>>>> implementation recently and would like to contribute it to the
>>>> community. Our approach and platform coverage is a bit different so
>>>> patches are definitely not the same. One might want to compare and
>>>> merge somehow to get most of both. We are performing difference
>>>> analysis but not yet finished. Will update once we have full
>>>> information.
>>>> The following is different to your approach:
>>>> - We did not add EnableJFR flag, JFR could be used in the same way as
>>>> in jdk11
>>>> - we have added ?enable-jfr parameter to configure script to control
>>>> inclusion of JFR into binary
>>>> - -XX:+/-LogJFR VM parameter to control JFR logging (analogous to
>>>> -Xlog:jfr*=info), with -XX:+Verbose acting like -Xlog:jfr*=trace
>>>> - we have removed the ?trace*? build files while adding ?jfr*? files.
>>>> We believe such approach makes it easier to backport further jfr
>>>> fixes from jdk11+
>>>> - we have the following platforms supported: Linux x86, ppc, arm, all
>>>> in both 32-bit and 64-bit variants. Also Mac and Windows x86 32/64
>>>> are supported (Solaris on x86 and sparc have some bugs which are not
>>>> resolved yet)
>>>> We as well have JFR test suite passed with some limitations coming
>>>> from missing VM features (we did not add some missing WhiteBox APIs
>>>> so test coverage is a bit smaller than yours)
>>>> There might be as well difference in data being supported, e.g. Azul
>>>> implementation does not support G1 memory types, while Alibaba seem
>>>> to have added missing G1 functionality to get this data
>>>> 
>>>> The webrev is at
>>>> http://cr.openjdk.java.net/~apetushkov/jfr8/
>>>> Baseline is 8u202.
>>>> The changes to aarch64- and aarch32-port projects are delta on top of
>>>> generic hotspot patch.
>>>> Shenandoah GC is not integrated with JFR. BTW, related question to
>>>> RedHat, I see that aarch64-port/jdk8u repos are stale for ~5 months,
>>>> and latest update level is u181. Does that mean that OpenJDK aarch64-
>>>> jdk8u mainline is considered to be hosted in
>>>> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ repos
>>>> (where 8u192 is propagated for some time already)? Just in case I?ve
>>>> posted integration patches for both repos
>>>> 
>>>> Regards,
>>>> Andrey
>>>> 
>>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: "guangyu.zhu" <guangyu.zhu at aliyun.com<mailto:
>>>> guangyu.zhu at aliyun.com>>
>>>> Subject: Re: Proposal for back-porting JFR to OpenJDK8u
>>>> Date: January 29, 2019 at 3:41:35 AM PST
>>>> To: "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "Mario
>>>> Torre" <neugens.limasoftware at gmail.com<mailto:
>>>> neugens.limasoftware at gmail.com>>, "jdk8u-dev" <
>>>> jdk8u-dev-bounces at openjdk.java.net<mailto:
>>>> jdk8u-dev-bounces at openjdk.java.net>>
>>>> Cc: yumin qi <yumin.qi at gmail.com<mailto:yumin.qi at gmail.com>>,
>>>> kingsum.chow <kingsum.chow at gmail.com<mailto:kingsum.chow at gmail.com>>,
>>>> jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
>>>> jdk8u-dev at openjdk.java.net>>, denghui.ddh <denghui.ddh at antfin.com<mai
>>>> lto:denghui.ddh at antfin.com>>
>>>> Reply-To: guangyu.zhu <guangyu.zhu at aliyun.com<mailto:
>>>> guangyu.zhu at aliyun.com>>
>>>> 
>>>> Hi there,
>>>> 
>>>> JFR backport patch has been uploaded to cr.openjdk. Please have a
>>>> review for the patch.
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~luchsh/hs_jfr_cr/
>>>> http://cr.openjdk.java.net/~luchsh/jdk_jfr_cr/
>>>> 
>>>> The original patch comes from webrev:
>>>> http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
>>>> . We ported it to jdk8u192-b26 and passed most of the jfr jtreg
>>>> tests on Linux/x86-64 platform. Some features related to Module, AOT
>>>> and log level are removed because jdk8 does not support them.
>>>> 
>>>> We have added a new option ?EnableJFR? to enable or disable the JFR
>>>> feature. It?s disabled by default. To enable it, you can start java
>>>> with ?-XX:+EnableJFR?.  For example:
>>>> java -XX:+EnableJFR
>>>> -XX:StartFlightRecording=duration=1m,filename=rec.jfr MyApp
>>>> 
>>>> When running the jtreg test, please add the extra option '-vmoption:-
>>>> XX:+EnableJFR'. Otherwise the test case will not execute correctly.
>>>> Here is an example of running jfr jtreg test:
>>>> make test JTREG_TEST_EXTRA_OPTIONS=-vmoption:-XX:+EnableJFR
>>>> TEST=jdk_jfr
>>>> 
>>>> There is one more thing worth noting, please use jmc version 7.0 or
>>>> later to open the jfr record file.
>>>> 
>>>> Your suggestions and comments are welcome.
>>>> 
>>>> Thanks,
>>>> Guangyu Zhu
>>>> ------------------------------------------------------------------
>>>> Sender:???(??) <sanhong.lsh at alibaba-inc.com<mailto:
>>>> sanhong.lsh at alibaba-inc.com>>
>>>> Sent At:2018 Dec. 17 (Mon.) 21:21
>>>> Recipient:Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Mario
>>>> Torre <neugens.limasoftware at gmail.com<mailto:
>>>> neugens.limasoftware at gmail.com>>
>>>> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:
>>>> jdk8u-dev at openjdk.java.net>>
>>>> Subject:Re: Proposal for back-porting JFR to OpenJDK8u
>>>> 
>>>> Thanks for comments, we are preparing our internal patches for
>>>> webrev.
>>>> In the meantime, Martijn/ Andrew mentioned we can use AdoptOpenJDK to
>>>> produce technical preview build.
>>>> Would like to know this... can Martijn point us some guide somewhere?
>>>> 
>>>> Thanks!
>>>> Sanhong
>>>> -----????-----
>>>> ???: Andrew Haley [mailto:aph at redhat.com]
>>>> ????: 2018?12?13? 3:03
>>>> ???: Mario Torre <neugens.limasoftware at gmail.com<mailto:
>>>> neugens.limasoftware at gmail.com>>; ???(??) <
>>>> sanhong.lsh at alibaba-inc.com<mailto:sanhong.lsh at alibaba-inc.com>>
>>>> ??: Volker Simonis <volker.simonis at gmail.com<mailto:
>>>> volker.simonis at gmail.com>>; jdk8u-dev at openjdk.java.net<mailto:
>>>> jdk8u-dev at openjdk.java.net>
>>>> ??: Re: Proposal for back-porting JFR to OpenJDK8u
>>>> 
>>>> On 12/12/18 1:44 PM, Mario Torre wrote:
>>>> I think the first thing to do would be to post the patch for review,
>>>> a
>>>> shared repository would make the review process a bit more complex I
>>>> think, and only makes sense if there is a need to work further on the
>>>> patch collectively.
>>>> 
>>>> Yes, exactly. That's the normal process, and it's the best place to
>>>> start.
>>>> 
>>>> --
>>>> Andrew Haley
>>>> Java Platform Lead Engineer
>>>> Red Hat UK Ltd. <https://www.redhat.com>
>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> --
>>> 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 deepak.kejriwal at oracle.com  Thu Feb 28 11:12:55 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Thu, 28 Feb 2019 03:12:55 -0800 (PST)
Subject: [8u-dev] Request for Approval: Backport of JDK-8202088, JDK-8207152, 
 JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
Message-ID: <93782021-9223-428c-93d6-63d314c2d7ad@default>

Hi All,

 

Please approve the backport of following bugs to 8u-dev.

 

JDK-8202088 : Japanese new era implementation

JDK-8207152 : Placeholder for Japanese new era should be two characters

JDK-8211398 : Square character support for the Japanese new era

JDK-8180469 : Wrong short form text for supplemental Japanese era

JDK-8206120 : Add test cases for lenient Japanese era parsing

JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points

JDK-8217710 : Add 5 currency code points to Java SE 8uX

 

JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058595.html

 

All the related testing is done and is a pass.

 

Regards,

Deepak

 

From hohensee at amazon.com  Thu Feb 28 12:04:07 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 28 Feb 2019 12:04:07 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8202088,
 JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <93782021-9223-428c-93d6-63d314c2d7ad@default>
References: <93782021-9223-428c-93d6-63d314c2d7ad@default>
Message-ID: <E902572D-025E-44A0-8DED-31359D84B8D5@amazon.com>

I added the 'jdk8u-fix-request' tag to these issues.

Paul

?On 2/28/19, 3:13 AM, "core-libs-dev on behalf of Deepak Kejriwal" <core-libs-dev-bounces at openjdk.java.net on behalf of deepak.kejriwal at oracle.com> wrote:

    Hi All,
    
     
    
    Please approve the backport of following bugs to 8u-dev.
    
     
    
    JDK-8202088 : Japanese new era implementation
    
    JDK-8207152 : Placeholder for Japanese new era should be two characters
    
    JDK-8211398 : Square character support for the Japanese new era
    
    JDK-8180469 : Wrong short form text for supplemental Japanese era
    
    JDK-8206120 : Add test cases for lenient Japanese era parsing
    
    JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
    
    JDK-8217710 : Add 5 currency code points to Java SE 8uX
    
     
    
    JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058595.html
    
     
    
    All the related testing is done and is a pass.
    
     
    
    Regards,
    
    Deepak
    
     
    


From sean.coffey at oracle.com  Thu Feb 28 12:09:43 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 28 Feb 2019 12:09:43 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8202088,
 JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <E902572D-025E-44A0-8DED-31359D84B8D5@amazon.com>
References: <93782021-9223-428c-93d6-63d314c2d7ad@default>
 <E902572D-025E-44A0-8DED-31359D84B8D5@amazon.com>
Message-ID: <2423c346-1d2f-60b8-4b63-cc6a25d801c6@oracle.com>

Thanks Paul.

Andrew - can the JDK 8 Updates Project page be updated to reflect the 
process required for pushing fixes ?

regards,
Sean.

On 28/02/2019 12:04, Hohensee, Paul wrote:
> I added the 'jdk8u-fix-request' tag to these issues.
>
> Paul
>
> ?On 2/28/19, 3:13 AM, "core-libs-dev on behalf of Deepak Kejriwal" <core-libs-dev-bounces at openjdk.java.net on behalf of deepak.kejriwal at oracle.com> wrote:
>
>      Hi All,
>      
>       
>      
>      Please approve the backport of following bugs to 8u-dev.
>      
>       
>      
>      JDK-8202088 : Japanese new era implementation
>      
>      JDK-8207152 : Placeholder for Japanese new era should be two characters
>      
>      JDK-8211398 : Square character support for the Japanese new era
>      
>      JDK-8180469 : Wrong short form text for supplemental Japanese era
>      
>      JDK-8206120 : Add test cases for lenient Japanese era parsing
>      
>      JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points
>      
>      JDK-8217710 : Add 5 currency code points to Java SE 8uX
>      
>       
>      
>      JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058595.html
>      
>       
>      
>      All the related testing is done and is a pass.
>      
>       
>      
>      Regards,
>      
>      Deepak
>      
>       
>      
>

From neugens at redhat.com  Thu Feb 28 13:34:06 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 28 Feb 2019 14:34:06 +0100
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <745A09DE-A22B-4887-8C58-247108D4246D@azul.com>
References: <EAAAAE24-7DCA-4AD8-A447-545898E43B5D@azul.com>
 <4B92F10E-FE9B-4261-8F5A-9A46503C238C@azul.com>
 <9B98122E-94F0-4614-94C8-4DF926DECD49@azul.com>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <AC9DA9CC-F6E6-404C-93A6-A50752669BB9@azul.com>
 <CAJwKKmZLtzyv5=vEs0TPCmbwC5-ZFMwYukY_uAeDOcv5YSs48A@mail.gmail.com>
 <745A09DE-A22B-4887-8C58-247108D4246D@azul.com>
Message-ID: <7d83a9cc9b940651607353eac93cefbc69364eff.camel@redhat.com>

On Thu, 2019-02-28 at 10:10 +0000, Andrey Petushkov wrote:
> Sorry, no matter how hard I try I cannot repeat this problem :(
> If I configure with --disable-jfr there are no JFR-related VM flags,
> diagnostic commands or beans (checked with command line and JMC). 
> So I see no means to initiate JFR dump.
> Could you please elaborate what target platform you're building for
> (I've checked on x86_64) and your exact configure parameters

This is interesting.

So, my system is a Fedora 28, x86_64, at this moment, I'm using this
configure:

$ sh configure --with-extra-cflags=-Wno-error --disable-jfr

The configure picks up the option correct as far as I can see
(config.log):

ENABLE_JFR='false'

If you can't replicate it, it's likely something wrong I'm doing, so
let's step back a second and see what's the full process.

I take the patches from here:
http://cr.openjdk.java.net/~apetushkov/jfr8/

And apply them in order:

jdk8u-jfr-incubator/zulu8-emb-dev.patch
jdk8u-jfr-incubator/jdk/jdk.patch
jdk8u-jfr-incubator/hotpost/hotspot.patch

I didn't apply the others as at this moment I'm not building any of
those targets, the patches don't contain any build related changes
anyway.

After that, I invoke my configure script, at this point no matter if I
pass  --disable-jfr or --enable-jfr I still end up with a full JFR
build.

What steps am I missing?

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 aph at redhat.com  Thu Feb 28 14:12:51 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 Feb 2019 14:12:51 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8202088,
 JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
In-Reply-To: <2423c346-1d2f-60b8-4b63-cc6a25d801c6@oracle.com>
References: <93782021-9223-428c-93d6-63d314c2d7ad@default>
 <E902572D-025E-44A0-8DED-31359D84B8D5@amazon.com>
 <2423c346-1d2f-60b8-4b63-cc6a25d801c6@oracle.com>
Message-ID: <7f4ff787-2ae8-f978-b953-cf6f7bbf0f8b@redhat.com>

On 2/28/19 12:09 PM, Se?n Coffey wrote:
> Andrew - can the JDK 8 Updates Project page be updated to reflect the 
> process required for pushing fixes ?

Of course! It's just that I'm overwhelmed with the task of reviewing
backports. In the meantime, the process is at

https://openjdk.java.net/projects/jdk-updates/approval.html

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

From shade at redhat.com  Thu Feb 28 20:05:48 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 28 Feb 2019 21:05:48 +0100
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>

On 2/27/19 3:34 PM, Langer, Christoph wrote:
> after putting some more efforts into my issue filters for jdk-updates projects, here is a current
> list of the available ones. It might be of value to some folks? As always: You need to be logged
> in to JBS, otherwise these won?t work.
Yes, so people complain (at least to Christoph and me) about the need to have a login to execute
complex JIRA queries. It is minor nuisance for OpenJDK Authors/Committers/Reviewers, but outsiders
are completely deprived of looking at those reports.

What can we do about that? We can dump the filter outputs regularly. For example, see filter-* here:
  https://builds.shipilev.net/backports-monitor/

-Aleksey


From goetz.lindenmaier at sap.com  Thu Feb 28 20:43:48 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 28 Feb 2019 20:43:48 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>
Message-ID: <VI1PR02MB5183F4CC92D712B0636D6B56EC750@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi Aleksey, 

This is really cool ?? !

Cheers,
  Goetz.

(I'm second after you in 11.0.3 pushes ??)

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Thursday, February 28, 2019 9:06 PM
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: JBS Filters for JDK update work
> 
> On 2/27/19 3:34 PM, Langer, Christoph wrote:
> > after putting some more efforts into my issue filters for jdk-updates
> projects, here is a current
> > list of the available ones. It might be of value to some folks? As always: You
> need to be logged
> > in to JBS, otherwise these won?t work.
> Yes, so people complain (at least to Christoph and me) about the need to
> have a login to execute
> complex JIRA queries. It is minor nuisance for OpenJDK
> Authors/Committers/Reviewers, but outsiders
> are completely deprived of looking at those reports.
> 
> What can we do about that? We can dump the filter outputs regularly. For
> example, see filter-* here:
>   https://builds.shipilev.net/backports-monitor/
> 
> -Aleksey


From xxinliu at amazon.com  Wed Feb 27 02:46:17 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 27 Feb 2019 02:46:17 +0000
Subject: [8u] Request for enhancement backport approval for CR 8207258-
 Distrust TLS server certificates anchored by Symantec Root CAs
In-Reply-To: <CABi63P7BU3YpDJqbDJ6r0Ayw+pZQAk3L7QDFZou+ZVN2ZvF-_A@mail.gmail.com>
References: <56815B57-59D5-44DB-8688-45C2F3F993CF@amazon.com>
 <5f0f5a48-2cbe-2b06-9664-2ecf82ac3eef@redhat.com>
 <CABi63P7-0mrE-hRdn7WCN_jnPm=c0_CEscF4yYDYz7JOpz3BoA@mail.gmail.com>
 <054C7878-C666-4F14-8620-765643B7D456@amazon.com>
 <d20774e2-d996-d716-2f4f-6c5395e5cd3e@redhat.com>
 <CABi63P7BU3YpDJqbDJ6r0Ayw+pZQAk3L7QDFZou+ZVN2ZvF-_A@mail.gmail.com>
Message-ID: <ED4F2C50-FF5A-4589-B135-2B1CBC96FD0E@amazon.com>

Hi, Andrew and Aleksey, 

Thanks! Here is a new revision of two backport patches. 
http://cr.openjdk.java.net/~phh/8207258/webrev.8u.01/

Delete irrelevant code change, fix the indents and pass jcheck. 
Thanks,
--lx


?On 2/26/19, 12:58 PM, "Andrew Hughes" <gnu.andrew at redhat.com> wrote:

    On Tue, 26 Feb 2019 at 18:12, Aleksey Shipilev <shade at redhat.com> wrote:
    >
    > On 2/26/19 7:04 PM, Liu, Xin wrote:
    > > When I backport , I always wonder if I shall keep backport patch as intact as possible or piggyback tide-up code?
    >
    > Keep it intact as much as possible.
    >
    > Cleanups can and should follow up as the patch in dev, and then trickle down as backports, if needed.
    >
    > -Aleksey
    >
    >
    
    For backports, apply the patch as is. If you find it depends on
    changes in earlier fixes, backport those
    first. Unless they are trivial, this should be in their own
    changesets. Either way, make sure to include
    the bug IDs of all changes backported for tracking purposes. Some of
    the more annoying cases I've
    found when backporting are where you are trying to apply a fix which
    doesn't appear to be there, and it
    fails, only to find that this is because the changes are there, but
    under the auspices of a completely
    different bug.
    
    In short, hg log -k <bug ID> should work for every backported bug.
    
    As to jcheck, it hooks into your Mercurial setup and runs during
    commit. You can use this to catch
    issues at the stage, rather than when you push and the server runs
    jcheck, rejecting your push.
    
    https://openjdk.java.net/projects/code-tools/jcheck/
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    Web Site: http://fuseyism.com
    Twitter: https://twitter.com/gnu_andrew_java
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    


From philip.m.jones at siemens.com  Thu Feb 28 21:01:15 2019
From: philip.m.jones at siemens.com (Jones, Philip)
Date: Thu, 28 Feb 2019 21:01:15 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <VI1PR02MB5183F4CC92D712B0636D6B56EC750@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <6b11c0da-d7ce-51fc-46d0-5ec3d0a78529@redhat.com>
 <VI1PR02MB5183F4CC92D712B0636D6B56EC750@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <3C3FEEEFE127B940BB0F5FADB28060412850DF93@DEKOMMBX001.net.plm.eds.com>

Thanks to all for the effort in this. I was one of the complainers and that is very useful output.

Philip

-----Original Message-----
From: jdk-updates-dev [mailto:jdk-updates-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: 28 February 2019 20:44
To: 'Aleksey Shipilev' <shade at redhat.com>; Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
Subject: RE: JBS Filters for JDK update work

Hi Aleksey,

This is really cool ?? !

Cheers,
  Goetz.

(I'm second after you in 11.0.3 pushes ??)

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Thursday, February 28, 2019 9:06 PM
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: JBS Filters for JDK update work
>
> On 2/27/19 3:34 PM, Langer, Christoph wrote:
> > after putting some more efforts into my issue filters for
> > jdk-updates
> projects, here is a current
> > list of the available ones. It might be of value to some folks? As
> > always: You
> need to be logged
> > in to JBS, otherwise these won?t work.
> Yes, so people complain (at least to Christoph and me) about the need
> to have a login to execute complex JIRA queries. It is minor nuisance
> for OpenJDK Authors/Committers/Reviewers, but outsiders are completely
> deprived of looking at those reports.
>
> What can we do about that? We can dump the filter outputs regularly.
> For example, see filter-* here:
>   https://builds.shipilev.net/backports-monitor/
>
> -Aleksey

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.