From goetz.lindenmaier at sap.com  Fri Mar  1 06:49:37 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 1 Mar 2019 06:49:37 +0000
Subject: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
 generation.
Message-ID: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi, 

please review this tiny fix for OpenJDK 8.
If an agent is specified, the VM does not start on ppc64.
The space for the template interpreter does not suffice any more.
http://cr.openjdk.java.net/~goetz/wr19/8219961-ppc64_interpreter_8/01/

Best regards,
  Goetz.


From christoph.langer at sap.com  Fri Mar  1 08:11:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 1 Mar 2019 08:11:27 +0000
Subject: JBS Filters for JDK update work
In-Reply-To: <5c897bc2d8e51bf79126136f586651f5@linux.vnet.ibm.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
 <5c897bc2d8e51bf79126136f586651f5@linux.vnet.ibm.com>
Message-ID: <60a488357aa9427d8fb43774a6c8a14e@sap.com>

Hi Ichiroh,

thanks for this hint. I fixed it and I also added views for rejected requests:

8u: https://bugs.openjdk.java.net/issues/?filter=36465 
11u: https://bugs.openjdk.java.net/issues/?filter=36466 
12u: https://bugs.openjdk.java.net/issues/?filter=36467 

Best regards
Christoph

> -----Original Message-----
> From: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> Sent: Freitag, 1. M?rz 2019 06:59
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: Re: JBS Filters for JDK update work
> 
> Hello Langer.
> 
> About "Unapproved requests", it's better to use following search text.
>    labels = jdk11u-fix-request AND labels not in (jdk11u-fix-no,
> jdk11u-fix-yes)
> On current query, 2 jdk11u-fix-no are there, they are always displayed.
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-02-27 23:34, 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
> >
> > 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 christoph.langer at sap.com  Fri Mar  1 10:43:54 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 1 Mar 2019 10:43:54 +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: <7f4ff787-2ae8-f978-b953-cf6f7bbf0f8b@redhat.com>
References: <93782021-9223-428c-93d6-63d314c2d7ad@default>
 <E902572D-025E-44A0-8DED-31359D84B8D5@amazon.com>
 <2423c346-1d2f-60b8-4b63-cc6a25d801c6@oracle.com>
 <7f4ff787-2ae8-f978-b953-cf6f7bbf0f8b@redhat.com>
Message-ID: <7656e192b4714efc9e15745d2a38eab1@sap.com>

Hi Andrew,

I've seen that you have approved JDK-8218915 yesterday for jdk8u.

However, you'll have to approve all of the mentioned items in the subject line because they'll all be fixed with the one commit that Se?n will (hopefully) do.

Best regards
Christoph

From deepak.kejriwal at oracle.com  Fri Mar  1 10:44:00 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Fri, 1 Mar 2019 02:44:00 -0800 (PST)
Subject: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by
 java.text.SimpleDateFormat
Message-ID: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>

Hi All,

 

Please review the back port of fix for JDK-8217609 to 8u-dev:-

 

JBS report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.openjdk.java.net/browse/JDK- 8217609

Webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/

Master bug change set:  http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17

Summary:
Fix is backported from JDK 13 to JDK 8u and is not a clean backport. Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses version 33. Below are the differences between 8u and 13:- 

.         The "jp.xml" version of JDK 8u does not contains "<eraNarrow>" node (<calendar type=japanese">). Therefore "<era type="236">N</era>" which is part of fix is not added to file.

.         I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java"  for JDK 8u.  It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)"

o   The  test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..).

o   The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras".  The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u.

Regards,

Deepak

 

From guangyu.zhu at aliyun.com  Fri Mar  1 11:59:55 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Fri, 01 Mar 2019 19:59:55 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <7d83a9cc9b940651607353eac93cefbc69364eff.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>	
 <AC9DA9CC-F6E6-404C-93A6-A50752669BB9@azul.com>	
 <CAJwKKmZLtzyv5=vEs0TPCmbwC5-ZFMwYukY_uAeDOcv5YSs48A@mail.gmail.com>	
 <745A09DE-A22B-4887-8C58-247108D4246D@azul.com>,
 <7d83a9cc9b940651607353eac93cefbc69364eff.camel@redhat.com>
Message-ID: <51eb858a-df2b-4d54-a450-a5de5bd64d3f.guangyu.zhu@aliyun.com>

To verify the "disabled" parameter, I just tried "./configure --disable-jfr" and then "make" jvm in a docker on x86-64 linux. Using the image, I can't start java with "-XX:StartFlightRecording = xxx", and also can't start JFR with jcmd. Hope this can help.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Mario Torre <neugens at redhat.com>
Sent At:2019 Feb. 28 (Thu.) 21:34
Recipient:Andrey Petushkov <andrey at azul.com>
Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

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 guangyu.zhu at aliyun.com  Fri Mar  1 12:38:33 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Fri, 01 Mar 2019 20:38:33 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
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: <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>

Hi Mario, Andrey

Very happy to see things moving forward. Some of my updates:

As Andrey and I both agreed, in order not to waste resources, Alibaba will be responsible for merging the missing features. The work is in progress, my colleague Denghui and I are working on below tasks.

- thread sampling. [code completed, under testing]
- biased locking events [code completed, under testing]
- G1 heap summary and region types  [not started yet]
- -XX:+/-EnableJFR run time flag [not started yet]

For the first three missing features, once we complete the coding and testing, we will send out webrev. For the last one, we added an 'EnableJFR' flag to enable or disable JFR functionality at runtime. Jdk11 does not have such a runtime flag. So we didn't start working right away, we want to hear the opinions of the community first.

There is one thing we think should be mentioned. Azul's patch removes the trace feature (JEP 167: Event-based JVM tracing, am I correct?) and replaces it with jfr, which is the same as jdk11. I am not sure if anyone is relying on the original trace feature. Maybe we should keep it. What do you think?

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Mario Torre <neugens at redhat.com>
Sent At:2019 Feb. 28 (Thu.) 00:00
Recipient:Andrey Petushkov <andrey at azul.com>; guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:[Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

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 neugens at redhat.com  Fri Mar  1 12:59:48 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 1 Mar 2019 13:59:48 +0100
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
Message-ID: <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>

On Fri, Mar 1, 2019 at 1:38 PM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>
> Hi Mario, Andrey
>
> Very happy to see things moving forward. Some of my updates:

Thanks for your work and help!

> As Andrey and I both agreed, in order not to waste resources, Alibaba will be responsible for merging the missing features. The work is in progress, my colleague Denghui and I are working on below tasks.
>
> - thread sampling. [code completed, under testing]
> - biased locking events [code completed, under testing]
> - G1 heap summary and region types  [not started yet]
> - -XX:+/-EnableJFR run time flag [not started yet]
>
> For the first three missing features, once we complete the coding and testing, we will send out webrev. For the last one, we added an 'EnableJFR' flag to enable or disable JFR functionality at runtime. Jdk11 does not have such a runtime flag. So we didn't start working right away, we want to hear the opinions of the community first.

I don't think we should diverge in any way from the other versions
unless necessary. For 8u-dev I would like to follow what Oracle did on
their VM, with the usual pack of -XX:+UnlockCommercialFeatures
-XX:+FlightRecorder -XX:StartFlightRecording=xxx options.

I know -XX:+UnlockCommercialFeatures isn't necessary in our case, but
it should be there for compatibility. I would be ok if the option
didn't do anything but was just there as to not crash the VM at
startup when someone was migrating from one downstream version to the
other. Of course, it can be said that -XX:+UnlockCommercialFeatures in
OpenJDK currently doesn't exist and is deprecated in later versions
anyway, so I defer to Andrew Haley regarding this specific point if he
has a strong opinion of not introducing the option at all.

Regarding +EnableJFR as a runtime flag, my take is that
-XX:+FlightRecorder -XX:StartFlightRecording are already doing the
same.

> There is one thing we think should be mentioned. Azul's patch removes the trace feature (JEP 167: Event-based JVM tracing, am I correct?) and replaces it with jfr, which is the same as jdk11. I am not sure if anyone is relying on the original trace feature. Maybe we should keep it. What do you think?

I'm going through the patch right now, but yes, from what I see the
trace is removed. I had too a concern about this and was about to send
a note. I'm not quite sure what to do, because Trace has been removed
in 11 as far as I know, but removing mid stream in 8 may be a more
interesting issue, however this isn't a user facing API, it was always
meant to be internal to the JVM, so I don't quite know if there's
really a reason we shouldn't change it. This is one question for the
CSR group I 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 aph at redhat.com  Fri Mar  1 14:45:30 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 1 Mar 2019 14:45:30 +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: <45f0e8be-3fa3-ea3c-a3ae-61b76c0bcc6d@redhat.com>

On 2/28/19 12:04 PM, Hohensee, Paul wrote:
> I added the 'jdk8u-fix-request' tag to these issues.

All should now be 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 Mar  1 14:46:07 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 1 Mar 2019 14:46:07 +0000
Subject: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
 generation.
In-Reply-To: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <e3040d0c-90f3-f35f-c493-48afc14c0244@redhat.com>

On 3/1/19 6:49 AM, Lindenmaier, Goetz wrote:
> If an agent is specified, the VM does not start on ppc64.
> The space for the template interpreter does not suffice any more.
> http://cr.openjdk.java.net/~goetz/wr19/8219961-ppc64_interpreter_8/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 dcherepanov at azul.com  Fri Mar  1 14:56:24 2019
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Fri, 1 Mar 2019 14:56:24 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source tree
Message-ID: <EE64E227-CF50-4D02-A1F7-919506E4AC82@azul.com>

Please review/approve the backport of 8170681 to 8u-dev

JBS: https://bugs.openjdk.java.net/browse/JDK-8170681
Webrev (root repo): http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.root/
Webrev (jdk repo): http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jdk/

The original patch doesn't apply cleanly to 8u-dev so it includes the following modifications
 - In 9, the fix for JDK-8138761 includes refactoring that splits libraries.m4 into several files (file per tool). For 8u-dev, the backport patch updates the existing libraries.m4 for consistency.
 - The original patch removes fontconfig.md with fontconfig license entry. For 8u-dev, the backport patch updates THIRD_PARTY_README files (for all repos).

Testing - repo with the patch builds on Windows/Mac. Also tested it on CentOS with and without fontconfig-devel installed.

Thanks,

Dmitry


From gnu.andrew at redhat.com  Fri Mar  1 15:39:27 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 1 Mar 2019 15:39:27 +0000
Subject: RFR: JDK8U Backport of 8217609: New era placeholder not
 recognized by java.text.SimpleDateFormat
In-Reply-To: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
Message-ID: <CABi63P7ztHHLqF=SYL9m28UQGk+RgzTYTd8FRLPycYKT9Uhu_g@mail.gmail.com>

On Fri, 1 Mar 2019 at 10:47, Deepak Kejriwal <deepak.kejriwal at oracle.com> wrote:
>
> Hi All,
>
>
>
> Please review the back port of fix for JDK-8217609 to 8u-dev:-
>
>
>
> JBS report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.openjdk.java.net/browse/JDK- 8217609
>
> Webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/
>
> Master bug change set:  http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17
>
> Summary:
> Fix is backported from JDK 13 to JDK 8u and is not a clean backport. Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses version 33. Below are the differences between 8u and 13:-
>
> .         The "jp.xml" version of JDK 8u does not contains "<eraNarrow>" node (<calendar type=japanese">). Therefore "<era type="236">N</era>" which is part of fix is not added to file.
>
> .         I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java"  for JDK 8u.  It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)"
>
> o   The  test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..).
>
> o   The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras".  The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u.
>
> Regards,
>
> Deepak
>
>

Patch looks good to me.

Is there a bug/patch to backport to fix the CLDR converter in OpenJDK
8, so japanese.long.Eras are included?

JDK-8217609 should have the label 'jdk8u-fix-request' added so it can
be approved for 8u.

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 sgehwolf at redhat.com  Fri Mar  1 16:10:56 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 01 Mar 2019 17:10:56 +0100
Subject: [8u] RFR: 8195153: [test] runtime/6981737/Test6981737.java
 shouldn't check 'java.vendor' and 'java.vm.vendor' properties
Message-ID: <017a668fe502ff2dd816d9a595e35d1d6f384b8e.camel@redhat.com>

Hi,

Could somebody please review this 8u backport for a test which checks
the java.vendor and java.vm.vendor property? The JDK 8 patch is the
same as JDK 10's version modulo contextual changes and reshuffeling.

the JDK 10 patch does not apply cleanly because there is no
Runtime.version() in JDK 8 (that is part of the patch context).

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

Testing: Test fails with AdoptOpenJDK's JDK 8 build, and passes after
the fix.

Thanks,
Severin


From naoto.sato at oracle.com  Fri Mar  1 17:37:25 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 1 Mar 2019 09:37:25 -0800
Subject: RFR: JDK8U Backport of 8217609: New era placeholder not
 recognized by java.text.SimpleDateFormat
In-Reply-To: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
Message-ID: <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com>

Hi Deepak,

A few comments on the JapaneseEraNameTest:

- Please indent code blocks accordingly, i.e., names object declaration 
(line 47-51), for loop in the main() (line 56,59,60).

- If you are commenting out the case for LONG, please address the reason 
with the comment (the following explanation will do)

- If the above issue is specific to 8u, and not related to the new era, 
file a separate issue for 8u.

Naoto

On 3/1/19 2:44 AM, Deepak Kejriwal wrote:
> Hi All,
> 
>   
> 
> Please review the back port of fix for JDK-8217609 to 8u-dev:-
> 
>   
> 
> JBS report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.openjdk.java.net/browse/JDK- 8217609
> 
> Webrev: http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/
> 
> Master bug change set:  http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17
> 
> Summary:
> Fix is backported from JDK 13 to JDK 8u and is not a clean backport. Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses version 33. Below are the differences between 8u and 13:-
> 
> .         The "jp.xml" version of JDK 8u does not contains "<eraNarrow>" node (<calendar type=japanese">). Therefore "<era type="236">N</era>" which is part of fix is not added to file.
> 
> .         I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java"  for JDK 8u.  It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)"
> 
> o   The  test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..).
> 
> o   The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras".  The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u.
> 
> Regards,
> 
> Deepak
> 
>   
> 

From andrey at azul.com  Fri Mar  1 19:09:46 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Fri, 1 Mar 2019 19:09:46 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
Message-ID: <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>

Hi guys,

> On 1 Mar 2019, at 15:59, Mario Torre <neugens at redhat.com> wrote:
> 
> On Fri, Mar 1, 2019 at 1:38 PM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>> 
>> Hi Mario, Andrey
>> 
>> Very happy to see things moving forward. Some of my updates:
> 
> Thanks for your work and help!
> 
>> As Andrey and I both agreed, in order not to waste resources, Alibaba will be responsible for merging the missing features. The work is in progress, my colleague Denghui and I are working on below tasks.
>> 
>> - thread sampling. [code completed, under testing]
>> - biased locking events [code completed, under testing]
That's great! Thank you!
>> - G1 heap summary and region types  [not started yet]
>> - -XX:+/-EnableJFR run time flag [not started yet]
>> 
>> For the first three missing features, once we complete the coding and testing, we will send out webrev. For the last one, we added an 'EnableJFR' flag to enable or disable JFR functionality at runtime. Jdk11 does not have such a runtime flag. So we didn't start working right away, we want to hear the opinions of the community first.
> 
> I don't think we should diverge in any way from the other versions
> unless necessary. For 8u-dev I would like to follow what Oracle did on
> their VM, with the usual pack of -XX:+UnlockCommercialFeatures
> -XX:+FlightRecorder -XX:StartFlightRecording=xxx options.
> 
> I know -XX:+UnlockCommercialFeatures isn't necessary in our case, but
> it should be there for compatibility. I would be ok if the option
> didn't do anything but was just there as to not crash the VM at
> startup when someone was migrating from one downstream version to the
> other. Of course, it can be said that -XX:+UnlockCommercialFeatures in
> OpenJDK currently doesn't exist and is deprecated in later versions
> anyway, so I defer to Andrew Haley regarding this specific point if he
> has a strong opinion of not introducing the option at all.
I fully agree that UnlockCommercialFeatures flag should be left for compatibility. That's exactly
what I have done, added it with a help text that this is the only purpose. In fact without it
one cannot use JMC with jdk8, JMC has built-in knowledge about necessity to specify
this flag if it deals with version 8
> 
> Regarding +EnableJFR as a runtime flag, my take is that
> -XX:+FlightRecorder -XX:StartFlightRecording are already doing the
> same.
Agree. Also, having another flag which is false by default will prevent from using typical procedure
to connect JMC to such JFR implementation. One would need to either EnableJFR with command line
or management interface beforehand
> 
>> There is one thing we think should be mentioned. Azul's patch removes the trace feature (JEP 167: Event-based JVM tracing, am I correct?) and replaces it with jfr, which is the same as jdk11. I am not sure if anyone is relying on the original trace feature. Maybe we should keep it. What do you think?
> 
> I'm going through the patch right now, but yes, from what I see the
> trace is removed. I had too a concern about this and was about to send
> a note. I'm not quite sure what to do, because Trace has been removed
> in 11 as far as I know, but removing mid stream in 8 may be a more
> interesting issue, however this isn't a user facing API, it was always
> meant to be internal to the JVM, so I don't quite know if there's
> really a reason we shouldn't change it. This is one question for the
> CSR group I think.
Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace 
was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
I will be happy to return it back

Thanks,
Andrey
> 
> 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  Fri Mar  1 19:21:08 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 1 Mar 2019 19:21:08 +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: <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>

On Tue, 26 Feb 2019 at 21:41, Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> 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?

I can live with that. I'm a bit nervous about pushing changes to jdk8u
before jdk8u-dev, but as long as it is tested regularly and integrated
back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet?

On your final point, the -ga tag will be the point at which we branch
+ the private CPU changes (which will be smaller than the batches
Oracle pushed, as we are only keeping private those that are
embargoed, not the entire release set). This is why I suggest we
declare the branch frozen at the point we use as a base internally, so
there are not changes between the baseline for the CPU and when we
push upstream. Tagging -ga after a merge would represent something
different from what we have already based our update binaries on.

The tagging is no different from the way things worked under Oracle;
they also tagged what their binaries were built from, not the point it
was merged. Where I hope we can be more open is in making it clear
what our base looks like for these CPU patches, and those within the
vulnerability group should be able to replicate the same thing for
their own pre-embargo binaries.

>
> > 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...??

Ok, I guess once we have the changes tagged in a repository, people
can do their testing and report issues.

>
> > 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.

Sounds good.

>
> Best regards
> Christoph
>

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  Fri Mar  1 19:46:01 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 1 Mar 2019 19:46:01 +0000
Subject: [8u] RFR: 8195153: [test] runtime/6981737/Test6981737.java
 shouldn't check 'java.vendor' and 'java.vm.vendor' properties
In-Reply-To: <017a668fe502ff2dd816d9a595e35d1d6f384b8e.camel@redhat.com>
References: <017a668fe502ff2dd816d9a595e35d1d6f384b8e.camel@redhat.com>
Message-ID: <CABi63P7R3mWQHRLXmO0cnzXUo1_qE5LRMYvbKc+Qf7HFH_siBw@mail.gmail.com>

On Fri, 1 Mar 2019 at 16:12, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi,
>
> Could somebody please review this 8u backport for a test which checks
> the java.vendor and java.vm.vendor property? The JDK 8 patch is the
> same as JDK 10's version modulo contextual changes and reshuffeling.
>
> the JDK 10 patch does not apply cleanly because there is no
> Runtime.version() in JDK 8 (that is part of the patch context).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195153
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8195153/jdk8/01/webrev/
>
> Testing: Test fails with AdoptOpenJDK's JDK 8 build, and passes after
> the fix.
>
> Thanks,
> Severin
>

Looks good to me.

I think we also need https://bugs.openjdk.java.net/browse/JDK-8189761 to make
this really worthwhile.

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  Mon Mar  4 06:42:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 4 Mar 2019 06:42:08 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@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>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>
Message-ID: <5bcb63d5207144c7b436d3594d9cb789@sap.com>

Hi Andrew,

> > 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?
> 
> I can live with that. I'm a bit nervous about pushing changes to jdk8u
> before jdk8u-dev, but as long as it is tested regularly and integrated
> back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet?

It has, yes.

> On your final point, the -ga tag will be the point at which we branch
> + the private CPU changes (which will be smaller than the batches
> Oracle pushed, as we are only keeping private those that are
> embargoed, not the entire release set). This is why I suggest we
> declare the branch frozen at the point we use as a base internally, so
> there are not changes between the baseline for the CPU and when we
> push upstream. Tagging -ga after a merge would represent something
> different from what we have already based our update binaries on.

Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA). We only expect few stabilization changes. And whenever you start your work on the security repo, you can do merges from jdk11u back into your private repository at any time.

Having said that, I, however, agree, that 'ga' should not be a merge between something that you worked on an tested in private and something that has diverged meanwhile in the public.
That means, between the point when you've synced the last public jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) == jdk11.0.3-ga, there must not be changes in the public repository.
So we should announce on the mailing list when we have a tag that we intend to use base for GA. And after that, no pushes any more to jdk11u, that's your hard freeze. :)
What'll be the time you need for that final round of testing? Maybe 1-2 weeks before GA?

Best regards
Christoph


From deepak.kejriwal at oracle.com  Mon Mar  4 08:56:59 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Mon, 4 Mar 2019 00:56:59 -0800 (PST)
Subject: RFR: JDK8U Backport of 8217609: New era placeholder not
 recognized by java.text.SimpleDateFormat
In-Reply-To: <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com>
References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
 <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com>
Message-ID: <dbe7b6c3-be3a-4f5f-8480-cd3e78923417@default>

Hi Naoto,

Thanks for review. I as update the webrev as per the review comments. Please find below updated version of webrev:
http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.01/

Since long and Japanese Locale issue is specific to 8u and not related to new era, I have raised a new issue JDK-8220020 for it.

Regards,
Deepak

-----Original Message-----
From: Naoto Sato 
Sent: Friday, March 1, 2019 11:07 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 Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat

Hi Deepak,

A few comments on the JapaneseEraNameTest:

- Please indent code blocks accordingly, i.e., names object declaration (line 47-51), for loop in the main() (line 56,59,60).

- If you are commenting out the case for LONG, please address the reason with the comment (the following explanation will do)

- If the above issue is specific to 8u, and not related to the new era, file a separate issue for 8u.

Naoto

On 3/1/19 2:44 AM, Deepak Kejriwal wrote:
> Hi All,
> 
>   
> 
> Please review the back port of fix for JDK-8217609 to 8u-dev:-
> 
>   
> 
> JBS report: HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.open
> jdk.java.net/browse/JDK- 8217609
> 
> Webrev: 
> http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/
> 
> Master bug change set:  
> http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17
> 
> Summary:
> Fix is backported from JDK 13 to JDK 8u and is not a clean backport. 
> Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses 
> version 33. Below are the differences between 8u and 13:-
> 
> .         The "jp.xml" version of JDK 8u does not contains "<eraNarrow>" node (<calendar type=japanese">). Therefore "<era type="236">N</era>" which is part of fix is not added to file.
> 
> .         I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java"  for JDK 8u.  It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)"
> 
> o   The  test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..).
> 
> o   The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras".  The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u.
> 
> Regards,
> 
> Deepak
> 
>   
> 

From deepak.kejriwal at oracle.com  Mon Mar  4 09:02:21 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Mon, 4 Mar 2019 01:02:21 -0800 (PST)
Subject: RFR: JDK8U Backport of 8217609: New era placeholder not
 recognized by java.text.SimpleDateFormat
In-Reply-To: <CABi63P7ztHHLqF=SYL9m28UQGk+RgzTYTd8FRLPycYKT9Uhu_g@mail.gmail.com>
References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
 <CABi63P7ztHHLqF=SYL9m28UQGk+RgzTYTd8FRLPycYKT9Uhu_g@mail.gmail.com>
Message-ID: <7896d3b3-d37e-42d5-9d4c-dc8d42c23b0c@default>

Hi Andrew,

Thanks for review. As of now we don't which bug need to be backported to 8u for fixing CLDR convertor issue. However, I have raised a separate bug for same:-
https://bugs.openjdk.java.net/browse/JDK-8220020

Regards,
Deepak 

-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com> 
Sent: Friday, March 1, 2019 9:09 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: RFR: JDK8U Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat

On Fri, 1 Mar 2019 at 10:47, Deepak Kejriwal <deepak.kejriwal at oracle.com> wrote:
>
> Hi All,
>
>
>
> Please review the back port of fix for JDK-8217609 to 8u-dev:-
>
>
>
> JBS report: HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-%208217609%22https://bugs.op
> enjdk.java.net/browse/JDK- 8217609
>
> Webrev: 
> http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/
>
> Master bug change set:  
> http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17
>
> Summary:
> Fix is backported from JDK 13 to JDK 8u and is not a clean backport. 
> Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses 
> version 33. Below are the differences between 8u and 13:-
>
> .         The "jp.xml" version of JDK 8u does not contains "<eraNarrow>" node (<calendar type=japanese">). Therefore "<era type="236">N</era>" which is part of fix is not added to file.
>
> .         I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java"  for JDK 8u.  It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)"
>
> o   The  test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..).
>
> o   The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras".  The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u.
>
> Regards,
>
> Deepak
>
>

Patch looks good to me.

Is there a bug/patch to backport to fix the CLDR converter in OpenJDK 8, so japanese.long.Eras are included?

JDK-8217609 should have the label 'jdk8u-fix-request' added so it can be approved for 8u.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=OIRLm_rdyVUfNJH3SLA-tRzXEZ3NIKC14aO9CokPvgI&m=j3CCAe0gKdZ1tUX3wqQmQH0-QEcf9c-SP_A6NIFBobU&s=taCA3iR6U95qSdORcSSBkhnzDPXZDhrUKtyZjecFOGw&e=)

Web Site: https://urldefense.proofpoint.com/v2/url?u=http-3A__fuseyism.com&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=OIRLm_rdyVUfNJH3SLA-tRzXEZ3NIKC14aO9CokPvgI&m=j3CCAe0gKdZ1tUX3wqQmQH0-QEcf9c-SP_A6NIFBobU&s=qf3t66gFRZcTpETTq7B7ur6kxz7LEX2z65dog1MIlKg&e=
Twitter: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_gnu-5Fandrew-5Fjava&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=OIRLm_rdyVUfNJH3SLA-tRzXEZ3NIKC14aO9CokPvgI&m=j3CCAe0gKdZ1tUX3wqQmQH0-QEcf9c-SP_A6NIFBobU&s=Kjo5wWD8vSXUKQhnMlZ9dNyEQWdR1QuHvqPAwz5hJ7c&e=
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From martin.doerr at sap.com  Mon Mar  4 09:06:03 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 4 Mar 2019 09:06:03 +0000
Subject: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
 generation.
In-Reply-To: <e3040d0c-90f3-f35f-c493-48afc14c0244@redhat.com>
References: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <e3040d0c-90f3-f35f-c493-48afc14c0244@redhat.com>
Message-ID: <AM6PR02MB478822EA6A17924A84AD8EAD9A710@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi G?tz,

reviewed. I think it's critical enough for 8u (instead of 8u-dev). Risk seems to be very low.

Best regards,
Martin


-----Original Message-----
From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of Andrew Haley
Sent: Freitag, 1. M?rz 2019 15:46
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk8u-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
Subject: Re: RFR(XS): 8219961: [ppc64] Increase code size for interpreter generation.

On 3/1/19 6:49 AM, Lindenmaier, Goetz wrote:
> If an agent is specified, the VM does not start on ppc64.
> The space for the template interpreter does not suffice any more.
> http://cr.openjdk.java.net/~goetz/wr19/8219961-ppc64_interpreter_8/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 goetz.lindenmaier at sap.com  Mon Mar  4 09:22:32 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 4 Mar 2019 09:22:32 +0000
Subject: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
 generation.
In-Reply-To: <AM6PR02MB478822EA6A17924A84AD8EAD9A710@AM6PR02MB4788.eurprd02.prod.outlook.com>
References: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <e3040d0c-90f3-f35f-c493-48afc14c0244@redhat.com>
 <AM6PR02MB478822EA6A17924A84AD8EAD9A710@AM6PR02MB4788.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB518324A3C1DC01D5F3F9510DEC710@VI1PR02MB5183.eurprd02.prod.outlook.com>

Thanks Martin!

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin
> Sent: Monday, March 4, 2019 10:06 AM
> To: Andrew Haley <aph at redhat.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; jdk8u-dev at openjdk.java.net; hotspot-
> dev at openjdk.java.net
> Subject: RE: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
> generation.
> 
> Hi G?tz,
> 
> reviewed. I think it's critical enough for 8u (instead of 8u-dev). Risk seems to
> be very low.
> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Andrew Haley
> Sent: Freitag, 1. M?rz 2019 15:46
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk8u-
> dev at openjdk.java.net; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
> generation.
> 
> On 3/1/19 6:49 AM, Lindenmaier, Goetz wrote:
> > If an agent is specified, the VM does not start on ppc64.
> > The space for the template interpreter does not suffice any more.
> > http://cr.openjdk.java.net/~goetz/wr19/8219961-ppc64_interpreter_8/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 neugens at redhat.com  Mon Mar  4 11:19:50 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 4 Mar 2019 12:19:50 +0100
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <470BA8E8-4A89-4207-96C3-91723643986E@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
Message-ID: <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>

On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:

> > I'm going through the patch right now, but yes, from what I see the
> > trace is removed. I had too a concern about this and was about to send
> > a note. I'm not quite sure what to do, because Trace has been removed
> > in 11 as far as I know, but removing mid stream in 8 may be a more
> > interesting issue, however this isn't a user facing API, it was always
> > meant to be internal to the JVM, so I don't quite know if there's
> > really a reason we shouldn't change it. This is one question for the
> > CSR group I think.
> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> I will be happy to return it back

Yes, I tend to agree with you, I do believe this is mostly an internal
API for easy of patching with the JFR code (which is almost
identical). The only concern is in the way the logging would be
triggered externally and the compile time options for it (I still see
a couple of instance where INCLUDE_TRACE is being used). As for
triggering the logs, I don't recall that 8 has any means of doing
this, I think some infrastructure came with 9 with the -Xlog option (I
didn't follow this however, I'm not sure the option ever landed in 9)?
In that case I guess it's safe to go after all.

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  Mon Mar  4 12:39:12 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Mon, 04 Mar 2019 20:39:12 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <470BA8E8-4A89-4207-96C3-91723643986E@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>,
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
Message-ID: <22d5ca5a-61b1-4083-91cc-35e8e494cc05.guangyu.zhu@aliyun.com>

Thank you both for your comments. For the runtime flags, let's continue to use the same flags as Oracle, at least at the current stage.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Mar. 2 (Sat.) 03:09
Recipient:Mario Torre <neugens at redhat.com>
Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Hi guys,

> On 1 Mar 2019, at 15:59, Mario Torre <neugens at redhat.com> wrote:
> 
> On Fri, Mar 1, 2019 at 1:38 PM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>> 
>> Hi Mario, Andrey
>> 
>> Very happy to see things moving forward. Some of my updates:
> 
> Thanks for your work and help!
> 
>> As Andrey and I both agreed, in order not to waste resources, Alibaba will be responsible for merging the missing features. The work is in progress, my colleague Denghui and I are working on below tasks.
>> 
>> - thread sampling. [code completed, under testing]
>> - biased locking events [code completed, under testing]
That's great! Thank you!
>> - G1 heap summary and region types  [not started yet]
>> - -XX:+/-EnableJFR run time flag [not started yet]
>> 
>> For the first three missing features, once we complete the coding and testing, we will send out webrev. For the last one, we added an 'EnableJFR' flag to enable or disable JFR functionality at runtime. Jdk11 does not have such a runtime flag. So we didn't start working right away, we want to hear the opinions of the community first.
> 
> I don't think we should diverge in any way from the other versions
> unless necessary. For 8u-dev I would like to follow what Oracle did on
> their VM, with the usual pack of -XX:+UnlockCommercialFeatures
> -XX:+FlightRecorder -XX:StartFlightRecording=xxx options.
> 
> I know -XX:+UnlockCommercialFeatures isn't necessary in our case, but
> it should be there for compatibility. I would be ok if the option
> didn't do anything but was just there as to not crash the VM at
> startup when someone was migrating from one downstream version to the
> other. Of course, it can be said that -XX:+UnlockCommercialFeatures in
> OpenJDK currently doesn't exist and is deprecated in later versions
> anyway, so I defer to Andrew Haley regarding this specific point if he
> has a strong opinion of not introducing the option at all.
I fully agree that UnlockCommercialFeatures flag should be left for compatibility. That's exactly
what I have done, added it with a help text that this is the only purpose. In fact without it
one cannot use JMC with jdk8, JMC has built-in knowledge about necessity to specify
this flag if it deals with version 8
> 
> Regarding +EnableJFR as a runtime flag, my take is that
> -XX:+FlightRecorder -XX:StartFlightRecording are already doing the
> same.
Agree. Also, having another flag which is false by default will prevent from using typical procedure
to connect JMC to such JFR implementation. One would need to either EnableJFR with command line
or management interface beforehand
> 
>> There is one thing we think should be mentioned. Azul's patch removes the trace feature (JEP 167: Event-based JVM tracing, am I correct?) and replaces it with jfr, which is the same as jdk11. I am not sure if anyone is relying on the original trace feature. Maybe we should keep it. What do you think?
> 
> I'm going through the patch right now, but yes, from what I see the
> trace is removed. I had too a concern about this and was about to send
> a note. I'm not quite sure what to do, because Trace has been removed
> in 11 as far as I know, but removing mid stream in 8 may be a more
> interesting issue, however this isn't a user facing API, it was always
> meant to be internal to the JVM, so I don't quite know if there's
> really a reason we shouldn't change it. This is one question for the
> CSR group I think.
Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace 
was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
I will be happy to return it back

Thanks,
Andrey
> 
> 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 goetz.lindenmaier at sap.com  Mon Mar  4 15:17:19 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 4 Mar 2019 15:17:19 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <90c57878b5254c6ca2d496a2a59b8eb8@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>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
Message-ID: <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>

 Hi Andrew, Aleksey, community,

Before, I proposed this, but got no comments:
> 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.

Should SAP take the role of doing above merges?

Best regards,
  Goetz



> 
> 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 naoto.sato at oracle.com  Mon Mar  4 16:27:27 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 4 Mar 2019 08:27:27 -0800
Subject: RFR: JDK8U Backport of 8217609: New era placeholder not
 recognized by java.text.SimpleDateFormat
In-Reply-To: <dbe7b6c3-be3a-4f5f-8480-cd3e78923417@default>
References: <1f8cd0df-719e-4101-bef9-71324ee32f6a@default>
 <4612f0ab-fbd9-025e-edf0-d2098f581407@oracle.com>
 <dbe7b6c3-be3a-4f5f-8480-cd3e78923417@default>
Message-ID: <cbd5e20a-3560-4dd6-9807-d86749454d12@oracle.com>

Looks good.

Naoto

On 3/4/19 12:56 AM, Deepak Kejriwal wrote:
> Hi Naoto,
> 
> Thanks for review. I as update the webrev as per the review comments. Please find below updated version of webrev:
> http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.01/
> 
> Since long and Japanese Locale issue is specific to 8u and not related to new era, I have raised a new issue JDK-8220020 for it.
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Friday, March 1, 2019 11:07 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 Backport of 8217609: New era placeholder not recognized by java.text.SimpleDateFormat
> 
> Hi Deepak,
> 
> A few comments on the JapaneseEraNameTest:
> 
> - Please indent code blocks accordingly, i.e., names object declaration (line 47-51), for loop in the main() (line 56,59,60).
> 
> - If you are commenting out the case for LONG, please address the reason with the comment (the following explanation will do)
> 
> - If the above issue is specific to 8u, and not related to the new era, file a separate issue for 8u.
> 
> Naoto
> 
> On 3/1/19 2:44 AM, Deepak Kejriwal wrote:
>> Hi All,
>>
>>    
>>
>> Please review the back port of fix for JDK-8217609 to 8u-dev:-
>>
>>    
>>
>> JBS report: HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-%208217609"https://bugs.open
>> jdk.java.net/browse/JDK- 8217609
>>
>> Webrev:
>> http://cr.openjdk.java.net/~pkoppula/dkejriwal/8217609/webrev.00/
>>
>> Master bug change set:
>> http://hg.openjdk.java.net/jdk/jdk/rev/8ea340a71f17
>>
>> Summary:
>> Fix is backported from JDK 13 to JDK 8u and is not a clean backport.
>> Reason for that is because JDK uses CLDR version 21.01 and JDK 13 uses
>> version 33. Below are the differences between 8u and 13:-
>>
>> .         The "jp.xml" version of JDK 8u does not contains "<eraNarrow>" node (<calendar type=japanese">). Therefore "<era type="236">N</era>" which is part of fix is not added to file.
>>
>> .         I've commented out one of the test data { LONG, JAPAN, "\u5143\u53f7" } in "JapaneseEraNameTest.java"  for JDK 8u.  It checks era name returned by method "java.util.Calendar.getDisplayName(int field, int style, Locale locale)"
>>
>> o   The  test fails for this particular data on prior 8u releases across all existing eras(HEISI,SHOWA,..).
>>
>> o   The cause of issue is that CLDR java resource file (FormatData_ja.java) generated by "CLDR Converter" does not contain required resource key "japanese.long.Eras".  The "CLDR Converter" need to be fixed to address this issue. Since this issue is an existing issue data point { LONG, JAPAN, "\u5143\u53f7" } is removed from "JapaneseEraNameTest.java" for 8u.
>>
>> Regards,
>>
>> Deepak
>>
>>    
>>

From gnu.andrew at redhat.com  Mon Mar  4 17:09:07 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 4 Mar 2019 17:09:07 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <5bcb63d5207144c7b436d3594d9cb789@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>
 <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>
 <5bcb63d5207144c7b436d3594d9cb789@sap.com>
Message-ID: <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@mail.gmail.com>

On Mon, 4 Mar 2019 at 06:42, Langer, Christoph <christoph.langer at sap.com> wrote:
>
> Hi Andrew,
>
> > > 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?
> >
> > I can live with that. I'm a bit nervous about pushing changes to jdk8u
> > before jdk8u-dev, but as long as it is tested regularly and integrated
> > back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet?
>
> It has, yes.

Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-)

>
> > On your final point, the -ga tag will be the point at which we branch
> > + the private CPU changes (which will be smaller than the batches
> > Oracle pushed, as we are only keeping private those that are
> > embargoed, not the entire release set). This is why I suggest we
> > declare the branch frozen at the point we use as a base internally, so
> > there are not changes between the baseline for the CPU and when we
> > push upstream. Tagging -ga after a merge would represent something
> > different from what we have already based our update binaries on.
>
> Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA). We only expect few stabilization changes. And whenever you start your work on the security repo, you can do merges from jdk11u back into your private repository at any time.
>
> Having said that, I, however, agree, that 'ga' should not be a merge between something that you worked on an tested in private and something that has diverged meanwhile in the public.
> That means, between the point when you've synced the last public jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) == jdk11.0.3-ga, there must not be changes in the public repository.
> So we should announce on the mailing list when we have a tag that we intend to use base for GA. And after that, no pushes any more to jdk11u, that's your hard freeze. :)
> What'll be the time you need for that final round of testing? Maybe 1-2 weeks before GA?

Yeah, I'd prefer to keep such merges to a minimum and only really
essential fixes should be going in during the later stages.
i see four changes already post-tag.

It depends a lot on the vulnerability group, but yes, I was thinking
the start of the month of the CPU (so April for this next one).

>
> Best regards
> Christoph
>


-- 
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  Mon Mar  4 17:18:42 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 4 Mar 2019 17:18:42 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@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>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>
 <5bcb63d5207144c7b436d3594d9cb789@sap.com>
 <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@mail.gmail.com>
Message-ID: <VI1PR02MB51839F8D57F305713A1292CBEC710@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi Andrew,

> It depends a lot on the vulnerability group, but yes, I was thinking
> the start of the month of the CPU (so April for this next one).
That seems to be a good point, I don't think we should go
more later, rather more early.
If it wasn't for jcheck not accepting other tags, I would propose 
to tag it at that point with 11.0.3-rc (For release candidate, see JEP 3).

Best regards,
  Goetz.




> -----Original Message-----
> From: Andrew Hughes <gnu.andrew at redhat.com>
> Sent: Monday, March 4, 2019 6:09 PM
> To: Langer, Christoph <christoph.langer at sap.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
> 
> On Mon, 4 Mar 2019 at 06:42, Langer, Christoph <christoph.langer at sap.com>
> wrote:
> >
> > Hi Andrew,
> >
> > > > 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?
> > >
> > > I can live with that. I'm a bit nervous about pushing changes to jdk8u
> > > before jdk8u-dev, but as long as it is tested regularly and integrated
> > > back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet?
> >
> > It has, yes.
> 
> Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-)
> 
> >
> > > On your final point, the -ga tag will be the point at which we branch
> > > + the private CPU changes (which will be smaller than the batches
> > > Oracle pushed, as we are only keeping private those that are
> > > embargoed, not the entire release set). This is why I suggest we
> > > declare the branch frozen at the point we use as a base internally, so
> > > there are not changes between the baseline for the CPU and when we
> > > push upstream. Tagging -ga after a merge would represent something
> > > different from what we have already based our update binaries on.
> >
> > Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA).
> We only expect few stabilization changes. And whenever you start your work
> on the security repo, you can do merges from jdk11u back into your private
> repository at any time.
> >
> > Having said that, I, however, agree, that 'ga' should not be a merge
> between something that you worked on an tested in private and something
> that has diverged meanwhile in the public.
> > That means, between the point when you've synced the last public
> jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) ==
> jdk11.0.3-ga, there must not be changes in the public repository.
> > So we should announce on the mailing list when we have a tag that we
> intend to use base for GA. And after that, no pushes any more to jdk11u,
> that's your hard freeze. :)
> > What'll be the time you need for that final round of testing? Maybe 1-2
> weeks before GA?
> 
> Yeah, I'd prefer to keep such merges to a minimum and only really
> essential fixes should be going in during the later stages.
> i see four changes already post-tag.
> 
> It depends a lot on the vulnerability group, but yes, I was thinking
> the start of the month of the CPU (so April for this next one).
> 
> >
> > Best regards
> > Christoph
> >
> 
> 
> --
> 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 Mar  4 17:36:10 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 4 Mar 2019 17:36:10 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source
 tree
In-Reply-To: <EE64E227-CF50-4D02-A1F7-919506E4AC82@azul.com>
References: <EE64E227-CF50-4D02-A1F7-919506E4AC82@azul.com>
Message-ID: <4af80f78-115b-acc7-b664-c45319ca3d16@redhat.com>

On 01/03/2019 14:56, Dmitry Cherepanov wrote:
> Please review/approve the backport of 8170681 to 8u-dev
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8170681
> Webrev (root repo): http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.root/
> Webrev (jdk repo): http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jdk/
> 
> The original patch doesn't apply cleanly to 8u-dev so it includes the following modifications
>  - In 9, the fix for JDK-8138761 includes refactoring that splits libraries.m4 into several files (file per tool). For 8u-dev, the backport patch updates the existing libraries.m4 for consistency.
>  - The original patch removes fontconfig.md with fontconfig license entry. For 8u-dev, the backport patch updates THIRD_PARTY_README files (for all repos).
> 
> Testing - repo with the patch builds on Windows/Mac. Also tested it on CentOS with and without fontconfig-devel installed.
> 
> Thanks,
> 
> Dmitry
> 

Looks good to me.

Are there changes for the other repos too, for THIRD_PARTY_README?
I see it is present across them all (as was the case for recent libpng
updates):

$ for repos in . corba jaxp jaxws langtools nashorn jdk hotspot; do echo
${repos}; grep -ri 'fontconfig'
../../jdk8u-dev/${repos}/THIRD_PARTY_README; done
.
%% This notice is provided with respect to FontConfig 2.5, which may be
corba
%% This notice is provided with respect to FontConfig 2.5, which may be
jaxp
%% This notice is provided with respect to FontConfig 2.5, which may be
jaxws
%% This notice is provided with respect to FontConfig 2.5, which may be
langtools
%% This notice is provided with respect to FontConfig 2.5, which may be
nashorn
%% This notice is provided with respect to FontConfig 2.5, which may be
jdk
%% This notice is provided with respect to FontConfig 2.5, which may be
hotspot
%% This notice is provided with respect to FontConfig 2.5, which may be

Thanks,
-- 
Andrew :)

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

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


From dcherepanov at azul.com  Mon Mar  4 17:57:02 2019
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Mon, 4 Mar 2019 17:57:02 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source
 tree
In-Reply-To: <4af80f78-115b-acc7-b664-c45319ca3d16@redhat.com>
References: <EE64E227-CF50-4D02-A1F7-919506E4AC82@azul.com>
 <4af80f78-115b-acc7-b664-c45319ca3d16@redhat.com>
Message-ID: <4CAFF9FF-CEED-4F2B-A2F5-E818E20B5FE5@azul.com>

Thanks for the review.
THIRD_PARTY_README has been updated for all repos.
Here?s the links to webrevs:

http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.root/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jdk/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.hotspot/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.corba/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jaxp/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jaxws/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.langtools/
http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.nashorn/

Thanks,

Dmitry

On Mar 4, 2019, at 8:36 PM, Andrew John Hughes <gnu.andrew at redhat.com<mailto:gnu.andrew at redhat.com>> wrote:

On 01/03/2019 14:56, Dmitry Cherepanov wrote:
Please review/approve the backport of 8170681 to 8u-dev

JBS: https://bugs.openjdk.java.net/browse/JDK-8170681
Webrev (root repo): http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.root/
Webrev (jdk repo): http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jdk/

The original patch doesn't apply cleanly to 8u-dev so it includes the following modifications
- In 9, the fix for JDK-8138761 includes refactoring that splits libraries.m4 into several files (file per tool). For 8u-dev, the backport patch updates the existing libraries.m4 for consistency.
- The original patch removes fontconfig.md with fontconfig license entry. For 8u-dev, the backport patch updates THIRD_PARTY_README files (for all repos).

Testing - repo with the patch builds on Windows/Mac. Also tested it on CentOS with and without fontconfig-devel installed.

Thanks,

Dmitry


Looks good to me.

Are there changes for the other repos too, for THIRD_PARTY_README?
I see it is present across them all (as was the case for recent libpng
updates):

$ for repos in . corba jaxp jaxws langtools nashorn jdk hotspot; do echo
${repos}; grep -ri 'fontconfig'
../../jdk8u-dev/${repos}/THIRD_PARTY_README; done
.
%% This notice is provided with respect to FontConfig 2.5, which may be
corba
%% This notice is provided with respect to FontConfig 2.5, which may be
jaxp
%% This notice is provided with respect to FontConfig 2.5, which may be
jaxws
%% This notice is provided with respect to FontConfig 2.5, which may be
langtools
%% This notice is provided with respect to FontConfig 2.5, which may be
nashorn
%% This notice is provided with respect to FontConfig 2.5, which may be
jdk
%% This notice is provided with respect to FontConfig 2.5, which may be
hotspot
%% This notice is provided with respect to FontConfig 2.5, which may be

Thanks,
--
Andrew :)

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

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


From deepak.kejriwal at oracle.com  Mon Mar  4 18:43:12 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Mon, 4 Mar 2019 10:43:12 -0800 (PST)
Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era
 placeholder not recognized by java.text.SimpleDateFormat
Message-ID: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>

Hi All,

 

Please approve the backport of following bugs to 8u-dev.

 

JDK- 8217609 : New era placeholder not recognized by java.text.SimpleDateFormat

 

JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058786.html

 

All the related testing is done and is a pass.

 

Regards,

Deepak

 

From gnu.andrew at redhat.com  Mon Mar  4 23:04:32 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 4 Mar 2019 23:04:32 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source
 tree
In-Reply-To: <4CAFF9FF-CEED-4F2B-A2F5-E818E20B5FE5@azul.com>
References: <EE64E227-CF50-4D02-A1F7-919506E4AC82@azul.com>
 <4af80f78-115b-acc7-b664-c45319ca3d16@redhat.com>
 <4CAFF9FF-CEED-4F2B-A2F5-E818E20B5FE5@azul.com>
Message-ID: <c902cb8a-14bf-e6d0-1f2f-fdff85986795@redhat.com>

On 04/03/2019 17:57, Dmitry Cherepanov wrote:
> Thanks for the review.
> THIRD_PARTY_README has been updated for all repos.
> Here?s the links to webrevs:
> 
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.root/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jdk/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.hotspot/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.corba/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jaxp/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.jaxws/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.langtools/
> http://cr.openjdk.java.net/~dcherepanov/8170681/v0/webrev.nashorn/
> 
> Thanks,
> 
> Dmitry
> 

Thanks. Looks good.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar  4 23:09:10 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 4 Mar 2019 23:09:10 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era
 placeholder not recognized by java.text.SimpleDateFormat
In-Reply-To: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>
References: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>
Message-ID: <ba4c14b7-f212-6351-68ff-d6c6d6d56731@redhat.com>



On 04/03/2019 18:43, Deepak Kejriwal wrote:
> Hi All,
> 
>  
> 
> Please approve the backport of following bugs to 8u-dev.
> 
>  
> 
> JDK- 8217609 : New era placeholder not recognized by java.text.SimpleDateFormat
> 
>  
> 
> JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058786.html
> 
>  
> 
> All the related testing is done and is a pass.
> 
>  
> 
> Regards,
> 
> Deepak
> 
>  
> 

We use the bug labelling approach now for OpenJDK 8 (jdk8u-fix-request
and jdk8u-fix-yes):

https://openjdk.java.net/projects/jdk-updates/approval.html

I've set jdk8u-fix-yes for this.

Thanks,
-- 
Andrew :)

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

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


From christoph.langer at sap.com  Tue Mar  5 07:32:44 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 5 Mar 2019 07:32:44 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@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>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>
 <5bcb63d5207144c7b436d3594d9cb789@sap.com>
 <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@mail.gmail.com>
Message-ID: <739e16adb54c490eb551e226b09f84de@sap.com>

Hi Andrew,

> Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-)

Sure, jdk-11.0.4+0 is already present in jdk11u-dev. :) If jdk-11.0.3+0 is particularly important to you for some reason, we can still tag some change with that label... Do you need that?

/Christoph


From sean.coffey at oracle.com  Tue Mar  5 09:54:43 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 5 Mar 2019 09:54:43 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era
 placeholder not recognized by java.text.SimpleDateFormat
In-Reply-To: <ba4c14b7-f212-6351-68ff-d6c6d6d56731@redhat.com>
References: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>
 <ba4c14b7-f212-6351-68ff-d6c6d6d56731@redhat.com>
Message-ID: <19dfc6c9-9109-b3bb-72c8-668b45d99614@oracle.com>

Andrew,

I think there's still confusion around the new process for JDK 8 
Updates. The 8u Project page needs to be updated IMO.

https://wiki.openjdk.java.net/display/jdk8u/Main

Regards,
Sean.

On 04/03/19 23:09, Andrew John Hughes wrote:
>
> On 04/03/2019 18:43, Deepak Kejriwal wrote:
>> Hi All,
>>
>>   
>>
>> Please approve the backport of following bugs to 8u-dev.
>>
>>   
>>
>> JDK- 8217609 : New era placeholder not recognized by java.text.SimpleDateFormat
>>
>>   
>>
>> JDK Review Thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058786.html
>>
>>   
>>
>> All the related testing is done and is a pass.
>>
>>   
>>
>> Regards,
>>
>> Deepak
>>
>>   
>>
> We use the bug labelling approach now for OpenJDK 8 (jdk8u-fix-request
> and jdk8u-fix-yes):
>
> https://openjdk.java.net/projects/jdk-updates/approval.html
>
> I've set jdk8u-fix-yes for this.
>
> Thanks,


From andrey at azul.com  Tue Mar  5 16:34:49 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 5 Mar 2019 16:34:49 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
Message-ID: <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>

Hi Mario,

> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> 
> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> 
>>> I'm going through the patch right now, but yes, from what I see the
>>> trace is removed. I had too a concern about this and was about to send
>>> a note. I'm not quite sure what to do, because Trace has been removed
>>> in 11 as far as I know, but removing mid stream in 8 may be a more
>>> interesting issue, however this isn't a user facing API, it was always
>>> meant to be internal to the JVM, so I don't quite know if there's
>>> really a reason we shouldn't change it. This is one question for the
>>> CSR group I think.
>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
>> I will be happy to return it back
> 
> Yes, I tend to agree with you, I do believe this is mostly an internal
> API for easy of patching with the JFR code (which is almost
> identical). The only concern is in the way the logging would be
> triggered externally and the compile time options for it (I still see
> a couple of instance where INCLUDE_TRACE is being used). As for
> triggering the logs, I don't recall that 8 has any means of doing
> this, I think some infrastructure came with 9 with the -Xlog option (I
> didn't follow this however, I'm not sure the option ever landed in 9)?
> In that case I guess it's safe to go after all.
Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
IMHO we should get rid of all of them, but cannot tell for sure now

Andrey
> 
> 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  Tue Mar  5 16:35:21 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 5 Mar 2019 16:35:21 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era
 placeholder not recognized by java.text.SimpleDateFormat
In-Reply-To: <19dfc6c9-9109-b3bb-72c8-668b45d99614@oracle.com>
References: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>
 <ba4c14b7-f212-6351-68ff-d6c6d6d56731@redhat.com>
 <19dfc6c9-9109-b3bb-72c8-668b45d99614@oracle.com>
Message-ID: <3b524f18-85d6-5c72-bfbd-e5637390ae2a@redhat.com>

On 3/5/19 9:54 AM, Se?n Coffey wrote:
> I think there's still confusion around the new process for JDK 8 
> Updates. The 8u Project page needs to be updated IMO.
> 
> https://wiki.openjdk.java.net/display/jdk8u/Main

Done. It's not perfect and it's a Work In Progress, but it's better than it was.

-- 
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  Tue Mar  5 18:06:16 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 5 Mar 2019 18:06:16 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era
 placeholder not recognized by java.text.SimpleDateFormat
In-Reply-To: <3b524f18-85d6-5c72-bfbd-e5637390ae2a@redhat.com>
References: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>
 <ba4c14b7-f212-6351-68ff-d6c6d6d56731@redhat.com>
 <19dfc6c9-9109-b3bb-72c8-668b45d99614@oracle.com>
 <3b524f18-85d6-5c72-bfbd-e5637390ae2a@redhat.com>
Message-ID: <0dbf6252-bb28-1f24-821f-1719e9feb875@redhat.com>



On 05/03/2019 16:35, Andrew Haley wrote:
> On 3/5/19 9:54 AM, Se?n Coffey wrote:
>> I think there's still confusion around the new process for JDK 8 
>> Updates. The 8u Project page needs to be updated IMO.
>>
>> https://wiki.openjdk.java.net/display/jdk8u/Main
> 
> Done. It's not perfect and it's a Work In Progress, but it's better than it was.
> 

Thanks. I'd suggest also removing the two Push templates to avoid
confusion.

I think "Proposing Critical 8u Fixes for CPU releases" &
"Phase 2 Integration Process" could also go, as they're covered
by "Guidelines for working on jdk8u", and I don't believe we're
using the critical-request label mentioned in the former.

Thanks,
-- 
Andrew :)

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

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


From hohensee at amazon.com  Tue Mar  5 19:23:10 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 5 Mar 2019 19:23:10 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <e396558c68dc46b580210c748c8ab345@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>
 <AE397680-E6FF-4A88-A515-C2E3EFBDB0F3@amazon.com>
 <39113bdc-2417-72d9-5d80-90f341be99c0@redhat.com>
 <56B31A97-2355-4BA4-B244-2B9A0B275B63@amazon.com>
 <e396558c68dc46b580210c748c8ab345@sap.com>
Message-ID: <CB79028C-6BD2-4515-88C0-3CCA08F9E739@amazon.com>

I don't know which is which. The last few pushes I've done have been the result of "hg commit -u <original-assignee>", which results in the original assignee being recorded as the backport assignee. I don't know how to put both that person's name and the backport author into the same issue.

Paul

?On 2/26/19, 2:53 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    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 goetz.lindenmaier at sap.com  Tue Mar  5 20:47:43 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 5 Mar 2019 20:47:43 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.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>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hmm, no comments yet on this ... assuming nobody objects
I will tag tomorrow and run the tests tomorrow night.

Best regards,
  Goetz

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Monday, March 4, 2019 4:17 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; Andrew Hughes <gnu.andrew at redhat.com>
> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: RE: 8u/11u repo access and Jira changes
> 
>  Hi Andrew, Aleksey, community,
> 
> Before, I proposed this, but got no comments:
> > 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.
> 
> Should SAP take the role of doing above merges?
> 
> Best regards,
>   Goetz
> 
> 
> 
> >
> > 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 aph at redhat.com  Wed Mar  6 09:20:18 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 6 Mar 2019 09:20:18 +0000
Subject: [8u-dev] Request for Approval: Backport of JDK-8217609 : New era
 placeholder not recognized by java.text.SimpleDateFormat
In-Reply-To: <0dbf6252-bb28-1f24-821f-1719e9feb875@redhat.com>
References: <d0899c9d-b355-40b7-a964-cf26caf926b6@default>
 <ba4c14b7-f212-6351-68ff-d6c6d6d56731@redhat.com>
 <19dfc6c9-9109-b3bb-72c8-668b45d99614@oracle.com>
 <3b524f18-85d6-5c72-bfbd-e5637390ae2a@redhat.com>
 <0dbf6252-bb28-1f24-821f-1719e9feb875@redhat.com>
Message-ID: <d18d68f3-442e-4049-9ae9-f92c65912fae@redhat.com>

On 3/5/19 6:06 PM, Andrew John Hughes wrote:
> 
> 
> On 05/03/2019 16:35, Andrew Haley wrote:
>> On 3/5/19 9:54 AM, Se?n Coffey wrote:
>>> I think there's still confusion around the new process for JDK 8 
>>> Updates. The 8u Project page needs to be updated IMO.
>>>
>>> https://wiki.openjdk.java.net/display/jdk8u/Main
>>
>> Done. It's not perfect and it's a Work In Progress, but it's better than it was.
> 
> Thanks. I'd suggest also removing the two Push templates to avoid
> confusion.
> 
> I think "Proposing Critical 8u Fixes for CPU releases" &
> "Phase 2 Integration Process" could also go, as they're covered
> by "Guidelines for working on jdk8u", and I don't believe we're
> using the critical-request label mentioned in the former.

OK.

I left these in because I wasn't quite sure what to replace them with.

-- 
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 takiguc at linux.vnet.ibm.com  Fri Mar  1 05:59:04 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 01 Mar 2019 14:59:04 +0900
Subject: JBS Filters for JDK update work
In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com>
References: <3fa6de91b4c44736a6570256851c52d3@sap.com>
Message-ID: <5c897bc2d8e51bf79126136f586651f5@linux.vnet.ibm.com>

Hello Langer.

About "Unapproved requests", it's better to use following search text.
   labels = jdk11u-fix-request AND labels not in (jdk11u-fix-no, 
jdk11u-fix-yes)
On current query, 2 jdk11u-fix-no are there, they are always displayed.

Thanks,
Ichiroh Takiguchi

On 2019-02-27 23:34, 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
> 
> 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 anwar at impact.com  Wed Mar  6 14:30:01 2019
From: anwar at impact.com (Anwar Sonday)
Date: Wed, 6 Mar 2019 16:30:01 +0200
Subject: JDK-8213825 help
Message-ID: <CAM0vRD42t9XrhrVUqmuf=Xz2GxntcW_nzk__3BZA4CANsXw2Dw@mail.gmail.com>

Hi

JDK-8213825 [1] has been resolved, and 12 is the fix version.
Does anyone know if these fixes will be back ported to the lower versions,
specifically 8 and 11?

We currently faced with this bug and we are using version 8 (java version
"1.8.0_152").

I would be highly appreciated if anyone could point offer some guidance or
point me the right direction.

Thank you
Anwar Sonday

[1] https://bugs.openjdk.java.net/browse/JDK-821382
<https://bugs.openjdk.java.net/browse/JDK-8213825>

From shade at redhat.com  Wed Mar  6 14:56:27 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 6 Mar 2019 15:56:27 +0100
Subject: JDK-8213825 help
In-Reply-To: <CAM0vRD42t9XrhrVUqmuf=Xz2GxntcW_nzk__3BZA4CANsXw2Dw@mail.gmail.com>
References: <CAM0vRD42t9XrhrVUqmuf=Xz2GxntcW_nzk__3BZA4CANsXw2Dw@mail.gmail.com>
Message-ID: <884df967-9be1-db2c-dc8e-32de4c05ad63@redhat.com>

On 3/6/19 3:30 PM, Anwar Sonday wrote:
> JDK-8213825 [1] has been resolved, and 12 is the fix version.
> Does anyone know if these fixes will be back ported to the lower versions,
> specifically 8 and 11?

This issue is not any list to backport. I marked it with redhat-openjdk for us (Red Hat people) to
see if we want to backport it to 11u and 8u.

> I would be highly appreciated if anyone could point offer some guidance or
> point me the right direction.

Normally, you follow these processes to backport to 11u and 8u:
  https://wiki.openjdk.java.net/display/jdk8u/Main
  http://openjdk.java.net/projects/jdk-updates/index.html

But this requires attention of compiler people anyway. You may try to apply the fix to both 11u and
8u and test the resulting binaries with your test suites, though.

Thanks,
-Aleksey


From gnu.andrew at redhat.com  Wed Mar  6 17:41:51 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 6 Mar 2019 17:41:51 +0000
Subject: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
 generation.
In-Reply-To: <VI1PR02MB518324A3C1DC01D5F3F9510DEC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <e3040d0c-90f3-f35f-c493-48afc14c0244@redhat.com>
 <AM6PR02MB478822EA6A17924A84AD8EAD9A710@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <VI1PR02MB518324A3C1DC01D5F3F9510DEC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <2d3bfe75-fc1c-941c-1aba-93b3c3beae69@redhat.com>


On 04/03/2019 09:22, Lindenmaier, Goetz wrote:
> Thanks Martin!
> 
> Best regards,
>   Goetz.
> 
>> -----Original Message-----
>> From: Doerr, Martin
>> Sent: Monday, March 4, 2019 10:06 AM
>> To: Andrew Haley <aph at redhat.com>; Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>; jdk8u-dev at openjdk.java.net; hotspot-
>> dev at openjdk.java.net
>> Subject: RE: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
>> generation.
>>
>> Hi G?tz,
>>
>> reviewed. I think it's critical enough for 8u (instead of 8u-dev). Risk seems to
>> be very low.
>>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
>> Andrew Haley
>> Sent: Freitag, 1. M?rz 2019 15:46
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk8u-
>> dev at openjdk.java.net; hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
>> generation.
>>
>> On 3/1/19 6:49 AM, Lindenmaier, Goetz wrote:
>>> If an agent is specified, the VM does not start on ppc64.
>>> The space for the template interpreter does not suffice any more.
>>> http://cr.openjdk.java.net/~goetz/wr19/8219961-ppc64_interpreter_8/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

This seems to have been pushed to the wrong tree (jdk8u rather than
jdk8u-dev):

https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/111b95ad4584

It also looks like the bug system is still assigning 'openjdk8u' to
jdk8u pushes.

https://bugs.openjdk.java.net/browse/JDK-8219961
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Wed Mar  6 18:13:03 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 6 Mar 2019 18:13:03 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.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>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <d1fda560-e13d-a202-369d-2f7db006f577@redhat.com>

On 05/03/2019 20:47, Remainder, Goethe wrote:
> Hmm, no comments yet on this ... assuming nobody objects
> I will tag tomorrow and run the tests tomorrow night.
> 
> Best regards,
>   Goetz
> 
>> -----Original Message-----
>> From: Lindenmaier, Goetz
>> Sent: Monday, March 4, 2019 4:17 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph
>> <christoph.langer at sap.com>; Andrew Hughes <gnu.andrew at redhat.com>
>> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
>> Subject: RE: 8u/11u repo access and Jira changes
>>
>>  Hi Andrew, Aleksey, community,
>>
>> Before, I proposed this, but got no comments:
>>> 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.
>>
>> Should SAP take the role of doing above merges?
>>
>> Best regards,
>>   Goetz
>>

Sorry, I meant to reply with a +1 on this.

Are we planning to do something similar with 8U as well? I guess we
need to first decide when we are ready to do the first merge from 8U-deb.

Thanks,
-- 
Andrew :)

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

PP Key: de25519/0FDA0F9B35964222 (kph://keys.gnu.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CODA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From xxinliu at amazon.com  Wed Mar  6 18:41:02 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 6 Mar 2019 18:41:02 +0000
Subject: [8u]Request for enhancement backport approval for JDK-8077608
 [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode
Message-ID: <D8651354-9793-4B37-828E-8E90879A9BC1@amazon.com>

My  original aim is to solve JDK-8180904: Hotspot tests running with -agentvm failing due to classpath, which appears in Aleksey?s list:
https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-8u212.txt

It turns out that jdk9 solved this problem by JDK-8077608, so I backported it to jdk8u-dev. Here is webrev.
http://cr.openjdk.java.net/~phh/8077608/webrev.8u.00/

I drop ?compiler/uncommontrap/TestUnstableIfTrap.java? because jdk8u-dev misses it. I verified all tests listed JDK-8180904<https://bugs.openjdk.java.net/browse/JDK-8180904> can pass with -agentvm.
Thanks,
--lx

From gnu.andrew at redhat.com  Wed Mar  6 18:49:09 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 6 Mar 2019 18:49:09 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <739e16adb54c490eb551e226b09f84de@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>
 <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>
 <5bcb63d5207144c7b436d3594d9cb789@sap.com>
 <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@mail.gmail.com>
 <739e16adb54c490eb551e226b09f84de@sap.com>
Message-ID: <b3dd243a-d263-b04b-5617-f5b74060eb57@redhat.com>



On 05/03/2019 07:32, Langer, Christoph wrote:
> Hi Andrew,
> 
>> Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-)
> 
> Sure, jdk-11.0.4+0 is already present in jdk11u-dev. :) If jdk-11.0.3+0 is particularly important to you for some reason, we can still tag some change with that label... Do you need that?
> 
> /Christoph
> 

No, it was just a consistency thing. As long as we go from 0 in future,
I'm fine with it as is.

I wasn't aware we were tagging in jdk11u-dev. Is that on a similar
regular cycle?

Thanks,
-- 
Andrew :)

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

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


From shade at redhat.com  Wed Mar  6 19:19:45 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 6 Mar 2019 20:19:45 +0100
Subject: JDK-8217305, JDK-8209002 and fixes
Message-ID: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>

Hi,

There is a public issue that is apparently fixed in 8u212 and 8u222:
  https://bugs.openjdk.java.net/browse/JDK-8217305

However, it seems that the fix went here:
  https://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/499617980681

...and there is a public review thread:
  https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-August/007792.html

...and the relevant issue is not public:
  https://bugs.openjdk.java.net/browse/JDK-8209002

Is there anything special about JDK-8209002? Can it be made public and linked to JDK-8217305?

CC'ing Kevin who is apparently the committer for both fixes. And David, who is trapped in being the
contact person for this kind of stuff over and over again.

Thanks,
-Aleksey


From christoph.langer at sap.com  Wed Mar  6 21:48:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 6 Mar 2019 21:48:08 +0000
Subject: RFR(XS): 8219961: [ppc64] Increase code size for interpreter
 generation.
In-Reply-To: <2d3bfe75-fc1c-941c-1aba-93b3c3beae69@redhat.com>
References: <VI1PR02MB51837BB2AB9931680BC15C78EC760@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <e3040d0c-90f3-f35f-c493-48afc14c0244@redhat.com>
 <AM6PR02MB478822EA6A17924A84AD8EAD9A710@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <VI1PR02MB518324A3C1DC01D5F3F9510DEC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <2d3bfe75-fc1c-941c-1aba-93b3c3beae69@redhat.com>
Message-ID: <HE1PR0201MB22663988E719836C75E08A748A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>

> This seems to have been pushed to the wrong tree (jdk8u rather than
> jdk8u-dev):
> 
> https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/111b95ad4584

Correct. I'll rant at the colleagues. But there's no need to fix anything.

> It also looks like the bug system is still assigning 'openjdk8u' to
> jdk8u pushes.
> 
> https://bugs.openjdk.java.net/browse/JDK-8219961

Also Correct. I fixed the bug to show openjdk8u211 now.

@aph: Can you please request ops to fix the jdk8u repo? Maybe we should at the same time also ask for an openjdk8u212 version because that's what we are working on?

Best regards
Christoph


From christoph.langer at sap.com  Wed Mar  6 21:51:51 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 6 Mar 2019 21:51:51 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <b3dd243a-d263-b04b-5617-f5b74060eb57@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>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <CABi63P4cfkoh3wn8+xFo+nqquWrJ1UCpU26biDB9BNF6h_9tFg@mail.gmail.com>
 <5bcb63d5207144c7b436d3594d9cb789@sap.com>
 <CABi63P76-cK_KJYR21OC8zdUCEjcsfH2Pycb5Ugo+8MSoEGHgQ@mail.gmail.com>
 <739e16adb54c490eb551e226b09f84de@sap.com>
 <b3dd243a-d263-b04b-5617-f5b74060eb57@redhat.com>
Message-ID: <HE1PR0201MB2266C50AB194B74359CBC4E18A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> I wasn't aware we were tagging in jdk11u-dev. Is that on a similar
> regular cycle?

No, the plan is only to tag ...+0 in jdk11u-dev at the moment we branch off to jdk11u (e.g. next time jdk11.0.5+0 end of May/beginning of June). All further tags well be set in jdk11u and will be merged back regularly.

Best regards
Christoph


From christoph.langer at sap.com  Wed Mar  6 22:00:25 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 6 Mar 2019 22:00:25 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <d1fda560-e13d-a202-369d-2f7db006f577@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>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <d1fda560-e13d-a202-369d-2f7db006f577@redhat.com>
Message-ID: <HE1PR0201MB226682CD47ED2EEDAF3812998A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

> >> -----Original Message-----
> >> From: Lindenmaier, Goetz
> >> Sent: Monday, March 4, 2019 4:17 PM
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph
> >> <christoph.langer at sap.com>; Andrew Hughes
> <gnu.andrew at redhat.com>
> >> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> >> Subject: RE: 8u/11u repo access and Jira changes
> >>
> >>  Hi Andrew, Aleksey, community,
> >>
> >> Before, I proposed this, but got no comments:
> >>> 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.
> >>

> Are we planning to do something similar with 8U as well? I guess we
> need to first decide when we are ready to do the first merge from 8U-deb.

I suggest the same should be done with jdk8u.
There are 9 issues left: https://bugs.openjdk.java.net/issues/?filter=36394 I think these should be handled now that we can merge to jdk8u.

I also looked at the tags: There's no +0 tag in 8u (tag format looks a bit different there, anyway). So I suggest after jdk8u-dev was transported to jdk8u, it should be tagged jdk8u212-b1 in jdk8u.

Best regards
Christoph


From hohensee at amazon.com  Wed Mar  6 23:26:39 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 6 Mar 2019 23:26:39 +0000
Subject: [8u]Request for enhancement backport approval for JDK-8077608
 [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode
In-Reply-To: <D8651354-9793-4B37-828E-8E90879A9BC1@amazon.com>
References: <D8651354-9793-4B37-828E-8E90879A9BC1@amazon.com>
Message-ID: <F989A08B-CB2C-48C5-9133-4BA0083BA4DA@amazon.com>

Lgtm. I tagged JDK-8077608 with jdk8u-fix-request. Be good to get another review.

Thanks,

Paul

?On 3/6/19, 10:43 AM, "jdk8u-dev on behalf of Liu, Xin" <jdk8u-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote:

    My  original aim is to solve JDK-8180904: Hotspot tests running with -agentvm failing due to classpath, which appears in Aleksey?s list:
    https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-8u212.txt
    
    It turns out that jdk9 solved this problem by JDK-8077608, so I backported it to jdk8u-dev. Here is webrev.
    http://cr.openjdk.java.net/~phh/8077608/webrev.8u.00/
    
    I drop ?compiler/uncommontrap/TestUnstableIfTrap.java? because jdk8u-dev misses it. I verified all tests listed JDK-8180904<https://bugs.openjdk.java.net/browse/JDK-8180904> can pass with -agentvm.
    Thanks,
    --lx
    


From kevin.walls at oracle.com  Thu Mar  7 07:56:53 2019
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 7 Mar 2019 07:56:53 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
Message-ID: <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>

Hi,

8209002 is a follow-on bug from 8034788 (I added a link), BUT I see now 
that 8209002 is actually not a public bug, although we reviewed it and 
pushed it in public.

I presume when JDK-8209002 was logged, being not public was probably 
because it was reported by something relating to an installer or not in 
the open, or it was thought it might be our internal process issue.? The 
actual fix relates to the build scripts, but by that point the bug 
description/notes may contain? non-public machines/info in notes.

8217305 is more recent, and a very similar change.? They aren't really 
related, not sure they should be linked, although the changes are so 
similar.

8209002 changes JDK_VER.
8217305 changes JDK_FVER.

8217305 is not a confidential bug, but I haven't yet done an open review 
for that one.? The required diff is below to clarify what it's about.? 
If there's impact to the open builds we can do the review/approval 
required to get it there...

Thanks
Kevin


--- a/common/autoconf/flags.m4??? Wed Feb 27 10:51:09 2019 -0800
+++ b/common/autoconf/flags.m4??? Thu Feb 28 02:55:32 2019 -0800
@@ -111,7 +111,7 @@
 ???????? -d 
\"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\" 
\
 ???????? -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
 ???????? -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) 
\$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
-??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
\$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
+??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
\$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
 ?? fi
 ?? AC_SUBST(RC_FLAGS)






On 06/03/2019 19:19, Aleksey Shipilev wrote:
> Hi,
>
> There is a public issue that is apparently fixed in 8u212 and 8u222:
>    https://bugs.openjdk.java.net/browse/JDK-8217305
>
> However, it seems that the fix went here:
>    https://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/499617980681
>
> ...and there is a public review thread:
>    https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-August/007792.html
>
> ...and the relevant issue is not public:
>    https://bugs.openjdk.java.net/browse/JDK-8209002
>
> Is there anything special about JDK-8209002? Can it be made public and linked to JDK-8217305?
>
> CC'ing Kevin who is apparently the committer for both fixes. And David, who is trapped in being the
> contact person for this kind of stuff over and over again.
>
> Thanks,
> -Aleksey
>

From christoph.langer at sap.com  Thu Mar  7 16:22:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Mar 2019 16:22:23 +0000
Subject: 8u: RFR(S) + RFA: 8211106: [windows]  Update OS detection code to
 recognize Windows Server 2019
Message-ID: <HE1PR0201MB2266FFA8614C59A767D3B98A8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

please review and approve the backport of 8211106 to 8u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8211106
Webrev for hotspot: http://cr.openjdk.java.net/~clanger/webrevs/8211106.8u.hotspot.0/
Webrev for jdk: http://cr.openjdk.java.net/~clanger/webrevs/8211106.8u.jdk.0/

The patch applies with minor fuzz. It would be nice, though, if somebody (Aleksey?) could run it through the Windows build + tests, because our infrastructure is not set up for jdk8u testing on Windows.

Thanks & Best regards
Christoph


From shade at redhat.com  Thu Mar  7 16:30:01 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 7 Mar 2019 17:30:01 +0100
Subject: 8u: RFR(S) + RFA: 8211106: [windows] Update OS detection code to
 recognize Windows Server 2019
In-Reply-To: <HE1PR0201MB2266FFA8614C59A767D3B98A8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB2266FFA8614C59A767D3B98A8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <7d242bde-ec2e-f957-c8af-cf30d5111e29@redhat.com>

On 3/7/19 5:22 PM, Langer, Christoph wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211106
> 
> Webrev for hotspot: http://cr.openjdk.java.net/~clanger/webrevs/8211106.8u.hotspot.0/
> Webrev for jdk: http://cr.openjdk.java.net/~clanger/webrevs/8211106.8u.jdk.0/

These look okay. I personally would like to see ">=" comparisons, but given it comes from upstream
in this form, I have to learn with disappointment :)

> The patch applies with minor fuzz. It would be nice, though, if somebody (Aleksey?) could run it
> through the Windows build + tests, because our infrastructure is not set up for jdk8u testing on
> Windows.

Let's ask our friends from Amazon and AdoptOpenJDK!

-Aleksey


From christoph.langer at sap.com  Thu Mar  7 16:15:18 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Mar 2019 16:15:18 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <CB79028C-6BD2-4515-88C0-3CCA08F9E739@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>
 <e396558c68dc46b580210c748c8ab345@sap.com>
 <CB79028C-6BD2-4515-88C0-3CCA08F9E739@amazon.com>
Message-ID: <HE1PR0201MB2266B50CCDE98A08CFAFD5BD8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Paul,

> I don't know which is which. The last few pushes I've done have been the
> result of "hg commit -u <original-assignee>", which results in the original
> assignee being recorded as the backport assignee. I don't know how to put
> both that person's name and the backport author into the same issue.

-u should contain the original author, not the backport assignee or backport author.

Best regards
Christoph


From hohensee at amazon.com  Thu Mar  7 19:43:31 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 7 Mar 2019 19:43:31 +0000
Subject: [8u] RFA 8204142: AWT hang occurs when sequenced events arrive
 out of sequence in multiple AppContexts
In-Reply-To: <HE1PR0201MB2266B50CCDE98A08CFAFD5BD8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.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>
 <e396558c68dc46b580210c748c8ab345@sap.com>
 <CB79028C-6BD2-4515-88C0-3CCA08F9E739@amazon.com>
 <HE1PR0201MB2266B50CCDE98A08CFAFD5BD8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <BE9C38FC-A6FB-44F3-8896-28E972EB284A@amazon.com>

Right, that's what I've been doing.

?On 3/7/19, 8:35 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi Paul,
    
    > I don't know which is which. The last few pushes I've done have been the
    > result of "hg commit -u <original-assignee>", which results in the original
    > assignee being recorded as the backport assignee. I don't know how to put
    > both that person's name and the backport author into the same issue.
    
    -u should contain the original author, not the backport assignee or backport author.
    
    Best regards
    Christoph
    
    


From hohensee at amazon.com  Thu Mar  7 19:46:51 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 7 Mar 2019 19:46:51 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
Message-ID: <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>

I tagged JDK-8217305 with jdk8u-fix-request.

Paul

?On 3/6/19, 11:58 PM, "jdk8u-dev on behalf of Kevin Walls" <jdk8u-dev-bounces at openjdk.java.net on behalf of kevin.walls at oracle.com> wrote:

    Hi,
    
    8209002 is a follow-on bug from 8034788 (I added a link), BUT I see now 
    that 8209002 is actually not a public bug, although we reviewed it and 
    pushed it in public.
    
    I presume when JDK-8209002 was logged, being not public was probably 
    because it was reported by something relating to an installer or not in 
    the open, or it was thought it might be our internal process issue.  The 
    actual fix relates to the build scripts, but by that point the bug 
    description/notes may contain  non-public machines/info in notes.
    
    8217305 is more recent, and a very similar change.  They aren't really 
    related, not sure they should be linked, although the changes are so 
    similar.
    
    8209002 changes JDK_VER.
    8217305 changes JDK_FVER.
    
    8217305 is not a confidential bug, but I haven't yet done an open review 
    for that one.  The required diff is below to clarify what it's about.  
    If there's impact to the open builds we can do the review/approval 
    required to get it there...
    
    Thanks
    Kevin
    
    
    --- a/common/autoconf/flags.m4    Wed Feb 27 10:51:09 2019 -0800
    +++ b/common/autoconf/flags.m4    Thu Feb 28 02:55:32 2019 -0800
    @@ -111,7 +111,7 @@
              -d 
    \"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\" 
    \
              -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
              -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) 
    \$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
    -        -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
    \$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
    +        -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
    \$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
        fi
        AC_SUBST(RC_FLAGS)
    
    
    
    
    
    
    On 06/03/2019 19:19, Aleksey Shipilev wrote:
    > Hi,
    >
    > There is a public issue that is apparently fixed in 8u212 and 8u222:
    >    https://bugs.openjdk.java.net/browse/JDK-8217305
    >
    > However, it seems that the fix went here:
    >    https://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/499617980681
    >
    > ...and there is a public review thread:
    >    https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-August/007792.html
    >
    > ...and the relevant issue is not public:
    >    https://bugs.openjdk.java.net/browse/JDK-8209002
    >
    > Is there anything special about JDK-8209002? Can it be made public and linked to JDK-8217305?
    >
    > CC'ing Kevin who is apparently the committer for both fixes. And David, who is trapped in being the
    > contact person for this kind of stuff over and over again.
    >
    > Thanks,
    > -Aleksey
    >
    


From hohensee at amazon.com  Thu Mar  7 20:04:09 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 7 Mar 2019 20:04:09 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
Message-ID: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>

We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 backports left on the u211/212 list. One is out for review (JDK-8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re all pretty small. Just need jdk8u-fix-yes tags. :)

I haven?t seen code freeze dates for non-embargoed patches candidates, but may have missed them going by. If they aren?t yet determined, it?d be excellent to have them so we can plan rampdown.

Thanks,

Paul


From hohensee at amazon.com  Thu Mar  7 20:10:10 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 7 Mar 2019 20:10:10 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
Message-ID: <61B8D31A-696A-42B7-B1EF-A56318EB15E7@amazon.com>

But the presence of 11.0.3 tags means I missed that 11.0.3 has already been forked for rampdown, correct?

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

    We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 backports left on the u211/212 list. One is out for review (JDK-8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re all pretty small. Just need jdk8u-fix-yes tags. :)
    
    I haven?t seen code freeze dates for non-embargoed patches candidates, but may have missed them going by. If they aren?t yet determined, it?d be excellent to have them so we can plan rampdown.
    
    Thanks,
    
    Paul
    
    


From christoph.langer at sap.com  Thu Mar  7 23:16:44 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Mar 2019 23:16:44 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <61B8D31A-696A-42B7-B1EF-A56318EB15E7@amazon.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <61B8D31A-696A-42B7-B1EF-A56318EB15E7@amazon.com>
Message-ID: <HE1PR0201MB22669F48BB4CEDEB9EE1497E8A4C0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Paul,

I've updated the Wiki https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u yesterday, adding some process description and timeline information. Didn't get feedback from Andrew so far. But I think I should add similar information to https://wiki.openjdk.java.net/display/jdk8u as well.

> But the presence of 11.0.3 tags means I missed that 11.0.3 has already been
> forked for rampdown, correct?

Yes, 11.03 has been moved to the jdk11u repository for rampdown. jdk11u-dev is now the working repository for 11.0.4.

>     We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There
> are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There
> are 9 backports left on the u211/212 list. One is out for review (JDK-
> 8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to
> be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re
> all pretty small. Just need jdk8u-fix-yes tags. :)
> 
>     I haven?t seen code freeze dates for non-embargoed patches candidates,
> but may have missed them going by. If they aren?t yet determined, it?d be
> excellent to have them so we can plan rampdown.

It would be great if you can do the remaining 6 issues. As soon as the list of backports is empty, we shall do the rampdown. For 8u222 and following we can do this hopefully a bit earlier.

Best regards
Christoph


From gnu.andrew at redhat.com  Mon Mar 11 04:36:44 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 04:36:44 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <HE1PR0201MB226682CD47ED2EEDAF3812998A730@HE1PR0201MB2266.eurprd02.prod.outlook.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>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <d1fda560-e13d-a202-369d-2f7db006f577@redhat.com>
 <HE1PR0201MB226682CD47ED2EEDAF3812998A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <4efa6e6f-ae3a-e912-615f-11bb743dd5ca@redhat.com>

On 06/03/2019 22:00, Langer, Christoph wrote

snip...

> I also looked at the tags: There's no +0 tag in 8u (tag format looks a bit different there, anyway). So I suggest after jdk8u-dev was transported to jdk8u, it should be tagged jdk8u212-b1 in jdk8u.
> 
> Best regards
> Christoph
> 

jdk8u212-b00 I'd say:

$ cat ../upstream/jdk8/.hgtags |grep '\-b00'|tail|uniq
ccac71a8778d18186967618df12bd2612d758f4b jdk8u162-b00
d66f57333c7fcc735f87eb0903ffdc0aaf899b32 jdk8u171-b00
f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00
e91f5717d8a5df396c8646da9b5a7bcd526bf288 jdk8u172-b00
f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00
dda7b81e20a3bb3ea6877d93dd6145381b52b6e4 jdk8u191-b00
d6007fa4ffae140f4c4ad551a1ee290a0704a094 jdk8u201-b00
3b5b53db61f2aaa5a94fd9ca51162d83565faabe jdk8u182-b00
dcfe85bcd9017741198b4e4a2045fdaaab212c74 jdk8u192-b00
6d8d269ee313fb1420375c2a81dd71c0b660a65f jdk8u202-b00

-- 
Andrew :)

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

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


From christoph.langer at sap.com  Mon Mar 11 07:22:24 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Mar 2019 07:22:24 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <4efa6e6f-ae3a-e912-615f-11bb743dd5ca@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>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <d1fda560-e13d-a202-369d-2f7db006f577@redhat.com>
 <HE1PR0201MB226682CD47ED2EEDAF3812998A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <4efa6e6f-ae3a-e912-615f-11bb743dd5ca@redhat.com>
Message-ID: <HE1PR0201MB22668ACD8191C5F81EE92DF08A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

> snip...
> 
> > I also looked at the tags: There's no +0 tag in 8u (tag format looks a bit
> > different there, anyway). So I suggest after jdk8u-dev was transported to
> > jdk8u, it should be tagged jdk8u212-b1 in jdk8u.
> 
> jdk8u212-b00 I'd say:
> 
> $ cat ../upstream/jdk8/.hgtags |grep '\-b00'|tail|uniq
> ccac71a8778d18186967618df12bd2612d758f4b jdk8u162-b00
> d66f57333c7fcc735f87eb0903ffdc0aaf899b32 jdk8u171-b00
> f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00
> e91f5717d8a5df396c8646da9b5a7bcd526bf288 jdk8u172-b00
> f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00
> dda7b81e20a3bb3ea6877d93dd6145381b52b6e4 jdk8u191-b00
> d6007fa4ffae140f4c4ad551a1ee290a0704a094 jdk8u201-b00
> 3b5b53db61f2aaa5a94fd9ca51162d83565faabe jdk8u182-b00
> dcfe85bcd9017741198b4e4a2045fdaaab212c74 jdk8u192-b00
> 6d8d269ee313fb1420375c2a81dd71c0b660a65f jdk8u202-b00

Ok, right.

We could set it now but we should make up our minds about jdk8u211 vs. jdk8u212 first.

Best regards
Christoph


From gnu.andrew at redhat.com  Mon Mar 11 07:24:48 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 07:24:48 +0000
Subject: [RFR] 8217753: Enable HotSpot builds on 5.x Linux kernels
Message-ID: <34de76b6-5ef8-c9fe-0514-e969bd58a788@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8217753
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8217753/webrev.01/

This is 8u and below only as it's part of the old HotSpot build replaced
in 9+.

There's a check in make/linux/Makefile to ensure that a 2.4 or later
kernel is being used. This has been extended by JDK-7072341 to
accommodate Linux 3.x and JDK-8074312 for 4.x. 5.x is now imminent [0]
and the build is broken again [1].

Given that 2.4 was released over 18 years ago [2], I think now is the
time to just get rid of this check rather than bumping it yet again. If
anyone is really trying to build OpenJDK 8 on a 2.2 kernel, I suspect
they will encounter other issues than a Makefile check, and it seems far
more likely that, if we just add a '5%' check, someone is going to build
with Linux 6.x in a few years and hit this same bug again.

[0] https://lwn.net/Articles/776034/
[1] https://bugs.gentoo.org/675920
[2] http://lkml.iu.edu/hypermail/linux/kernel/0101.0/0776.html
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar 11 07:33:16 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 07:33:16 +0000
Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
Message-ID: <2f310840-ec43-1c4a-2c73-bf5968163c63@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/

When JDK-8036003 was backported, it added a bunch of conditionals in
make/common/NativeCompilation.gmk which cause debuginfo to not be
generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
were missed, causing the build to fail, because there's no dependency
for the .diz target.

I suspect this doesn't show up when the new configure option is
specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
does regress my existing builds which don't specify that option.

Simple fix and 8u only.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar 11 07:50:33 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 07:50:33 +0000
Subject: [RFR] 8175120: Remove old tests on kdc timeout policy
Message-ID: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/
Original review:
https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html

This is not a clean backport because the tests in 8u differ slightly
from those in OpenJDK 10:

1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
That same change (adding a property to the @run line) also needs to be
applied to the new KdcPolicy.java test for it to succeed.

2. 10u contains "JDK-8006690: sun/security/krb5/auto/BadKdc* tests fails
intermittently" which I assume is obsoleted by the more reliable
KdcPolicy.java test

Strangely enough, this & JDK-8164656 were already approved last July,
but never pushed [0].  I can't see how this was a straightforward
backport then though either.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007667.html
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar 11 08:06:02 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 08:06:02 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
Message-ID: <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>

On 07/03/2019 20:04, Hohensee, Paul wrote:
> We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 backports left on the u211/212 list. One is out for review (JDK-8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re all pretty small. Just need jdk8u-fix-yes tags. :)
> 
> I haven?t seen code freeze dates for non-embargoed patches candidates, but may have missed them going by. If they aren?t yet determined, it?d be excellent to have them so we can plan rampdown.
> 
> Thanks,
> 
> Paul
> 

It'd be helpful if you could link to the list you're referring to, so
we're all the same page :)

Assuming this was [0], it's now down to 4 and I've just posted a review
for JDK-8175120

I also pushed JDK-8164656 & JDK-7127191 as they were approved clean
backports.

Of the approved but pending push list [2], I plan to look at JDK-8189761
next which depends on JDK-8193764 [3] being approved as a pre-requisite.

I'm also waiting on review & approval for JDK-8217753 [4] and
JDK-8220397 [5]

I think that just leaves JDK-8217305, JDK-8213825, JDK-8180904 &
JDK-8077608. I think Aleksey is looking at the first two and you're on
the second two.

JDK-8213983 is the only unapproved bug on [0] and seems to be a Mac OS
issue. I think Aleksey has looked at it though, from the bug history.

As to a final freeze, I think we agreed the first of the embargo month,
so the 1st of April for 2019-04.

[0] https://bugs.openjdk.java.net/browse/JDK-8217305?filter=36396
[1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html
[2] https://bugs.openjdk.java.net/browse/JDK-8175120?filter=36427
[3] https://bugs.openjdk.java.net/browse/JDK-8193764
[4] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008844.html
[5] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008845.html
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar 11 08:08:01 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 08:08:01 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <HE1PR0201MB22668ACD8191C5F81EE92DF08A480@HE1PR0201MB2266.eurprd02.prod.outlook.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>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <d1fda560-e13d-a202-369d-2f7db006f577@redhat.com>
 <HE1PR0201MB226682CD47ED2EEDAF3812998A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <4efa6e6f-ae3a-e912-615f-11bb743dd5ca@redhat.com>
 <HE1PR0201MB22668ACD8191C5F81EE92DF08A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <59b44218-87b3-3d1a-c0ea-0c22e3bdeb81@redhat.com>

On 11/03/2019 07:22, Langer, Christoph wrote:
> Hi,
> 
>> snip...
>>
>>> I also looked at the tags: There's no +0 tag in 8u (tag format looks a bit
>>> different there, anyway). So I suggest after jdk8u-dev was transported to
>>> jdk8u, it should be tagged jdk8u212-b1 in jdk8u.
>>
>> jdk8u212-b00 I'd say:
>>
>> $ cat ../upstream/jdk8/.hgtags |grep '\-b00'|tail|uniq
>> ccac71a8778d18186967618df12bd2612d758f4b jdk8u162-b00
>> d66f57333c7fcc735f87eb0903ffdc0aaf899b32 jdk8u171-b00
>> f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00
>> e91f5717d8a5df396c8646da9b5a7bcd526bf288 jdk8u172-b00
>> f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00
>> dda7b81e20a3bb3ea6877d93dd6145381b52b6e4 jdk8u191-b00
>> d6007fa4ffae140f4c4ad551a1ee290a0704a094 jdk8u201-b00
>> 3b5b53db61f2aaa5a94fd9ca51162d83565faabe jdk8u182-b00
>> dcfe85bcd9017741198b4e4a2045fdaaab212c74 jdk8u192-b00
>> 6d8d269ee313fb1420375c2a81dd71c0b660a65f jdk8u202-b00
> 
> Ok, right.
> 
> We could set it now but we should make up our minds about jdk8u211 vs. jdk8u212 first.
> 
> Best regards
> Christoph
> 

I thought we already made up our minds on 8u212. The whole 8u211 thing
was a mistake of habit on my part.

Thanks,
-- 
Andrew :)

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

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


From christoph.langer at sap.com  Mon Mar 11 08:13:22 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Mar 2019 08:13:22 +0000
Subject: 8u/11u repo access and Jira changes
In-Reply-To: <59b44218-87b3-3d1a-c0ea-0c22e3bdeb81@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>
 <CABi63P4FaxHW8enL-ERhwpi=1Des6dWcy5py7um8-yYUOPvE-A@mail.gmail.com>
 <3f49543e8bd14cf5b3ed7381abaad339@sap.com>
 <90c57878b5254c6ca2d496a2a59b8eb8@sap.com>
 <VI1PR02MB5183AA4C4235B9C51F55ED60EC710@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB5183CE702DCEC2E29DADA64AEC720@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <d1fda560-e13d-a202-369d-2f7db006f577@redhat.com>
 <HE1PR0201MB226682CD47ED2EEDAF3812998A730@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <4efa6e6f-ae3a-e912-615f-11bb743dd5ca@redhat.com>
 <HE1PR0201MB22668ACD8191C5F81EE92DF08A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <59b44218-87b3-3d1a-c0ea-0c22e3bdeb81@redhat.com>
Message-ID: <HE1PR0201MB22669EDC5D60B29458C6F3178A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

> I thought we already made up our minds on 8u212. The whole 8u211 thing
> was a mistake of habit on my part.

Ok, that's what I tought. So, @Andrew Haley: Please request openjdk8u212 from ops and have them set up both forests, 8u and 8u-dev, for it - if you haven't done so already.

Thanks
Christoph


From sgehwolf at redhat.com  Mon Mar 11 10:45:28 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Mar 2019 11:45:28 +0100
Subject: [8u] RFR: 8219772: EXTRA_CFLAGS not being picked up for assembler
 files
Message-ID: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>

Hi,

Could somebody please review this one-liner change for the 8u (OpenJDK)
build system? The issue at hand is that for assembler source files
extra C flags are not being passed to the compiler (GCC in the Linux
case). This is a problem for instrumented builds to facilitate checks
on produced binaries in terms of optimization flags and other build-
time invariants[1]. The patch doesn't affect builds without extra C-
flags. Thus, risk should be minimal.

This is an 8u-only change. The new build system in JDK 11 and up seems
to handle these cases correctly.

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

Testing: Compiling with extra cflags, inspecting build logs for
assembler source files on Linux x86_64

Thoughts?

Thanks,
Severin

[1] https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/


From sgehwolf at redhat.com  Mon Mar 11 11:04:16 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Mar 2019 12:04:16 +0100
Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
In-Reply-To: <2f310840-ec43-1c4a-2c73-bf5968163c63@redhat.com>
References: <2f310840-ec43-1c4a-2c73-bf5968163c63@redhat.com>
Message-ID: <bf0b88e69446028570faa064710dae7fdf5e8658.camel@redhat.com>

On Mon, 2019-03-11 at 07:33 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/
> 
> When JDK-8036003 was backported, it added a bunch of conditionals in
> make/common/NativeCompilation.gmk which cause debuginfo to not be
> generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
> were missed, causing the build to fail, because there's no dependency
> for the .diz target.
> 
> I suspect this doesn't show up when the new configure option is
> specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
> does regress my existing builds which don't specify that option.

Sorry, but I'm not sure why this would be needed? There is a new
configure flag supporting these use-cases (including yours?):

no debug symbols: --with-native-debug-symbols=none (or old mechanims)
zipped debug symbols: --with-native-debug-symbols=zipped (or old mechanism)
no stripping at all: --with-native-debug-symbols=internal (no supported way previously)
external debug symbols: --with-native-debug-symbols=external (or old mechanism)

Why would you want to continue some unsupported way to produce the
equivalent of --with-native-debug-symbols=internal?

> Simple fix and 8u only.

Fix is simple enough, but it also encourages people to *not* change
their build scripts to the supported configure option :-(

Thanks,
Severin


From sgehwolf at redhat.com  Mon Mar 11 13:39:51 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Mar 2019 14:39:51 +0100
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
Message-ID: <24b6996abb7b886ea2c6cf1fe5d69cfc6eab2267.camel@redhat.com>

On Mon, 2019-03-11 at 08:06 +0000, Andrew John Hughes wrote:
> JDK-8213983 is the only unapproved bug on [0] and seems to be a Mac OS
> issue. I think Aleksey has looked at it though, from the bug history.

I'm looking at JDK-8213983 for JDK 8.

> As to a final freeze, I think we agreed the first of the embargo month,
> so the 1st of April for 2019-04.
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8217305?filter=36396

--^ should probably be:
https://bugs.openjdk.java.net/issues/?filter=36394

> [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8175120?filter=36427

--^ should probably be:
https://bugs.openjdk.java.net/issues/?filter=36427

> [3] https://bugs.openjdk.java.net/browse/JDK-8193764
> [4] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008844.html
> [5] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008845.html

Thanks,
Severin


From christoph.langer at sap.com  Mon Mar 11 13:43:37 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Mar 2019 13:43:37 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
Message-ID: <HE1PR0201MB226608F2106E93CDF8D1A7D98A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> It'd be helpful if you could link to the list you're referring to, so
> we're all the same page :)
> 
> Assuming this was [0], it's now down to 4 and I've just posted a review
> for JDK-8175120

Your link [0], that is: https://bugs.openjdk.java.net/issues/?filter=36396 is either wrong or your private filter. A public filter that we can all see is: https://bugs.openjdk.java.net/issues/?filter=36394. I assume that's what you mean. It lists the differences to Oracle for 8u212.

> I think that just leaves JDK-8217305, JDK-8213825, JDK-8180904 &
> JDK-8077608. I think Aleksey is looking at the first two and you're on
> the second two.

From those bugs there are JDK-8217305 and JDK-8180904 on the list that I shared.

> JDK-8213983 is the only unapproved bug on [0] and seems to be a Mac OS
> issue. I think Aleksey has looked at it though, from the bug history.

This one is on the list as well. I hope it can be resolved within this week.

> As to a final freeze, I think we agreed the first of the embargo month,
> so the 1st of April for 2019-04.

Yep. We should, however, close the list above as early as we can and transport to jdk8u when it is empty.

Best regards
Christoph


From christoph.langer at sap.com  Mon Mar 11 13:45:26 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Mar 2019 13:45:26 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <24b6996abb7b886ea2c6cf1fe5d69cfc6eab2267.camel@redhat.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
 <24b6996abb7b886ea2c6cf1fe5d69cfc6eab2267.camel@redhat.com>
Message-ID: <HE1PR0201MB226649BA33135214487F46698A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Severin,

> On Mon, 2019-03-11 at 08:06 +0000, Andrew John Hughes wrote:
> > JDK-8213983 is the only unapproved bug on [0] and seems to be a Mac OS
> > issue. I think Aleksey has looked at it though, from the bug history.
> 
> I'm looking at JDK-8213983 for JDK 8.

Thanks ??

Our mails have crossed...

/Christoph

From hohensee at amazon.com  Mon Mar 11 16:21:03 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 11 Mar 2019 16:21:03 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <HE1PR0201MB226649BA33135214487F46698A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
 <24b6996abb7b886ea2c6cf1fe5d69cfc6eab2267.camel@redhat.com>
 <HE1PR0201MB226649BA33135214487F46698A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <2D49E85F-5315-4536-9B3A-9C29CE89C018@amazon.com>

I've been using https://bugs.openjdk.java.net/issues/?filter=36394 to find u212 issues.

Just pushed patch for 8180904/8077608. So we're down to 8213983 (OSX issue, Christoph),  8175120 (out for review, Andrew H) and 8217305 (Windows issue, Aleksey).

Paul

?On 3/11/19, 6:46 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 Severin,
    
    > On Mon, 2019-03-11 at 08:06 +0000, Andrew John Hughes wrote:
    > > JDK-8213983 is the only unapproved bug on [0] and seems to be a Mac OS
    > > issue. I think Aleksey has looked at it though, from the bug history.
    > 
    > I'm looking at JDK-8213983 for JDK 8.
    
    Thanks ??
    
    Our mails have crossed...
    
    /Christoph
    


From christoph.langer at sap.com  Mon Mar 11 16:24:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Mar 2019 16:24:02 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <2D49E85F-5315-4536-9B3A-9C29CE89C018@amazon.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
 <24b6996abb7b886ea2c6cf1fe5d69cfc6eab2267.camel@redhat.com>
 <HE1PR0201MB226649BA33135214487F46698A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <2D49E85F-5315-4536-9B3A-9C29CE89C018@amazon.com>
Message-ID: <HE1PR0201MB22667B3CDF152D8463761EC38A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>

> I've been using https://bugs.openjdk.java.net/issues/?filter=36394 to find
> u212 issues.
> 
> Just pushed patch for 8180904/8077608. So we're down to 8213983 (OSX
> issue, Christoph),  8175120 (out for review, Andrew H) and 8217305
> (Windows issue, Aleksey).

Correction: 8213983 (OSX issue, Severin) ??

From erik.joelsson at oracle.com  Mon Mar 11 16:27:58 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 11 Mar 2019 09:27:58 -0700
Subject: [8u] RFR: 8219772: EXTRA_CFLAGS not being picked up for assembler
 files
In-Reply-To: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>
References: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>
Message-ID: <abad036a-904b-4cc1-258f-0a127cbbf0db@oracle.com>

I think that's ok.

/Erik

On 2019-03-11 03:45, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review this one-liner change for the 8u (OpenJDK)
> build system? The issue at hand is that for assembler source files
> extra C flags are not being passed to the compiler (GCC in the Linux
> case). This is a problem for instrumented builds to facilitate checks
> on produced binaries in terms of optimization flags and other build-
> time invariants[1]. The patch doesn't affect builds without extra C-
> flags. Thus, risk should be minimal.
>
> This is an 8u-only change. The new build system in JDK 11 and up seems
> to handle these cases correctly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219772
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219772/01/webrev/
>
> Testing: Compiling with extra cflags, inspecting build logs for
> assembler source files on Linux x86_64
>
> Thoughts?
>
> Thanks,
> Severin
>
> [1] https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/
>

From sgehwolf at redhat.com  Mon Mar 11 16:35:07 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Mar 2019 17:35:07 +0100
Subject: [8u] RFR: 8219772: EXTRA_CFLAGS not being picked up for
 assembler files
In-Reply-To: <abad036a-904b-4cc1-258f-0a127cbbf0db@oracle.com>
References: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>
 <abad036a-904b-4cc1-258f-0a127cbbf0db@oracle.com>
Message-ID: <32f681e22181f07a6ca05edcff9cf7a37180fcca.camel@redhat.com>

On Mon, 2019-03-11 at 09:27 -0700, Erik Joelsson wrote:
> I think that's ok.

Thanks for the review, Erik!

Cheers,
Severin

> /Erik
> 
> On 2019-03-11 03:45, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review this one-liner change for the 8u (OpenJDK)
> > build system? The issue at hand is that for assembler source files
> > extra C flags are not being passed to the compiler (GCC in the Linux
> > case). This is a problem for instrumented builds to facilitate checks
> > on produced binaries in terms of optimization flags and other build-
> > time invariants[1]. The patch doesn't affect builds without extra C-
> > flags. Thus, risk should be minimal.
> > 
> > This is an 8u-only change. The new build system in JDK 11 and up seems
> > to handle these cases correctly.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219772
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219772/01/webrev/
> > 
> > Testing: Compiling with extra cflags, inspecting build logs for
> > assembler source files on Linux x86_64
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > [1] https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/
> > 


From gnu.andrew at redhat.com  Mon Mar 11 17:40:51 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 17:40:51 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <HE1PR0201MB226608F2106E93CDF8D1A7D98A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
 <HE1PR0201MB226608F2106E93CDF8D1A7D98A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <0201e7ac-a468-9527-4d32-4c44b896ff21@redhat.com>

On 11/03/2019 13:43, Langer, Christoph wrote:
> Hi Andrew,
> 
>> It'd be helpful if you could link to the list you're referring to, so
>> we're all the same page :)
>>
>> Assuming this was [0], it's now down to 4 and I've just posted a review
>> for JDK-8175120
> 
> Your link [0], that is: https://bugs.openjdk.java.net/issues/?filter=36396 is either wrong or your private filter. A public filter that we can all see is: https://bugs.openjdk.java.net/issues/?filter=36394. I assume that's what you mean. It lists the differences to Oracle for 8u212.
> 

Ugh, yes, that's right. JIRA rewrites these URLs when it opens them into
the format I posted. 36396 & 36394 produce identical results and it's
not obvious on this end that one is private :( I can't see an option to
make one public either.

>> I think that just leaves JDK-8217305, JDK-8213825, JDK-8180904 &
>> JDK-8077608. I think Aleksey is looking at the first two and you're on
>> the second two.
> 
> From those bugs there are JDK-8217305 and JDK-8180904 on the list that I shared.
> 

You seem to have snipped a bit of my e-mail here. This is referring to
the pending push list: https://bugs.openjdk.java.net/issues/?filter=36427

It's a moving target so what I wrote in an e-mail may not be true when
you follow the link from that e-mail :) In this case, I think Paul dealt
with 8077608 in the interim.

That list is currently:

* JDk-8217305: Windows build issue (Aleksey)
* JDK-8213825: assertion fix (Aleksey)
* JDK-8189761: versioning fix, waiting on approval of 8193764 (gnu_andrew)
* JDK-8175120: Kerberos tests, out for review (gnu_andrew)

Two of those are our suggestions, and so aren't on the Oracle list
(8213825 & 8189761)

>> JDK-8213983 is the only unapproved bug on [0] and seems to be a Mac OS
>> issue. I think Aleksey has looked at it though, from the bug history.
> 
> This one is on the list as well. I hope it can be resolved within this week.
> 
>> As to a final freeze, I think we agreed the first of the embargo month,
>> so the 1st of April for 2019-04.
> 
> Yep. We should, however, close the list above as early as we can and transport to jdk8u when it is empty.
> 

Yes, that's the final date when I expect nothing more to be accepted
into the release except security patches or critical, stop-the-train
stuff. I'd expect the first merge + tag to jdk8u to be this week.

> Best regards
> Christoph
> 

Best regards,
-- 
Andrew :)

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

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


From martinrb at google.com  Mon Mar 11 17:58:46 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Mar 2019 10:58:46 -0700
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <0201e7ac-a468-9527-4d32-4c44b896ff21@redhat.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
 <HE1PR0201MB226608F2106E93CDF8D1A7D98A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <0201e7ac-a468-9527-4d32-4c44b896ff21@redhat.com>
Message-ID: <CA+kOe08-NZG2Y3AKvLwU7wGpap0Mh_7jKgNz5X2VwvkiTbwOwg@mail.gmail.com>

On Mon, Mar 11, 2019 at 10:42 AM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:

>
> Ugh, yes, that's right. JIRA rewrites these URLs when it opens them into
> the format I posted.


Yes, that's annoying!


> 36396 & 36394 produce identical results and it's
> not obvious on this end that one is private :( I can't see an option to
> make one public either.
>
>
I believe you can make filters you own public via:
- visit filter
- Details -> Edit permissions

From gnu.andrew at redhat.com  Mon Mar 11 18:01:01 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 18:01:01 +0000
Subject: [8u] RFR: 8219772: EXTRA_CFLAGS not being picked up for assembler
 files
In-Reply-To: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>
References: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>
Message-ID: <0ff9a2d7-d8ee-582d-0332-00a3a4e72edb@redhat.com>



On 11/03/2019 10:45, Severin Gehwolf wrote:
> Hi,
> 
> Could somebody please review this one-liner change for the 8u (OpenJDK)
> build system? The issue at hand is that for assembler source files
> extra C flags are not being passed to the compiler (GCC in the Linux
> case). This is a problem for instrumented builds to facilitate checks
> on produced binaries in terms of optimization flags and other build-
> time invariants[1]. The patch doesn't affect builds without extra C-
> flags. Thus, risk should be minimal.
> 
> This is an 8u-only change. The new build system in JDK 11 and up seems
> to handle these cases correctly.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219772
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219772/01/webrev/
> 
> Testing: Compiling with extra cflags, inspecting build logs for
> assembler source files on Linux x86_64
> 
> Thoughts?
> 
> Thanks,
> Severin
> 
> [1] https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/
> 

Surely the correct way to do this is to add an --with-extra-asflags
option rather than abuse flags for the C compiler?

The 11 version in make/autoconf/flags-other.m4 states:

  # Misuse EXTRA_CFLAGS to mimic old behavior

  $2JVM_ASFLAGS="$JVM_BASIC_ASFLAGS ${$2EXTRA_CFLAGS}"

which suggests this might not be the best way to do this. I'm not sure
what old behaviour it is trying to emulate if 8u doesn't support this.

Either way, I think this is a change that should wait until 8u222 at
this point.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar 11 18:05:40 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 18:05:40 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <CA+kOe08-NZG2Y3AKvLwU7wGpap0Mh_7jKgNz5X2VwvkiTbwOwg@mail.gmail.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <7f158643-95e3-da7b-bc0f-182c7d6d6b5f@redhat.com>
 <HE1PR0201MB226608F2106E93CDF8D1A7D98A480@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <0201e7ac-a468-9527-4d32-4c44b896ff21@redhat.com>
 <CA+kOe08-NZG2Y3AKvLwU7wGpap0Mh_7jKgNz5X2VwvkiTbwOwg@mail.gmail.com>
Message-ID: <b55dfe59-7483-5f37-a632-74ac5f9d2c22@redhat.com>



On 11/03/2019 17:58, Martin Buchholz wrote:
> 
> 
> On Mon, Mar 11, 2019 at 10:42 AM Andrew John Hughes
> <gnu.andrew at redhat.com <mailto:gnu.andrew at redhat.com>> wrote:
> 
> 
>     Ugh, yes, that's right. JIRA rewrites these URLs when it opens them into
>     the format I posted. 
> 
> 
> Yes, that's annoying!
> ?
> 
>     36396 & 36394 produce identical results and it's
>     not obvious on this end that one is private :( I can't see an option to
>     make one public either.
> 
> 
> I believe you can make filters you own public via:
> - visit filter
> - Details -> Edit permissions
> ?

Ah, thanks for that, Martin. I think I've fixed that one now and also
the more useful one I created for 7u221:

https://bugs.openjdk.java.net/issues/?filter=36489

Thanks,
-- 
Andrew :)

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

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


From shade at redhat.com  Mon Mar 11 18:09:41 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 11 Mar 2019 19:09:41 +0100
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
Message-ID: <3915722e-10cd-d248-1d19-4740db636894@redhat.com>

On 3/7/19 8:46 PM, Hohensee, Paul wrote:
> I tagged JDK-8217305 with jdk8u-fix-request.

Have you been doing the work for it? Generally, if you put the tag, it is expected that you also put
the appropriate "Fix Request" comment, which implies you did the backporting work.

> ?On 3/6/19, 11:58 PM, "jdk8u-dev on behalf of Kevin Walls" <jdk8u-dev-bounces at openjdk.java.net on behalf of kevin.walls at oracle.com> wrote:
>     8209002 changes JDK_VER.
>     8217305 changes JDK_FVER.
>     
>     8217305 is not a confidential bug, but I haven't yet done an open review 
>     for that one.  The required diff is below to clarify what it's about.  
>     If there's impact to the open builds we can do the review/approval 
>     required to get it there...
>     
>     --- a/common/autoconf/flags.m4    Wed Feb 27 10:51:09 2019 -0800
>     +++ b/common/autoconf/flags.m4    Thu Feb 28 02:55:32 2019 -0800
>     @@ -111,7 +111,7 @@
>               -d 
>     \"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\" 
>     \
>               -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
>               -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) 
>     \$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
>     -        -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
>     \$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
>     +        -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
>     \$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
>         fi
>         AC_SUBST(RC_FLAGS)

Hey Kevin, do I understand correctly this is the exact fix for 8217305 for 8u? If so, I'd be working
to get it into 8u.

Thanks,
-Aleksey



From gnu.andrew at redhat.com  Mon Mar 11 18:09:49 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 18:09:49 +0000
Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
In-Reply-To: <bf0b88e69446028570faa064710dae7fdf5e8658.camel@redhat.com>
References: <2f310840-ec43-1c4a-2c73-bf5968163c63@redhat.com>
 <bf0b88e69446028570faa064710dae7fdf5e8658.camel@redhat.com>
Message-ID: <8915ca28-09e9-391b-86d2-2ac675586e0a@redhat.com>



On 11/03/2019 11:04, Severin Gehwolf wrote:
> On Mon, 2019-03-11 at 07:33 +0000, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/
>>
>> When JDK-8036003 was backported, it added a bunch of conditionals in
>> make/common/NativeCompilation.gmk which cause debuginfo to not be
>> generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
>> were missed, causing the build to fail, because there's no dependency
>> for the .diz target.
>>
>> I suspect this doesn't show up when the new configure option is
>> specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
>> does regress my existing builds which don't specify that option.
> 
> Sorry, but I'm not sure why this would be needed? There is a new
> configure flag supporting these use-cases (including yours?):
> 
> no debug symbols: --with-native-debug-symbols=none (or old mechanims)
> zipped debug symbols: --with-native-debug-symbols=zipped (or old mechanism)
> no stripping at all: --with-native-debug-symbols=internal (no supported way previously)
> external debug symbols: --with-native-debug-symbols=external (or old mechanism)
> 

Yes, I'm aware of this, as I said with 'the new configure option'.

> Why would you want to continue some unsupported way to produce the
> equivalent of --with-native-debug-symbols=internal?
> 

Why would you want to keep a regression of something that previously worked?

>> Simple fix and 8u only.
> 
> Fix is simple enough, but it also encourages people to *not* change
> their build scripts to the supported configure option :-(

So we should break people's build to force them to specify it, even
though the breakage makes it in no way clear that this is the problem?

There's nothing different in this patch from what you added yourself to
the same file in 8036003. You just missed a bunch of cases.

> 
> Thanks,
> Severin
> 

-- 
Andrew :)

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

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


From kevin.walls at oracle.com  Mon Mar 11 18:20:01 2019
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 11 Mar 2019 18:20:01 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
 <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
Message-ID: <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>


Hi Alexsey - yes, that little change in flags.m4 is what I did for 8217305.

I'm just feeling my way in the new process, so I pushed to our internal 
repo.

Paul I was pleased to see your keyword addition, and the approval.? I 
didn't quite know if it meant you were taking the change I mentioned and 
getting it into the open 8u-dev (you're probably aware that in 8u with 
these build ones, we make the .m4 change, then run autogen.sh to 
regenerated generated-autoconfigure.sh, pushing both).? If you are, 
that's great.? If you aren't, I'll do it as I have it in my head, and it 
appears to be approved. 8-)

Thanks
Kevin


On 11/03/2019 18:09, Aleksey Shipilev wrote:
> On 3/7/19 8:46 PM, Hohensee, Paul wrote:
>> I tagged JDK-8217305 with jdk8u-fix-request.
> Have you been doing the work for it? Generally, if you put the tag, it is expected that you also put
> the appropriate "Fix Request" comment, which implies you did the backporting work.
>
>> ?On 3/6/19, 11:58 PM, "jdk8u-dev on behalf of Kevin Walls" <jdk8u-dev-bounces at openjdk.java.net on behalf of kevin.walls at oracle.com> wrote:
>>      8209002 changes JDK_VER.
>>      8217305 changes JDK_FVER.
>>      
>>      8217305 is not a confidential bug, but I haven't yet done an open review
>>      for that one.  The required diff is below to clarify what it's about.
>>      If there's impact to the open builds we can do the review/approval
>>      required to get it there...
>>      
>>      --- a/common/autoconf/flags.m4    Wed Feb 27 10:51:09 2019 -0800
>>      +++ b/common/autoconf/flags.m4    Thu Feb 28 02:55:32 2019 -0800
>>      @@ -111,7 +111,7 @@
>>                -d
>>      \"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\"
>>      \
>>                -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
>>                -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME)
>>      \$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
>>      -        -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if
>>      \$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
>>      +        -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if
>>      \$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
>>          fi
>>          AC_SUBST(RC_FLAGS)
> Hey Kevin, do I understand correctly this is the exact fix for 8217305 for 8u? If so, I'd be working
> to get it into 8u.
>
> Thanks,
> -Aleksey
>
>

From shade at redhat.com  Mon Mar 11 18:35:18 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 11 Mar 2019 19:35:18 +0100
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
 <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
 <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>
Message-ID: <88c602c7-a85d-f1b1-a078-c6d2376b8085@redhat.com>

On 3/11/19 7:20 PM, Kevin Walls wrote:
> Paul I was pleased to see your keyword addition, and the approval.? I didn't quite know if it meant
> you were taking the change I mentioned and getting it into the open 8u-dev (you're probably aware
> that in 8u with these build ones, we make the .m4 change, then run autogen.sh to regenerated
> generated-autoconfigure.sh, pushing both).? If you are, that's great.? If you aren't, I'll do it as
> I have it in my head, and it appears to be approved. 8-)

I think you can do it, Kevin!

The 8u push approval (jdk8u-fix-yes tag) is there, so the fix can be pushed to jdk8u/jdk8u-dev.
There are two little deviations from the process. These two things should have happened before push
approval was there:
  a) "Fix Request" comment should be present in 8217305 describing what this patch is about, what
testing was done, and what are the risks;
  b) Public RFR should be present for 8217305, given it is not a backport, but rather a new change
in 8u;

All that is nominally needed for maintainer to set jdk8u-fix-yes for the request, but that had
already happened. We might want to put pro-forma "Fix Request" [1] and pro-forma RFR on this list
[2] to make history look good if we even need to come back to this issue, and also for somebody to
eyeball the fix before pushing.

-Aleksey

[1] Example: https://bugs.openjdk.java.net/browse/JDK-8211382?focusedCommentId=14247397#comment-14247397
[2] Example: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008684.html


From sgehwolf at redhat.com  Mon Mar 11 19:10:04 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Mar 2019 20:10:04 +0100
Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
In-Reply-To: <8915ca28-09e9-391b-86d2-2ac675586e0a@redhat.com>
References: <2f310840-ec43-1c4a-2c73-bf5968163c63@redhat.com>
 <bf0b88e69446028570faa064710dae7fdf5e8658.camel@redhat.com>
 <8915ca28-09e9-391b-86d2-2ac675586e0a@redhat.com>
Message-ID: <f5297c976f92b3f68e769f6421da8ebf306759bf.camel@redhat.com>

On Mon, 2019-03-11 at 18:09 +0000, Andrew John Hughes wrote:
> 
> On 11/03/2019 11:04, Severin Gehwolf wrote:
> > On Mon, 2019-03-11 at 07:33 +0000, Andrew John Hughes wrote:
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
> > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/
> > > 
> > > When JDK-8036003 was backported, it added a bunch of conditionals in
> > > make/common/NativeCompilation.gmk which cause debuginfo to not be
> > > generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
> > > were missed, causing the build to fail, because there's no dependency
> > > for the .diz target.
> > > 
> > > I suspect this doesn't show up when the new configure option is
> > > specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
> > > does regress my existing builds which don't specify that option.
> > 
> > Sorry, but I'm not sure why this would be needed? There is a new
> > configure flag supporting these use-cases (including yours?):
> > 
> > no debug symbols: --with-native-debug-symbols=none (or old mechanims)
> > zipped debug symbols: --with-native-debug-symbols=zipped (or old mechanism)
> > no stripping at all: --with-native-debug-symbols=internal (no supported way previously)
> > external debug symbols: --with-native-debug-symbols=external (or old mechanism)
> > 
> 
> Yes, I'm aware of this, as I said with 'the new configure option'.
> 
> > Why would you want to continue some unsupported way to produce the
> > equivalent of --with-native-debug-symbols=internal?
> > 
> 
> Why would you want to keep a regression of something that previously worked?

Two reasons:
   1. My understanding is that one has to say ZIP_DEBUGINFO_FILES=true
      STRIP_POLICY=no_strip somehow so that this surfaces. That's
      something unsupported and that means "you are on your own when it
      breaks". Besides, these are implementation details.
   2. ZIP_DEBUGINFO_FILES=true STRIP_POLICY=no_strip as a combination are
      orthogonal. Making this use case work seems to give the illusion
      that this actually works: internal, but zipped debug info?

Sounds to me, the premise is wrong: It should have never worked ;-)
Thus, not a regression.

> > > Simple fix and 8u only.
> > 
> > Fix is simple enough, but it also encourages people to *not* change
> > their build scripts to the supported configure option :-(
> 
> So we should break people's build to force them to specify it, even
> though the breakage makes it in no way clear that this is the problem?

When 8036003 was implemented for 8, there was the requirement to *not*
break existing use-cases. That is, existing config options --disable-
zip-debug-info and --disable-debug-symbols take precedence over the new
option and continue to work.

> There's nothing different in this patch from what you added yourself to
> the same file in 8036003. You just missed a bunch of cases.

Thanks,
Severin


From hohensee at amazon.com  Mon Mar 11 19:11:10 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 11 Mar 2019 19:11:10 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <88c602c7-a85d-f1b1-a078-c6d2376b8085@redhat.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
 <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
 <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>
 <88c602c7-a85d-f1b1-a078-c6d2376b8085@redhat.com>
Message-ID: <0D5AD94B-14FD-4F5E-B4BF-670C7C19533A@amazon.com>

Yes, please do it, Kevin. I'm still learning protocol, which in this case is "if you tag a bug as a backport fix request, you own pushing it".

Thanks,

Paul

?On 3/11/19, 11:35 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    On 3/11/19 7:20 PM, Kevin Walls wrote:
    > Paul I was pleased to see your keyword addition, and the approval.  I didn't quite know if it meant
    > you were taking the change I mentioned and getting it into the open 8u-dev (you're probably aware
    > that in 8u with these build ones, we make the .m4 change, then run autogen.sh to regenerated
    > generated-autoconfigure.sh, pushing both).  If you are, that's great.  If you aren't, I'll do it as
    > I have it in my head, and it appears to be approved. 8-)
    
    I think you can do it, Kevin!
    
    The 8u push approval (jdk8u-fix-yes tag) is there, so the fix can be pushed to jdk8u/jdk8u-dev.
    There are two little deviations from the process. These two things should have happened before push
    approval was there:
      a) "Fix Request" comment should be present in 8217305 describing what this patch is about, what
    testing was done, and what are the risks;
      b) Public RFR should be present for 8217305, given it is not a backport, but rather a new change
    in 8u;
    
    All that is nominally needed for maintainer to set jdk8u-fix-yes for the request, but that had
    already happened. We might want to put pro-forma "Fix Request" [1] and pro-forma RFR on this list
    [2] to make history look good if we even need to come back to this issue, and also for somebody to
    eyeball the fix before pushing.
    
    -Aleksey
    
    [1] Example: https://bugs.openjdk.java.net/browse/JDK-8211382?focusedCommentId=14247397#comment-14247397
    [2] Example: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008684.html
    
    


From gnu.andrew at redhat.com  Mon Mar 11 19:15:15 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 19:15:15 +0000
Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
In-Reply-To: <8915ca28-09e9-391b-86d2-2ac675586e0a@redhat.com>
References: <2f310840-ec43-1c4a-2c73-bf5968163c63@redhat.com>
 <bf0b88e69446028570faa064710dae7fdf5e8658.camel@redhat.com>
 <8915ca28-09e9-391b-86d2-2ac675586e0a@redhat.com>
Message-ID: <2d6a8be9-dd93-d376-1f69-a57f577b1fb1@redhat.com>



On 11/03/2019 18:09, Andrew John Hughes wrote:
> 
> 
> On 11/03/2019 11:04, Severin Gehwolf wrote:
>> On Mon, 2019-03-11 at 07:33 +0000, Andrew John Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/
>>>
>>> When JDK-8036003 was backported, it added a bunch of conditionals in
>>> make/common/NativeCompilation.gmk which cause debuginfo to not be
>>> generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
>>> were missed, causing the build to fail, because there's no dependency
>>> for the .diz target.
>>>
>>> I suspect this doesn't show up when the new configure option is
>>> specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
>>> does regress my existing builds which don't specify that option.
>>
>> Sorry, but I'm not sure why this would be needed? There is a new
>> configure flag supporting these use-cases (including yours?):
>>
>> no debug symbols: --with-native-debug-symbols=none (or old mechanims)
>> zipped debug symbols: --with-native-debug-symbols=zipped (or old mechanism)
>> no stripping at all: --with-native-debug-symbols=internal (no supported way previously)
>> external debug symbols: --with-native-debug-symbols=external (or old mechanism)
>>
> 
> Yes, I'm aware of this, as I said with 'the new configure option'.
> 
>> Why would you want to continue some unsupported way to produce the
>> equivalent of --with-native-debug-symbols=internal?
>>
> 
> Why would you want to keep a regression of something that previously worked?
> 
>>> Simple fix and 8u only.
>>
>> Fix is simple enough, but it also encourages people to *not* change
>> their build scripts to the supported configure option :-(
> 
> So we should break people's build to force them to specify it, even
> though the breakage makes it in no way clear that this is the problem?
> 
> There's nothing different in this patch from what you added yourself to
> the same file in 8036003. You just missed a bunch of cases.
> 
>>
>> Thanks,
>> Severin
>>
> 

This is the configure output:

checking if we should generate debug symbols... true
checking if we should zip debug-info files... yes
checking what type of native debug symbols to use (this will override
previous settings)... not specified
configure: --with-native-debug-symbols not specified. Using values from
--disable-debug-symbols and --disable-zip-debug-info

It defaults to turning on zipped debug symbols. STRIP_POLICY="no_strip"
was previously ignored in that file. You made changes that made it
partially recognised, but wrongly assumed that STRIP_POLICY="no_strip"
means ZIP_DEBUGINFO_FILES is not set to "true".

You can't switch to the new configure flag if it doesn't exist. I've
adopted it when possible [0], but I originally wrote this patch in
October because I was also still having to build on a bunch of trees
that didn't have this change (including 7). That may be less likely now,
but I still think this is a bug that should be fixed.

TL;DR this is a clear regression that is easily fixed without breaking
anything else.

[0] https://icedtea.classpath.org/hg/icedtea8/rev/c5e1418ca5d0099e56c42d
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Mar 11 19:27:13 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 11 Mar 2019 19:27:13 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <0D5AD94B-14FD-4F5E-B4BF-670C7C19533A@amazon.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
 <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
 <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>
 <88c602c7-a85d-f1b1-a078-c6d2376b8085@redhat.com>
 <0D5AD94B-14FD-4F5E-B4BF-670C7C19533A@amazon.com>
Message-ID: <6973e79e-9fa4-74c5-755a-fd92f5f30689@redhat.com>



On 11/03/2019 19:11, Hohensee, Paul wrote:
> Yes, please do it, Kevin. I'm still learning protocol, which in this case is "if you tag a bug as a backport fix request, you own pushing it".
> 
> Thanks,
> 
> Paul
> 

I think one of the issues with labelling bugs rather than asking for
approval on the list is it has broken the ordering in some cases. The
original expectation was:

1. Have fix for 8u reviewed by appropriate reviewers.
2. Have fix for 8u approved for inclusion by 8u maintainers.

If you look at it like this, having #2 done by the person working on the
fix makes sense because they will also have gone through #1. Of course,
#1 is skipped in the case of clean backports, which is where some of the
confusion comes about.

They are very different processes. #1 is a review of the content of the
patch as a good change to make. #2 is a review of whether the change is
appropriate at this point in the 8u lifecycle.

Where I think we still need to finesse #2 is in the deciding of whether
a fix goes to just 8u-dev or also 8u which will soon be in the second
stage of development for 8u212.

The wiki currently still contains:

https://wiki.openjdk.java.net/display/jdk8u/Proposing+critical+8u+fixes+for+CPU+releases

Do we want to update that process slightly as a route for changes to go
into the later stages of 8u? It then becomes a case of jdk8u-fix-yes
gets you 8u-dev and 8u-CPU-critical-approved gets you jdk8u.

We may need to adopt a different label to avoid conflicts with Oracle.
It does look kind of abandoned though, at the minute. I still have a
pending request which has been made redundant by the release of 8u202:

https://bugs.openjdk.java.net/browse/JDK-8165231
-- 
Andrew :)

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

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


From sgehwolf at redhat.com  Mon Mar 11 19:58:42 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 11 Mar 2019 20:58:42 +0100
Subject: [8u] RFR: 8219772: EXTRA_CFLAGS not being picked up for
 assembler files
In-Reply-To: <0ff9a2d7-d8ee-582d-0332-00a3a4e72edb@redhat.com>
References: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com>
 <0ff9a2d7-d8ee-582d-0332-00a3a4e72edb@redhat.com>
Message-ID: <a48a42333297cb550230127489923c0e72af1abe.camel@redhat.com>

On Mon, 2019-03-11 at 18:01 +0000, Andrew John Hughes wrote:
> 
> On 11/03/2019 10:45, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review this one-liner change for the 8u (OpenJDK)
> > build system? The issue at hand is that for assembler source files
> > extra C flags are not being passed to the compiler (GCC in the Linux
> > case). This is a problem for instrumented builds to facilitate checks
> > on produced binaries in terms of optimization flags and other build-
> > time invariants[1]. The patch doesn't affect builds without extra C-
> > flags. Thus, risk should be minimal.
> > 
> > This is an 8u-only change. The new build system in JDK 11 and up seems
> > to handle these cases correctly.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219772
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219772/01/webrev/
> > 
> > Testing: Compiling with extra cflags, inspecting build logs for
> > assembler source files on Linux x86_64
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > [1] https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/
> > 
> 
> Surely the correct way to do this is to add an --with-extra-asflags
> option rather than abuse flags for the C compiler?

Fair enough. It would require for this option to go into jdk/jdk first,
which seems reasonable.

> The 11 version in make/autoconf/flags-other.m4 states:
> 
>   # Misuse EXTRA_CFLAGS to mimic old behavior
> 
>   $2JVM_ASFLAGS="$JVM_BASIC_ASFLAGS ${$2EXTRA_CFLAGS}"
> 
> which suggests this might not be the best way to do this. I'm not sure
> what old behaviour it is trying to emulate if 8u doesn't support this.
> 
> Either way, I think this is a change that should wait until 8u222 at
> this point.

Sure. It can wait.

Thanks,
Severin


From kevin.walls at oracle.com  Mon Mar 11 22:34:03 2019
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 11 Mar 2019 22:34:03 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <0D5AD94B-14FD-4F5E-B4BF-670C7C19533A@amazon.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
 <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
 <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>
 <88c602c7-a85d-f1b1-a078-c6d2376b8085@redhat.com>
 <0D5AD94B-14FD-4F5E-B4BF-670C7C19533A@amazon.com>
Message-ID: <c732f058-fc77-73aa-b762-c2278b57c43b@oracle.com>

No problem...

Generally the confusing part I see is, it's not obvious if RFR emails 
were replaced with the fix-request keyword, and a Fix Request bug 
template/comment.? I see they are not, but it's not clear if they 
duplicate each other, or if they intend to separately deal with 
technical approval and push approval, the RFR vs RFA emails we had in 
the past.


On 11/03/2019 19:11, Hohensee, Paul wrote:
> Yes, please do it, Kevin. I'm still learning protocol, which in this case is "if you tag a bug as a backport fix request, you own pushing it".
>
> Thanks,
>
> Paul
>
> ?On 3/11/19, 11:35 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:
>
>      On 3/11/19 7:20 PM, Kevin Walls wrote:
>      > Paul I was pleased to see your keyword addition, and the approval.  I didn't quite know if it meant
>      > you were taking the change I mentioned and getting it into the open 8u-dev (you're probably aware
>      > that in 8u with these build ones, we make the .m4 change, then run autogen.sh to regenerated
>      > generated-autoconfigure.sh, pushing both).  If you are, that's great.  If you aren't, I'll do it as
>      > I have it in my head, and it appears to be approved. 8-)
>      
>      I think you can do it, Kevin!
>      
>      The 8u push approval (jdk8u-fix-yes tag) is there, so the fix can be pushed to jdk8u/jdk8u-dev.
>      There are two little deviations from the process. These two things should have happened before push
>      approval was there:
>        a) "Fix Request" comment should be present in 8217305 describing what this patch is about, what
>      testing was done, and what are the risks;
>        b) Public RFR should be present for 8217305, given it is not a backport, but rather a new change
>      in 8u;
>      
>      All that is nominally needed for maintainer to set jdk8u-fix-yes for the request, but that had
>      already happened. We might want to put pro-forma "Fix Request" [1] and pro-forma RFR on this list
>      [2] to make history look good if we even need to come back to this issue, and also for somebody to
>      eyeball the fix before pushing.
>      
>      -Aleksey
>      
>      [1] Example: https://bugs.openjdk.java.net/browse/JDK-8211382?focusedCommentId=14247397#comment-14247397
>      [2] Example: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008684.html
>      
>      
>

From gnu.andrew at redhat.com  Tue Mar 12 04:00:22 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 12 Mar 2019 04:00:22 +0000
Subject: JDK-8217305, JDK-8209002 and fixes
In-Reply-To: <c732f058-fc77-73aa-b762-c2278b57c43b@oracle.com>
References: <97b746eb-a59a-dd72-7fea-363469f96526@redhat.com>
 <58ce45ee-9943-a7d9-6dbb-8b9467f07ec8@oracle.com>
 <45DEE51D-5313-4F8C-9B06-BDC8D9432C52@amazon.com>
 <3915722e-10cd-d248-1d19-4740db636894@redhat.com>
 <f4293728-d61d-ab24-38f5-cdfd46cfe851@oracle.com>
 <88c602c7-a85d-f1b1-a078-c6d2376b8085@redhat.com>
 <0D5AD94B-14FD-4F5E-B4BF-670C7C19533A@amazon.com>
 <c732f058-fc77-73aa-b762-c2278b57c43b@oracle.com>
Message-ID: <db9d2aa8-dd80-4ed2-84d3-c3ade08547a9@redhat.com>



On 11/03/2019 22:34, Kevin Walls wrote:
> No problem...
> 
> Generally the confusing part I see is, it's not obvious if RFR emails
> were replaced with the fix-request keyword, and a Fix Request bug
> template/comment.? I see they are not, but it's not clear if they
> duplicate each other, or if they intend to separately deal with
> technical approval and push approval, the RFR vs RFA emails we had in
> the past.
> 
> 

I believe the Fix Request comment replaces the body of an RFA e-mail
(i.e. why should this be allowed, does it apply cleanly, if not where
was it reviewed).

Reviews (RFRs) work as they would for the current development tree.
-- 
Andrew :)

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

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


From kevin.walls at oracle.com  Tue Mar 12 07:57:11 2019
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 12 Mar 2019 07:57:11 +0000
Subject: RFR (S): 8217305: Missing 0 in java.dll file version cause issues
 with patch management software
Message-ID: <416d2f02-9169-b51e-22a0-988e5392d1ca@oracle.com>

Hi,

I'd like to get a review for an 8u fix for:

8217305: Missing 0 in java.dll file version cause issues with patch 
management software
JBS:https://bugs.openjdk.java.net/browse/JDK-8217305

Diff pasted below as it is a one-liner (plus regenerating 
common/autoconf/generated-configure.sh).

We need to correct the JDK_FVER setting in flags.m4, which dropped some 
use of "COOKED" version during a previous change. Important to change 
back as this is a regression, breaking the version format expected by 
some people and tools.

Low risk, manual testing.

Thanks
Kevin


bash-4.2$ hg diff
diff -r 9da665f87c4b common/autoconf/flags.m4
--- a/common/autoconf/flags.m4? Wed Oct 25 13:11:07 2017 -0700
+++ b/common/autoconf/flags.m4? Mon Mar 11 15:48:15 2019 -0700
@@ -111,7 +111,7 @@
 ???????? -d 
\"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\" 
\
 ???????? -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
 ???????? -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) 
\$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
-??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
\$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
+??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
\$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
 ?? fi
 ?? AC_SUBST(RC_FLAGS)

diff -r 9da665f87c4b common/autoconf/generated-configure.sh
--- a/common/autoconf/generated-configure.sh??? Wed Oct 25 13:11:07 2017 
-0700
+++ b/common/autoconf/generated-configure.sh??? Mon Mar 11 15:48:15 2019 
-0700
@@ -4358,7 +4358,7 @@
 ?#CUSTOM_AUTOCONF_INCLUDE

 ?# Do not change or remove the following line, it is needed for 
consistency checks:
-DATE_WHEN_GENERATED=1551441508
+DATE_WHEN_GENERATED=1552344461

 ?###############################################################################
 ?#
@@ -40540,7 +40540,7 @@
 ???????? -d 
\"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\" 
\
 ???????? -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
 ???????? -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME) 
\$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
-??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
\$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
+??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if 
\$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
 ?? fi




From christoph.langer at sap.com  Tue Mar 12 10:25:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Mar 2019 10:25:47 +0000
Subject: [8u, 11u] Wiki Page updates
Message-ID: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

I have updated the Wiki Pages for both, jdk11u and jdk8u so that they look consistent.

JDK8u: https://wiki.openjdk.java.net/display/jdk8u
JDK11u: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

I have written some sentences about processes and infrastructure, covering also the push approval process. Furthermore, I've added the upcoming release dates and links to the JBS filters.

Please review this documentation, whether it's correct in content and also whether it's understandable. Thanks in advance for any feedback.

Best regards
Christoph


From sgehwolf at redhat.com  Tue Mar 12 10:54:41 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 12 Mar 2019 11:54:41 +0100
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
Message-ID: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>

Adding security-dev as reviews should happen on the corresponding area
lists. Even for 8.

On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/

This looks OK to me. It removes the same tests as was done for JDK 9.
I've verified that KdcPolicy.java passes after your changes. Not a
Reviewer, though.

Thanks,
Severin

> Original review:
> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html
> 
> This is not a clean backport because the tests in 8u differ slightly
> from those in OpenJDK 10:
> 
> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
> That same change (adding a property to the @run line) also needs to be
> applied to the new KdcPolicy.java test for it to succeed.
> 
> 2. 10u contains "JDK-8006690: sun/security/krb5/auto/BadKdc* tests fails
> intermittently" which I assume is obsoleted by the more reliable
> KdcPolicy.java test
> 
> Strangely enough, this & JDK-8164656 were already approved last July,
> but never pushed [0].  I can't see how this was a straightforward
> backport then though either.
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007667.html


From martijnverburg at gmail.com  Tue Mar 12 11:11:40 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 12 Mar 2019 11:11:40 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAP7YuAQ+dZs4AEQLvTAq49BeU2Jq8L55KDuz6V38PPtGSkQdpg@mail.gmail.com>

Thank you!

On Tue, 12 Mar 2019 at 10:26, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
> I have updated the Wiki Pages for both, jdk11u and jdk8u so that they look
> consistent.
>
> JDK8u: https://wiki.openjdk.java.net/display/jdk8u
> JDK11u: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
>
> I have written some sentences about processes and infrastructure, covering
> also the push approval process. Furthermore, I've added the upcoming
> release dates and links to the JBS filters.
>
> Please review this documentation, whether it's correct in content and also
> whether it's understandable. Thanks in advance for any feedback.
>
> Best regards
> Christoph
>
> --
Cheers, Martijn (Sent from Gmail Mobile)

From shade at redhat.com  Tue Mar 12 12:21:31 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Mar 2019 13:21:31 +0100
Subject: RFR (S): 8217305: Missing 0 in java.dll file version cause issues
 with patch management software
In-Reply-To: <416d2f02-9169-b51e-22a0-988e5392d1ca@oracle.com>
References: <416d2f02-9169-b51e-22a0-988e5392d1ca@oracle.com>
Message-ID: <00a3912b-a3ea-35a6-a80d-57e60f2e68c7@redhat.com>

On 3/12/19 8:57 AM, Kevin Walls wrote:
> 8217305: Missing 0 in java.dll file version cause issues with patch management software
> JBS:https://bugs.openjdk.java.net/browse/JDK-8217305
> 
> Diff pasted below as it is a one-liner (plus regenerating common/autoconf/generated-configure.sh).

Looks good!

-Aleksey


From guangyu.zhu at aliyun.com  Tue Mar 12 13:29:35 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Tue, 12 Mar 2019 21:29:35 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>,
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
Message-ID: <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>

Hi Andrey, Mario

Is there any progress in backporting? We have completed the patch for the missing features. Please review. 

- thread sampling: 
http://cr.openjdk.java.net/~luchsh/thread_sampling/

- biased locking events: 
http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/

- G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
http://cr.openjdk.java.net/~luchsh/g1region_type_change_event

Thanks,
Guangyu



------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Mar. 6 (Wed.) 00:34
Recipient:Mario Torre <neugens at redhat.com>
Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Hi Mario,

> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> 
> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> 
>>> I'm going through the patch right now, but yes, from what I see the
>>> trace is removed. I had too a concern about this and was about to send
>>> a note. I'm not quite sure what to do, because Trace has been removed
>>> in 11 as far as I know, but removing mid stream in 8 may be a more
>>> interesting issue, however this isn't a user facing API, it was always
>>> meant to be internal to the JVM, so I don't quite know if there's
>>> really a reason we shouldn't change it. This is one question for the
>>> CSR group I think.
>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
>> I will be happy to return it back
> 
> Yes, I tend to agree with you, I do believe this is mostly an internal
> API for easy of patching with the JFR code (which is almost
> identical). The only concern is in the way the logging would be
> triggered externally and the compile time options for it (I still see
> a couple of instance where INCLUDE_TRACE is being used). As for
> triggering the logs, I don't recall that 8 has any means of doing
> this, I think some infrastructure came with 9 with the -Xlog option (I
> didn't follow this however, I'm not sure the option ever landed in 9)?
> In that case I guess it's safe to go after all.
Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
IMHO we should get rid of all of them, but cannot tell for sure now

Andrey
> 
> 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  Tue Mar 12 13:34:30 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 12 Mar 2019 13:34:30 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <bf80f850-38f5-40a7-a4b8-d729b2cffcca.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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
Message-ID: <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>

Hi Guangyu,

Cool! Thank you so much! Will review changes ASAP
The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after 
April update release (mostly limited by testing resources capacity)

Regards,
Andrey

> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> Hi Andrey, Mario
> 
> Is there any progress in backporting? We have completed the patch for the missing features. Please review. 
> 
> - thread sampling: 
> http://cr.openjdk.java.net/~luchsh/thread_sampling/
> 
> - biased locking events: 
> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> 
> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> 
> Thanks,
> Guangyu
> 
> 
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Mar. 6 (Wed.) 00:34
> Recipient:Mario Torre <neugens at redhat.com>
> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Mario,
> 
> > On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> > 
> > On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> > 
> >>> I'm going through the patch right now, but yes, from what I see the
> >>> trace is removed. I had too a concern about this and was about to send
> >>> a note. I'm not quite sure what to do, because Trace has been removed
> >>> in 11 as far as I know, but removing mid stream in 8 may be a more
> >>> interesting issue, however this isn't a user facing API, it was always
> >>> meant to be internal to the JVM, so I don't quite know if there's
> >>> really a reason we shouldn't change it. This is one question for the
> >>> CSR group I think.
> >> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> >> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> >> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> >> I will be happy to return it back
> > 
> > Yes, I tend to agree with you, I do believe this is mostly an internal
> > API for easy of patching with the JFR code (which is almost
> > identical). The only concern is in the way the logging would be
> > triggered externally and the compile time options for it (I still see
> > a couple of instance where INCLUDE_TRACE is being used). As for
> > triggering the logs, I don't recall that 8 has any means of doing
> > this, I think some infrastructure came with 9 with the -Xlog option (I
> > didn't follow this however, I'm not sure the option ever landed in 9)?
> > In that case I guess it's safe to go after all.
> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
> IMHO we should get rid of all of them, but cannot tell for sure now
> 
> Andrey
> > 
> > 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 christoph.langer at sap.com  Tue Mar 12 14:58:02 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Mar 2019 14:58:02 +0000
Subject: OpenJDK 8u212 status
Message-ID: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi there,

as of today, we have the official release version "openjdk8u212" set up in the JBS bug system. I've updated all bug items for the recent jdk8u pushes to use openjdk8u212 as "Fix Version".

We'd like to promote the work from the jdk8u-dev mercurial forest to the jdk8u forest for release stabilization as soon as possible. We're currently waiting for the following issues:

https://bugs.openjdk.java.net/browse/JDK-8217305 -> waiting for push by Kevin
https://bugs.openjdk.java.net/browse/JDK-8213983 -> Severin working on it
https://bugs.openjdk.java.net/browse/JDK-8175120 -> waiting for final review and push by Andrew
https://bugs.openjdk.java.net/browse/JDK-8213825 -> waiting for push by Aleksey
https://bugs.openjdk.java.net/browse/JDK-8189761 -> handled by Andrew. Approval is there, but no RFR?

Once these are in, I'll add the tag jdk8u201-b00 and promote to jdk8u.

I also suggest to suspend fix approvals for 8u until the jdk8u-dev->jdk8u promotion happened and jdk8u-dev is set up for openjdk8u222.

Best regards
Christoph


From sgehwolf at redhat.com  Tue Mar 12 15:04:18 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 12 Mar 2019 16:04:18 +0100
Subject: OpenJDK 8u212 status
In-Reply-To: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <37c9c77b7ba26309606f8f2087ffb1973d0f4390.camel@redhat.com>

On Tue, 2019-03-12 at 14:58 +0000, Langer, Christoph wrote:
> Once these are in, I?ll add the tag jdk8u201-b00 and promote to jdk8u.

Shouldn't this be jdk8u212-b00? 8u201 went already out the door.

Thanks,
Severin


From christoph.langer at sap.com  Tue Mar 12 15:08:05 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Mar 2019 15:08:05 +0000
Subject: OpenJDK 8u212 status
In-Reply-To: <37c9c77b7ba26309606f8f2087ffb1973d0f4390.camel@redhat.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <37c9c77b7ba26309606f8f2087ffb1973d0f4390.camel@redhat.com>
Message-ID: <HE1PR0201MB2266B50D5DCE29DB38792D9A8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>

> On Tue, 2019-03-12 at 14:58 +0000, Langer, Christoph wrote:
> > Once these are in, I?ll add the tag jdk8u201-b00 and promote to jdk8u.
> 
> Shouldn't this be jdk8u212-b00? 8u201 went already out the door.

Yeah, sorry. Copy&Paste and then forget to modify ??


From shade at redhat.com  Tue Mar 12 17:39:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 12 Mar 2019 18:39:37 +0100
Subject: OpenJDK 8u212 status
In-Reply-To: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <fd3765ed-75e5-6efa-31d5-aba4cc3f2c26@redhat.com>

On 3/12/19 3:58 PM, Langer, Christoph wrote:
> https://bugs.openjdk.java.net/browse/JDK-8213825 -> waiting for push by Aleksey

I prefer to push it to next 8u (for July). The patch is simple, but it is a compiler fix and I'd
like to to be tested a bit more thoroughly. This is why the relevant backport is in 11.0.4, not in
11.0.3. Therefore, let me push this _after_ we fork for stabilization.

-Aleksey


From gnu.andrew at redhat.com  Tue Mar 12 20:06:33 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 12 Mar 2019 20:06:33 +0000
Subject: RFR (S): 8217305: Missing 0 in java.dll file version cause issues
 with patch management software
In-Reply-To: <416d2f02-9169-b51e-22a0-988e5392d1ca@oracle.com>
References: <416d2f02-9169-b51e-22a0-988e5392d1ca@oracle.com>
Message-ID: <29149a7a-cc99-2b8e-dd72-0217b7a0964a@redhat.com>



On 12/03/2019 07:57, Kevin Walls wrote:
> Hi,
> 
> I'd like to get a review for an 8u fix for:
> 
> 8217305: Missing 0 in java.dll file version cause issues with patch
> management software
> JBS:https://bugs.openjdk.java.net/browse/JDK-8217305
> 
> Diff pasted below as it is a one-liner (plus regenerating
> common/autoconf/generated-configure.sh).
> 
> We need to correct the JDK_FVER setting in flags.m4, which dropped some
> use of "COOKED" version during a previous change. Important to change
> back as this is a regression, breaking the version format expected by
> some people and tools.
> 
> Low risk, manual testing.
> 
> Thanks
> Kevin
> 
> 
> bash-4.2$ hg diff
> diff -r 9da665f87c4b common/autoconf/flags.m4
> --- a/common/autoconf/flags.m4? Wed Oct 25 13:11:07 2017 -0700
> +++ b/common/autoconf/flags.m4? Mon Mar 11 15:48:15 2019 -0700
> @@ -111,7 +111,7 @@
> ???????? -d
> \"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\"
> \
> ???????? -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
> ???????? -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME)
> \$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
> -??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if
> \$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
> +??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if
> \$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
> 
> ?? fi
> ?? AC_SUBST(RC_FLAGS)
> 
> diff -r 9da665f87c4b common/autoconf/generated-configure.sh
> --- a/common/autoconf/generated-configure.sh??? Wed Oct 25 13:11:07 2017
> -0700
> +++ b/common/autoconf/generated-configure.sh??? Mon Mar 11 15:48:15 2019
> -0700
> @@ -4358,7 +4358,7 @@
> ?#CUSTOM_AUTOCONF_INCLUDE
> 
> ?# Do not change or remove the following line, it is needed for
> consistency checks:
> -DATE_WHEN_GENERATED=1551441508
> +DATE_WHEN_GENERATED=1552344461
> 
> ?###############################################################################
> 
> ?#
> @@ -40540,7 +40540,7 @@
> ???????? -d
> \"JDK_VER=\$(JDK_MINOR_VERSION).\$(JDK_MICRO_VERSION).\$(COOKED_JDK_UPDATE_VERSION).\$(COOKED_BUILD_NUMBER)\"
> \
> ???????? -d \"JDK_COPYRIGHT=Copyright \xA9 $COPYRIGHT_YEAR\" \
> ???????? -d \"JDK_NAME=\$(PRODUCT_NAME) \$(JDK_RC_PLATFORM_NAME)
> \$(JDK_MINOR_VERSION) \$(JDK_UPDATE_META_TAG)\" \
> -??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if
> \$(JDK_UPDATE_VERSION),\$(JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
> +??????? -d \"JDK_FVER=\$(JDK_MINOR_VERSION),\$(JDK_MICRO_VERSION),\$(if
> \$(COOKED_JDK_UPDATE_VERSION),\$(COOKED_JDK_UPDATE_VERSION),0),\$(COOKED_BUILD_NUMBER)\""
> 
> ?? fi
> 
> 
> 

Looks good to me.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Tue Mar 12 20:48:09 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 12 Mar 2019 20:48:09 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>

On 12/03/2019 10:25, Langer, Christoph wrote:
> Hi,
> 
> I have updated the Wiki Pages for both, jdk11u and jdk8u so that they look consistent.
> 
> JDK8u: https://wiki.openjdk.java.net/display/jdk8u
> JDK11u: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> 
> I have written some sentences about processes and infrastructure, covering also the push approval process. Furthermore, I've added the upcoming release dates and links to the JBS filters.
> 
> Please review this documentation, whether it's correct in content and also whether it's understandable. Thanks in advance for any feedback.
> 
> Best regards
> Christoph
> 

Oh, I was under the impression only aph had the permissions to edit this!

As I said yesterday [0], I think we need a label for fixes that are in
8u-dev but are candidates for the current 8u after the initial
integration. Leaving this to bug comments makes them hard for us to find.

I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as
previously used [1].

Some other minor issues; I'd prefer we referred to the security work as
taking place in a secure environment with internal testing. The word
"closed" has associations with "closed source". Also, it's "Red Hat"
with a space, not "RedHat".

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008870.html
[1]
https://wiki.openjdk.java.net/display/jdk8u/Proposing+critical+8u+fixes+for+CPU+releases

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Tue Mar 12 20:50:47 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 12 Mar 2019 20:50:47 +0000
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
Message-ID: <12469a4d-c6ce-52c8-1429-8e0b47b62eb3@redhat.com>

On 12/03/2019 10:54, Severin Gehwolf wrote:
> Adding security-dev as reviews should happen on the corresponding area
> lists. Even for 8.
> 

I'm not sure about this. We've never done that for 7u under Red Hat
leadership and I wonder whether it potentially risks fixes being delayed
by Oracle reviewers that are no longer interesting in working on 8u, not
to mention creating additional noise on the other lists.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Tue Mar 12 20:59:13 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 12 Mar 2019 20:59:13 +0000
Subject: OpenJDK 8u212 status
In-Reply-To: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>

On 12/03/2019 14:58, Langer, Christoph wrote:
> Hi there,
> 
> ?
> 
> as of today, we have the official release version ?openjdk8u212? set up
> in the JBS bug system. I?ve updated all bug items for the recent jdk8u
> pushes to use openjdk8u212 as ?Fix Version?.
> 
> ?
> 
> We?d like to promote the work from the jdk8u-dev mercurial forest to the
> jdk8u forest for release stabilization as soon as possible. We?re
> currently waiting for the following issues:
> 
> ?
> 
> https://bugs.openjdk.java.net/browse/JDK-8217305 -> waiting for push by
> Kevin
> 
> https://bugs.openjdk.java.net/browse/JDK-8213983 -> Severin working on it
> 
> https://bugs.openjdk.java.net/browse/JDK-8175120 -> waiting for final
> review and push by Andrew

For clarity, I can't review my own patch. Another 8u reviewer needs to
do so before I can push it.

> 
> https://bugs.openjdk.java.net/browse/JDK-8213825 -> waiting for push by
> Aleksey
> 
> https://bugs.openjdk.java.net/browse/JDK-8189761 -> handled by Andrew.
> Approval is there, but no RFR?

This depends on https://bugs.openjdk.java.net/browse/JDK-8193764.

I haven't posted an RFR for that either because I currently have three
pending for over 24 hours:

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008844.html
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008845.html

All of these are pretty trivial patches, so I'm curious why they've not
been reviewed yet.

Paul & Aleksey are both 8u reviewers. Are we in a position to propose
any more?

> 
> ?
> 
> Once these are in, I?ll add the tag jdk8u201-b00 and promote to jdk8u.
> 
> ?
> 
> I also suggest to suspend fix approvals for 8u until the
> jdk8u-dev->jdk8u promotion happened and jdk8u-dev is set up for
> openjdk8u222.
> 

Suspending approvals at present will block JDK-8193764 and thus JDK-8189761.

However, I don't intend to approve any more bugs until we've branched.

> ?
> 
> Best regards
> 
> Christoph
> 
> ?
> 

Best regards,
-- 
Andrew :)

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

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


From aoqi at loongson.cn  Wed Mar 13 01:20:39 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Wed, 13 Mar 2019 09:20:39 +0800
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
Message-ID: <CALjzQn5uc38M54a=gAMSQqzP+mi=3SNAZ1UccP5_qfojb7WE5w@mail.gmail.com>

Hi,

Thanks for doing this! Finally I saw the upcoming version timeline. It
helps a lot to guide our jdk8u release date in the future.

One minor issue, on 8u page [1], I saw:

  JDK 8u222 timeline
    March 2019 jdk11u-dev forest open
    ...
 JDK 8u232 timeline
    June 2019 jdk11u-dev forest open
    ..

Is jdk11u-dev a copy-paste typo?

Thanks,
Ao Qi

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

On Wed, Mar 13, 2019 at 4:48 AM Andrew John Hughes
<gnu.andrew at redhat.com> wrote:
>
> On 12/03/2019 10:25, Langer, Christoph wrote:
> > Hi,
> >
> > I have updated the Wiki Pages for both, jdk11u and jdk8u so that they look consistent.
> >
> > JDK8u: https://wiki.openjdk.java.net/display/jdk8u
> > JDK11u: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> >
> > I have written some sentences about processes and infrastructure, covering also the push approval process. Furthermore, I've added the upcoming release dates and links to the JBS filters.
> >
> > Please review this documentation, whether it's correct in content and also whether it's understandable. Thanks in advance for any feedback.
> >
> > Best regards
> > Christoph
> >
>
> Oh, I was under the impression only aph had the permissions to edit this!
>
> As I said yesterday [0], I think we need a label for fixes that are in
> 8u-dev but are candidates for the current 8u after the initial
> integration. Leaving this to bug comments makes them hard for us to find.
>
> I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as
> previously used [1].
>
> Some other minor issues; I'd prefer we referred to the security work as
> taking place in a secure environment with internal testing. The word
> "closed" has associations with "closed source". Also, it's "Red Hat"
> with a space, not "RedHat".
>
> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008870.html
> [1]
> https://wiki.openjdk.java.net/display/jdk8u/Proposing+critical+8u+fixes+for+CPU+releases
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>

From christoph.langer at sap.com  Wed Mar 13 07:58:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Mar 2019 07:58:47 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
Message-ID: <HE1PR0201MB226690D47F4753F6F9F246948A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> As I said yesterday [0], I think we need a label for fixes that are in
> 8u-dev but are candidates for the current 8u after the initial
> integration. Leaving this to bug comments makes them hard for us to find.
> 
> I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as
> previously used [1].

I think it sounds reasonable. We can use jdk8u-critical-request and jdk11u-critical-request, since we are not planning to ship CPUs in OpenJDK. This will avoid namespace collisions with Oracle.

I also think this should not only apply for changes that are already in jdk8u-dev/jdk11u-dev and shall be brought to jdk8u/jdk11u but also for direct pushes into jdk8u/jdk11u.

What do other people think, especially aph? If we agree on it, I'll update this part in the wiki and we can start living up to it.

> Some other minor issues; I'd prefer we referred to the security work as
> taking place in a secure environment with internal testing. The word
> "closed" has associations with "closed source". Also, it's "Red Hat"
> with a space, not "RedHat".

Yep, that sounds better. I fixed it ??

> 
> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> March/008870.html
> [1]
> https://wiki.openjdk.java.net/display/jdk8u/Proposing+critical+8u+fixes+for
> +CPU+releases

Best regards
Christoph


From christoph.langer at sap.com  Wed Mar 13 08:01:32 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Mar 2019 08:01:32 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <CALjzQn5uc38M54a=gAMSQqzP+mi=3SNAZ1UccP5_qfojb7WE5w@mail.gmail.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
 <CALjzQn5uc38M54a=gAMSQqzP+mi=3SNAZ1UccP5_qfojb7WE5w@mail.gmail.com>
Message-ID: <HE1PR0201MB22662A9E82B8342560F697388A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Ao Qi,

> One minor issue, on 8u page [1], I saw:
> 
>   JDK 8u222 timeline
>     March 2019 jdk11u-dev forest open
>     ...
>  JDK 8u232 timeline
>     June 2019 jdk11u-dev forest open
>     ..
> 
> Is jdk11u-dev a copy-paste typo?

Good catch. Yes, it was a copy-paste typo. Fixed it.

Best regards
Christoph

From christoph.langer at sap.com  Wed Mar 13 08:08:13 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Mar 2019 08:08:13 +0000
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <12469a4d-c6ce-52c8-1429-8e0b47b62eb3@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
 <12469a4d-c6ce-52c8-1429-8e0b47b62eb3@redhat.com>
Message-ID: <HE1PR0201MB22667950E904DC355B8151438A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

> > Adding security-dev as reviews should happen on the corresponding area
> > lists. Even for 8.
> >
> 
> I'm not sure about this. We've never done that for 7u under Red Hat
> leadership and I wonder whether it potentially risks fixes being delayed
> by Oracle reviewers that are no longer interesting in working on 8u, not
> to mention creating additional noise on the other lists.

It was the practice for JDK 8 updates so far. For me, the main benefit of including other lists in update reviews is the notification of potential reviewers that would usually not read the update mailing lists.

/Christoph


From christoph.langer at sap.com  Wed Mar 13 09:08:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Mar 2019 09:08:23 +0000
Subject: OpenJDK 8u212 status
In-Reply-To: <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
Message-ID: <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

...snip...

> I haven't posted an RFR for that either because I currently have three
> pending for over 24 hours:
> 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> March/008846.html
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> March/008844.html
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> March/008845.html
> 
> All of these are pretty trivial patches, so I'm curious why they've not
> been reviewed yet.
> 
> Paul & Aleksey are both 8u reviewers. Are we in a position to propose
> any more?

I think Severin could be proposed as reviewer. He has enough pushes in jdk8u.
I'd also love to be a reviewer in 8u but I think my stats there are still too low (I counted 18 distinct pushes) and the outlook for growth is not so big. Maybe my track record in the jdk project would help to close the gap but I'm not in the position to assess this. ??

> > I also suggest to suspend fix approvals for 8u until the
> > jdk8u-dev->jdk8u promotion happened and jdk8u-dev is set up for
> > openjdk8u222.
> >
> 
> Suspending approvals at present will block JDK-8193764 and thus JDK-
> 8189761.

I only meant to suspend approvals for issues that can wait for 8u222. ?? JDK-8193764 certainly needs to be approved asap.

/Christoph


From sgehwolf at redhat.com  Wed Mar 13 09:24:35 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 13 Mar 2019 10:24:35 +0100
Subject: OpenJDK 8u212 status
In-Reply-To: <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
 <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <357063d5ccad48c9db5513d381b8e78e7a0f8a02.camel@redhat.com>

On Wed, 2019-03-13 at 09:08 +0000, Langer, Christoph wrote:
> > Paul & Aleksey are both 8u reviewers. Are we in a position to propose
> > any more?
> 
> I think Severin could be proposed as reviewer. He has enough pushes in jdk8u.

I'm flattered, thanks. It would be a bit awkward, though, since I'm not
a reviewer in jdk/jdk.

Thanks,
Severin


From neugens.limasoftware at gmail.com  Wed Mar 13 11:25:50 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 13 Mar 2019 07:25:50 -0400
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <9993E0D1-2583-4A33-AFE7-DDED438AE79C@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
Message-ID: <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>

Thanks!

I?m currently traveling but I?ll offer my review as soon as I get back next
week.

Cheers,
Mario
On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:

> Hi Guangyu,
>
> Cool! Thank you so much! Will review changes ASAP
> The backporting is still in progress. There are quite a lot of changes to
> consider so we'll likely finish some time after
> April update release (mostly limited by testing resources capacity)
>
> Regards,
> Andrey
>
> > On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >
> > Hi Andrey, Mario
> >
> > Is there any progress in backporting? We have completed the patch for
> the missing features. Please review.
> >
> > - thread sampling:
> > http://cr.openjdk.java.net/~luchsh/thread_sampling/
> >
> > - biased locking events:
> > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> >
> > - G1 heap region (heap summary is still missing, Alibaba's patch does
> not support heap summary either):
> > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> >
> > Thanks,
> > Guangyu
> >
> >
> > ------------------------------------------------------------------
> > Sender:Andrey Petushkov <andrey at azul.com>
> > Sent At:2019 Mar. 6 (Wed.) 00:34
> > Recipient:Mario Torre <neugens at redhat.com>
> > Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <
> jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> > Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to
> OpenJDK8u
> >
> > Hi Mario,
> >
> > > On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> > >
> > > On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com>
> wrote:
> > >
> > >>> I'm going through the patch right now, but yes, from what I see the
> > >>> trace is removed. I had too a concern about this and was about to
> send
> > >>> a note. I'm not quite sure what to do, because Trace has been removed
> > >>> in 11 as far as I know, but removing mid stream in 8 may be a more
> > >>> interesting issue, however this isn't a user facing API, it was
> always
> > >>> meant to be internal to the JVM, so I don't quite know if there's
> > >>> really a reason we shouldn't change it. This is one question for the
> > >>> CSR group I think.
> > >> Since trace was removed by the same commit as JFR was added to jdk11
> my guess is that trace
> > >> was used internally at Oracle to integrate closed implementation of
> JFR. With this sense I see no point
> > >> to keep it. However if the guess is wrong and there some alternative
> implementation of trace event consumer
> > >> I will be happy to return it back
> > >
> > > Yes, I tend to agree with you, I do believe this is mostly an internal
> > > API for easy of patching with the JFR code (which is almost
> > > identical). The only concern is in the way the logging would be
> > > triggered externally and the compile time options for it (I still see
> > > a couple of instance where INCLUDE_TRACE is being used). As for
> > > triggering the logs, I don't recall that 8 has any means of doing
> > > this, I think some infrastructure came with 9 with the -Xlog option (I
> > > didn't follow this however, I'm not sure the option ever landed in 9)?
> > > In that case I guess it's safe to go after all.
> > Right, the new logging infrastructure is badly missing here. Both
> Alibaba and Azul have added means of
> > some JFR logging but far from what jdk11 could do. Let me check the rest
> of INCLUDE_TRACE places,
> > IMHO we should get rid of all of them, but cannot tell for sure now
> >
> > Andrey
> > >
> > > 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 Mar 13 15:55:37 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 13 Mar 2019 15:55:37 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <HE1PR0201MB226690D47F4753F6F9F246948A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
 <HE1PR0201MB226690D47F4753F6F9F246948A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <22437ea4-8b2d-0791-a6c4-42e54a613833@redhat.com>



On 13/03/2019 07:58, Langer, Christoph wrote:
> Hi Andrew,
> 
>> As I said yesterday [0], I think we need a label for fixes that are in
>> 8u-dev but are candidates for the current 8u after the initial
>> integration. Leaving this to bug comments makes them hard for us to find.
>>
>> I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as
>> previously used [1].
> 
> I think it sounds reasonable. We can use jdk8u-critical-request and jdk11u-critical-request, since we are not planning to ship CPUs in OpenJDK. This will avoid namespace collisions with Oracle.
> 
> I also think this should not only apply for changes that are already in jdk8u-dev/jdk11u-dev and shall be brought to jdk8u/jdk11u but also for direct pushes into jdk8u/jdk11u.
> 
> What do other people think, especially aph? If we agree on it, I'll update this part in the wiki and we can start living up to it.
> 

That sounds fine to me. Presumably, these would be paired with
jdk8u-critical-approved and jdk11u-critical-approved.

Thanks,
-- 
Andrew :)

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

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


From shade at redhat.com  Wed Mar 13 16:28:38 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 13 Mar 2019 17:28:38 +0100
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
Message-ID: <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>

On 3/12/19 11:54 AM, Severin Gehwolf wrote:
> On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/

This looks good, except the change in KdcPolicy.java. See below:
>> Original review:
>> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html
>>
>> This is not a clean backport because the tests in 8u differ slightly
>> from those in OpenJDK 10:
>>
>> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
>> That same change (adding a property to the @run line) also needs to be
>> applied to the new KdcPolicy.java test for it to succeed.

It looks to me that change to KdcPolicy.java does not relate to 8175120 (this one). It would be
confusing to backport that change under this bug ID? Maybe have a quick and separate 8u-specific fix?

Thanks,
-Aleksey


From martinrb at google.com  Wed Mar 13 16:58:00 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 09:58:00 -0700
Subject: OpenJDK 8u212 status
In-Reply-To: <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
 <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CA+kOe08_v2nDPn0g4wQYuohqj96nLy1=tysCdLeBEOr=jUHF0Q@mail.gmail.com>

On Wed, Mar 13, 2019 at 2:09 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

>
> I think Severin could be proposed as reviewer. He has enough pushes in
> jdk8u.
> I'd also love to be a reviewer in 8u but I think my stats there are still
> too low (I counted 18 distinct pushes) and the outlook for growth is not so
> big. Maybe my track record in the jdk project would help to close the gap
> but I'm not in the position to assess this. ??
>

I continue to think it's too hard to get Reviewer bits.  I am a jdk8u
Reviewer but that was not earned by making jdk8u changes.  All of you
actively working on jdk8u have earned Maintainer status IMO.

From jesper.wilhelmsson at oracle.com  Wed Mar 13 20:40:58 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 13 Mar 2019 21:40:58 +0100
Subject: OpenJDK 8u212 status
In-Reply-To: <357063d5ccad48c9db5513d381b8e78e7a0f8a02.camel@redhat.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
 <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <357063d5ccad48c9db5513d381b8e78e7a0f8a02.camel@redhat.com>
Message-ID: <A6B802CA-ACC3-4D20-A965-68F46818665E@oracle.com>

> On 13 Mar 2019, at 10:24, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> On Wed, 2019-03-13 at 09:08 +0000, Langer, Christoph wrote:
>>> Paul & Aleksey are both 8u reviewers. Are we in a position to propose
>>> any more?
>> 
>> I think Severin could be proposed as reviewer. He has enough pushes in jdk8u.
> 
> I'm flattered, thanks. It would be a bit awkward, though, since I'm not
> a reviewer in jdk/jdk.

Being a Reviewer in the jdk project is not a requirement to become a Reviewer in the jdk8u project. These are two separate projects. There are plenty of examples of developers who are Reviewers in jdk8u but not in jdk.

/Jesper

> 
> Thanks,
> Severin
> 


From gnu.andrew at redhat.com  Thu Mar 14 00:10:30 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 00:10:30 +0000
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <HE1PR0201MB22667950E904DC355B8151438A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
 <12469a4d-c6ce-52c8-1429-8e0b47b62eb3@redhat.com>
 <HE1PR0201MB22667950E904DC355B8151438A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <e1fb609e-672c-b7ad-f926-3e6df60a48fc@redhat.com>

On 13/03/2019 08:08, Langer, Christoph wrote:
>>> Adding security-dev as reviews should happen on the corresponding area
>>> lists. Even for 8.
>>>
>>
>> I'm not sure about this. We've never done that for 7u under Red Hat
>> leadership and I wonder whether it potentially risks fixes being delayed
>> by Oracle reviewers that are no longer interesting in working on 8u, not
>> to mention creating additional noise on the other lists.
> 
> It was the practice for JDK 8 updates so far. For me, the main benefit of including other lists in update reviews is the notification of potential reviewers that would usually not read the update mailing lists.
> 
> /Christoph
> 

Yeah, I've done it when Oracle were still leading the project. I guess I
just kind of assumed the noise wouldn't be welcome on the main lists,
but you make a good point about a wider reviewership. I'll forward the
ones I've posted so far.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Mar 14 02:31:15 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 02:31:15 +0000
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
 <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>
Message-ID: <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com>

On 13/03/2019 16:28, Aleksey Shipilev wrote:
> On 3/12/19 11:54 AM, Severin Gehwolf wrote:
>> On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/
> 
> This looks good, except the change in KdcPolicy.java. See below:
>>> Original review:
>>> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html
>>>
>>> This is not a clean backport because the tests in 8u differ slightly
>>> from those in OpenJDK 10:
>>>
>>> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
>>> That same change (adding a property to the @run line) also needs to be
>>> applied to the new KdcPolicy.java test for it to succeed.
> 
> It looks to me that change to KdcPolicy.java does not relate to 8175120 (this one). It would be
> confusing to backport that change under this bug ID? Maybe have a quick and separate 8u-specific fix?
> 

I guess. I didn't know about 8190690 until it came up as a diff between
the versions of the test in the backported patch and those in 8u. As
KdcPolicy.java was failing without it, it seemed logical to move it from
the files being removed to this new test so the replacement test was no
longer broken. But it does affect the clarity of the backport, you're right.

I've filed

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

for that issue and generated a new webrev for 8175120:

https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/


> Thanks,
> -Aleksey
> 

-- 
Andrew :)

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

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


From guangyu.zhu at aliyun.com  Thu Mar 14 02:39:55 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Thu, 14 Mar 2019 10:39:55 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>,
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
Message-ID: <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>

Ok. I look forward to the feedbacks from both of you.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Mario Torre <neugens.limasoftware at gmail.com>
Sent At:2019 Mar. 13 (Wed.) 19:26
Recipient:Andrey Petushkov <andrey at azul.com>
Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Thanks!

I?m currently traveling but I?ll offer my review as soon as I get back next week.

Cheers,
Mario
On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
Hi Guangyu,

 Cool! Thank you so much! Will review changes ASAP
 The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after 
 April update release (mostly limited by testing resources capacity)

 Regards,
 Andrey

 > On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
 > 
 > Hi Andrey, Mario
 > 
 > Is there any progress in backporting? We have completed the patch for the missing features. Please review. 
 > 
 > - thread sampling: 
 > http://cr.openjdk.java.net/~luchsh/thread_sampling/
 > 
 > - biased locking events: 
 > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
 > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
 > 
 > - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
 > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
 > 
 > Thanks,
 > Guangyu
 > 
 > 
 > ------------------------------------------------------------------
 > Sender:Andrey Petushkov <andrey at azul.com>
 > Sent At:2019 Mar. 6 (Wed.) 00:34
 > Recipient:Mario Torre <neugens at redhat.com>
 > Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
 > Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
 > 
 > Hi Mario,
 > 
 > > On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
 > > 
 > > On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
 > > 
 > >>> I'm going through the patch right now, but yes, from what I see the
 > >>> trace is removed. I had too a concern about this and was about to send
 > >>> a note. I'm not quite sure what to do, because Trace has been removed
 > >>> in 11 as far as I know, but removing mid stream in 8 may be a more
 > >>> interesting issue, however this isn't a user facing API, it was always
 > >>> meant to be internal to the JVM, so I don't quite know if there's
 > >>> really a reason we shouldn't change it. This is one question for the
 > >>> CSR group I think.
 > >> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
 > >> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
 > >> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
 > >> I will be happy to return it back
 > > 
 > > Yes, I tend to agree with you, I do believe this is mostly an internal
 > > API for easy of patching with the JFR code (which is almost
 > > identical). The only concern is in the way the logging would be
 > > triggered externally and the compile time options for it (I still see
 > > a couple of instance where INCLUDE_TRACE is being used). As for
 > > triggering the logs, I don't recall that 8 has any means of doing
 > > this, I think some infrastructure came with 9 with the -Xlog option (I
 > > didn't follow this however, I'm not sure the option ever landed in 9)?
 > > In that case I guess it's safe to go after all.
 > Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
 > some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
 > IMHO we should get rid of all of them, but cannot tell for sure now
 > 
 > Andrey
 > > 
 > > 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  Thu Mar 14 02:46:11 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 02:46:11 +0000
Subject: OpenJDK 8u212 status
In-Reply-To: <A6B802CA-ACC3-4D20-A965-68F46818665E@oracle.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
 <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <357063d5ccad48c9db5513d381b8e78e7a0f8a02.camel@redhat.com>
 <A6B802CA-ACC3-4D20-A965-68F46818665E@oracle.com>
Message-ID: <b7aa7157-b103-e507-da65-998d050f9fb1@redhat.com>

On 13/03/2019 20:40, jesper.wilhelmsson at oracle.com wrote:
>> On 13 Mar 2019, at 10:24, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>>
>> On Wed, 2019-03-13 at 09:08 +0000, Langer, Christoph wrote:
>>>> Paul & Aleksey are both 8u reviewers. Are we in a position to propose
>>>> any more?
>>>
>>> I think Severin could be proposed as reviewer. He has enough pushes in jdk8u.
>>
>> I'm flattered, thanks. It would be a bit awkward, though, since I'm not
>> a reviewer in jdk/jdk.
> 
> Being a Reviewer in the jdk project is not a requirement to become a Reviewer in the jdk8u project. These are two separate projects. There are plenty of examples of developers who are Reviewers in jdk8u but not in jdk.
> 
> /Jesper
> 
>>
>> Thanks,
>> Severin
>>
> 

I do think those of us outside Oracle are probably too stringent on
ourselves on this, and I don't see the same reluctance in proposing
votes among Oracle staff.

There are many who are reviewers for 9 and later without being reviewers
for earlier releases, simply because of the way reviewership is carried
forward to new JDK projects, but not applied retrospectively. If you
started working on OpenJDK at the time of OpenJDK 9 or 10, you likely
have committer or reviewer status there, but nothing further back. This
problem only gets deeper the further back you go and we struggle even
more for reviewers on OpenJDK 7.

At the end of the day, the only requirement in the bylaws [0] is that of
a vote, the legitimacy of which is conferred by the proposer being
someone who already holds the required status. Any further guidelines on
what makes someone eligible for that status are just that; guidelines.
My own interpretation of the bylaws is that the burden of proof for
rejecting such a nomination lies on the person who attempts to veto it
[1] and that the eligibility of the nominee is left down to the
discretion of the nominator.

With that in mind, I'm happy to suggest Christoph for jdk8u reviewership
(as he already has it for 9+) and Severin for jdk reviewership (we can
look into 8u after)

[0] https://openjdk.java.net/bylaws#reviewer
[1] https://openjdk.java.net/bylaws#veto
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Mar 14 03:11:53 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 03:11:53 +0000
Subject: Results: New OpenJDK 8u Reviewer: Mario Torre
Message-ID: <977b3734-f70f-7732-86e6-0fb12c00f192@redhat.com>

Voting for Mario Torre [0] is now closed.

Yes: 4
Veto: 0
Abstain: 0

Turnout: 4.2% (4/96)

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-February/008744.html
[1] http://openjdk.java.net/bylaws#three-vote-consensus
-- 
Andrew :)

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

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


From jesper.wilhelmsson at oracle.com  Thu Mar 14 03:31:26 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 14 Mar 2019 04:31:26 +0100
Subject: OpenJDK 8u212 status
In-Reply-To: <b7aa7157-b103-e507-da65-998d050f9fb1@redhat.com>
References: <HE1PR0201MB22667FD4239EA3017C5ACF268A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a8ee7e6c-740c-ce14-d1ba-797cd6fbb043@redhat.com>
 <HE1PR0201MB2266D7C967121BC89687EA748A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <357063d5ccad48c9db5513d381b8e78e7a0f8a02.camel@redhat.com>
 <A6B802CA-ACC3-4D20-A965-68F46818665E@oracle.com>
 <b7aa7157-b103-e507-da65-998d050f9fb1@redhat.com>
Message-ID: <C6B45CDC-DF24-4CBB-996B-310317412A86@oracle.com>



> On 14 Mar 2019, at 03:46, Andrew John Hughes <gnu.andrew at redhat.com> wrote:
> 
> On 13/03/2019 20:40, jesper.wilhelmsson at oracle.com wrote:
>>> On 13 Mar 2019, at 10:24, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>>> 
>>> On Wed, 2019-03-13 at 09:08 +0000, Langer, Christoph wrote:
>>>>> Paul & Aleksey are both 8u reviewers. Are we in a position to propose
>>>>> any more?
>>>> 
>>>> I think Severin could be proposed as reviewer. He has enough pushes in jdk8u.
>>> 
>>> I'm flattered, thanks. It would be a bit awkward, though, since I'm not
>>> a reviewer in jdk/jdk.
>> 
>> Being a Reviewer in the jdk project is not a requirement to become a Reviewer in the jdk8u project. These are two separate projects. There are plenty of examples of developers who are Reviewers in jdk8u but not in jdk.
>> 
>> /Jesper
>> 
>>> 
>>> Thanks,
>>> Severin
>>> 
>> 
> 
> I do think those of us outside Oracle are probably too stringent on
> ourselves on this, and I don't see the same reluctance in proposing
> votes among Oracle staff.
> 
> There are many who are reviewers for 9 and later without being reviewers
> for earlier releases, simply because of the way reviewership is carried
> forward to new JDK projects, but not applied retrospectively. If you
> started working on OpenJDK at the time of OpenJDK 9 or 10, you likely
> have committer or reviewer status there, but nothing further back. This
> problem only gets deeper the further back you go and we struggle even
> more for reviewers on OpenJDK 7.
> 
> At the end of the day, the only requirement in the bylaws [0] is that of
> a vote, the legitimacy of which is conferred by the proposer being
> someone who already holds the required status. Any further guidelines on
> what makes someone eligible for that status are just that; guidelines.
> My own interpretation of the bylaws is that the burden of proof for
> rejecting such a nomination lies on the person who attempts to veto it
> [1] and that the eligibility of the nominee is left down to the
> discretion of the nominator.

Yes, I think this is exactly how to interpret the bylaws.

> With that in mind, I'm happy to suggest Christoph for jdk8u reviewership
> (as he already has it for 9+) and Severin for jdk reviewership (we can
> look into 8u after)

I was about to follow up my email with a nomination of Severin for 8u Reviewer but I realized that I'm not a Reviewer in 8u myself so that didn't work... :-)
/Jesper

> 
> [0] https://openjdk.java.net/bylaws#reviewer
> [1] https://openjdk.java.net/bylaws#veto
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
> 


From gnu.andrew at redhat.com  Thu Mar 14 03:35:15 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 03:35:15 +0000
Subject: CFV: New OpenJDK 8u Reviewer: Christoph Langer
Message-ID: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>

I hereby nominate Christoph Langer [0] for the role of OpenJDK 8u Reviewer.

He's a active member of many OpenJDK projects, including being
a reviewer on OpenJDK 9 and up, and a committer to the Metropolis project.

Most of his commits have been to OpenJDK 9 and later,
but there are still a fair number in 8u [1] [2].

In a similar manner to Andrew Dinn's nomination [3], his lack of
reviewer status on OpenJDK 8 Updates, while holding it on all later
releases, seems more a simple case of when he gained JDK reviewership -
as the same status is conferred on to new JDK releases, but
not retrospectively to older ones - than a lack of sufficient
technical qualification.  With the new JDK and JDK-Updates projects
covering all releases, this is a problem that only really applies
to the older releases.

Votes are due by the 27th of March, 2018, at 17h00 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] http://openjdk.java.net/census#clanger
[1]
https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
[2]
https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
[3]
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-November/008135.html
[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)

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


From gnu.andrew at redhat.com  Thu Mar 14 03:36:26 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 03:36:26 +0000
Subject: CFV: New OpenJDK 8u Reviewer: Christoph Langer
In-Reply-To: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
References: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
Message-ID: <ab2f67f0-1fd4-7580-c951-c60dd979ddfc@redhat.com>

On 14/03/2019 03:35, Andrew John Hughes wrote:
> I hereby nominate Christoph Langer [0] for the role of OpenJDK 8u Reviewer.
> 
> He's a active member of many OpenJDK projects, including being
> a reviewer on OpenJDK 9 and up, and a committer to the Metropolis project.
> 
> Most of his commits have been to OpenJDK 9 and later,
> but there are still a fair number in 8u [1] [2].
> 
> In a similar manner to Andrew Dinn's nomination [3], his lack of
> reviewer status on OpenJDK 8 Updates, while holding it on all later
> releases, seems more a simple case of when he gained JDK reviewership -
> as the same status is conferred on to new JDK releases, but
> not retrospectively to older ones - than a lack of sufficient
> technical qualification.  With the new JDK and JDK-Updates projects
> covering all releases, this is a problem that only really applies
> to the older releases.
> 
> Votes are due by the 27th of March, 2018, at 17h00 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] http://openjdk.java.net/census#clanger
> [1]
> https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
> [2]
> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
> [3]
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-November/008135.html
> [4] http://openjdk.java.net/census#jdk8u
> [5] http://openjdk.java.net/bylaws#three-vote-consensus
> 

Vote: Yes.
-- 
Andrew :)

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

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


From martinrb at google.com  Thu Mar 14 03:40:34 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 20:40:34 -0700
Subject: CFV: New OpenJDK 8u Reviewer: Christoph Langer
In-Reply-To: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
References: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
Message-ID: <CA+kOe0-eXhOZg_fRfgE1KYN_UirWiCqobj2_gGoY1sN5L0D5bA@mail.gmail.com>

Vote: yes

From vladimir.kozlov at oracle.com  Thu Mar 14 03:49:18 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Mar 2019 20:49:18 -0700
Subject: CFV: New OpenJDK 8u Reviewer: Christoph Langer
In-Reply-To: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
References: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
Message-ID: <81a79499-76c3-f4c2-cb29-93528d6438bb@oracle.com>

Vote: yes

On 3/13/19 8:35 PM, Andrew John Hughes wrote:
> I hereby nominate Christoph Langer [0] for the role of OpenJDK 8u Reviewer.
> 
> He's a active member of many OpenJDK projects, including being
> a reviewer on OpenJDK 9 and up, and a committer to the Metropolis project.
> 
> Most of his commits have been to OpenJDK 9 and later,
> but there are still a fair number in 8u [1] [2].
> 
> In a similar manner to Andrew Dinn's nomination [3], his lack of
> reviewer status on OpenJDK 8 Updates, while holding it on all later
> releases, seems more a simple case of when he gained JDK reviewership -
> as the same status is conferred on to new JDK releases, but
> not retrospectively to older ones - than a lack of sufficient
> technical qualification.  With the new JDK and JDK-Updates projects
> covering all releases, this is a problem that only really applies
> to the older releases.
> 
> Votes are due by the 27th of March, 2018, at 17h00 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] http://openjdk.java.net/census#clanger
> [1]
> https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
> [2]
> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
> [3]
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-November/008135.html
> [4] http://openjdk.java.net/census#jdk8u
> [5] http://openjdk.java.net/bylaws#three-vote-consensus
> 

From shade at redhat.com  Thu Mar 14 08:56:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Mar 2019 09:56:37 +0100
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
 <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>
 <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com>
Message-ID: <9e717b95-1b62-390c-9c25-ea63783668d0@redhat.com>

On 3/14/19 3:31 AM, Andrew John Hughes wrote:
> I've filed
> https://bugs.openjdk.java.net/browse/JDK-8220641

Yes, let's RFR and push that too.

> for that issue and generated a new webrev for 8175120:
> 
> https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/

Looks good!

-Aleksey



From shade at redhat.com  Thu Mar 14 08:58:26 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Mar 2019 09:58:26 +0100
Subject: CFV: New OpenJDK 8u Reviewer: Christoph Langer
In-Reply-To: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
References: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
Message-ID: <50f64479-dd0f-e7ca-fffc-99a11686ddf0@redhat.com>

Vote: yes

On 3/14/19 4:35 AM, Andrew John Hughes wrote:
> I hereby nominate Christoph Langer [0] for the role of OpenJDK 8u Reviewer.




From goetz.lindenmaier at sap.com  Thu Mar 14 09:28:25 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 14 Mar 2019 09:28:25 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
Message-ID: <VI1PR02MB5183663A722F60CBD17CAFD1EC4B0@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi Paul, 

> There are two 11.0.3 tags in jdk11u-dev,
Please note that it is jdk11u that is tagged, the changes are thereafter merged
to jdk11u-dev, so the tags happen to show up there, too.
jdk11u-dev contains changes targeted to 11.0.4.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Hohensee, Paul
> Sent: Donnerstag, 7. M?rz 2019 21:04
> To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: [DMARC FAILURE] openjdk8u212 and openjdk11.0.3 code
> freeze/rampdown dates
> 
> We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are
> two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9
> backports left on the u211/212 list. One is out for review (JDK-
> 8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to
> be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re
> all pretty small. Just need jdk8u-fix-yes tags. :)
> 
> I haven?t seen code freeze dates for non-embargoed patches candidates, but
> may have missed them going by. If they aren?t yet determined, it?d be excellent
> to have them so we can plan rampdown.
> 
> Thanks,
> 
> Paul


From andrey at azul.com  Thu Mar 14 11:44:18 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Thu, 14 Mar 2019 11:44:18 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <0ad5650b-6534-411b-a066-3d49b336bc14.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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
Message-ID: <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>

Hi Guangyu,

By the moment I've read first two patches (thread sampling and biased locks). These look good to me
One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it

I need a bit more time to read through G1 heap region types one.
BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please

Thanks a lot,
Andrey

> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> Ok. I look forward to the feedbacks from both of you.
> 
> Thanks,
> Guangyu
> ------------------------------------------------------------------
> Sender:Mario Torre <neugens.limasoftware at gmail.com>
> Sent At:2019 Mar. 13 (Wed.) 19:26
> Recipient:Andrey Petushkov <andrey at azul.com>
> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Thanks!
> 
> I?m currently traveling but I?ll offer my review as soon as I get back next week.
> 
> Cheers,
> Mario
> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
> Hi Guangyu,
> 
> Cool! Thank you so much! Will review changes ASAP
> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
> April update release (mostly limited by testing resources capacity)
> 
> Regards,
> Andrey
> 
> > On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >
> > Hi Andrey, Mario
> >
> > Is there any progress in backporting? We have completed the patch for the missing features. Please review.
> >
> > - thread sampling:
> > http://cr.openjdk.java.net/~luchsh/thread_sampling/
> >
> > - biased locking events:
> > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> >
> > - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
> > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> >
> > Thanks,
> > Guangyu
> >
> >
> > ------------------------------------------------------------------
> > Sender:Andrey Petushkov <andrey at azul.com>
> > Sent At:2019 Mar. 6 (Wed.) 00:34
> > Recipient:Mario Torre <neugens at redhat.com>
> > Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> > Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >
> > Hi Mario,
> >
> > > On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> > >
> > > On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> > >
> > >>> I'm going through the patch right now, but yes, from what I see the
> > >>> trace is removed. I had too a concern about this and was about to send
> > >>> a note. I'm not quite sure what to do, because Trace has been removed
> > >>> in 11 as far as I know, but removing mid stream in 8 may be a more
> > >>> interesting issue, however this isn't a user facing API, it was always
> > >>> meant to be internal to the JVM, so I don't quite know if there's
> > >>> really a reason we shouldn't change it. This is one question for the
> > >>> CSR group I think.
> > >> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> > >> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> > >> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> > >> I will be happy to return it back
> > >
> > > Yes, I tend to agree with you, I do believe this is mostly an internal
> > > API for easy of patching with the JFR code (which is almost
> > > identical). The only concern is in the way the logging would be
> > > triggered externally and the compile time options for it (I still see
> > > a couple of instance where INCLUDE_TRACE is being used). As for
> > > triggering the logs, I don't recall that 8 has any means of doing
> > > this, I think some infrastructure came with 9 with the -Xlog option (I
> > > didn't follow this however, I'm not sure the option ever landed in 9)?
> > > In that case I guess it's safe to go after all.
> > Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
> > some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
> > IMHO we should get rid of all of them, but cannot tell for sure now
> >
> > Andrey
> > >
> > > 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  Thu Mar 14 13:05:20 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Mar 2019 14:05:20 +0100
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <72570676-d5df-d003-2364-f693a7be6be5@redhat.com>

On 3/12/19 11:25 AM, Langer, Christoph wrote:
> JDK11u:
> https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

It is a good start, but I feel it does not help the outsiders, who would be as puzzled after reading
that page. Concrete suggestions:

 *) Let's spell out:
     "Current status:
       jdk-updates/jdk11u-dev repository collects non-critical update fixes, targeted to 11.0.4.
       jdk-updates/jdk11u repository is stabilizing for 11.0.3 release"


 *) We need a verbose "How Do I" section, for example

 ------ 8< -----------------------------------------------------------------------
How Do I...

...Suggest the Change

Normally, requesters are expected to do the bulk of the backporting work. If do not have time and
resources to do the work, you have to find someone who would. You can ask around the original
authors of the change and/or current (co-)maintainers in the update release.

...Request the Backport

Backports are the issues that exist in later JDK versions and need to be applied to lower ones as well.

 1. Pick the existing issue from the JBS
      - Take careful note of the linked issues that need to be brought with
        the fix, especially the follow-up fixes;
      - If there are relevant issues that prevent clean backport, consider backporting
        those first (within reason)
 2. Check out the jdk-updates/jdk11u-dev, and try to apply the patch there
      - Make sure to keep the changeset metadata: original authors, Reviewed-by: lines, etc
 3. If patch does not apply cleanly, you have to start the RFR thread at jdk-updates-dev@
      - Need to state what changes were needed and why
      - Optionally, seek the review from the original authors
 4. Test the patch
      - "tier1" tests should be passing at all times
      - Look at what area the patch affects, and run the tests from there
      - New regression tests that come with the patch should pass
      - Optionally, new regression tests may need to be verified to fail without the patch
 5. Once everything is done, put jdk11u-fix-request tag and the "Fix Request" comment on the issue
      - Fix Request should explain why the fix should be backported, what testing was done,
        and the risk estimate
 6. Wait for maintainer approval, which would manifest as jdk11u-fix-yes tag on the issue
 7. Push the change
      - You might need a sponsor in jdk-updates project, ask at jdk-updates-dev@ list
 8. Wait around to resolve any problems that might arise from the push


...Request the Change (without Backport)

There are cases when the lower JDK release needs to have the patch that is not required for the
higher JDK releases. The same rule set applies, as for backports, with mandatory RFR at
jdk-updates-dev list.


...Keep the Changeset Metadata

The easiest way to keep metadata is to import the full changeset from Mercurial.
<mq example goes here>

...Test the Change

<jtreg example goes here>

...Submit the RFR (Request For Review)

<RFR template goes here>

 ------ 8< -----------------------------------------------------------------------

-Aleksey


From christoph.langer at sap.com  Thu Mar 14 13:22:55 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Mar 2019 13:22:55 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <72570676-d5df-d003-2364-f693a7be6be5@redhat.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <72570676-d5df-d003-2364-f693a7be6be5@redhat.com>
Message-ID: <HE1PR0201MB22666527908C4CF97C99E5F08A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Aleksey,

> It is a good start, but I feel it does not help the outsiders, who would be as
> puzzled after reading that page.

yeah, I tend to agree...

> Concrete suggestions:
> 
>  *) Let's spell out:
>      "Current status:
>        jdk-updates/jdk11u-dev repository collects non-critical update fixes,
> targeted to 11.0.4.
>        jdk-updates/jdk11u repository is stabilizing for 11.0.3 release"
> 

Good idea. I'll add that section.

With that section it is important, though, that we keep it up to date. Maybe I shall also create a "release engineers recipe/to do list" for things to do during a release cycle, e.g. bump version numbers, set initial tags, branches etc. Probably worth another Wiki page. I'll look into that, too.

>  *) We need a verbose "How Do I" section, for example
> 
>  ------ 8< -----------------------------------------------------------------------
> How Do I...
> 
> ...Suggest the Change
> 
> Normally, requesters are expected to do the bulk of the backporting work. If
> do not have time and
> resources to do the work, you have to find someone who would. You can ask
> around the original
> authors of the change and/or current (co-)maintainers in the update release.
> 
> ...Request the Backport
> 
> Backports are the issues that exist in later JDK versions and need to be
> applied to lower ones as well.
> 
>  1. Pick the existing issue from the JBS
>       - Take careful note of the linked issues that need to be brought with
>         the fix, especially the follow-up fixes;
>       - If there are relevant issues that prevent clean backport, consider
> backporting
>         those first (within reason)
>  2. Check out the jdk-updates/jdk11u-dev, and try to apply the patch there
>       - Make sure to keep the changeset metadata: original authors, Reviewed-
> by: lines, etc
>  3. If patch does not apply cleanly, you have to start the RFR thread at jdk-
> updates-dev@
>       - Need to state what changes were needed and why
>       - Optionally, seek the review from the original authors
>  4. Test the patch
>       - "tier1" tests should be passing at all times
>       - Look at what area the patch affects, and run the tests from there
>       - New regression tests that come with the patch should pass
>       - Optionally, new regression tests may need to be verified to fail without
> the patch
>  5. Once everything is done, put jdk11u-fix-request tag and the "Fix Request"
> comment on the issue
>       - Fix Request should explain why the fix should be backported, what
> testing was done,
>         and the risk estimate
>  6. Wait for maintainer approval, which would manifest as jdk11u-fix-yes tag
> on the issue
>  7. Push the change
>       - You might need a sponsor in jdk-updates project, ask at jdk-updates-
> dev@ list
>  8. Wait around to resolve any problems that might arise from the push
> 
> 
> ...Request the Change (without Backport)
> 
> There are cases when the lower JDK release needs to have the patch that is
> not required for the
> higher JDK releases. The same rule set applies, as for backports, with
> mandatory RFR at
> jdk-updates-dev list.
> 
> 
> ...Keep the Changeset Metadata
> 
> The easiest way to keep metadata is to import the full changeset from
> Mercurial.
> <mq example goes here>
> 
> ...Test the Change
> 
> <jtreg example goes here>
> 
> ...Submit the RFR (Request For Review)
> 
> <RFR template goes here>
> 
>  ------ 8< -----------------------------------------------------------------------

That's also a very good idea. I will look into adding such a HowTo starting off with your proposal. Do you think it should be on the main page or shall I create a separate page and link to it? It's quite a bit content and might bloat the main page.

It's also maybe a bit orthogonal to Severin's guide: https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance. 

Best regards
Christoph


From christoph.langer at sap.com  Thu Mar 14 13:25:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Mar 2019 13:25:29 +0000
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <22437ea4-8b2d-0791-a6c4-42e54a613833@redhat.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com>
 <HE1PR0201MB226690D47F4753F6F9F246948A4A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <22437ea4-8b2d-0791-a6c4-42e54a613833@redhat.com>
Message-ID: <HE1PR0201MB22669784EB3568ED66C4F51D8A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> >> As I said yesterday [0], I think we need a label for fixes that are in
> >> 8u-dev but are candidates for the current 8u after the initial
> >> integration. Leaving this to bug comments makes them hard for us to find.
> >>
> >> I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as
> >> previously used [1].
> >
> > I think it sounds reasonable. We can use jdk8u-critical-request and jdk11u-
> critical-request, since we are not planning to ship CPUs in OpenJDK. This will
> avoid namespace collisions with Oracle.
> >
> > I also think this should not only apply for changes that are already in jdk8u-
> dev/jdk11u-dev and shall be brought to jdk8u/jdk11u but also for direct
> pushes into jdk8u/jdk11u.
> >
> > What do other people think, especially aph? If we agree on it, I'll update
> this part in the wiki and we can start living up to it.
> >
> 
> That sounds fine to me. Presumably, these would be paired with
> jdk8u-critical-approved and jdk11u-critical-approved.

Ok, let's wait a bit for further feedback to this. But if I don't get objections, I'll amend that to the process description on the wiki page and I'll also create appropriate JBS filters which we'd need then.

Best regards
Christoph


From shade at redhat.com  Thu Mar 14 13:31:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Mar 2019 14:31:37 +0100
Subject: [8u, 11u] Wiki Page updates
In-Reply-To: <HE1PR0201MB22666527908C4CF97C99E5F08A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22666E2F3852D799A88E78CA8A490@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <72570676-d5df-d003-2364-f693a7be6be5@redhat.com>
 <HE1PR0201MB22666527908C4CF97C99E5F08A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <215ef40d-3d8d-8ff8-5249-9f8d62aad0f0@redhat.com>

On 3/14/19 2:22 PM, Langer, Christoph wrote:
> That's also a very good idea. I will look into adding such a HowTo starting off with your
> proposal. Do you think it should be on the main page or shall I create a separate page and link
> to it? It's quite a bit content and might bloat the main page.

I think all the "fast path" info should be on the main page. Gory details may be in sub-pages.

Thinking from the outsider perspective, I should come in, spend 5 minutes to read the checklist,
understand what is nominally expected and start doing it. As I go, maintainers and reviewers can
point me to "full" policies on other pages.

-Aleksey


From hohensee at amazon.com  Thu Mar 14 18:50:37 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 14 Mar 2019 18:50:37 +0000
Subject: New OpenJDK 8u Reviewer: Christoph Langer
In-Reply-To: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
References: <9bea8f23-7a12-7965-cf6c-048f8890d724@redhat.com>
Message-ID: <A5FC5D8A-7A13-449F-BE63-2850BECAB0F4@amazon.com>

Vote: yes

?On 3/13/19, 8:37 PM, "jdk8u-dev on behalf of Andrew John Hughes" <jdk8u-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    I hereby nominate Christoph Langer [0] for the role of OpenJDK 8u Reviewer.
    
    He's a active member of many OpenJDK projects, including being
    a reviewer on OpenJDK 9 and up, and a committer to the Metropolis project.
    
    Most of his commits have been to OpenJDK 9 and later,
    but there are still a fair number in 8u [1] [2].
    
    In a similar manner to Andrew Dinn's nomination [3], his lack of
    reviewer status on OpenJDK 8 Updates, while holding it on all later
    releases, seems more a simple case of when he gained JDK reviewership -
    as the same status is conferred on to new JDK releases, but
    not retrospectively to older ones - than a lack of sufficient
    technical qualification.  With the new JDK and JDK-Updates projects
    covering all releases, this is a problem that only really applies
    to the older releases.
    
    Votes are due by the 27th of March, 2018, at 17h00 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] http://openjdk.java.net/census#clanger
    [1]
    https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
    [2]
    https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(clanger)+or+desc(%22christoph.langer%40sap.com%22))+and+not+merge()
    [3]
    https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-November/008135.html
    [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)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew
    
    


From hohensee at amazon.com  Thu Mar 14 18:59:22 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 14 Mar 2019 18:59:22 +0000
Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates
In-Reply-To: <VI1PR02MB5183663A722F60CBD17CAFD1EC4B0@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <B4D00362-1D97-4CB6-A4A4-A97AB5C36C3E@amazon.com>
 <VI1PR02MB5183663A722F60CBD17CAFD1EC4B0@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <8A7BCA18-7EBA-43E8-B0CF-E196B00F370B@amazon.com>

Thanks, that clarifies things for me.

Paul

?On 3/14/19, 2:29 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:

    Hi Paul, 
    
    > There are two 11.0.3 tags in jdk11u-dev,
    Please note that it is jdk11u that is tagged, the changes are thereafter merged
    to jdk11u-dev, so the tags happen to show up there, too.
    jdk11u-dev contains changes targeted to 11.0.4.
    
    Best regards,
      Goetz.
    
    
    > -----Original Message-----
    > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
    > Behalf Of Hohensee, Paul
    > Sent: Donnerstag, 7. M?rz 2019 21:04
    > To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
    > Subject: [DMARC FAILURE] openjdk8u212 and openjdk11.0.3 code
    > freeze/rampdown dates
    > 
    > We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are
    > two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9
    > backports left on the u211/212 list. One is out for review (JDK-
    > 8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to
    > be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re
    > all pretty small. Just need jdk8u-fix-yes tags. :)
    > 
    > I haven?t seen code freeze dates for non-embargoed patches candidates, but
    > may have missed them going by. If they aren?t yet determined, it?d be excellent
    > to have them so we can plan rampdown.
    > 
    > Thanks,
    > 
    > Paul
    
    


From gnu.andrew at redhat.com  Fri Mar 15 04:55:45 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 15 Mar 2019 04:55:45 +0000
Subject: [RFR] [8u] 8220641, ,
 New test KdcPolicy.java introduced by JDK-8164656
 needs same change as JDK-8190690
Message-ID: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/

This is the patch we split out from my original post for 8175120. It
applies the same change to the @run command in KdcPolicy.java as was
applied to the tests deleted by 8175120 in JDK-8190690.

Without this fix, the test fails with a name lookup error. With it, it
passes.

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

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

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


From sgehwolf at redhat.com  Fri Mar 15 09:07:52 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 15 Mar 2019 10:07:52 +0100
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
Message-ID: <715a7ac719a9a1ef652fd12c8050ab1d80913e9a.camel@redhat.com>

Hi Andrew,

On Fri, 2019-03-15 at 04:55 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
> Webrev: 
> https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
> 
> This is the patch we split out from my original post for 8175120. It
> applies the same change to the @run command in KdcPolicy.java as was
> applied to the tests deleted by 8175120 in JDK-8190690.
> 
> Without this fix, the test fails with a name lookup error. With it, it
> passes.

This looks good to me. I'm not an 8u Reviewer, though.

Thanks,
Severin


> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html


From jiapeng.li at perfma.com  Fri Mar 15 09:46:39 2019
From: jiapeng.li at perfma.com (=?utf-8?B?5a+S5rOJ5a2Q?=)
Date: Fri, 15 Mar 2019 17:46:39 +0800
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
Message-ID: <tencent_7C2180971581EF2E543060E1@qq.com>

Recently, our company(PerfMa) is troubleshooting a JVM problem for a customer (JDK1.8.0_191-b12), and found that the process is always killed by the OS, which is caused by memory leaks. Finally, it was discovered that OOM is caused by a large amount of memory allocated by C2 thread. This is a bug in C2. The following is the troubleshooting process:

First, through /proc/<pid>/smaps, I saw a lot of 64MB of memory allocation, and RSS is basically exhausted.
7fd690000000-7fd693f23000 rw-p 00000000 00:00 0  Size:              64652 kB Rss:               64652 kB Pss:               64652 kB Shared_Clean:          0 kB Shared_Dirty:          0 kB Private_Clean:         0 kB Private_Dirty:     64652 kB Referenced:        64652 kB Anonymous:         64652 kB AnonHugePages:         0 kB Swap:                  0 kB KernelPageSize:        4 kB MMUPageSize:           4 kB Locked:                0 kB VmFlags: rd wr mr mw me nr sd  7fd693f23000-7fd694000000 ---p 00000000 00:00 0  Size:                884 kB Rss:                   0 kB Pss:                   0 kB Shared_Clean:          0 kB Shared_Dirty:          0 kB Private_Clean:         0 kB Private_Dirty:         0 kB Referenced:            0 kB Anonymous:             0 kB AnonHugePages:         0 kB Swap:                  0 kB KernelPageSize:        4 kB MMUPageSize:           4 kB Locked:                0 kB VmFlags: mr mw me nr sd 

Then trace the system call through the strace command, combined with the above virtual address, we found the corresponding mmap system call

[pid 71] 13:34:41.982589 mmap(0x7fd690000000, 67108864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fd690000000 <0.000107>

The thread that executes mmap is the 71 thread, so the thread is dumped through jstack, and the corresponding thread is found to be C2 CompilerThread0.
"C2 CompilerThread0" #39 daemon prio=9 os_prio=0 tid=0x00007fd8acebb000 nid=0x47 runnable [0x0000000000000000]    java.lang.Thread.State: RUNNABLE

Then grep the output of strace, see a lot of memory were allocated by this thread, probably more than 2G.

C2 is memory-limited under normal circumstances, but why is there a memory consumption greater than 2G? Finally, we found that a bug in the JVM will cause memory leaks. The location of this code is the nmethod::metadata_do method of nmethod.cpp:
void nmethod::metadata_do(void f(Metadata*)) {   address low_boundary = verified_entry_point();   if (is_not_entrant()) {     low_boundary += NativeJump::instruction_size;     // %%% Note:  On SPARC we patch only a 4-byte trap, not a full NativeJump.     // (See comment above.)   }   {     // Visit all immediate references that are embedded in the instruction stream.     RelocIterator iter(this, low_boundary);     while (iter.next()) {       if (iter.type() == relocInfo::metadata_type ) {         metadata_Relocation* r = iter.metadata_reloc();         // In this metadata, we must only follow those metadatas directly embedded in         // the code.  Other metadatas (oop_index>0) are seen as part of         // the metadata section below.         assert(1 == (r->metadata_is_immediate()) +                (r->metadata_addr() >= metadata_begin() && r->metadata_addr() < metadata_end()),                ?metadata must be found in exactly one place?);         if (r->metadata_is_immediate() && r->metadata_value() != NULL) {           Metadata* md = r->metadata_value();           if (md != _method) f(md);         }       } else if (iter.type() == relocInfo::virtual_call_type) {         // Check compiledIC holders associated with this nmethod         CompiledIC *ic = CompiledIC_at(&iter);         if (ic->is_icholder_call()) {           CompiledICHolder* cichk = ic->cached_icholder();           f(cichk->holder_metadata());           f(cichk->holder_klass());         } else {           Metadata* ic_oop = ic->cached_metadata();           if (ic_oop != NULL) {             f(ic_oop);           }         }       }     }   }

Because CompiledIC is a ResourceObj, but it is not freed by ResourceMark, so when this method is called multiple times, OOM will appear.

The fix is very simple, just add ResourceMark rm; before CompiledIC *ic = CompiledIC_at(&iter);

Can this patch be entered into JDK8?



Best,
- Jia Peng @ PerfMa

From tobias.hartmann at oracle.com  Fri Mar 15 10:01:02 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 15 Mar 2019 11:01:02 +0100
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <tencent_7C2180971581EF2E543060E1@qq.com>
References: <tencent_7C2180971581EF2E543060E1@qq.com>
Message-ID: <a17e14fa-7b28-c6b3-e1db-c757fd90e877@oracle.com>

Hi Jia Peng,

thanks for reporting this!

It seems that the bug was fixed in JDK 12 by JDK-8208677 [1]:
http://hg.openjdk.java.net/jdk/jdk/rev/aa3bfacc912c#l4.7

Coleen, any details here?

Thanks,
Tobias

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

On 15.03.19 10:46, ??? wrote:
> Recently, our company(PerfMa) is troubleshooting a JVM problem for a customer (JDK1.8.0_191-b12), and found that the process is always killed by the OS, which is caused by memory leaks. Finally, it was discovered that OOM is caused by a large amount of memory allocated by C2 thread. This is a bug in C2. The following is the troubleshooting process:
> 
> First, through /proc/<pid>/smaps, I saw a lot of 64MB of memory allocation, and RSS is basically exhausted.
> 7fd690000000-7fd693f23000 rw-p 00000000 00:00 0  Size:              64652 kB Rss:               64652 kB Pss:               64652 kB Shared_Clean:          0 kB Shared_Dirty:          0 kB Private_Clean:         0 kB Private_Dirty:     64652 kB Referenced:        64652 kB Anonymous:         64652 kB AnonHugePages:         0 kB Swap:                  0 kB KernelPageSize:        4 kB MMUPageSize:           4 kB Locked:                0 kB VmFlags: rd wr mr mw me nr sd  7fd693f23000-7fd694000000 ---p 00000000 00:00 0  Size:                884 kB Rss:                   0 kB Pss:                   0 kB Shared_Clean:          0 kB Shared_Dirty:          0 kB Private_Clean:         0 kB Private_Dirty:         0 kB Referenced:            0 kB Anonymous:             0 kB AnonHugePages:         0 kB Swap:                  0 kB KernelPageSize:        4 kB MMUPageSize:           4 kB Locked:                0 kB VmFlags: mr mw me nr sd 
> 
> Then trace the system call through the strace command, combined with the above virtual address, we found the corresponding mmap system call
> 
> [pid 71] 13:34:41.982589 mmap(0x7fd690000000, 67108864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fd690000000 <0.000107>
> 
> The thread that executes mmap is the 71 thread, so the thread is dumped through jstack, and the corresponding thread is found to be C2 CompilerThread0.
> "C2 CompilerThread0" #39 daemon prio=9 os_prio=0 tid=0x00007fd8acebb000 nid=0x47 runnable [0x0000000000000000]    java.lang.Thread.State: RUNNABLE
> 
> Then grep the output of strace, see a lot of memory were allocated by this thread, probably more than 2G.
> 
> C2 is memory-limited under normal circumstances, but why is there a memory consumption greater than 2G? Finally, we found that a bug in the JVM will cause memory leaks. The location of this code is the nmethod::metadata_do method of nmethod.cpp:
> void nmethod::metadata_do(void f(Metadata*)) {   address low_boundary = verified_entry_point();   if (is_not_entrant()) {     low_boundary += NativeJump::instruction_size;     // %%% Note:  On SPARC we patch only a 4-byte trap, not a full NativeJump.     // (See comment above.)   }   {     // Visit all immediate references that are embedded in the instruction stream.     RelocIterator iter(this, low_boundary);     while (iter.next()) {       if (iter.type() == relocInfo::metadata_type ) {         metadata_Relocation* r = iter.metadata_reloc();         // In this metadata, we must only follow those metadatas directly embedded in         // the code.  Other metadatas (oop_index>0) are seen as part of         // the metadata section below.         assert(1 == (r->metadata_is_immediate()) +                (r->metadata_addr() >= metadata_begin() && r->metadata_addr() < metadata_end()),                ?metadata must be found in exactly one place?);         if (r->metadata_is_immediate() && r->metadata_value() != NULL) {           Metadata* md = r->metadata_value();           if (md != _method) f(md);         }       } else if (iter.type() == relocInfo::virtual_call_type) {         // Check compiledIC holders associated with this nmethod         CompiledIC *ic = CompiledIC_at(&iter);         if (ic->is_icholder_call()) {           CompiledICHolder* cichk = ic->cached_icholder();           f(cichk->holder_metadata());           f(cichk->holder_klass());         } else {           Metadata* ic_oop = ic->cached_metadata();           if (ic_oop != NULL) {             f(ic_oop);           }         }       }     }   }
> 
> Because CompiledIC is a ResourceObj, but it is not freed by ResourceMark, so when this method is called multiple times, OOM will appear.
> 
> The fix is very simple, just add ResourceMark rm; before CompiledIC *ic = CompiledIC_at(&iter);
> 
> Can this patch be entered into JDK8?
> 
> 
> 
> Best,
> - Jia Peng @ PerfMa
> 

From nijiaben at perfma.com  Fri Mar 15 10:18:45 2019
From: nijiaben at perfma.com (=?utf-8?B?bmlqaWFiZW4=?=)
Date: Fri, 15 Mar 2019 18:18:45 +0800
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
Message-ID: <tencent_38CBFF5D52DD77C76C6409FA@qq.com>

Hi, All

Recently, I?m troubleshooting a JVM problem (JDK1.8.0_191-b12), and found that the process is always killed by the OS, which is caused by memory leaks. Finally, it was discovered that OOM is caused by a large amount of memory allocated by C2 thread. This is a bug in C2. The following is the troubleshooting process:

First, through /proc//smaps, I saw a lot of 64MB of memory allocation, and RSS is basically exhausted.
7fd690000000-7fd693f23000 rw-p 00000000 00:00 0  Size:              64652 kB Rss:               64652 kB Pss:               64652 kB Shared_Clean:          0 kB Shared_Dirty:          0 kB Private_Clean:         0 kB Private_Dirty:     64652 kB Referenced:        64652 kB Anonymous:         64652 kB AnonHugePages:         0 kB Swap:                  0 kB KernelPageSize:        4 kB MMUPageSize:           4 kB Locked:                0 kB VmFlags: rd wr mr mw me nr sd  7fd693f23000-7fd694000000 ---p 00000000 00:00 0  Size:                884 kB Rss:                   0 kB Pss:                   0 kB Shared_Clean:          0 kB Shared_Dirty:          0 kB Private_Clean:         0 kB Private_Dirty:         0 kB Referenced:            0 kB Anonymous:             0 kB AnonHugePages:         0 kB Swap:                  0 kB KernelPageSize:        4 kB MMUPageSize:           4 kB Locked:                0 kB VmFlags: mr mw me nr sd 

Then trace the system call through the strace command, combined with the above virtual address, we found the corresponding mmap system call[pid 71] 13:34:41.982589 mmap(0x7fd690000000, 67108864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fd690000000 <0.000107>The thread that executes mmap is the 71 thread, so the thread is dumped through jstack, and the corresponding thread is found to be C2 CompilerThread0.
"C2 CompilerThread0" #39 daemon prio=9 os_prio=0 tid=0x00007fd8acebb000 nid=0x47 runnable [0x0000000000000000]    java.lang.Thread.State: RUNNABLE

Then grep the output of strace, see a lot of memory were allocated by this thread, probably more than 2G.

C2 is memory-limited under normal circumstances, but why is there a memory consumption greater than 2G? Finally, we found that a bug in the JVM will cause memory leaks. The location of this code is the nmethod::metadata_do method of nmethod.cpp:
void nmethod::metadata_do(void f(Metadata*)) {   address low_boundary = verified_entry_point();   if (is_not_entrant()) {     low_boundary += NativeJump::instruction_size;     // %%% Note:  On SPARC we patch only a 4-byte trap, not a full NativeJump.     // (See comment above.)   }   {     // Visit all immediate references that are embedded in the instruction stream.     RelocIterator iter(this, low_boundary);     while (iter.next()) {       if (iter.type() == relocInfo::metadata_type ) {         metadata_Relocation* r = iter.metadata_reloc();         // In this metadata, we must only follow those metadatas directly embedded in         // the code.  Other metadatas (oop_index>0) are seen as part of         // the metadata section below.         assert(1 == (r->metadata_is_immediate()) +                (r->metadata_addr() >= metadata_begin() && r->metadata_addr() < metadata_end()),                ?metadata must be found in exactly one place?);         if (r->metadata_is_immediate() && r->metadata_value() != NULL) {           Metadata* md = r->metadata_value();           if (md != _method) f(md);         }       } else if (iter.type() == relocInfo::virtual_call_type) {         // Check compiledIC holders associated with this nmethod         CompiledIC *ic = CompiledIC_at(&iter);         if (ic->is_icholder_call()) {           CompiledICHolder* cichk = ic->cached_icholder();           f(cichk->holder_metadata());           f(cichk->holder_klass());         } else {           Metadata* ic_oop = ic->cached_metadata();           if (ic_oop != NULL) {             f(ic_oop);           }         }       }     }   }

Because CompiledIC is a ResourceObj, but it is not freed by ResourceMark, so when this method is called multiple times, OOM will appear.

The fix is very simple, just add ResourceMark rm; before CompiledIC *ic = CompiledIC_at(&iter);

And I found out that it has been solved on JDK12.

http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/aa3bfacc912c

Can this patch be entered into JDK8?




Thanks,

nijiaben @ PerfMa

From tobias.hartmann at oracle.com  Fri Mar 15 10:42:24 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 15 Mar 2019 11:42:24 +0100
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <tencent_141AE1667687FE427D957DF5@qq.com>
References: <tencent_7C2180971581EF2E543060E1@qq.com>
 <a17e14fa-7b28-c6b3-e1db-c757fd90e877@oracle.com>
 <tencent_141AE1667687FE427D957DF5@qq.com>
Message-ID: <d9603628-d590-6b83-922c-7f9fda9f727e@oracle.com>


On 15.03.19 11:08, ??? wrote:
> ? ? Thank you, will this patch consider backport to jdk8?

Probably a point fix is more suitable for a backport but I leave this to Coleen / the runtime team
to decide.

Best regards,
Tobias

From shade at redhat.com  Fri Mar 15 10:45:48 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Mar 2019 11:45:48 +0100
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <d9603628-d590-6b83-922c-7f9fda9f727e@oracle.com>
References: <tencent_7C2180971581EF2E543060E1@qq.com>
 <a17e14fa-7b28-c6b3-e1db-c757fd90e877@oracle.com>
 <tencent_141AE1667687FE427D957DF5@qq.com>
 <d9603628-d590-6b83-922c-7f9fda9f727e@oracle.com>
Message-ID: <9782702d-af3b-e72a-b369-ee69f9efb064@redhat.com>

On 3/15/19 11:42 AM, Tobias Hartmann wrote:
> On 15.03.19 11:08, ??? wrote:
>> ? ? Thank you, will this patch consider backport to jdk8?
> 
> Probably a point fix is more suitable for a backport but I leave this to Coleen / the runtime team
> to decide.

What a coincidence! I think my build server OOMs on tests with similar symptoms.

If there are no objections and/or subtle problems with it, I am willing to pick this up for 11u and
8u backports:

$ hg qdiff
diff -r 3086207c8650 src/hotspot/share/code/nmethod.cpp
--- a/src/hotspot/share/code/nmethod.cpp        Tue Mar 05 08:24:58 2019 -0500
+++ b/src/hotspot/share/code/nmethod.cpp        Fri Mar 15 11:39:27 2019 +0100
@@ -1538,10 +1538,11 @@
           Metadata* md = r->metadata_value();
           if (md != _method) f(md);
         }
       } else if (iter.type() == relocInfo::virtual_call_type) {
         // Check compiledIC holders associated with this nmethod
+        ResourceMark rm;
         CompiledIC *ic = CompiledIC_at(&iter);
         if (ic->is_icholder_call()) {
           CompiledICHolder* cichk = ic->cached_icholder();
           f(cichk->holder_metadata());
           f(cichk->holder_klass());


-Aleksey


From shade at redhat.com  Fri Mar 15 10:57:53 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Mar 2019 11:57:53 +0100
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
Message-ID: <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>

On 3/15/19 5:55 AM, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/

Looks good, ship it.

-Aleksey


From sgehwolf at redhat.com  Fri Mar 15 11:05:08 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 15 Mar 2019 12:05:08 +0100
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <d9603628-d590-6b83-922c-7f9fda9f727e@oracle.com>
References: <tencent_7C2180971581EF2E543060E1@qq.com>
 <a17e14fa-7b28-c6b3-e1db-c757fd90e877@oracle.com>
 <tencent_141AE1667687FE427D957DF5@qq.com>
 <d9603628-d590-6b83-922c-7f9fda9f727e@oracle.com>
Message-ID: <2c86fda2e7178fcd7e0184b061111dd2676cb975.camel@redhat.com>

On Fri, 2019-03-15 at 11:42 +0100, Tobias Hartmann wrote:
> On 15.03.19 11:08, ??? wrote:
> >     Thank you, will this patch consider backport to jdk8?
> 
> Probably a point fix is more suitable for a backport but I leave this to Coleen / the runtime team
> to decide.

FWIW, it seems to affect OpenJDK 11u and OpenJDK 8u.

Thanks,
Severin


From shade at redhat.com  Fri Mar 15 11:08:14 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Mar 2019 12:08:14 +0100
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <9782702d-af3b-e72a-b369-ee69f9efb064@redhat.com>
References: <tencent_7C2180971581EF2E543060E1@qq.com>
 <a17e14fa-7b28-c6b3-e1db-c757fd90e877@oracle.com>
 <tencent_141AE1667687FE427D957DF5@qq.com>
 <d9603628-d590-6b83-922c-7f9fda9f727e@oracle.com>
 <9782702d-af3b-e72a-b369-ee69f9efb064@redhat.com>
Message-ID: <4bfc14c4-f80c-9d5f-a036-4555dda9d016@redhat.com>

On 3/15/19 11:45 AM, Aleksey Shipilev wrote:
> On 3/15/19 11:42 AM, Tobias Hartmann wrote:
>> On 15.03.19 11:08, ??? wrote:
>>> ? ? Thank you, will this patch consider backport to jdk8?
>>
>> Probably a point fix is more suitable for a backport but I leave this to Coleen / the runtime team
>> to decide.
> 
> What a coincidence! I think my build server OOMs on tests with similar symptoms.
> 
> If there are no objections and/or subtle problems with it, I am willing to pick this up for 11u and
> 8u backports:
> 
> $ hg qdiff
> diff -r 3086207c8650 src/hotspot/share/code/nmethod.cpp
> --- a/src/hotspot/share/code/nmethod.cpp        Tue Mar 05 08:24:58 2019 -0500
> +++ b/src/hotspot/share/code/nmethod.cpp        Fri Mar 15 11:39:27 2019 +0100
> @@ -1538,10 +1538,11 @@
>            Metadata* md = r->metadata_value();
>            if (md != _method) f(md);
>          }
>        } else if (iter.type() == relocInfo::virtual_call_type) {
>          // Check compiledIC holders associated with this nmethod
> +        ResourceMark rm;
>          CompiledIC *ic = CompiledIC_at(&iter);
>          if (ic->is_icholder_call()) {
>            CompiledICHolder* cichk = ic->cached_icholder();
>            f(cichk->holder_metadata());
>            f(cichk->holder_klass());

Tracked here:
  https://bugs.openjdk.java.net/browse/JDK-8220718

-Aleksey


From matthias.baesken at sap.com  Fri Mar 15 12:17:26 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 15 Mar 2019 12:17:26 +0000
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
Message-ID: <AM6PR02MB50784E30580E9CBB27637B2893440@AM6PR02MB5078.eurprd02.prod.outlook.com>


Hello, looks  like   


nmethod::print_calls


3284    case relocInfo::opt_virtual_call_type: {
3285      VerifyMutexLocker mc(CompiledIC_lock);
3286      CompiledIC_at(&iter)->print();
3287      break;
3288    }


Misses the Resourcemark too  (although   the coding might be unused (?) )  ...

Best regards, Matthias



> Date: Fri, 15 Mar 2019 12:08:14 +0100
> From: Aleksey Shipilev <shade at redhat.com>
> To: Tobias Hartmann <tobias.hartmann at oracle.com>, ???
> 	<jiapeng.li at perfma.com>, jdk8u-dev <jdk8u-
> dev at openjdk.java.net>,
> 	hotspot-runtime-dev <hotspot-runtime-dev at openjdk.java.net>,
> 	hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>,
> Coleen
> 	Phillimore <coleen.phillimore at oracle.com>
> Subject: Re: A bug in C2 that causes a large amount of physical memory
> 	to be allocated
> Message-ID: <4bfc14c4-f80c-9d5f-a036-4555dda9d016 at redhat.com>
> Content-Type: text/plain; charset=utf-8
> 
> On 3/15/19 11:45 AM, Aleksey Shipilev wrote:
> > On 3/15/19 11:42 AM, Tobias Hartmann wrote:
> >> On 15.03.19 11:08, ??? wrote:
> >>> ? ? Thank you, will this patch consider backport to jdk8?
> >>
> >> Probably a point fix is more suitable for a backport but I leave this to
> Coleen / the runtime team
> >> to decide.
> >
> > What a coincidence! I think my build server OOMs on tests with similar
> symptoms.
> >
> > If there are no objections and/or subtle problems with it, I am willing to
> pick this up for 11u and
> > 8u backports:
> >
> > $ hg qdiff
> > diff -r 3086207c8650 src/hotspot/share/code/nmethod.cpp
> > --- a/src/hotspot/share/code/nmethod.cpp        Tue Mar 05 08:24:58 2019 -
> 0500
> > +++ b/src/hotspot/share/code/nmethod.cpp        Fri Mar 15 11:39:27 2019
> +0100
> > @@ -1538,10 +1538,11 @@
> >            Metadata* md = r->metadata_value();
> >            if (md != _method) f(md);
> >          }
> >        } else if (iter.type() == relocInfo::virtual_call_type) {
> >          // Check compiledIC holders associated with this nmethod
> > +        ResourceMark rm;
> >          CompiledIC *ic = CompiledIC_at(&iter);
> >          if (ic->is_icholder_call()) {
> >            CompiledICHolder* cichk = ic->cached_icholder();
> >            f(cichk->holder_metadata());
> >            f(cichk->holder_klass());
> 
> Tracked here:
>   https://bugs.openjdk.java.net/browse/JDK-8220718
> 
> -Aleksey


From shade at redhat.com  Fri Mar 15 12:21:31 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Mar 2019 13:21:31 +0100
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <AM6PR02MB50784E30580E9CBB27637B2893440@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB50784E30580E9CBB27637B2893440@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <ca36dba4-95a0-7f28-38e1-d7da1fd32d10@redhat.com>

On 3/15/19 1:17 PM, Baesken, Matthias wrote:
> nmethod::print_calls
> 
> 3284    case relocInfo::opt_virtual_call_type: {
> 3285      VerifyMutexLocker mc(CompiledIC_lock);
> 3286      CompiledIC_at(&iter)->print();
> 3287      break;
> 3288    }
> 
> Misses the Resourcemark too  (although   the coding might be unused (?) )  ...

This one is guarded by #ifndef PRODUCT, so not as important. Feel free to submit another RFE to
clean that up.

-Aleksey


From matthias.baesken at sap.com  Fri Mar 15 12:26:07 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 15 Mar 2019 12:26:07 +0000
Subject: A bug in C2 that causes a large amount of physical memory to be
 allocated
In-Reply-To: <ca36dba4-95a0-7f28-38e1-d7da1fd32d10@redhat.com>
References: <AM6PR02MB50784E30580E9CBB27637B2893440@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <ca36dba4-95a0-7f28-38e1-d7da1fd32d10@redhat.com>
Message-ID: <AM6PR02MB5078558D7C1110D175326B4B93440@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi, should I remove the function  nmethod::print_calls   ? It looks like the function is unused .
Or is it left over to be called   from a debugger or something like this ?

Best regards, Matthias


> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Freitag, 15. M?rz 2019 13:22
> To: Baesken, Matthias <matthias.baesken at sap.com>; jdk8u-
> dev at openjdk.java.net; Hotspot dev runtime <hotspot-runtime-
> dev at openjdk.java.net>
> Subject: Re: A bug in C2 that causes a large amount of physical memory to be
> allocated
> 
> On 3/15/19 1:17 PM, Baesken, Matthias wrote:
> > nmethod::print_calls
> >
> > 3284    case relocInfo::opt_virtual_call_type: {
> > 3285      VerifyMutexLocker mc(CompiledIC_lock);
> > 3286      CompiledIC_at(&iter)->print();
> > 3287      break;
> > 3288    }
> >
> > Misses the Resourcemark too  (although   the coding might be unused (?) )
> ...
> 
> This one is guarded by #ifndef PRODUCT, so not as important. Feel free to
> submit another RFE to
> clean that up.
> 
> -Aleksey


From andrey at azul.com  Fri Mar 15 13:44:34 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Fri, 15 Mar 2019 13:44:34 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <2B339EB1-87F2-4120-B778-81A760CC55C6@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
 <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>
Message-ID: <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@azul.com>

Hi Guangyu,

The G1 heap region type reporting looks good to me as well. Thanks a lot for doing it!

Regards,
Andrey

> On 14 Mar 2019, at 14:44, Andrey Petushkov <andrey at azul.com> wrote:
> 
> Hi Guangyu,
> 
> By the moment I've read first two patches (thread sampling and biased locks). These look good to me
> One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it
> 
> I need a bit more time to read through G1 heap region types one.
> BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please
> 
> Thanks a lot,
> Andrey
> 
>> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>> 
>> Ok. I look forward to the feedbacks from both of you.
>> 
>> Thanks,
>> Guangyu
>> ------------------------------------------------------------------
>> Sender:Mario Torre <neugens.limasoftware at gmail.com>
>> Sent At:2019 Mar. 13 (Wed.) 19:26
>> Recipient:Andrey Petushkov <andrey at azul.com>
>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
>> 
>> Thanks!
>> 
>> I?m currently traveling but I?ll offer my review as soon as I get back next week.
>> 
>> Cheers,
>> Mario
>> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
>> Hi Guangyu,
>> 
>> Cool! Thank you so much! Will review changes ASAP
>> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
>> April update release (mostly limited by testing resources capacity)
>> 
>> Regards,
>> Andrey
>> 
>>> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>>> 
>>> Hi Andrey, Mario
>>> 
>>> Is there any progress in backporting? We have completed the patch for the missing features. Please review.
>>> 
>>> - thread sampling:
>>> http://cr.openjdk.java.net/~luchsh/thread_sampling/
>>> 
>>> - biased locking events:
>>> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
>>> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
>>> 
>>> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
>>> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
>>> 
>>> Thanks,
>>> Guangyu
>>> 
>>> 
>>> ------------------------------------------------------------------
>>> Sender:Andrey Petushkov <andrey at azul.com>
>>> Sent At:2019 Mar. 6 (Wed.) 00:34
>>> Recipient:Mario Torre <neugens at redhat.com>
>>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
>>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
>>> 
>>> Hi Mario,
>>> 
>>>> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
>>>> 
>>>> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
>>>> 
>>>>>> I'm going through the patch right now, but yes, from what I see the
>>>>>> trace is removed. I had too a concern about this and was about to send
>>>>>> a note. I'm not quite sure what to do, because Trace has been removed
>>>>>> in 11 as far as I know, but removing mid stream in 8 may be a more
>>>>>> interesting issue, however this isn't a user facing API, it was always
>>>>>> meant to be internal to the JVM, so I don't quite know if there's
>>>>>> really a reason we shouldn't change it. This is one question for the
>>>>>> CSR group I think.
>>>>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
>>>>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
>>>>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
>>>>> I will be happy to return it back
>>>> 
>>>> Yes, I tend to agree with you, I do believe this is mostly an internal
>>>> API for easy of patching with the JFR code (which is almost
>>>> identical). The only concern is in the way the logging would be
>>>> triggered externally and the compile time options for it (I still see
>>>> a couple of instance where INCLUDE_TRACE is being used). As for
>>>> triggering the logs, I don't recall that 8 has any means of doing
>>>> this, I think some infrastructure came with 9 with the -Xlog option (I
>>>> didn't follow this however, I'm not sure the option ever landed in 9)?
>>>> In that case I guess it's safe to go after all.
>>> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
>>> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
>>> IMHO we should get rid of all of them, but cannot tell for sure now
>>> 
>>> Andrey
>>>> 
>>>> Cheers,
>>>> Mario
>>>> --
>>>> Mario Torre
>>>> Associate Manager, Software Engineering
>>>> Red Hat GmbH <https://www.redhat.com>
>>>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>> 
>> 
>> 
> 


From hohensee at amazon.com  Fri Mar 15 17:58:59 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 15 Mar 2019 17:58:59 +0000
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
 <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
Message-ID: <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>

+1

Paul

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

    On 3/15/19 5:55 AM, Andrew John Hughes wrote:
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
    > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
    
    Looks good, ship it.
    
    -Aleksey
    
    


From gnu.andrew at redhat.com  Fri Mar 15 18:58:00 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 15 Mar 2019 18:58:00 +0000
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
 <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
 <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>
Message-ID: <ce79090a-2f15-1a79-213e-00f2f0e466cb@redhat.com>

On 15/03/2019 17:58, Hohensee, Paul wrote:
> +1
> 
> Paul
> 
> ?On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:
> 
>     On 3/15/19 5:55 AM, Andrew John Hughes wrote:
>     > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
>     > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
>     
>     Looks good, ship it.
>     
>     -Aleksey
>     
>     
> 

Thanks, guys. Just waiting on aph to set jdk8u-fix-yes on it now.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Fri Mar 15 19:04:57 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 15 Mar 2019 19:04:57 +0000
Subject: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a build
Message-ID: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/

This one applies pretty much as-is, when adjustments are made to use the
jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in
8u. generated-configure.sh is regenerated rather than patched.

I've confirmed that a build using --with-vendor-name=$VENDOR sees
$VENDOR appear in the generated spec.gmk.
-- 
Andrew :)

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

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


From martinrb at google.com  Fri Mar 15 19:19:47 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 15 Mar 2019 12:19:47 -0700
Subject: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a
 build
In-Reply-To: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
References: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
Message-ID: <CA+kOe0_QmnGeLP=OQu7CWR26JyH0iLBNGNdUg4me4RinH94cUA@mail.gmail.com>

Looks good to me.

On Fri, Mar 15, 2019 at 12:05 PM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/
>
> This one applies pretty much as-is, when adjustments are made to use the
> jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in
> 8u. generated-configure.sh is regenerated rather than patched.
>
> I've confirmed that a build using --with-vendor-name=$VENDOR sees
> $VENDOR appear in the generated spec.gmk.
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>
>

From christoph.langer at sap.com  Fri Mar 15 21:23:07 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Mar 2019 21:23:07 +0000
Subject: [jdk8u, jdk11u] Process update: Patch approval process for fixes
 after RDP2
Message-ID: <DB6PR0201MB2263C5B791E18C6A93B427958A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>

Hi,

as discussed on the mailing list [0], we have updated our process for critical fixes that should go into the OpenJDK update release that is stabilized in jdk8u/jdk11u after RDP2 (such as 11.0.3 at the moment and 8u212 in a few days).

If a fix shall be brought to jdk8u/jdk11u directly, please use the labels jdk8u-critical-request/jdk11u-critical-request. The maintainer will then set jdk8u-critical-yes/jdk11u-critical-yes if the fix request is approved or jdk8u-critical-no/jdk11u-critical-no otherwise.

I?ve updated the Wiki page for the jdk11u updates project [1] accordingly and will do this for jdk8u next week, too.

As always, feedback is welcome ??

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-March/000777.html
[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u


From christoph.langer at sap.com  Fri Mar 15 21:32:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Mar 2019 21:32:53 +0000
Subject: JDK8u212 next steps
Message-ID: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>

Hi,

we have reached a state where the list of required jdk8u backport items [0] is in jdk8u-dev. Thanks to all contributors for their hard work!

When there are no objections, I'll do the push to jdk8u on Monday. In detail this will mean the following steps:
1. merge the repos jdk8u-dev -> jdk8u
2. tag jdk8u with "jdk8u212-b01"
3. tag jdk8u-dev  with "jdk8u222-b00"
4. merge "jdk8u212-b01" back into to jdk8u-dev
5. request ops on behalf of the project lead to create version "openjdk8u222" in JBS and set up hgupdater to honor this version for pushes to jdk8u-dev

I'll communicate when this work is finished. After that, jdk8u-dev will collect fixes for OpenJDK 8u222 and critical fixes can be requested to be pushed to jdk8u for 8u212 using the jdk8u-critical-request label.

Best regards
Christoph

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


From guangyu.zhu at aliyun.com  Mon Mar 18 01:18:11 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Mon, 18 Mar 2019 09:18:11 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
 <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>,
 <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@azul.com>
Message-ID: <dccc6efb-5372-442f-9cf5-66a3a1df9ef4.guangyu.zhu@aliyun.com>

ok, we will update the patch based on your comments.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Mar. 15 (Fri.) 21:44
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Hi Guangyu,

The G1 heap region type reporting looks good to me as well. Thanks a lot for doing it!

Regards,
Andrey

> On 14 Mar 2019, at 14:44, Andrey Petushkov <andrey at azul.com> wrote:
> 
> Hi Guangyu,
> 
> By the moment I've read first two patches (thread sampling and biased locks). These look good to me
> One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it
> 
> I need a bit more time to read through G1 heap region types one.
> BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please
> 
> Thanks a lot,
> Andrey
> 
>> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>> 
>> Ok. I look forward to the feedbacks from both of you.
>> 
>> Thanks,
>> Guangyu
>> ------------------------------------------------------------------
>> Sender:Mario Torre <neugens.limasoftware at gmail.com>
>> Sent At:2019 Mar. 13 (Wed.) 19:26
>> Recipient:Andrey Petushkov <andrey at azul.com>
>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
>> 
>> Thanks!
>> 
>> I?m currently traveling but I?ll offer my review as soon as I get back next week.
>> 
>> Cheers,
>> Mario
>> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
>> Hi Guangyu,
>> 
>> Cool! Thank you so much! Will review changes ASAP
>> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
>> April update release (mostly limited by testing resources capacity)
>> 
>> Regards,
>> Andrey
>> 
>>> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>>> 
>>> Hi Andrey, Mario
>>> 
>>> Is there any progress in backporting? We have completed the patch for the missing features. Please review.
>>> 
>>> - thread sampling:
>>> http://cr.openjdk.java.net/~luchsh/thread_sampling/
>>> 
>>> - biased locking events:
>>> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
>>> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
>>> 
>>> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
>>> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
>>> 
>>> Thanks,
>>> Guangyu
>>> 
>>> 
>>> ------------------------------------------------------------------
>>> Sender:Andrey Petushkov <andrey at azul.com>
>>> Sent At:2019 Mar. 6 (Wed.) 00:34
>>> Recipient:Mario Torre <neugens at redhat.com>
>>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
>>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
>>> 
>>> Hi Mario,
>>> 
>>>> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
>>>> 
>>>> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
>>>> 
>>>>>> I'm going through the patch right now, but yes, from what I see the
>>>>>> trace is removed. I had too a concern about this and was about to send
>>>>>> a note. I'm not quite sure what to do, because Trace has been removed
>>>>>> in 11 as far as I know, but removing mid stream in 8 may be a more
>>>>>> interesting issue, however this isn't a user facing API, it was always
>>>>>> meant to be internal to the JVM, so I don't quite know if there's
>>>>>> really a reason we shouldn't change it. This is one question for the
>>>>>> CSR group I think.
>>>>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
>>>>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
>>>>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
>>>>> I will be happy to return it back
>>>> 
>>>> Yes, I tend to agree with you, I do believe this is mostly an internal
>>>> API for easy of patching with the JFR code (which is almost
>>>> identical). The only concern is in the way the logging would be
>>>> triggered externally and the compile time options for it (I still see
>>>> a couple of instance where INCLUDE_TRACE is being used). As for
>>>> triggering the logs, I don't recall that 8 has any means of doing
>>>> this, I think some infrastructure came with 9 with the -Xlog option (I
>>>> didn't follow this however, I'm not sure the option ever landed in 9)?
>>>> In that case I guess it's safe to go after all.
>>> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
>>> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
>>> IMHO we should get rid of all of them, but cannot tell for sure now
>>> 
>>> Andrey
>>>> 
>>>> 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  Mon Mar 18 08:47:18 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Mar 2019 08:47:18 +0000
Subject: JDK8u212 next steps
In-Reply-To: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
Message-ID: <39f77831-9ea9-9675-a869-1b5d89e91c64@redhat.com>

On 3/15/19 9:32 PM, Langer, Christoph wrote:
> When there are no objections, I'll do the push to jdk8u on Monday. In detail this will mean the following steps:
> 1. merge the repos jdk8u-dev -> jdk8u
> 2. tag jdk8u with "jdk8u212-b01"
> 3. tag jdk8u-dev  with "jdk8u222-b00"
> 4. merge "jdk8u212-b01" back into to jdk8u-dev

That sounds right. Please let me know when this is done.

> 5. request ops on behalf of the project lead to create version "openjdk8u222" in JBS and set up hgupdater to honor this version for pushes to jdk8u-dev

I have to do 5.

-- 
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 Mar 18 08:58:05 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Mar 2019 08:58:05 +0000
Subject: JDK8u212 next steps
In-Reply-To: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

I've transported the changes for OpenJDK 8u212 to the jdk8u repository forest, as per the steps below. The request for a new JBS release "openjdk8u222" was sent to ops.

As of now, changes that are targeted for jdk8u212 need to be pushed to jdk8u. Those must, of course, have been labeled with "jdk8u-critical-request" and approved beforehand. I've set  "jdk8u-critical-request" on bugs JDK-8220641, JDK-8193764 and JDK-8189761 as I assume they shall go into jdk8u. Please correct it in JBS if my assumption is wrong.

Approvals & pushes for openjdk8u222 will have to wait until the new setup for jdk8u-dev is in place. I'll send an update once this is available.

Best regards
Christoph


From: Langer, Christoph
Sent: Freitag, 15. M?rz 2019 22:33
To: jdk8u-dev at openjdk.java.net
Subject: JDK8u212 next steps

Hi,

we have reached a state where the list of required jdk8u backport items [0] is in jdk8u-dev. Thanks to all contributors for their hard work!

When there are no objections, I'll do the push to jdk8u on Monday. In detail this will mean the following steps:
1. merge the repos jdk8u-dev -> jdk8u
2. tag jdk8u with "jdk8u212-b01"
3. tag jdk8u-dev  with "jdk8u222-b00"
4. merge "jdk8u212-b01" back into to jdk8u-dev
5. request ops on behalf of the project lead to create version "openjdk8u222" in JBS and set up hgupdater to honor this version for pushes to jdk8u-dev

I'll communicate when this work is finished. After that, jdk8u-dev will collect fixes for OpenJDK 8u222 and critical fixes can be requested to be pushed to jdk8u for 8u212 using the jdk8u-critical-request label.

Best regards
Christoph

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


From christoph.langer at sap.com  Mon Mar 18 08:59:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Mar 2019 08:59:46 +0000
Subject: JDK8u212 next steps
In-Reply-To: <39f77831-9ea9-9675-a869-1b5d89e91c64@redhat.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <39f77831-9ea9-9675-a869-1b5d89e91c64@redhat.com>
Message-ID: <HE1PR0201MB2266BD15FE8ECA9B2B572E548A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew

> On 3/15/19 9:32 PM, Langer, Christoph wrote:
> > When there are no objections, I'll do the push to jdk8u on Monday. In
> detail this will mean the following steps:
> > 1. merge the repos jdk8u-dev -> jdk8u
> > 2. tag jdk8u with "jdk8u212-b01"
> > 3. tag jdk8u-dev  with "jdk8u222-b00"
> > 4. merge "jdk8u212-b01" back into to jdk8u-dev
> 
> That sounds right. Please let me know when this is done.

Done, see the other mail.

> > 5. request ops on behalf of the project lead to create version
> "openjdk8u222" in JBS and set up hgupdater to honor this version for pushes
> to jdk8u-dev
> 
> I have to do 5.

I had already sent a mail to ops with you on copy. Maybe you want to affirm my request that there are no doubts for ops?

Thanks
Christoph


From christoph.langer at sap.com  Mon Mar 18 09:24:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Mar 2019 09:24:21 +0000
Subject: [jdk8u, jdk11u] Process update: Patch approval process for fixes
 after RDP2
In-Reply-To: <DB6PR0201MB2263C5B791E18C6A93B427958A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
References: <DB6PR0201MB2263C5B791E18C6A93B427958A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0201MB22669E7B62E3B60524FDF0018A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>

FYI: The Wiki page for jdk8 updates now also mentions the new RDP2 process. It needs to be applied for fixes targeting 8u212 as of now.

From: Langer, Christoph
Sent: Freitag, 15. M?rz 2019 22:23
To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
Cc: Andrew Haley <aph at redhat.com>
Subject: [jdk8u, jdk11u] Process update: Patch approval process for fixes after RDP2

Hi,

as discussed on the mailing list [0], we have updated our process for critical fixes that should go into the OpenJDK update release that is stabilized in jdk8u/jdk11u after RDP2 (such as 11.0.3 at the moment and 8u212 in a few days).

If a fix shall be brought to jdk8u/jdk11u directly, please use the labels jdk8u-critical-request/jdk11u-critical-request. The maintainer will then set jdk8u-critical-yes/jdk11u-critical-yes if the fix request is approved or jdk8u-critical-no/jdk11u-critical-no otherwise.

I?ve updated the Wiki page for the jdk11u updates project [1] accordingly and will do this for jdk8u next week, too.

As always, feedback is welcome ??

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-March/000777.html
[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u


From sgehwolf at redhat.com  Mon Mar 18 09:33:42 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 18 Mar 2019 10:33:42 +0100
Subject: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a
 build
In-Reply-To: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
References: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
Message-ID: <6084395085be99e6d8a1afc6e6660069ab1177bf.camel@redhat.com>

On Fri, 2019-03-15 at 19:04 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/
> 
> This one applies pretty much as-is, when adjustments are made to use the
> jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in
> 8u. generated-configure.sh is regenerated rather than patched.
> 
> I've confirmed that a build using --with-vendor-name=$VENDOR sees
> $VENDOR appear in the generated spec.gmk.

Looks good to me. I'm not a Reviewer, though.

Thanks,
Severin


From aph at redhat.com  Mon Mar 18 15:44:51 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Mar 2019 15:44:51 +0000
Subject: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a
 build
In-Reply-To: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
References: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
Message-ID: <411fd398-e455-85fd-cda8-3277918d3a24@redhat.com>

On 3/15/19 7:04 PM, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/
> 
> This one applies pretty much as-is, when adjustments are made to use the
> jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in
> 8u. generated-configure.sh is regenerated rather than patched.
> 
> I've confirmed that a build using --with-vendor-name=$VENDOR sees
> $VENDOR appear in the generated spec.gmk.

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 erik.joelsson at oracle.com  Mon Mar 18 16:31:01 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 18 Mar 2019 09:31:01 -0700
Subject: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a
 build
In-Reply-To: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
References: <cb4e5f22-a025-1001-0a82-a32deed4498f@redhat.com>
Message-ID: <2233b6c9-5dd7-f6b8-78d9-0c9376d39afd@oracle.com>

Looks good.

/Erik

On 2019-03-15 12:04, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/
>
> This one applies pretty much as-is, when adjustments are made to use the
> jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in
> 8u. generated-configure.sh is regenerated rather than patched.
>
> I've confirmed that a build using --with-vendor-name=$VENDOR sees
> $VENDOR appear in the generated spec.gmk.

From fujie at loongson.cn  Tue Mar 19 12:25:51 2019
From: fujie at loongson.cn (Jie Fu)
Date: Tue, 19 Mar 2019 20:25:51 +0800
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to deprecated-declarations
 warnings
Message-ID: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>

Hi all,

To fix build failures caused by deprecated-declarations warnings, can we 
make this change to jdk8u?
------------------------------------------
diff -r 6e2900603bc6 make/linux/makefiles/gcc.make
--- a/make/linux/makefiles/gcc.make???? Mon Mar 18 08:33:53 2019 +0100
+++ b/make/linux/makefiles/gcc.make???? Tue Mar 19 20:20:17 2019 +0800
@@ -209,6 +209,8 @@
 ?? WARNINGS_ARE_ERRORS += -Wno-switch 
-Wno-tautological-constant-out-of-range-compare -Wno-tautological-compare
 ?? WARNINGS_ARE_ERRORS += -Wno-delete-non-virtual-dtor -Wno-deprecated 
-Wno-format -Wno-dynamic-class-memaccess
 ?? WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body
+else
+? WARNINGS_ARE_ERRORS += -Wno-deprecated-declarations
 ?endif

 ?WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef 
-Wunused-function -Wunused-value
------------------------------------------

Thanks a lot.

Best regards,
Jie



From aph at redhat.com  Tue Mar 19 14:45:48 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 19 Mar 2019 14:45:48 +0000
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
Message-ID: <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>

On 3/19/19 12:25 PM, Jie Fu wrote:
> To fix build failures caused by deprecated-declarations warnings, can we 
> make this change to jdk8u?

This is very GCC-version dependent. We really should probe at configure time for
these options.

-- 
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 martinrb at google.com  Tue Mar 19 15:09:13 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 19 Mar 2019 08:09:13 -0700
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
Message-ID: <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>

Probably it's because glibc deprecated readdir, and we don't have
--disable-warnings-as-errors by default?

(I think warnings should not be errors except as opt-in by openjdk
developers/maintainers)

On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley <aph at redhat.com> wrote:

> On 3/19/19 12:25 PM, Jie Fu wrote:
> > To fix build failures caused by deprecated-declarations warnings, can we
> > make this change to jdk8u?
>
> This is very GCC-version dependent. We really should probe at configure
> time for
> these options.
>
> --
> 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 brian.burkhalter at oracle.com  Tue Mar 19 15:15:12 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 19 Mar 2019 08:15:12 -0700
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
 <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
Message-ID: <2F5443E0-A169-4C31-8D1A-0BFA82600382@oracle.com>

jdk8u-dev will build with this conf

bash configure --with-extra-cflags=-Wno-error

at least on Ubuntu 18.04.

> On Mar 19, 2019, at 8:09 AM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Probably it's because glibc deprecated readdir, and we don't have
> --disable-warnings-as-errors by default?
> 
> (I think warnings should not be errors except as opt-in by openjdk
> developers/maintainers)
> 
> On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley <aph at redhat.com> wrote:
> 
>> On 3/19/19 12:25 PM, Jie Fu wrote:
>>> To fix build failures caused by deprecated-declarations warnings, can we
>>> make this change to jdk8u?
>> 
>> This is very GCC-version dependent. We really should probe at configure
>> time for
>> these options.
>> 
>> --
>> 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 Mar 19 17:18:44 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 19 Mar 2019 17:18:44 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <dccc6efb-5372-442f-9cf5-66a3a1df9ef4.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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
 <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>
 <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@azul.com>
 <dccc6efb-5372-442f-9cf5-66a3a1df9ef4.guangyu.zhu@aliyun.com>
Message-ID: <9114E7B2-1EC7-4095-A19D-4D1ED7F46879@azul.com>

Hi Guangyu,

We have found that your thread sampling implementation causes VM crashes. E.g. test jdk/jfr/cmd/TestPrintDefault could be used to
reproduce it (we've found 29 JFR tests in total which exhibit this problem).
On debug build this manifests as:

#  Internal Error (/home/andrey/ws/zulu8-emb-dev/hotspot/src/share/vm/runtime/thread.hpp:1789), pid=25987, tid=0x00007fffc0be1700
#  assert(thread != NULL && thread->is_Java_thread()) failed: just checking

with thread list like this:

Java Threads: ( => current thread )
  0x00007fff8c001800 JavaThread "JFR Recording Scheduler" daemon [_thread_blocked, id=26020, stack(0x00007fffc09e0000,0x00007fffc0ae1000)]
  0x00007fff942f0000 JavaThread "JFR Periodic Tasks" daemon [_thread_blocked, id=26018, stack(0x00007fffc0be2000,0x00007fffc0ce3000)]
  0x00007fff9420f800 JavaThread "JFR Recorder Thread" daemon [_thread_blocked, id=26017, stack(0x00007fffc0f4b000,0x00007fffc104c000)]
  0x00007ffff0205800 JavaThread "MainThread" [_thread_in_Java, id=26013, stack(0x00007fffc229a000,0x00007fffc239b000)]
  0x00007ffff0190800 JavaThread "Service Thread" daemon [_thread_blocked, id=26011, stack(0x00007fffc255b000,0x00007fffc265c000)]
  0x00007ffff017c000 JavaThread "C1 CompilerThread2" daemon [_thread_in_native, id=26010, stack(0x00007fffc265c000,0x00007fffc275d000)]
  0x00007ffff017a000 JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26009, stack(0x00007fffc275d000,0x00007fffc285e000)]
  0x00007ffff0176800 JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=26008, stack(0x00007fffc285e000,0x00007fffc295f000)]
  0x00007ffff0173000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=26007, stack(0x00007fffc295f000,0x00007fffc2a60000)]
  0x00007ffff0122800 JavaThread "Finalizer" daemon [_thread_blocked, id=26006, stack(0x00007fffc2d38000,0x00007fffc2e39000)]
  0x00007ffff011d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=26005, stack(0x00007fffc2e39000,0x00007fffc2f3a000)]
  0x00007ffff000f800 JavaThread "main" [_thread_blocked, id=25997, stack(0x00007ffff7eda000,0x00007ffff7fdb000)]

Other Threads:
  0x00007ffff010e000 VMThread [stack: 0x00007fffc2f3a000,0x00007fffc303b000] [id=26004]
  0x00007ffff018e000 WatcherThread [stack: 0x00007fffc245a000,0x00007fffc255b000] [id=26012]

=>0x00007fff942e5000 (exited) Thread [stack: 0x00007fffc0ae1000,0x00007fffc0be2000] [id=26021]

Looks like if thread exits during JFR thread sampling the latter still tries to traverse it. Which is, well, not something to be done on that stage
Would you be able to check the issue, please?

Thank you,
Andrey

> On 18 Mar 2019, at 04:18, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> ok, we will update the patch based on your comments.
> 
> Thanks,
> Guangyu
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Mar. 15 (Fri.) 21:44
> Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Guangyu,
> 
> The G1 heap region type reporting looks good to me as well. Thanks a lot for doing it!
> 
> Regards,
> Andrey
> 
> > On 14 Mar 2019, at 14:44, Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Hi Guangyu,
> >
> > By the moment I've read first two patches (thread sampling and biased locks). These look good to me
> > One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it
> >
> > I need a bit more time to read through G1 heap region types one.
> > BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please
> >
> > Thanks a lot,
> > Andrey
> >
> >> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >>
> >> Ok. I look forward to the feedbacks from both of you.
> >>
> >> Thanks,
> >> Guangyu
> >> ------------------------------------------------------------------
> >> Sender:Mario Torre <neugens.limasoftware at gmail.com>
> >> Sent At:2019 Mar. 13 (Wed.) 19:26
> >> Recipient:Andrey Petushkov <andrey at azul.com>
> >> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> >> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >>
> >> Thanks!
> >>
> >> I?m currently traveling but I?ll offer my review as soon as I get back next week.
> >>
> >> Cheers,
> >> Mario
> >> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
> >> Hi Guangyu,
> >>
> >> Cool! Thank you so much! Will review changes ASAP
> >> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
> >> April update release (mostly limited by testing resources capacity)
> >>
> >> Regards,
> >> Andrey
> >>
> >>> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >>>
> >>> Hi Andrey, Mario
> >>>
> >>> Is there any progress in backporting? We have completed the patch for the missing features. Please review.
> >>>
> >>> - thread sampling:
> >>> http://cr.openjdk.java.net/~luchsh/thread_sampling/
> >>>
> >>> - biased locking events:
> >>> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> >>> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> >>>
> >>> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
> >>> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> >>>
> >>> Thanks,
> >>> Guangyu
> >>>
> >>>
> >>> ------------------------------------------------------------------
> >>> Sender:Andrey Petushkov <andrey at azul.com>
> >>> Sent At:2019 Mar. 6 (Wed.) 00:34
> >>> Recipient:Mario Torre <neugens at redhat.com>
> >>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> >>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >>>
> >>> Hi Mario,
> >>>
> >>>> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> >>>>
> >>>> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> >>>>
> >>>>>> I'm going through the patch right now, but yes, from what I see the
> >>>>>> trace is removed. I had too a concern about this and was about to send
> >>>>>> a note. I'm not quite sure what to do, because Trace has been removed
> >>>>>> in 11 as far as I know, but removing mid stream in 8 may be a more
> >>>>>> interesting issue, however this isn't a user facing API, it was always
> >>>>>> meant to be internal to the JVM, so I don't quite know if there's
> >>>>>> really a reason we shouldn't change it. This is one question for the
> >>>>>> CSR group I think.
> >>>>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> >>>>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> >>>>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> >>>>> I will be happy to return it back
> >>>>
> >>>> Yes, I tend to agree with you, I do believe this is mostly an internal
> >>>> API for easy of patching with the JFR code (which is almost
> >>>> identical). The only concern is in the way the logging would be
> >>>> triggered externally and the compile time options for it (I still see
> >>>> a couple of instance where INCLUDE_TRACE is being used). As for
> >>>> triggering the logs, I don't recall that 8 has any means of doing
> >>>> this, I think some infrastructure came with 9 with the -Xlog option (I
> >>>> didn't follow this however, I'm not sure the option ever landed in 9)?
> >>>> In that case I guess it's safe to go after all.
> >>> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
> >>> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
> >>> IMHO we should get rid of all of them, but cannot tell for sure now
> >>>
> >>> Andrey
> >>>>
> >>>> 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  Tue Mar 19 18:11:47 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 19 Mar 2019 18:11:47 +0000
Subject: JDK8u212 next steps
In-Reply-To: <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <e694dc60-4c5f-d9aa-3e57-b147ec4bbbc6@redhat.com>



On 18/03/2019 08:58, Langer, Christoph wrote:
> Hi,
> 
> I've transported the changes for OpenJDK 8u212 to the jdk8u repository forest, as per the steps below. The request for a new JBS release "openjdk8u222" was sent to ops.
> 
> As of now, changes that are targeted for jdk8u212 need to be pushed to jdk8u. Those must, of course, have been labeled with "jdk8u-critical-request" and approved beforehand. I've set  "jdk8u-critical-request" on bugs JDK-8220641, JDK-8193764 and JDK-8189761 as I assume they shall go into jdk8u. Please correct it in JBS if my assumption is wrong.
> 

Why was this forked before these changes were pushed in the first place?
We'd already agreed they would go in first.

> 
> When there are no objections, I'll do the push to jdk8u on Monday. In detail this will mean the following steps:

When exactly do you expect such objections, given you didn't send this
until 21:32 on Friday evening?
-- 
Andrew :)

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

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


From christoph.langer at sap.com  Tue Mar 19 19:25:28 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Mar 2019 19:25:28 +0000
Subject: JDK8u212 next steps
In-Reply-To: <e694dc60-4c5f-d9aa-3e57-b147ec4bbbc6@redhat.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e694dc60-4c5f-d9aa-3e57-b147ec4bbbc6@redhat.com>
Message-ID: <HE1PR0201MB22662A615BA3CD0F4D8A33E08A400@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> On 18/03/2019 08:58, Langer, Christoph wrote:
> > Hi,
> >
> > I've transported the changes for OpenJDK 8u212 to the jdk8u repository
> forest, as per the steps below. The request for a new JBS release
> "openjdk8u222" was sent to ops.
> >
> > As of now, changes that are targeted for jdk8u212 need to be pushed to
> jdk8u. Those must, of course, have been labeled with "jdk8u-critical-
> request" and approved beforehand. I've set  "jdk8u-critical-request" on bugs
> JDK-8220641, JDK-8193764 and JDK-8189761 as I assume they shall go into
> jdk8u. Please correct it in JBS if my assumption is wrong.
> >
> 
> Why was this forked before these changes were pushed in the first place?
> We'd already agreed they would go in first.

Yes, we agreed they should go in. But you also said "... until we find it's taking too long". However, I have to admit, I was maybe a bit too eager here.

> >
> > When there are no objections, I'll do the push to jdk8u on Monday. In
> detail this will mean the following steps:
> 
> When exactly do you expect such objections, given you didn't send this
> until 21:32 on Friday evening?

Hm, you are probably right. I should have let passed a working day at least for such objections.

So, after all, I should say sorry here. I guess I learned a lesson for the next round...

Best regards
Christoph


From xxinliu at amazon.com  Tue Mar 19 21:48:19 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Tue, 19 Mar 2019 21:48:19 +0000
Subject: Shall we tag 212 for openjfx? 
Message-ID: <541DC109-BA76-4716-B418-0869EB60BFB8@amazon.com>

Hi, Community,

A JDK8u distribution need to include OpenJFX, but I found that the openjfx-8u repo doesn?t have a tag corresponding to 212.
https://hg.openjdk.java.net/openjfx/8u-dev/rt/tags
https://hg.openjdk.java.net/openjfx/8u/rt/tags

Is it intentional? If we don?t have any change of JFX into 212 release, shall we tag it or just fall back to use 8u202-ga?

Thanks,
--lx


From kevin.rushforth at oracle.com  Tue Mar 19 23:05:48 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 19 Mar 2019 16:05:48 -0700
Subject: Shall we tag 212 for openjfx?
In-Reply-To: <541DC109-BA76-4716-B418-0869EB60BFB8@amazon.com>
References: <541DC109-BA76-4716-B418-0869EB60BFB8@amazon.com>
Message-ID: <d8139996-84f4-cf4b-a00c-e4ce7205263c@oracle.com>

OpenJFX is a separate Project in OpenJDK. The openjfx/8u code line 
currently has no maintainer. Unless and until a suitable maintainer 
steps forward, there is no point in tagging it (and without a 
maintainer, no one with any standing to do so). See this message [1] 
sent to the openjfx-dev mailing list.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-January/023039.html


On 3/19/2019 2:48 PM, Liu, Xin wrote:
> Hi, Community,
>
> A JDK8u distribution need to include OpenJFX, but I found that the openjfx-8u repo doesn?t have a tag corresponding to 212.
> https://hg.openjdk.java.net/openjfx/8u-dev/rt/tags
> https://hg.openjdk.java.net/openjfx/8u/rt/tags
>
> Is it intentional? If we don?t have any change of JFX into 212 release, shall we tag it or just fall back to use 8u202-ga?
>
> Thanks,
> --lx
>


From xxinliu at amazon.com  Wed Mar 20 00:55:45 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 20 Mar 2019 00:55:45 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source tree
Message-ID: <8B3DEE95-2003-4AFF-95F9-EEF1B09A36DC@amazon.com>

Hi, Dmitry,
For your backport,  I think jdk8u also need to backport this one.
https://bugs.openjdk.java.net/browse/JDK-8192854

If users specify ?with-fontconfig, buildscript is supposed to use ?FONTCONFIG_CFLAGS? to discover the header file fontconfig/fontconfig.h.  If you ignore FONTCONFIG_CFLAGS,  it will fall back to pick up from /usr/include. It?s fine by almost Linux distros.  We(Amazon) put 3rd libraries in non-standard location.  That why we have this problem.

webrev for backport JDK-8192854
https://cr.openjdk.java.net/~xliu/8192854/webrev/

thanks,
--lx




From gnu.andrew at redhat.com  Wed Mar 20 01:18:29 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 20 Mar 2019 01:18:29 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source
 tree
In-Reply-To: <8B3DEE95-2003-4AFF-95F9-EEF1B09A36DC@amazon.com>
References: <8B3DEE95-2003-4AFF-95F9-EEF1B09A36DC@amazon.com>
Message-ID: <c6347fea-807a-0619-2d09-79608554e056@redhat.com>

On 20/03/2019 00:55, Liu, Xin wrote:
> Hi, Dmitry,
> For your backport,  I think jdk8u also need to backport this one.
> https://bugs.openjdk.java.net/browse/JDK-8192854
> 
> If users specify ?with-fontconfig, buildscript is supposed to use ?FONTCONFIG_CFLAGS? to discover the header file fontconfig/fontconfig.h.  If you ignore FONTCONFIG_CFLAGS,  it will fall back to pick up from /usr/include. It?s fine by almost Linux distros.  We(Amazon) put 3rd libraries in non-standard location.  That why we have this problem.
> 
> webrev for backport JDK-8192854
> https://cr.openjdk.java.net/~xliu/8192854/webrev/
> 
> thanks,
> --lx
> 
> 
> 

This looks fine to me. You should flag the bug with jdk8u-fix-request to
get it into 8u222.

If you want it in 8u212, which has branched, use jdk8u-critical-request
instead.
-- 
Andrew :)

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

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


From fujie at loongson.cn  Wed Mar 20 03:40:11 2019
From: fujie at loongson.cn (Jie Fu)
Date: Wed, 20 Mar 2019 11:40:11 +0800
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
 <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
Message-ID: <7b528e8a-61a3-9d43-c9bd-ce42037ef989@loongson.cn>

On 2019/3/19 ??11:09, Martin Buchholz wrote:

> Probably it's because glibc deprecated readdir, and we don't have 
> --disable-warnings-as-errors by default?
Yes.
>
> (I think warnings should not be errors except as opt-in by openjdk 
> developers/maintainers)
>
I agree, especially for deprecated-declarations warnings.
> On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley <aph at redhat.com 
> <mailto:aph at redhat.com>> wrote:
>
>     On 3/19/19 12:25 PM, Jie Fu wrote:
>     > To fix build failures caused by deprecated-declarations
>     warnings, can we
>     > make this change to jdk8u?
>
>     This is very GCC-version dependent. We really should probe at
>     configure time for
>     these options.
>
>     -- 
>     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 fujie at loongson.cn  Wed Mar 20 04:09:44 2019
From: fujie at loongson.cn (Jie Fu)
Date: Wed, 20 Mar 2019 12:09:44 +0800
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <1f171de2-b237-030c-c15f-6b6ac76a02d3@redhat.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
 <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
 <1f171de2-b237-030c-c15f-6b6ac76a02d3@redhat.com>
Message-ID: <3625808e-1e59-3069-afbf-f5845456583f@loongson.cn>

Hi all,

Unless a runtime failure is triggered, I think the simplest way to fix 
this issue is to change the build system since deprecated-declarations 
warnings are not errors at all.

deprecated-declarations warnings seem to be treated as errors only for 
hotspot build.
But why not for jdk build?
There are also deprecated-declarations warnings when building jdk:
------------------------------------------------------------------------
jdk8u/jdk/src/solaris/native/java/util/TimeZone_md.c:136:5: warning: 
?readdir64_r? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/java/io/UnixFileSystem_md.c:310:5: warning: 
?readdir64_r? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:693:5: 
warning: ?readdir64_r? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/management/OperatingSystemImpl.c:83:5: 
warning: ?readdir_r? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:836:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:836:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:840:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:841:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:842:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:843:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:858:13: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:861:13: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:868:13: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XWindow.c:871:13: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XlibWrapper.c:1289:9: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
jdk8u/jdk/src/solaris/native/sun/xawt/XlibWrapper.c:1923:5: warning: 
?XKeycodeToKeysym? is deprecated [-Wdeprecated-declarations]
------------------------------------------------------------------------

It seems unfair to accept deprecated-declarations warnings in jdk build 
but not in hotspot build.

Best regards,
Jie


On 2019/3/20 ??2:06, Andrew John Hughes wrote:
> On 19/03/2019 15:09, Martin Buchholz wrote:
>> Probably it's because glibc deprecated readdir, and we don't have
>> --disable-warnings-as-errors by default?
>>
>> (I think warnings should not be errors except as opt-in by openjdk
>> developers/maintainers)
>>
>> On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 3/19/19 12:25 PM, Jie Fu wrote:
>>>> To fix build failures caused by deprecated-declarations warnings, can we
>>>> make this change to jdk8u?
>>> This is very GCC-version dependent. We really should probe at configure
>>> time for
>>> these options.
>>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>
> If this is because of readdir_r, then that's on my radar to backport
> once we've branched for 8u212 (it needs time to soak, so I'm aiming for
> 8u222). I've prefer we fixed this rather than disabling warnings
> unnecessarily.


From christoph.langer at sap.com  Wed Mar 20 08:23:04 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 08:23:04 +0000
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <ce79090a-2f15-1a79-213e-00f2f0e466cb@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
 <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
 <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>
 <ce79090a-2f15-1a79-213e-00f2f0e466cb@redhat.com>
Message-ID: <HE1PR0201MB2266051B84FFECE252DA9A9A8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

can you approve this for jdk8u-critical, as it should got to jdk8u212?
https://bugs.openjdk.java.net/issues/?filter=36564

Thanks
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Andrew John Hughes
> Sent: Freitag, 15. M?rz 2019 19:58
> To: Hohensee, Paul <hohensee at amazon.com>; Aleksey Shipilev
> <shade at redhat.com>; 'jdk8u-dev at openjdk.java.net' <jdk8u-
> dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net>
> Subject: Re: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-
> 8164656 needs same change as JDK-8190690
> 
> On 15/03/2019 17:58, Hohensee, Paul wrote:
> > +1
> >
> > Paul
> >
> > ?On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-
> dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:
> >
> >     On 3/15/19 5:55 AM, Andrew John Hughes wrote:
> >     > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
> >     > Webrev:
> https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
> >
> >     Looks good, ship it.
> >
> >     -Aleksey
> >
> >
> >
> 
> Thanks, guys. Just waiting on aph to set jdk8u-fix-yes on it now.
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew


From shade at redhat.com  Wed Mar 20 10:15:54 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 20 Mar 2019 11:15:54 +0100
Subject: JDK8u212 next steps
In-Reply-To: <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>

Hi,

On 3/18/19 9:58 AM, Langer, Christoph wrote:
> Approvals & pushes for openjdk8u222 will have to wait until the new setup for jdk8u-dev is in
> place. I'll send an update once this is available.

How's the progress on this? I have lots of things to push to jdk8u-dev :)

-Aleksey



From christoph.langer at sap.com  Wed Mar 20 10:29:56 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 10:29:56 +0000
Subject: JDK8u212 next steps
In-Reply-To: <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
Message-ID: <HE1PR0201MB2266CCE6A8254E3BD77AA8D78A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Aleksey,

good question. In JBS we have openjdk8u222 now. But I didn't get a confirmation mail, whether hgupdater for jdk8u-dev repositories has been updated. I have send a mail to ops this morning, requesting this confirmation.

On the other hand, I guess, you can test it yourself by pushing one of your changes and then see how the backport issue will look like. If it's openjdk8u222, all is fine and you can push your batch. If not, we can repair the one backport issue manually and we continue to wait... What do you think?

Best regards
Christoph

> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Mittwoch, 20. M?rz 2019 11:16
> To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
> dev at openjdk.java.net
> Subject: Re: JDK8u212 next steps
> 
> Hi,
> 
> On 3/18/19 9:58 AM, Langer, Christoph wrote:
> > Approvals & pushes for openjdk8u222 will have to wait until the new setup
> for jdk8u-dev is in
> > place. I'll send an update once this is available.
> 
> How's the progress on this? I have lots of things to push to jdk8u-dev :)
> 
> -Aleksey
> 


From shade at redhat.com  Wed Mar 20 10:36:15 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 20 Mar 2019 11:36:15 +0100
Subject: JDK8u212 next steps
In-Reply-To: <HE1PR0201MB2266CCE6A8254E3BD77AA8D78A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
 <HE1PR0201MB2266CCE6A8254E3BD77AA8D78A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <dcf20eeb-77a6-f20a-c345-b5a91ddf697a@redhat.com>

On 3/20/19 11:29 AM, Langer, Christoph wrote:
> On the other hand, I guess, you can test it yourself by pushing one of your changes and then see
> how the backport issue will look like. If it's openjdk8u222, all is fine and you can push your
> batch. If not, we can repair the one backport issue manually and we continue to wait... What do
> you think?

Pushed this:
 https://bugs.openjdk.java.net/browse/JDK-8218479

It yields openjdk8u212 backport:
 https://bugs.openjdk.java.net/browse/JDK-8221156

So I guess hgupdater is not done yet.

-Aleksey


From christoph.langer at sap.com  Wed Mar 20 10:39:44 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 10:39:44 +0000
Subject: JDK8u212 next steps
In-Reply-To: <dcf20eeb-77a6-f20a-c345-b5a91ddf697a@redhat.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
 <HE1PR0201MB2266CCE6A8254E3BD77AA8D78A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <dcf20eeb-77a6-f20a-c345-b5a91ddf697a@redhat.com>
Message-ID: <HE1PR0201MB2266FA435C1F1158760CC7118A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

> On 3/20/19 11:29 AM, Langer, Christoph wrote:
> > On the other hand, I guess, you can test it yourself by pushing one of your
> changes and then see
> > how the backport issue will look like. If it's openjdk8u222, all is fine and you
> can push your
> > batch. If not, we can repair the one backport issue manually and we
> continue to wait... What do
> > you think?
> 
> Pushed this:
>  https://bugs.openjdk.java.net/browse/JDK-8218479
> 
> It yields openjdk8u212 backport:
>  https://bugs.openjdk.java.net/browse/JDK-8221156
> 
> So I guess hgupdater is not done yet.

Ok. I fixed https://bugs.openjdk.java.net/browse/JDK-8221156 to openjdk8u222. And we'll have to continue waiting a bit...

/Christoph


From aph at redhat.com  Wed Mar 20 11:14:04 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 20 Mar 2019 11:14:04 +0000
Subject: JDK8u212 next steps
In-Reply-To: <HE1PR0201MB2266CCE6A8254E3BD77AA8D78A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
 <HE1PR0201MB2266CCE6A8254E3BD77AA8D78A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <3fe43628-13e9-fd88-3594-1b2fbbf2b34d@redhat.com>

On 3/20/19 10:29 AM, Langer, Christoph wrote:

> good question. In JBS we have openjdk8u222 now. But I didn't get a
> confirmation mail, whether hgupdater for jdk8u-dev repositories has
> been updated. I have send a mail to ops this morning, requesting
> this confirmation.

It can take a while. Please don't bother ops unnecessarily. We'll get
confirmation once it's done.

-- 
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 Mar 20 15:53:14 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 20 Mar 2019 15:53:14 +0000
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
 <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
Message-ID: <c3bd5ea2-88c3-7bbb-f1b3-21d640d72cf9@redhat.com>

On 19/03/2019 15:09, Martin Buchholz wrote:
> Probably it's because glibc deprecated readdir, and we don't have
> --disable-warnings-as-errors by default?
> 
> (I think warnings should not be errors except as opt-in by openjdk
> developers/maintainers)

I agree, and we've implemented it that way downstream in IcedTea.
At present, 8u doesn't even have the option to toggle this in the
HotSpot build. I can certainly look at providing such an option and that
would be a better, more general fix than turning off one specific warning.

Note that warnings as errors is still the default in jdk/jdk unless xlc
is used:

https://hg.openjdk.java.net/jdk/jdk/file/83cace4142c8/make/autoconf/flags-cflags.m4#l142
-- 
Andrew :)

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

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


From xxinliu at amazon.com  Wed Mar 20 17:29:19 2019
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 20 Mar 2019 17:29:19 +0000
Subject: [8u] RFR 8170681: Remove fontconfig header files from JDK source
 tree
In-Reply-To: <c6347fea-807a-0619-2d09-79608554e056@redhat.com>
References: <8B3DEE95-2003-4AFF-95F9-EEF1B09A36DC@amazon.com>
 <c6347fea-807a-0619-2d09-79608554e056@redhat.com>
Message-ID: <482C059D-1AD2-4054-B276-17B32A1A5ECE@amazon.com>

Hi,  Andrew, 

Thanks for looking this issue.
I've put the label ' jdk8u-fix-request' on JDK-8192854
It's not necessary to go jdk8u-critical-request. 8u222 is fine. 

Thanks,
--lx

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

    On 20/03/2019 00:55, Liu, Xin wrote:
    > Hi, Dmitry,
    > For your backport,  I think jdk8u also need to backport this one.
    > https://bugs.openjdk.java.net/browse/JDK-8192854
    > 
    > If users specify ?with-fontconfig, buildscript is supposed to use ?FONTCONFIG_CFLAGS? to discover the header file fontconfig/fontconfig.h.  If you ignore FONTCONFIG_CFLAGS,  it will fall back to pick up from /usr/include. It?s fine by almost Linux distros.  We(Amazon) put 3rd libraries in non-standard location.  That why we have this problem.
    > 
    > webrev for backport JDK-8192854
    > https://cr.openjdk.java.net/~xliu/8192854/webrev/
    > 
    > thanks,
    > --lx
    > 
    > 
    > 
    
    This looks fine to me. You should flag the bug with jdk8u-fix-request to
    get it into 8u222.
    
    If you want it in 8u212, which has branched, use jdk8u-critical-request
    instead.
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew
    
    


From gnu.andrew at redhat.com  Wed Mar 20 18:30:13 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 20 Mar 2019 18:30:13 +0000
Subject: JDK8u212 next steps
In-Reply-To: <HE1PR0201MB22662A615BA3CD0F4D8A33E08A400@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e694dc60-4c5f-d9aa-3e57-b147ec4bbbc6@redhat.com>
 <HE1PR0201MB22662A615BA3CD0F4D8A33E08A400@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <9080a152-86e6-2079-29ae-be5379e76642@redhat.com>



On 19/03/2019 19:25, Langer, Christoph wrote:
> Hi Andrew,
> 
>> On 18/03/2019 08:58, Langer, Christoph wrote:
>>> Hi,
>>>
>>> I've transported the changes for OpenJDK 8u212 to the jdk8u repository
>> forest, as per the steps below. The request for a new JBS release
>> "openjdk8u222" was sent to ops.
>>>
>>> As of now, changes that are targeted for jdk8u212 need to be pushed to
>> jdk8u. Those must, of course, have been labeled with "jdk8u-critical-
>> request" and approved beforehand. I've set  "jdk8u-critical-request" on bugs
>> JDK-8220641, JDK-8193764 and JDK-8189761 as I assume they shall go into
>> jdk8u. Please correct it in JBS if my assumption is wrong.
>>>
>>
>> Why was this forked before these changes were pushed in the first place?
>> We'd already agreed they would go in first.
> 
> Yes, we agreed they should go in. But you also said "... until we find it's taking too long". However, I have to admit, I was maybe a bit too eager here.
> 
>>>
>>> When there are no objections, I'll do the push to jdk8u on Monday. In
>> detail this will mean the following steps:
>>
>> When exactly do you expect such objections, given you didn't send this
>> until 21:32 on Friday evening?
> 
> Hm, you are probably right. I should have let passed a working day at least for such objections.
> 
> So, after all, I should say sorry here. I guess I learned a lesson for the next round...
> 
> Best regards
> Christoph
> 

Thanks, it's appreciated. Rushing things is rarely a good idea.

I've now rebased and pushed 8220641 & 8193764. Just review of 8189761 to go.
-- 
Andrew :)

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

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


From christoph.langer at sap.com  Wed Mar 20 21:50:49 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 21:50:49 +0000
Subject: JDK8u212 next steps
In-Reply-To: <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
References: <DB6PR0201MB226349D060B06EF9559BBDA48A440@DB6PR0201MB2263.eurprd02.prod.outlook.com>
 <HE1PR0201MB2266067C41A419447862C5B68A470@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e40bf826-c2e8-c282-3e4e-cb1e5b60edd0@redhat.com>
Message-ID: <HE1PR0201MB2266B69D9A0A45B83FC4566F8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Aleksey, all,

jdk8u-dev setup for release "openjdk8u222" is done. We have the confirmation by ops and it has already been proven to work: https://bugs.openjdk.java.net/browse/JDK-8221166

Have fun pushing!

Christoph

> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Mittwoch, 20. M?rz 2019 11:16
> To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
> dev at openjdk.java.net
> Subject: Re: JDK8u212 next steps
> 
> Hi,
> 
> On 3/18/19 9:58 AM, Langer, Christoph wrote:
> > Approvals & pushes for openjdk8u222 will have to wait until the new setup
> for jdk8u-dev is in
> > place. I'll send an update once this is available.
> 
> How's the progress on this? I have lots of things to push to jdk8u-dev :)
> 
> -Aleksey
> 


From fujie at loongson.cn  Thu Mar 21 01:10:23 2019
From: fujie at loongson.cn (Jie Fu)
Date: Thu, 21 Mar 2019 09:10:23 +0800
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <c3bd5ea2-88c3-7bbb-f1b3-21d640d72cf9@redhat.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
 <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
 <c3bd5ea2-88c3-7bbb-f1b3-21d640d72cf9@redhat.com>
Message-ID: <f6fdfcd7-de2e-e137-5908-09dea7184faa@loongson.cn>

Thanks Andrew.

On 2019/3/20 ??11:53, Andrew John Hughes wrote:
> On 19/03/2019 15:09, Martin Buchholz wrote:
>> Probably it's because glibc deprecated readdir, and we don't have
>> --disable-warnings-as-errors by default?
>>
>> (I think warnings should not be errors except as opt-in by openjdk
>> developers/maintainers)
> I agree, and we've implemented it that way downstream in IcedTea.
> At present, 8u doesn't even have the option to toggle this in the
> HotSpot build. I can certainly look at providing such an option and that
> would be a better, more general fix than turning off one specific warning.
>
> Note that warnings as errors is still the default in jdk/jdk unless xlc
> is used:
>
> https://hg.openjdk.java.net/jdk/jdk/file/83cace4142c8/make/autoconf/flags-cflags.m4#l142


From guangyu.zhu at aliyun.com  Thu Mar 21 08:29:42 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Thu, 21 Mar 2019 16:29:42 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <9114E7B2-1EC7-4095-A19D-4D1ED7F46879@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>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
 <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>
 <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@azul.com>
 <dccc6efb-5372-442f-9cf5-66a3a1df9ef4.guangyu.zhu@aliyun.com>,
 <9114E7B2-1EC7-4095-A19D-4D1ED7F46879@azul.com>
Message-ID: <888e4706-18ac-4e5d-b75c-7143cba17caa.guangyu.zhu@aliyun.com>

Hi Andrey,

Thank you for pointing out. I ran the jtreg tests on the release build, but didn't run on the debug version, so the bug was hidden. With Alibaba's codebase, I can't reproduce this bug. Maybe I missed some code when doing the merge. Let me check.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Mar. 20 (Wed.) 01:18
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>; Ekaterina Vergizova <katya at azul.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Hi Guangyu,

We have found that your thread sampling implementation causes VM crashes. E.g. test jdk/jfr/cmd/TestPrintDefault could be used to
reproduce it (we've found 29 JFR tests in total which exhibit this problem).
On debug build this manifests as:

#  Internal Error (/home/andrey/ws/zulu8-emb-dev/hotspot/src/share/vm/runtime/thread.hpp:1789), pid=25987, tid=0x00007fffc0be1700
#  assert(thread != NULL && thread->is_Java_thread()) failed: just checking

with thread list like this:

Java Threads: ( => current thread )
  0x00007fff8c001800 JavaThread "JFR Recording Scheduler" daemon [_thread_blocked, id=26020, stack(0x00007fffc09e0000,0x00007fffc0ae1000)]
  0x00007fff942f0000 JavaThread "JFR Periodic Tasks" daemon [_thread_blocked, id=26018, stack(0x00007fffc0be2000,0x00007fffc0ce3000)]
  0x00007fff9420f800 JavaThread "JFR Recorder Thread" daemon [_thread_blocked, id=26017, stack(0x00007fffc0f4b000,0x00007fffc104c000)]
  0x00007ffff0205800 JavaThread "MainThread" [_thread_in_Java, id=26013, stack(0x00007fffc229a000,0x00007fffc239b000)]
  0x00007ffff0190800 JavaThread "Service Thread" daemon [_thread_blocked, id=26011, stack(0x00007fffc255b000,0x00007fffc265c000)]
  0x00007ffff017c000 JavaThread "C1 CompilerThread2" daemon [_thread_in_native, id=26010, stack(0x00007fffc265c000,0x00007fffc275d000)]
  0x00007ffff017a000 JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26009, stack(0x00007fffc275d000,0x00007fffc285e000)]
  0x00007ffff0176800 JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=26008, stack(0x00007fffc285e000,0x00007fffc295f000)]
  0x00007ffff0173000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=26007, stack(0x00007fffc295f000,0x00007fffc2a60000)]
  0x00007ffff0122800 JavaThread "Finalizer" daemon [_thread_blocked, id=26006, stack(0x00007fffc2d38000,0x00007fffc2e39000)]
  0x00007ffff011d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=26005, stack(0x00007fffc2e39000,0x00007fffc2f3a000)]
  0x00007ffff000f800 JavaThread "main" [_thread_blocked, id=25997, stack(0x00007ffff7eda000,0x00007ffff7fdb000)]

Other Threads:
  0x00007ffff010e000 VMThread [stack: 0x00007fffc2f3a000,0x00007fffc303b000] [id=26004]
  0x00007ffff018e000 WatcherThread [stack: 0x00007fffc245a000,0x00007fffc255b000] [id=26012]

=>0x00007fff942e5000 (exited) Thread [stack: 0x00007fffc0ae1000,0x00007fffc0be2000] [id=26021]

Looks like if thread exits during JFR thread sampling the latter still tries to traverse it. Which is, well, not something to be done on that stage
Would you be able to check the issue, please?

Thank you,
Andrey

> On 18 Mar 2019, at 04:18, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> ok, we will update the patch based on your comments.
> 
> Thanks,
> Guangyu
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Mar. 15 (Fri.) 21:44
> Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Guangyu,
> 
> The G1 heap region type reporting looks good to me as well. Thanks a lot for doing it!
> 
> Regards,
> Andrey
> 
> > On 14 Mar 2019, at 14:44, Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Hi Guangyu,
> >
> > By the moment I've read first two patches (thread sampling and biased locks). These look good to me
> > One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it
> >
> > I need a bit more time to read through G1 heap region types one.
> > BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please
> >
> > Thanks a lot,
> > Andrey
> >
> >> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >>
> >> Ok. I look forward to the feedbacks from both of you.
> >>
> >> Thanks,
> >> Guangyu
> >> ------------------------------------------------------------------
> >> Sender:Mario Torre <neugens.limasoftware at gmail.com>
> >> Sent At:2019 Mar. 13 (Wed.) 19:26
> >> Recipient:Andrey Petushkov <andrey at azul.com>
> >> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> >> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >>
> >> Thanks!
> >>
> >> I?m currently traveling but I?ll offer my review as soon as I get back next week.
> >>
> >> Cheers,
> >> Mario
> >> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
> >> Hi Guangyu,
> >>
> >> Cool! Thank you so much! Will review changes ASAP
> >> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
> >> April update release (mostly limited by testing resources capacity)
> >>
> >> Regards,
> >> Andrey
> >>
> >>> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >>>
> >>> Hi Andrey, Mario
> >>>
> >>> Is there any progress in backporting? We have completed the patch for the missing features. Please review.
> >>>
> >>> - thread sampling:
> >>> http://cr.openjdk.java.net/~luchsh/thread_sampling/
> >>>
> >>> - biased locking events:
> >>> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> >>> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> >>>
> >>> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
> >>> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> >>>
> >>> Thanks,
> >>> Guangyu
> >>>
> >>>
> >>> ------------------------------------------------------------------
> >>> Sender:Andrey Petushkov <andrey at azul.com>
> >>> Sent At:2019 Mar. 6 (Wed.) 00:34
> >>> Recipient:Mario Torre <neugens at redhat.com>
> >>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> >>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >>>
> >>> Hi Mario,
> >>>
> >>>> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> >>>>
> >>>> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> >>>>
> >>>>>> I'm going through the patch right now, but yes, from what I see the
> >>>>>> trace is removed. I had too a concern about this and was about to send
> >>>>>> a note. I'm not quite sure what to do, because Trace has been removed
> >>>>>> in 11 as far as I know, but removing mid stream in 8 may be a more
> >>>>>> interesting issue, however this isn't a user facing API, it was always
> >>>>>> meant to be internal to the JVM, so I don't quite know if there's
> >>>>>> really a reason we shouldn't change it. This is one question for the
> >>>>>> CSR group I think.
> >>>>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> >>>>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> >>>>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> >>>>> I will be happy to return it back
> >>>>
> >>>> Yes, I tend to agree with you, I do believe this is mostly an internal
> >>>> API for easy of patching with the JFR code (which is almost
> >>>> identical). The only concern is in the way the logging would be
> >>>> triggered externally and the compile time options for it (I still see
> >>>> a couple of instance where INCLUDE_TRACE is being used). As for
> >>>> triggering the logs, I don't recall that 8 has any means of doing
> >>>> this, I think some infrastructure came with 9 with the -Xlog option (I
> >>>> didn't follow this however, I'm not sure the option ever landed in 9)?
> >>>> In that case I guess it's safe to go after all.
> >>> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
> >>> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
> >>> IMHO we should get rid of all of them, but cannot tell for sure now
> >>>
> >>> Andrey
> >>>>
> >>>> 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 christoph.langer at sap.com  Thu Mar 21 10:05:54 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Mar 2019 10:05:54 +0000
Subject: Build OpenJDK 8 on MacOS Mojave (10.14.3)
Message-ID: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

the Mac experts will probably find my question to be silly and start laughing? but nevertheless, I?m asking it here ??

I was looking into building OpenJDK 8 today on my developer Mac, which runs Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I was trying to install xcode 4.6.3 ? but seems this wouldn?t run on Mojave. What can I do?

Ok, on the build requirements page [0], the requirements are documented to be MacOS 10.7 (Lion). However, I?m thinking, since OpenJDK 8 is not completely legacy yet, at least a developer build should be possible on a current operating system. I would accept having to install the oldest running Xcode compiler for sure, but not at all being able to build on a recent MacOS is not good.

So, question to the experts: Will it be impossible to bump the build environment because changes would be too complex? Or is there a solution to this which I?m just not aware of?

Thank you and Best regards
Christoph

[0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms


From aph at redhat.com  Thu Mar 21 10:12:32 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 21 Mar 2019 10:12:32 +0000
Subject: RFR: [8u] Build failed on Ubuntu 18.04 due to
 deprecated-declarations warnings
In-Reply-To: <c3bd5ea2-88c3-7bbb-f1b3-21d640d72cf9@redhat.com>
References: <d93fe1a4-9215-b4b9-adc2-0332e14ab6e7@loongson.cn>
 <a7c8ee41-8085-d969-c1fa-b55f740fb41f@redhat.com>
 <CA+kOe0-ExAP1cGdcQFm=dJ03OOOz_ugHz5HBh_FBUACyTWob0g@mail.gmail.com>
 <c3bd5ea2-88c3-7bbb-f1b3-21d640d72cf9@redhat.com>
Message-ID: <a0a7d29a-3f66-7654-065d-d9f89303268c@redhat.com>

On 3/20/19 3:53 PM, Andrew John Hughes wrote:
> On 19/03/2019 15:09, Martin Buchholz wrote:
>> Probably it's because glibc deprecated readdir, and we don't have
>> --disable-warnings-as-errors by default?
>>
>> (I think warnings should not be errors except as opt-in by openjdk
>> developers/maintainers)
> I agree

I'm pretty sure that -Wall should never be used with -Werror, because
-Wall is a grab bag of unconnected warnings. The official doc is "all
the warnings about constructions that some users consider
questionable, and that are easy to avoid (or modify to prevent the
warning)".

So, I think that warnings-as-errors makes sense, but not in
conjunction with -Wall. I guess no-one wants to start the bikeshed
discussion about which warnings should be on, though.

-- 
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  Thu Mar 21 10:20:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Mar 2019 10:20:34 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ?
Message-ID: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update?

With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests.

Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all?

Just trying to start a discussion? ??

Best regards
Christoph

[0] http://openjdk.java.net/jeps/319
[1] https://bugs.openjdk.java.net/browse/JDK-8189131


From stooke at redhat.com  Thu Mar 21 14:28:29 2019
From: stooke at redhat.com (Simon Tooke)
Date: Thu, 21 Mar 2019 10:28:29 -0400
Subject: Build OpenJDK 8 on MacOS Mojave (10.14.3)
In-Reply-To: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <18b29d3a-5aa2-ca61-051f-ead5cb885366@redhat.com>

I have (with a couple of small changes) built 8u on the latest macOS +
XCode.? The laptop with that build is at home right now, so I cant
forward a patch.? It was mostly fixing clang debug file generation and
updating Xcode version checking.

My build runs fine but crashes on shutdown in
PerfDataManager::destroy().? Interestingly, it was an issue for some
people building JDK 9, too [1]; I suspect it won't be too hard to track
down, but since it's a weekend project I haven't got to it yet.

I'll poke at it this evening.

-Simon

[1]
https://stackoverflow.com/questions/51123714/issue-when-using-mac-to-build-openjdk-9


On 3/21/2019 6:05 AM, Langer, Christoph wrote:
> Hi,
>
> the Mac experts will probably find my question to be silly and start laughing? but nevertheless, I?m asking it here ??
>
> I was looking into building OpenJDK 8 today on my developer Mac, which runs Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I was trying to install xcode 4.6.3 ? but seems this wouldn?t run on Mojave. What can I do?
>
> Ok, on the build requirements page [0], the requirements are documented to be MacOS 10.7 (Lion). However, I?m thinking, since OpenJDK 8 is not completely legacy yet, at least a developer build should be possible on a current operating system. I would accept having to install the oldest running Xcode compiler for sure, but not at all being able to build on a recent MacOS is not good.
>
> So, question to the experts: Will it be impossible to bump the build environment because changes would be too complex? Or is there a solution to this which I?m just not aware of?
>
> Thank you and Best regards
> Christoph
>
> [0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>


From erik.joelsson at oracle.com  Thu Mar 21 15:49:22 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 21 Mar 2019 08:49:22 -0700
Subject: Build OpenJDK 8 on MacOS Mojave (10.14.3)
In-Reply-To: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <d4bf0311-3a3e-8ae5-f50f-2c0a5af0bbc0@oracle.com>

I don't think anyone has tried. Just removing the check in configure 
should be simple enough, but I suspect there will be lots of follow-on 
issues.

/Erik

On 2019-03-21 03:05, Langer, Christoph wrote:
> Hi,
>
> the Mac experts will probably find my question to be silly and start laughing? but nevertheless, I?m asking it here ??
>
> I was looking into building OpenJDK 8 today on my developer Mac, which runs Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I was trying to install xcode 4.6.3 ? but seems this wouldn?t run on Mojave. What can I do?
>
> Ok, on the build requirements page [0], the requirements are documented to be MacOS 10.7 (Lion). However, I?m thinking, since OpenJDK 8 is not completely legacy yet, at least a developer build should be possible on a current operating system. I would accept having to install the oldest running Xcode compiler for sure, but not at all being able to build on a recent MacOS is not good.
>
> So, question to the experts: Will it be impossible to bump the build environment because changes would be too complex? Or is there a solution to this which I?m just not aware of?
>
> Thank you and Best regards
> Christoph
>
> [0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>

From christoph.langer at sap.com  Thu Mar 21 15:39:05 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Mar 2019 15:39:05 +0000
Subject: Build OpenJDK 8 on MacOS Mojave (10.14.3)
In-Reply-To: <18b29d3a-5aa2-ca61-051f-ead5cb885366@redhat.com>
References: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <18b29d3a-5aa2-ca61-051f-ead5cb885366@redhat.com>
Message-ID: <HE1PR0201MB2266417F62AFF7EB6B7032D28A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Simon,

that sounds good. Looking forward to your patch(es), maybe we can build upon it...

Thanks
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Simon Tooke
> Sent: Donnerstag, 21. M?rz 2019 15:28
> To: jdk8u-dev at openjdk.java.net
> Subject: Re: Build OpenJDK 8 on MacOS Mojave (10.14.3)
> 
> I have (with a couple of small changes) built 8u on the latest macOS +
> XCode.? The laptop with that build is at home right now, so I cant
> forward a patch.? It was mostly fixing clang debug file generation and
> updating Xcode version checking.
> 
> My build runs fine but crashes on shutdown in
> PerfDataManager::destroy().? Interestingly, it was an issue for some
> people building JDK 9, too [1]; I suspect it won't be too hard to track
> down, but since it's a weekend project I haven't got to it yet.
> 
> I'll poke at it this evening.
> 
> -Simon
> 
> [1]
> https://stackoverflow.com/questions/51123714/issue-when-using-mac-to-
> build-openjdk-9
> 
> 
> On 3/21/2019 6:05 AM, Langer, Christoph wrote:
> > Hi,
> >
> > the Mac experts will probably find my question to be silly and start
> laughing? but nevertheless, I?m asking it here ??
> >
> > I was looking into building OpenJDK 8 today on my developer Mac, which
> runs Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I
> was trying to install xcode 4.6.3 ? but seems this wouldn?t run on Mojave.
> What can I do?
> >
> > Ok, on the build requirements page [0], the requirements are documented
> to be MacOS 10.7 (Lion). However, I?m thinking, since OpenJDK 8 is not
> completely legacy yet, at least a developer build should be possible on a
> current operating system. I would accept having to install the oldest running
> Xcode compiler for sure, but not at all being able to build on a recent MacOS
> is not good.
> >
> > So, question to the experts: Will it be impossible to bump the build
> environment because changes would be too complex? Or is there a solution
> to this which I?m just not aware of?
> >
> > Thank you and Best regards
> > Christoph
> >
> > [0]
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> >


From deepak.kejriwal at oracle.com  Fri Mar 22 15:51:44 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Fri, 22 Mar 2019 08:51:44 -0700 (PDT)
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
Message-ID: <627764ae-9c68-4113-920b-f1010086e8c7@default>

Hi All,

 

Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:-

 

JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131

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

 

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

 

Master bug change set:  http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2

http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519

Summary:
The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 (from 12u) are not clean backport. Changes for file "DateTimeFormatterBuilder.java" are manually merged. Since, test file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only test cases modified as part for JDK-8042131 and JDK-8210633 are added.

All tests are run against the changes and found to be passing. 

Regards,

Deepak

 

From naoto.sato at oracle.com  Fri Mar 22 17:29:26 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 22 Mar 2019 10:29:26 -0700
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <627764ae-9c68-4113-920b-f1010086e8c7@default>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
Message-ID: <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>

Hi Deepak,

Please modify the copyright year accordingly. Otherwise it looks good to me.

Naoto

On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
> Hi All,
> 
>   
> 
> Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:-
> 
>   
> 
> JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
> 
>        https://bugs.openjdk.java.net/browse/JDK-8210633
> 
>   
> 
> Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
> 
>   
> 
> Master bug change set:  http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
> 
> Summary:
> The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 (from 12u) are not clean backport. Changes for file "DateTimeFormatterBuilder.java" are manually merged. Since, test file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only test cases modified as part for JDK-8042131 and JDK-8210633 are added.
> 
> All tests are run against the changes and found to be passing.
> 
> Regards,
> 
> Deepak
> 
>   
> 

From sean.mullan at oracle.com  Fri Mar 22 19:33:27 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 22 Mar 2019 15:33:27 -0400
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>

Hi Christoph,

On 3/21/19 6:20 AM, Langer, Christoph wrote:
> Hi,
> 
> I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update?
> 
> With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests.
> 
> Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all?

I can answer the first two questions. I talked to one of our Product 
Managers who was involved with this JEP and he said that we have 
permission to release these certificates as open source at OpenJDK (much 
as Mozilla has roots in Firefox).  Therefore there should be no concerns 
using with OpenJDK 8 or other versions for that matter.  If you mean the 
jdk8u project specifically, you should check with the current 
maintainers for interest in this as I think they currently use other 
means for their builds.

--Sean

> 
> Just trying to start a discussion? ??
> 
> Best regards
> Christoph
> 
> [0] http://openjdk.java.net/jeps/319
> [1] https://bugs.openjdk.java.net/browse/JDK-8189131
> 

From martijnverburg at gmail.com  Fri Mar 22 19:37:37 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 22 Mar 2019 19:37:37 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
Message-ID: <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>

FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide a
patch to upstream that change.

Cheers,
Martijn


On Fri, 22 Mar 2019 at 19:35, Sean Mullan <sean.mullan at oracle.com> wrote:

> Hi Christoph,
>
> On 3/21/19 6:20 AM, Langer, Christoph wrote:
> > Hi,
> >
> > I recently came across a scenario where I wanted to use a self-built
> OpenJDK 8 in a maven build and it could not download artefacts due to
> missing root certificates. I helped myself by replacing the cacerts with
> some other version from a later OpenJDK and came over the issue. However,
> I?ve asked myself whether it was possible/worthwhile to get the root
> certificates also into an OpenJDK 8 update?
> >
> > With JEP 319 [0], Oracle has open-sourced the root certificates into
> OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1].
> After that, several commits have been made to update the set of root
> certificates and improve the tests.
> >
> > Now my questions are: Is it legally possible to bring these root
> certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be
> added to OpenJDK 8 via an update release? And, last but not least, would
> there be interest in the community for that at all?
>
> I can answer the first two questions. I talked to one of our Product
> Managers who was involved with this JEP and he said that we have
> permission to release these certificates as open source at OpenJDK (much
> as Mozilla has roots in Firefox).  Therefore there should be no concerns
> using with OpenJDK 8 or other versions for that matter.  If you mean the
> jdk8u project specifically, you should check with the current
> maintainers for interest in this as I think they currently use other
> means for their builds.
>
> --Sean
>
> >
> > Just trying to start a discussion? ??
> >
> > Best regards
> > Christoph
> >
> > [0] http://openjdk.java.net/jeps/319
> > [1] https://bugs.openjdk.java.net/browse/JDK-8189131
> >
>

From christoph.langer at sap.com  Sun Mar 24 20:38:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 24 Mar 2019 20:38:14 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
Message-ID: <HE1PR0201MB2266E76919BDF3FAE4C543578A5D0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Sean,

> > Now my questions are: Is it legally possible to bring these root certificates
> also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK
> 8 via an update release? And, last but not least, would there be interest in
> the community for that at all?
> 
> I can answer the first two questions. I talked to one of our Product
> Managers who was involved with this JEP and he said that we have
> permission to release these certificates as open source at OpenJDK (much
> as Mozilla has roots in Firefox).  Therefore there should be no concerns
> using with OpenJDK 8 or other versions for that matter.  If you mean the
> jdk8u project specifically, you should check with the current
> maintainers for interest in this as I think they currently use other
> means for their builds.

Thank you for responding. So I'll check with the jdk8u project whether there's interest in this.

Best regards
Christoph


From deepak.kejriwal at oracle.com  Mon Mar 25 04:41:22 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Sun, 24 Mar 2019 21:41:22 -0700 (PDT)
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
Message-ID: <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>

Hi Naoto,

Thanks for review. I will update the copyright information and push the changes.

Regards,
Deepak 


-----Original Message-----
From: Naoto Sato 
Sent: Friday, March 22, 2019 10:59 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 Backport of JDK-8042131 and JDK-8210633

Hi Deepak,

Please modify the copyright year accordingly. Otherwise it looks good to me.

Naoto

On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
> Hi All,
> 
>   
> 
> Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-dev:-
> 
>   
> 
> JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
> 
>        https://bugs.openjdk.java.net/browse/JDK-8210633
> 
>   
> 
> Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
> 
>   
> 
> Master bug change set:  http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
> 
> Summary:
> The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633 (from 12u) are not clean backport. Changes for file "DateTimeFormatterBuilder.java" are manually merged. Since, test file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only test cases modified as part for JDK-8042131 and JDK-8210633 are added.
> 
> All tests are run against the changes and found to be passing.
> 
> Regards,
> 
> Deepak
> 
>   
> 

From ramanand.patil at oracle.com  Mon Mar 25 06:37:40 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Sun, 24 Mar 2019 23:37:40 -0700 (PDT)
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
 <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
Message-ID: <7afc386a-11ac-403c-a6ec-0d7988604818@default>

Hi Deepak,

In particular, the test TestDateTimeFormatterBuilderWithLocale.java should have only one copyright year i.e. 2019, since this is a new file in jdk8u-dev repos. Also I think, you can omit the second copyright info(from line no. 24) for the same reason.


Note: I am not a reviewer for JDK 8 Updates Project.

Regards,
Ramanand.

> -----Original Message-----
> From: Deepak Kejriwal
> Sent: Monday, March 25, 2019 10:11 AM
> To: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> 
> Hi Naoto,
> 
> Thanks for review. I will update the copyright information and push the
> changes.
> 
> Regards,
> Deepak
> 
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Friday, March 22, 2019 10:59 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 Backport of JDK-8042131 and JDK-8210633
> 
> Hi Deepak,
> 
> Please modify the copyright year accordingly. Otherwise it looks good to me.
> 
> Naoto
> 
> On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
> > Hi All,
> >
> >
> >
> > Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-
> dev:-
> >
> >
> >
> > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
> >
> >        https://bugs.openjdk.java.net/browse/JDK-8210633
> >
> >
> >
> > Webrev: http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
> >
> >
> >
> > Master bug change set:
> http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
> >
> > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
> >
> > Summary:
> > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-8210633
> (from 12u) are not clean backport. Changes for file
> "DateTimeFormatterBuilder.java" are manually merged. Since, test file
> "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only
> test cases modified as part for JDK-8042131 and JDK-8210633 are added.
> >
> > All tests are run against the changes and found to be passing.
> >
> > Regards,
> >
> > Deepak
> >
> >
> >

From christoph.langer at sap.com  Mon Mar 25 07:12:12 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Mar 2019 07:12:12 +0000
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <7afc386a-11ac-403c-a6ec-0d7988604818@default>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
 <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
 <7afc386a-11ac-403c-a6ec-0d7988604818@default>
Message-ID: <HE1PR0201MB226683A8A4B6055474D0EF828A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi there,

since this is a downport for jdk/jdk, I think the copyright headers should be the same as upstream.

So, for src/share/classes/java/time/format/DateTimeFormatterBuilder.java, you should take 2018 as copyright year. For the test the headers look correct.

As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle 8 updates. For the former, you'll have to request downport by setting the jdk8u-fix-request label in the bugs.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Ramanand Patil
> Sent: Montag, 25. M?rz 2019 07:38
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato
> <naoto.sato at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>;
> jdk8u-dev at openjdk.java.net
> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> 
> Hi Deepak,
> 
> In particular, the test TestDateTimeFormatterBuilderWithLocale.java should
> have only one copyright year i.e. 2019, since this is a new file in jdk8u-dev
> repos. Also I think, you can omit the second copyright info(from line no. 24)
> for the same reason.
> 
> 
> Note: I am not a reviewer for JDK 8 Updates Project.
> 
> Regards,
> Ramanand.
> 
> > -----Original Message-----
> > From: Deepak Kejriwal
> > Sent: Monday, March 25, 2019 10:11 AM
> > To: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-
> > dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> >
> > Hi Naoto,
> >
> > Thanks for review. I will update the copyright information and push the
> > changes.
> >
> > Regards,
> > Deepak
> >
> >
> > -----Original Message-----
> > From: Naoto Sato
> > Sent: Friday, March 22, 2019 10:59 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 Backport of JDK-8042131 and JDK-8210633
> >
> > Hi Deepak,
> >
> > Please modify the copyright year accordingly. Otherwise it looks good to
> me.
> >
> > Naoto
> >
> > On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
> > > Hi All,
> > >
> > >
> > >
> > > Please review the back port of fix for JDK-8042131 and JDK-8210633 to 8u-
> > dev:-
> > >
> > >
> > >
> > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
> > >
> > >        https://bugs.openjdk.java.net/browse/JDK-8210633
> > >
> > >
> > >
> > > Webrev:
> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
> > >
> > >
> > >
> > > Master bug change set:
> > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
> > >
> > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
> > >
> > > Summary:
> > > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-
> 8210633
> > (from 12u) are not clean backport. Changes for file
> > "DateTimeFormatterBuilder.java" are manually merged. Since, test file
> > "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u release only
> > test cases modified as part for JDK-8042131 and JDK-8210633 are added.
> > >
> > > All tests are run against the changes and found to be passing.
> > >
> > > Regards,
> > >
> > > Deepak
> > >
> > >
> > >

From christoph.langer at sap.com  Mon Mar 25 07:22:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Mar 2019 07:22:34 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
 <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>
Message-ID: <HE1PR0201MB2266E612E73C33F39B1057438A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Martijn,

as far as I understand the AdoptOpenJDK infrastructure, you have created a cacerts file from the Mozilla certificates which you are using in the AdoptOpenJDK 8 build via configure option [1]. Is that correct or am I missing something?

I was planning to bring the cacerts file from jdk/jdk down to 8 with the associated tests. Your build setup should still work then, I guess.

However, if somebody from AdoptOpenJDK wants to do the work of bringing it into OpenJDK8 updates, feel free. It?s not the very first thing on my todo list ??

Thanks & Best regards
Christoph

[1] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/security


From: Martijn Verburg <martijnverburg at gmail.com>
Sent: Freitag, 22. M?rz 2019 20:38
To: Sean Mullan <sean.mullan at oracle.com>
Cc: Langer, Christoph <christoph.langer at sap.com>; jdk8u-dev at openjdk.java.net; OpenJDK Dev list <security-dev at openjdk.java.net>
Subject: Re: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ?

FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide a patch to upstream that change.

Cheers,
Martijn


On Fri, 22 Mar 2019 at 19:35, Sean Mullan <sean.mullan at oracle.com<mailto:sean.mullan at oracle.com>> wrote:
Hi Christoph,

On 3/21/19 6:20 AM, Langer, Christoph wrote:
> Hi,
>
> I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update?
>
> With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests.
>
> Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all?

I can answer the first two questions. I talked to one of our Product
Managers who was involved with this JEP and he said that we have
permission to release these certificates as open source at OpenJDK (much
as Mozilla has roots in Firefox).  Therefore there should be no concerns
using with OpenJDK 8 or other versions for that matter.  If you mean the
jdk8u project specifically, you should check with the current
maintainers for interest in this as I think they currently use other
means for their builds.

--Sean

>
> Just trying to start a discussion? ??
>
> Best regards
> Christoph
>
> [0] http://openjdk.java.net/jeps/319
> [1] https://bugs.openjdk.java.net/browse/JDK-8189131
>

From ramanand.patil at oracle.com  Mon Mar 25 10:23:33 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 25 Mar 2019 03:23:33 -0700 (PDT)
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <HE1PR0201MB226683A8A4B6055474D0EF828A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
 <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
 <7afc386a-11ac-403c-a6ec-0d7988604818@default>
 <HE1PR0201MB226683A8A4B6055474D0EF828A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <94b978d4-aabc-4551-8229-3b8a71d37d5f@default>

Hi Christoph,
I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same.

Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it.

Regards,
Ramanand.

> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Monday, March 25, 2019 12:42 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Cc: Ramanand Patil <ramanand.patil at oracle.com>; Naoto Sato
> <naoto.sato at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>;
> jdk8u-dev at openjdk.java.net
> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> 
> Hi there,
> 
> since this is a downport for jdk/jdk, I think the copyright headers should be
> the same as upstream.
> 
> So, for src/share/classes/java/time/format/DateTimeFormatterBuilder.java,
> you should take 2018 as copyright year. For the test the headers look correct.
> 
> As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle 8
> updates. For the former, you'll have to request downport by setting the
> jdk8u-fix-request label in the bugs.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> > Ramanand Patil
> > Sent: Montag, 25. M?rz 2019 07:38
> > To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato
> > <naoto.sato at oracle.com>; core-libs-dev
> > <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> >
> > Hi Deepak,
> >
> > In particular, the test TestDateTimeFormatterBuilderWithLocale.java
> > should have only one copyright year i.e. 2019, since this is a new
> > file in jdk8u-dev repos. Also I think, you can omit the second
> > copyright info(from line no. 24) for the same reason.
> >
> >
> > Note: I am not a reviewer for JDK 8 Updates Project.
> >
> > Regards,
> > Ramanand.
> >
> > > -----Original Message-----
> > > From: Deepak Kejriwal
> > > Sent: Monday, March 25, 2019 10:11 AM
> > > To: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-
> > > dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> > >
> > > Hi Naoto,
> > >
> > > Thanks for review. I will update the copyright information and push
> > > the changes.
> > >
> > > Regards,
> > > Deepak
> > >
> > >
> > > -----Original Message-----
> > > From: Naoto Sato
> > > Sent: Friday, March 22, 2019 10:59 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 Backport of JDK-8042131 and JDK-8210633
> > >
> > > Hi Deepak,
> > >
> > > Please modify the copyright year accordingly. Otherwise it looks
> > > good to
> > me.
> > >
> > > Naoto
> > >
> > > On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
> > > > Hi All,
> > > >
> > > >
> > > >
> > > > Please review the back port of fix for JDK-8042131 and JDK-8210633
> > > > to 8u-
> > > dev:-
> > > >
> > > >
> > > >
> > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
> > > >
> > > >        https://bugs.openjdk.java.net/browse/JDK-8210633
> > > >
> > > >
> > > >
> > > > Webrev:
> > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
> > > >
> > > >
> > > >
> > > > Master bug change set:
> > > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
> > > >
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
> > > >
> > > > Summary:
> > > > The backport of fix for both bugs JDK-8042131 (from 11u) and JDK-
> > 8210633
> > > (from 12u) are not clean backport. Changes for file
> > > "DateTimeFormatterBuilder.java" are manually merged. Since, test
> > > file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u
> > > release only test cases modified as part for JDK-8042131 and JDK-8210633
> are added.
> > > >
> > > > All tests are run against the changes and found to be passing.
> > > >
> > > > Regards,
> > > >
> > > > Deepak
> > > >
> > > >
> > > >

From stooke at redhat.com  Mon Mar 25 13:48:16 2019
From: stooke at redhat.com (Simon Tooke)
Date: Mon, 25 Mar 2019 09:48:16 -0400
Subject: Build OpenJDK 8 on MacOS Mojave (10.14.3)
In-Reply-To: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226617EC641F0939178CFBCC8A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <cb86324a-8678-c263-2ba7-469e4da21a87@redhat.com>

I have successfully done this (with some very important caveats that
make it useful only for hacking the JDK at this point).

Please let me know if you have any comments or corrections to my rough
guide:

https://github.com/stooke/jdk8u-xcode10

I'll write a shell script at some point, and clean up the patches into a
proper PR.

On 3/21/2019 6:05 AM, Langer, Christoph wrote:
> Hi,
>
> the Mac experts will probably find my question to be silly and start laughing? but nevertheless, I?m asking it here ??
>
> I was looking into building OpenJDK 8 today on my developer Mac, which runs Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I was trying to install xcode 4.6.3 ? but seems this wouldn?t run on Mojave. What can I do?
>
> Ok, on the build requirements page [0], the requirements are documented to be MacOS 10.7 (Lion). However, I?m thinking, since OpenJDK 8 is not completely legacy yet, at least a developer build should be possible on a current operating system. I would accept having to install the oldest running Xcode compiler for sure, but not at all being able to build on a recent MacOS is not good.
>
> So, question to the experts: Will it be impossible to bump the build environment because changes would be too complex? Or is there a solution to this which I?m just not aware of?
>
> Thank you and Best regards
> Christoph
>
> [0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>

From deepak.kejriwal at oracle.com  Mon Mar 25 13:53:45 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Mon, 25 Mar 2019 06:53:45 -0700 (PDT)
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <94b978d4-aabc-4551-8229-3b8a71d37d5f@default>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
 <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
 <7afc386a-11ac-403c-a6ec-0d7988604818@default>
 <HE1PR0201MB226683A8A4B6055474D0EF828A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <94b978d4-aabc-4551-8229-3b8a71d37d5f@default>
Message-ID: <ef95c006-6910-46e3-999b-e3af9a035f6b@default>

Hi Ramanand / Christoph,

Thanks for review. I think Naoto and Ramanand are right, we do update the copyright year when it is not a clean backport. Please find the updated version of webrev.

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

Regards,
Deepak

-----Original Message-----
From: Ramanand Patil 
Sent: Monday, March 25, 2019 3:54 PM
To: Langer, Christoph <christoph.langer at sap.com>; Deepak Kejriwal <deepak.kejriwal at oracle.com>
Cc: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi Christoph,
I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same.

Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it.

Regards,
Ramanand.

> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Monday, March 25, 2019 12:42 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Cc: Ramanand Patil <ramanand.patil at oracle.com>; Naoto Sato 
> <naoto.sato at oracle.com>; core-libs-dev 
> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> 
> Hi there,
> 
> since this is a downport for jdk/jdk, I think the copyright headers 
> should be the same as upstream.
> 
> So, for 
> src/share/classes/java/time/format/DateTimeFormatterBuilder.java,
> you should take 2018 as copyright year. For the test the headers look correct.
> 
> As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle 
> 8 updates. For the former, you'll have to request downport by setting 
> the jdk8u-fix-request label in the bugs.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of 
> > Ramanand Patil
> > Sent: Montag, 25. M?rz 2019 07:38
> > To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato 
> > <naoto.sato at oracle.com>; core-libs-dev 
> > <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> >
> > Hi Deepak,
> >
> > In particular, the test TestDateTimeFormatterBuilderWithLocale.java
> > should have only one copyright year i.e. 2019, since this is a new 
> > file in jdk8u-dev repos. Also I think, you can omit the second 
> > copyright info(from line no. 24) for the same reason.
> >
> >
> > Note: I am not a reviewer for JDK 8 Updates Project.
> >
> > Regards,
> > Ramanand.
> >
> > > -----Original Message-----
> > > From: Deepak Kejriwal
> > > Sent: Monday, March 25, 2019 10:11 AM
> > > To: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs- 
> > > dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> > > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> > >
> > > Hi Naoto,
> > >
> > > Thanks for review. I will update the copyright information and 
> > > push the changes.
> > >
> > > Regards,
> > > Deepak
> > >
> > >
> > > -----Original Message-----
> > > From: Naoto Sato
> > > Sent: Friday, March 22, 2019 10:59 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 Backport of JDK-8042131 and JDK-8210633
> > >
> > > Hi Deepak,
> > >
> > > Please modify the copyright year accordingly. Otherwise it looks 
> > > good to
> > me.
> > >
> > > Naoto
> > >
> > > On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
> > > > Hi All,
> > > >
> > > >
> > > >
> > > > Please review the back port of fix for JDK-8042131 and 
> > > > JDK-8210633 to 8u-
> > > dev:-
> > > >
> > > >
> > > >
> > > > JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
> > > >
> > > >        https://bugs.openjdk.java.net/browse/JDK-8210633
> > > >
> > > >
> > > >
> > > > Webrev:
> > http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
> > > >
> > > >
> > > >
> > > > Master bug change set:
> > > http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
> > > >
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
> > > >
> > > > Summary:
> > > > The backport of fix for both bugs JDK-8042131 (from 11u) and 
> > > > JDK-
> > 8210633
> > > (from 12u) are not clean backport. Changes for file 
> > > "DateTimeFormatterBuilder.java" are manually merged. Since, test 
> > > file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u 
> > > release only test cases modified as part for JDK-8042131 and 
> > > JDK-8210633
> are added.
> > > >
> > > > All tests are run against the changes and found to be passing.
> > > >
> > > > Regards,
> > > >
> > > > Deepak
> > > >
> > > >
> > > >

From naoto.sato at oracle.com  Mon Mar 25 19:39:24 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Mar 2019 12:39:24 -0700
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <ef95c006-6910-46e3-999b-e3af9a035f6b@default>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
 <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
 <7afc386a-11ac-403c-a6ec-0d7988604818@default>
 <HE1PR0201MB226683A8A4B6055474D0EF828A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <94b978d4-aabc-4551-8229-3b8a71d37d5f@default>
 <ef95c006-6910-46e3-999b-e3af9a035f6b@default>
Message-ID: <9a025359-2f31-6f73-59b5-cc3d6ed9ea34@oracle.com>

Looks good.

Naoto

On 3/25/19 6:53 AM, Deepak Kejriwal wrote:
> Hi Ramanand / Christoph,
> 
> Thanks for review. I think Naoto and Ramanand are right, we do update the copyright year when it is not a clean backport. Please find the updated version of webrev.
> 
> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Ramanand Patil
> Sent: Monday, March 25, 2019 3:54 PM
> To: Langer, Christoph <christoph.langer at sap.com>; Deepak Kejriwal <deepak.kejriwal at oracle.com>
> Cc: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
> 
> Hi Christoph,
> I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same.
> 
> Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it.
> 
> Regards,
> Ramanand.
> 
>> -----Original Message-----
>> From: Langer, Christoph <christoph.langer at sap.com>
>> Sent: Monday, March 25, 2019 12:42 PM
>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>
>> Cc: Ramanand Patil <ramanand.patil at oracle.com>; Naoto Sato
>> <naoto.sato at oracle.com>; core-libs-dev
>> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
>> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
>>
>> Hi there,
>>
>> since this is a downport for jdk/jdk, I think the copyright headers
>> should be the same as upstream.
>>
>> So, for
>> src/share/classes/java/time/format/DateTimeFormatterBuilder.java,
>> you should take 2018 as copyright year. For the test the headers look correct.
>>
>> As for jdk8u push: Will you push it to OpenJDK 8 updates or to Oracle
>> 8 updates. For the former, you'll have to request downport by setting
>> the jdk8u-fix-request label in the bugs.
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
>>> Ramanand Patil
>>> Sent: Montag, 25. M?rz 2019 07:38
>>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Naoto Sato
>>> <naoto.sato at oracle.com>; core-libs-dev
>>> <core-libs-dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
>>> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
>>>
>>> Hi Deepak,
>>>
>>> In particular, the test TestDateTimeFormatterBuilderWithLocale.java
>>> should have only one copyright year i.e. 2019, since this is a new
>>> file in jdk8u-dev repos. Also I think, you can omit the second
>>> copyright info(from line no. 24) for the same reason.
>>>
>>>
>>> Note: I am not a reviewer for JDK 8 Updates Project.
>>>
>>> Regards,
>>> Ramanand.
>>>
>>>> -----Original Message-----
>>>> From: Deepak Kejriwal
>>>> Sent: Monday, March 25, 2019 10:11 AM
>>>> To: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-
>>>> dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net
>>>> Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
>>>>
>>>> Hi Naoto,
>>>>
>>>> Thanks for review. I will update the copyright information and
>>>> push the changes.
>>>>
>>>> Regards,
>>>> Deepak
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Naoto Sato
>>>> Sent: Friday, March 22, 2019 10:59 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 Backport of JDK-8042131 and JDK-8210633
>>>>
>>>> Hi Deepak,
>>>>
>>>> Please modify the copyright year accordingly. Otherwise it looks
>>>> good to
>>> me.
>>>>
>>>> Naoto
>>>>
>>>> On 3/22/19 8:51 AM, Deepak Kejriwal wrote:
>>>>> Hi All,
>>>>>
>>>>>
>>>>>
>>>>> Please review the back port of fix for JDK-8042131 and
>>>>> JDK-8210633 to 8u-
>>>> dev:-
>>>>>
>>>>>
>>>>>
>>>>> JBS report: https://bugs.openjdk.java.net/browse/JDK-8042131
>>>>>
>>>>>         https://bugs.openjdk.java.net/browse/JDK-8210633
>>>>>
>>>>>
>>>>>
>>>>> Webrev:
>>> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.00/
>>>>>
>>>>>
>>>>>
>>>>> Master bug change set:
>>>> http://hg.openjdk.java.net/jdk/jdk/rev/f2d94a0619a2
>>>>>
>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/a0426bc28519
>>>>>
>>>>> Summary:
>>>>> The backport of fix for both bugs JDK-8042131 (from 11u) and
>>>>> JDK-
>>> 8210633
>>>> (from 12u) are not clean backport. Changes for file
>>>> "DateTimeFormatterBuilder.java" are manually merged. Since, test
>>>> file "TestDateTimeFormatterBuilderWithLocale.java" is new in 8u
>>>> release only test cases modified as part for JDK-8042131 and
>>>> JDK-8210633
>> are added.
>>>>>
>>>>> All tests are run against the changes and found to be passing.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Deepak
>>>>>
>>>>>
>>>>>

From martijnverburg at gmail.com  Mon Mar 25 19:47:19 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 25 Mar 2019 19:47:19 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <HE1PR0201MB2266E612E73C33F39B1057438A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
 <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>
 <HE1PR0201MB2266E612E73C33F39B1057438A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAP7YuAQ2YnieMP3VC1+3A8Ko9i9yTQwij2+Y+K248tJMefwSRg@mail.gmail.com>

We basically pulled in the JEP 319 certs from 11 and put them into 8. Happy
to create a patch if that helps, might be a slightly different set to what
you are proposing though?

Cheers,
Martijn


On Mon, 25 Mar 2019 at 07:22, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Martijn,
>
>
>
> as far as I understand the AdoptOpenJDK infrastructure, you have created a
> cacerts file from the Mozilla certificates which you are using in the
> AdoptOpenJDK 8 build via configure option [1]. Is that correct or am I
> missing something?
>
>
>
> I was planning to bring the cacerts file from jdk/jdk down to 8 with the
> associated tests. Your build setup should still work then, I guess.
>
>
>
> However, if somebody from AdoptOpenJDK wants to do the work of bringing it
> into OpenJDK8 updates, feel free. It?s not the very first thing on my todo
> list ??
>
>
>
> Thanks & Best regards
>
> Christoph
>
>
>
> [1] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/security
>
>
>
>
>
> *From:* Martijn Verburg <martijnverburg at gmail.com>
> *Sent:* Freitag, 22. M?rz 2019 20:38
> *To:* Sean Mullan <sean.mullan at oracle.com>
> *Cc:* Langer, Christoph <christoph.langer at sap.com>;
> jdk8u-dev at openjdk.java.net; OpenJDK Dev list <
> security-dev at openjdk.java.net>
> *Subject:* Re: [8u] Is it possible to bring root certificates to OpenJDK
> 8 [JEP319] ?
>
>
>
> FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide
> a patch to upstream that change.
>
>
> Cheers,
> Martijn
>
>
>
>
>
> On Fri, 22 Mar 2019 at 19:35, Sean Mullan <sean.mullan at oracle.com> wrote:
>
> Hi Christoph,
>
> On 3/21/19 6:20 AM, Langer, Christoph wrote:
> > Hi,
> >
> > I recently came across a scenario where I wanted to use a self-built
> OpenJDK 8 in a maven build and it could not download artefacts due to
> missing root certificates. I helped myself by replacing the cacerts with
> some other version from a later OpenJDK and came over the issue. However,
> I?ve asked myself whether it was possible/worthwhile to get the root
> certificates also into an OpenJDK 8 update?
> >
> > With JEP 319 [0], Oracle has open-sourced the root certificates into
> OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1].
> After that, several commits have been made to update the set of root
> certificates and improve the tests.
> >
> > Now my questions are: Is it legally possible to bring these root
> certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be
> added to OpenJDK 8 via an update release? And, last but not least, would
> there be interest in the community for that at all?
>
> I can answer the first two questions. I talked to one of our Product
> Managers who was involved with this JEP and he said that we have
> permission to release these certificates as open source at OpenJDK (much
> as Mozilla has roots in Firefox).  Therefore there should be no concerns
> using with OpenJDK 8 or other versions for that matter.  If you mean the
> jdk8u project specifically, you should check with the current
> maintainers for interest in this as I think they currently use other
> means for their builds.
>
> --Sean
>
> >
> > Just trying to start a discussion? ??
> >
> > Best regards
> > Christoph
> >
> > [0] http://openjdk.java.net/jeps/319
> > [1] https://bugs.openjdk.java.net/browse/JDK-8189131
> >
>
>

From christoph.langer at sap.com  Mon Mar 25 22:59:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Mar 2019 22:59:21 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
Message-ID: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

I was wondering, whether we want to tag a new build in jdk8u and merge back to jdk8u-dev, similar as Goetz is doing with jdk11u?

JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK-8189761 is approved but I don't see a review thread... Do we maybe want to wait for JDK-8189761? What's the outlook for that one?

Best regards
Christoph


From gnu.andrew at redhat.com  Tue Mar 26 01:59:06 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 26 Mar 2019 01:59:06 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, 
 but no configure flag
Message-ID: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8189761
Webrev(s):
https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot/
https://cr.openjdk.java.net/~andrew/openjdk8/8189761/jdk/
https://cr.openjdk.java.net/~andrew/openjdk8/8189761/root/

This backport is largely clean, bar fuzzing, for the JDK and root
repositories, but needs changes in the HotSpot repository to account for
the older build used in OpenJDK 8 and below. In 8, the HotSpot build is
largely independent of the main configure-based build and so
occasionally duplicates top-level logic.

I've tested this works on GNU/Linux. Due to the different platforms
affected, ideally someone should test this on other platforms,
particularly Windows, to avoid breakage there.
-- 
Andrew :)

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

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


From christoph.langer at sap.com  Tue Mar 26 08:09:42 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Mar 2019 08:09:42 +0000
Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633
In-Reply-To: <ef95c006-6910-46e3-999b-e3af9a035f6b@default>
References: <627764ae-9c68-4113-920b-f1010086e8c7@default>
 <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com>
 <dfc51c6b-1591-410e-b25d-e5bdfb21e427@default>
 <7afc386a-11ac-403c-a6ec-0d7988604818@default>
 <HE1PR0201MB226683A8A4B6055474D0EF828A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <94b978d4-aabc-4551-8229-3b8a71d37d5f@default>
 <ef95c006-6910-46e3-999b-e3af9a035f6b@default>
Message-ID: <HE1PR0201MB226611F2BEAA6F34D10048548A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Deepak,

> Thanks for review. I think Naoto and Ramanand are right, we do update the
> copyright year when it is not a clean backport. Please find the updated
> version of webrev.
> 
> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/

Ok, you are right... Still wondering, whether in the test the copyright year should be 2012, 2019, since it is very much derived from the upstream version. But in the end, I don't want to bikeshed. All good for me ??

Thanks
Christoph


From gaetan.njinang at gmail.com  Tue Mar 26 11:22:29 2019
From: gaetan.njinang at gmail.com (Gaetan Njinang)
Date: Tue, 26 Mar 2019 12:22:29 +0100
Subject: Add the support of the TLS signature RSASSA-PSS
Message-ID: <CACLFop0ODFAgQg6rK42_OXhAnTmASFGaQ=BxGc9gSa1RiHK8cw@mail.gmail.com>

Hello all,

We have a new PKI in my company and certificates generated with it are
signed with the certificate RSASSA-PSS. This signature is not recognized by
several projects using the jdk8. Is there a plan to upgrade the jdk to
support this project ?

Thanks,

From sgehwolf at redhat.com  Tue Mar 26 11:37:14 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 26 Mar 2019 12:37:14 +0100
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR,  but no configure flag
In-Reply-To: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
Message-ID: <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>

Hi Andrew,

On Tue, 2019-03-26 at 01:59 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189761
> Webrev(s):
> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot/

 105 CXXFLAGS/vm_version.o += ${JRE_VERSION}
 106 CXXFLAGS/arguments.o += ${VERSION_CFLAGS}

This got me curious why VERSION_CFLAGS would only be needed for
arguments.o. This hunk:

+ifneq ($(COMPANY_NAME),)
+  # COMPANY_NAME is set to "N/A" in $AUTOCONF_DIR/version-numbers by default,
+  # but can be customized with the '--with-vendor-name' configure option.
+  # Only export "VENDOR" to the build if COMPANY_NAME contains a real value.
+  # Otherwise the default value for VENDOR, which is used to set the "java.vendor"
+  # and "java.vm.vendor" properties is hard-coded into the source code (i.e. in
+  # System.c in the jdk for "vm.vendor" and vm_version.cpp in the VM for "java.vm.vendor")
+  ifneq ($(COMPANY_NAME), N/A)
+    VERSION_CFLAGS += -DVENDOR='"$(COMPANY_NAME)"'
+  endif
+endif

... mentions System.c (jdk) and vm_version.cpp (hotspot). Indeed,
java.vm.vendor doesn't change when --with-vendor-name="Red Hat Inc." is
being passed for a patched JDK 8u:

$ ./bin/java -XshowSettings -version 2>&1 | grep vendor
    java.specification.vendor = Oracle Corporation
    java.vendor = Red Hat Inc.
    java.vendor.url = http://java.oracle.com/
    java.vendor.url.bug = http://bugreport.sun.com/bugreport/
    java.vm.specification.vendor = Oracle Corporation
    java.vm.vendor = Oracle Corporation

That's different from a JDK 11u build:

$ ./bin/java -XshowSettings -version 2>&1 | grep vendor

bin/java -XshowSettings -version 2>&1 | grep vendor
    java.specification.vendor = Oracle Corporation
    java.vendor = Red Hat Inc.
    java.vendor.url = http://java.oracle.com/
    java.vendor.url.bug = http://bugreport.java.com/bugreport/
    java.vendor.version = 18.9
    java.vm.specification.vendor = Oracle Corporation
    java.vm.vendor = Red Hat Inc.

This should fix it:

CXXFLAGS/vm_version.o += ${JRE_VERSION} ${VERSION_CFLAGS}

Thanks,
Severin


From christoph.langer at sap.com  Tue Mar 26 21:57:54 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Mar 2019 21:57:54 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR,  but no configure flag
In-Reply-To: <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
Message-ID: <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

thanks for doing this backport. I agree, Severin's finding needs to be added to hotspot's Unix/Posix vm.make files.

Also, the additional printing of those variables in the Unixish buildtree.make files should be added to windows' make/windows/build.make in target $(variantDir)\local.make.

Other than that, I'm running a build on Windows and it looks good.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 26. M?rz 2019 12:37
> To: Andrew John Hughes <gnu.andrew at redhat.com>; 'jdk8u-
> dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>; build-
> dev at openjdk.java.net
> Subject: Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR,
> BUNDLE_VENDOR, VENDOR, but no configure flag
> 
> Hi Andrew,
> 
> On Tue, 2019-03-26 at 01:59 +0000, Andrew John Hughes wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189761
> > Webrev(s):
> > https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot/
> 
>  105 CXXFLAGS/vm_version.o += ${JRE_VERSION}
>  106 CXXFLAGS/arguments.o += ${VERSION_CFLAGS}
> 
> This got me curious why VERSION_CFLAGS would only be needed for
> arguments.o. This hunk:
> 
> +ifneq ($(COMPANY_NAME),)
> +  # COMPANY_NAME is set to "N/A" in $AUTOCONF_DIR/version-numbers
> by default,
> +  # but can be customized with the '--with-vendor-name' configure option.
> +  # Only export "VENDOR" to the build if COMPANY_NAME contains a real
> value.
> +  # Otherwise the default value for VENDOR, which is used to set the
> "java.vendor"
> +  # and "java.vm.vendor" properties is hard-coded into the source code (i.e.
> in
> +  # System.c in the jdk for "vm.vendor" and vm_version.cpp in the VM for
> "java.vm.vendor")
> +  ifneq ($(COMPANY_NAME), N/A)
> +    VERSION_CFLAGS += -DVENDOR='"$(COMPANY_NAME)"'
> +  endif
> +endif
> 
> ... mentions System.c (jdk) and vm_version.cpp (hotspot). Indeed,
> java.vm.vendor doesn't change when --with-vendor-name="Red Hat Inc." is
> being passed for a patched JDK 8u:
> 
> $ ./bin/java -XshowSettings -version 2>&1 | grep vendor
>     java.specification.vendor = Oracle Corporation
>     java.vendor = Red Hat Inc.
>     java.vendor.url = http://java.oracle.com/
>     java.vendor.url.bug = http://bugreport.sun.com/bugreport/
>     java.vm.specification.vendor = Oracle Corporation
>     java.vm.vendor = Oracle Corporation
> 
> That's different from a JDK 11u build:
> 
> $ ./bin/java -XshowSettings -version 2>&1 | grep vendor
> 
> bin/java -XshowSettings -version 2>&1 | grep vendor
>     java.specification.vendor = Oracle Corporation
>     java.vendor = Red Hat Inc.
>     java.vendor.url = http://java.oracle.com/
>     java.vendor.url.bug = http://bugreport.java.com/bugreport/
>     java.vendor.version = 18.9
>     java.vm.specification.vendor = Oracle Corporation
>     java.vm.vendor = Red Hat Inc.
> 
> This should fix it:
> 
> CXXFLAGS/vm_version.o += ${JRE_VERSION} ${VERSION_CFLAGS}
> 
> Thanks,
> Severin


From guangyu.zhu at aliyun.com  Wed Mar 27 03:12:26 2019
From: guangyu.zhu at aliyun.com (guangyu.zhu)
Date: Wed, 27 Mar 2019 11:12:26 +0800
Subject: =?UTF-8?B?UmU6IFtQcmVsaW1pbmFyeSBSZXZpZXddOiBQcm9wb3NhbCBmb3IgYmFjay1wb3J0aW5nIEpG?=
 =?UTF-8?B?UiB0byBPcGVuSkRLOHU=?=
In-Reply-To: <888e4706-18ac-4e5d-b75c-7143cba17caa.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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
 <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>
 <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@azul.com>
 <dccc6efb-5372-442f-9cf5-66a3a1df9ef4.guangyu.zhu@aliyun.com>,
 <9114E7B2-1EC7-4095-A19D-4D1ED7F46879@azul.com>,
 <888e4706-18ac-4e5d-b75c-7143cba17caa.guangyu.zhu@aliyun.com>
Message-ID: <657a36a7-3c14-4274-a294-4c4ae9c0b8bf.guangyu.zhu@aliyun.com>

Hi Andrey,

We have fixed the crash in thread sampling and finished the g1 heap summary porting. See webrev:
http://cr.openjdk.java.net/~luchsh/jfr_cr/

The crash fix is very small, one line is missing when porting from jdk11.
--- old/src/share/vm/classfile/javaClasses.cpp  2019-03-25 19:20:33.985861477 +0800
+++ new/src/share/vm/classfile/javaClasses.cpp  2019-03-25 19:20:33.824866124 +0800
@@ -1047,7 +1047,10 @@

 // Read thread status value from threadStatus field in java.lang.Thread java class.
 java_lang_Thread::ThreadStatus java_lang_Thread::get_thread_status(oop java_thread) {
-  assert(Thread::current()->is_Watcher_thread() || Thread::current()->is_VM_thread() ||
+  assert(Threads_lock->owned_by_self() || Thread::current()->is_Watcher_thread() ||
+         Thread::current()->is_VM_thread() ||
          JavaThread::current()->thread_state() == _thread_in_vm,
          "Java Thread is not running in vm");

Thanks,
Guangyu
------------------------------------------------------------------
Sender:guangyu.zhu <guangyu.zhu at aliyun.com>
Sent At:2019 Mar. 21 (Thu.) 16:30
Recipient:Andrey Petushkov <andrey at azul.com>
Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net>; Ekaterina Vergizova <katya at azul.com>; denghui.ddh <denghui.ddh at antfin.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Hi Andrey,

Thank you for pointing out. I ran the jtreg tests on the release build, but didn't run on the debug version, so the bug was hidden. With Alibaba's codebase, I can't reproduce this bug. Maybe I missed some code when doing the merge. Let me check.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Andrey Petushkov <andrey at azul.com>
Sent At:2019 Mar. 20 (Wed.) 01:18
Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>; Ekaterina Vergizova <katya at azul.com>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

Hi Guangyu,

We have found that your thread sampling implementation causes VM crashes. E.g. test jdk/jfr/cmd/TestPrintDefault could be used to
reproduce it (we've found 29 JFR tests in total which exhibit this problem).
On debug build this manifests as:

#  Internal Error (/home/andrey/ws/zulu8-emb-dev/hotspot/src/share/vm/runtime/thread.hpp:1789), pid=25987, tid=0x00007fffc0be1700
#  assert(thread != NULL && thread->is_Java_thread()) failed: just checking

with thread list like this:

Java Threads: ( => current thread )
  0x00007fff8c001800 JavaThread "JFR Recording Scheduler" daemon [_thread_blocked, id=26020, stack(0x00007fffc09e0000,0x00007fffc0ae1000)]
  0x00007fff942f0000 JavaThread "JFR Periodic Tasks" daemon [_thread_blocked, id=26018, stack(0x00007fffc0be2000,0x00007fffc0ce3000)]
  0x00007fff9420f800 JavaThread "JFR Recorder Thread" daemon [_thread_blocked, id=26017, stack(0x00007fffc0f4b000,0x00007fffc104c000)]
  0x00007ffff0205800 JavaThread "MainThread" [_thread_in_Java, id=26013, stack(0x00007fffc229a000,0x00007fffc239b000)]
  0x00007ffff0190800 JavaThread "Service Thread" daemon [_thread_blocked, id=26011, stack(0x00007fffc255b000,0x00007fffc265c000)]
  0x00007ffff017c000 JavaThread "C1 CompilerThread2" daemon [_thread_in_native, id=26010, stack(0x00007fffc265c000,0x00007fffc275d000)]
  0x00007ffff017a000 JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26009, stack(0x00007fffc275d000,0x00007fffc285e000)]
  0x00007ffff0176800 JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=26008, stack(0x00007fffc285e000,0x00007fffc295f000)]
  0x00007ffff0173000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=26007, stack(0x00007fffc295f000,0x00007fffc2a60000)]
  0x00007ffff0122800 JavaThread "Finalizer" daemon [_thread_blocked, id=26006, stack(0x00007fffc2d38000,0x00007fffc2e39000)]
  0x00007ffff011d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=26005, stack(0x00007fffc2e39000,0x00007fffc2f3a000)]
  0x00007ffff000f800 JavaThread "main" [_thread_blocked, id=25997, stack(0x00007ffff7eda000,0x00007ffff7fdb000)]

Other Threads:
  0x00007ffff010e000 VMThread [stack: 0x00007fffc2f3a000,0x00007fffc303b000] [id=26004]
  0x00007ffff018e000 WatcherThread [stack: 0x00007fffc245a000,0x00007fffc255b000] [id=26012]

=>0x00007fff942e5000 (exited) Thread [stack: 0x00007fffc0ae1000,0x00007fffc0be2000] [id=26021]

Looks like if thread exits during JFR thread sampling the latter still tries to traverse it. Which is, well, not something to be done on that stage
Would you be able to check the issue, please?

Thank you,
Andrey

> On 18 Mar 2019, at 04:18, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> ok, we will update the patch based on your comments.
> 
> Thanks,
> Guangyu
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Mar. 15 (Fri.) 21:44
> Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Guangyu,
> 
> The G1 heap region type reporting looks good to me as well. Thanks a lot for doing it!
> 
> Regards,
> Andrey
> 
> > On 14 Mar 2019, at 14:44, Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Hi Guangyu,
> >
> > By the moment I've read first two patches (thread sampling and biased locks). These look good to me
> > One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it
> >
> > I need a bit more time to read through G1 heap region types one.
> > BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please
> >
> > Thanks a lot,
> > Andrey
> >
> >> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >>
> >> Ok. I look forward to the feedbacks from both of you.
> >>
> >> Thanks,
> >> Guangyu
> >> ------------------------------------------------------------------
> >> Sender:Mario Torre <neugens.limasoftware at gmail.com>
> >> Sent At:2019 Mar. 13 (Wed.) 19:26
> >> Recipient:Andrey Petushkov <andrey at azul.com>
> >> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> >> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >>
> >> Thanks!
> >>
> >> I?m currently traveling but I?ll offer my review as soon as I get back next week.
> >>
> >> Cheers,
> >> Mario
> >> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
> >> Hi Guangyu,
> >>
> >> Cool! Thank you so much! Will review changes ASAP
> >> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
> >> April update release (mostly limited by testing resources capacity)
> >>
> >> Regards,
> >> Andrey
> >>
> >>> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >>>
> >>> Hi Andrey, Mario
> >>>
> >>> Is there any progress in backporting? We have completed the patch for the missing features. Please review.
> >>>
> >>> - thread sampling:
> >>> http://cr.openjdk.java.net/~luchsh/thread_sampling/
> >>>
> >>> - biased locking events:
> >>> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> >>> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> >>>
> >>> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
> >>> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> >>>
> >>> Thanks,
> >>> Guangyu
> >>>
> >>>
> >>> ------------------------------------------------------------------
> >>> Sender:Andrey Petushkov <andrey at azul.com>
> >>> Sent At:2019 Mar. 6 (Wed.) 00:34
> >>> Recipient:Mario Torre <neugens at redhat.com>
> >>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> >>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >>>
> >>> Hi Mario,
> >>>
> >>>> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> >>>>
> >>>> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> >>>>
> >>>>>> I'm going through the patch right now, but yes, from what I see the
> >>>>>> trace is removed. I had too a concern about this and was about to send
> >>>>>> a note. I'm not quite sure what to do, because Trace has been removed
> >>>>>> in 11 as far as I know, but removing mid stream in 8 may be a more
> >>>>>> interesting issue, however this isn't a user facing API, it was always
> >>>>>> meant to be internal to the JVM, so I don't quite know if there's
> >>>>>> really a reason we shouldn't change it. This is one question for the
> >>>>>> CSR group I think.
> >>>>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> >>>>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> >>>>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> >>>>> I will be happy to return it back
> >>>>
> >>>> Yes, I tend to agree with you, I do believe this is mostly an internal
> >>>> API for easy of patching with the JFR code (which is almost
> >>>> identical). The only concern is in the way the logging would be
> >>>> triggered externally and the compile time options for it (I still see
> >>>> a couple of instance where INCLUDE_TRACE is being used). As for
> >>>> triggering the logs, I don't recall that 8 has any means of doing
> >>>> this, I think some infrastructure came with 9 with the -Xlog option (I
> >>>> didn't follow this however, I'm not sure the option ever landed in 9)?
> >>>> In that case I guess it's safe to go after all.
> >>> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
> >>> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
> >>> IMHO we should get rid of all of them, but cannot tell for sure now
> >>>
> >>> Andrey
> >>>>
> >>>> 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 Mar 27 15:03:53 2019
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 27 Mar 2019 15:03:53 +0000
Subject: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
In-Reply-To: <657a36a7-3c14-4274-a294-4c4ae9c0b8bf.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>
 <de8953dd6dbd99f5b0872f3056871d09bdb2e880.camel@redhat.com>
 <fa4f227c-1d49-4cd1-8dd8-e9f0f1f11ead.guangyu.zhu@aliyun.com>
 <CAJwKKmZjZf6Wa6r9mSYwow4rhQhBUpCEYaS8NBdofn6V_kxtdQ@mail.gmail.com>
 <470BA8E8-4A89-4207-96C3-91723643986E@azul.com>
 <CAJwKKmZvKcr-Q9biHEVqgCWVhLdhmr6in9Hbj7frJKU_cNW8BQ@mail.gmail.com>
 <A5C59E01-C7C5-4D97-9784-E9D56D63D42E@azul.com>
 <bf80f850-38f5-40a7-a4b8-d729b2cffcca.guangyu.zhu@aliyun.com>
 <9993E0D1-2583-4A33-AFE7-DDED438AE79C@azul.com>
 <CAGUMyaQ4=mUSgDcOPvrEGja_7c-9UzT32DDYs6XKoKCOMiSW-g@mail.gmail.com>
 <0ad5650b-6534-411b-a066-3d49b336bc14.guangyu.zhu@aliyun.com>
 <2B339EB1-87F2-4120-B778-81A760CC55C6@azul.com>
 <94A0B90C-FC36-4BCC-AA40-234E2EC561B0@azul.com>
 <dccc6efb-5372-442f-9cf5-66a3a1df9ef4.guangyu.zhu@aliyun.com>
 <9114E7B2-1EC7-4095-A19D-4D1ED7F46879@azul.com>
 <888e4706-18ac-4e5d-b75c-7143cba17caa. guangyu.zhu@aliyun.com>
 <657a36a7-3c14-4274-a294-4c4ae9c0b8bf.guangyu.zhu@aliyun.com>
Message-ID: <1452E545-3346-4053-8A42-F97781186298@azul.com>

Dear Guangyu,

Thank you very much for the fix. I've ran a few tests, including all those failed earlier, on linux x86 and don't see problem anymore. So I believe we should consider problem fixed. We'll run more tests in next few days, will let you know if we find anything

Regards,
Andrey

> On 27 Mar 2019, at 06:12, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> 
> Hi Andrey,
> 
> We have fixed the crash in thread sampling and finished the g1 heap summary porting. See webrev:
> http://cr.openjdk.java.net/~luchsh/jfr_cr/
> 
> The crash fix is very small, one line is missing when porting from jdk11.
> --- old/src/share/vm/classfile/javaClasses.cpp  2019-03-25 19:20:33.985861477 +0800
> +++ new/src/share/vm/classfile/javaClasses.cpp  2019-03-25 19:20:33.824866124 +0800
> @@ -1047,7 +1047,10 @@
> 
>  // Read thread status value from threadStatus field in java.lang.Thread java class.
>  java_lang_Thread::ThreadStatus java_lang_Thread::get_thread_status(oop java_thread) {
> -  assert(Thread::current()->is_Watcher_thread() || Thread::current()->is_VM_thread() ||
> +  assert(Threads_lock->owned_by_self() || Thread::current()->is_Watcher_thread() ||
> +         Thread::current()->is_VM_thread() ||
>           JavaThread::current()->thread_state() == _thread_in_vm,
>           "Java Thread is not running in vm");
> 
> Thanks,
> Guangyu
> ------------------------------------------------------------------
> Sender:guangyu.zhu <guangyu.zhu at aliyun.com>
> Sent At:2019 Mar. 21 (Thu.) 16:30
> Recipient:Andrey Petushkov <andrey at azul.com>
> Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net>; Ekaterina Vergizova <katya at azul.com>; denghui.ddh <denghui.ddh at antfin.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Andrey,
> 
> Thank you for pointing out. I ran the jtreg tests on the release build, but didn't run on the debug version, so the bug was hidden. With Alibaba's codebase, I can't reproduce this bug. Maybe I missed some code when doing the merge. Let me check.
> 
> Thanks,
> Guangyu
> ------------------------------------------------------------------
> Sender:Andrey Petushkov <andrey at azul.com>
> Sent At:2019 Mar. 20 (Wed.) 01:18
> Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>; Ekaterina Vergizova <katya at azul.com>
> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> 
> Hi Guangyu,
> 
> We have found that your thread sampling implementation causes VM crashes. E.g. test jdk/jfr/cmd/TestPrintDefault could be used to
> reproduce it (we've found 29 JFR tests in total which exhibit this problem).
> On debug build this manifests as:
> 
> #  Internal Error (/home/andrey/ws/zulu8-emb-dev/hotspot/src/share/vm/runtime/thread.hpp:1789), pid=25987, tid=0x00007fffc0be1700
> #  assert(thread != NULL && thread->is_Java_thread()) failed: just checking
> 
> with thread list like this:
> 
> Java Threads: ( => current thread )
>   0x00007fff8c001800 JavaThread "JFR Recording Scheduler" daemon [_thread_blocked, id=26020, stack(0x00007fffc09e0000,0x00007fffc0ae1000)]
>   0x00007fff942f0000 JavaThread "JFR Periodic Tasks" daemon [_thread_blocked, id=26018, stack(0x00007fffc0be2000,0x00007fffc0ce3000)]
>   0x00007fff9420f800 JavaThread "JFR Recorder Thread" daemon [_thread_blocked, id=26017, stack(0x00007fffc0f4b000,0x00007fffc104c000)]
>   0x00007ffff0205800 JavaThread "MainThread" [_thread_in_Java, id=26013, stack(0x00007fffc229a000,0x00007fffc239b000)]
>   0x00007ffff0190800 JavaThread "Service Thread" daemon [_thread_blocked, id=26011, stack(0x00007fffc255b000,0x00007fffc265c000)]
>   0x00007ffff017c000 JavaThread "C1 CompilerThread2" daemon [_thread_in_native, id=26010, stack(0x00007fffc265c000,0x00007fffc275d000)]
>   0x00007ffff017a000 JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26009, stack(0x00007fffc275d000,0x00007fffc285e000)]
>   0x00007ffff0176800 JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=26008, stack(0x00007fffc285e000,0x00007fffc295f000)]
>   0x00007ffff0173000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=26007, stack(0x00007fffc295f000,0x00007fffc2a60000)]
>   0x00007ffff0122800 JavaThread "Finalizer" daemon [_thread_blocked, id=26006, stack(0x00007fffc2d38000,0x00007fffc2e39000)]
>   0x00007ffff011d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=26005, stack(0x00007fffc2e39000,0x00007fffc2f3a000)]
>   0x00007ffff000f800 JavaThread "main" [_thread_blocked, id=25997, stack(0x00007ffff7eda000,0x00007ffff7fdb000)]
> 
> Other Threads:
>   0x00007ffff010e000 VMThread [stack: 0x00007fffc2f3a000,0x00007fffc303b000] [id=26004]
>   0x00007ffff018e000 WatcherThread [stack: 0x00007fffc245a000,0x00007fffc255b000] [id=26012]
> 
> =>0x00007fff942e5000 (exited) Thread [stack: 0x00007fffc0ae1000,0x00007fffc0be2000] [id=26021]
> 
> Looks like if thread exits during JFR thread sampling the latter still tries to traverse it. Which is, well, not something to be done on that stage
> Would you be able to check the issue, please?
> 
> Thank you,
> Andrey
> 
> > On 18 Mar 2019, at 04:18, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >
> > ok, we will update the patch based on your comments.
> >
> > Thanks,
> > Guangyu
> > ------------------------------------------------------------------
> > Sender:Andrey Petushkov <andrey at azul.com>
> > Sent At:2019 Mar. 15 (Fri.) 21:44
> > Recipient:guangyu.zhu <guangyu.zhu at aliyun.com>
> > Cc:Mario Torre <neugens.limasoftware at gmail.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> > Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> >
> > Hi Guangyu,
> >
> > The G1 heap region type reporting looks good to me as well. Thanks a lot for doing it!
> >
> > Regards,
> > Andrey
> >
> > > On 14 Mar 2019, at 14:44, Andrey Petushkov <andrey at azul.com> wrote:
> > >
> > > Hi Guangyu,
> > >
> > > By the moment I've read first two patches (thread sampling and biased locks). These look good to me
> > > One very small note, I'd rather be verbose with the value of _trace_flag in thread.hpp. Just to prevent occasional use of the same value for another item of this enum in the (almost impossible) case that someone adds it
> > >
> > > I need a bit more time to read through G1 heap region types one.
> > > BTW, it looks I've forgotten to mention that Azul is also missing G1 heap occupancy percent data which is indeed supported by Alibaba. Would you be able to integrate it also, please
> > >
> > > Thanks a lot,
> > > Andrey
> > >
> > >> On 14 Mar 2019, at 05:39, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> > >>
> > >> Ok. I look forward to the feedbacks from both of you.
> > >>
> > >> Thanks,
> > >> Guangyu
> > >> ------------------------------------------------------------------
> > >> Sender:Mario Torre <neugens.limasoftware at gmail.com>
> > >> Sent At:2019 Mar. 13 (Wed.) 19:26
> > >> Recipient:Andrey Petushkov <andrey at azul.com>
> > >> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> > >> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> > >>
> > >> Thanks!
> > >>
> > >> I?m currently traveling but I?ll offer my review as soon as I get back next week.
> > >>
> > >> Cheers,
> > >> Mario
> > >> On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:
> > >> Hi Guangyu,
> > >>
> > >> Cool! Thank you so much! Will review changes ASAP
> > >> The backporting is still in progress. There are quite a lot of changes to consider so we'll likely finish some time after
> > >> April update release (mostly limited by testing resources capacity)
> > >>
> > >> Regards,
> > >> Andrey
> > >>
> > >>> On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> > >>>
> > >>> Hi Andrey, Mario
> > >>>
> > >>> Is there any progress in backporting? We have completed the patch for the missing features. Please review.
> > >>>
> > >>> - thread sampling:
> > >>> http://cr.openjdk.java.net/~luchsh/thread_sampling/
> > >>>
> > >>> - biased locking events:
> > >>> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> > >>> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> > >>>
> > >>> - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
> > >>> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> > >>>
> > >>> Thanks,
> > >>> Guangyu
> > >>>
> > >>>
> > >>> ------------------------------------------------------------------
> > >>> Sender:Andrey Petushkov <andrey at azul.com>
> > >>> Sent At:2019 Mar. 6 (Wed.) 00:34
> > >>> Recipient:Mario Torre <neugens at redhat.com>
> > >>> Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> > >>> Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
> > >>>
> > >>> Hi Mario,
> > >>>
> > >>>> On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> > >>>>
> > >>>> On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com> wrote:
> > >>>>
> > >>>>>> I'm going through the patch right now, but yes, from what I see the
> > >>>>>> trace is removed. I had too a concern about this and was about to send
> > >>>>>> a note. I'm not quite sure what to do, because Trace has been removed
> > >>>>>> in 11 as far as I know, but removing mid stream in 8 may be a more
> > >>>>>> interesting issue, however this isn't a user facing API, it was always
> > >>>>>> meant to be internal to the JVM, so I don't quite know if there's
> > >>>>>> really a reason we shouldn't change it. This is one question for the
> > >>>>>> CSR group I think.
> > >>>>> Since trace was removed by the same commit as JFR was added to jdk11 my guess is that trace
> > >>>>> was used internally at Oracle to integrate closed implementation of JFR. With this sense I see no point
> > >>>>> to keep it. However if the guess is wrong and there some alternative implementation of trace event consumer
> > >>>>> I will be happy to return it back
> > >>>>
> > >>>> Yes, I tend to agree with you, I do believe this is mostly an internal
> > >>>> API for easy of patching with the JFR code (which is almost
> > >>>> identical). The only concern is in the way the logging would be
> > >>>> triggered externally and the compile time options for it (I still see
> > >>>> a couple of instance where INCLUDE_TRACE is being used). As for
> > >>>> triggering the logs, I don't recall that 8 has any means of doing
> > >>>> this, I think some infrastructure came with 9 with the -Xlog option (I
> > >>>> didn't follow this however, I'm not sure the option ever landed in 9)?
> > >>>> In that case I guess it's safe to go after all.
> > >>> Right, the new logging infrastructure is badly missing here. Both Alibaba and Azul have added means of
> > >>> some JFR logging but far from what jdk11 could do. Let me check the rest of INCLUDE_TRACE places,
> > >>> IMHO we should get rid of all of them, but cannot tell for sure now
> > >>>
> > >>> Andrey
> > >>>>
> > >>>> 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 Mar 27 15:42:29 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 27 Mar 2019 15:42:29 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
In-Reply-To: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>

On 25/03/2019 22:59, Langer, Christoph wrote:
> Hi,
> 
> ?
> 
> I was wondering, whether we want to tag a new build in jdk8u and merge
> back to jdk8u-dev, similar as Goetz is doing with jdk11u?
> 
> ?
> 
> JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK-8189761 is
> approved but I don?t see a review thread? Do we maybe want to wait for
> JDK-8189761? What?s the outlook for that one?
> 
> ?
> 
> Best regards
> 
> Christoph
> 
> ?
> 

As you'll have seen, 8189761 was posted a few hours after your e-mail.
My thinking was that we'd tag -b02 once these three pending ones were in.

Given it's the 1st on Monday, I'd expect that to be the freeze point. I
don't see any other critical fixes waiting for approval. There is a
further update coming from Oracle with the final Japanese epoch, I
believe, but I can bring that in with the security fixes if need be.
-- 
Andrew :)

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

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


From hohensee at amazon.com  Wed Mar 27 18:49:52 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 27 Mar 2019 18:49:52 +0000
Subject: [8u-dev] RFR (S) + RFA: 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
Message-ID: <E402C402-BC6B-4F0D-B519-E8932605425E@amazon.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8207760
Webrev for jaxp: http://cr.openjdk.java.net/~phh/8207760/webrev.8u.jaxp.00/
Webrev for jdk: http://cr.openjdk.java.net/~phh/8207760/webrev.8u.jdk.00/

The jaxp patch applies cleanly net of line numbers. The jdk patch is to a jtreg test that I modified slightly to run on 8u, which modification needs review. The diff for that test against jdk tip is http://cr.openjdk.java.net/~phh/8207760/JDK8207760.java.diff.

Thanks,

Paul


From gnu.andrew at redhat.com  Thu Mar 28 02:58:48 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Mar 2019 02:58:48 +0000
Subject: Result: New OpenJDK 8u Reviewer: Christoph Langer
Message-ID: <2fa66d86-7583-9bcf-bd30-b556a59a8cd1@redhat.com>

Voting for Christoph Langer [0] is now closed.

Yes: 5
Veto: 0
Abstain: 0

Turnout: 5.2% (5/97)

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-March/008906.html
[1] http://openjdk.java.net/bylaws#three-vote-consensus
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Mar 28 02:59:35 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Mar 2019 02:59:35 +0000
Subject: [8u-dev] RFR (S) + RFA: 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <E402C402-BC6B-4F0D-B519-E8932605425E@amazon.com>
References: <E402C402-BC6B-4F0D-B519-E8932605425E@amazon.com>
Message-ID: <e1aa550b-b55c-82ce-bf4f-96c0f26fa536@redhat.com>



On 27/03/2019 18:49, Hohensee, Paul wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8207760
> Webrev for jaxp: http://cr.openjdk.java.net/~phh/8207760/webrev.8u.jaxp.00/
> Webrev for jdk: http://cr.openjdk.java.net/~phh/8207760/webrev.8u.jdk.00/
> 
> The jaxp patch applies cleanly net of line numbers. The jdk patch is to a jtreg test that I modified slightly to run on 8u, which modification needs review. The diff for that test against jdk tip is http://cr.openjdk.java.net/~phh/8207760/JDK8207760.java.diff.
> 
> Thanks,
> 
> Paul
> 

Looks good to me. Thanks for clarifying the test changes.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Mar 28 03:56:51 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Mar 2019 03:56:51 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>

On 26/03/2019 21:57, Langer, Christoph wrote:
> Hi Andrew,
> 
> thanks for doing this backport. I agree, Severin's finding needs to be added to hotspot's Unix/Posix vm.make files.

Yes, it was missed because it's already there prior to this patch in the
9 and up HotSpot build which is quite different. It also seems to
require a change to vm_version.cpp so the value isn't double-quoted.

> 
> Also, the additional printing of those variables in the Unixish buildtree.make files should be added to windows' make/windows/build.make in target $(variantDir)\local.make.

Ah, I was looking for the equivalent but it's odd that it's not in
make/windows, and so didn't show up with grep.

Revised HotSpot webrev:

https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
-- 
Andrew :)

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

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


From sgehwolf at redhat.com  Thu Mar 28 08:51:22 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 28 Mar 2019 09:51:22 +0100
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
Message-ID: <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>

On Thu, 2019-03-28 at 03:56 +0000, Andrew John Hughes wrote:
> On 26/03/2019 21:57, Langer, Christoph wrote:
> > Hi Andrew,
> > 
> > thanks for doing this backport. I agree, Severin's finding needs to be added to hotspot's Unix/Posix vm.make files.
> 
> Yes, it was missed because it's already there prior to this patch in the
> 9 and up HotSpot build which is quite different. It also seems to
> require a change to vm_version.cpp so the value isn't double-quoted.

Nice catch! This is JDK-8200115, right? Perhaps we should keep
"XSTR(VENDOR)" in this backport and then also backport JDK-8200115
separately?

> > Also, the additional printing of those variables in the Unixish buildtree.make files should be added to windows' make/windows/build.make in target $(variantDir)\local.make.
> 
> Ah, I was looking for the equivalent but it's odd that it's not in
> make/windows, and so didn't show up with grep.
> 
> Revised HotSpot webrev:
> 
> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02

+++ new/src/share/vm/runtime/vm_version.cpp	2019-03-28 03:52:51.384737947 +0000
@@ -140,7 +140,7 @@
 
 const char* Abstract_VM_Version::vm_vendor() {
 #ifdef VENDOR
-  return XSTR(VENDOR);
+  return VENDOR;

This looks like the change from JDK-8200115. Have you considered
backporting this separately? Failing that, we should mention JDK-
8200115 in the backport commit message as well.

Looks good to me otherwise.

Thanks,
Severin


From christoph.langer at sap.com  Thu Mar 28 09:30:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 28 Mar 2019 09:30:39 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
 <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
Message-ID: <HE1PR0201MB22662B0F11695006C725A2708A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

> > Revised HotSpot webrev:
> >
> > https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
> 
> +++ new/src/share/vm/runtime/vm_version.cpp	2019-03-28
> 03:52:51.384737947 +0000
> @@ -140,7 +140,7 @@
> 
>  const char* Abstract_VM_Version::vm_vendor() {
>  #ifdef VENDOR
> -  return XSTR(VENDOR);
> +  return VENDOR;
> 
> This looks like the change from JDK-8200115. Have you considered
> backporting this separately? Failing that, we should mention JDK-
> 8200115 in the backport commit message as well.

I suggest inlining the backport of 8200115 to this commit by adding "8200115: System property java.vm.vendor value includes quotation marks" to the commit message. It will resolve/backport 8200115 as well. Process wise we should probably tag 8200115 with jdk8u-critcal-request and get it approved, though?

Please also update the copyright years accordingly when pushing.

Thanks & Best regards
Christoph


From christoph.langer at sap.com  Thu Mar 28 11:37:38 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 28 Mar 2019 11:37:38 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
In-Reply-To: <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>
References: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>
Message-ID: <HE1PR0201MB22666F11AA7903295C3385F18A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> > I was wondering, whether we want to tag a new build in jdk8u and merge
> > back to jdk8u-dev, similar as Goetz is doing with jdk11u?
> >
> >
> >
> > JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK-8189761
> is
> > approved but I don't see a review thread... Do we maybe want to wait for
> > JDK-8189761? What's the outlook for that one?
> >
> >
> 
> As you'll have seen, 8189761 was posted a few hours after your e-mail.
> My thinking was that we'd tag -b02 once these three pending ones were in.
> 
> Given it's the 1st on Monday, I'd expect that to be the freeze point. I
> don't see any other critical fixes waiting for approval. There is a
> further update coming from Oracle with the final Japanese epoch, I
> believe, but I can bring that in with the security fixes if need be.

Sounds fair.

So, when I see that 8189761 has landed on or after next Monday, the 1st of April, shall I do tag -b02 and communicate the freeze? Or do you want to do it this time?

Best regards
Christoph


From OGATAK at jp.ibm.com  Thu Mar 28 12:55:37 2019
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Thu, 28 Mar 2019 21:55:37 +0900
Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array
 copy stubs by using vector instructions
Message-ID: <OFC7C8CB5D.F77CC7E7-ON492583CB.004623ED-492583CB.00470A22@notes.na.collabserv.com>

Hi,

May I get review for non-clean backport of 8154156: PPC64: improve array 
copy stubs by using vector instructions?

This is the same change as I posted in January [1], but I updated the 
patch based on the latest jdk8u-dev tree.  As we've had ppc-expert 
reviewers in jdk8u-dev community, I'd like to request for review.

Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e
Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.02/

I confirmed it was buildable for both release and fastdebug builds, and 
JTREG caused no degradation.

Refs: 
[1] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008372.html


Regards,
Ogata




From mark.reinhold at oracle.com  Thu Mar 28 15:16:11 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 28 Mar 2019 08:16:11 -0700
Subject: Result: New OpenJDK 8u Reviewer: Christoph Langer
In-Reply-To: <2fa66d86-7583-9bcf-bd30-b556a59a8cd1@redhat.com>
References: <2fa66d86-7583-9bcf-bd30-b556a59a8cd1@redhat.com>
Message-ID: <20190328081611.768878618@eggemoggin.niobe.net>

2019/3/27 19:58:48 -0700, Andrew John Hughes <gnu.andrew at redhat.com>:
> Voting for Christoph Langer [0] is now closed.
> 
> Yes: 5
> Veto: 0
> Abstain: 0
> 
> Turnout: 5.2% (5/97)
> 
> According to the Bylaws definition of Three-Vote Consensus [1], this is
> sufficient to approve the nomination.

So recorded.

- Mark

From hohensee at amazon.com  Thu Mar 28 19:10:53 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 28 Mar 2019 19:10:53 +0000
Subject: [8u-dev] RFR (S) + RFA: 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <e1aa550b-b55c-82ce-bf4f-96c0f26fa536@redhat.com>
References: <E402C402-BC6B-4F0D-B519-E8932605425E@amazon.com>
 <e1aa550b-b55c-82ce-bf4f-96c0f26fa536@redhat.com>
Message-ID: <7E31E077-82B1-4325-ADD5-E290DA3199B6@amazon.com>

Thanks, Andrew. Pushed.

?On 3/27/19, 8:00 PM, "jdk8u-dev on behalf of Andrew John Hughes" <jdk8u-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    
    
    On 27/03/2019 18:49, Hohensee, Paul wrote:
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8207760
    > Webrev for jaxp: http://cr.openjdk.java.net/~phh/8207760/webrev.8u.jaxp.00/
    > Webrev for jdk: http://cr.openjdk.java.net/~phh/8207760/webrev.8u.jdk.00/
    > 
    > The jaxp patch applies cleanly net of line numbers. The jdk patch is to a jtreg test that I modified slightly to run on 8u, which modification needs review. The diff for that test against jdk tip is http://cr.openjdk.java.net/~phh/8207760/JDK8207760.java.diff.
    > 
    > Thanks,
    > 
    > Paul
    > 
    
    Looks good to me. Thanks for clarifying the test changes.
    
    Thanks,
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew
    
    


From ali.ince at gmail.com  Thu Mar 28 19:47:56 2019
From: ali.ince at gmail.com (Ali Ince)
Date: Thu, 28 Mar 2019 19:47:56 +0000
Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image
Message-ID: <E4AAFF49-DF80-4274-B32A-B3633AC4671F@gmail.com>

Hi All,

We're working on building JDK8U with VS2017 at AdoptOpenJDK and found out that the new vcruntime140.dll is copied to the built image named as `vcrunt~1.dll` which is basically because of the extra call to `BASIC_FIXUP_PATH` call in `toolchain_windows.m4` file. If the call is removed, everything works fine.

On previous versions of VS, the VC runtime DLL was originally named in 8.3 style (ex. msvcr100.dll) and BASIC_FIXUP_PATH did not have any affect on the file name itself. I've checked with `toolchain_windows.m4` files in jdk11u and onwards and also saw that this call doesn't exist.

I've came up with the following patch which removes this call. I'm not sure what's the process about updating the checked-in generated_configure.sh but I could also add the patch for that if it's required.

Let me know if you have any feedback or comments.

Regards,

Ali

---------------------------------------------

diff -r e0b7721459ee common/autoconf/toolchain_windows.m4
--- a/common/autoconf/toolchain_windows.m4    Wed Mar 20 16:32:54 2019 +0000
+++ b/common/autoconf/toolchain_windows.m4    Thu Mar 28 00:03:10 2019 +0000
@@ -493,7 +493,6 @@
     if $ECHO "$MSVC_DLL_FILETYPE" | $GREP "$CORRECT_MSVCR_ARCH" 2>&1 > /dev/null; then
       AC_MSG_RESULT([ok])
       MSVC_DLL="$POSSIBLE_MSVC_DLL"
-      BASIC_FIXUP_PATH(MSVC_DLL)
       AC_MSG_CHECKING([for $DLL_NAME])
       AC_MSG_RESULT([$MSVC_DLL])
     else



From gnu.andrew at redhat.com  Thu Mar 28 23:33:32 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Mar 2019 23:33:32 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
In-Reply-To: <HE1PR0201MB22666F11AA7903295C3385F18A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>
 <HE1PR0201MB22666F11AA7903295C3385F18A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <e1773a7b-b177-54e6-ed43-7e38ec061f2a@redhat.com>



On 28/03/2019 11:37, Langer, Christoph wrote:
> Hi Andrew,
> 
>>> I was wondering, whether we want to tag a new build in jdk8u and merge
>>> back to jdk8u-dev, similar as Goetz is doing with jdk11u?
>>>
>>>
>>>
>>> JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK-8189761
>> is
>>> approved but I don't see a review thread... Do we maybe want to wait for
>>> JDK-8189761? What's the outlook for that one?
>>>
>>>
>>
>> As you'll have seen, 8189761 was posted a few hours after your e-mail.
>> My thinking was that we'd tag -b02 once these three pending ones were in.
>>
>> Given it's the 1st on Monday, I'd expect that to be the freeze point. I
>> don't see any other critical fixes waiting for approval. There is a
>> further update coming from Oracle with the final Japanese epoch, I
>> believe, but I can bring that in with the security fixes if need be.
> 
> Sounds fair.
> 
> So, when I see that 8189761 has landed on or after next Monday, the 1st of April, shall I do tag -b02 and communicate the freeze? Or do you want to do it this time?
> 
> Best regards
> Christoph
> 

I'll let you keep doing the tagging.

I'll announce a freeze separately for both 8u and 11u on the 1st.

Does that sound ok?

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Mar 28 23:49:55 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 28 Mar 2019 23:49:55 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
 <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
Message-ID: <bec638b2-b507-4b7e-f7b1-a0c842366b15@redhat.com>



On 28/03/2019 08:51, Severin Gehwolf wrote:
> On Thu, 2019-03-28 at 03:56 +0000, Andrew John Hughes wrote:
>> On 26/03/2019 21:57, Langer, Christoph wrote:
>>> Hi Andrew,
>>>
>>> thanks for doing this backport. I agree, Severin's finding needs to be added to hotspot's Unix/Posix vm.make files.
>>
>> Yes, it was missed because it's already there prior to this patch in the
>> 9 and up HotSpot build which is quite different. It also seems to
>> require a change to vm_version.cpp so the value isn't double-quoted.
> 
> Nice catch! This is JDK-8200115, right? Perhaps we should keep
> "XSTR(VENDOR)" in this backport and then also backport JDK-8200115
> separately?
> 

I wasn't aware of that bug until you mentioned it. I came up with the
same fix independently. I was looking at the 10 sources - where 8189761
was first applied - which still has XSTR(VENDOR) and I guess still has
this bug.

I've flagged it with jdk8u-fix-request and jdk8u-critical-request.

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

and will move it to a separate webrev.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Fri Mar 29 06:18:28 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 29 Mar 2019 06:18:28 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <HE1PR0201MB22662B0F11695006C725A2708A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
 <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
 <HE1PR0201MB22662B0F11695006C725A2708A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <8c0c0cdb-bf25-9dfe-6a7d-58247a8167fb@redhat.com>



On 28/03/2019 09:30, Langer, Christoph wrote:
> Hi,
> 
>>> Revised HotSpot webrev:
>>>
>>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
>>
>> +++ new/src/share/vm/runtime/vm_version.cpp	2019-03-28
>> 03:52:51.384737947 +0000
>> @@ -140,7 +140,7 @@
>>
>>  const char* Abstract_VM_Version::vm_vendor() {
>>  #ifdef VENDOR
>> -  return XSTR(VENDOR);
>> +  return VENDOR;
>>
>> This looks like the change from JDK-8200115. Have you considered
>> backporting this separately? Failing that, we should mention JDK-
>> 8200115 in the backport commit message as well.
> 
> I suggest inlining the backport of 8200115 to this commit by adding "8200115: System property java.vm.vendor value includes quotation marks" to the commit message. It will resolve/backport 8200115 as well. Process wise we should probably tag 8200115 with jdk8u-critcal-request and get it approved, though?
> 
> Please also update the copyright years accordingly when pushing.
> 
> Thanks & Best regards
> Christoph
> 

Revised version without 8200115 & with copyright updates:

https://cr.openjdk.java.net/~andrew/openjdk8/8189761/webrev.02/

I bumped the existing copyright where the change was from the original
patch. I added our copyright where the changes were unique to this
backport (HotSpot only).
-- 
Andrew :)

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

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


From goetz.lindenmaier at sap.com  Fri Mar 29 06:40:26 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 29 Mar 2019 06:40:26 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
In-Reply-To: <e1773a7b-b177-54e6-ed43-7e38ec061f2a@redhat.com>
References: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>
 <HE1PR0201MB22666F11AA7903295C3385F18A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e1773a7b-b177-54e6-ed43-7e38ec061f2a@redhat.com>
Message-ID: <VI1PR02MB51834D2F3D662D9F8011B030EC5A0@VI1PR02MB5183.eurprd02.prod.outlook.com>

Hi Andrew, 

> I'll announce a freeze separately for both 8u and 11u on the 1st.

I would prefer to fix a tag, not a date.

So I would propose to either state that you freeze on the existing
tag jdk-11.0.3+5, or you announce on the 1st that you will
freeze on tag jdk-11.0.3+6 which I will push on the 3rd.

I think that the second is better because you announce in advance
what you will freeze -- if the 3rd is still in time for you.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew John Hughes
> Sent: Friday, March 29, 2019 12:34 AM
> To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
> dev at openjdk.java.net; 'jdk-updates-dev at openjdk.java.net' <jdk-updates-
> dev at openjdk.java.net>
> Subject: Re: Tag a build in jdk8u and merge to jdk8u-dev?
> 
> 
> 
> On 28/03/2019 11:37, Langer, Christoph wrote:
> > Hi Andrew,
> >
> >>> I was wondering, whether we want to tag a new build in jdk8u and
> merge
> >>> back to jdk8u-dev, similar as Goetz is doing with jdk11u?
> >>>
> >>>
> >>>
> >>> JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK-
> 8189761
> >> is
> >>> approved but I don't see a review thread... Do we maybe want to wait
> for
> >>> JDK-8189761? What's the outlook for that one?
> >>>
> >>>
> >>
> >> As you'll have seen, 8189761 was posted a few hours after your e-mail.
> >> My thinking was that we'd tag -b02 once these three pending ones were
> in.
> >>
> >> Given it's the 1st on Monday, I'd expect that to be the freeze point. I
> >> don't see any other critical fixes waiting for approval. There is a
> >> further update coming from Oracle with the final Japanese epoch, I
> >> believe, but I can bring that in with the security fixes if need be.
> >
> > Sounds fair.
> >
> > So, when I see that 8189761 has landed on or after next Monday, the 1st of
> April, shall I do tag -b02 and communicate the freeze? Or do you want to do it
> this time?
> >
> > Best regards
> > Christoph
> >
> 
> I'll let you keep doing the tagging.
> 
> I'll announce a freeze separately for both 8u and 11u on the 1st.
> 
> Does that sound ok?
> 
> Thanks,
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew


From christoph.langer at sap.com  Fri Mar 29 08:50:53 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 29 Mar 2019 08:50:53 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
In-Reply-To: <e1773a7b-b177-54e6-ed43-7e38ec061f2a@redhat.com>
References: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>
 <HE1PR0201MB22666F11AA7903295C3385F18A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e1773a7b-b177-54e6-ed43-7e38ec061f2a@redhat.com>
Message-ID: <HE1PR0201MB2266ABD1470C42D6FD0568028A5A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> I'll let you keep doing the tagging.
> 
> I'll announce a freeze separately for both 8u and 11u on the 1st.
> 
> Does that sound ok?

Sounds fine for the tagging.

I agree to Goetz' point about announcing the freeze on a tag. So when we've done the tagging in both, jdk11u and jdk8u next week I guess this would be a good candidate for the freeze point.

Best regards
Christoph


From christoph.langer at sap.com  Fri Mar 29 10:51:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 29 Mar 2019 10:51:16 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <8c0c0cdb-bf25-9dfe-6a7d-58247a8167fb@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
 <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
 <HE1PR0201MB22662B0F11695006C725A2708A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8c0c0cdb-bf25-9dfe-6a7d-58247a8167fb@redhat.com>
Message-ID: <HE1PR0201MB22667B6C5B0710761040AE898A5A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Looks good to me now ??

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Freitag, 29. M?rz 2019 07:18
> To: Langer, Christoph <christoph.langer at sap.com>; Severin Gehwolf
> <sgehwolf at redhat.com>; 'jdk8u-dev at openjdk.java.net' <jdk8u-
> dev at openjdk.java.net>; build-dev at openjdk.java.net
> Subject: Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR,
> BUNDLE_VENDOR, VENDOR, but no configure flag
> 
> 
> 
> On 28/03/2019 09:30, Langer, Christoph wrote:
> > Hi,
> >
> >>> Revised HotSpot webrev:
> >>>
> >>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
> >>
> >> +++ new/src/share/vm/runtime/vm_version.cpp	2019-03-28
> >> 03:52:51.384737947 +0000
> >> @@ -140,7 +140,7 @@
> >>
> >>  const char* Abstract_VM_Version::vm_vendor() {
> >>  #ifdef VENDOR
> >> -  return XSTR(VENDOR);
> >> +  return VENDOR;
> >>
> >> This looks like the change from JDK-8200115. Have you considered
> >> backporting this separately? Failing that, we should mention JDK-
> >> 8200115 in the backport commit message as well.
> >
> > I suggest inlining the backport of 8200115 to this commit by adding
> "8200115: System property java.vm.vendor value includes quotation marks"
> to the commit message. It will resolve/backport 8200115 as well. Process
> wise we should probably tag 8200115 with jdk8u-critcal-request and get it
> approved, though?
> >
> > Please also update the copyright years accordingly when pushing.
> >
> > Thanks & Best regards
> > Christoph
> >
> 
> Revised version without 8200115 & with copyright updates:
> 
> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/webrev.02/
> 
> I bumped the existing copyright where the change was from the original
> patch. I added our copyright where the changes were unique to this
> backport (HotSpot only).
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Fri Mar 29 14:15:52 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 29 Mar 2019 14:15:52 +0000
Subject: Tag a build in jdk8u and merge to jdk8u-dev?
In-Reply-To: <VI1PR02MB51834D2F3D662D9F8011B030EC5A0@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22661421C94EF4D2461EC4918A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com>
 <HE1PR0201MB22666F11AA7903295C3385F18A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <e1773a7b-b177-54e6-ed43-7e38ec061f2a@redhat.com>
 <VI1PR02MB51834D2F3D662D9F8011B030EC5A0@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <2f3ea620-a537-c10e-beec-772fe97e6890@redhat.com>

On 29/03/2019 06:40, Lindenmaier, Goetz wrote:
> Hi Andrew, 
> 
>> I'll announce a freeze separately for both 8u and 11u on the 1st.
> 
> I would prefer to fix a tag, not a date.
> 
> So I would propose to either state that you freeze on the existing
> tag jdk-11.0.3+5, or you announce on the 1st that you will
> freeze on tag jdk-11.0.3+6 which I will push on the 3rd.
> 
> I think that the second is better because you announce in advance
> what you will freeze -- if the 3rd is still in time for you.
> 
> Best regards,
>   Goetz.
> 
> 

My intent was a combination of both i.e. that the 1st is the deadline
for changes and, at that time, I announce a freeze on a tag.

In the event that there are changes after that tag, we can decide
whether to re-tag to include them or they have to wait until the next
release. But the idea of stating the deadline early is that there should
ideally not be such changes.

Best regards,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Fri Mar 29 15:00:14 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 29 Mar 2019 15:00:14 +0000
Subject: Handling Backport Changesets
Message-ID: <b09ef682-19b5-99c6-f36c-a8fe97f676d1@redhat.com>

Just a heads up that I've filed:

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

to try and get backporting formally recognised in changesets, in the
same way as Contributed-by.

Hopefully, this will resolve the confusion over who to credit for such
changes.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Fri Mar 29 15:24:02 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 29 Mar 2019 15:24:02 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <HE1PR0201MB22667B6C5B0710761040AE898A5A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
 <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
 <HE1PR0201MB22662B0F11695006C725A2708A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8c0c0cdb-bf25-9dfe-6a7d-58247a8167fb@redhat.com>
 <HE1PR0201MB22667B6C5B0710761040AE898A5A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <7bfeac40-7751-e1fb-ce1e-0ec5ee0d6304@redhat.com>


On 29/03/2019 10:51, Langer, Christoph wrote:
> Looks good to me now ??
> 
>> -----Original Message-----
>> From: Andrew John Hughes <gnu.andrew at redhat.com>
>> Sent: Freitag, 29. M?rz 2019 07:18
>> To: Langer, Christoph <christoph.langer at sap.com>; Severin Gehwolf
>> <sgehwolf at redhat.com>; 'jdk8u-dev at openjdk.java.net' <jdk8u-
>> dev at openjdk.java.net>; build-dev at openjdk.java.net
>> Subject: Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR,
>> BUNDLE_VENDOR, VENDOR, but no configure flag
>>
>>
>>
>> On 28/03/2019 09:30, Langer, Christoph wrote:
>>> Hi,
>>>
>>>>> Revised HotSpot webrev:
>>>>>
>>>>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
>>>>
>>>> +++ new/src/share/vm/runtime/vm_version.cpp	2019-03-28
>>>> 03:52:51.384737947 +0000
>>>> @@ -140,7 +140,7 @@
>>>>
>>>>  const char* Abstract_VM_Version::vm_vendor() {
>>>>  #ifdef VENDOR
>>>> -  return XSTR(VENDOR);
>>>> +  return VENDOR;
>>>>
>>>> This looks like the change from JDK-8200115. Have you considered
>>>> backporting this separately? Failing that, we should mention JDK-
>>>> 8200115 in the backport commit message as well.
>>>
>>> I suggest inlining the backport of 8200115 to this commit by adding
>> "8200115: System property java.vm.vendor value includes quotation marks"
>> to the commit message. It will resolve/backport 8200115 as well. Process
>> wise we should probably tag 8200115 with jdk8u-critcal-request and get it
>> approved, though?
>>>
>>> Please also update the copyright years accordingly when pushing.
>>>
>>> Thanks & Best regards
>>> Christoph
>>>
>>
>> Revised version without 8200115 & with copyright updates:
>>
>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/webrev.02/
>>
>> I bumped the existing copyright where the change was from the original
>> patch. I added our copyright where the changes were unique to this
>> backport (HotSpot only).
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>> https://keybase.io/gnu_andrew
> 

Thanks. I've now pushed both changes.

I committed the HotSpot change under my own name as there was little
from the original changeset. Hopefully, my changeset addition for
formally recognising backports [0] will be accepted to avoid this issue
in future.

[0] https://bugs.openjdk.java.net/browse/JDK-8221692
-- 
Andrew :)

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

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


From christoph.langer at sap.com  Fri Mar 29 16:02:24 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 29 Mar 2019 16:02:24 +0000
Subject: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <7bfeac40-7751-e1fb-ce1e-0ec5ee0d6304@redhat.com>
References: <b10e0c3b-e5d7-7ba4-246f-efe9fe741bc8@redhat.com>
 <e5381d76f21fa6a6bcad9e40be8875f4c4c33a79.camel@redhat.com>
 <HE1PR0201MB2266297749E327429E637B718A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8bfd5138-bfe2-d932-a88f-dea924b53c88@redhat.com>
 <34c86efd6efdde2e71e7158d8978a4ca6b08202f.camel@redhat.com>
 <HE1PR0201MB22662B0F11695006C725A2708A590@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <8c0c0cdb-bf25-9dfe-6a7d-58247a8167fb@redhat.com>
 <HE1PR0201MB22667B6C5B0710761040AE898A5A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <7bfeac40-7751-e1fb-ce1e-0ec5ee0d6304@redhat.com>
Message-ID: <HE1PR0201MB22663E7BBE28CBA18ACFB7D28A5A0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Andrew,

> Thanks. I've now pushed both changes.
> 
> I committed the HotSpot change under my own name as there was little
> from the original changeset. Hopefully, my changeset addition for
> formally recognising backports [0] will be accepted to avoid this issue
> in future.
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8221692

Looks good. I endorse this.

So, on Monday I'll tag b02 then and you can announce the freeze.

Have a nice weekend
Christoph



From martinrb at google.com  Fri Mar 29 16:23:47 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 29 Mar 2019 09:23:47 -0700
Subject: make reconfigure broken (quoting problem?)
Message-ID: <CA+kOe09--3wUWRXcE0UAKea6_RvM7LwCbRFhMaFd9qHECN1y7g@mail.gmail.com>

Recipe:

( rm -rf build; set -x; bash configure --with-toolchain-type=gcc
--with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure )
=>
configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid on
this platform.
configure: Valid toolchains: gcc clang.

---
Do y'all always build from scratch?

From volker.simonis at gmail.com  Fri Mar 29 16:49:10 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 29 Mar 2019 17:49:10 +0100
Subject: Handling Backport Changesets
In-Reply-To: <b09ef682-19b5-99c6-f36c-a8fe97f676d1@redhat.com>
References: <b09ef682-19b5-99c6-f36c-a8fe97f676d1@redhat.com>
Message-ID: <CA+3eh11p0-hcfR=mrFYdi3umEsamxJNrr1zw-jErkybE6u6=6A@mail.gmail.com>

Good idea!

>From my naive understanding, this is merely a question of changing
"jcheck" in such a way that it allows these sort of extra comments. As
project owner you can disable "jcheck" altogether, in which case we
could start using the new comments right away. I'd nevertheless vote
for keeping "jcheck" but extend it to allow the new format.

Regards,
Volker

On Fri, Mar 29, 2019 at 4:00 PM Andrew John Hughes
<gnu.andrew at redhat.com> wrote:
>
> Just a heads up that I've filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8221692
>
> to try and get backporting formally recognised in changesets, in the
> same way as Contributed-by.
>
> Hopefully, this will resolve the confusion over who to credit for such
> changes.
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>

From gnu.andrew at redhat.com  Fri Mar 29 18:34:01 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 29 Mar 2019 18:34:01 +0000
Subject: make reconfigure broken (quoting problem?)
In-Reply-To: <CA+kOe09--3wUWRXcE0UAKea6_RvM7LwCbRFhMaFd9qHECN1y7g@mail.gmail.com>
References: <CA+kOe09--3wUWRXcE0UAKea6_RvM7LwCbRFhMaFd9qHECN1y7g@mail.gmail.com>
Message-ID: <f945fd2d-7c8d-adfa-a268-3c5c15f0334f@redhat.com>

On 29/03/2019 16:23, Martin Buchholz wrote:
> Recipe:
> 
> ( rm -rf build; set -x; bash configure --with-toolchain-type=gcc
> --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure )
> =>
> configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid on
> this platform.
> configure: Valid toolchains: gcc clang.
> 
> ---
> Do y'all always build from scratch?
> 

Personally speaking, not always. It depends what I've altered.

Where are you seeing this? jdk8u or jdk8u-dev? And any idea what change
caused it?

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Fri Mar 29 18:36:39 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 29 Mar 2019 18:36:39 +0000
Subject: Handling Backport Changesets
In-Reply-To: <CA+3eh11p0-hcfR=mrFYdi3umEsamxJNrr1zw-jErkybE6u6=6A@mail.gmail.com>
References: <b09ef682-19b5-99c6-f36c-a8fe97f676d1@redhat.com>
 <CA+3eh11p0-hcfR=mrFYdi3umEsamxJNrr1zw-jErkybE6u6=6A@mail.gmail.com>
Message-ID: <6e4e8d2d-8b96-676e-ca16-38666d421a5c@redhat.com>

On 29/03/2019 16:49, Volker Simonis wrote:
> Good idea!
> 
> From my naive understanding, this is merely a question of changing
> "jcheck" in such a way that it allows these sort of extra comments. As
> project owner you can disable "jcheck" altogether, in which case we
> could start using the new comments right away. I'd nevertheless vote
> for keeping "jcheck" but extend it to allow the new format.
> 
> Regards,
> Volker
> 

Well, I'm not project owner; that would be aph :) (TooManyAndrewsException)

jcheck catches quite a lot of stuff, much as it annoys me sometimes, so
I prefer to keep it enabled if possible. Also, this proposal would apply
to Oracle-maintained repositories as well (e.g. jdk12).
-- 
Andrew :)

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

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


From martinrb at google.com  Sat Mar 30 01:48:57 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 29 Mar 2019 18:48:57 -0700
Subject: make reconfigure broken (quoting problem?)
In-Reply-To: <f945fd2d-7c8d-adfa-a268-3c5c15f0334f@redhat.com>
References: <CA+kOe09--3wUWRXcE0UAKea6_RvM7LwCbRFhMaFd9qHECN1y7g@mail.gmail.com>
 <f945fd2d-7c8d-adfa-a268-3c5c15f0334f@redhat.com>
Message-ID: <CA+kOe0_f1XWTUJ1KVoG6P3yyxgTPbdZdb8Hh6iKWjbPTNyh2Mg@mail.gmail.com>

It looks to me like this feature was broken at the time of its backport to
jdk8u

changeset:   2163:2209644bcac4
user:        kevinw
date:        2018-04-10 07:46 -0700
8034199: Add 'reconfigure' target for re-creating a configuration
Reviewed-by: ihse, erikj, tbell

Recipe:
hg update 2209644bcac4 && hg log -r . && bash configure
--with-toolchain-type=gcc --with-boot-jdk=$HOME/jdk/jdk7 && make
reconfigure
...
configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid on
this platform.
configure: Valid toolchains: gcc clang.
configure: error: Cannot continue.



On Fri, Mar 29, 2019 at 11:35 AM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:

> On 29/03/2019 16:23, Martin Buchholz wrote:
> > Recipe:
> >
> > ( rm -rf build; set -x; bash configure --with-toolchain-type=gcc
> > --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure )
> > =>
> > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid
> on
> > this platform.
> > configure: Valid toolchains: gcc clang.
> >
> > ---
> > Do y'all always build from scratch?
> >
>
> Personally speaking, not always. It depends what I've altered.
>
> Where are you seeing this? jdk8u or jdk8u-dev? And any idea what change
> caused it?
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>
>