From christoph.langer at sap.com  Thu Jan  2 09:57:13 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 2 Jan 2020 09:57:13 +0000
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Jaroslav,

done with the next step. JDK-8214850 successfully runs through our test system. I applied it manually and came to the same result as you in your webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So I'll approve and push now and will then apply and test the last prereq change JDK-8209802.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 30. Dezember 2019 09:59
> To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net>
> Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
> 
> Hi Jaroslav,
> 
> I just reviewed and tested the backport for JDK-8210024. It mostly applies,
> just one trivial resolve in thread.cpp is necessary. I end up with the same
> patch as in your webrev. Running it through jdk11u-dev build & testing shows
> no problems so I'll approve and push it now and continue with JDK-8214850.
> 
> Best regards
> Christoph
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Jaroslav Bachor?k
> > Sent: Freitag, 15. November 2019 16:46
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event
> > creates unexpected amount of checkpoint data
> >
> > Hi,
> >
> > I would like to get this non-trivial JFR related backport reviewed. This
> > backport is required because OldObjectSample event in the current (JDK
> 11)
> > form will cause unlimited growth of the recording thus making this event
> > unsuitable in production memory leak detection - which is its main
> purpose.
> >
> > The backport for 8225797 requires several other changes to be backported
> as
> > well. I am listing the changes and the related webrevs here in order to
> > have all the pieces in one place. The webrevs, unfortunately, are showing
> > cumulative changes, so please, disregard that information. Each webrev is
> > generated for that particular commit.
> >
> > The following tests were run successfully:
> > - jdk_tier1
> > - jdk_tier2
> > - jdk_jfr
> > - jdk_core
> >
> > ---
> >
> > Prerequisites:
> > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> >
> > # 8209976: Improve iteration over non-JavaThreads
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> >
> > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> >
> > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> >
> > # 8209802: Garbage collectors should register JFR types themselves to
> avoid
> > build errors.
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code locations for g1 sources (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> >
> >
> > Backport:
> > # 8225797: OldObjectSample event creates unexpected amount of
> > checkpoint
> > data
> > - the original patch had to be accommodated to the JDK 11 status of JFR to
> > minimize the number of prerequisite backports and therefore it is slightly
> > more complex (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> >
> >
> > Thanks!
> >
> > -JB-

From goetz.lindenmaier at sap.com  Thu Jan  2 11:23:47 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 2 Jan 2020 11:23:47 +0000
Subject: [11u] RFR: 8225430: Replace wildcard address with loopback or local
 host in tests - part 14
Message-ID: <AM5PR0201MB24339D9BA21A5920C61F7A22EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>

Hi

I would like to downport this for parity with 11.0.7-oracle.

I added a missing import to
java/net/URLClassLoader/closetest/CloseTest.java
The import was introduced in 14 in a change not
downported to 11.

http://cr.openjdk.java.net/~goetz/wr20/8225430-wildcard_loopback_14-jdk11/01/
https://bugs.openjdk.java.net/browse/JDK-8225430
https://hg.openjdk.java.net/jdk/jdk/rev/70f5cbb711a9

Best regards,
  Goetz.

From goetz.lindenmaier at sap.com  Thu Jan  2 11:27:36 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 2 Jan 2020 11:27:36 +0000
Subject: [11u] RFR: 8223638: Replace wildcard address with loopback or
 local host in tests - part 6
In-Reply-To: <AM0PR0202MB3297CD2C65D2FF996FA434DA9A2A0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM5PR0201MB24336E478A928909D183AA2EEC2A0@AM5PR0201MB2433.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297CD2C65D2FF996FA434DA9A2A0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM5PR0201MB243325DF4FD52862F4E3EBC0EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>

Hi,

unfortunately I had to do another change to get this working.

java/net/URL/PerConnectionProxy.java calls a new constructor from 
TestHttpServer.java that was added in "8223145: Replace wildcard address with loopback or local host in tests - part 1".
8223145 does not apply well. Also I don't want to go back too far to get clean imports.
So I decided to take the missing constructor and the two others added 
by 8223145 and add them to this change, see this diff:
http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-jdk11/02/test/jdk/sun/net/www/httptest/TestHttpServer.java.udiff.html

new webrev:
http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-jdk11/02/
https://bugs.openjdk.java.net/browse/JDK-8223638
http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Freitag, 27. Dezember 2019 15:36
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8223638: Replace wildcard address with loopback or
> local host in tests - part 6
> 
> Hi G?tz,
> 
> looks good.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Freitag, 27. Dezember 2019 11:13
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR: 8223638: Replace wildcard address with
> > loopback or local host in tests - part 6
> >
> > Hi,
> >
> > I would like to downport this because a later 11.0.7-oracle change
> > Applies clean with this.
> > I had to do a simple resolve due to context in UnreferencedSockets.java
> >
> > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> > jdk11/01/
> > https://bugs.openjdk.java.net/browse/JDK-8223638
> > http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a
> >
> > Best regards,
> >   Goetz.

From martin.doerr at sap.com  Thu Jan  2 13:33:17 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 2 Jan 2020 13:33:17 +0000
Subject: [11u] RFR: 8223638: Replace wildcard address with loopback or
 local host in tests - part 6
In-Reply-To: <AM5PR0201MB243325DF4FD52862F4E3EBC0EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>
References: <AM5PR0201MB24336E478A928909D183AA2EEC2A0@AM5PR0201MB2433.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297CD2C65D2FF996FA434DA9A2A0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM5PR0201MB243325DF4FD52862F4E3EBC0EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB329774FEAAC830CE9763EDCD9A200@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi G?tz,

Integrating the TestHttpServer.java part from JDK-8223145 makes sense to me.
Looks good.

Best regards,
Martin


> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Donnerstag, 2. Januar 2020 12:28
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8223638: Replace wildcard address with loopback or
> local host in tests - part 6
> 
> Hi,
> 
> unfortunately I had to do another change to get this working.
> 
> java/net/URL/PerConnectionProxy.java calls a new constructor from
> TestHttpServer.java that was added in "8223145: Replace wildcard address
> with loopback or local host in tests - part 1".
> 8223145 does not apply well. Also I don't want to go back too far to get clean
> imports.
> So I decided to take the missing constructor and the two others added
> by 8223145 and add them to this change, see this diff:
> http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> jdk11/02/test/jdk/sun/net/www/httptest/TestHttpServer.java.udiff.html
> 
> new webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> jdk11/02/
> https://bugs.openjdk.java.net/browse/JDK-8223638
> http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: Doerr, Martin <martin.doerr at sap.com>
> > Sent: Freitag, 27. Dezember 2019 15:36
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: RE: [11u] RFR: 8223638: Replace wildcard address with loopback or
> > local host in tests - part 6
> >
> > Hi G?tz,
> >
> > looks good.
> >
> > Best regards,
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Lindenmaier, Goetz
> > > Sent: Freitag, 27. Dezember 2019 11:13
> > > To: jdk-updates-dev at openjdk.java.net
> > > Subject: [11u] RFR: 8223638: Replace wildcard address with
> > > loopback or local host in tests - part 6
> > >
> > > Hi,
> > >
> > > I would like to downport this because a later 11.0.7-oracle change
> > > Applies clean with this.
> > > I had to do a simple resolve due to context in UnreferencedSockets.java
> > >
> > > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> > > jdk11/01/
> > > https://bugs.openjdk.java.net/browse/JDK-8223638
> > > http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a
> > >
> > > Best regards,
> > >   Goetz.

From jaroslav.bachorik at datadoghq.com  Thu Jan  2 13:37:02 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Thu, 2 Jan 2020 14:37:02 +0100
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>

Great to see this moving fast! Thanks!

On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Jaroslav,
>
> done with the next step. JDK-8214850 successfully runs through our test
> system. I applied it manually and came to the same result as you in your
> webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So
> I'll approve and push now and will then apply and test the last prereq
> change JDK-8209802.
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: Langer, Christoph
> > Sent: Montag, 30. Dezember 2019 09:59
> > To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>; jdk-updates-dev
> > <jdk-updates-dev at openjdk.java.net>
> > Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> > event creates unexpected amount of checkpoint data
> >
> > Hi Jaroslav,
> >
> > I just reviewed and tested the backport for JDK-8210024. It mostly
> applies,
> > just one trivial resolve in thread.cpp is necessary. I end up with the
> same
> > patch as in your webrev. Running it through jdk11u-dev build & testing
> shows
> > no problems so I'll approve and push it now and continue with
> JDK-8214850.
> >
> > Best regards
> > Christoph
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > > Behalf Of Jaroslav Bachor?k
> > > Sent: Freitag, 15. November 2019 16:46
> > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> > event
> > > creates unexpected amount of checkpoint data
> > >
> > > Hi,
> > >
> > > I would like to get this non-trivial JFR related backport reviewed.
> This
> > > backport is required because OldObjectSample event in the current (JDK
> > 11)
> > > form will cause unlimited growth of the recording thus making this
> event
> > > unsuitable in production memory leak detection - which is its main
> > purpose.
> > >
> > > The backport for 8225797 requires several other changes to be
> backported
> > as
> > > well. I am listing the changes and the related webrevs here in order to
> > > have all the pieces in one place. The webrevs, unfortunately, are
> showing
> > > cumulative changes, so please, disregard that information. Each webrev
> is
> > > generated for that particular commit.
> > >
> > > The following tests were run successfully:
> > > - jdk_tier1
> > > - jdk_tier2
> > > - jdk_jfr
> > > - jdk_core
> > >
> > > ---
> > >
> > > Prerequisites:
> > > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> > >
> > > # 8209976: Improve iteration over non-JavaThreads
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> > >
> > > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> > >
> > > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> > >
> > > # 8209802: Garbage collectors should register JFR types themselves to
> > avoid
> > > build errors.
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code locations for g1 sources (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> > >
> > >
> > > Backport:
> > > # 8225797: OldObjectSample event creates unexpected amount of
> > > checkpoint
> > > data
> > > - the original patch had to be accommodated to the JDK 11 status of
> JFR to
> > > minimize the number of prerequisite backports and therefore it is
> slightly
> > > more complex (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> > >
> > >
> > > Thanks!
> > >
> > > -JB-
>

From goetz.lindenmaier at sap.com  Fri Jan  3 13:10:37 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 3 Jan 2020 13:10:37 +0000
Subject: [11u] RFR: 8227645: Some tests in serviceability/sa run with fixed
 -Xmx values and risk running out of memory
Message-ID: <VE1PR02MB54229A54BF1DD3144F27AA84EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

I would like to downport this for parity with 11.0.7-oracle.

This change moves tests into a new directory.

The patch does not apply clean because
test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
lacks 
"8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers"
and
"8215568: Refactor SA clhsdb tests to use ClhsdbLauncher"
which each introduced a minor fix in the test.

Downporting these two changes will fail for this file as it was moved. 
I added the chunk of 8217473 to the test, as it's a standalone fix.
The chunk of 8215568 breaks the test, so I left it out.

Please review:
http://cr.openjdk.java.net/~goetz/wr20/8227645-SA_test_oom-jdk11/01/
https://bugs.openjdk.java.net/browse/JDK-8227645
https://hg.openjdk.java.net/jdk/jdk/rev/a64caa5269cf

Best regards,
  Goetz.

From goetz.lindenmaier at sap.com  Fri Jan  3 13:40:43 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 3 Jan 2020 13:40:43 +0000
Subject: [11u] RFR: 8185005: Improve performance of
 ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
Message-ID: <VE1PR02MB5422F5FE5E783811CA5F1569EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi

I had to do some trivial resolves due to context in mutexLocker.h|cpp  to downport this:

http://cr.openjdk.java.net/~goetz/wr20/8185005-getThreadInfo_performance-jdk11/01/
https://bugs.openjdk.java.net/browse/JDK-8185005
https://hg.openjdk.java.net/jdk/jdk/rev/f4abe950c3b0

Best regards,
  Goetz.

From martin.doerr at sap.com  Fri Jan  3 13:52:59 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 3 Jan 2020 13:52:59 +0000
Subject: [11u] RFR: 8227645: Some tests in serviceability/sa run with
 fixed -Xmx values and risk running out of memory
In-Reply-To: <VE1PR02MB54229A54BF1DD3144F27AA84EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB54229A54BF1DD3144F27AA84EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3297F69753904B58F06D9A5B9A230@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi G?tz,

"I added the chunk of 8217473 to the test" means you removed "if (regionDetailsOutput == null) { ... }", right?
If that's all you've changed, I think it's fine.

I think it will be helpful to add a comment to the bug which was partly backported as part of this change.

Best regards,
Martin



> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Freitag, 3. Januar 2020 14:11
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8227645: Some tests in serviceability/sa run
> with fixed -Xmx values and risk running out of memory
> 
> Hi,
> 
> I would like to downport this for parity with 11.0.7-oracle.
> 
> This change moves tests into a new directory.
> 
> The patch does not apply clean because
> test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.jav
> a
> lacks
> "8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers"
> and
> "8215568: Refactor SA clhsdb tests to use ClhsdbLauncher"
> which each introduced a minor fix in the test.
> 
> Downporting these two changes will fail for this file as it was moved.
> I added the chunk of 8217473 to the test, as it's a standalone fix.
> The chunk of 8215568 breaks the test, so I left it out.
> 
> Please review:
> http://cr.openjdk.java.net/~goetz/wr20/8227645-SA_test_oom-jdk11/01/
> https://bugs.openjdk.java.net/browse/JDK-8227645
> https://hg.openjdk.java.net/jdk/jdk/rev/a64caa5269cf
> 
> Best regards,
>   Goetz.

From martin.doerr at sap.com  Fri Jan  3 13:59:05 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 3 Jan 2020 13:59:05 +0000
Subject: [11u] RFR: 8185005: Improve performance of
 ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
In-Reply-To: <VE1PR02MB5422F5FE5E783811CA5F1569EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422F5FE5E783811CA5F1569EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB329766040F67F4871C8695CF9A230@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi G?tz,

thanks for backporting. Looks good.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Freitag, 3. Januar 2020 14:41
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8185005: Improve performance of
> ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
> 
> Hi
> 
> I had to do some trivial resolves due to context in mutexLocker.h|cpp  to
> downport this:
> 
> http://cr.openjdk.java.net/~goetz/wr20/8185005-
> getThreadInfo_performance-jdk11/01/
> https://bugs.openjdk.java.net/browse/JDK-8185005
> https://hg.openjdk.java.net/jdk/jdk/rev/f4abe950c3b0
> 
> Best regards,
>   Goetz.

From goetz.lindenmaier at sap.com  Fri Jan  3 14:38:18 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 3 Jan 2020 14:38:18 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support 
Message-ID: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Severin, 

I'm working on downporting the 11.0.7-oracle changes.
https://bugs.openjdk.java.net/browse/JDK-8232207: Linux os::available_memory re-reads cgroup configuration on every invocation
depends on 8217338.  You had once intended to downport 
https://bugs.openjdk.java.net/browse/JDK-8217338.
The downport was then abandoned.

I am wondering whether you want to pick this up again?
8217338 is productive in 13 for a while now, and it applies
clean.
I'm not sure about the Java changes, do they change the API?
The hotspot changes help to apply 8232207, though.

I would like to wait with 8232207 until this is decided.

Best regards,
  Goetz.






From goetz.lindenmaier at sap.com  Fri Jan  3 16:32:33 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 3 Jan 2020 16:32:33 +0000
Subject: Help with downporting 8225019: Update JVMCI
Message-ID: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

I am working on downporting 11.0.7-oracle fixes to OpenJDK
11.0.7.

I encountered "8225019: Update JVMCI" which is applying badly. 
It has lots of rejects. There are various places that are not
 trivial to resolve.

I don't have any background in JVMCI/AOT and SAP does
not use it (yet).
I would appreciate if someone with appropriate background
or interest could step up and bring this change to jdk11u-dev.

https://bugs.openjdk.java.net/browse/JDK-8225019
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034050.html

Best regards,
  Goetz.

From christoph.langer at sap.com  Sun Jan  5 22:36:44 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 5 Jan 2020 22:36:44 +0000
Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as
 Paths instead of URLs
In-Reply-To: <8a24c155-9dbf-ae9e-e829-cd116de00b30@gmail.com>
References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com>
 <AM6PR02MB498499029FC9D35C7F15067B8A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <8a24c155-9dbf-ae9e-e829-cd116de00b30@gmail.com>
Message-ID: <AM6PR02MB49846C151D1177C4038667AD8A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Jaikiran,

I've ran your patches through our testing now. It turns out that 8218268 needs a little modification for 11u. The call Path.of(url.toURI()) needs to be converted to Paths.get(url.toURI()) because of the requirement of JDK11 to be buildable with a bootstrap OpenJDK of version 10. com.sun.tools.javac.file.FSInfo is compiled with the bootstrap JDK and JDK 10 does not yet have the Path.of methods.

So request to the Reviewers: May I please get a review for: http://cr.openjdk.java.net/~clanger/webrevs/8218268.11u/ ?

Thanks
Christoph



> -----Original Message-----
> From: Jaikiran Pai <jai.forums2013 at gmail.com>
> Sent: Montag, 30. Dezember 2019 15:19
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as
> Paths instead of URLs
> 
> Hello Christoph,
> 
> On 30/12/19 4:12 PM, Langer, Christoph wrote:
> > Hi Jaikiran,
> >
> > I guess it's holiday season so you ran into a little delay.
> >
> > Your request involves two bugfixes, one is JDK-8232170 and the other is
> JDK-8218268. They should be backported separately. From looking at their
> description, I guess they are viable candidates for a backport. They alter the
> behavior of javac a bit - but I'd assume only in the sense of fixing bugs ??.
> >
> > Since both patches apply cleanly, I have added them to our build&test
> system. We should have results on whether there are regressions by
> tomorrow.
> 
> Thank you very much for doing that.
> 
> 
> >
> > Can you please add a fix request comment&label to JDK-8232170 as well? In
> case everything goes fine I'll approve and sponsor for you.
> 
> I've now updated that JBS issue to include a backport RFR comment as
> well as added the jdk11u-fix-request label. Thanks again for sponsoring
> this :)
> 
> -Jaikiran
> 


From christoph.langer at sap.com  Sun Jan  5 22:49:54 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 5 Jan 2020 22:49:54 +0000
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
Message-ID: <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Jaroslav,

looking at 8209802, I?d like to make a small modification to your proposed webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209802.11u/

I think, the changes done in src/hotspot/share/gc/shared/gcTrace.cpp should be guarded by #if INCLUDE_G1GC as the original changes live in a G1 specific file (src/hotspot/share/gc/g1/g1Trace.cpp). Other than that, it matches your original webrev. What do you think?

In case this gets reviewed, I?m ready to push. The patch has passed all our regression testing.

Best regards
Christoph

From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
Sent: Donnerstag, 2. Januar 2020 14:37
To: Langer, Christoph <christoph.langer at sap.com>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Great to see this moving fast! Thanks!

On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

done with the next step. JDK-8214850 successfully runs through our test system. I applied it manually and came to the same result as you in your webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So I'll approve and push now and will then apply and test the last prereq change JDK-8209802.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 30. Dezember 2019 09:59
> To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
> Hi Jaroslav,
>
> I just reviewed and tested the backport for JDK-8210024. It mostly applies,
> just one trivial resolve in thread.cpp is necessary. I end up with the same
> patch as in your webrev. Running it through jdk11u-dev build & testing shows
> no problems so I'll approve and push it now and continue with JDK-8214850.
>
> Best regards
> Christoph
>
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> > Behalf Of Jaroslav Bachor?k
> > Sent: Freitag, 15. November 2019 16:46
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event
> > creates unexpected amount of checkpoint data
> >
> > Hi,
> >
> > I would like to get this non-trivial JFR related backport reviewed. This
> > backport is required because OldObjectSample event in the current (JDK
> 11)
> > form will cause unlimited growth of the recording thus making this event
> > unsuitable in production memory leak detection - which is its main
> purpose.
> >
> > The backport for 8225797 requires several other changes to be backported
> as
> > well. I am listing the changes and the related webrevs here in order to
> > have all the pieces in one place. The webrevs, unfortunately, are showing
> > cumulative changes, so please, disregard that information. Each webrev is
> > generated for that particular commit.
> >
> > The following tests were run successfully:
> > - jdk_tier1
> > - jdk_tier2
> > - jdk_jfr
> > - jdk_core
> >
> > ---
> >
> > Prerequisites:
> > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> >
> > # 8209976: Improve iteration over non-JavaThreads
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> >
> > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> >
> > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> >
> > # 8209802: Garbage collectors should register JFR types themselves to
> avoid
> > build errors.
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code locations for g1 sources (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> >
> >
> > Backport:
> > # 8225797: OldObjectSample event creates unexpected amount of
> > checkpoint
> > data
> > - the original patch had to be accommodated to the JDK 11 status of JFR to
> > minimize the number of prerequisite backports and therefore it is slightly
> > more complex (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> >
> >
> > Thanks!
> >
> > -JB-

From jai.forums2013 at gmail.com  Mon Jan  6 04:23:54 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 6 Jan 2020 09:53:54 +0530
Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as
 Paths instead of URLs
In-Reply-To: <AM6PR02MB49846C151D1177C4038667AD8A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com>
 <AM6PR02MB498499029FC9D35C7F15067B8A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <8a24c155-9dbf-ae9e-e829-cd116de00b30@gmail.com>
 <AM6PR02MB49846C151D1177C4038667AD8A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <48b7ca24-280a-d7cc-6bae-182487497f9c@gmail.com>

Hello Christoph,

On 06/01/20 4:06 AM, Langer, Christoph wrote:
> Hi Jaikiran,
>
> I've ran your patches through our testing now.

Thank you.


>  It turns out that 8218268 needs a little modification for 11u. The call Path.of(url.toURI()) needs to be converted to Paths.get(url.toURI()) because of the requirement of JDK11 to be buildable with a bootstrap OpenJDK of version 10. com.sun.tools.javac.file.FSInfo is compiled with the bootstrap JDK and JDK 10 does not yet have the Path.of methods.

I thought I had built and run the relevant tests on jdk11u repo before
sending this patch, but now I'm not really confident if I indeed did
that (it's been a while now). Is it possible that maybe I used JDK 11 to
bootstrap that repo itself and the build process didn't catch this issue?

Either way, thank you very much for taking care of the change and
proposing the new patch.

-Jaikiran


From jaroslav.bachorik at datadoghq.com  Mon Jan  6 09:01:29 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 6 Jan 2020 10:01:29 +0100
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
 <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>

Hi Christoph,

the change looks good and makes sense. Please, go ahead!

-JB-

On Sun, Jan 5, 2020 at 11:50 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Jaroslav,
>
>
>
> looking at 8209802, I?d like to make a small modification to your proposed
> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209802.11u/
>
>
>
> I think, the changes done in src/hotspot/share/gc/shared/gcTrace.cpp
> should be guarded by #if INCLUDE_G1GC as the original changes live in a G1
> specific file (src/hotspot/share/gc/g1/g1Trace.cpp). Other than that, it
> matches your original webrev. What do you think?
>
>
>
> In case this gets reviewed, I?m ready to push. The patch has passed all
> our regression testing.
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
> *Sent:* Donnerstag, 2. Januar 2020 14:37
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> *Subject:* Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
>
>
> Great to see this moving fast! Thanks!
>
>
>
> On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <
> christoph.langer at sap.com> wrote:
>
> Hi Jaroslav,
>
> done with the next step. JDK-8214850 successfully runs through our test
> system. I applied it manually and came to the same result as you in your
> webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So
> I'll approve and push now and will then apply and test the last prereq
> change JDK-8209802.
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: Langer, Christoph
> > Sent: Montag, 30. Dezember 2019 09:59
> > To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>; jdk-updates-dev
> > <jdk-updates-dev at openjdk.java.net>
> > Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> > event creates unexpected amount of checkpoint data
> >
> > Hi Jaroslav,
> >
> > I just reviewed and tested the backport for JDK-8210024. It mostly
> applies,
> > just one trivial resolve in thread.cpp is necessary. I end up with the
> same
> > patch as in your webrev. Running it through jdk11u-dev build & testing
> shows
> > no problems so I'll approve and push it now and continue with
> JDK-8214850.
> >
> > Best regards
> > Christoph
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > > Behalf Of Jaroslav Bachor?k
> > > Sent: Freitag, 15. November 2019 16:46
> > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> > event
> > > creates unexpected amount of checkpoint data
> > >
> > > Hi,
> > >
> > > I would like to get this non-trivial JFR related backport reviewed.
> This
> > > backport is required because OldObjectSample event in the current (JDK
> > 11)
> > > form will cause unlimited growth of the recording thus making this
> event
> > > unsuitable in production memory leak detection - which is its main
> > purpose.
> > >
> > > The backport for 8225797 requires several other changes to be
> backported
> > as
> > > well. I am listing the changes and the related webrevs here in order to
> > > have all the pieces in one place. The webrevs, unfortunately, are
> showing
> > > cumulative changes, so please, disregard that information. Each webrev
> is
> > > generated for that particular commit.
> > >
> > > The following tests were run successfully:
> > > - jdk_tier1
> > > - jdk_tier2
> > > - jdk_jfr
> > > - jdk_core
> > >
> > > ---
> > >
> > > Prerequisites:
> > > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> > >
> > > # 8209976: Improve iteration over non-JavaThreads
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> > >
> > > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> > >
> > > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> > >
> > > # 8209802: Garbage collectors should register JFR types themselves to
> > avoid
> > > build errors.
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code locations for g1 sources (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> > >
> > >
> > > Backport:
> > > # 8225797: OldObjectSample event creates unexpected amount of
> > > checkpoint
> > > data
> > > - the original patch had to be accommodated to the JDK 11 status of
> JFR to
> > > minimize the number of prerequisite backports and therefore it is
> slightly
> > > more complex (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> > >
> > >
> > > Thanks!
> > >
> > > -JB-
>
>

From jonathan.gibbons at oracle.com  Mon Jan  6 18:15:01 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 Jan 2020 10:15:01 -0800
Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as
 Paths instead of URLs
In-Reply-To: <AM6PR02MB49846C151D1177C4038667AD8A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com>
 <AM6PR02MB498499029FC9D35C7F15067B8A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <8a24c155-9dbf-ae9e-e829-cd116de00b30@gmail.com>
 <AM6PR02MB49846C151D1177C4038667AD8A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <53597703-1893-f907-0724-57b619d237b1@oracle.com>

Cristoph,

As the author of the patch being backported, this looks good to me.

-- Jon

On 1/5/20 2:36 PM, Langer, Christoph wrote:
> Hi Jaikiran,
>
> I've ran your patches through our testing now. It turns out that 8218268 needs a little modification for 11u. The call Path.of(url.toURI()) needs to be converted to Paths.get(url.toURI()) because of the requirement of JDK11 to be buildable with a bootstrap OpenJDK of version 10. com.sun.tools.javac.file.FSInfo is compiled with the bootstrap JDK and JDK 10 does not yet have the Path.of methods.
>
> So request to the Reviewers: May I please get a review for: http://cr.openjdk.java.net/~clanger/webrevs/8218268.11u/ ?
>
> Thanks
> Christoph
>
>
>
>> -----Original Message-----
>> From: Jaikiran Pai <jai.forums2013 at gmail.com>
>> Sent: Montag, 30. Dezember 2019 15:19
>> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
>> dev at openjdk.java.net
>> Subject: Re: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as
>> Paths instead of URLs
>>
>> Hello Christoph,
>>
>> On 30/12/19 4:12 PM, Langer, Christoph wrote:
>>> Hi Jaikiran,
>>>
>>> I guess it's holiday season so you ran into a little delay.
>>>
>>> Your request involves two bugfixes, one is JDK-8232170 and the other is
>> JDK-8218268. They should be backported separately. From looking at their
>> description, I guess they are viable candidates for a backport. They alter the
>> behavior of javac a bit - but I'd assume only in the sense of fixing bugs ??.
>>> Since both patches apply cleanly, I have added them to our build&test
>> system. We should have results on whether there are regressions by
>> tomorrow.
>>
>> Thank you very much for doing that.
>>
>>
>>> Can you please add a fix request comment&label to JDK-8232170 as well? In
>> case everything goes fine I'll approve and sponsor for you.
>>
>> I've now updated that JBS issue to include a backport RFR comment as
>> well as added the jdk11u-fix-request label. Thanks again for sponsoring
>> this :)
>>
>> -Jaikiran
>>

From christoph.langer at sap.com  Tue Jan  7 10:15:22 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 7 Jan 2020 10:15:22 +0000
Subject: [11u] RFR: 8225430: Replace wildcard address with loopback or
 local host in tests - part 14
In-Reply-To: <AM5PR0201MB24339D9BA21A5920C61F7A22EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>
References: <AM5PR0201MB24339D9BA21A5920C61F7A22EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984E8BBCFE2FD128D2A4FC28A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Goetz,

looks good to me.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Donnerstag, 2. Januar 2020 12:24
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR: 8225430: Replace wildcard address with
> loopback or local host in tests - part 14
> 
> Hi
> 
> I would like to downport this for parity with 11.0.7-oracle.
> 
> I added a missing import to
> java/net/URLClassLoader/closetest/CloseTest.java
> The import was introduced in 14 in a change not
> downported to 11.
> 
> http://cr.openjdk.java.net/~goetz/wr20/8225430-wildcard_loopback_14-
> jdk11/01/
> https://bugs.openjdk.java.net/browse/JDK-8225430
> https://hg.openjdk.java.net/jdk/jdk/rev/70f5cbb711a9
> 
> Best regards,
>   Goetz.

From christoph.langer at sap.com  Tue Jan  7 10:21:34 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 7 Jan 2020 10:21:34 +0000
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
 <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>
Message-ID: <AM6PR02MB49845530BE014E771BD5EBA88A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Jaroslav,

thanks for the review. I?ve pushed JDK-8209802 which leaves us with the actual JDK-8225797. I?ll try to run it through our build/test system now. As I?ve written a while ago when I initially applied your whole queue, there were errors, even during build on some platforms/configurations. So, I?ll try once again and get back to you when I have results.

Best regards
Christoph


From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
Sent: Montag, 6. Januar 2020 10:01
To: Langer, Christoph <christoph.langer at sap.com>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Hi Christoph,

the change looks good and makes sense. Please, go ahead!

-JB-

On Sun, Jan 5, 2020 at 11:50 PM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

looking at 8209802, I?d like to make a small modification to your proposed webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209802.11u/

I think, the changes done in src/hotspot/share/gc/shared/gcTrace.cpp should be guarded by #if INCLUDE_G1GC as the original changes live in a G1 specific file (src/hotspot/share/gc/g1/g1Trace.cpp). Other than that, it matches your original webrev. What do you think?

In case this gets reviewed, I?m ready to push. The patch has passed all our regression testing.

Best regards
Christoph

From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>
Sent: Donnerstag, 2. Januar 2020 14:37
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Great to see this moving fast! Thanks!

On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

done with the next step. JDK-8214850 successfully runs through our test system. I applied it manually and came to the same result as you in your webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So I'll approve and push now and will then apply and test the last prereq change JDK-8209802.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 30. Dezember 2019 09:59
> To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
> Hi Jaroslav,
>
> I just reviewed and tested the backport for JDK-8210024. It mostly applies,
> just one trivial resolve in thread.cpp is necessary. I end up with the same
> patch as in your webrev. Running it through jdk11u-dev build & testing shows
> no problems so I'll approve and push it now and continue with JDK-8214850.
>
> Best regards
> Christoph
>
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> > Behalf Of Jaroslav Bachor?k
> > Sent: Freitag, 15. November 2019 16:46
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event
> > creates unexpected amount of checkpoint data
> >
> > Hi,
> >
> > I would like to get this non-trivial JFR related backport reviewed. This
> > backport is required because OldObjectSample event in the current (JDK
> 11)
> > form will cause unlimited growth of the recording thus making this event
> > unsuitable in production memory leak detection - which is its main
> purpose.
> >
> > The backport for 8225797 requires several other changes to be backported
> as
> > well. I am listing the changes and the related webrevs here in order to
> > have all the pieces in one place. The webrevs, unfortunately, are showing
> > cumulative changes, so please, disregard that information. Each webrev is
> > generated for that particular commit.
> >
> > The following tests were run successfully:
> > - jdk_tier1
> > - jdk_tier2
> > - jdk_jfr
> > - jdk_core
> >
> > ---
> >
> > Prerequisites:
> > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> >
> > # 8209976: Improve iteration over non-JavaThreads
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> >
> > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> >
> > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> >
> > # 8209802: Garbage collectors should register JFR types themselves to
> avoid
> > build errors.
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code locations for g1 sources (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> >
> >
> > Backport:
> > # 8225797: OldObjectSample event creates unexpected amount of
> > checkpoint
> > data
> > - the original patch had to be accommodated to the JDK 11 status of JFR to
> > minimize the number of prerequisite backports and therefore it is slightly
> > more complex (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> >
> >
> > Thanks!
> >
> > -JB-

From christoph.langer at sap.com  Tue Jan  7 10:33:54 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 7 Jan 2020 10:33:54 +0000
Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as
 Paths instead of URLs
In-Reply-To: <48b7ca24-280a-d7cc-6bae-182487497f9c@gmail.com>
References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com>
 <AM6PR02MB498499029FC9D35C7F15067B8A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <8a24c155-9dbf-ae9e-e829-cd116de00b30@gmail.com>
 <AM6PR02MB49846C151D1177C4038667AD8A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <48b7ca24-280a-d7cc-6bae-182487497f9c@gmail.com>
Message-ID: <AM6PR02MB498432EF3730F72D1AB7320B8A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Jaikiran,

> >  It turns out that 8218268 needs a little modification for 11u. The call
> Path.of(url.toURI()) needs to be converted to Paths.get(url.toURI()) because
> of the requirement of JDK11 to be buildable with a bootstrap OpenJDK of
> version 10. com.sun.tools.javac.file.FSInfo is compiled with the bootstrap JDK
> and JDK 10 does not yet have the Path.of methods.
> 
> I thought I had built and run the relevant tests on jdk11u repo before
> sending this patch, but now I'm not really confident if I indeed did
> that (it's been a while now). Is it possible that maybe I used JDK 11 to
> bootstrap that repo itself and the build process didn't catch this issue?

You'll probably have used JDK11 as bootstrap JDK. I guess most people do so today, given that JDK11 is LTS and JDK10 has been out of maintenance for quite some time now. However, there are a few folks around that still run build pipelines with JDK10.

> Either way, thank you very much for taking care of the change and
> proposing the new patch.

Welcome. I just pushed it to 11u-dev.

Cheers
Christoph



From jaroslav.bachorik at datadoghq.com  Tue Jan  7 12:25:57 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Tue, 7 Jan 2020 13:25:57 +0100
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <AM6PR02MB49845530BE014E771BD5EBA88A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
 <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>
 <AM6PR02MB49845530BE014E771BD5EBA88A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <CAPb8aJ74obrAhnA6TnysKNyYwxUUgh1PBnrPN-x3KUpXobYJZA@mail.gmail.com>

Great, thanks for the update. Don't hesitate to contact me if there are any
failures. Getting this in is my top priority.

-JB-

On Tue, Jan 7, 2020 at 11:21 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Jaroslav,
>
>
>
> thanks for the review. I?ve pushed JDK-8209802 which leaves us with the
> actual JDK-8225797. I?ll try to run it through our build/test system now.
> As I?ve written a while ago when I initially applied your whole queue,
> there were errors, even during build on some platforms/configurations. So,
> I?ll try once again and get back to you when I have results.
>
>
>
> Best regards
>
> Christoph
>
>
>
>
>
> *From:* Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
> *Sent:* Montag, 6. Januar 2020 10:01
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> *Subject:* Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
>
>
> Hi Christoph,
>
>
>
> the change looks good and makes sense. Please, go ahead!
>
>
>
> -JB-
>
>
>
> On Sun, Jan 5, 2020 at 11:50 PM Langer, Christoph <
> christoph.langer at sap.com> wrote:
>
> Hi Jaroslav,
>
>
>
> looking at 8209802, I?d like to make a small modification to your proposed
> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209802.11u/
>
>
>
> I think, the changes done in src/hotspot/share/gc/shared/gcTrace.cpp
> should be guarded by #if INCLUDE_G1GC as the original changes live in a G1
> specific file (src/hotspot/share/gc/g1/g1Trace.cpp). Other than that, it
> matches your original webrev. What do you think?
>
>
>
> In case this gets reviewed, I?m ready to push. The patch has passed all
> our regression testing.
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
> *Sent:* Donnerstag, 2. Januar 2020 14:37
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> *Subject:* Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
>
>
> Great to see this moving fast! Thanks!
>
>
>
> On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <
> christoph.langer at sap.com> wrote:
>
> Hi Jaroslav,
>
> done with the next step. JDK-8214850 successfully runs through our test
> system. I applied it manually and came to the same result as you in your
> webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So
> I'll approve and push now and will then apply and test the last prereq
> change JDK-8209802.
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: Langer, Christoph
> > Sent: Montag, 30. Dezember 2019 09:59
> > To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>; jdk-updates-dev
> > <jdk-updates-dev at openjdk.java.net>
> > Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> > event creates unexpected amount of checkpoint data
> >
> > Hi Jaroslav,
> >
> > I just reviewed and tested the backport for JDK-8210024. It mostly
> applies,
> > just one trivial resolve in thread.cpp is necessary. I end up with the
> same
> > patch as in your webrev. Running it through jdk11u-dev build & testing
> shows
> > no problems so I'll approve and push it now and continue with
> JDK-8214850.
> >
> > Best regards
> > Christoph
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > > Behalf Of Jaroslav Bachor?k
> > > Sent: Freitag, 15. November 2019 16:46
> > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> > event
> > > creates unexpected amount of checkpoint data
> > >
> > > Hi,
> > >
> > > I would like to get this non-trivial JFR related backport reviewed.
> This
> > > backport is required because OldObjectSample event in the current (JDK
> > 11)
> > > form will cause unlimited growth of the recording thus making this
> event
> > > unsuitable in production memory leak detection - which is its main
> > purpose.
> > >
> > > The backport for 8225797 requires several other changes to be
> backported
> > as
> > > well. I am listing the changes and the related webrevs here in order to
> > > have all the pieces in one place. The webrevs, unfortunately, are
> showing
> > > cumulative changes, so please, disregard that information. Each webrev
> is
> > > generated for that particular commit.
> > >
> > > The following tests were run successfully:
> > > - jdk_tier1
> > > - jdk_tier2
> > > - jdk_jfr
> > > - jdk_core
> > >
> > > ---
> > >
> > > Prerequisites:
> > > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> > >
> > > # 8209976: Improve iteration over non-JavaThreads
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> > >
> > > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> > >
> > > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code structure  (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> > >
> > > # 8209802: Garbage collectors should register JFR types themselves to
> > avoid
> > > build errors.
> > > - applied almost cleanly with only minimal changes to account for
> slightly
> > > different code locations for g1 sources (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> > >
> > >
> > > Backport:
> > > # 8225797: OldObjectSample event creates unexpected amount of
> > > checkpoint
> > > data
> > > - the original patch had to be accommodated to the JDK 11 status of
> JFR to
> > > minimize the number of prerequisite backports and therefore it is
> slightly
> > > more complex (patch diff -
> > > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> > >
> > >
> > > Thanks!
> > >
> > > -JB-
>
>

From sgehwolf at redhat.com  Tue Jan  7 14:11:55 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 07 Jan 2020 15:11:55 +0100
Subject: Downport 8217338: [Containers] Improve systemd slice memory
 limit support
In-Reply-To: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>

Hi Goetz!

On Fri, 2020-01-03 at 14:38 +0000, Lindenmaier, Goetz wrote:
> Hi Severin, 
> 
> I'm working on downporting the 11.0.7-oracle changes.
> https://bugs.openjdk.java.net/browse/JDK-8232207: Linux os::available_memory re-reads cgroup configuration on every invocation
> depends on 8217338.  You had once intended to downport 
> https://bugs.openjdk.java.net/browse/JDK-8217338.
> The downport was then abandoned.
> 
> I am wondering whether you want to pick this up again?

Sure, I can pick it up again. I'll try to get it done in the next week
or so.

> 8217338 is productive in 13 for a while now, and it applies
> clean.
> I'm not sure about the Java changes, do they change the API?

Not that I'm aware of. Cgroup related code is Linux only and in an
jdk.internal package.

> The hotspot changes help to apply 8232207, though.
> 
> I would like to wait with 8232207 until this is decided.

Thanks for reaching out.

Backporting 8232207 is a good idea.

Thanks,
Severin


From goetz.lindenmaier at sap.com  Tue Jan  7 15:59:36 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 7 Jan 2020 15:59:36 +0000
Subject: [11u] RFR: 8227645: Some tests in serviceability/sa run with
 fixed -Xmx values and risk running out of memory
In-Reply-To: <AM0PR0202MB3297F69753904B58F06D9A5B9A230@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <VE1PR02MB54229A54BF1DD3144F27AA84EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297F69753904B58F06D9A5B9A230@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <VE1PR02MB5422FADCEBCC97E9B79E9565EC3F0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Martin,

yes, you are right. 

Thanks for reviewing.

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Freitag, 3. Januar 2020 14:53
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8227645: Some tests in serviceability/sa run with fixed -
> Xmx values and risk running out of memory
> 
> Hi G?tz,
> 
> "I added the chunk of 8217473 to the test" means you removed "if
> (regionDetailsOutput == null) { ... }", right?
> If that's all you've changed, I think it's fine.
> 
> I think it will be helpful to add a comment to the bug which was partly
> backported as part of this change.
> 
> Best regards,
> Martin
> 
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Freitag, 3. Januar 2020 14:11
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR: 8227645: Some tests in serviceability/sa run
> > with fixed -Xmx values and risk running out of memory
> >
> > Hi,
> >
> > I would like to downport this for parity with 11.0.7-oracle.
> >
> > This change moves tests into a new directory.
> >
> > The patch does not apply clean because
> > test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.jav
> > a
> > lacks
> > "8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers"
> > and
> > "8215568: Refactor SA clhsdb tests to use ClhsdbLauncher"
> > which each introduced a minor fix in the test.
> >
> > Downporting these two changes will fail for this file as it was moved.
> > I added the chunk of 8217473 to the test, as it's a standalone fix.
> > The chunk of 8215568 breaks the test, so I left it out.
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr20/8227645-SA_test_oom-jdk11/01/
> > https://bugs.openjdk.java.net/browse/JDK-8227645
> > https://hg.openjdk.java.net/jdk/jdk/rev/a64caa5269cf
> >
> > Best regards,
> >   Goetz.

From gnu.andrew at redhat.com  Wed Jan  8 06:46:04 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 8 Jan 2020 06:46:04 +0000
Subject: RFR: [11u] JDK-8236039: JSSE Client does not accept status_request
 extension in CertificateRequest messages for TLS 1.3
Message-ID: <605aae0a-9e0a-90c2-218c-8bd533a2dab3@redhat.com>

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

TLS 1.3 allows the status_request extension, but, as the JSSE provider
does not currently support it, it throws an exception. It should instead
simply ignore the extension.

Backporting this fix will increase compatibility with TLS 1.3 clients.

Patch nearly applies cleanly, with the exception of the copyright header
having been previously updated in 15u, but not 11u:

 @@ -1,5 +1,5 @@
  /*
-- * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights
reserved.
+- * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
 + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights
reserved.

Ok for 11.0.7?

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 goetz.lindenmaier at sap.com  Wed Jan  8 09:04:49 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 09:04:49 +0000
Subject: [11u] RFR: 8223638: Replace wildcard address with loopback or
 local host in tests - part 6
In-Reply-To: <AM0PR0202MB329774FEAAC830CE9763EDCD9A200@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM5PR0201MB24336E478A928909D183AA2EEC2A0@AM5PR0201MB2433.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297CD2C65D2FF996FA434DA9A2A0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM5PR0201MB243325DF4FD52862F4E3EBC0EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>
 <AM0PR0202MB329774FEAAC830CE9763EDCD9A200@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <VE1PR02MB5422DF5DA3F9C398EFCC890CEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Martin,

thanks for reviewing!

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Donnerstag, 2. Januar 2020 14:33
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8223638: Replace wildcard address with loopback or
> local host in tests - part 6
> 
> Hi G?tz,
> 
> Integrating the TestHttpServer.java part from JDK-8223145 makes sense to
> me.
> Looks good.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Sent: Donnerstag, 2. Januar 2020 12:28
> > To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: RE: [11u] RFR: 8223638: Replace wildcard address with loopback or
> > local host in tests - part 6
> >
> > Hi,
> >
> > unfortunately I had to do another change to get this working.
> >
> > java/net/URL/PerConnectionProxy.java calls a new constructor from
> > TestHttpServer.java that was added in "8223145: Replace wildcard address
> > with loopback or local host in tests - part 1".
> > 8223145 does not apply well. Also I don't want to go back too far to get clean
> > imports.
> > So I decided to take the missing constructor and the two others added
> > by 8223145 and add them to this change, see this diff:
> > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> > jdk11/02/test/jdk/sun/net/www/httptest/TestHttpServer.java.udiff.html
> >
> > new webrev:
> > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> > jdk11/02/
> > https://bugs.openjdk.java.net/browse/JDK-8223638
> > http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a
> >
> > Best regards,
> >   Goetz.
> >
> > > -----Original Message-----
> > > From: Doerr, Martin <martin.doerr at sap.com>
> > > Sent: Freitag, 27. Dezember 2019 15:36
> > > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> > > dev at openjdk.java.net
> > > Subject: RE: [11u] RFR: 8223638: Replace wildcard address with loopback or
> > > local host in tests - part 6
> > >
> > > Hi G?tz,
> > >
> > > looks good.
> > >
> > > Best regards,
> > > Martin
> > >
> > >
> > > > -----Original Message-----
> > > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> > On
> > > > Behalf Of Lindenmaier, Goetz
> > > > Sent: Freitag, 27. Dezember 2019 11:13
> > > > To: jdk-updates-dev at openjdk.java.net
> > > > Subject: [11u] RFR: 8223638: Replace wildcard address with
> > > > loopback or local host in tests - part 6
> > > >
> > > > Hi,
> > > >
> > > > I would like to downport this because a later 11.0.7-oracle change
> > > > Applies clean with this.
> > > > I had to do a simple resolve due to context in UnreferencedSockets.java
> > > >
> > > > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-
> > > > jdk11/01/
> > > > https://bugs.openjdk.java.net/browse/JDK-8223638
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a
> > > >
> > > > Best regards,
> > > >   Goetz.

From goetz.lindenmaier at sap.com  Wed Jan  8 09:19:31 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 09:19:31 +0000
Subject: [11u] RFR: 8225430: Replace wildcard address with loopback or
 local host in tests - part 14
In-Reply-To: <AM6PR02MB4984E8BBCFE2FD128D2A4FC28A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <AM5PR0201MB24339D9BA21A5920C61F7A22EC200@AM5PR0201MB2433.eurprd02.prod.outlook.com>
 <AM6PR02MB4984E8BBCFE2FD128D2A4FC28A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <VE1PR02MB5422C4B4A03D33790419E103EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Christoph, 

thanks for reviewing!

Best regards,
  Goetz.

> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Dienstag, 7. Januar 2020 11:15
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8225430: Replace wildcard address with loopback or
> local host in tests - part 14
> 
> Hi Goetz,
> 
> looks good to me.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Donnerstag, 2. Januar 2020 12:24
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [11u] RFR: 8225430: Replace wildcard address with
> > loopback or local host in tests - part 14
> >
> > Hi
> >
> > I would like to downport this for parity with 11.0.7-oracle.
> >
> > I added a missing import to
> > java/net/URLClassLoader/closetest/CloseTest.java
> > The import was introduced in 14 in a change not
> > downported to 11.
> >
> > http://cr.openjdk.java.net/~goetz/wr20/8225430-wildcard_loopback_14-
> > jdk11/01/
> > https://bugs.openjdk.java.net/browse/JDK-8225430
> > https://hg.openjdk.java.net/jdk/jdk/rev/70f5cbb711a9
> >
> > Best regards,
> >   Goetz.

From goetz.lindenmaier at sap.com  Wed Jan  8 10:19:53 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 10:19:53 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support
In-Reply-To: <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
Message-ID: <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Severin, everybody,

I wanted to follow your plan and let you do this downport. 
But it was in one of my queues in between of other changes
that were approved and which I can push.
Now I accidentally pushed this change along with the others, 
sorry!

I ran the change through our testing and it's all green. 
But I did not request downport, so it was not approved (yet).
Also I thought it needs some discussion as Andrew Haley
had questioned it in a comment:
https://bugs.openjdk.java.net/browse/JDK-8217338
It brings some changes in internal classes in java.base.

What should I do? Should I back it out, or should 
I request downport and only back it out in case downport
is rejected?

Me personally am in favour of bringing the cgroup improvements
to 11. I think it's an important thing for Java to support.

Best regards
  Goetz

PS: the current process of bringing changes to 11 that were
downported by Oracle is extremely cumbersome.  I am doing
lots of completely pointless webrevs/reviews, and I have to 
coordinate with a row of other resources: reviewer, approval, 
testing. In the end I have 15-30 open changes for downport, 
some not reviewed, some not approved, some in the testing, 
some I need to fix as they did not pass testing. This leads to errors.
And only from the testing I ever got useful feedback ... 
It would be much better if I could just push all changes that
applied without substantial conflicts after they passed testing.




> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Dienstag, 7. Januar 2020 15:12
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: Downport 8217338: [Containers] Improve systemd slice memory
> limit support
> 
> Hi Goetz!
> 
> On Fri, 2020-01-03 at 14:38 +0000, Lindenmaier, Goetz wrote:
> > Hi Severin,
> >
> > I'm working on downporting the 11.0.7-oracle changes.
> > https://bugs.openjdk.java.net/browse/JDK-8232207: Linux
> os::available_memory re-reads cgroup configuration on every invocation
> > depends on 8217338.  You had once intended to downport
> > https://bugs.openjdk.java.net/browse/JDK-8217338.
> > The downport was then abandoned.
> >
> > I am wondering whether you want to pick this up again?
> 
> Sure, I can pick it up again. I'll try to get it done in the next week
> or so.
> 
> > 8217338 is productive in 13 for a while now, and it applies
> > clean.
> > I'm not sure about the Java changes, do they change the API?
> 
> Not that I'm aware of. Cgroup related code is Linux only and in an
> jdk.internal package.
> 
> > The hotspot changes help to apply 8232207, though.
> >
> > I would like to wait with 8232207 until this is decided.
> 
> Thanks for reaching out.
> 
> Backporting 8232207 is a good idea.
> 
> Thanks,
> Severin


From aph at redhat.com  Wed Jan  8 11:20:09 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 8 Jan 2020 11:20:09 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support
In-Reply-To: <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
 <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <80ea7560-6aa4-bc09-8c74-7237e7364566@redhat.com>

On 1/8/20 10:19 AM, Lindenmaier, Goetz wrote:
> PS: the current process of bringing changes to 11 that were
> downported by Oracle is extremely cumbersome.  I am doing
> lots of completely pointless webrevs/reviews, and I have to 
> coordinate with a row of other resources: reviewer, approval, 
> testing. In the end I have 15-30 open changes for downport, 
> some not reviewed, some not approved, some in the testing, 
> some I need to fix as they did not pass testing. This leads to errors.
> And only from the testing I ever got useful feedback ... 
> It would be much better if I could just push all changes that
> applied without substantial conflicts after they passed testing.

We have the Committers' Workshop upcoming. We can discuss this problem
there.

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


From goetz.lindenmaier at sap.com  Wed Jan  8 11:36:19 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 11:36:19 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support
In-Reply-To: <80ea7560-6aa4-bc09-8c74-7237e7364566@redhat.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
 <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <80ea7560-6aa4-bc09-8c74-7237e7364566@redhat.com>
Message-ID: <VE1PR02MB5422362488741112C7A741BBEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi

> We have the Committers' Workshop upcoming. We can discuss this problem
> there.
That's a good idea.  Christoph will be there from our side. 
Unfortunately I won't make it.

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Mittwoch, 8. Januar 2020 12:20
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Severin Gehwolf
> <sgehwolf at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: Downport 8217338: [Containers] Improve systemd slice memory
> limit support
> 
> On 1/8/20 10:19 AM, Lindenmaier, Goetz wrote:
> > PS: the current process of bringing changes to 11 that were
> > downported by Oracle is extremely cumbersome.  I am doing
> > lots of completely pointless webrevs/reviews, and I have to
> > coordinate with a row of other resources: reviewer, approval,
> > testing. In the end I have 15-30 open changes for downport,
> > some not reviewed, some not approved, some in the testing,
> > some I need to fix as they did not pass testing. This leads to errors.
> > And only from the testing I ever got useful feedback ...
> > It would be much better if I could just push all changes that
> > applied without substantial conflicts after they passed testing.
> 
> We have the Committers' Workshop upcoming. We can discuss this problem
> there.
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From goetz.lindenmaier at sap.com  Wed Jan  8 12:10:56 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 12:10:56 +0000
Subject: [11u] RFR: 8232834: RunTest sometimes fails to produce valid
 exitcode.txt
Message-ID: <VE1PR02MB542203DE214CD211AA8EB43DEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

I had to resolve this manually.
The original change introduces brackets after each
ExecuteWithLog statement.
In 11, these statements look different so that the patch
does not apply.

I checked all occurances of this statement and added
the brackets accordingly.

http://cr.openjdk.java.net/~goetz/wr20/8232834-RunTest_fails-jdk11/01/
https://bugs.openjdk.java.net/browse/JDK-8232834
https://hg.openjdk.java.net/jdk/jdk/rev/f67f4674b466

Best regards,
  Goetz.

From christoph.langer at sap.com  Wed Jan  8 13:20:34 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 Jan 2020 13:20:34 +0000
Subject: [11u] RFR: 8232834: RunTest sometimes fails to produce valid
 exitcode.txt
In-Reply-To: <VE1PR02MB542203DE214CD211AA8EB43DEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB542203DE214CD211AA8EB43DEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB49840A15FD0794E05514929C8A3E0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Goetz,

looks good.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 8. Januar 2020 13:11
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR: 8232834: RunTest sometimes fails to produce
> valid exitcode.txt
> 
> Hi,
> 
> I had to resolve this manually.
> The original change introduces brackets after each
> ExecuteWithLog statement.
> In 11, these statements look different so that the patch
> does not apply.
> 
> I checked all occurances of this statement and added
> the brackets accordingly.
> 
> http://cr.openjdk.java.net/~goetz/wr20/8232834-RunTest_fails-jdk11/01/
> https://bugs.openjdk.java.net/browse/JDK-8232834
> https://hg.openjdk.java.net/jdk/jdk/rev/f67f4674b466
> 
> Best regards,
>   Goetz.

From sgehwolf at redhat.com  Wed Jan  8 14:42:31 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 08 Jan 2020 15:42:31 +0100
Subject: Downport 8217338: [Containers] Improve systemd slice memory
 limit support
In-Reply-To: <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
 <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <430cc145d6545c5ce7fda2386a5c7cb6a8d8907a.camel@redhat.com>

Hi Goetz!

On Wed, 2020-01-08 at 10:19 +0000, Lindenmaier, Goetz wrote:
> Hi Severin, everybody,
> 
> I wanted to follow your plan and let you do this downport. 
> But it was in one of my queues in between of other changes
> that were approved and which I can push.
> Now I accidentally pushed this change along with the others, 
> sorry!

I see. Thanks for the heads-up and being pro-active about it.

> I ran the change through our testing and it's all green. 
> But I did not request downport, so it was not approved (yet).
> Also I thought it needs some discussion as Andrew Haley
> had questioned it in a comment:
> https://bugs.openjdk.java.net/browse/JDK-8217338
> It brings some changes in internal classes in java.base.

Those changes were all in jdk.internal.platform related classes.
Metrics.java is also Linux-only. While it changes the binary
compatibility, I'm not sure this is a concern in practice.

> What should I do? Should I back it out, or should 
> I request downport and only back it out in case downport
> is rejected?

I'd say request downport and if approved keep it in. It was a clean
backport wasn't it? Also, this is in JDK 13 and I haven't heard of
problems.

My concern originally was JDK-8227006 (and friends). With JDK-8232207
the idea of caching for some period of time came up and paved the way
for a fix for JDK-8227006.

Since the plan is to downport this *and* JDK-8232207 it should be fine.
JDK-8232207 fixes the perf regression in hotspot runtime related to
cgroups.

> Me personally am in favour of bringing the cgroup improvements
> to 11. I think it's an important thing for Java to support.

+1

There are more changes in the pipeline, fwiw. Cgroups v2 support being
one.

Thanks,
Severin


From goetz.lindenmaier at sap.com  Wed Jan  8 14:55:15 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 8 Jan 2020 14:55:15 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support
In-Reply-To: <430cc145d6545c5ce7fda2386a5c7cb6a8d8907a.camel@redhat.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
 <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <430cc145d6545c5ce7fda2386a5c7cb6a8d8907a.camel@redhat.com>
Message-ID: <VE1PR02MB5422AFF05113A378FD728102EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Severin,

> ... being pro-active about it.
I guess I was a bit too pro-active :)

But yes, I flagged jdk11u-fix-request. I think this is the 
best to do.

Best regards,
  Goetz.


> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Mittwoch, 8. Januar 2020 15:43
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: Downport 8217338: [Containers] Improve systemd slice memory
> limit support
> 
> Hi Goetz!
> 
> On Wed, 2020-01-08 at 10:19 +0000, Lindenmaier, Goetz wrote:
> > Hi Severin, everybody,
> >
> > I wanted to follow your plan and let you do this downport.
> > But it was in one of my queues in between of other changes
> > that were approved and which I can push.
> > Now I accidentally pushed this change along with the others,
> > sorry!
> 
> I see. Thanks for the heads-up and being pro-active about it.
> 
> > I ran the change through our testing and it's all green.
> > But I did not request downport, so it was not approved (yet).
> > Also I thought it needs some discussion as Andrew Haley
> > had questioned it in a comment:
> > https://bugs.openjdk.java.net/browse/JDK-8217338
> > It brings some changes in internal classes in java.base.
> 
> Those changes were all in jdk.internal.platform related classes.
> Metrics.java is also Linux-only. While it changes the binary
> compatibility, I'm not sure this is a concern in practice.
> 
> > What should I do? Should I back it out, or should
> > I request downport and only back it out in case downport
> > is rejected?
> 
> I'd say request downport and if approved keep it in. It was a clean
> backport wasn't it? Also, this is in JDK 13 and I haven't heard of
> problems.
> 
> My concern originally was JDK-8227006 (and friends). With JDK-8232207
> the idea of caching for some period of time came up and paved the way
> for a fix for JDK-8227006.
> 
> Since the plan is to downport this *and* JDK-8232207 it should be fine.
> JDK-8232207 fixes the perf regression in hotspot runtime related to
> cgroups.
> 
> > Me personally am in favour of bringing the cgroup improvements
> > to 11. I think it's an important thing for Java to support.
> 
> +1
> 
> There are more changes in the pipeline, fwiw. Cgroups v2 support being
> one.
> 
> Thanks,
> Severin


From christoph.langer at sap.com  Wed Jan  8 15:17:00 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 Jan 2020 15:17:00 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support
In-Reply-To: <VE1PR02MB5422362488741112C7A741BBEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
 <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <80ea7560-6aa4-bc09-8c74-7237e7364566@redhat.com>
 <VE1PR02MB5422362488741112C7A741BBEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984F7FA860221F5B32A0EE48A3E0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi,

> > We have the Committers' Workshop upcoming. We can discuss this problem
> > there.
> That's a good idea.  Christoph will be there from our side.
> Unfortunately I won't make it.

Yes, we should definitely take this topic to discussion in the workshop.

/Christoph

> > -----Original Message-----
> > From: Andrew Haley <aph at redhat.com>
> > Sent: Mittwoch, 8. Januar 2020 12:20
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Severin Gehwolf
> > <sgehwolf at redhat.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: Re: Downport 8217338: [Containers] Improve systemd slice
> memory
> > limit support
> >
> > On 1/8/20 10:19 AM, Lindenmaier, Goetz wrote:
> > > PS: the current process of bringing changes to 11 that were
> > > downported by Oracle is extremely cumbersome.  I am doing
> > > lots of completely pointless webrevs/reviews, and I have to
> > > coordinate with a row of other resources: reviewer, approval,
> > > testing. In the end I have 15-30 open changes for downport,
> > > some not reviewed, some not approved, some in the testing,
> > > some I need to fix as they did not pass testing. This leads to errors.
> > > And only from the testing I ever got useful feedback ...
> > > It would be much better if I could just push all changes that
> > > applied without substantial conflicts after they passed testing.
> >
> > We have the Committers' Workshop upcoming. We can discuss this
> problem
> > there.
> >
> > --
> > Andrew Haley  (he/him)
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > https://keybase.io/andrewhaley
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From christoph.langer at sap.com  Wed Jan  8 15:24:57 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 Jan 2020 15:24:57 +0000
Subject: Downport 8217338: [Containers] Improve systemd slice memory limit
 support
In-Reply-To: <VE1PR02MB5422AFF05113A378FD728102EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422A049E574F199943B142BEC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <686ecd80c440e622fbb264245beb668a7d4cea3e.camel@redhat.com>
 <VE1PR02MB5422697C7F14B53C1764A16AEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <430cc145d6545c5ce7fda2386a5c7cb6a8d8907a.camel@redhat.com>
 <VE1PR02MB5422AFF05113A378FD728102EC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984E17EDC72D72F85822CF78A3E0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi,

I just took a glance at the fix and think there is no concern which would necessitate a backout. Especially not at this stage of the April Update release process.

We should definitely also take in JDK-8232207 and JDK-8227006. The former will be done anyway since it's already part of Oracle 11.0.7.

So I'm approving this now. If anybody has objections, don't hesitate to speak up.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 8. Januar 2020 15:55
> To: Severin Gehwolf <sgehwolf at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: Downport 8217338: [Containers] Improve systemd
> slice memory limit support
> 
> Hi Severin,
> 
> > ... being pro-active about it.
> I guess I was a bit too pro-active :)
> 
> But yes, I flagged jdk11u-fix-request. I think this is the
> best to do.
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: Severin Gehwolf <sgehwolf at redhat.com>
> > Sent: Mittwoch, 8. Januar 2020 15:43
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: Re: Downport 8217338: [Containers] Improve systemd slice
> memory
> > limit support
> >
> > Hi Goetz!
> >
> > On Wed, 2020-01-08 at 10:19 +0000, Lindenmaier, Goetz wrote:
> > > Hi Severin, everybody,
> > >
> > > I wanted to follow your plan and let you do this downport.
> > > But it was in one of my queues in between of other changes
> > > that were approved and which I can push.
> > > Now I accidentally pushed this change along with the others,
> > > sorry!
> >
> > I see. Thanks for the heads-up and being pro-active about it.
> >
> > > I ran the change through our testing and it's all green.
> > > But I did not request downport, so it was not approved (yet).
> > > Also I thought it needs some discussion as Andrew Haley
> > > had questioned it in a comment:
> > > https://bugs.openjdk.java.net/browse/JDK-8217338
> > > It brings some changes in internal classes in java.base.
> >
> > Those changes were all in jdk.internal.platform related classes.
> > Metrics.java is also Linux-only. While it changes the binary
> > compatibility, I'm not sure this is a concern in practice.
> >
> > > What should I do? Should I back it out, or should
> > > I request downport and only back it out in case downport
> > > is rejected?
> >
> > I'd say request downport and if approved keep it in. It was a clean
> > backport wasn't it? Also, this is in JDK 13 and I haven't heard of
> > problems.
> >
> > My concern originally was JDK-8227006 (and friends). With JDK-8232207
> > the idea of caching for some period of time came up and paved the way
> > for a fix for JDK-8227006.
> >
> > Since the plan is to downport this *and* JDK-8232207 it should be fine.
> > JDK-8232207 fixes the perf regression in hotspot runtime related to
> > cgroups.
> >
> > > Me personally am in favour of bringing the cgroup improvements
> > > to 11. I think it's an important thing for Java to support.
> >
> > +1
> >
> > There are more changes in the pipeline, fwiw. Cgroups v2 support being
> > one.
> >
> > Thanks,
> > Severin


From sgehwolf at redhat.com  Wed Jan  8 19:10:21 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 08 Jan 2020 20:10:21 +0100
Subject: [11u] RFR: 8232834: RunTest sometimes fails to produce valid
 exitcode.txt
In-Reply-To: <VE1PR02MB542203DE214CD211AA8EB43DEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB542203DE214CD211AA8EB43DEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <4dbc855f246475fa28f18ced21eb70ee527a8cb5.camel@redhat.com>

Hi Goetz,

On Wed, 2020-01-08 at 12:10 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> I had to resolve this manually.
> The original change introduces brackets after each
> ExecuteWithLog statement.
> In 11, these statements look different so that the patch
> does not apply.
> 
> I checked all occurances of this statement and added
> the brackets accordingly.
> 
> http://cr.openjdk.java.net/~goetz/wr20/8232834-RunTest_fails-jdk11/01/
> https://bugs.openjdk.java.net/browse/JDK-8232834
> https://hg.openjdk.java.net/jdk/jdk/rev/f67f4674b466

This seems to have broken running tier1 tests (make run-test-tier1).
I'm getting a bash syntax error message.

>From the webrev:

+	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/jtreg, ( \
 	    $$(JAVA) $$($1_JTREG_LAUNCHER_OPTIONS) \
 	        -Dprogram=jtreg -jar $$(JT_HOME)/lib/jtreg.jar \
 	        $$($1_JTREG_BASIC_OPTIONS) \
@@ -754,7 +754,7 @@
 	        $$($1_TEST_NAME) \
 	    && $$(ECHO) $$$$? > $$($1_EXITCODE) \
 	    || $$(ECHO) $$$$? > $$($1_EXITCODE) \
-	)
+	)))
 
   $1_RESULT_FILE := $$($1_TEST_RESULTS_DIR)/text/stats.txt
 
@@ -828,12 +828,12 @@
 	$$(call LogWarn)
 	$$(call LogWarn, Running test '$$($1_TEST)')
 	$$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))
-	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/test-execution, \
+	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/test-execution, ( \
 	    $$($1_TEST_COMMAND_LINE) \
 	        > >($(TEE) $$($1_TEST_RESULTS_DIR)/test-output.txt) \
 	    && $$(ECHO) $$$$? > $$($1_EXITCODE) \
 	    || $$(ECHO) $$$$? > $$($1_EXITCODE) \
-	)
+	)))

This is different from the JDK HEAD patch. Adds one too many closing brackets.

Thanks,
Severin




From sgehwolf at redhat.com  Thu Jan  9 09:18:36 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 09 Jan 2020 10:18:36 +0100
Subject: [11u] RFR: 8232834: RunTest sometimes fails to produce valid
 exitcode.txt
In-Reply-To: <4dbc855f246475fa28f18ced21eb70ee527a8cb5.camel@redhat.com>
References: <VE1PR02MB542203DE214CD211AA8EB43DEC3E0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <4dbc855f246475fa28f18ced21eb70ee527a8cb5.camel@redhat.com>
Message-ID: <809471db72190e22dd3fb9d4b2a3daf3d6326d24.camel@redhat.com>

On Wed, 2020-01-08 at 20:10 +0100, Severin Gehwolf wrote:
> > http://cr.openjdk.java.net/~goetz/wr20/8232834-RunTest_fails-jdk11/01/
> > https://bugs.openjdk.java.net/browse/JDK-8232834
> > https://hg.openjdk.java.net/jdk/jdk/rev/f67f4674b466
> 
> This seems to have broken running tier1 tests (make run-test-tier1).
> I'm getting a bash syntax error message.
> 
> From the webrev:
> 
> +	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/jtreg, ( \
>  	    $$(JAVA) $$($1_JTREG_LAUNCHER_OPTIONS) \
>  	        -Dprogram=jtreg -jar $$(JT_HOME)/lib/jtreg.jar \
>  	        $$($1_JTREG_BASIC_OPTIONS) \
> @@ -754,7 +754,7 @@
>  	        $$($1_TEST_NAME) \
>  	    && $$(ECHO) $$$$? > $$($1_EXITCODE) \
>  	    || $$(ECHO) $$$$? > $$($1_EXITCODE) \
> -	)
> +	)))
>  
>    $1_RESULT_FILE := $$($1_TEST_RESULTS_DIR)/text/stats.txt
>  
> @@ -828,12 +828,12 @@
>  	$$(call LogWarn)
>  	$$(call LogWarn, Running test '$$($1_TEST)')
>  	$$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR))
> -	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/test-execution, \
> +	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/test-execution, ( \
>  	    $$($1_TEST_COMMAND_LINE) \
>  	        > >($(TEE) $$($1_TEST_RESULTS_DIR)/test-output.txt) \
>  	    && $$(ECHO) $$$$? > $$($1_EXITCODE) \
>  	    || $$(ECHO) $$$$? > $$($1_EXITCODE) \
> -	)
> +	)))
> 
> This is different from the JDK HEAD patch. Adds one too many closing brackets.

I've opened a 11-only bug for this here. RFR will be proposed shortly:
https://bugs.openjdk.java.net/browse/JDK-8236848

Thanks,
Severin


From sgehwolf at redhat.com  Thu Jan  9 09:30:24 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 09 Jan 2020 10:30:24 +0100
Subject: [11u] RFR: 8236848: [JDK 11u] make run-test-tier1 fails after
 backport of JDK-8232834
Message-ID: <e6970404e9d0edfbead7157f36f2e285ce62b7cd.camel@redhat.com>

Hi,

Please review this OpenJDK 11.0.7-dev only fix. 'make run-test-*' is
currently broken after the backport of JDK-8232834. Fails with:

/usr/bin/bash: -c: line 0: syntax error near unexpected token `)' 

Fix is rather trivial and adjusts the backport to match what's in
jdk/jdk by removing the extra closing brackets so opening and closing
brackets are balanced again.

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

Thoughts?

Thanks,
Severin


From neugens at redhat.com  Thu Jan  9 09:34:13 2020
From: neugens at redhat.com (Mario Torre)
Date: Thu, 9 Jan 2020 10:34:13 +0100
Subject: [11u] RFR: 8236848: [JDK 11u] make run-test-tier1 fails after
 backport of JDK-8232834
In-Reply-To: <e6970404e9d0edfbead7157f36f2e285ce62b7cd.camel@redhat.com>
References: <e6970404e9d0edfbead7157f36f2e285ce62b7cd.camel@redhat.com>
Message-ID: <CAJwKKmZdmrX+VFu8L7JqA3N+6JVGVwE+d09CudtWSbX=ZToc-Q@mail.gmail.com>

Hi Severin,

Good catch, the fix looks good to me.

Cheers,
Mario

On Thu, Jan 9, 2020 at 10:31 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi,
>
> Please review this OpenJDK 11.0.7-dev only fix. 'make run-test-*' is
> currently broken after the backport of JDK-8232834. Fails with:
>
> /usr/bin/bash: -c: line 0: syntax error near unexpected token `)'
>
> Fix is rather trivial and adjusts the backport to match what's in
> jdk/jdk by removing the extra closing brackets so opening and closing
> brackets are balanced again.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236848
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236848/01/webrev/
>
> Thoughts?
>
> Thanks,
> Severin
>


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


From sgehwolf at redhat.com  Thu Jan  9 09:42:06 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 09 Jan 2020 10:42:06 +0100
Subject: [11u] RFR: 8236848: [JDK 11u] make run-test-tier1 fails after
 backport of JDK-8232834
In-Reply-To: <CAJwKKmZdmrX+VFu8L7JqA3N+6JVGVwE+d09CudtWSbX=ZToc-Q@mail.gmail.com>
References: <e6970404e9d0edfbead7157f36f2e285ce62b7cd.camel@redhat.com>
 <CAJwKKmZdmrX+VFu8L7JqA3N+6JVGVwE+d09CudtWSbX=ZToc-Q@mail.gmail.com>
Message-ID: <2ddb7f113c42ef86ecdd0641acb259687acff7a5.camel@redhat.com>

On Thu, 2020-01-09 at 10:34 +0100, Mario Torre wrote:
> Hi Severin,
> 
> Good catch, the fix looks good to me.

Thanks for the quick review, Mario! I've added the jdk11u-fix-request
label and will push once approved.

Thanks,
Severin

> Cheers,
> Mario
> 
> On Thu, Jan 9, 2020 at 10:31 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi,
> > 
> > Please review this OpenJDK 11.0.7-dev only fix. 'make run-test-*' is
> > currently broken after the backport of JDK-8232834. Fails with:
> > 
> > /usr/bin/bash: -c: line 0: syntax error near unexpected token `)'
> > 
> > Fix is rather trivial and adjusts the backport to match what's in
> > jdk/jdk by removing the extra closing brackets so opening and closing
> > brackets are balanced again.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8236848
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236848/01/webrev/
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> 
> 


From goetz.lindenmaier at sap.com  Thu Jan  9 12:32:54 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 9 Jan 2020 12:32:54 +0000
Subject: [11u] RFR: 8236848: [JDK 11u] make run-test-tier1 fails after
 backport of JDK-8232834
In-Reply-To: <2ddb7f113c42ef86ecdd0641acb259687acff7a5.camel@redhat.com>
References: <e6970404e9d0edfbead7157f36f2e285ce62b7cd.camel@redhat.com>
 <CAJwKKmZdmrX+VFu8L7JqA3N+6JVGVwE+d09CudtWSbX=ZToc-Q@mail.gmail.com>,
 <2ddb7f113c42ef86ecdd0641acb259687acff7a5.camel@redhat.com>
Message-ID: <EB56022B-E560-4C1B-BA27-050740C1CF09@sap.com>

Hi,

First sorry for breaking this.
Looks good to me.

Best regards,
  Goetz

> Am 09.01.2020 um 10:43 schrieb Severin Gehwolf <sgehwolf at redhat.com>:
> 
>> On Thu, 2020-01-09 at 10:34 +0100, Mario Torre wrote:
>> Hi Severin,
>> 
>> Good catch, the fix looks good to me.
> 
> Thanks for the quick review, Mario! I've added the jdk11u-fix-request
> label and will push once approved.
> 
> Thanks,
> Severin
> 
>> Cheers,
>> Mario
>> 
>>> On Thu, Jan 9, 2020 at 10:31 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>>> Hi,
>>> 
>>> Please review this OpenJDK 11.0.7-dev only fix. 'make run-test-*' is
>>> currently broken after the backport of JDK-8232834. Fails with:
>>> 
>>> /usr/bin/bash: -c: line 0: syntax error near unexpected token `)'
>>> 
>>> Fix is rather trivial and adjusts the backport to match what's in
>>> jdk/jdk by removing the extra closing brackets so opening and closing
>>> brackets are balanced again.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236848
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236848/01/webrev/
>>> 
>>> Thoughts?
>>> 
>>> Thanks,
>>> Severin
>>> 
>> 
>> 
> 

From sgehwolf at redhat.com  Thu Jan  9 12:37:30 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 09 Jan 2020 13:37:30 +0100
Subject: [11u] RFR: 8236848: [JDK 11u] make run-test-tier1 fails after
 backport of JDK-8232834
In-Reply-To: <EB56022B-E560-4C1B-BA27-050740C1CF09@sap.com>
References: <e6970404e9d0edfbead7157f36f2e285ce62b7cd.camel@redhat.com>
 <CAJwKKmZdmrX+VFu8L7JqA3N+6JVGVwE+d09CudtWSbX=ZToc-Q@mail.gmail.com>
 ,<2ddb7f113c42ef86ecdd0641acb259687acff7a5.camel@redhat.com>
 <EB56022B-E560-4C1B-BA27-050740C1CF09@sap.com>
Message-ID: <32082a9ea320bf07be9364b229ef71a18f7ed0f2.camel@redhat.com>

On Thu, 2020-01-09 at 12:32 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> First sorry for breaking this.
> Looks good to me.

Thanks for the review, Goetz!

Cheers,
Severin

> Best regards,
>   Goetz
> 
> > Am 09.01.2020 um 10:43 schrieb Severin Gehwolf <sgehwolf at redhat.com>:
> > 
> > > On Thu, 2020-01-09 at 10:34 +0100, Mario Torre wrote:
> > > Hi Severin,
> > > 
> > > Good catch, the fix looks good to me.
> > 
> > Thanks for the quick review, Mario! I've added the jdk11u-fix-request
> > label and will push once approved.
> > 
> > Thanks,
> > Severin
> > 
> > > Cheers,
> > > Mario
> > > 
> > > > On Thu, Jan 9, 2020 at 10:31 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > > > Hi,
> > > > 
> > > > Please review this OpenJDK 11.0.7-dev only fix. 'make run-test-*' is
> > > > currently broken after the backport of JDK-8232834. Fails with:
> > > > 
> > > > /usr/bin/bash: -c: line 0: syntax error near unexpected token `)'
> > > > 
> > > > Fix is rather trivial and adjusts the backport to match what's in
> > > > jdk/jdk by removing the extra closing brackets so opening and closing
> > > > brackets are balanced again.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236848
> > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236848/01/webrev/
> > > > 
> > > > Thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 


From shade at redhat.com  Sun Jan 12 10:36:44 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Sun, 12 Jan 2020 11:36:44 +0100
Subject: jdk-updates/jdk14u
Message-ID: <b8c346b3-6dc1-f459-3264-a4a7cd6e4d48@redhat.com>

Hi,

I believe it was discussed at one of the previous OCWs: when does jdk-updates/jdk{$X}u get created?

IIRC, the agreed expectation was "at the time jdk{$X} forks for stabilization, in order to collect
fixes/backports that do not fit RDP1, RDP2, RC criterias for inclusion into jdk/jdk{$X}". I cannot
find this on record anywhere though.

With that in mind, is there a plan to create jdk-updates/jdk14u soon?

-- 
Thanks,
-Aleksey


From rob.mckenna at oracle.com  Mon Jan 13 14:40:58 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 13 Jan 2020 14:40:58 +0000
Subject: jdk-updates/jdk14u
In-Reply-To: <b8c346b3-6dc1-f459-3264-a4a7cd6e4d48@redhat.com>
References: <b8c346b3-6dc1-f459-3264-a4a7cd6e4d48@redhat.com>
Message-ID: <20200113144058.GD9097@yoga>

The fork was requested from ops some time ago. A reminder was sent
recently and I expect the fork to be ready shortly.

    -Rob

On 12/01/20 11:36, Aleksey Shipilev wrote:
> Hi,
> 
> I believe it was discussed at one of the previous OCWs: when does jdk-updates/jdk{$X}u get created?
> 
> IIRC, the agreed expectation was "at the time jdk{$X} forks for stabilization, in order to collect
> fixes/backports that do not fit RDP1, RDP2, RC criterias for inclusion into jdk/jdk{$X}". I cannot
> find this on record anywhere though.
> 
> With that in mind, is there a plan to create jdk-updates/jdk14u soon?
> 
> -- 
> Thanks,
> -Aleksey
> 

From rob.mckenna at oracle.com  Tue Jan 14 14:24:50 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 14 Jan 2020 14:24:50 +0000
Subject: [14u Communication] jdk14u repo available
In-Reply-To: <20190624154130.GB19779@vimes>
References: <20190624154130.GB19779@vimes>
Message-ID: <20200114142450.GG9097@yoga>

I'd like to announce the availibility of the JDK 14 Updates forest at:

http://hg.openjdk.java.net/jdk-updates/jdk14u/

Thanks,

    -Rob

From gnu.andrew at redhat.com  Tue Jan 14 22:26:45 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 14 Jan 2020 22:26:45 +0000
Subject: [RFR] [11u] 11.0.6+10 / 11.0.6-ga
Message-ID: <a3d71fe4-3275-fea8-80ac-aabf411559ae@redhat.com>

Here are the remaining changes for the jdk11u repository:

Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.6/

Changes in jdk-11.0.6+10:
  - S8220598: Malformed copyright year range in a few files in java.base
  - S8224909, CVE-2020-2583: Unlink Set of LinkedHashSets
  - S8225261: Better method resolutions
  - S8225279: Better XRender interpolation
  - S8226352, CVE-2020-2590: Improve Kerberos interop capabilities
  - S8227758: More valid PKIX processing
  - S8227816: More Colorful ICC profiles
  - S8228548, CVE-2020-2593: Normalize normalization for all
  - S8229728: Implement negotiation parameters
  - S8229951, CVE-2020-2601: Better Ticket Granting Services
  - S8230279: Improve Pack200 file reading
  - S8230318: Better trust store usage
  - S8230967: Improve Registry support of clients
  - S8231139: Improved keystore support
  - S8231422, CVE-2020-2604: Better serial filter handling
  - S8231780, CVE-2020-2655: Better TLS messaging support
  - S8231790: Provide better FileSystemProviders
  - S8232419: Improve Registry registration
  - S8234037, CVE-2020-2654: Improve Object Identifier Processing

The result is tagged 11.0.6+10 and 11.0.6-ga.

Ok to push?

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  Tue Jan 14 22:35:29 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 14 Jan 2020 23:35:29 +0100
Subject: [RFR] [11u] 11.0.6+10 / 11.0.6-ga
In-Reply-To: <a3d71fe4-3275-fea8-80ac-aabf411559ae@redhat.com>
References: <a3d71fe4-3275-fea8-80ac-aabf411559ae@redhat.com>
Message-ID: <f7c8cb78-2975-8f13-419c-79c477d5361a@redhat.com>

On 1/14/20 11:26 PM, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.6/

Looks good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Tue Jan 14 22:51:34 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 14 Jan 2020 22:51:34 +0000
Subject: [RFR] [11u] 11.0.6+10 / 11.0.6-ga
In-Reply-To: <f7c8cb78-2975-8f13-419c-79c477d5361a@redhat.com>
References: <a3d71fe4-3275-fea8-80ac-aabf411559ae@redhat.com>
 <f7c8cb78-2975-8f13-419c-79c477d5361a@redhat.com>
Message-ID: <06461a26-602f-e766-9454-ae05d6c49e25@redhat.com>

On 14/01/2020 22:35, Aleksey Shipilev wrote:
> On 1/14/20 11:26 PM, Andrew John Hughes wrote:
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.6/
> 
> Looks good.
> 
>> Ok to push?
> 
> Yes.
> 

Thanks, pushed.
-- 
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 Jan 15 05:52:24 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 15 Jan 2020 05:52:24 +0000
Subject: OpenJDK 11.0.6 Released
Message-ID: <d67290f6-9c07-89b7-f877-39a04e3ffaf2@redhat.com>

We are pleased to announce the release of OpenJDK 11.0.6.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.6-ga.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.6-ga.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

6a225f713d69f25303fed28e2f5d533b30d13b20b2b2088366b98ba265306147
openjdk-11.0.6-ga.tar.xz
0627198e8e2a83ba436458d2d25716c96296f74cb8e1e46112dc3442a2f6ec8d
openjdk-11.0.6-ga.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.6-ga.sha256

What's New?
===========
* Security fixes
  - S8224909, CVE-2020-2583: Unlink Set of LinkedHashSets
  - S8225261: Better method resolutions
  - S8225279: Better XRender interpolation
  - S8226352, CVE-2020-2590: Improve Kerberos interop capabilities
  - S8227758: More valid PKIX processing
  - S8227816: More Colorful ICC profiles
  - S8228548, CVE-2020-2593: Normalize normalization for all
  - S8229728: Implement negotiation parameters
  - S8229951, CVE-2020-2601: Better Ticket Granting Services
  - S8230279: Improve Pack200 file reading
  - S8230318: Better trust store usage
  - S8230967: Improve Registry support of clients
  - S8231139: Improved keystore support
  - S8231422, CVE-2020-2604: Better serial filter handling
  - S8231780, CVE-2020-2655: Better TLS messaging support
  - S8231790: Provide better FileSystemProviders
  - S8232419: Improve Registry registration
  - S8234037, CVE-2020-2654: Improve Object Identifier Processing
* Other changes
  - S8016914: CoreDocumentImpl.setXmlVersion NPE
  - S8048556: Unnecessary GCLocker-initiated young GCs
  - S8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
  - S8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported
  - S8144125: [macOS]
java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java
failed automatically
  - S8146238: [macosx] Java2D Queue Flusher crash on OSX after switching
between user accounts
  - S8176837: SunPKCS11 provider needs to check more details on PKCS11
Mechanism
  - S8185898: setRequestProperty(key, null) results in HTTP header
without colon in request
  - S8190737: use unicode version of the canonicalize() function to
handle long path on windows
  - S8191521: handle long relative path specified in -Xbootclasspath/a
on windows
  - S8193255: Root Certificates should be stored in text format and
assembled at build time
  - S8193325: StackFrameInfo::getByteCodeIndex returns wrong value if
bci > 32767
  - S8198882: Add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/
  - S8200381: Typos in javadoc - missing verb "be" and alike
  - S8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed
with OutOfMemoryError
  - S8205516: JFR tool
  - S8206115: Use shared macros for JavaClasses::compute_offsets and
MetaspaceShared::serialize_well_known_classes
  - S8207263: Store the Configuration for system modules into CDS archive.
  - S8207922: ctw of jdk.security.auth failed with "Unexpected zero exit
codebefore finishing all compilations"
  - S8208179: Devanagari not shown with logical fonts on Windows after
removal of Lucida Sans from JDK
  - S8208236: [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout
  - S8208364:
java/lang/reflect/callerCache/ReflectionCallerCacheTest.java missing
module dependencies declaration
  - S8208582: Introduce native oop barriers in C1 for OopHandle
  - S8208601: Introduce native oop barriers in C2 for OopHandle
  - S8209003: Consolidate use of empty collections in java.lang.module
  - S8209120: Archive the Integer.IntegerCache
  - S8209178: Proxied HttpsURLConnection doesn't send BODY when retrying
POST request
  - S8209545: Simplify HeapShared::archive_module_graph_objects
  - S8209647: constantPoolHandle::constantPoolHandle(ConstantPool*) when
precompiled header is disabled
  - S8209691: Allow MemBar on single memory slice
  - S8209771: jdk.test.lib.Utils::runAndCheckException error
  - S8209790: SA tools not providing option to connect to debug server
  - S8209833: C2 compilation fails with
"assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all
collected exceptions must come from the same place"
  - S8209835: Aarch64: elide barriers on all volatile operations
  - S8209972: [GRAAL] Don't run RTM tests with Graal
  - S8210158: Accessorize JFR getEventWriter() intrinsics
  - S8210384: SunLayoutEngine.isAAT() font is expensive on MacOS
  - S8210387: C2 compilation fails with "assert(node->_last_del ==
_last) failed: must have deleted the edge just produced"
  - S8210403: Refactor java.util.Locale:i18n shell tests to plain java tests
  - S8210559: ClassLoaderData Symbols can leak
  - S8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7
  - S8210789: langtools/tools/javac/T8152616.java missing @modules
  - S8211037: Load jib jars dynamically from JibArtifactManager
  - S8211147: Incorrect comparator
com.sun.beans.introspect.MethodInfo.MethodOrder
  - S8211385: (zipfs) ZipDirectoryStream yields a stream of absolute
paths when directory is relative
  - S8211740: [AOT] -XX:AOTLibrary doesn't accept windows path
  - S8211866: TLS 1.3 CertificateRequest message sometimes offers
disallowed signature algorithms
  - S8211919: ZipDirectoryStream should provide a stream of paths that
are relative to the directory
  - S8211992: GraphicsConfiguration.getDevice().getDisplayMode() causes
JVM crash on Mac
  - S8212028: Use run-test makefile framework for testing in Oracle's Mach5
  - S8212071: Need to set the FreeType LCD Filter to reduce fringing.
  - S8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java
timed out
  - S8212673: jtreg/applications/runthese/RunThese30M.java fails in C2
with "assert(!had_error) failed: bad dominance"
  - S8212738: Incorrectly named signature scheme ecdsa_secp512r1_sha512
  - S8212752: Typo in SSL log message related to inactive/disabled
signature scheme
  - S8213005: Missing symbols in hs_err files on Windows after JDK-8212028
  - S8213008: Cipher with UNWRAP_MODE should support the generation of
an AES key type
  - S8213014: Crash in CompileBroker::make_thread due to OOM
  - S8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails
  - S8213381: Hook to allow GC to inject Node::Ideal() calls
  - S8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash
  - S8213568: Typo in java/awt/GraphicsEnvironment/LoadLock/GE_init5.java
  - S8213604: Fix missing includes after JDK-8212673
  - S8214046: [macosx] Undecorated Frame does not Iconify when set to
  - S8214052: [testbug]
vmTestbase/vm/compiler/CodeCacheInfoOnCompilation - wrong shell used
  - S8214098: sun.security.ssl.HandshakeHash.T12HandshakeHash
constructor check backwards.
  - S8214311: dtrace gensrc has missing dependencies
  - S8214315: G1: fatal error: acquiring lock SATB_Q_FL_lock/1 out of
order with lock tty_lock/0
  - S8214321: Misleading code in SSLCipher
  - S8214542: JFR: Old Object Sample event slow on a deep heap in debug
builds
  - S8214750: Unnecessary <p> tags in jfr classes
  - S8214773: Replace use of thread unsafe strtok
  - S8214896: JFR Tool left files behind
  - S8214925: JFR tool fails to execute
  - S8214975: No hs-err file if fatal error is raised during dynamic
initialization
  - S8215032: Support Kerberos cross-realm referrals (RFC 6806)
  - S8215105: java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java:
Wrong Pixel Color
  - S8215200: IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow
  - S8215411: some GetByteArrayElements calls miss corresponding Release
  - S8215449: Several tests failing when jtreg run with
-vmoption:--illegal-access=deny
  - S8215524: Finished message validation failure should be
decrypt_error alert
  - S8215699: -Xlog::file cannot be used with named pipe
  - S8215708: ZGC: Add missing LoadBarrierNode::size_of()
  - S8215755: ZGC: split_barrier_thru_phi: check number of inputs of phi
  - S8215771: The jfr tool should pretty print reference chains
  - S8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed
on de_DE and ja_JP locale.
  - S8216064: -XX:StartFlightRecording:settings= doesn't work properly
  - S8216135: C2 assert(!had_error) failed: bad dominance
  - S8216283: Allow shorter method sampling interval than 10 ms
  - S8216363: NullPointerException in java.util.logging.Handler#isLoggable
  - S8216426: Usage of array placement new may lead to memory corruption
  - S8216561: HttpClient: The logic of retry on connect exception is
inverted
  - S8216977: ShowHiddenFrames use in
java_lang_StackTraceElement::fill_in appears broken
  - S8217362: Emergency dump does not work when disk=false is set
  - S8217610: TLSv1.3 fail with ClassException when EC keys are stored
in PKCS11
  - S8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11
  - S8218468: Load barrier slow path node should be MachTypeNode
  - S8218580: endpoint identification algorithm should be case-insensitive
  - S8218935: Make jfr strncpy uses GCC 8.x friendly
  - S8219504: Test for JDK-8211435 can be run on all platforms
  - S8219914: Change the environment variable for Java Access Bridge
logging to have a directory.
  - S8220175: serviceability/dcmd/framework/VMVersionTest.java fails
with a timeout
  - S8220231: Cache HarfBuzz face object for same font's text layout calls
  - S8220352: Crash with assert(external_guard || result != __null)
failed: Invalid JNI handle
  - S8220394: bufferedStream does not honor size limit
  - S8220474: Incorrect GPL header in
src/java.instrument/share/classes/java/lang/instrument/package-info.java
  - S8220476: Incorrect GPL header in
src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java
  - S8220528: [AIX] Fix basic Xinerama and Xrender functionality
  - S8220555: JFR tool shows potentially misleading message when it
cannot access a file
  - S8220598: Malformed copyright year range in a few files in java.base
  - S8221092: UseAVX=3 has performance degredation on Skylake (X7)
processors
  - S8221172: SunEC specific test is not limited to SunEC
  - S8221246: NullPointerException within Win32ShellFolder2
  - S8221395: HttpClient leaving connections in CLOSE_WAIT state until
Java process ends
  - S8221406: Windows 32bit build error in NetworkInterface_winXP.c
  - S8221456: nmethod::make_unloaded() clears _method member too early
  - S8221532: Incorrect copyright header in FileSystemSupport_md.c
  - S8221539: [metaspace] Improve MetaspaceObj::is_metaspace_obj() and
friends
  - S8221569: JFR tool produces incorrect output when both --categories
and --events are specified
  - S8221711: [TESTBUG] create more tests for JFR in container environment
  - S8221913: Add GC.selected() jtreg-ext function
  - S8222015: Small VM.metaspace improvements
  - S8222440: (zipfs) JarFileSystem does not correctly handle versioned
entries if no root entry is present
  - S8222529: sun.jdwp.listenerAddress agent property uses wrong encoding
  - S8222807: Address iteration with invalid ZIP header entries
  - S8222888: [TESTBUG] docker/TestJFREvents.java fails due to
"RuntimeException: JAVA_MAIN_CLASS_ is not defined"
  - S8223438: add VirtualizationInformation JFR event
  - S8223490: Optimize search algorithm for determining default time zone
  - S8223697: jfr tool can't format duration values greater than 1 minute
  - S8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java on
more platforms
  - S8224152: [macOS] ProblemList tests that leave rubbish on the screen
  - S8224157: BCEL: update to version 6.3.1
  - S8224172: assert(jfr_is_event_enabled(id)) failed: invariant
  - S8224193: stringStream should not use Resouce Area
  - S8224217: RecordingInfo should use textual representation of path
  - S8224502: [TESTBUG] JDK docker test TestSystemMetrics.java fails
with access issues and OOM
  - S8224505: TestQuotedLogOutput failure after ProcessBuilder changes
  - S8224538: LoadBarrierNode::common_barrier must check address
  - S8224958: add os::dll_load calls to event log
  - S8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when
change keybord map
  - S8225225: stringStream internal buffer should always be zero terminated
  - S8225392: Comparison builds are failing due to cacerts file
  - S8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)
  - S8225694: Destination option missing in FlightRecorderMXBeanImpl
  - S8225695: 32-bit build failures after JDK-8080462 (Update SunPKCS11
provider with PKCS11 v2.40 support)
  - S8225745: NoSuchAlgorithmException exception for SHA256withECDSA
with RSASSA-PSS support
  - S8226513: JEditorPane is shown with incorrect size
  - S8226651: Setting the mgfHash in CK_RSA_PKCS_PSS_PARAMS has no effect
  - S8226719: Kerberos login to Windows 2000 failed with "Inappropriate
type of checksum in message"
  - S8226779: [TESTBUG] Test JFR API from Java agent
  - S8226869: Test java/util/Locale/LocaleProvidersRun.java should
enable assertions
  - S8226899: Problemlist compiler/rtm tests
  - S8227031: Print NMT statistics on fatal errors
  - S8227032: MetaspaceUtils::print_report crashes when called before
initialization
  - S8227035: JVM::printFlags fails in native OOM situations
  - S8227061: KDC.java test behaves incorrectly when AS-REQ contains a
PAData not PA-ENC-TS-ENC
  - S8227086: Use AS_NO_KEEPALIVE loads in HeapDumper
  - S8227127: Era designator not displayed correctly using the COMPAT
provider
  - S8227338: templateInterpreter.cpp: copy_table() needs to be safer
  - S8227368: EnumSet.class serialization broken in JDK 9+
  - S8227381: GSS login fails with PREAUTH_FAILED
  - S8227391: Update double-conversion to version 3.1.5
  - S8227397: Add --with-extra-asflags configure option
  - S8227411: TestTimeMultiple.java failed "assert(!lease()) failed:
invariant"
  - S8227435: Perf::attach() should not throw a java.lang.Exception
  - S8227437: S4U2proxy cannot continue because server's TGT cannot be found
  - S8227439: Turn off AOT by default
  - S8227605: Kitchensink fails "assert((((klass)->trace_id() &
(JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant"
  - S8227642: [TESTBUG] Make docker tests podman compatible
  - S8228368: avoid incompatible pointer to integer conversion
initializing gint in gtk2_interface
  - S8228434: jdk/net/Sockets/Test.java fails after JDK-8227642
  - S8228465: HOST locale provider holds wrong era name for
GregorianCalendar in US locale
  - S8228625: [TESTBUG] sun/tools/jhsdb/JShellHeapDumpTest.java fails
with RuntimeException 'JShellToolProvider' missing from stdout/stderr
  - S8228645: Don't run sun/security/pkcs11/Cipher/TestKATForGCM.java on
buggy NSS solaris versions
  - S8228687: [TESTBUG] exclude Container tests from hotspot_misc group
  - S8228772: C2 compilation fails due to unschedulable graph if
DominatorSearchLimit is reached
  - S8228834: Regression caused by JDK-8214542 not installing complete
checkpoint data to candidates
  - S8228835: Memory leak in PKCS11 provider when using AES GCM
  - S8228888: C2 compilation fails with assert "m has strange control"
  - S8228902: add os::dll_load to the unified logging os category
  - S8229016: C2 scalarization crashes with assert(node->Opcode() ==
Op_CastP2X) failed: ConvP2XNode required
  - S8229020: Failure on CPUs allowing loads reordering:
assert(_tasks[t] == 1) failed: What else?
  - S8229022: BufferedReader performance can be improved by using
StringBuilder
  - S8229156: ProblemList
gc/stress/gclocker/TestExcessGCLockerCollections.java
  - S8229169: False failure of GenericTaskQueue::pop_local on
architectures with weak memory model
  - S8229182: runtime/containers/docker/TestMemoryAwareness.java test
fails on SLES12
  - S8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4
  - S8229284: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails
for - memory:getMemoryUsage
  - S8229408: Bump update version for OpenJDK: jdk-11.0.6
  - S8229420: [Redo] jstat reports incorrect values for OU for CMS GC
  - S8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant
  - S8229450: C2 compilation fails with assert(found_sfpt) failed
  - S8229483: Sinking load out of loop may trigger: assert(found_sfpt)
failed: no node in loop that's not input to safepoint
  - S8229496: SIGFPE (division by zero) in C2 OSR compiled method
  - S8229515: [macos] access to window property of NSView on wrong thread
  - S8229701: aarch64: C2 OSR compilation fails with "shouldn't process
one node several times" in final graph reshaping
  - S8229800: WindowsServerCore 1809 does not provide d2d1.dll library
required by awt.dll
  - S8229810: [macos] NullPointerException getting bounds of
GraphicsConfiguration
  - S8229872: (fs) Increase buffer size used with getmntent
  - S8229899: Make java.io.File.isInvalid() less racy
  - S8230061: # assert(mode == ControlAroundStripMined && use == sfpt)
failed: missed a node
  - S8230062: assert(i == p->size()-1) failed: must be last element of
the pack
  - S8230110: TestLinkageErrorInGenerateOopMap times out
  - S8230115: Problemlist JFR TestNetworkUtilization test
  - S8230238: Add another regression test for JDK-8134739
  - S8230303: JDB hangs when running monitor command
  - S8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return
false if n is not in the CG
  - S8230376: [TESTBUG] runtime/StackTrace/HiddenFrameTest.java fails
with release VM
  - S8230388: Problemlist additional compiler/rtm tests
  - S8230466: check malloc/calloc results in jdk.hotspot.agent
  - S8230646: Epsilon does not extend TLABs to max size
  - S8230669: [s390] C1: assert(is_bound() || is_unused()) failed: Label
was never bound to a location, but it was used as a jmp target
  - S8230671: x86_32 build failures after JDK-8229496
  - S8230711: ConnectionGraph::unique_java_object(Node* N) return NULL
if n is not in the CG
  - S8230728: Thin stroked shapes are not rendered if affine transform
has flip bit
  - S8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in
early return
  - S8230782: Robot.createScreenCapture() fails if ?awt.robot.gtk? is
set to false
  - S8230813: Add JDK-8010500 to
compiler/loopopts/superword/TestFuzzPreLoop.java bug list
  - S8230856: Java_java_net_NetworkInterface_getByName0 on unix misses
ReleaseStringUTFChars in early return
  - S8230861: missing ReleaseStringUTFChars in
Java_sun_security_pkcs11_wrapper_PKCS11_connect
  - S8230873: [AIX] GUI app does not work with UTF-8 locale on minimum
software requirements
  - S8230881: serviceability/sa/TestJmapCore tests fail with
java.lang.RuntimeException: Could not find dump file
  - S8230900: missing ReleaseStringUTFChars in java.desktop native code
  - S8230901: missing ReleaseStringUTFChars in serviceability native code
  - S8230923: SunJSSE is not properly initialized in FIPS mode from a
configuration file
  - S8230943: False deadlock detection with -XX:+CIPrintCompileQueue
after JDK-8163511
  - S8231055: C2: arraycopy with same non escaping src and dest but
different positions causes wrong execution
  - S8231084: Large performance regression in SwingMark TextArea in 14-b13
  - S8231085: C2/GC: Better GC-interface for expanding clone
  - S8231098: (tz) Upgrade time-zone data to tzdata2019c
  - S8231124: Missing closedir call with JDK-8223490
  - S8231201: hs_err should print coalesced safepoint operations in
Events section
  - S8231222: fix pkcs11 P11_DEBUG guarded native traces
  - S8231223: C2's conditional move optimization fails with
assert(bol->Opcode() == Op_Bool) failed
  - S8231247: (zipfs) Test failure in
jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807
  - S8231254: (fs) Add test for macOS Catalina changes to protect system
software
  - S8231294: ZGC:
vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted002 fails
  - S8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails
  - S8231318: Several compiler/aot tests fail for JDK11 on Windows when
only MSVC 2017 is installed
  - S8231336: Corrupted option dialog in JTHarness with JDK14b13
  - S8231403: [ppc]: Align ReservedCodeCacheSize default value with
other platforms
  - S8231457: Asserts on AIX because os::elapsed_counter() is not monotonic
  - S8231503: [TESTBUG] compiler/{jvmci,aot} tests should not run with
GCs that do not support JVMCI/AOT
  - S8231620: assert(bol->is_Bool()) crash during split if due to
FastLockNode
  - S8231665: 8231055 broke escapeAnalysis/TestSelfArrayCopy.java
  - S8231693: Backout "8230728: Thin stroked shapes are not rendered if
affine transform has flip bit" from jdk11u
  - S8231751: on aix handle Power 9 in os::get_summary_cpu_info
  - S8231770: Test java/util/zip/FlaterTest.java fails with -Xcheck:jni
  - S8231885: Fix/remove malformed assert in os_windows.cpp
  - S8231887: ComodoCA.java fails because certificate was revoked
  - S8231930: Windows build fails after JDK-8191521
  - S8231949: [PPC64, s390]: Make async profiling more reliable
  - S8231988: Unexpected test result caused by C2
IdealLoopTree::do_remove_empty_loop
  - S8231991: Mouse wheel change focus on awt/swing windows
  - S8232005: [s390, PPC64] More exception checks missing in interpreter
  - S8232019: Add LuxTrust certificate updates to the existing root program
  - S8232051: Epsilon should warn about Xms/Xmx/AlwaysPreTouch configuration
  - S8232052: use string literal for format string when handling
PauseAtStartupFile
  - S8232178: MacVolumesTest failed after upgrade to MacOS Catalina
  - S8232381: add result NULL-checking to freetypeScaler.c
  - S8232539: SIGSEGV in C2 Node::unique_ctrl_out
  - S8232592: <Unknown compiled code> is shown in jstack mixed mode
  - S8232874: Add missing test for 8230062
  - S8232879: Writing out data with the Zip File System leads to a CRC
failure
  - S8232984: Upgrading Joni License version to 2.1.16
  - S8233075: JFR - nmetods - misspelled in several places
  - S8233081: C1: PatchingStub for field access copies too much
  - S8233097: Fontmetrics for large Fonts has zero width
  - S8233202: exclude
javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java
  - S8233203: fix non-product build on AIX when compiling with
xlc16/legacy-xlc
  - S8233223: Add Amazon Root CA certificates
  - S8233404: System property to set the number of PBE iterations in
JCEKS keystores
  - S8233820: Test crashed with assert(phi->operand_count() != 1 ||
phi->subst() != phi) failed: missed trivial simplification
  - S8233839: aarch64: missing memory barrier in NewObjectArrayStub and
NewTypeArrayStub
  - S8233886: TEST_BUG jdk/java/net/CookieHandler/B6791927.java hit
hardcoded expiration date
  - S8233944: Make KerberosPrincipal.KRB_NT_ENTERPRISE field package private
  - S8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after
removing sunec.dll
  - S8234080: jdk/nio/zipfs/CRCWriteTest.java fails
  - S8234107: Several AWT modal dialog tests failing on Linux after
JDK-8231991
  - S8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to
wrong checksum
  - S8234321: Call cache flush after generating trampoline.
  - S8234591: [11u] Build with old C compiler broken by 8223490
  - S8234625: hs test serviceability/sa/ClhsdbCDSCore.java fails on
macOS 10.15
  - S8234645: ARM32: C1: PatchingStub for field access: not enough bytes
  - S8234906: [TESTBUG] TestDivZeroCheckControl fails for client VMs due
to Unrecognized VM option LoopUnrollLimit
  - S8235142: JDK-8193255 backport broke bootstrap with JDK 10
  - S8235403: Further cleanup to test serviceability/sa/ClhsdbCDSCore.java
  - S8235585: Enable macOS codesigning for all libraries and executables
  - S8235687: Contents/MacOS/libjli.dylib cannot be a symlink

More details:
https://builds.shipilev.net/backports-monitor/release-notes-11.0.6.txt

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 felix.yang at huawei.com  Wed Jan 15 06:58:32 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Wed, 15 Jan 2020 06:58:32 +0000
Subject: [RFC] ZGC proposal for aarch64  jdk11u
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>

Hi,

Currently, we only have zgc for the jdk11 x86 platform.  Zgc for aarch64 platform was later added in jdk13 by Stuart from Linaro.
So it?s an interesting question whether zgc for aarch64 platform should be backported to jdk11.

    Dozens of our arm-based cloud customers are switching to jdk11 and some of them have a strong demand for the zgc feature for their business.
To satisfy that requirement, we took the action to backport this feature in our jdk11 release.
But we think this work should not be kept private.  Other jdk11 vendors may come to the same problem.
It?s appreciated if this work could be incorporated in the upstream jdk11 repo and further improved.

    We have backported the following zgc related patches to jdk11u:
https://bugs.openjdk.java.net/browse/JDK-8217745
https://bugs.openjdk.java.net/browse/JDK-8224187
https://bugs.openjdk.java.net/browse/JDK-8214527
https://bugs.openjdk.java.net/browse/JDK-8224675<javascript:;>

   Basic test such as jtreg, jcstress looks good.  Specjbb2015 test with zgc gives us anticipated max & critical score.
    I can provide more details and propose a webrev for the backport.  But before that I would like to hear your comments & suggestions.

Thanks,
Felix

From shade at redhat.com  Wed Jan 15 08:50:10 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 15 Jan 2020 09:50:10 +0100
Subject: [14u Communication] jdk14u repo available
In-Reply-To: <20200114142450.GG9097@yoga>
References: <20190624154130.GB19779@vimes> <20200114142450.GG9097@yoga>
Message-ID: <bb13ed62-b75b-036d-35d4-6fb4d7ba092e@redhat.com>

On 1/14/20 3:24 PM, Rob McKenna wrote:
> I'd like to announce the availibility of the JDK 14 Updates forest at:
> http://hg.openjdk.java.net/jdk-updates/jdk14u/

Thank you!

As usual, workspace blob for it is here:
 https://builds.shipilev.net/workspaces/jdk-updates-jdk14u.tar.xz

-- 
Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Wed Jan 15 08:54:17 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 15 Jan 2020 08:54:17 +0000
Subject: [11u] RFR: 8185005: Improve performance of
 ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
In-Reply-To: <VE1PR02MB5422F5FE5E783811CA5F1569EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422F5FE5E783811CA5F1569EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <VE1PR02MB54228D4675FC1780B4195B85EC370@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

I had to do some more smaller fixes to this to get it working.

The third template argument of the hash table declaration was removed in
"8214822: Move ConcurrentHashTable VALUE parameter to CONFIG". This is missing in 11, 
thus I need to specify a type for VALUE.  

Also, "8213587: Speed up CDS dump time by using resizable hashtables" 
is missing which moves primitive_hash() from resourceHash.hpp 
to globalDefinitions.hpp, so I need to include resourceHash.hpp.

http://cr.openjdk.java.net/~goetz/wr20/8185005-getThreadInfo_performance-jdk11/02-incremental/
http://cr.openjdk.java.net/~goetz/wr20/8185005-getThreadInfo_performance-jdk11/02/

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Friday, January 3, 2020 2:41 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR: 8185005: Improve performance of
> ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
> 
> Hi
> 
> I had to do some trivial resolves due to context in mutexLocker.h|cpp  to
> downport this:
> 
> http://cr.openjdk.java.net/~goetz/wr20/8185005-
> getThreadInfo_performance-jdk11/01/
> https://bugs.openjdk.java.net/browse/JDK-8185005
> https://hg.openjdk.java.net/jdk/jdk/rev/f4abe950c3b0
> 
> Best regards,
>   Goetz.

From martin.doerr at sap.com  Wed Jan 15 11:18:37 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 15 Jan 2020 11:18:37 +0000
Subject: [11u] RFR: 8185005: Improve performance of
 ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
In-Reply-To: <VE1PR02MB54228D4675FC1780B4195B85EC370@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422F5FE5E783811CA5F1569EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <VE1PR02MB54228D4675FC1780B4195B85EC370@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3297964001AB537F23FEE70B9A370@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi G?tz,

that makes sense. Looks good except the non-alphabetic include ordering (I don't need to see another webrev for that).

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 15. Januar 2020 09:54
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: [CAUTION] RE: [11u] RFR: 8185005: Improve performance of
> ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
> 
> Hi,
> 
> I had to do some more smaller fixes to this to get it working.
> 
> The third template argument of the hash table declaration was removed in
> "8214822: Move ConcurrentHashTable VALUE parameter to CONFIG". This is
> missing in 11,
> thus I need to specify a type for VALUE.
> 
> Also, "8213587: Speed up CDS dump time by using resizable hashtables"
> is missing which moves primitive_hash() from resourceHash.hpp
> to globalDefinitions.hpp, so I need to include resourceHash.hpp.
> 
> http://cr.openjdk.java.net/~goetz/wr20/8185005-
> getThreadInfo_performance-jdk11/02-incremental/
> http://cr.openjdk.java.net/~goetz/wr20/8185005-
> getThreadInfo_performance-jdk11/02/
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Friday, January 3, 2020 2:41 PM
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [11u] RFR: 8185005: Improve performance of
> > ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
> >
> > Hi
> >
> > I had to do some trivial resolves due to context in mutexLocker.h|cpp  to
> > downport this:
> >
> > http://cr.openjdk.java.net/~goetz/wr20/8185005-
> > getThreadInfo_performance-jdk11/01/
> > https://bugs.openjdk.java.net/browse/JDK-8185005
> > https://hg.openjdk.java.net/jdk/jdk/rev/f4abe950c3b0
> >
> > Best regards,
> >   Goetz.

From per.liden at oracle.com  Wed Jan 15 12:07:42 2020
From: per.liden at oracle.com (Per Liden)
Date: Wed, 15 Jan 2020 13:07:42 +0100
Subject: [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
Message-ID: <38a15dc5-9cee-0f44-13ee-98f185ee72ae@oracle.com>

Hi,

Please note that backporting JDK-8224675 "Late GC barrier insertion for 
ZGC" is not great idea, since that patch introduced stability issues and 
the whole approach was later superseded by JDK-8230565 "ZGC: Redesign C2 
load barrier to expand on the MachNode level".

If you want to go down this path, I'd suggest that you either don't 
backport JDK-8224675 at all, or backport everything up to JDK-8224675 + 
JDK-8230565. Also note that if you include JDK-8230565 you want to be 
careful to also include any followup bug fixes, like JDK-8233506.

In general, a lot of stability and performance improvements have gone 
into ZGC since JDK 11. If at all possible, I would strongly recommend 
using JDK 14 instead, where you already have aarch64 support and all 
other goodies.

cheers,
Per

On 1/15/20 7:58 AM, Yangfei (Felix) wrote:
> Hi,
> 
> Currently, we only have zgc for the jdk11 x86 platform.  Zgc for aarch64 platform was later added in jdk13 by Stuart from Linaro.
> So it?s an interesting question whether zgc for aarch64 platform should be backported to jdk11.
> 
>      Dozens of our arm-based cloud customers are switching to jdk11 and some of them have a strong demand for the zgc feature for their business.
> To satisfy that requirement, we took the action to backport this feature in our jdk11 release.
> But we think this work should not be kept private.  Other jdk11 vendors may come to the same problem.
> It?s appreciated if this work could be incorporated in the upstream jdk11 repo and further improved.
> 
>      We have backported the following zgc related patches to jdk11u:
> https://bugs.openjdk.java.net/browse/JDK-8217745
> https://bugs.openjdk.java.net/browse/JDK-8224187
> https://bugs.openjdk.java.net/browse/JDK-8214527
> https://bugs.openjdk.java.net/browse/JDK-8224675<javascript:;>
> 
>     Basic test such as jtreg, jcstress looks good.  Specjbb2015 test with zgc gives us anticipated max & critical score.
>      I can provide more details and propose a webrev for the backport.  But before that I would like to hear your comments & suggestions.
> 
> Thanks,
> Felix
> 

From stuart.monteith at linaro.org  Wed Jan 15 13:10:57 2020
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Wed, 15 Jan 2020 13:10:57 +0000
Subject: [aarch64-port-dev ] [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
Message-ID: <CAEGA6kZzXgo-BozGHtWnpn6vw1RPrhFL_s42cG9Vu9vK4-C6hQ@mail.gmail.com>

Hello Felix,
     I'm pleased that there is interest in ZGC on aarch64, that the
performance is at expected levels and is apparently trouble free.
However, I'd like to understand why this backporting is being done. If
it is for running in production, then I'd expect Per, etc, to not be
upset or disagree when I that ZGC on aarch64 in JDK 13 isn't
production ready. I understand it would be easier to test with an
existing software stack on top of JDK 11 rather than moving onto JDK
13, etc. However, ZGC is an experimental VM feature, and the model
OpenJDK has moved to is for 6 monthly releases. Per and his team have
made lots of improvements, and fixes, in ZGC since 11, so I would
expect people to run and test on current release to avoid hitting
already known issues, whether that be on x86 or aarch64.

There might be a possibility of backporting some features, if there is
no effect when they are disabled. However, it is probably better to
track ZGC development through the released versions as a single
backport will not be enough, I wouldn't want to burden Per's team with
maintaining something that is in as much development as ZGC at this
point.

BR,
   Stuart

On Wed, 15 Jan 2020 at 06:59, Yangfei (Felix) <felix.yang at huawei.com> wrote:
>
> Hi,
>
> Currently, we only have zgc for the jdk11 x86 platform.  Zgc for aarch64 platform was later added in jdk13 by Stuart from Linaro.
> So it?s an interesting question whether zgc for aarch64 platform should be backported to jdk11.
>
>     Dozens of our arm-based cloud customers are switching to jdk11 and some of them have a strong demand for the zgc feature for their business.
> To satisfy that requirement, we took the action to backport this feature in our jdk11 release.
> But we think this work should not be kept private.  Other jdk11 vendors may come to the same problem.
> It?s appreciated if this work could be incorporated in the upstream jdk11 repo and further improved.
>
>     We have backported the following zgc related patches to jdk11u:
> https://bugs.openjdk.java.net/browse/JDK-8217745
> https://bugs.openjdk.java.net/browse/JDK-8224187
> https://bugs.openjdk.java.net/browse/JDK-8214527
> https://bugs.openjdk.java.net/browse/JDK-8224675<javascript:;>
>
>    Basic test such as jtreg, jcstress looks good.  Specjbb2015 test with zgc gives us anticipated max & critical score.
>     I can provide more details and propose a webrev for the backport.  But before that I would like to hear your comments & suggestions.
>
> Thanks,
> Felix

From sgehwolf at redhat.com  Wed Jan 15 13:40:16 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 15 Jan 2020 14:40:16 +0100
Subject: OpenJDK 11.0.6 Released
In-Reply-To: <d67290f6-9c07-89b7-f877-39a04e3ffaf2@redhat.com>
References: <d67290f6-9c07-89b7-f877-39a04e3ffaf2@redhat.com>
Message-ID: <d038bf0d2c8067ed7222e53259ead5d531d26e4d.camel@redhat.com>

On Wed, 2020-01-15 at 05:52 +0000, Andrew John Hughes wrote:
> We are pleased to announce the release of OpenJDK 11.0.6.
> 
> The source tarball is available from:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.6-ga.tar.xz
> 
> The tarball is accompanied by a digital signature available at:
> 
> * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.6-ga.tar.xz.sig
> 
> This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

The binaries for Linux and Windows to go with it are available here
(JDK 8 builds will follow shortly, hopefully):
https://adoptopenjdk.net/upstream.html

Thanks,
Severin


From rob.mckenna at oracle.com  Wed Jan 15 16:05:42 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 15 Jan 2020 16:05:42 +0000
Subject: [Updates Communication] 13.0.2 security patches pushed
In-Reply-To: <20191016185707.GA7038@vimes>
References: <20191016185707.GA7038@vimes>
Message-ID: <20200115160542.GM9097@yoga>

13.0.2 patches have been pushed to:

http://hg.openjdk.java.net/jdk-updates/jdk13u/

    -Rob


From sgehwolf at redhat.com  Wed Jan 15 17:06:42 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 15 Jan 2020 18:06:42 +0100
Subject: [Updates Communication] 13.0.2 security patches pushed
In-Reply-To: <20200115160542.GM9097@yoga>
References: <20191016185707.GA7038@vimes> <20200115160542.GM9097@yoga>
Message-ID: <6caa77fbcebcd32256567a295a00bda4033c25c2.camel@redhat.com>

On Wed, 2020-01-15 at 16:05 +0000, Rob McKenna wrote:
> 13.0.2 patches have been pushed to:
> 
> http://hg.openjdk.java.net/jdk-updates/jdk13u/

Thanks, Rob! Is there going to be a jdk-13.0.2-ga tag?

Cheers,
Severin


From aph at redhat.com  Wed Jan 15 18:03:54 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Jan 2020 18:03:54 +0000
Subject: [aarch64-port-dev ] [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <CAEGA6kZzXgo-BozGHtWnpn6vw1RPrhFL_s42cG9Vu9vK4-C6hQ@mail.gmail.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
 <CAEGA6kZzXgo-BozGHtWnpn6vw1RPrhFL_s42cG9Vu9vK4-C6hQ@mail.gmail.com>
Message-ID: <6b716737-ba03-71c2-5488-b5654093c447@redhat.com>

On 1/15/20 1:10 PM, Stuart Monteith wrote:
>      I'm pleased that there is interest in ZGC on aarch64, that the
> performance is at expected levels and is apparently trouble free.
> However, I'd like to understand why this backporting is being done. If
> it is for running in production, then I'd expect Per, etc, to not be
> upset or disagree when I that ZGC on aarch64 in JDK 13 isn't
> production ready.

In particular, it's perhaps odd that something which is still an experimental
feature in mainline is being considered for a backport.

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


From gnu.andrew at redhat.com  Wed Jan 15 19:18:00 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 15 Jan 2020 19:18:00 +0000
Subject: RFR: [11u] JDK-8236039: JSSE Client does not accept
 status_request extension in CertificateRequest messages for TLS 1.3
In-Reply-To: <605aae0a-9e0a-90c2-218c-8bd533a2dab3@redhat.com>
References: <605aae0a-9e0a-90c2-218c-8bd533a2dab3@redhat.com>
Message-ID: <e531a70e-79ac-2905-caf7-fdad4debab0b@redhat.com>

On 08/01/2020 06:46, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236039
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8236039/webrev.01/
> 
> TLS 1.3 allows the status_request extension, but, as the JSSE provider
> does not currently support it, it throws an exception. It should instead
> simply ignore the extension.
> 
> Backporting this fix will increase compatibility with TLS 1.3 clients.
> 
> Patch nearly applies cleanly, with the exception of the copyright header
> having been previously updated in 15u, but not 11u:
> 
>  @@ -1,5 +1,5 @@
>   /*
> -- * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights
> reserved.
> +- * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
>  + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights
> reserved.
> 
> Ok for 11.0.7?
> 
> Thanks,
> 

Ping?

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 felix.yang at huawei.com  Thu Jan 16 03:01:55 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Thu, 16 Jan 2020 03:01:55 +0000
Subject: [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <38a15dc5-9cee-0f44-13ee-98f185ee72ae@oracle.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
 <38a15dc5-9cee-0f44-13ee-98f185ee72ae@oracle.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA7BE@dggeml527-mbx.china.huawei.com>

Hi,

> Hi,
> 
> Please note that backporting JDK-8224675 "Late GC barrier insertion for ZGC"
> is not great idea, since that patch introduced stability issues and the whole
> approach was later superseded by JDK-8230565 "ZGC: Redesign C2 load
> barrier to expand on the MachNode level".
> 
> If you want to go down this path, I'd suggest that you either don't backport
> JDK-8224675 at all, or backport everything up to JDK-8224675 + JDK-8230565.
> Also note that if you include JDK-8230565 you want to be careful to also include
> any followup bug fixes, like JDK-8233506.

Thanks for pointing this out.  It's helpful for our current work.  
We plan to start with the four patches and will check for other necessary ones.  
We noticed patches like JDK-8230565 are necessary for x86 zgc, but it's not there in jdk11.  
Users who want to stay with LTS versions like jdk11 will most likely come to the problems when they try zgc on the x86 platform.  
Is there a plan to incorporate these patches in jdk11?  

> In general, a lot of stability and performance improvements have gone into ZGC
> since JDK 11. If at all possible, I would strongly recommend using JDK 14
> instead, where you already have aarch64 support and all other goodies.

Does that mean zgc in jdk11 will not be maintained by the community?  


Thanks,
Felix

From felix.yang at huawei.com  Thu Jan 16 06:42:29 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Thu, 16 Jan 2020 06:42:29 +0000
Subject: [aarch64-port-dev ] [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <6b716737-ba03-71c2-5488-b5654093c447@redhat.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
 <CAEGA6kZzXgo-BozGHtWnpn6vw1RPrhFL_s42cG9Vu9vK4-C6hQ@mail.gmail.com>
 <6b716737-ba03-71c2-5488-b5654093c447@redhat.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA8AB@dggeml527-mbx.china.huawei.com>

Hi,

> On 1/15/20 1:10 PM, Stuart Monteith wrote:
> >      I'm pleased that there is interest in ZGC on aarch64, that the
> > performance is at expected levels and is apparently trouble free.
> > However, I'd like to understand why this backporting is being done. If
> > it is for running in production, then I'd expect Per, etc, to not be
> > upset or disagree when I that ZGC on aarch64 in JDK 13 isn't
> > production ready.
> 
> In particular, it's perhaps odd that something which is still an experimental
> feature in mainline is being considered for a backport.

So long as zgc in jdk11 is continually maintained by the community, it may not be a bad idea
to enable it on one more arch provided that the risk is acceptable after code review.  Otherwise, we are on our own.  
Users are much conservative when it comes to migrating to a new jdk version.  Also they have their own decision about which GC policy to use.  


Thanks,
Felix

From per.liden at oracle.com  Thu Jan 16 08:22:33 2020
From: per.liden at oracle.com (Per Liden)
Date: Thu, 16 Jan 2020 09:22:33 +0100
Subject: [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA7BE@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
 <38a15dc5-9cee-0f44-13ee-98f185ee72ae@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DFA7BE@dggeml527-mbx.china.huawei.com>
Message-ID: <e30afa6e-375b-3b30-38b5-6a754ac38810@oracle.com>

Hi,

ZGC in JDK 11 is fairly stable as it is, so there's no super compelling 
reason to spend time and resources on backporting JDK-8233506 at this 
time. However, backporting only JDK-8224675 would be a mistake, as it 
would destabilize ZGC (including the x86 port) so you would basically 
have to go all the way to JDK-8230565, or alternatively don't backport 
JDK-8224675 and adjust the aarch64 port accordingly.

Whatever path you take here, it would require significant work and 
testing, which is why I'd again recommend that you to consider using JDK 
14 (when it's GA) for these workloads.

cheers,
Per

On 1/16/20 4:01 AM, Yangfei (Felix) wrote:
> Hi,
> 
>> Hi,
>>
>> Please note that backporting JDK-8224675 "Late GC barrier insertion for ZGC"
>> is not great idea, since that patch introduced stability issues and the whole
>> approach was later superseded by JDK-8230565 "ZGC: Redesign C2 load
>> barrier to expand on the MachNode level".
>>
>> If you want to go down this path, I'd suggest that you either don't backport
>> JDK-8224675 at all, or backport everything up to JDK-8224675 + JDK-8230565.
>> Also note that if you include JDK-8230565 you want to be careful to also include
>> any followup bug fixes, like JDK-8233506.
> 
> Thanks for pointing this out.  It's helpful for our current work.
> We plan to start with the four patches and will check for other necessary ones.
> We noticed patches like JDK-8230565 are necessary for x86 zgc, but it's not there in jdk11.
> Users who want to stay with LTS versions like jdk11 will most likely come to the problems when they try zgc on the x86 platform.
> Is there a plan to incorporate these patches in jdk11?
> 
>> In general, a lot of stability and performance improvements have gone into ZGC
>> since JDK 11. If at all possible, I would strongly recommend using JDK 14
>> instead, where you already have aarch64 support and all other goodies.
> 
> Does that mean zgc in jdk11 will not be maintained by the community?
> 
> 
> Thanks,
> Felix
> 

From christoph.langer at sap.com  Thu Jan 16 13:27:16 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 16 Jan 2020 13:27:16 +0000
Subject: RFR: [11u] JDK-8236039: JSSE Client does not accept
 status_request extension in CertificateRequest messages for TLS 1.3
In-Reply-To: <e531a70e-79ac-2905-caf7-fdad4debab0b@redhat.com>
References: <605aae0a-9e0a-90c2-218c-8bd533a2dab3@redhat.com>
 <e531a70e-79ac-2905-caf7-fdad4debab0b@redhat.com>
Message-ID: <AM0PR02MB5714162634842CB406CDCF5F8A360@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Andrew,

this looks like something one wants to have in JDK11. Webrev looks good to me. I also approved by adding jdk11u fix request labels to the bug.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew John Hughes
> Sent: Mittwoch, 15. Januar 2020 20:18
> To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-
> dev at openjdk.java.net>
> Subject: Re: RFR: [11u] JDK-8236039: JSSE Client does not accept
> status_request extension in CertificateRequest messages for TLS 1.3
> 
> On 08/01/2020 06:46, Andrew John Hughes wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8236039
> > Webrev:
> https://cr.openjdk.java.net/~andrew/openjdk11/8236039/webrev.01/
> >
> > TLS 1.3 allows the status_request extension, but, as the JSSE provider
> > does not currently support it, it throws an exception. It should instead
> > simply ignore the extension.
> >
> > Backporting this fix will increase compatibility with TLS 1.3 clients.
> >
> > Patch nearly applies cleanly, with the exception of the copyright header
> > having been previously updated in 15u, but not 11u:
> >
> >  @@ -1,5 +1,5 @@
> >   /*
> > -- * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights
> > reserved.
> > +- * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> >  + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights
> > reserved.
> >
> > Ok for 11.0.7?
> >
> > Thanks,
> >
> 
> Ping?
> 
> 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 rob.mckenna at oracle.com  Thu Jan 16 15:18:19 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 16 Jan 2020 15:18:19 +0000
Subject: [Updates Communication] 13.0.2 security patches pushed
In-Reply-To: <6caa77fbcebcd32256567a295a00bda4033c25c2.camel@redhat.com>
References: <20191016185707.GA7038@vimes> <20200115160542.GM9097@yoga>
 <6caa77fbcebcd32256567a295a00bda4033c25c2.camel@redhat.com>
Message-ID: <20200116151819.GP9097@yoga>

Just pushed - apologies for the delay.

    -Rob

On 15/01/20 18:06, Severin Gehwolf wrote:
> On Wed, 2020-01-15 at 16:05 +0000, Rob McKenna wrote:
> > 13.0.2 patches have been pushed to:
> > 
> > http://hg.openjdk.java.net/jdk-updates/jdk13u/
> 
> Thanks, Rob! Is there going to be a jdk-13.0.2-ga tag?
> 
> Cheers,
> Severin
> 

From gnu.andrew at redhat.com  Thu Jan 16 16:59:03 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 16 Jan 2020 16:59:03 +0000
Subject: RFR: [11u] JDK-8236039: JSSE Client does not accept
 status_request extension in CertificateRequest messages for TLS 1.3
In-Reply-To: <AM0PR02MB5714162634842CB406CDCF5F8A360@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <605aae0a-9e0a-90c2-218c-8bd533a2dab3@redhat.com>
 <e531a70e-79ac-2905-caf7-fdad4debab0b@redhat.com>
 <AM0PR02MB5714162634842CB406CDCF5F8A360@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <84805ea0-ee6b-16b8-dc9b-e5cebe7f47d4@redhat.com>



On 16/01/2020 13:27, Langer, Christoph wrote:
> Hi Andrew,
> 
> this looks like something one wants to have in JDK11. Webrev looks good to me. I also approved by adding jdk11u fix request labels to the bug.
> 
> Best regards
> Christoph
> 

Thanks. I was going to add those once it was reviewed. Thanks for saving
me the trouble :)
-- 
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 neugens at redhat.com  Thu Jan 16 17:01:19 2020
From: neugens at redhat.com (Mario Torre)
Date: Thu, 16 Jan 2020 18:01:19 +0100
Subject: JDK-8227662 approval
Message-ID: <CAJwKKma4nE+ycHMspR3yNhDv6p-7YM0rf0t3S=i2rnMN9qyzXw@mail.gmail.com>

Hi Christoph, Andrew,

I accidentally pushed the patch without jdk11u-fix-yes:

https://bugs.openjdk.java.net/browse/JDK-8227662
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/594c091567bf

I apologise for this, would it be possible to have a retroactive approval?

Sorry again for the mistake...

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 felix.yang at huawei.com  Fri Jan 17 08:00:24 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 17 Jan 2020 08:00:24 +0000
Subject: [RFC] ZGC proposal for aarch64 jdk11u
In-Reply-To: <e30afa6e-375b-3b30-38b5-6a754ac38810@oracle.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE3DFA504@dggeml527-mbx.china.huawei.com>
 <38a15dc5-9cee-0f44-13ee-98f185ee72ae@oracle.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE3DFA7BE@dggeml527-mbx.china.huawei.com>
 <e30afa6e-375b-3b30-38b5-6a754ac38810@oracle.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE3DFAC6A@dggeml527-mbx.china.huawei.com>

Hi,

> ZGC in JDK 11 is fairly stable as it is, so there's no super compelling reason to
> spend time and resources on backporting JDK-8233506 at this time. However,
> backporting only JDK-8224675 would be a mistake, as it would destabilize ZGC
> (including the x86 port) so you would basically have to go all the way to
> JDK-8230565, or alternatively don't backport
> JDK-8224675 and adjust the aarch64 port accordingly.

Yes, we see your point here and will look into it.  

> Whatever path you take here, it would require significant work and testing,
> which is why I'd again recommend that you to consider using JDK
> 14 (when it's GA) for these workloads.

Thanks again for your helpful comments.  We will consider it when people are willing to switch to higher jdk versions.  

Best regards,
Felix

From christoph.langer at sap.com  Fri Jan 17 10:51:23 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 17 Jan 2020 10:51:23 +0000
Subject: JDK-8227662 approval
In-Reply-To: <CAJwKKma4nE+ycHMspR3yNhDv6p-7YM0rf0t3S=i2rnMN9qyzXw@mail.gmail.com>
References: <CAJwKKma4nE+ycHMspR3yNhDv6p-7YM0rf0t3S=i2rnMN9qyzXw@mail.gmail.com>
Message-ID: <AM0PR02MB571468124FCB53D5891059368A310@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Mario,

I've approved it. As it's an Oracle 11.0.7 item, there's no discussion about it. ??

At the committers workshop we shall discuss some process alleviations for Oracle parity backports...

Cheers
Christoph


> -----Original Message-----
> From: Mario Torre <neugens at redhat.com>
> Sent: Donnerstag, 16. Januar 2020 18:01
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Cc: Langer, Christoph <christoph.langer at sap.com>; Andrew Haley
> <aph at redhat.com>
> Subject: JDK-8227662 approval
> 
> Hi Christoph, Andrew,
> 
> I accidentally pushed the patch without jdk11u-fix-yes:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227662
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/594c091567bf
> 
> I apologise for this, would it be possible to have a retroactive approval?
> 
> Sorry again for the mistake...
> 
> 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 neugens at redhat.com  Fri Jan 17 11:04:33 2020
From: neugens at redhat.com (Mario Torre)
Date: Fri, 17 Jan 2020 12:04:33 +0100
Subject: JDK-8227662 approval
In-Reply-To: <AM0PR02MB571468124FCB53D5891059368A310@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CAJwKKma4nE+ycHMspR3yNhDv6p-7YM0rf0t3S=i2rnMN9qyzXw@mail.gmail.com>
 <AM0PR02MB571468124FCB53D5891059368A310@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CAJwKKmbqVbMgsUWQZ0XaOpdto-KtX_=GNgOs9iGF0zdLCn9M2Q@mail.gmail.com>

On Fri, Jan 17, 2020 at 11:53 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Mario,
>
> I've approved it. As it's an Oracle 11.0.7 item, there's no discussion
> about it. ??
>

Thanks!

At the committers workshop we shall discuss some process alleviations for
> Oracle parity backports...
>

\o/

Cheers,
Mario



> Cheers
> Christoph
>
>
> > -----Original Message-----
> > From: Mario Torre <neugens at redhat.com>
> > Sent: Donnerstag, 16. Januar 2020 18:01
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Cc: Langer, Christoph <christoph.langer at sap.com>; Andrew Haley
> > <aph at redhat.com>
> > Subject: JDK-8227662 approval
> >
> > Hi Christoph, Andrew,
> >
> > I accidentally pushed the patch without jdk11u-fix-yes:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8227662
> > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/594c091567bf
> >
> > I apologise for this, would it be possible to have a retroactive
> approval?
> >
> > Sorry again for the mistake...
> >
> > Cheers,
> > Mario
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>

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

From rkennke at redhat.com  Fri Jan 17 15:08:52 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 17 Jan 2020 16:08:52 +0100
Subject: RFR (11u): 8224187: Refactor arraycopy_prologue to allow ZGC read
 barriers on arraycopy
Message-ID: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>

I'd like to backport the following aarch64-specific change to 11u:

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

I need it for recent changes to Shenandoah GC's arraycopy
implementation, namely:

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

The patch only differs from the original patch in that it omits the
Shenandoah parts, which are not in 11u, yet. Other than those, it
applies cleanly.

Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8224187/webrev.00/

Testing: tier1 and tier2 tests, hotspot_gc_shenandoah tests in private
repo that combines this change with the corresponding Shenandoah changes.

Can I please get a review?

Thanks,
Roman


From stuart.monteith at linaro.org  Fri Jan 17 16:21:24 2020
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 17 Jan 2020 16:21:24 +0000
Subject: [aarch64-port-dev ] RFR (11u): 8224187: Refactor
 arraycopy_prologue to allow ZGC read barriers on arraycopy
In-Reply-To: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>
References: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>
Message-ID: <CAEGA6kbgMkDrG6vNuWFkReCScrAniY6YpAOLsC66TSN=3SBJOQ@mail.gmail.com>

 I'm not a reviewer, however it looks good to me.

Stuart

On Fri, 17 Jan 2020 at 15:09, Roman Kennke <rkennke at redhat.com> wrote:
>
> I'd like to backport the following aarch64-specific change to 11u:
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8224187
>
> I need it for recent changes to Shenandoah GC's arraycopy
> implementation, namely:
>
> https://bugs.openjdk.java.net/browse/JDK-8231086
>
> The patch only differs from the original patch in that it omits the
> Shenandoah parts, which are not in 11u, yet. Other than those, it
> applies cleanly.
>
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8224187/webrev.00/
>
> Testing: tier1 and tier2 tests, hotspot_gc_shenandoah tests in private
> repo that combines this change with the corresponding Shenandoah changes.
>
> Can I please get a review?
>
> Thanks,
> Roman
>

From shade at redhat.com  Fri Jan 17 16:32:53 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 17 Jan 2020 17:32:53 +0100
Subject: [aarch64-port-dev ] RFR (11u): 8224187: Refactor
 arraycopy_prologue to allow ZGC read barriers on arraycopy
In-Reply-To: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>
References: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>
Message-ID: <d8901f1c-f19f-8bc1-c924-b019d8ade5f9@redhat.com>

On 1/17/20 4:08 PM, Roman Kennke wrote:
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8224187/webrev.00/
> 
> Can I please get a review?

This backport looks good to me.

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Fri Jan 17 17:05:25 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 17 Jan 2020 18:05:25 +0100
Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u
Message-ID: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com>

Hello,

The Shenandoah GC has been integrated into jdk12 a little over a year ago:

http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3

The Shenandoah team has been maintaining the Shenandoah-enabled jdk11u
downstream repository since the inception of jdk11 under:

http://hg.openjdk.java.net/shenandoah/jdk11

In order to make it more useful and accessible for users, we would like
to make it available in upstream jdk11u. The Shenandoah team at Red Hat
intends to maintain it the same way it had been maintained in
shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat
already does.

Thanks to recent changes in Shenandoah over the last year, we are now
able to fit the GC interface in jdk11 almost exactly. There are a few
exceptions though. We tried to follow the following pattern for all
shared-code changes where it made sense:

#if INCLUDE_SHENANDOAH_GC
  if (UseShenandoahGC) {
    ...
  }
#endif

This ensures that the Shenandoah-specific changes are cut out of the
build when building without Shenandoah, and avoid those code paths at
runtime when running without Shenandoah.

Also, there are a few places where this was not possible or where it
didn't seem feasible, but we tried to keep them few and obvious.
Whenever this is the case, we are mirroring as close as possible what we
have in jdk/jdk.

Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other
architectures still build fine, and Shenandoah gets automatically
disabled during configure if not supported. OS-wise, Shenandoah runs on
Linux, Windows, and is known to run on MacOS X and Solaris too.

I wasn't sure which form this should take. I decided to start with the
easiest possible form this could take: a simple patch/webrev and an RFR.
Let me know if you need a JIRA issue or any other formalities to track that.

Full webrev:
https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-all/

Webrev only for shared-code changes:
https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-shared/

The webrevs are based on and depend on the arraycopy patch proposed for
review here:

https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002396.html

Testing:
The code has been tested many many times, continuously while maintaining
it. It has also served as the basis for RPMs and shipped to customers.
We are running all sorts of tests of the hotspot/jtreg testsuite, in
particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests,
several popular benchmarks (specjvm, specjbb on a regular basis), on a
nightly basis.

Please let me know what you think.

Thanks,
Roman








From gnu.andrew at redhat.com  Fri Jan 17 17:33:32 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 17 Jan 2020 17:33:32 +0000
Subject: JDK-8227662 approval
In-Reply-To: <AM0PR02MB571468124FCB53D5891059368A310@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CAJwKKma4nE+ycHMspR3yNhDv6p-7YM0rf0t3S=i2rnMN9qyzXw@mail.gmail.com>
 <AM0PR02MB571468124FCB53D5891059368A310@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <f4bea79a-6dd7-ed3c-c30f-2cd84f431df0@redhat.com>



On 17/01/2020 10:51, Langer, Christoph wrote:
> Hi Mario,
> 
> I've approved it. As it's an Oracle 11.0.7 item, there's no discussion about it. ??
> 

I don't see 11.0.7-oracle on the bug.

Compare with e.g. https://bugs.openjdk.java.net/browse/JDK-8227646

> At the committers workshop we shall discuss some process alleviations for Oracle parity backports...
> 

I don't think we should be giving a free pass to issues, simply because
Oracle has blessed them for unknown reasons.

We have discussed this before.

> Cheers
> Christoph
> 
> 
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 Jan 20 08:36:43 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 20 Jan 2020 08:36:43 +0000
Subject: JDK-8227662 approval
In-Reply-To: <f4bea79a-6dd7-ed3c-c30f-2cd84f431df0@redhat.com>
References: <CAJwKKma4nE+ycHMspR3yNhDv6p-7YM0rf0t3S=i2rnMN9qyzXw@mail.gmail.com>
 <AM0PR02MB571468124FCB53D5891059368A310@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f4bea79a-6dd7-ed3c-c30f-2cd84f431df0@redhat.com>
Message-ID: <AM0PR02MB5714A8A8DE1E0DFDB08918BC8A320@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Freitag, 17. Januar 2020 18:34
> To: Langer, Christoph <christoph.langer at sap.com>; Mario Torre
> <neugens at redhat.com>; jdk-updates-dev <jdk-updates-
> dev at openjdk.java.net>
> Subject: Re: JDK-8227662 approval
> 
> 
> 
> On 17/01/2020 10:51, Langer, Christoph wrote:
> > Hi Mario,
> >
> > I've approved it. As it's an Oracle 11.0.7 item, there's no discussion about it.
> ??
> >
> 
> I don't see 11.0.7-oracle on the bug.
> 
> Compare with e.g. https://bugs.openjdk.java.net/browse/JDK-8227646
> 

Oh, you're right. I confused 11.0.7 with 11.0.7-oracle there. But still, the fix seems appropriate - it's a local, self-contained fix of an issue with a test case attached. So my approval holds valid, still.

> > At the committers workshop we shall discuss some process alleviations for
> Oracle parity backports...
> >
> 
> I don't think we should be giving a free pass to issues, simply because
> Oracle has blessed them for unknown reasons.
> 
> We have discussed this before.

I understand your concern. I think in general our goal is to pull in the backports that Oracle selected, even without knowing all the reasons behind their decisions. This is about both, keeping compatibility and have some parity regarding fixed problems. Sure, there might be technical concerns or risk assessments that might inhibit some backport or cause it to be shifted in a later release cycle.

But looking at 11u, there's some people who do the big bulk of Oracle parity backports, e.g. Goetz, Aleksey or myself. And we all have quite a good regression test infrastructure at hand to assess whether a backport would break something. So, to ease the processing for these folks, I was thinking to propose disburdening their process a bit by
a) considering Oracle backports as auto-approved
b) require review of backport changesets on some sense of proportion, e.g. not if there was only some contextual resolving necessary
c) restrict this "fast-path" backporting to a named set of people

I would also think that the need for a public review when pushing the CPU changes should be dropped. Those changes have been discussed and reviewed via the vulnerability group and you probably have done the integration builds and tests for the GA tag. So these changes can then just be pushed after the embargo is over.

But all that would be my proposal for a discussion at the committers workshop. Would be great if you could be there, too. ??

Best regards
Christoph


From shade at redhat.com  Mon Jan 20 12:54:57 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Jan 2020 13:54:57 +0100
Subject: [11u] Incomplete backport: JDK-8210910
Message-ID: <c205905e-eeb2-20fd-a090-ac3307950dc1@redhat.com>

Hi Goetz,

See:
  https://bugs.openjdk.java.net/browse/JDK-8210910

Compare:
  https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2b542536582a
  https://hg.openjdk.java.net/jdk/jdk/rev/c70468fc7118

New files are missing.

Because of this, tier3 tests fail:
 $ make run-test TEST=sanity/client/SwingSet/src/FileChooserDemoTest.java

...with:
 java.nio.file.NoSuchFileException:
.../jdk-updates-jdk11u-dev/test/jdk/sanity/client/SwingSet/src/resources/images/duke.jpg

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jan 20 13:11:39 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Jan 2020 14:11:39 +0100
Subject: [11u] Incomplete backport: JDK-8209499
Message-ID: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>

Hi again,

See:
  https://bugs.openjdk.java.net/browse/JDK-8209499

Compare:
  https://hg.openjdk.java.net/jdk/jdk/rev/e851c8ca30a7
  https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/111a1a8bbbd4

Again, new files are missing.

I think this is why new test times out in 11u:
 $ make run-test TEST=sanity/client/SwingSet/src/EditorPaneDemoTest.java

If I copy the missing files, it starts to pass.

-- 
Thanks,
-Aleksey


From martin.doerr at sap.com  Mon Jan 20 13:43:48 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 20 Jan 2020 13:43:48 +0000
Subject: [11u] Incomplete backport: JDK-8210910
In-Reply-To: <c205905e-eeb2-20fd-a090-ac3307950dc1@redhat.com>
References: <c205905e-eeb2-20fd-a090-ac3307950dc1@redhat.com>
Message-ID: <AM0PR0202MB32973DBFD8714C93801B8E049A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Aleksey,

thanks for reporting. I've created an issue:
https://bugs.openjdk.java.net/browse/JDK-8237540

@Christoph, can I push the following files from the original change:
test/jdk/sanity/client/SwingSet/src/resources/images/duke.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/FileChooserDemo.gif
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/apply.png
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/fliphor.png
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/flipvert.png
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/rotateleft.png
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/rotateright.png

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Montag, 20. Januar 2020 13:55
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [11u] Incomplete backport: JDK-8210910
> 
> Hi Goetz,
> 
> See:
>   https://bugs.openjdk.java.net/browse/JDK-8210910
> 
> Compare:
>   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2b542536582a
>   https://hg.openjdk.java.net/jdk/jdk/rev/c70468fc7118
> 
> New files are missing.
> 
> Because of this, tier3 tests fail:
>  $ make run-test TEST=sanity/client/SwingSet/src/FileChooserDemoTest.java
> 
> ...with:
>  java.nio.file.NoSuchFileException:
> .../jdk-updates-jdk11u-
> dev/test/jdk/sanity/client/SwingSet/src/resources/images/duke.jpg
> 
> --
> Thanks,
> -Aleksey


From christoph.langer at sap.com  Mon Jan 20 13:49:27 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 20 Jan 2020 13:49:27 +0000
Subject: [11u] Incomplete backport: JDK-8210910
In-Reply-To: <AM0PR0202MB32973DBFD8714C93801B8E049A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <c205905e-eeb2-20fd-a090-ac3307950dc1@redhat.com>
 <AM0PR0202MB32973DBFD8714C93801B8E049A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714EC24DE083A4640B0A9B48A320@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Martin,

thanks for fixing this. I have changed the title of your issue to: "Missing files in backport of JDK-8210910" and approved it. Please go ahead and push.

Thanks Aleksey for spotting this. We'll check our setup about why that happened. (e.g. why the files were missed out and why we obviously didn't run the tests that would have spotted this.)

Best regards
Christoph

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Montag, 20. Januar 2020 14:44
> To: Aleksey Shipilev <shade at redhat.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] Incomplete backport: JDK-8210910
> 
> Hi Aleksey,
> 
> thanks for reporting. I've created an issue:
> https://bugs.openjdk.java.net/browse/JDK-8237540
> 
> @Christoph, can I push the following files from the original change:
> test/jdk/sanity/client/SwingSet/src/resources/images/duke.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filecho
> oser/resources/images/FileChooserDemo.gif
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filecho
> oser/resources/images/apply.png
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filecho
> oser/resources/images/fliphor.png
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filecho
> oser/resources/images/flipvert.png
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filecho
> oser/resources/images/rotateleft.png
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filecho
> oser/resources/images/rotateright.png
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Aleksey Shipilev
> > Sent: Montag, 20. Januar 2020 13:55
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] Incomplete backport: JDK-8210910
> >
> > Hi Goetz,
> >
> > See:
> >   https://bugs.openjdk.java.net/browse/JDK-8210910
> >
> > Compare:
> >   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2b542536582a
> >   https://hg.openjdk.java.net/jdk/jdk/rev/c70468fc7118
> >
> > New files are missing.
> >
> > Because of this, tier3 tests fail:
> >  $ make run-test
> TEST=sanity/client/SwingSet/src/FileChooserDemoTest.java
> >
> > ...with:
> >  java.nio.file.NoSuchFileException:
> > .../jdk-updates-jdk11u-
> > dev/test/jdk/sanity/client/SwingSet/src/resources/images/duke.jpg
> >
> > --
> > Thanks,
> > -Aleksey


From martin.doerr at sap.com  Mon Jan 20 13:55:45 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 20 Jan 2020 13:55:45 +0000
Subject: [11u] Incomplete backport: JDK-8209499
In-Reply-To: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
References: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
Message-ID: <AM0PR0202MB3297CA6ACA4F3BB75DE130EF9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi again,

same for this one ??
https://bugs.openjdk.java.net/browse/JDK-8237541

I'll push the new files from the original change if I get approval:
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/ant.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/book.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/bug.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/bug2.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/crest.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/king.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/micro.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/seaweed.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/editorpane/back.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/editorpane/forward.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/editorpane/header.jpg
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/resources/images/EditorPaneDemo.gif

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Montag, 20. Januar 2020 14:12
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [11u] Incomplete backport: JDK-8209499
> 
> Hi again,
> 
> See:
>   https://bugs.openjdk.java.net/browse/JDK-8209499
> 
> Compare:
>   https://hg.openjdk.java.net/jdk/jdk/rev/e851c8ca30a7
>   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/111a1a8bbbd4
> 
> Again, new files are missing.
> 
> I think this is why new test times out in 11u:
>  $ make run-test TEST=sanity/client/SwingSet/src/EditorPaneDemoTest.java
> 
> If I copy the missing files, it starts to pass.
> 
> --
> Thanks,
> -Aleksey


From christoph.langer at sap.com  Mon Jan 20 14:03:34 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 20 Jan 2020 14:03:34 +0000
Subject: [11u] Incomplete backport: JDK-8209499
In-Reply-To: <AM0PR0202MB3297CA6ACA4F3BB75DE130EF9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
 <AM0PR0202MB3297CA6ACA4F3BB75DE130EF9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714AC9B92023FFCE36909658A320@AM0PR02MB5714.eurprd02.prod.outlook.com>

Approved as well.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Doerr, Martin
> Sent: Montag, 20. Januar 2020 14:56
> To: Aleksey Shipilev <shade at redhat.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: [11u] Incomplete backport: JDK-8209499
> 
> Hi again,
> 
> same for this one ??
> https://bugs.openjdk.java.net/browse/JDK-8237541
> 
> I'll push the new files from the original change if I get approval:
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/ant.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/book.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/bug.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/bug2.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/crest.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/king.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/micro.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/Octavo/seaweed.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/editorpane/back.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/editorpane/forward.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/book/editorpane/header.jpg
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> ane/resources/images/EditorPaneDemo.gif
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Aleksey Shipilev
> > Sent: Montag, 20. Januar 2020 14:12
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] Incomplete backport: JDK-8209499
> >
> > Hi again,
> >
> > See:
> >   https://bugs.openjdk.java.net/browse/JDK-8209499
> >
> > Compare:
> >   https://hg.openjdk.java.net/jdk/jdk/rev/e851c8ca30a7
> >   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/111a1a8bbbd4
> >
> > Again, new files are missing.
> >
> > I think this is why new test times out in 11u:
> >  $ make run-test
> TEST=sanity/client/SwingSet/src/EditorPaneDemoTest.java
> >
> > If I copy the missing files, it starts to pass.
> >
> > --
> > Thanks,
> > -Aleksey


From martin.doerr at sap.com  Mon Jan 20 14:08:17 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 20 Jan 2020 14:08:17 +0000
Subject: [11u] Incomplete backport: JDK-8209499
In-Reply-To: <AM0PR02MB5714AC9B92023FFCE36909658A320@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
 <AM0PR0202MB3297CA6ACA4F3BB75DE130EF9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM0PR02MB5714AC9B92023FFCE36909658A320@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3297BE640F832BE33E4118759A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Aleksey,

missing files are pushed (both issues):

age 	author 	description
15 months ago 	vagarwal 	8237540: Missing files in backport of JDK-8210910default tip
15 months ago 	akolarkunnu 	8237541: Missing files in backport of JDK-8236528

Best regards,
Martin


> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Montag, 20. Januar 2020 15:04
> To: Doerr, Martin <martin.doerr at sap.com>; Aleksey Shipilev
> <shade at redhat.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] Incomplete backport: JDK-8209499
> 
> Approved as well.
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Doerr, Martin
> > Sent: Montag, 20. Januar 2020 14:56
> > To: Aleksey Shipilev <shade at redhat.com>; Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] RE: [11u] Incomplete backport: JDK-8209499
> >
> > Hi again,
> >
> > same for this one ??
> > https://bugs.openjdk.java.net/browse/JDK-8237541
> >
> > I'll push the new files from the original change if I get approval:
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/ant.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/book.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/bug.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/bug2.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/crest.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/king.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/micro.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/Octavo/seaweed.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/editorpane/back.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/editorpane/forward.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/book/editorpane/header.jpg
> >
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorp
> > ane/resources/images/EditorPaneDemo.gif
> >
> > Best regards,
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Aleksey Shipilev
> > > Sent: Montag, 20. Januar 2020 14:12
> > > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > > Cc: jdk-updates-dev at openjdk.java.net
> > > Subject: [11u] Incomplete backport: JDK-8209499
> > >
> > > Hi again,
> > >
> > > See:
> > >   https://bugs.openjdk.java.net/browse/JDK-8209499
> > >
> > > Compare:
> > >   https://hg.openjdk.java.net/jdk/jdk/rev/e851c8ca30a7
> > >   https://hg.openjdk.java.net/jdk-updates/jdk11u-
> dev/rev/111a1a8bbbd4
> > >
> > > Again, new files are missing.
> > >
> > > I think this is why new test times out in 11u:
> > >  $ make run-test
> > TEST=sanity/client/SwingSet/src/EditorPaneDemoTest.java
> > >
> > > If I copy the missing files, it starts to pass.
> > >
> > > --
> > > Thanks,
> > > -Aleksey


From shade at redhat.com  Mon Jan 20 16:33:58 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Jan 2020 17:33:58 +0100
Subject: [11u] Incomplete backport: JDK-8210910
In-Reply-To: <AM0PR02MB5714EC24DE083A4640B0A9B48A320@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <c205905e-eeb2-20fd-a090-ac3307950dc1@redhat.com>
 <AM0PR0202MB32973DBFD8714C93801B8E049A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM0PR02MB5714EC24DE083A4640B0A9B48A320@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <0ca1b774-ba59-dada-f0be-33d0f578700f@redhat.com>

On 1/20/20 2:49 PM, Langer, Christoph wrote:
> Thanks Aleksey for spotting this. We'll check our setup about why that happened. (e.g. why the
> files were missed out and why we obviously didn't run the tests that would have spotted this.)

No problem. This only slowed down me a bit running tier3 tests manually.

I confirm this fixes the failures for me.

-Aleksey



From shade at redhat.com  Mon Jan 20 16:34:34 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Jan 2020 17:34:34 +0100
Subject: [11u] Incomplete backport: JDK-8209499
In-Reply-To: <AM0PR0202MB3297BE640F832BE33E4118759A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
 <AM0PR0202MB3297CA6ACA4F3BB75DE130EF9A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM0PR02MB5714AC9B92023FFCE36909658A320@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297BE640F832BE33E4118759A320@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <18e8e992-b894-bda4-a82b-e613ca5215e0@redhat.com>

On 1/20/20 3:08 PM, Doerr, Martin wrote:
> age 	author 	description
> 15 months ago 	vagarwal 	8237540: Missing files in backport of JDK-8210910default tip
> 15 months ago 	akolarkunnu 	8237541: Missing files in backport of JDK-8236528

This fixes the test failures for me!

Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Tue Jan 21 08:15:59 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 21 Jan 2020 08:15:59 +0000
Subject: [11u] Incomplete backport: JDK-8209499
In-Reply-To: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
References: <75a957bc-ee10-6e31-b7c7-1051c634d16f@redhat.com>
Message-ID: <VE1PR02MB54223A5BC9BFC1B1298DFFA4EC0D0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi,

sorry for breaking these!
I wonder how this happened. Probably the files were already there
in the repo when I did the hg import, due to some previous
broken import.  But that should not be the case, as these 
changes applied clean.

Martin, Aleksey, thanks for fixing this!

Best regards,
  Goetz

> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Montag, 20. Januar 2020 14:12
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [11u] Incomplete backport: JDK-8209499
> 
> Hi again,
> 
> See:
>   https://bugs.openjdk.java.net/browse/JDK-8209499
> 
> Compare:
>   https://hg.openjdk.java.net/jdk/jdk/rev/e851c8ca30a7
>   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/111a1a8bbbd4
> 
> Again, new files are missing.
> 
> I think this is why new test times out in 11u:
>  $ make run-test TEST=sanity/client/SwingSet/src/EditorPaneDemoTest.java
> 
> If I copy the missing files, it starts to pass.
> 
> --
> Thanks,
> -Aleksey


From jianglizhou at google.com  Wed Jan 22 01:04:52 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 21 Jan 2020 17:04:52 -0800
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap regions
 usable even if compressed oop encoding has changed
Message-ID: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>

I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
enhancement that improves CDS usability and would improve startup time
if there's an existing default CDS archive (currently does not exist
in OpenJDK 11).

  webrev: http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.00

The backport applied to jdk11u-dev mostly clean. The following small
set of changes were hand merged to filemap.cpp without additional
modifications. The backport was tested with all existing cds and
appcds tests, and tier 1 tests.

--- filemap.cpp
+++ filemap.cpp
@@ -967,7 +1069,9 @@
     if (base == NULL || base != addr) {
       // dealloc the regions from java heap
       dealloc_archive_heap_regions(regions, region_num);
-      log_info(cds)("UseSharedSpaces: Unable to map at required
address in java heap.");
+      log_info(cds)("UseSharedSpaces: Unable to map at required
address in java heap. "
+                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
+                    p2i(addr), regions[i].byte_size());
       return false;
     }
   }
@@ -1216,34 +1348,25 @@
          idx == MetaspaceShared::rw ||
          idx == MetaspaceShared::mc ||
          idx == MetaspaceShared::md, "invalid region index");
-  char* base = _header->region_addr(idx);
+  char* base = region_addr(idx);
   if (p >= base && p < base + space_at(idx)->_used) {
     return true;
   }
   return false;
 }

-void FileMapInfo::print_shared_spaces() {
-  tty->print_cr("Shared Spaces:");
-  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
-    CDSFileMapRegion* si = space_at(i);
-    char *base = _header->region_addr(i);
-    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
-                        shared_region_name[i],
-                        p2i(base), p2i(base + si->_used));
-  }
-}
-
 // Unmap mapped regions of shared space.
 void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
   FileMapInfo *map_info = FileMapInfo::current_info();
   if (map_info) {
     map_info->fail_continue("%s", msg);
     for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
-      char *addr = map_info->_header->region_addr(i);
-      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
-        map_info->unmap_region(i);
-        map_info->space_at(i)->_addr._base = NULL;
+      if (!MetaspaceShared::is_heap_region(i)) {
+        char *addr = map_info->region_addr(i);
+        if (addr != NULL) {
+          map_info->unmap_region(i);
+          map_info->space_at(i)->_addr._base = NULL;
+        }

Best regards,
Jiangli

From aph at redhat.com  Thu Jan 23 14:10:30 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Jan 2020 14:10:30 +0000
Subject: [aarch64-port-dev ] RFR (11u): 8224187: Refactor
 arraycopy_prologue to allow ZGC read barriers on arraycopy
In-Reply-To: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>
References: <16275de9-2e23-ce03-a329-cebd26bea10d@redhat.com>
Message-ID: <23cac5d2-d7af-c8f3-0e33-6926c3551201@redhat.com>

On 1/17/20 3:08 PM, Roman Kennke wrote:
> The patch only differs from the original patch in that it omits the
> Shenandoah parts, which are not in 11u, yet. Other than those, it
> applies cleanly.
> 
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8224187/webrev.00/

Sure, thanks.

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


From denghui.ddh at alibaba-inc.com  Fri Jan 24 05:59:27 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Fri, 24 Jan 2020 13:59:27 +0800
Subject: =?UTF-8?B?UkZSIChYUykgODIzNzgwNjogQ29udmVydCBUSU1FT1VUIG9mIHN1bi5uZXQuZG5zLlJlc29s?=
 =?UTF-8?B?dmVyQ29uZmlndXJhdGlvbkltcGwgaW50byBwcm9wZXJ0eQ==?=
Message-ID: <8d1d76e2-5a49-4a7c-9839-7db1fc64b0b4.denghui.ddh@alibaba-inc.com>

Hi team,
Could I have a review of a small change that converts TIMEOUT of ResolverConfigurationImpl into property.
Summary:
The value of TIMEOUT of ResolverConfigurationImpl was hardcoded, it's useful to use a system property to specify
the value of it.


JIRA: https://bugs.openjdk.java.net/browse/JDK-8237806
Webrev: http://cr.openjdk.java.net/~ddong/8237806/webrev.00/

Thanks
Denghui Dong

From david.holmes at oracle.com  Fri Jan 24 06:39:31 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jan 2020 16:39:31 +1000
Subject: RFR (XS) 8237806: Convert TIMEOUT of
 sun.net.dns.ResolverConfigurationImpl into property
In-Reply-To: <8d1d76e2-5a49-4a7c-9839-7db1fc64b0b4.denghui.ddh@alibaba-inc.com>
References: <8d1d76e2-5a49-4a7c-9839-7db1fc64b0b4.denghui.ddh@alibaba-inc.com>
Message-ID: <9ddbd6e2-cdba-b4d7-2cbc-0feb9c701f27@oracle.com>

Hi,

This looks like it should be going to net-dev at openjdk.java.net if 
intended for mainline jdk/jdk. Also adding a property will need a CSR 
request to be filed and approved:

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

Thanks,
David

On 24/01/2020 3:59 pm, Denghui Dong wrote:
> Hi team,
> Could I have a review of a small change that converts TIMEOUT of ResolverConfigurationImpl into property.
> Summary:
> The value of TIMEOUT of ResolverConfigurationImpl was hardcoded, it's useful to use a system property to specify
> the value of it.
> 
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8237806
> Webrev: http://cr.openjdk.java.net/~ddong/8237806/webrev.00/
> 
> Thanks
> Denghui Dong
> 

From denghui.ddh at alibaba-inc.com  Fri Jan 24 08:18:15 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Fri, 24 Jan 2020 16:18:15 +0800
Subject: =?UTF-8?B?UmU6IFJGUiAoWFMpIDgyMzc4MDY6IENvbnZlcnQgVElNRU9VVCBvZiBzdW4ubmV0LmRucy5S?=
 =?UTF-8?B?ZXNvbHZlckNvbmZpZ3VyYXRpb25JbXBsIGludG8gcHJvcGVydHk=?=
In-Reply-To: <9ddbd6e2-cdba-b4d7-2cbc-0feb9c701f27@oracle.com>
References: <8d1d76e2-5a49-4a7c-9839-7db1fc64b0b4.denghui.ddh@alibaba-inc.com>,
 <9ddbd6e2-cdba-b4d7-2cbc-0feb9c701f27@oracle.com>
Message-ID: <c739901d-215c-4279-aaad-036fdd7cf2a8.denghui.ddh@alibaba-inc.com>

Thanks for your remind!

Denghui Dong
------------------------------------------------------------------
From:David Holmes <david.holmes at oracle.com>
Send Time:2020?1?24?(???) 14:39
To:???(??) <denghui.ddh at alibaba-inc.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Subject:Re: RFR (XS) 8237806: Convert TIMEOUT of sun.net.dns.ResolverConfigurationImpl into property

Hi,

This looks like it should be going to net-dev at openjdk.java.net if 
intended for mainline jdk/jdk. Also adding a property will need a CSR 
request to be filed and approved:

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

Thanks,
David

On 24/01/2020 3:59 pm, Denghui Dong wrote:
> Hi team,
> Could I have a review of a small change that converts TIMEOUT of ResolverConfigurationImpl into property.
> Summary:
> The value of TIMEOUT of ResolverConfigurationImpl was hardcoded, it's useful to use a system property to specify
> the value of it.
> 
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8237806
> Webrev: http://cr.openjdk.java.net/~ddong/8237806/webrev.00/
> 
> Thanks
> Denghui Dong
> 

From akashche at redhat.com  Fri Jan 24 10:59:36 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Fri, 24 Jan 2020 10:59:36 +0000
Subject: [11u] RFR: 8216472: (se) Stack overflow during selection operation
 leads to crash (win)
Message-ID: <c21f52d6-40ad-e330-87a1-30b92e148b24@redhat.com>

Hi,

Please review the backport of JDK-8216472 to 11u:

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

Original review thread: 
https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html

Original review thread (continuation): 
https://mail.openjdk.java.net/pipermail/nio-dev/2019-November/006777.html

Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e

11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8216472/webrev.00/

Please note, that original change, besides moving structs off the stack, 
additionally removes the logic for the case, when select() call returns 
SOCKET_ERROR:

  - starting here: 
https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e#l2.58
  - explanation (point 1 there): 
https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006708.html

To stay on the safe side with LTS versions, this 11u backport keeps 
select() failure logic intact and allocates the space for 6 fd_set 
structs (instead of 3 in original change). It is proposed to have the 
change added to 11u in this "fix only" form. And, if necessary, to 
remove select() failure logic in a follow-up change.

Testing: 11u change in this form was included with Red Hat 
11.0.6-windows release and passed usual release testing.

-- 
-Alex


From christoph.langer at sap.com  Fri Jan 24 13:04:14 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 13:04:14 +0000
Subject: [11u] RFR: 8231081: TestMetadataRetention fails due to missing symbol
 id
Message-ID: <AM0PR02MB5714D19A9907A12145AE3B288A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

as we are about to backport JDK-8225797 [0] - OldObjectSample event creates unexpected amount of checkpoint data - we should also backport JDK-8231081.

This patch did not apply cleanly, I had rejects in the following files:
src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp
src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp

The first ones were due to the missing ClassDatagraph lock in 11u.

I've resolved them and with the change all jfr related jtreg tests pass, as well as the added testcase.

Bug: https://bugs.openjdk.java.net/browse/JDK-8231081
Original change: https://hg.openjdk.java.net/jdk/jdk/rev/7909763ad193
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8231081.11u/

Please review.

Thanks
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8225797


From christoph.langer at sap.com  Fri Jan 24 14:24:00 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 14:24:00 +0000
Subject: FW: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <AM0PR02MB5714ADAC3148036E5CA3B30E8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
 <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>
 <AM6PR02MB49845530BE014E771BD5EBA88A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ74obrAhnA6TnysKNyYwxUUgh1PBnrPN-x3KUpXobYJZA@mail.gmail.com>
 <AM0PR02MB5714ADAC3148036E5CA3B30E8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714916722F3F0A7E1D546F88A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jaroslav, all,

I?m done with testing your backport patch for JDK-8225797 now.

So, this was your original proposal:
JBS: https://bugs.openjdk.java.net/browse/JDK-8225797
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/caa25ab47aca
Initial backport Webrev: http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/

First of all, to make the debug build work, I had to do a very few modifications (incremental diff to your original backport): http://cr.openjdk.java.net/~clanger/webrevs/8225797.fix-debug-incremental.11u/
It was mainly about the ClassLoaderDataGraph_lock and cld->is_unsafe_anonymous() which don?t exist in jdk11 but were used in assertions. So this would only be noticed in debug builds.

So this is the final webrev with the changes worked in: http://cr.openjdk.java.net/~clanger/webrevs/8225797.11u/

Please review.

When pushing this, we also need to push the fix for https://bugs.openjdk.java.net/browse/JDK-8231025 (Incorrect method tag offset for big endian platform), otherwise we?ll see crashes and test failures in big endian platforms like sun_64 or linuxppc64 and AIX. However, this change applies with minor fuzz, so it should just be tagged with a jdk11u-fix-request label.

I also suggest to backport JDK-8231081 (TestMetadataRetention fails due to missing symbol id) immediately after 8225797 but I?ll send out a separate RFR for this.

Best regards
Christoph


From christoph.langer at sap.com  Fri Jan 24 14:32:52 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 14:32:52 +0000
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
Message-ID: <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jiangli,

This backport looks good to me.

Would you want me to run it through our test infrastructure to get additional confidence?

Cheers
Christoph

> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-
> bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> Sent: Mittwoch, 22. Januar 2020 02:05
> To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> runtime-dev at openjdk.java.net>
> Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> regions usable even if compressed oop encoding has changed
> 
> I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> enhancement that improves CDS usability and would improve startup time
> if there's an existing default CDS archive (currently does not exist
> in OpenJDK 11).
> 
>   webrev: http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.00
> 
> The backport applied to jdk11u-dev mostly clean. The following small
> set of changes were hand merged to filemap.cpp without additional
> modifications. The backport was tested with all existing cds and
> appcds tests, and tier 1 tests.
> 
> --- filemap.cpp
> +++ filemap.cpp
> @@ -967,7 +1069,9 @@
>      if (base == NULL || base != addr) {
>        // dealloc the regions from java heap
>        dealloc_archive_heap_regions(regions, region_num);
> -      log_info(cds)("UseSharedSpaces: Unable to map at required
> address in java heap.");
> +      log_info(cds)("UseSharedSpaces: Unable to map at required
> address in java heap. "
> +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> +                    p2i(addr), regions[i].byte_size());
>        return false;
>      }
>    }
> @@ -1216,34 +1348,25 @@
>           idx == MetaspaceShared::rw ||
>           idx == MetaspaceShared::mc ||
>           idx == MetaspaceShared::md, "invalid region index");
> -  char* base = _header->region_addr(idx);
> +  char* base = region_addr(idx);
>    if (p >= base && p < base + space_at(idx)->_used) {
>      return true;
>    }
>    return false;
>  }
> 
> -void FileMapInfo::print_shared_spaces() {
> -  tty->print_cr("Shared Spaces:");
> -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> -    CDSFileMapRegion* si = space_at(i);
> -    char *base = _header->region_addr(i);
> -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> -                        shared_region_name[i],
> -                        p2i(base), p2i(base + si->_used));
> -  }
> -}
> -
>  // Unmap mapped regions of shared space.
>  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
>    FileMapInfo *map_info = FileMapInfo::current_info();
>    if (map_info) {
>      map_info->fail_continue("%s", msg);
>      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> -      char *addr = map_info->_header->region_addr(i);
> -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> -        map_info->unmap_region(i);
> -        map_info->space_at(i)->_addr._base = NULL;
> +      if (!MetaspaceShared::is_heap_region(i)) {
> +        char *addr = map_info->region_addr(i);
> +        if (addr != NULL) {
> +          map_info->unmap_region(i);
> +          map_info->space_at(i)->_addr._base = NULL;
> +        }
> 
> Best regards,
> Jiangli

From christoph.langer at sap.com  Fri Jan 24 14:51:10 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 14:51:10 +0000
Subject: [14u Communication] jdk14u repo available
In-Reply-To: <20200114142450.GG9097@yoga>
References: <20190624154130.GB19779@vimes> <20200114142450.GG9097@yoga>
Message-ID: <AM0PR02MB571497850D7D4497FFB6DC9B8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Rob,

that's great, thank you.

There are already the first backport requests ??

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Rob McKenna
> Sent: Dienstag, 14. Januar 2020 15:25
> To: jdk-updates-dev at openjdk.java.net
> Subject: [14u Communication] jdk14u repo available
> 
> I'd like to announce the availibility of the JDK 14 Updates forest at:
> 
> http://hg.openjdk.java.net/jdk-updates/jdk14u/
> 
> Thanks,
> 
>     -Rob

From christoph.langer at sap.com  Fri Jan 24 15:21:17 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 15:21:17 +0000
Subject: Issue with 13.0.2 release (was: [Updates Communication] 13.0.2
 security patches pushed)
Message-ID: <AM0PR02MB57142F27C079007D65808D6F8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Rob,

first of all, thanks for pushing the security patches to 13.0.2 and setting the tags.

I have, however, found a little issue. The tag 13.0.2-ga points to this change: http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/7b8ce94cc932

If you look at the repository tree, you'll see however that this change is below the merge of this branch and another line in jdk13u which contains the last 6 public pushes:

8233223: Add Amazon Root CA certificates8 weeks ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/459a2f735b99 
8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong checksum2 months ago, by jiefu - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/b2305a0a3146 
8233219: NMT output on AIX misses some categories2 months ago, by mbaesken - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/0919082b7634 
8232019: Add LuxTrust certificate updates to the existing root program2 months ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/e69aa0686696 
8234107: Several AWT modal dialog tests failing on Linux after JDK-82319912 months ago, by neugens - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/486735e93d55 
8231991: Mouse wheel change focus on awt/swing windows - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/743b29c2372f 

So, these 6 changesets are not contained in 13.0.2-ga!

Looking at the corresponding JBS items, you'll find resolved backports of these for 13.0.2 and 13u-cpu. I think since we see 13.0.2 here, those should be under the 13.0.2-ga tag.

For the LuxTrust and Amazon Root CA changes, there have been separate pushes in your internal repository as well which are in 13.0.2-ga. And I believe 8234245 was contained in your internal 8233223 push. So, effectively 13.0.2 OpenJDK is missing these items:
8233219: NMT output on AIX misses some categories
8234107: Several AWT modal dialog tests failing on Linux after JDK-8231991
8231991: Mouse wheel change focus on awt/swing windows

I don't know whether we should move the 13.0.2-ga tag to the merge commit or just leave it as is, given the importance of JDK13 and the priority of these fixes. But in any case, this shouldn't happen again with 14.0.1 and later...

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Rob McKenna
> Sent: Donnerstag, 16. Januar 2020 16:18
> To: Severin Gehwolf <sgehwolf at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: [Updates Communication] 13.0.2 security patches pushed
> 
> Just pushed - apologies for the delay.
> 
>     -Rob
> 
> On 15/01/20 18:06, Severin Gehwolf wrote:
> > On Wed, 2020-01-15 at 16:05 +0000, Rob McKenna wrote:
> > > 13.0.2 patches have been pushed to:
> > >
> > > http://hg.openjdk.java.net/jdk-updates/jdk13u/
> >
> > Thanks, Rob! Is there going to be a jdk-13.0.2-ga tag?
> >
> > Cheers,
> > Severin
> >

From jianglizhou at google.com  Fri Jan 24 15:32:13 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 24 Jan 2020 07:32:13 -0800
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
 <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>

Hi Christoph,

On Fri, Jan 24, 2020 at 6:33 AM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Jiangli,
>
> This backport looks good to me.
>
> Would you want me to run it through our test infrastructure to get additional confidence?
>

That would be most helpful and reassuring. I will wait for your
testing result before pushing. Thank you!

Best regards,

Jiangli
> Cheers
> Christoph
>
> > -----Original Message-----
> > From: hotspot-runtime-dev <hotspot-runtime-dev-
> > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> > Sent: Mittwoch, 22. Januar 2020 02:05
> > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > runtime-dev at openjdk.java.net>
> > Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > regions usable even if compressed oop encoding has changed
> >
> > I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> > enhancement that improves CDS usability and would improve startup time
> > if there's an existing default CDS archive (currently does not exist
> > in OpenJDK 11).
> >
> >   webrev: http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.00
> >
> > The backport applied to jdk11u-dev mostly clean. The following small
> > set of changes were hand merged to filemap.cpp without additional
> > modifications. The backport was tested with all existing cds and
> > appcds tests, and tier 1 tests.
> >
> > --- filemap.cpp
> > +++ filemap.cpp
> > @@ -967,7 +1069,9 @@
> >      if (base == NULL || base != addr) {
> >        // dealloc the regions from java heap
> >        dealloc_archive_heap_regions(regions, region_num);
> > -      log_info(cds)("UseSharedSpaces: Unable to map at required
> > address in java heap.");
> > +      log_info(cds)("UseSharedSpaces: Unable to map at required
> > address in java heap. "
> > +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> > +                    p2i(addr), regions[i].byte_size());
> >        return false;
> >      }
> >    }
> > @@ -1216,34 +1348,25 @@
> >           idx == MetaspaceShared::rw ||
> >           idx == MetaspaceShared::mc ||
> >           idx == MetaspaceShared::md, "invalid region index");
> > -  char* base = _header->region_addr(idx);
> > +  char* base = region_addr(idx);
> >    if (p >= base && p < base + space_at(idx)->_used) {
> >      return true;
> >    }
> >    return false;
> >  }
> >
> > -void FileMapInfo::print_shared_spaces() {
> > -  tty->print_cr("Shared Spaces:");
> > -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> > -    CDSFileMapRegion* si = space_at(i);
> > -    char *base = _header->region_addr(i);
> > -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> > -                        shared_region_name[i],
> > -                        p2i(base), p2i(base + si->_used));
> > -  }
> > -}
> > -
> >  // Unmap mapped regions of shared space.
> >  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
> >    FileMapInfo *map_info = FileMapInfo::current_info();
> >    if (map_info) {
> >      map_info->fail_continue("%s", msg);
> >      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> > -      char *addr = map_info->_header->region_addr(i);
> > -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> > -        map_info->unmap_region(i);
> > -        map_info->space_at(i)->_addr._base = NULL;
> > +      if (!MetaspaceShared::is_heap_region(i)) {
> > +        char *addr = map_info->region_addr(i);
> > +        if (addr != NULL) {
> > +          map_info->unmap_region(i);
> > +          map_info->space_at(i)->_addr._base = NULL;
> > +        }
> >
> > Best regards,
> > Jiangli

From jaroslav.bachorik at datadoghq.com  Fri Jan 24 16:53:27 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 24 Jan 2020 11:53:27 -0500
Subject: [11u] RFR: 8231081: TestMetadataRetention fails due to missing
 symbol id
In-Reply-To: <AM0PR02MB5714D19A9907A12145AE3B288A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714D19A9907A12145AE3B288A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CAPb8aJ6PZ3Wikv1CTaqQ3mHggp8TrBEASc9fbRCuZbpqm3qkGg@mail.gmail.com>

Looks good!

Thanks,

-JB-

On Fri, Jan 24, 2020 at 8:04 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
>
>
> as we are about to backport JDK-8225797 [0] - OldObjectSample event
> creates unexpected amount of checkpoint data - we should also backport
> JDK-8231081.
>
>
>
> This patch did not apply cleanly, I had rejects in the following files:
>
> src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
>
> src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp
>
> src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp
>
>
>
> The first ones were due to the missing ClassDatagraph lock in 11u.
>
>
>
> I?ve resolved them and with the change all jfr related jtreg tests pass,
> as well as the added testcase.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231081
>
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/7909763ad193
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8231081.11u/
>
>
>
> Please review.
>
>
>
> Thanks
>
> Christoph
>
>
>
> [0] https://bugs.openjdk.java.net/browse/JDK-8225797
>
>
>

From christoph.langer at sap.com  Fri Jan 24 22:33:07 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 22:33:07 +0000
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
 <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>
Message-ID: <AM0PR02MB57144F5B36E5FBA49A6FC5C78A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jiangli,

unfortunately your patch seems to break every build because the file memory/heapShared.inline.hpp does not exist in 11u. So I think you have to update the patch a bit further...

Best regards
Christoph

> -----Original Message-----
> From: Jiangli Zhou <jianglizhou at google.com>
> Sent: Freitag, 24. Januar 2020 16:32
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> runtime-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> regions usable even if compressed oop encoding has changed
>
> Hi Christoph,
>
> On Fri, Jan 24, 2020 at 6:33 AM Langer, Christoph
> <christoph.langer at sap.com> wrote:
> >
> > Hi Jiangli,
> >
> > This backport looks good to me.
> >
> > Would you want me to run it through our test infrastructure to get
> additional confidence?
> >
>
> That would be most helpful and reassuring. I will wait for your
> testing result before pushing. Thank you!
>
> Best regards,
>
> Jiangli
> > Cheers
> > Christoph
> >
> > > -----Original Message-----
> > > From: hotspot-runtime-dev <hotspot-runtime-dev-
> > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> > > Sent: Mittwoch, 22. Januar 2020 02:05
> > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > > runtime-dev at openjdk.java.net>
> > > Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > regions usable even if compressed oop encoding has changed
> > >
> > > I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> > > enhancement that improves CDS usability and would improve startup
> time
> > > if there's an existing default CDS archive (currently does not exist
> > > in OpenJDK 11).
> > >
> > >   webrev: http://cr.openjdk.java.net/~jiangli/8208658-
> backport/webrev.00
> > >
> > > The backport applied to jdk11u-dev mostly clean. The following small
> > > set of changes were hand merged to filemap.cpp without additional
> > > modifications. The backport was tested with all existing cds and
> > > appcds tests, and tier 1 tests.
> > >
> > > --- filemap.cpp
> > > +++ filemap.cpp
> > > @@ -967,7 +1069,9 @@
> > >      if (base == NULL || base != addr) {
> > >        // dealloc the regions from java heap
> > >        dealloc_archive_heap_regions(regions, region_num);
> > > -      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > address in java heap.");
> > > +      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > address in java heap. "
> > > +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> > > +                    p2i(addr), regions[i].byte_size());
> > >        return false;
> > >      }
> > >    }
> > > @@ -1216,34 +1348,25 @@
> > >           idx == MetaspaceShared::rw ||
> > >           idx == MetaspaceShared::mc ||
> > >           idx == MetaspaceShared::md, "invalid region index");
> > > -  char* base = _header->region_addr(idx);
> > > +  char* base = region_addr(idx);
> > >    if (p >= base && p < base + space_at(idx)->_used) {
> > >      return true;
> > >    }
> > >    return false;
> > >  }
> > >
> > > -void FileMapInfo::print_shared_spaces() {
> > > -  tty->print_cr("Shared Spaces:");
> > > -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> > > -    CDSFileMapRegion* si = space_at(i);
> > > -    char *base = _header->region_addr(i);
> > > -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> > > -                        shared_region_name[i],
> > > -                        p2i(base), p2i(base + si->_used));
> > > -  }
> > > -}
> > > -
> > >  // Unmap mapped regions of shared space.
> > >  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
> > >    FileMapInfo *map_info = FileMapInfo::current_info();
> > >    if (map_info) {
> > >      map_info->fail_continue("%s", msg);
> > >      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> > > -      char *addr = map_info->_header->region_addr(i);
> > > -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> > > -        map_info->unmap_region(i);
> > > -        map_info->space_at(i)->_addr._base = NULL;
> > > +      if (!MetaspaceShared::is_heap_region(i)) {
> > > +        char *addr = map_info->region_addr(i);
> > > +        if (addr != NULL) {
> > > +          map_info->unmap_region(i);
> > > +          map_info->space_at(i)->_addr._base = NULL;
> > > +        }
> > >
> > > Best regards,
> > > Jiangli

From jianglizhou at google.com  Fri Jan 24 23:34:35 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 24 Jan 2020 15:34:35 -0800
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <AM0PR02MB57144F5B36E5FBA49A6FC5C78A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
 <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>
 <AM0PR02MB57144F5B36E5FBA49A6FC5C78A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jwmt210RpbNX92PJXP+TaEQSeWwwRA4AHfh7LY2Oh=84A@mail.gmail.com>

Hi Christoph,

Oops, forgot to run 'hg add ...' before generating the webrev. The
webrev was missing the following two files. Thank you for catching
that!

  src/hotspot/share/memory/heapShared.inline.hpp
  test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java

Here is the updated webrev with the missing files included. Could you
please try the new patch? Thanks!

http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.01/

Best regards,

Jiangli

On Fri, Jan 24, 2020 at 2:33 PM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Jiangli,
>
> unfortunately your patch seems to break every build because the file memory/heapShared.inline.hpp does not exist in 11u. So I think you have to update the patch a bit further...
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: Jiangli Zhou <jianglizhou at google.com>
> > Sent: Freitag, 24. Januar 2020 16:32
> > To: Langer, Christoph <christoph.langer at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > runtime-dev at openjdk.java.net>
> > Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > regions usable even if compressed oop encoding has changed
> >
> > Hi Christoph,
> >
> > On Fri, Jan 24, 2020 at 6:33 AM Langer, Christoph
> > <christoph.langer at sap.com> wrote:
> > >
> > > Hi Jiangli,
> > >
> > > This backport looks good to me.
> > >
> > > Would you want me to run it through our test infrastructure to get
> > additional confidence?
> > >
> >
> > That would be most helpful and reassuring. I will wait for your
> > testing result before pushing. Thank you!
> >
> > Best regards,
> >
> > Jiangli
> > > Cheers
> > > Christoph
> > >
> > > > -----Original Message-----
> > > > From: hotspot-runtime-dev <hotspot-runtime-dev-
> > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> > > > Sent: Mittwoch, 22. Januar 2020 02:05
> > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > > > runtime-dev at openjdk.java.net>
> > > > Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > > regions usable even if compressed oop encoding has changed
> > > >
> > > > I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> > > > enhancement that improves CDS usability and would improve startup
> > time
> > > > if there's an existing default CDS archive (currently does not exist
> > > > in OpenJDK 11).
> > > >
> > > >   webrev: http://cr.openjdk.java.net/~jiangli/8208658-
> > backport/webrev.00
> > > >
> > > > The backport applied to jdk11u-dev mostly clean. The following small
> > > > set of changes were hand merged to filemap.cpp without additional
> > > > modifications. The backport was tested with all existing cds and
> > > > appcds tests, and tier 1 tests.
> > > >
> > > > --- filemap.cpp
> > > > +++ filemap.cpp
> > > > @@ -967,7 +1069,9 @@
> > > >      if (base == NULL || base != addr) {
> > > >        // dealloc the regions from java heap
> > > >        dealloc_archive_heap_regions(regions, region_num);
> > > > -      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > address in java heap.");
> > > > +      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > address in java heap. "
> > > > +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> > > > +                    p2i(addr), regions[i].byte_size());
> > > >        return false;
> > > >      }
> > > >    }
> > > > @@ -1216,34 +1348,25 @@
> > > >           idx == MetaspaceShared::rw ||
> > > >           idx == MetaspaceShared::mc ||
> > > >           idx == MetaspaceShared::md, "invalid region index");
> > > > -  char* base = _header->region_addr(idx);
> > > > +  char* base = region_addr(idx);
> > > >    if (p >= base && p < base + space_at(idx)->_used) {
> > > >      return true;
> > > >    }
> > > >    return false;
> > > >  }
> > > >
> > > > -void FileMapInfo::print_shared_spaces() {
> > > > -  tty->print_cr("Shared Spaces:");
> > > > -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> > > > -    CDSFileMapRegion* si = space_at(i);
> > > > -    char *base = _header->region_addr(i);
> > > > -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> > > > -                        shared_region_name[i],
> > > > -                        p2i(base), p2i(base + si->_used));
> > > > -  }
> > > > -}
> > > > -
> > > >  // Unmap mapped regions of shared space.
> > > >  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
> > > >    FileMapInfo *map_info = FileMapInfo::current_info();
> > > >    if (map_info) {
> > > >      map_info->fail_continue("%s", msg);
> > > >      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> > > > -      char *addr = map_info->_header->region_addr(i);
> > > > -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> > > > -        map_info->unmap_region(i);
> > > > -        map_info->space_at(i)->_addr._base = NULL;
> > > > +      if (!MetaspaceShared::is_heap_region(i)) {
> > > > +        char *addr = map_info->region_addr(i);
> > > > +        if (addr != NULL) {
> > > > +          map_info->unmap_region(i);
> > > > +          map_info->space_at(i)->_addr._base = NULL;
> > > > +        }
> > > >
> > > > Best regards,
> > > > Jiangli

From andrey.petushkov at gmail.com  Mon Jan 27 09:52:19 2020
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Mon, 27 Jan 2020 12:52:19 +0300
Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes
In-Reply-To: <DB8PR02MB5547DD102CE2859CCC93BEC98A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com>
 <AM6PR02MB5192E6B4EE0CBCEFDE2E048C8A9A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com>
 <AM6PR02MB480160158C767BD07A085BCE8A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <AM6PR02MB48014FA3A55DDF7148DE7AA38A4E0@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <DB8PR02MB55479EC14D2B4481676F187A8A5C0@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com>
 <DB8PR02MB55475FED0C39FA48E9F0DB018A5F0@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <ac2fac3c-4c7f-4af6-a227-5101bdf0c879.denghui.ddh@alibaba-inc.com>
 <DB8PR02MB5547131FB9967E25B27E076F8A580@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com>
 <DD83F159-A3F2-4253-A335-291399CBF633@azul.com>
 <DB8PR02MB5547DD102CE2859CCC93BEC98A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
Message-ID: <CADV+1JrDfn8gkq9wdHpz6o7rg1Rx5v+uQRH5cVWaNihST-Z2Ow@mail.gmail.com>

Hi Christoph, All,

Please excuse me for taking so long to respond.
Finally we got a list of JFR changes which are considered by Azul as
worth backporting to jdk11.

Features and changesets they depend on:
8185525: Add JFR event for DictionarySizes
   8223599: minimal build fails after JDK-8185525
   8225310: JFR crashed in
JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics()
8196341: Add JFR events for parallel phases of G1
   8211239: Build fails without JFR: empty JFR events signatures mismatch
8216041: [Event Request] - Deoptimization
8226897: Provide object age with JFR OldObjectSample event
8232594: Make the output of the JFR command duration more user friendly
8226511: Implement JFR Event Streaming
   8233700: EventStream not closed
   8233870: JFR TestSetEndTime.java times out - onClose() is never called
   8234059: Stress test fails with "Unexpected Exception in thread JFR
Event Stream"
   8234671: JFR api/consumer/recordingstream/TestStart.java failed due
to timeout at testStartTwice()
   8234684: JFR crashes when rotating the JFR output during assertion failure
   8234888: EventStream::close doesn't abort streaming thread
   8229209: [TESTBUG] test for cross-process JFR event streaming
   8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should clean up files
   8235454: [TESTBUG] Basic test for JFR event streaming for jdk_jfr_sanity

Bugfixes and improvements:
8215237: jdk.jfr.Recording javadoc does not compile
8216565: Specifying the same path creates a new directory in JFR.configure
   8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with
"java.lang.RuntimeException: assertTrue: expected true, was false"
8216995: Clean up JFR command line processing
8217089: JFR: Lazy install os interface components for improved startup
8219205: JFR file without license header
8230400: Missing constant pool entry for a method in stacktrace
8230767: FlightRecorderListener returns null recording
8220344: Build failures when using --with-jvm-features=-g1gc,-jfr
8233111: Epoch shift synchronization point for Compiler threads
8233197: Invert JvmtiExport::post_vm_initialized() and
Jfr:on_vm_start() start-up order for correct option parsing
8233375: JFR emergency dump does not recover thread state
8234060: Potential memory reordering problem in JfrBuffer flush mechanism
8235390: JfrEmergencyDump::on_vm_shutdown crashes
8235654: JFR leak profiler should not trace through the StringTable
8222379: JFR TestClassLoadEvent.java failed due to EXCEPTION_ACCESS_VIOLATION
8232905: JFR fails with assertion: assert(t->unflushed_size() == 0)
failed: invariant
8233416: JFR: assert((((((klass)->trace_id()) & (((1 << 1) << 8) |
(JfrTraceIdEpoch::in_use_this_epoch_bit()))) != 0))) failed: invariant
8210024: JFR calls virtual is_Java_thread from ~Thread()
8225004: Remove invalid assertion in jfr_conditional_flush()
8225797: OldObjectSample event creates unexpected amount of checkpoint data
   8231025: Incorrect method tag offset for big endian platform
   8231081: TestMetadataRetention fails due to missing symbol id
8209802: Garbage collectors should register JFR types themselves to
avoid build errors
(the last 6 are already have backport-request label)

Most of those we'd like to backport to jdk8 as well

Thanks,
Andrey


On Thu, Dec 19, 2019 at 5:06 PM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Andrey,
>
> thanks for your comments about these JFR event backports.
>
> Can you compile a list of items that you?d like to backport to both, 8u JFR and 11u? Then we can sync together with Mario and Andrew Haley and take a decision about what we want to approve.
>
> Cheers
> Christoph
>
> From: Andrey Petushkov <andrey at azul.com>
> Sent: Montag, 9. Dezember 2019 13:08
> To: Denghui Dong <denghui.ddh at alibaba-inc.com>; Erik Gahlin <erik.gahlin at oracle.com>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Langer, Christoph <christoph.langer at sap.com>
> Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi guys, All,
>
> No, there is not special reasoning for back-porting of this particular event type. Feel free to reject the request. A few comments though
> - we at Azul see JFR as a very useful and successful tool for solving customer issues. So in general we try to keep up with new fixes and features there, unless we consider fix as too risky or inappropriate
> - all these JFR backports proposed are undergo full test cycle, involving all tests we have (including of course all jtreg) on all platforms supported by Azul (well, a lot)
> - @Christoph regarding fix not yet pushed to 8u. We (Marrio and team involved into JFR to 8u backporting)  have a policy that we don't push into 8u until it's pushed into 11u. Hence it's not pushed
>
> Regards,
> Andrey
>
>
> On 9 Dec 2019, at 12:33, Denghui Dong <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com>> wrote:
>
> I think we could wait for Andrey's reply to this issue before we decide whether to reject the backport.
>
> Thanks,
> Denghui Dong
> ------------------------------------------------------------------
> From:Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
> Send Time:2019?12?9?(???) 17:17
> To:???(??) <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com>>; Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>; Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>; Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>
> Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi Denghui,
>
> ok, I see. So, taking a glance on http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/, I can?t see that the bug is pushed there. So, if that?s true, I?d rather reject the backport to 11u for now. Would you agree?
>
> Thanks
> Christoph
>
> From: Denghui Dong <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com>>
> Sent: Montag, 9. Dezember 2019 10:06
> To: Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Andrey Petushkov <andrey at azul.com<mailto:andrey at azul.com>>; Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>
> Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi Christoph,
>   I was on vacation last week, sorry for the late reply.
>   In fact, the backport of 8185525 for 8u was requested by @Andrey at first (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html)
>   For the sake of consistency, I made this backport for 11u.
>   And in my opinion, these events are not very useful for users indeed.
>
> Thanks,
> Denghui Dong
> ------------------------------------------------------------------
> From:Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
> Send Time:2019?12?6?(???) 16:32
> To:Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Cc:???(??) <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com>>
> Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi Erik,
>
> thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high.
>
> @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents?
>
> Thanks
> Christoph
>
> From: Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>>
> Sent: Freitag, 6. Dezember 2019 05:14
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Cc: Denghui Dong <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
> Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi,
>
> What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording.
>
> Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another.
>
> In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported.
>
> My $.02
>
> Erik
>
> On 5 Dec 2019, at 23:28, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
>
> Hi Denghui,
>
> since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions.
>
> Cheers
> Christoph
>
> From: Langer, Christoph
> Sent: Freitag, 22. November 2019 00:30
> To: Denghui Dong <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com>>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Cc: Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>
> Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi,
>
> we had a discussion on this list regarding JFR feature requests. As a summary, I take we should
>
>  1.  Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated)
>  2.  Be very careful when it comes to extensive bugfixes for existing features
>
> This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites.
>
> Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle.
>
> So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date.
>
> Thanks
> Christoph
>
> From: Langer, Christoph
> Sent: Mittwoch, 30. Oktober 2019 15:41
> To: Denghui Dong <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com><mailto:denghui.ddh at alibaba-inc.com>>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net><mailto:jdk-updates-dev at openjdk.java.net>>
> Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi Denghui,
>
> sorry for the late reply.
>
> I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today:
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html
> Let?s see if there?s any feedback?
>
> Best regards
> Christoph
>
> From: Denghui Dong <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com><mailto:denghui.ddh at alibaba-inc.com>>
> Sent: Dienstag, 22. Oktober 2019 04:09
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net><mailto:jdk-updates-dev at openjdk.java.net>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com><mailto:christoph.langer at sap.com>>
> Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi Christoph,
>  What's the status of this backport ?
>  By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/
>
> Thanks,
> Denghui Dong
> ------------------------------------------------------------------
> From:Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com><mailto:christoph.langer at sap.com>>
> Send Time:2019?10?8?(???) 22:34
> To:???(??) <denghui.ddh at alibaba-inc.com<mailto:denghui.ddh at alibaba-inc.com><mailto:denghui.ddh at alibaba-inc.com>>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net><mailto:jdk-updates-dev at openjdk.java.net>>
> Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi Denghui,
>
> this is quite a large JFR enhancement.
>
> Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing.
>
> However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon.
>
> Best regards
> Christoph
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net><mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> Behalf Of Denghui Dong
> Sent: Donnerstag, 26. September 2019 17:03
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net><mailto:jdk-updates-dev at openjdk.java.net>>
> Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes
>
> Hi all,
>  Please review this backport, original patch doesn't apply cleanly, because
> SymbolTable has made some changes in upstream (I think it's not necessary
> to backport those changes)
> and class ClassLoaderDataGraph is located in different files.
> 11u-webrev:
> http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/
> Original bug:
> https://bugs.openjdk.java.net/browse/JDK-8185525
> http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916
> Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java
>
> Thanks,
> Denghui Dong
>

From christoph.langer at sap.com  Mon Jan 27 19:41:32 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 27 Jan 2020 19:41:32 +0000
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <CALrW1jwmt210RpbNX92PJXP+TaEQSeWwwRA4AHfh7LY2Oh=84A@mail.gmail.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
 <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>
 <AM0PR02MB57144F5B36E5FBA49A6FC5C78A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jwmt210RpbNX92PJXP+TaEQSeWwwRA4AHfh7LY2Oh=84A@mail.gmail.com>
Message-ID: <AM0PR02MB57148B7B523C950B3B953EE78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jiangli,

the patch from your second webrev worked well, no regressions spotted. So go ahead with pushing at your convenience.

I, however, noticed that your patch also doesn't contain metadata (e.g. change description, reviewed-by, etc.). So, Im wondering whether you use the workflow to do a hg export --git -r ... > ... and then hg qimport/hg qpush/hg qrefresh. That should keep the metadata intact and also take care that no files get lost... See here for reference, in case you didn't know: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix

Best regards
Christoph

> -----Original Message-----
> From: Jiangli Zhou <jianglizhou at google.com>
> Sent: Samstag, 25. Januar 2020 00:35
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> runtime-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> regions usable even if compressed oop encoding has changed
> 
> Hi Christoph,
> 
> Oops, forgot to run 'hg add ...' before generating the webrev. The
> webrev was missing the following two files. Thank you for catching
> that!
> 
>   src/hotspot/share/memory/heapShared.inline.hpp
>   test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java
> 
> Here is the updated webrev with the missing files included. Could you
> please try the new patch? Thanks!
> 
> http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.01/
> 
> Best regards,
> 
> Jiangli
> 
> On Fri, Jan 24, 2020 at 2:33 PM Langer, Christoph
> <christoph.langer at sap.com> wrote:
> >
> > Hi Jiangli,
> >
> > unfortunately your patch seems to break every build because the file
> memory/heapShared.inline.hpp does not exist in 11u. So I think you have to
> update the patch a bit further...
> >
> > Best regards
> > Christoph
> >
> > > -----Original Message-----
> > > From: Jiangli Zhou <jianglizhou at google.com>
> > > Sent: Freitag, 24. Januar 2020 16:32
> > > To: Langer, Christoph <christoph.langer at sap.com>
> > > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > > runtime-dev at openjdk.java.net>
> > > Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > regions usable even if compressed oop encoding has changed
> > >
> > > Hi Christoph,
> > >
> > > On Fri, Jan 24, 2020 at 6:33 AM Langer, Christoph
> > > <christoph.langer at sap.com> wrote:
> > > >
> > > > Hi Jiangli,
> > > >
> > > > This backport looks good to me.
> > > >
> > > > Would you want me to run it through our test infrastructure to get
> > > additional confidence?
> > > >
> > >
> > > That would be most helpful and reassuring. I will wait for your
> > > testing result before pushing. Thank you!
> > >
> > > Best regards,
> > >
> > > Jiangli
> > > > Cheers
> > > > Christoph
> > > >
> > > > > -----Original Message-----
> > > > > From: hotspot-runtime-dev <hotspot-runtime-dev-
> > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> > > > > Sent: Mittwoch, 22. Januar 2020 02:05
> > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev
> <hotspot-
> > > > > runtime-dev at openjdk.java.net>
> > > > > Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > > > regions usable even if compressed oop encoding has changed
> > > > >
> > > > > I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> > > > > enhancement that improves CDS usability and would improve startup
> > > time
> > > > > if there's an existing default CDS archive (currently does not exist
> > > > > in OpenJDK 11).
> > > > >
> > > > >   webrev: http://cr.openjdk.java.net/~jiangli/8208658-
> > > backport/webrev.00
> > > > >
> > > > > The backport applied to jdk11u-dev mostly clean. The following small
> > > > > set of changes were hand merged to filemap.cpp without additional
> > > > > modifications. The backport was tested with all existing cds and
> > > > > appcds tests, and tier 1 tests.
> > > > >
> > > > > --- filemap.cpp
> > > > > +++ filemap.cpp
> > > > > @@ -967,7 +1069,9 @@
> > > > >      if (base == NULL || base != addr) {
> > > > >        // dealloc the regions from java heap
> > > > >        dealloc_archive_heap_regions(regions, region_num);
> > > > > -      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > > address in java heap.");
> > > > > +      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > > address in java heap. "
> > > > > +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> > > > > +                    p2i(addr), regions[i].byte_size());
> > > > >        return false;
> > > > >      }
> > > > >    }
> > > > > @@ -1216,34 +1348,25 @@
> > > > >           idx == MetaspaceShared::rw ||
> > > > >           idx == MetaspaceShared::mc ||
> > > > >           idx == MetaspaceShared::md, "invalid region index");
> > > > > -  char* base = _header->region_addr(idx);
> > > > > +  char* base = region_addr(idx);
> > > > >    if (p >= base && p < base + space_at(idx)->_used) {
> > > > >      return true;
> > > > >    }
> > > > >    return false;
> > > > >  }
> > > > >
> > > > > -void FileMapInfo::print_shared_spaces() {
> > > > > -  tty->print_cr("Shared Spaces:");
> > > > > -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> > > > > -    CDSFileMapRegion* si = space_at(i);
> > > > > -    char *base = _header->region_addr(i);
> > > > > -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> > > > > -                        shared_region_name[i],
> > > > > -                        p2i(base), p2i(base + si->_used));
> > > > > -  }
> > > > > -}
> > > > > -
> > > > >  // Unmap mapped regions of shared space.
> > > > >  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
> > > > >    FileMapInfo *map_info = FileMapInfo::current_info();
> > > > >    if (map_info) {
> > > > >      map_info->fail_continue("%s", msg);
> > > > >      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> > > > > -      char *addr = map_info->_header->region_addr(i);
> > > > > -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> > > > > -        map_info->unmap_region(i);
> > > > > -        map_info->space_at(i)->_addr._base = NULL;
> > > > > +      if (!MetaspaceShared::is_heap_region(i)) {
> > > > > +        char *addr = map_info->region_addr(i);
> > > > > +        if (addr != NULL) {
> > > > > +          map_info->unmap_region(i);
> > > > > +          map_info->space_at(i)->_addr._base = NULL;
> > > > > +        }
> > > > >
> > > > > Best regards,
> > > > > Jiangli

From jianglizhou at google.com  Tue Jan 28 01:32:05 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Mon, 27 Jan 2020 17:32:05 -0800
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <AM0PR02MB57148B7B523C950B3B953EE78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
 <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>
 <AM0PR02MB57144F5B36E5FBA49A6FC5C78A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jwmt210RpbNX92PJXP+TaEQSeWwwRA4AHfh7LY2Oh=84A@mail.gmail.com>
 <AM0PR02MB57148B7B523C950B3B953EE78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jyN7rM=JAU9qKs4Tqh=L-=7kkPwC7VrmHi30PkLf0qbCg@mail.gmail.com>

Hi Christoph,

On Mon, Jan 27, 2020 at 11:41 AM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Jiangli,
>
> the patch from your second webrev worked well, no regressions spotted. So go ahead with pushing at your convenience.
>

Thanks for confirming!

> I, however, noticed that your patch also doesn't contain metadata (e.g. change description, reviewed-by, etc.). So, Im wondering whether you use the workflow to do a hg export --git -r ... > ... and then hg qimport/hg qpush/hg qrefresh. That should keep the metadata intact and also take care that no files get lost... See here for reference, in case you didn't know: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
>

I didn't know about the process indeed. Thanks a lot for the pointer!
Will include the metadata by following the instructions.

Best regards,
Jiangli

> Best regards
> Christoph
>
> > -----Original Message-----
> > From: Jiangli Zhou <jianglizhou at google.com>
> > Sent: Samstag, 25. Januar 2020 00:35
> > To: Langer, Christoph <christoph.langer at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > runtime-dev at openjdk.java.net>
> > Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > regions usable even if compressed oop encoding has changed
> >
> > Hi Christoph,
> >
> > Oops, forgot to run 'hg add ...' before generating the webrev. The
> > webrev was missing the following two files. Thank you for catching
> > that!
> >
> >   src/hotspot/share/memory/heapShared.inline.hpp
> >   test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java
> >
> > Here is the updated webrev with the missing files included. Could you
> > please try the new patch? Thanks!
> >
> > http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.01/
> >
> > Best regards,
> >
> > Jiangli
> >
> > On Fri, Jan 24, 2020 at 2:33 PM Langer, Christoph
> > <christoph.langer at sap.com> wrote:
> > >
> > > Hi Jiangli,
> > >
> > > unfortunately your patch seems to break every build because the file
> > memory/heapShared.inline.hpp does not exist in 11u. So I think you have to
> > update the patch a bit further...
> > >
> > > Best regards
> > > Christoph
> > >
> > > > -----Original Message-----
> > > > From: Jiangli Zhou <jianglizhou at google.com>
> > > > Sent: Freitag, 24. Januar 2020 16:32
> > > > To: Langer, Christoph <christoph.langer at sap.com>
> > > > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > > > runtime-dev at openjdk.java.net>
> > > > Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > > regions usable even if compressed oop encoding has changed
> > > >
> > > > Hi Christoph,
> > > >
> > > > On Fri, Jan 24, 2020 at 6:33 AM Langer, Christoph
> > > > <christoph.langer at sap.com> wrote:
> > > > >
> > > > > Hi Jiangli,
> > > > >
> > > > > This backport looks good to me.
> > > > >
> > > > > Would you want me to run it through our test infrastructure to get
> > > > additional confidence?
> > > > >
> > > >
> > > > That would be most helpful and reassuring. I will wait for your
> > > > testing result before pushing. Thank you!
> > > >
> > > > Best regards,
> > > >
> > > > Jiangli
> > > > > Cheers
> > > > > Christoph
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: hotspot-runtime-dev <hotspot-runtime-dev-
> > > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> > > > > > Sent: Mittwoch, 22. Januar 2020 02:05
> > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev
> > <hotspot-
> > > > > > runtime-dev at openjdk.java.net>
> > > > > > Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > > > > regions usable even if compressed oop encoding has changed
> > > > > >
> > > > > > I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> > > > > > enhancement that improves CDS usability and would improve startup
> > > > time
> > > > > > if there's an existing default CDS archive (currently does not exist
> > > > > > in OpenJDK 11).
> > > > > >
> > > > > >   webrev: http://cr.openjdk.java.net/~jiangli/8208658-
> > > > backport/webrev.00
> > > > > >
> > > > > > The backport applied to jdk11u-dev mostly clean. The following small
> > > > > > set of changes were hand merged to filemap.cpp without additional
> > > > > > modifications. The backport was tested with all existing cds and
> > > > > > appcds tests, and tier 1 tests.
> > > > > >
> > > > > > --- filemap.cpp
> > > > > > +++ filemap.cpp
> > > > > > @@ -967,7 +1069,9 @@
> > > > > >      if (base == NULL || base != addr) {
> > > > > >        // dealloc the regions from java heap
> > > > > >        dealloc_archive_heap_regions(regions, region_num);
> > > > > > -      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > > > address in java heap.");
> > > > > > +      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > > > address in java heap. "
> > > > > > +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> > > > > > +                    p2i(addr), regions[i].byte_size());
> > > > > >        return false;
> > > > > >      }
> > > > > >    }
> > > > > > @@ -1216,34 +1348,25 @@
> > > > > >           idx == MetaspaceShared::rw ||
> > > > > >           idx == MetaspaceShared::mc ||
> > > > > >           idx == MetaspaceShared::md, "invalid region index");
> > > > > > -  char* base = _header->region_addr(idx);
> > > > > > +  char* base = region_addr(idx);
> > > > > >    if (p >= base && p < base + space_at(idx)->_used) {
> > > > > >      return true;
> > > > > >    }
> > > > > >    return false;
> > > > > >  }
> > > > > >
> > > > > > -void FileMapInfo::print_shared_spaces() {
> > > > > > -  tty->print_cr("Shared Spaces:");
> > > > > > -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> > > > > > -    CDSFileMapRegion* si = space_at(i);
> > > > > > -    char *base = _header->region_addr(i);
> > > > > > -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> > > > > > -                        shared_region_name[i],
> > > > > > -                        p2i(base), p2i(base + si->_used));
> > > > > > -  }
> > > > > > -}
> > > > > > -
> > > > > >  // Unmap mapped regions of shared space.
> > > > > >  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
> > > > > >    FileMapInfo *map_info = FileMapInfo::current_info();
> > > > > >    if (map_info) {
> > > > > >      map_info->fail_continue("%s", msg);
> > > > > >      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> > > > > > -      char *addr = map_info->_header->region_addr(i);
> > > > > > -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> > > > > > -        map_info->unmap_region(i);
> > > > > > -        map_info->space_at(i)->_addr._base = NULL;
> > > > > > +      if (!MetaspaceShared::is_heap_region(i)) {
> > > > > > +        char *addr = map_info->region_addr(i);
> > > > > > +        if (addr != NULL) {
> > > > > > +          map_info->unmap_region(i);
> > > > > > +          map_info->space_at(i)->_addr._base = NULL;
> > > > > > +        }
> > > > > >
> > > > > > Best regards,
> > > > > > Jiangli

From goetz.lindenmaier at sap.com  Tue Jan 28 15:06:11 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 28 Jan 2020 15:06:11 +0000
Subject: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt CDS
 archive
Message-ID: <VE1PR02MB5422565EE4F727ACE1FA3BC1EC0A0@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi

I would like to downport gthis change for parity with 11.0.7-oracle.

I had to do several adaptions of the change to get the code into 11u.

In filemap.cpp jdk13 distinguishes CDS_ARCHIVE_MAGIC and CDS_DYNAMIC_ARCHIVE_MAGIC. Also, 13 checks field _header_size which is not in 11.

I simplified this to check only for CDS_ARCHIVE_MAGIC which is known in 11. I removed the checks for _header_size.

The test too varies a lot between 11 and 13.

Ran it through our testing, and ran the test manually. Both passed.

http://cr.openjdk.java.net/~goetz/wr20/8226406-corrupt_CDS_archive-jdk11/01/

Best regards,
  Goetz

From jianglizhou at google.com  Tue Jan 28 23:20:21 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 28 Jan 2020 15:20:21 -0800
Subject: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt CDS
 archive
In-Reply-To: <VE1PR02MB5422565EE4F727ACE1FA3BC1EC0A0@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422565EE4F727ACE1FA3BC1EC0A0@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jwe3twF17RVWV4ZZeOPZN6ftLewYyHHaLUhVGci60=zJQ@mail.gmail.com>

Hi Goetz,

The backport and modifications in filemap.cpp look good. Would it be
good to also add a comment noting the code below is backported from
JDK 13 and not compatible/needed for 11?

 527   //if (_header->_header_size != sz) {
 528   //  log_info(cds)("_header_size expected: " SIZE_FORMAT, sz);
 529   //  log_info(cds)("               actual: " SIZE_FORMAT,
_header->_header_size);
 530   //  FileMapInfo::fail_continue("The shared archive file has an
incorrect header size.");
 531   //  return false;
 532   // }

I'll also run some tests on my side with your patch applied.

Best regards,

Jiangli

On Tue, Jan 28, 2020 at 7:07 AM Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
>
> Hi
>
> I would like to downport gthis change for parity with 11.0.7-oracle.
>
> I had to do several adaptions of the change to get the code into 11u.
>
> In filemap.cpp jdk13 distinguishes CDS_ARCHIVE_MAGIC and CDS_DYNAMIC_ARCHIVE_MAGIC. Also, 13 checks field _header_size which is not in 11.
>
> I simplified this to check only for CDS_ARCHIVE_MAGIC which is known in 11. I removed the checks for _header_size.
>
> The test too varies a lot between 11 and 13.
>
> Ran it through our testing, and ran the test manually. Both passed.
>
> http://cr.openjdk.java.net/~goetz/wr20/8226406-corrupt_CDS_archive-jdk11/01/
>
> Best regards,
>   Goetz

From gnu.andrew at redhat.com  Wed Jan 29 03:13:56 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 29 Jan 2020 03:13:56 +0000
Subject: [RFR] [11u] 8224851: AArch64: fix warnings and errors with Clang and
 GCC 8.3
Message-ID: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>

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

Backporting this fix helps to get OpenJDK 11 building with GCC 10. With
11.0.6, it fails due to  MacroAssembler::call_VM_leaf_base being
declared twice.

The backport is mostly clean. The only changes were due to an older
copyright header in src/hotspot/cpu/aarch64/frame_aarch64.cpp and the
lack of the simulator conditionals in
src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp, thanks to its
removal in JDK-8228400.

Ok for 11.0.7?

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 Jan 29 05:45:08 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 29 Jan 2020 06:45:08 +0100
Subject: [RFR] [11u] 8224851: AArch64: fix warnings and errors with Clang
 and GCC 8.3
In-Reply-To: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
References: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
Message-ID: <2b9bbca6-a7c5-f1ac-fe68-d165a841a742@redhat.com>

On 1/29/20 4:13 AM, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8224851/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8224851

It is quite a bit odd to see strictfp additions and add_and_fetch modification (which IMO look like
behavioral changes) in the patch that alleges to fix warnings, but that's the question to the
original patch.

Backport looks good.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Wed Jan 29 07:52:41 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 29 Jan 2020 07:52:41 +0000
Subject: [RFR] [11u] 8224851: AArch64: fix warnings and errors with Clang
 and GCC 8.3
In-Reply-To: <2b9bbca6-a7c5-f1ac-fe68-d165a841a742@redhat.com>
References: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
 <2b9bbca6-a7c5-f1ac-fe68-d165a841a742@redhat.com>
Message-ID: <1415f15f-5b41-1c0e-f12d-fdad21922119@redhat.com>



On 29/01/2020 05:45, Aleksey Shipilev wrote:
> On 1/29/20 4:13 AM, Andrew John Hughes wrote:
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8224851/webrev.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224851
> 
> It is quite a bit odd to see strictfp additions and add_and_fetch modification (which IMO look like
> behavioral changes) in the patch that alleges to fix warnings, but that's the question to the
> original patch.
> 
> Backport looks good.
> 

Thanks. I thought the same initially with regard to some of those
changes, but the original thread is quite detailed on why they were needed:

https://mail.openjdk.java.net/pipermail/build-dev/2019-May/025639.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 aph at redhat.com  Wed Jan 29 09:05:10 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 29 Jan 2020 09:05:10 +0000
Subject: [aarch64-port-dev ] [RFR] [11u] 8224851: AArch64: fix warnings
 and errors with Clang and GCC 8.3
In-Reply-To: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
References: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
Message-ID: <a114a582-999e-989b-7d10-e4a264da2f5d@redhat.com>

On 1/29/20 3:13 AM, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8224851/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8224851
> 
> Backporting this fix helps to get OpenJDK 11 building with GCC 10. With
> 11.0.6, it fails due to  MacroAssembler::call_VM_leaf_base being
> declared twice.
> 
> The backport is mostly clean. The only changes were due to an older
> copyright header in src/hotspot/cpu/aarch64/frame_aarch64.cpp and the
> lack of the simulator conditionals in
> src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp, thanks to its
> removal in JDK-8228400.
> 
> Ok for 11.0.7?

Yes, thanks.

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


From rob.mckenna at oracle.com  Wed Jan 29 14:00:57 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 29 Jan 2020 14:00:57 +0000
Subject: Issue with 13.0.2 release (was: [Updates Communication] 13.0.2
 security patches pushed)
In-Reply-To: <AM0PR02MB57142F27C079007D65808D6F8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57142F27C079007D65808D6F8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <20200129140057.GA13559@yoga>

Hi Christoph,

These patches did not make the ga build of OpenJDK 13.0.2, however the
patches were pushed to the repo (post-ga tag) in order to give the
option to downstream builders to include them in their own builds if
they wanted.

Those 13.0.2 records are incorrect however, thanks for pointing that
out. I'll change the fix version to jdk13u.

    -Rob

On 24/01/20 15:21, Langer, Christoph wrote:
> Hi Rob,
> 
> first of all, thanks for pushing the security patches to 13.0.2 and setting the tags.
> 
> I have, however, found a little issue. The tag 13.0.2-ga points to this change: http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/7b8ce94cc932
> 
> If you look at the repository tree, you'll see however that this change is below the merge of this branch and another line in jdk13u which contains the last 6 public pushes:
> 
> 8233223: Add Amazon Root CA certificates8 weeks ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/459a2f735b99 
> 8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong checksum2 months ago, by jiefu - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/b2305a0a3146 
> 8233219: NMT output on AIX misses some categories2 months ago, by mbaesken - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/0919082b7634 
> 8232019: Add LuxTrust certificate updates to the existing root program2 months ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/e69aa0686696 
> 8234107: Several AWT modal dialog tests failing on Linux after JDK-82319912 months ago, by neugens - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/486735e93d55 
> 8231991: Mouse wheel change focus on awt/swing windows - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/743b29c2372f 
> 
> So, these 6 changesets are not contained in 13.0.2-ga!
> 
> Looking at the corresponding JBS items, you'll find resolved backports of these for 13.0.2 and 13u-cpu. I think since we see 13.0.2 here, those should be under the 13.0.2-ga tag.
> 
> For the LuxTrust and Amazon Root CA changes, there have been separate pushes in your internal repository as well which are in 13.0.2-ga. And I believe 8234245 was contained in your internal 8233223 push. So, effectively 13.0.2 OpenJDK is missing these items:
> 8233219: NMT output on AIX misses some categories
> 8234107: Several AWT modal dialog tests failing on Linux after JDK-8231991
> 8231991: Mouse wheel change focus on awt/swing windows
> 
> I don't know whether we should move the 13.0.2-ga tag to the merge commit or just leave it as is, given the importance of JDK13 and the priority of these fixes. But in any case, this shouldn't happen again with 14.0.1 and later...
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Rob McKenna
> > Sent: Donnerstag, 16. Januar 2020 16:18
> > To: Severin Gehwolf <sgehwolf at redhat.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: Re: [Updates Communication] 13.0.2 security patches pushed
> > 
> > Just pushed - apologies for the delay.
> > 
> >     -Rob
> > 
> > On 15/01/20 18:06, Severin Gehwolf wrote:
> > > On Wed, 2020-01-15 at 16:05 +0000, Rob McKenna wrote:
> > > > 13.0.2 patches have been pushed to:
> > > >
> > > > http://hg.openjdk.java.net/jdk-updates/jdk13u/
> > >
> > > Thanks, Rob! Is there going to be a jdk-13.0.2-ga tag?
> > >
> > > Cheers,
> > > Severin
> > >

From rob.mckenna at oracle.com  Wed Jan 29 14:09:49 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 29 Jan 2020 14:09:49 +0000
Subject: Issue with 13.0.2 release (was: [Updates Communication] 13.0.2
 security patches pushed)
In-Reply-To: <20200129140057.GA13559@yoga>
References: <AM0PR02MB57142F27C079007D65808D6F8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <20200129140057.GA13559@yoga>
Message-ID: <20200129140949.GC13559@yoga>

Ah, I see your point here, there was no need to repush these from the
13.0.2 repo. That is correct and shouldn't happen in future.

To be clear: the ga tag is pointing to the correct changeset and should
not change.

    -Rob

On 29/01/20 14:00, Rob McKenna wrote:
> Hi Christoph,
> 
> These patches did not make the ga build of OpenJDK 13.0.2, however the
> patches were pushed to the repo (post-ga tag) in order to give the
> option to downstream builders to include them in their own builds if
> they wanted.
> 
> Those 13.0.2 records are incorrect however, thanks for pointing that
> out. I'll change the fix version to jdk13u.
> 
>     -Rob
> 
> On 24/01/20 15:21, Langer, Christoph wrote:
> > Hi Rob,
> > 
> > first of all, thanks for pushing the security patches to 13.0.2 and setting the tags.
> > 
> > I have, however, found a little issue. The tag 13.0.2-ga points to this change: http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/7b8ce94cc932
> > 
> > If you look at the repository tree, you'll see however that this change is below the merge of this branch and another line in jdk13u which contains the last 6 public pushes:
> > 
> > 8233223: Add Amazon Root CA certificates8 weeks ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/459a2f735b99 
> > 8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong checksum2 months ago, by jiefu - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/b2305a0a3146 
> > 8233219: NMT output on AIX misses some categories2 months ago, by mbaesken - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/0919082b7634 
> > 8232019: Add LuxTrust certificate updates to the existing root program2 months ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/e69aa0686696 
> > 8234107: Several AWT modal dialog tests failing on Linux after JDK-82319912 months ago, by neugens - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/486735e93d55 
> > 8231991: Mouse wheel change focus on awt/swing windows - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/743b29c2372f 
> > 
> > So, these 6 changesets are not contained in 13.0.2-ga!
> > 
> > Looking at the corresponding JBS items, you'll find resolved backports of these for 13.0.2 and 13u-cpu. I think since we see 13.0.2 here, those should be under the 13.0.2-ga tag.
> > 
> > For the LuxTrust and Amazon Root CA changes, there have been separate pushes in your internal repository as well which are in 13.0.2-ga. And I believe 8234245 was contained in your internal 8233223 push. So, effectively 13.0.2 OpenJDK is missing these items:
> > 8233219: NMT output on AIX misses some categories
> > 8234107: Several AWT modal dialog tests failing on Linux after JDK-8231991
> > 8231991: Mouse wheel change focus on awt/swing windows
> > 
> > I don't know whether we should move the 13.0.2-ga tag to the merge commit or just leave it as is, given the importance of JDK13 and the priority of these fixes. But in any case, this shouldn't happen again with 14.0.1 and later...
> > 
> > Best regards
> > Christoph
> > 
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > > Behalf Of Rob McKenna
> > > Sent: Donnerstag, 16. Januar 2020 16:18
> > > To: Severin Gehwolf <sgehwolf at redhat.com>
> > > Cc: jdk-updates-dev at openjdk.java.net
> > > Subject: Re: [Updates Communication] 13.0.2 security patches pushed
> > > 
> > > Just pushed - apologies for the delay.
> > > 
> > >     -Rob
> > > 
> > > On 15/01/20 18:06, Severin Gehwolf wrote:
> > > > On Wed, 2020-01-15 at 16:05 +0000, Rob McKenna wrote:
> > > > > 13.0.2 patches have been pushed to:
> > > > >
> > > > > http://hg.openjdk.java.net/jdk-updates/jdk13u/
> > > >
> > > > Thanks, Rob! Is there going to be a jdk-13.0.2-ga tag?
> > > >
> > > > Cheers,
> > > > Severin
> > > >

From sgehwolf at redhat.com  Wed Jan 29 17:06:38 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 29 Jan 2020 18:06:38 +0100
Subject: [RFR] [11u] 8224851: AArch64: fix warnings and errors with
 Clang and GCC 8.3
In-Reply-To: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
References: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
Message-ID: <0bcf15e6cd15d1f2a5299c1a7545bf768e104ee7.camel@redhat.com>

On Wed, 2020-01-29 at 03:13 +0000, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8224851/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8224851
> 
> Backporting this fix helps to get OpenJDK 11 building with GCC 10. With
> 11.0.6, it fails due to  MacroAssembler::call_VM_leaf_base being
> declared twice.
> 
> The backport is mostly clean. The only changes were due to an older
> copyright header in src/hotspot/cpu/aarch64/frame_aarch64.cpp and the
> lack of the simulator conditionals in
> src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp, thanks to its
> removal in JDK-8228400.

Comparing patches from JDK HEAD and this backport it's as you say. This
looks OK to me, but I'd prefer if some AArch64 compiler folks approved
this too.

Thanks,
Severin


From gnu.andrew at redhat.com  Wed Jan 29 18:01:18 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 29 Jan 2020 18:01:18 +0000
Subject: [aarch64-port-dev ] [RFR] [11u] 8224851: AArch64: fix warnings
 and errors with Clang and GCC 8.3
In-Reply-To: <a114a582-999e-989b-7d10-e4a264da2f5d@redhat.com>
References: <b7c5c038-c0a4-5f27-544d-0ca586175332@redhat.com>
 <a114a582-999e-989b-7d10-e4a264da2f5d@redhat.com>
Message-ID: <af338546-1d6e-d557-3267-6186af9b5359@redhat.com>



On 29/01/2020 09:05, Andrew Haley wrote:
> On 1/29/20 3:13 AM, Andrew John Hughes wrote:
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8224851/webrev.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224851
>>
>> Backporting this fix helps to get OpenJDK 11 building with GCC 10. With
>> 11.0.6, it fails due to  MacroAssembler::call_VM_leaf_base being
>> declared twice.
>>
>> The backport is mostly clean. The only changes were due to an older
>> copyright header in src/hotspot/cpu/aarch64/frame_aarch64.cpp and the
>> lack of the simulator conditionals in
>> src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp, thanks to its
>> removal in JDK-8228400.
>>
>> Ok for 11.0.7?
> 
> Yes, thanks.
> 

Thanks. If you or Christoph could give the bug the necessary
jdk11u-fix-yes, that'd be great.
-- 
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 Jan 29 18:07:41 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 29 Jan 2020 18:07:41 +0000
Subject: Issue with 13.0.2 release (was: [Updates Communication] 13.0.2
 security patches pushed)
In-Reply-To: <20200129140057.GA13559@yoga>
References: <AM0PR02MB57142F27C079007D65808D6F8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <20200129140057.GA13559@yoga>
Message-ID: <9e6362f6-1912-15f7-73c9-888fdfff4b4c@redhat.com>



On 29/01/2020 14:00, Rob McKenna wrote:
> Hi Christoph,
> 
> These patches did not make the ga build of OpenJDK 13.0.2, however the
> patches were pushed to the repo (post-ga tag) in order to give the
> option to downstream builders to include them in their own builds if
> they wanted.
> 
> Those 13.0.2 records are incorrect however, thanks for pointing that
> out. I'll change the fix version to jdk13u.
> 
>     -Rob
> 
> On 24/01/20 15:21, Langer, Christoph wrote:
>> Hi Rob,
>>
>> first of all, thanks for pushing the security patches to 13.0.2 and setting the tags.
>>
>> I have, however, found a little issue. The tag 13.0.2-ga points to this change: http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/7b8ce94cc932
>>
>> If you look at the repository tree, you'll see however that this change is below the merge of this branch and another line in jdk13u which contains the last 6 public pushes:
>>
>> 8233223: Add Amazon Root CA certificates8 weeks ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/459a2f735b99 
>> 8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong checksum2 months ago, by jiefu - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/b2305a0a3146 
>> 8233219: NMT output on AIX misses some categories2 months ago, by mbaesken - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/0919082b7634 
>> 8232019: Add LuxTrust certificate updates to the existing root program2 months ago, by rhalade - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/e69aa0686696 
>> 8234107: Several AWT modal dialog tests failing on Linux after JDK-82319912 months ago, by neugens - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/486735e93d55 
>> 8231991: Mouse wheel change focus on awt/swing windows - http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/743b29c2372f 
>>
>> So, these 6 changesets are not contained in 13.0.2-ga!
>>
>> Looking at the corresponding JBS items, you'll find resolved backports of these for 13.0.2 and 13u-cpu. I think since we see 13.0.2 here, those should be under the 13.0.2-ga tag.
>>
>> For the LuxTrust and Amazon Root CA changes, there have been separate pushes in your internal repository as well which are in 13.0.2-ga. And I believe 8234245 was contained in your internal 8233223 push. So, effectively 13.0.2 OpenJDK is missing these items:
>> 8233219: NMT output on AIX misses some categories
>> 8234107: Several AWT modal dialog tests failing on Linux after JDK-8231991
>> 8231991: Mouse wheel change focus on awt/swing windows
>>
>> I don't know whether we should move the 13.0.2-ga tag to the merge commit or just leave it as is, given the importance of JDK13 and the priority of these fixes. But in any case, this shouldn't happen again with 14.0.1 and later...
>>
>> Best regards
>> Christoph
>>

It sounds like 13.0.2-ga accurately reflects what was released - which
didn't include those fixes - and can't be changed.

Having these additional changesets that have never made a release is
confusing and I agree it should be avoided with future release branches.

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 goetz.lindenmaier at sap.com  Wed Jan 29 18:51:15 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 29 Jan 2020 18:51:15 +0000
Subject: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt CDS
 archive
In-Reply-To: <CALrW1jwe3twF17RVWV4ZZeOPZN6ftLewYyHHaLUhVGci60=zJQ@mail.gmail.com>
References: <VE1PR02MB5422565EE4F727ACE1FA3BC1EC0A0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <CALrW1jwe3twF17RVWV4ZZeOPZN6ftLewYyHHaLUhVGci60=zJQ@mail.gmail.com>
Message-ID: <VE1PR02MB54225AA9CC5CED9DB7F53091EC050@VE1PR02MB5422.eurprd02.prod.outlook.com>

Hi Jiangli,

thanks for your review! I will add a comment. 
I thought better leave this in, in case the other functionality
will be downported one can see this is needed, too.

Best regards,
  Goetz

> -----Original Message-----
> From: Jiangli Zhou <jianglizhou at google.com>
> Sent: Mittwoch, 29. Januar 2020 00:20
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt
> CDS archive
> 
> Hi Goetz,
> 
> The backport and modifications in filemap.cpp look good. Would it be
> good to also add a comment noting the code below is backported from
> JDK 13 and not compatible/needed for 11?
> 
>  527   //if (_header->_header_size != sz) {
>  528   //  log_info(cds)("_header_size expected: " SIZE_FORMAT, sz);
>  529   //  log_info(cds)("               actual: " SIZE_FORMAT,
> _header->_header_size);
>  530   //  FileMapInfo::fail_continue("The shared archive file has an
> incorrect header size.");
>  531   //  return false;
>  532   // }
> 
> I'll also run some tests on my side with your patch applied.
> 
> Best regards,
> 
> Jiangli
> 
> On Tue, Jan 28, 2020 at 7:07 AM Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi
> >
> > I would like to downport gthis change for parity with 11.0.7-oracle.
> >
> > I had to do several adaptions of the change to get the code into 11u.
> >
> > In filemap.cpp jdk13 distinguishes CDS_ARCHIVE_MAGIC and
> CDS_DYNAMIC_ARCHIVE_MAGIC. Also, 13 checks field _header_size which is
> not in 11.
> >
> > I simplified this to check only for CDS_ARCHIVE_MAGIC which is known in 11.
> I removed the checks for _header_size.
> >
> > The test too varies a lot between 11 and 13.
> >
> > Ran it through our testing, and ran the test manually. Both passed.
> >
> > http://cr.openjdk.java.net/~goetz/wr20/8226406-corrupt_CDS_archive-
> jdk11/01/
> >
> > Best regards,
> >   Goetz

From jianglizhou at google.com  Thu Jan 30 18:35:54 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 30 Jan 2020 10:35:54 -0800
Subject: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt CDS
 archive
In-Reply-To: <VE1PR02MB54225AA9CC5CED9DB7F53091EC050@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422565EE4F727ACE1FA3BC1EC0A0@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <CALrW1jwe3twF17RVWV4ZZeOPZN6ftLewYyHHaLUhVGci60=zJQ@mail.gmail.com>
 <VE1PR02MB54225AA9CC5CED9DB7F53091EC050@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jyivrABWTfDKNfSUD0otqHaT0UK0nKj=s8vbLKgmV7rrw@mail.gmail.com>

Hi Goetz,

My testing result looks good.

On Wed, Jan 29, 2020 at 10:51 AM Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
>
> Hi Jiangli,
>
> thanks for your review! I will add a comment.
> I thought better leave this in, in case the other functionality
> will be downported one can see this is needed, too.

SGTM.

Best regards,
Jiangli
>
> Best regards,
>   Goetz
>
> > -----Original Message-----
> > From: Jiangli Zhou <jianglizhou at google.com>
> > Sent: Mittwoch, 29. Januar 2020 00:20
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> > Subject: Re: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt
> > CDS archive
> >
> > Hi Goetz,
> >
> > The backport and modifications in filemap.cpp look good. Would it be
> > good to also add a comment noting the code below is backported from
> > JDK 13 and not compatible/needed for 11?
> >
> >  527   //if (_header->_header_size != sz) {
> >  528   //  log_info(cds)("_header_size expected: " SIZE_FORMAT, sz);
> >  529   //  log_info(cds)("               actual: " SIZE_FORMAT,
> > _header->_header_size);
> >  530   //  FileMapInfo::fail_continue("The shared archive file has an
> > incorrect header size.");
> >  531   //  return false;
> >  532   // }
> >
> > I'll also run some tests on my side with your patch applied.
> >
> > Best regards,
> >
> > Jiangli
> >
> > On Tue, Jan 28, 2020 at 7:07 AM Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com> wrote:
> > >
> > > Hi
> > >
> > > I would like to downport gthis change for parity with 11.0.7-oracle.
> > >
> > > I had to do several adaptions of the change to get the code into 11u.
> > >
> > > In filemap.cpp jdk13 distinguishes CDS_ARCHIVE_MAGIC and
> > CDS_DYNAMIC_ARCHIVE_MAGIC. Also, 13 checks field _header_size which is
> > not in 11.
> > >
> > > I simplified this to check only for CDS_ARCHIVE_MAGIC which is known in 11.
> > I removed the checks for _header_size.
> > >
> > > The test too varies a lot between 11 and 13.
> > >
> > > Ran it through our testing, and ran the test manually. Both passed.
> > >
> > > http://cr.openjdk.java.net/~goetz/wr20/8226406-corrupt_CDS_archive-
> > jdk11/01/
> > >
> > > Best regards,
> > >   Goetz

From jianglizhou at google.com  Thu Jan 30 19:56:42 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 30 Jan 2020 11:56:42 -0800
Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
 regions usable even if compressed oop encoding has changed
In-Reply-To: <CALrW1jyN7rM=JAU9qKs4Tqh=L-=7kkPwC7VrmHi30PkLf0qbCg@mail.gmail.com>
References: <CALrW1jz+YLaQGZxxJiQ6NH0D4seGaugyy4zvUq+u-dosxt10gQ@mail.gmail.com>
 <AM0PR02MB57147F4188DAAEC44C112EF28A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jxi-Af3MAtbrS7hDQTZd7pAQ4wu3Jyki_oimjEMZKEbsA@mail.gmail.com>
 <AM0PR02MB57144F5B36E5FBA49A6FC5C78A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jwmt210RpbNX92PJXP+TaEQSeWwwRA4AHfh7LY2Oh=84A@mail.gmail.com>
 <AM0PR02MB57148B7B523C950B3B953EE78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jyN7rM=JAU9qKs4Tqh=L-=7kkPwC7VrmHi30PkLf0qbCg@mail.gmail.com>
Message-ID: <CALrW1jxYOcdSg3t5CsdEtM7Sj8UME=GPnv1qfoKWdRYHsCcPxA@mail.gmail.com>

Hi Christoph,

I just pushed the backport with proper metadata:
https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-January/001179.html.
Sorry for the delay. My productivity has been affected by a bad cold
in the past few days. Catching up the speed now.

Best regards,
Jiangli

On Mon, Jan 27, 2020 at 5:32 PM Jiangli Zhou <jianglizhou at google.com> wrote:
>
> Hi Christoph,
>
> On Mon, Jan 27, 2020 at 11:41 AM Langer, Christoph
> <christoph.langer at sap.com> wrote:
> >
> > Hi Jiangli,
> >
> > the patch from your second webrev worked well, no regressions spotted. So go ahead with pushing at your convenience.
> >
>
> Thanks for confirming!
>
> > I, however, noticed that your patch also doesn't contain metadata (e.g. change description, reviewed-by, etc.). So, Im wondering whether you use the workflow to do a hg export --git -r ... > ... and then hg qimport/hg qpush/hg qrefresh. That should keep the metadata intact and also take care that no files get lost... See here for reference, in case you didn't know: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
> >
>
> I didn't know about the process indeed. Thanks a lot for the pointer!
> Will include the metadata by following the instructions.
>
> Best regards,
> Jiangli
>
> > Best regards
> > Christoph
> >
> > > -----Original Message-----
> > > From: Jiangli Zhou <jianglizhou at google.com>
> > > Sent: Samstag, 25. Januar 2020 00:35
> > > To: Langer, Christoph <christoph.langer at sap.com>
> > > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > > runtime-dev at openjdk.java.net>
> > > Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > regions usable even if compressed oop encoding has changed
> > >
> > > Hi Christoph,
> > >
> > > Oops, forgot to run 'hg add ...' before generating the webrev. The
> > > webrev was missing the following two files. Thank you for catching
> > > that!
> > >
> > >   src/hotspot/share/memory/heapShared.inline.hpp
> > >   test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java
> > >
> > > Here is the updated webrev with the missing files included. Could you
> > > please try the new patch? Thanks!
> > >
> > > http://cr.openjdk.java.net/~jiangli/8208658-backport/webrev.01/
> > >
> > > Best regards,
> > >
> > > Jiangli
> > >
> > > On Fri, Jan 24, 2020 at 2:33 PM Langer, Christoph
> > > <christoph.langer at sap.com> wrote:
> > > >
> > > > Hi Jiangli,
> > > >
> > > > unfortunately your patch seems to break every build because the file
> > > memory/heapShared.inline.hpp does not exist in 11u. So I think you have to
> > > update the patch a bit further...
> > > >
> > > > Best regards
> > > > Christoph
> > > >
> > > > > -----Original Message-----
> > > > > From: Jiangli Zhou <jianglizhou at google.com>
> > > > > Sent: Freitag, 24. Januar 2020 16:32
> > > > > To: Langer, Christoph <christoph.langer at sap.com>
> > > > > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev <hotspot-
> > > > > runtime-dev at openjdk.java.net>
> > > > > Subject: Re: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > > > regions usable even if compressed oop encoding has changed
> > > > >
> > > > > Hi Christoph,
> > > > >
> > > > > On Fri, Jan 24, 2020 at 6:33 AM Langer, Christoph
> > > > > <christoph.langer at sap.com> wrote:
> > > > > >
> > > > > > Hi Jiangli,
> > > > > >
> > > > > > This backport looks good to me.
> > > > > >
> > > > > > Would you want me to run it through our test infrastructure to get
> > > > > additional confidence?
> > > > > >
> > > > >
> > > > > That would be most helpful and reassuring. I will wait for your
> > > > > testing result before pushing. Thank you!
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jiangli
> > > > > > Cheers
> > > > > > Christoph
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: hotspot-runtime-dev <hotspot-runtime-dev-
> > > > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou
> > > > > > > Sent: Mittwoch, 22. Januar 2020 02:05
> > > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev
> > > <hotspot-
> > > > > > > runtime-dev at openjdk.java.net>
> > > > > > > Subject: [11u] RFR: backport of JDK-8208658: Make CDS archived heap
> > > > > > > regions usable even if compressed oop encoding has changed
> > > > > > >
> > > > > > > I'd like to request a backport of JDK-8208658 to JDK 11u. It was an
> > > > > > > enhancement that improves CDS usability and would improve startup
> > > > > time
> > > > > > > if there's an existing default CDS archive (currently does not exist
> > > > > > > in OpenJDK 11).
> > > > > > >
> > > > > > >   webrev: http://cr.openjdk.java.net/~jiangli/8208658-
> > > > > backport/webrev.00
> > > > > > >
> > > > > > > The backport applied to jdk11u-dev mostly clean. The following small
> > > > > > > set of changes were hand merged to filemap.cpp without additional
> > > > > > > modifications. The backport was tested with all existing cds and
> > > > > > > appcds tests, and tier 1 tests.
> > > > > > >
> > > > > > > --- filemap.cpp
> > > > > > > +++ filemap.cpp
> > > > > > > @@ -967,7 +1069,9 @@
> > > > > > >      if (base == NULL || base != addr) {
> > > > > > >        // dealloc the regions from java heap
> > > > > > >        dealloc_archive_heap_regions(regions, region_num);
> > > > > > > -      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > > > > address in java heap.");
> > > > > > > +      log_info(cds)("UseSharedSpaces: Unable to map at required
> > > > > > > address in java heap. "
> > > > > > > +                    INTPTR_FORMAT ", size = " SIZE_FORMAT " bytes",
> > > > > > > +                    p2i(addr), regions[i].byte_size());
> > > > > > >        return false;
> > > > > > >      }
> > > > > > >    }
> > > > > > > @@ -1216,34 +1348,25 @@
> > > > > > >           idx == MetaspaceShared::rw ||
> > > > > > >           idx == MetaspaceShared::mc ||
> > > > > > >           idx == MetaspaceShared::md, "invalid region index");
> > > > > > > -  char* base = _header->region_addr(idx);
> > > > > > > +  char* base = region_addr(idx);
> > > > > > >    if (p >= base && p < base + space_at(idx)->_used) {
> > > > > > >      return true;
> > > > > > >    }
> > > > > > >    return false;
> > > > > > >  }
> > > > > > >
> > > > > > > -void FileMapInfo::print_shared_spaces() {
> > > > > > > -  tty->print_cr("Shared Spaces:");
> > > > > > > -  for (int i = 0; i < MetaspaceShared::n_regions; i++) {
> > > > > > > -    CDSFileMapRegion* si = space_at(i);
> > > > > > > -    char *base = _header->region_addr(i);
> > > > > > > -    tty->print("  %s " INTPTR_FORMAT "-" INTPTR_FORMAT,
> > > > > > > -                        shared_region_name[i],
> > > > > > > -                        p2i(base), p2i(base + si->_used));
> > > > > > > -  }
> > > > > > > -}
> > > > > > > -
> > > > > > >  // Unmap mapped regions of shared space.
> > > > > > >  void FileMapInfo::stop_sharing_and_unmap(const char* msg) {
> > > > > > >    FileMapInfo *map_info = FileMapInfo::current_info();
> > > > > > >    if (map_info) {
> > > > > > >      map_info->fail_continue("%s", msg);
> > > > > > >      for (int i = 0; i < MetaspaceShared::num_non_heap_spaces; i++) {
> > > > > > > -      char *addr = map_info->_header->region_addr(i);
> > > > > > > -      if (addr != NULL && !MetaspaceShared::is_heap_region(i)) {
> > > > > > > -        map_info->unmap_region(i);
> > > > > > > -        map_info->space_at(i)->_addr._base = NULL;
> > > > > > > +      if (!MetaspaceShared::is_heap_region(i)) {
> > > > > > > +        char *addr = map_info->region_addr(i);
> > > > > > > +        if (addr != NULL) {
> > > > > > > +          map_info->unmap_region(i);
> > > > > > > +          map_info->space_at(i)->_addr._base = NULL;
> > > > > > > +        }
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jiangli

From christoph.langer at sap.com  Mon Jan 27 19:38:06 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 27 Jan 2020 19:38:06 -0000
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <CAPb8aJ575BbbQL1U2cWS_OHMD+kjR+3SQ+8niTY2kfVp8=wf0g@mail.gmail.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
 <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>
 <AM6PR02MB49845530BE014E771BD5EBA88A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ74obrAhnA6TnysKNyYwxUUgh1PBnrPN-x3KUpXobYJZA@mail.gmail.com>
 <AM0PR02MB5714ADAC3148036E5CA3B30E8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CAPb8aJ575BbbQL1U2cWS_OHMD+kjR+3SQ+8niTY2kfVp8=wf0g@mail.gmail.com>
Message-ID: <AM0PR02MB5714946F63B88F2CBC5931218A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jaroslav,

your review mail wasn?t sent to the list. Nevertheless, I guess it?s valid. ??

So, finally, I pushed:
http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2a13c6785ad2
http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/84a2fafde191
http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5fb303a75fb8

Let?s see how it works out.

Best regards
Christoph

From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
Sent: Samstag, 25. Januar 2020 16:00
To: Langer, Christoph <christoph.langer at sap.com>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Hi,

the changes look good and the proposed followup fix backports as well.

LGTM!

Thanks,

-JB-

On Fri, Jan 24, 2020 at 7:51 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav, all,

I?m done with testing your backport patch for JDK-8225797 now.

So, this was your original proposal:
JBS: https://bugs.openjdk.java.net/browse/JDK-8225797
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/caa25ab47aca
Initial backport Webrev: http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/

First of all, to make the debug build work, I had to do a very few modifications (incremental diff to your original backport): http://cr.openjdk.java.net/~clanger/webrevs/8225797.fix-debug-incremental.11u/
It was mainly about the ClassLoaderDataGraph_lock and cld->is_unsafe_anonymous() which don?t exist in jdk11 but were used in assertions. So this would only be noticed in debug builds.

So this is the final webrev with the changes worked in: http://cr.openjdk.java.net/~clanger/webrevs/8225797.11u/

Please review.

When pushing this, we also need to push the fix for https://bugs.openjdk.java.net/browse/JDK-8231025 (Incorrect method tag offset for big endian platform), otherwise we?ll see crashes and test failures in big endian platforms like sun_64 or linuxppc64 and AIX. However, this change applies with minor fuzz, so it should just be tagged with a jdk11u-fix-request label.

I also suggest to backport JDK-8231081 (TestMetadataRetention fails due to missing symbol id) immediately after 8225797 but I?ll send out a separate RFR for this.

Best regards
Christoph


From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>
Sent: Dienstag, 7. Januar 2020 13:26
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Great, thanks for the update. Don't hesitate to contact me if there are any failures. Getting this in is my top priority.

-JB-

On Tue, Jan 7, 2020 at 11:21 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

thanks for the review. I?ve pushed JDK-8209802 which leaves us with the actual JDK-8225797. I?ll try to run it through our build/test system now. As I?ve written a while ago when I initially applied your whole queue, there were errors, even during build on some platforms/configurations. So, I?ll try once again and get back to you when I have results.

Best regards
Christoph


From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>
Sent: Montag, 6. Januar 2020 10:01
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Hi Christoph,

the change looks good and makes sense. Please, go ahead!

-JB-

On Sun, Jan 5, 2020 at 11:50 PM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

looking at 8209802, I?d like to make a small modification to your proposed webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209802.11u/

I think, the changes done in src/hotspot/share/gc/shared/gcTrace.cpp should be guarded by #if INCLUDE_G1GC as the original changes live in a G1 specific file (src/hotspot/share/gc/g1/g1Trace.cpp). Other than that, it matches your original webrev. What do you think?

In case this gets reviewed, I?m ready to push. The patch has passed all our regression testing.

Best regards
Christoph

From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>
Sent: Donnerstag, 2. Januar 2020 14:37
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Great to see this moving fast! Thanks!

On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

done with the next step. JDK-8214850 successfully runs through our test system. I applied it manually and came to the same result as you in your webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So I'll approve and push now and will then apply and test the last prereq change JDK-8209802.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 30. Dezember 2019 09:59
> To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
> Hi Jaroslav,
>
> I just reviewed and tested the backport for JDK-8210024. It mostly applies,
> just one trivial resolve in thread.cpp is necessary. I end up with the same
> patch as in your webrev. Running it through jdk11u-dev build & testing shows
> no problems so I'll approve and push it now and continue with JDK-8214850.
>
> Best regards
> Christoph
>
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> > Behalf Of Jaroslav Bachor?k
> > Sent: Freitag, 15. November 2019 16:46
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event
> > creates unexpected amount of checkpoint data
> >
> > Hi,
> >
> > I would like to get this non-trivial JFR related backport reviewed. This
> > backport is required because OldObjectSample event in the current (JDK
> 11)
> > form will cause unlimited growth of the recording thus making this event
> > unsuitable in production memory leak detection - which is its main
> purpose.
> >
> > The backport for 8225797 requires several other changes to be backported
> as
> > well. I am listing the changes and the related webrevs here in order to
> > have all the pieces in one place. The webrevs, unfortunately, are showing
> > cumulative changes, so please, disregard that information. Each webrev is
> > generated for that particular commit.
> >
> > The following tests were run successfully:
> > - jdk_tier1
> > - jdk_tier2
> > - jdk_jfr
> > - jdk_core
> >
> > ---
> >
> > Prerequisites:
> > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> >
> > # 8209976: Improve iteration over non-JavaThreads
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> >
> > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> >
> > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> >
> > # 8209802: Garbage collectors should register JFR types themselves to
> avoid
> > build errors.
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code locations for g1 sources (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> >
> >
> > Backport:
> > # 8225797: OldObjectSample event creates unexpected amount of
> > checkpoint
> > data
> > - the original patch had to be accommodated to the JDK 11 status of JFR to
> > minimize the number of prerequisite backports and therefore it is slightly
> > more complex (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> >
> >
> > Thanks!
> >
> > -JB-

From christoph.langer at sap.com  Fri Jan 24 12:51:21 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 12:51:21 -0000
Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event
 creates unexpected amount of checkpoint data
In-Reply-To: <CAPb8aJ74obrAhnA6TnysKNyYwxUUgh1PBnrPN-x3KUpXobYJZA@mail.gmail.com>
References: <CAPb8aJ4VdsTpqGWgUFf5A2PgDiOczmK0=nzauV6eOS=chfSFJA@mail.gmail.com>
 <AM6PR02MB49848BEED7C4CB089EF221078A270@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <AM6PR02MB4984C09052401A8E5F513F378A200@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ7HU_6KyRht_-_toyPPUk5sQsrofq5=XN_hiSMFLu5=Sw@mail.gmail.com>
 <AM6PR02MB4984EDBC8F820A3C2BD983D08A3D0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ4jnjMtXg1WdEqXLReo3=KFewf7CWdPtCG1isazL1vBMw@mail.gmail.com>
 <AM6PR02MB49845530BE014E771BD5EBA88A3F0@AM6PR02MB4984.eurprd02.prod.outlook.com>
 <CAPb8aJ74obrAhnA6TnysKNyYwxUUgh1PBnrPN-x3KUpXobYJZA@mail.gmail.com>
Message-ID: <AM0PR02MB5714ADAC3148036E5CA3B30E8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jaroslav, all,

I?m done with testing your backport patch for JDK-8225797 now.

So, this was your original proposal:
JBS: https://bugs.openjdk.java.net/browse/JDK-8225797
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/caa25ab47aca
Initial backport Webrev: http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/

First of all, to make the debug build work, I had to do a very few modifications (incremental diff to your original backport): http://cr.openjdk.java.net/~clanger/webrevs/8225797.fix-debug-incremental.11u/
It was mainly about the ClassLoaderDataGraph_lock and cld->is_unsafe_anonymous() which don?t exist in jdk11 but were used in assertions. So this would only be noticed in debug builds.

So this is the final webrev with the changes worked in: http://cr.openjdk.java.net/~clanger/webrevs/8225797.11u/

Please review.

When pushing this, we also need to push the fix for https://bugs.openjdk.java.net/browse/JDK-8231025 (Incorrect method tag offset for big endian platform), otherwise we?ll see crashes and test failures in big endian platforms like sun_64 or linuxppc64 and AIX. However, this change applies with minor fuzz, so it should just be tagged with a jdk11u-fix-request label.

I also suggest to backport JDK-8231081 (TestMetadataRetention fails due to missing symbol id) immediately after 8225797 but I?ll send out a separate RFR for this.

Best regards
Christoph


From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com>
Sent: Dienstag, 7. Januar 2020 13:26
To: Langer, Christoph <christoph.langer at sap.com>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Great, thanks for the update. Don't hesitate to contact me if there are any failures. Getting this in is my top priority.

-JB-

On Tue, Jan 7, 2020 at 11:21 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

thanks for the review. I?ve pushed JDK-8209802 which leaves us with the actual JDK-8225797. I?ll try to run it through our build/test system now. As I?ve written a while ago when I initially applied your whole queue, there were errors, even during build on some platforms/configurations. So, I?ll try once again and get back to you when I have results.

Best regards
Christoph


From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>
Sent: Montag, 6. Januar 2020 10:01
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Hi Christoph,

the change looks good and makes sense. Please, go ahead!

-JB-

On Sun, Jan 5, 2020 at 11:50 PM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

looking at 8209802, I?d like to make a small modification to your proposed webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209802.11u/

I think, the changes done in src/hotspot/share/gc/shared/gcTrace.cpp should be guarded by #if INCLUDE_G1GC as the original changes live in a G1 specific file (src/hotspot/share/gc/g1/g1Trace.cpp). Other than that, it matches your original webrev. What do you think?

In case this gets reviewed, I?m ready to push. The patch has passed all our regression testing.

Best regards
Christoph

From: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>
Sent: Donnerstag, 2. Januar 2020 14:37
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: Re: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data

Great to see this moving fast! Thanks!

On Thu, Jan 2, 2020 at 10:57 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Jaroslav,

done with the next step. JDK-8214850 successfully runs through our test system. I applied it manually and came to the same result as you in your webrev (http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/) . So I'll approve and push now and will then apply and test the last prereq change JDK-8209802.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 30. Dezember 2019 09:59
> To: Jaroslav Bachor?k <jaroslav.bachorik at datadoghq.com<mailto:jaroslav.bachorik at datadoghq.com>>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Subject: RE: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event creates unexpected amount of checkpoint data
>
> Hi Jaroslav,
>
> I just reviewed and tested the backport for JDK-8210024. It mostly applies,
> just one trivial resolve in thread.cpp is necessary. I end up with the same
> patch as in your webrev. Running it through jdk11u-dev build & testing shows
> no problems so I'll approve and push it now and continue with JDK-8214850.
>
> Best regards
> Christoph
>
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net<mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
> > Behalf Of Jaroslav Bachor?k
> > Sent: Freitag, 15. November 2019 16:46
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample
> event
> > creates unexpected amount of checkpoint data
> >
> > Hi,
> >
> > I would like to get this non-trivial JFR related backport reviewed. This
> > backport is required because OldObjectSample event in the current (JDK
> 11)
> > form will cause unlimited growth of the recording thus making this event
> > unsuitable in production memory leak detection - which is its main
> purpose.
> >
> > The backport for 8225797 requires several other changes to be backported
> as
> > well. I am listing the changes and the related webrevs here in order to
> > have all the pieces in one place. The webrevs, unfortunately, are showing
> > cumulative changes, so please, disregard that information. Each webrev is
> > generated for that particular commit.
> >
> > The following tests were run successfully:
> > - jdk_tier1
> > - jdk_tier2
> > - jdk_jfr
> > - jdk_core
> >
> > ---
> >
> > Prerequisites:
> > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff)
> > JIRA .   : https://bugs.openjdk.java.net/browse/JDK-8209850
> > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/
> >
> > # 8209976: Improve iteration over non-JavaThreads
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/
> > <http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/>
> >
> > # 8210024: JFR calls virtual is_Java_thread from ~Thread()
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/
> >
> > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code structure  (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/
> >
> > # 8209802: Garbage collectors should register JFR types themselves to
> avoid
> > build errors.
> > - applied almost cleanly with only minimal changes to account for slightly
> > different code locations for g1 sources (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/
> >
> >
> > Backport:
> > # 8225797: OldObjectSample event creates unexpected amount of
> > checkpoint
> > data
> > - the original patch had to be accommodated to the JDK 11 status of JFR to
> > minimize the number of prerequisite backports and therefore it is slightly
> > more complex (patch diff -
> > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff)
> > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797
> > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/
> >
> >
> > Thanks!
> >
> > -JB-