From shade at redhat.com  Mon Aug  3 09:20:55 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 3 Aug 2020 11:20:55 +0200
Subject: [11u] RFR 8230870: (zipfs) Add a ZIP FS test that is similar to
 test/jdk/java/util/zip/EntryCount64k.java
In-Reply-To: <CA+kOe08uEaJiMAcRrbjmHRC5qB5z9oLuTb-RUtYBT_bLPjm9Fw@mail.gmail.com>
References: <cea91531-fb77-bc12-b21f-954612fe13fd@redhat.com>
 <CA+kOe08uEaJiMAcRrbjmHRC5qB5z9oLuTb-RUtYBT_bLPjm9Fw@mail.gmail.com>
Message-ID: <f0b0c82f-a6c5-4fd9-e208-0a75c1c1f043@redhat.com>

Thanks, I added the tags.

On 7/31/20 7:27 PM, Martin Buchholz wrote:
> LGTM
> 
> On Fri, Jul 31, 2020 at 4:15 AM Aleksey Shipilev <shade at redhat.com> wrote:
>>
>> Original fix:
>>   https://bugs.openjdk.java.net/browse/JDK-8230870
>>   https://hg.openjdk.java.net/jdk/jdk/rev/6a05019acb67

-- 
-Aleksey


From shade at redhat.com  Mon Aug  3 09:50:05 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 3 Aug 2020 11:50:05 +0200
Subject: [11u] RFR 8212807: tools/jar/multiRelease/Basic.java times out
Message-ID: <c9db4cb8-b489-c4f8-b8e8-d4d1f6cb09a2@redhat.com>

Original fix:
  https://bugs.openjdk.java.net/browse/JDK-8212807
  https://hg.openjdk.java.net/jdk/jdk/rev/d22206f24d59

The patch applies to 11u cleanly, but fails to compile. The hunk that I had to do on my own:

diff -r 96d712b162e6 test/lib/jdk/test/lib/process/OutputAnalyzer.java
--- a/test/lib/jdk/test/lib/process/OutputAnalyzer.java Sun Jun 02 17:13:31 2019 -0400
+++ b/test/lib/jdk/test/lib/process/OutputAnalyzer.java Mon Aug 03 11:45:18 2020 +0200
@@ -79,11 +79,13 @@
      * @param stderr stderr buffer to analyze
      * @param stderr exitValue result to analyze
      */
     public OutputAnalyzer(String stdout, String stderr, int exitValue)
     {
-        buffer = OutputBuffer.of(stdout, stderr, exitValue);
+        this.stdout = stdout;
+        this.stderr = stderr;
+        this.exitValue = exitValue;
     }

OutputBuffer.of is introduced by JDK-8210112, which is too large to backport.

11u webrev:
  https://cr.openjdk.java.net/~shade/8212807/webrev.11u.01/

Testing: jdk/tools/jar/multiRelease/ tests

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Aug  3 10:27:02 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 3 Aug 2020 12:27:02 +0200
Subject: [11u] RFR 8230000: some httpclients testng tests run zero test
Message-ID: <66eeba15-035d-588e-cc4f-8c832d095fc7@redhat.com>

Original fix:
  https://bugs.openjdk.java.net/browse/JDK-8230000
  https://hg.openjdk.java.net/jdk/jdk/rev/ff08db52ad92

The patch applies to 11u with a minor conflict in AbstractThrowingPushPromises.java, which I
resolved by reapplying the hunks by hand.

11u webrev:
  https://cr.openjdk.java.net/~shade/8230000/webrev.11u.01/

Testing: jdk/java/net/httpclient tests

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Mon Aug  3 12:06:16 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 03 Aug 2020 14:06:16 +0200
Subject: [11u] RFR 8212807: tools/jar/multiRelease/Basic.java times out
In-Reply-To: <c9db4cb8-b489-c4f8-b8e8-d4d1f6cb09a2@redhat.com>
References: <c9db4cb8-b489-c4f8-b8e8-d4d1f6cb09a2@redhat.com>
Message-ID: <9f804d3e93df75f4086636d0148756c4348a3c1b.camel@redhat.com>

On Mon, 2020-08-03 at 11:50 +0200, Aleksey Shipilev wrote:
> Original fix:
>   https://bugs.openjdk.java.net/browse/JDK-8212807
>   https://hg.openjdk.java.net/jdk/jdk/rev/d22206f24d59
> 
> The patch applies to 11u cleanly, but fails to compile. The hunk that I had to do on my own:
> 
> diff -r 96d712b162e6 test/lib/jdk/test/lib/process/OutputAnalyzer.java
> --- a/test/lib/jdk/test/lib/process/OutputAnalyzer.java Sun Jun 02 17:13:31 2019 -0400
> +++ b/test/lib/jdk/test/lib/process/OutputAnalyzer.java Mon Aug 03 11:45:18 2020 +0200
> @@ -79,11 +79,13 @@
>       * @param stderr stderr buffer to analyze
>       * @param stderr exitValue result to analyze
>       */
>      public OutputAnalyzer(String stdout, String stderr, int exitValue)
>      {
> -        buffer = OutputBuffer.of(stdout, stderr, exitValue);
> +        this.stdout = stdout;
> +        this.stderr = stderr;
> +        this.exitValue = exitValue;
>      }
> 
> OutputBuffer.of is introduced by JDK-8210112, which is too large to backport.
> 
> 11u webrev:
>   https://cr.openjdk.java.net/~shade/8212807/webrev.11u.01/
> 
> Testing: jdk/tools/jar/multiRelease/ tests

Looks OK to me.

Thanks,
Severin


From shade at redhat.com  Tue Aug  4 06:03:09 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 4 Aug 2020 08:03:09 +0200
Subject: [11u] RFR 8212807: tools/jar/multiRelease/Basic.java times out
In-Reply-To: <9f804d3e93df75f4086636d0148756c4348a3c1b.camel@redhat.com>
References: <c9db4cb8-b489-c4f8-b8e8-d4d1f6cb09a2@redhat.com>
 <9f804d3e93df75f4086636d0148756c4348a3c1b.camel@redhat.com>
Message-ID: <b30b3404-3aa8-b85d-9b96-e090ad7b9645@redhat.com>

On 8/3/20 2:06 PM, Severin Gehwolf wrote:
>> 11u webrev:
>>   https://cr.openjdk.java.net/~shade/8212807/webrev.11u.01/
>>
>> Testing: jdk/tools/jar/multiRelease/ tests
> 
> Looks OK to me.

Thanks, added the flags.

-- 
-Aleksey


From qingfeng.yy at alibaba-inc.com  Tue Aug  4 09:09:20 2020
From: qingfeng.yy at alibaba-inc.com (=?UTF-8?B?5p2o5piTKOmdkumjjik=?=)
Date: Tue, 04 Aug 2020 17:09:20 +0800
Subject: =?UTF-8?B?VVJMQ2xhc3NMb2FkZXIuZmluZFJlc291cmNlcyByZXR1cm5zIGluY29tcGxldGUgZW51bWVy?=
 =?UTF-8?B?YXRpb24gd2hlbiB1c2luZyBKYXJJbmRleA==?=
Message-ID: <cc7ebcb4-59fc-419a-962f-a04df8b34ce3.qingfeng.yy@alibaba-inc.com>

Hi,
  When I use URLClassLoader.findResources to find given resource from many jar files, it works as I expected, but as I generate jar index(jar -i) for jar files, URLClassLoader.findResources will return only ONE resource file even if there exist multi resource files. I can reproduce this scenario by the following script with JDK11~14

```bash
#! /bin/bash
if [ ! -d "bug_ucp" ]; then
  mkdir bug_ucp
fi
cd bug_ucp
echo '
  public class A{
    public A(){}
    void foo(){}
  }
' > A.java
javac A.java
touch res1
touch res2
jar cf A.jar A.class res2
jar cf B.jar A.class res1 res2
jar cf X.jar res1 res2
PREFIX=`pwd`
ajar=$PREFIX/"A.jar"
bjar=$PREFIX/"B.jar"
xjar=$PREFIX/"x.jar"
echo '
import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.Enumeration;
public class FindSameRes {
    private static URL[] urls;
    private static URLClassLoader loader;
    static {
        try {
            urls = new URL[]{
                    new URL("file:'$xjar'"),
                    new URL("file:'$ajar'"),
                    new URL("file:'$bjar'")
                };
            loader = new URLClassLoader(urls);
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
    }
    public static void findMultiResource() {
        try {
            Enumeration<URL> result = loader.findResources("res2");
            while (result.hasMoreElements()){
                System.out.println(result.nextElement());
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    public static void main(String[] args) {
       findMultiResource();
    }
}
' > FindSameRes.java
javac FindSameRes.java
echo 'Find res in jars, without JarIndex'
java FindSameRes
echo 'Find res in jars, with JarIndex'
jar -i $xjar $ajar $bjarjava FindSameRes
```

Is this a bug? 

From suenaga at oss.nttdata.com  Wed Aug  5 02:31:02 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Wed, 5 Aug 2020 11:31:02 +0900
Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which comes
 from Substrate VM
Message-ID: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>

Hi all,

Please approve backport of JDK-8250826:

   JBS: https://bugs.openjdk.java.net/browse/JDK-8250826
   Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2727e4c78f04
   webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250826/jdk11u/webrev.00/

This change affects GraalVM. Please see https://github.com/oracle/graal/issues/2579 for more details.

Original fix changes both SA for Linux and macOS, however this backport request would change only Linux because I confirmed this issue on Linux.
jdk/jdk has been separated common code to ps_core_common.{c,h} between Linux and macOS since JDK-8231986.


Thanks,

Yasumasa

From chris.plummer at oracle.com  Wed Aug  5 20:09:21 2020
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 5 Aug 2020 13:09:21 -0700
Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which comes
 from Substrate VM
In-Reply-To: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
References: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
Message-ID: <8a92bcd8-c03d-e7cf-9a63-18abac0042a6@oracle.com>

LGTM

Chris

On 8/4/20 7:31 PM, Yasumasa Suenaga wrote:
> Hi all,
>
> Please approve backport of JDK-8250826:
>
> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8250826
> ? Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2727e4c78f04
> ? webrev for 11u: 
> http://cr.openjdk.java.net/~ysuenaga/JDK-8250826/jdk11u/webrev.00/
>
> This change affects GraalVM. Please see 
> https://github.com/oracle/graal/issues/2579 for more details.
>
> Original fix changes both SA for Linux and macOS, however this 
> backport request would change only Linux because I confirmed this 
> issue on Linux.
> jdk/jdk has been separated common code to ps_core_common.{c,h} between 
> Linux and macOS since JDK-8231986.
>
>
> Thanks,
>
> Yasumasa



From suenaga at oss.nttdata.com  Thu Aug  6 00:10:04 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Thu, 6 Aug 2020 09:10:04 +0900
Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which comes
 from Substrate VM
In-Reply-To: <8a92bcd8-c03d-e7cf-9a63-18abac0042a6@oracle.com>
References: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
 <8a92bcd8-c03d-e7cf-9a63-18abac0042a6@oracle.com>
Message-ID: <80f24790-2254-3cce-243c-7c5522425b60@oss.nttdata.com>

Thanks Chris!

Yasumasa


On 2020/08/06 5:09, Chris Plummer wrote:
> LGTM
> 
> Chris
> 
> On 8/4/20 7:31 PM, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> Please approve backport of JDK-8250826:
>>
>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8250826
>> ? Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2727e4c78f04
>> ? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250826/jdk11u/webrev.00/
>>
>> This change affects GraalVM. Please see https://github.com/oracle/graal/issues/2579 for more details.
>>
>> Original fix changes both SA for Linux and macOS, however this backport request would change only Linux because I confirmed this issue on Linux.
>> jdk/jdk has been separated common code to ps_core_common.{c,h} between Linux and macOS since JDK-8231986.
>>
>>
>> Thanks,
>>
>> Yasumasa
> 
> 

From sgehwolf at redhat.com  Thu Aug  6 08:01:29 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 06 Aug 2020 10:01:29 +0200
Subject: [11u] RFR 8230000: some httpclients testng tests run zero test
In-Reply-To: <66eeba15-035d-588e-cc4f-8c832d095fc7@redhat.com>
References: <66eeba15-035d-588e-cc4f-8c832d095fc7@redhat.com>
Message-ID: <1e1bc197c0343e09dc3fe1d2f8bd63a8efcfcd5a.camel@redhat.com>

On Mon, 2020-08-03 at 12:27 +0200, Aleksey Shipilev wrote:
> Original fix:
>   https://bugs.openjdk.java.net/browse/JDK-8230000
>   https://hg.openjdk.java.net/jdk/jdk/rev/ff08db52ad92
> 
> The patch applies to 11u with a minor conflict in AbstractThrowingPushPromises.java, which I
> resolved by reapplying the hunks by hand.
> 
> 11u webrev:
>   https://cr.openjdk.java.net/~shade/8230000/webrev.11u.01/
> 
> Testing: jdk/java/net/httpclient tests

Patch seems fine.

Thanks,
Severin


From rs at jelastic.com  Thu Aug  6 17:00:20 2020
From: rs at jelastic.com (Ruslan Synytsky)
Date: Thu, 6 Aug 2020 19:00:20 +0200
Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory
 from G1
Message-ID: <CA++bR4Na-b0pDW+XGLOv7N2UGFYHDipn8BfZJFUCmnU4vCnd6Q@mail.gmail.com>

Hi All, I would like to refresh this topic by sharing a very simple example
that demonstrates why Java looks broken without this improvement.

Jenkins is one of the most popular CI/CD tools. Unfortunately it supports
only Java 8 and Java 11
<https://www.jenkins.io/doc/administration/requirements/java/>. If you
start a simple standalone Jenkins instance and *just sign in* inside the
admin panel then the JVM will start consuming a significant amount of
memory immediately. In my case I had the following limits: container limit
- 8G, heap limit (Xmx) - 6.5G and the memory consumption after the sign in
action got to 3G. By default all Java runtimes lower than Java 12 within
Jelastic are supplied with our Java agent (which is a workaround) that
tracks memory usage and if this agent detects a significant waste it calls
full GC. After this full GC call the memory consumption goes down to 0.5G
(check the screenshot)
<https://raw.githubusercontent.com/siruslan/java-memory-usage/master/images/jenkins-memory-usage-diff.png>.
If we disable our agent then the memory usage at the idle JVM will stay at
3G forever which is a waste of resources
<https://raw.githubusercontent.com/siruslan/java-memory-usage/master/images/jenkins-memory-usage-waste.png>.
If you put additional load on Jenkins the picture will look even worse.

Usually one large host node runs hundreds of containers, and one cloud
cluster may consist of tens, hundreds or thousands of host nodes, so the
issue multiplies. And the case with Jenkins is just one of the examples.
I'm pretty sure this inefficient memory usage issue was damaging the Java
brand for many years and a lot of developers believe that Java is too
heavy. Is not it a strong reason to bring the fix to Java 11?

Thanks
-- 
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS <https://jelastic.com/>

From jspurling at twitter.com  Fri Aug  7 14:00:18 2020
From: jspurling at twitter.com (John Spurling)
Date: Fri, 7 Aug 2020 07:00:18 -0700
Subject: RFR: 8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&)
Message-ID: <CAJqWbWgYeurXk5KxFPhuoGdPD8jOwgWssBkDSQZYcpCYn8FjPA@mail.gmail.com>

Hi,

Please review this backport of JDK-8239497.

Bug: https://bugs.openjdk.java.net/browse/JDK-8239497
Original change: https://hg.openjdk.java.net/jdk/jdk/rev/743c9071c317
Web rev: https://cr.openjdk.java.net/~tonyp/8239497/webrev.0/

As noted in the JIRA issue, we (Twitter) experienced a test failure in
jdk/jfr/startupargs/TestOldObjectQueueSize.java when running Graal. We
have tested this patch in a loop for four days and not experienced a
failure. The patch to 15 did not apply cleanly to 11; this patch is
the one posted by Markus Gr?nlund in JIRA.

Thanks,
john

From adinn at redhat.com  Fri Aug  7 14:54:04 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 7 Aug 2020 15:54:04 +0100
Subject: RFR: 8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&)
In-Reply-To: <CAJqWbWgYeurXk5KxFPhuoGdPD8jOwgWssBkDSQZYcpCYn8FjPA@mail.gmail.com>
References: <CAJqWbWgYeurXk5KxFPhuoGdPD8jOwgWssBkDSQZYcpCYn8FjPA@mail.gmail.com>
Message-ID: <c407454a-8c9b-33d0-6cee-9bdf6de6b4ae@redhat.com>

Hi John,

On 07/08/2020 15:00, John Spurling wrote:
> Please review this backport of JDK-8239497.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8239497
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/743c9071c317
> Web rev: https://cr.openjdk.java.net/~tonyp/8239497/webrev.0/
> 
> As noted in the JIRA issue, we (Twitter) experienced a test failure in
> jdk/jfr/startupargs/TestOldObjectQueueSize.java when running Graal. We
> have tested this patch in a loop for four days and not experienced a
> failure. The patch to 15 did not apply cleanly to 11; this patch is
> the one posted by Markus Gr?nlund in JIRA.
Thanks. The backport patch looks fine.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From jcbeyler at google.com  Fri Aug  7 18:24:54 2020
From: jcbeyler at google.com (Jean Christophe Beyler)
Date: Fri, 7 Aug 2020 14:24:54 -0400
Subject: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
 the heap sampler
In-Reply-To: <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
References: <CAF9BGBxpWxqw2FHejUjNH8o8W0WSKs0c=3=GAPxKb-5rJ9nqKw@mail.gmail.com>
 <CAF9BGBzWFXhA91y02hU=TjezTTMPnuucLj5KjzkV3BrNLOnrEQ@mail.gmail.com>
 <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
Message-ID: <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>

Hi Volker,

Sorry for the delay in my answer!

First off, thanks for the review! I think I need someone to help push this
webrev though and I am not sure if I need a second reviewer. That being
said, here is the request with the empty line removed:

- The original bug is here: https://bugs.openjdk.java.net/browse/JDK-8247615
- The original change is here:
https://hg.openjdk.java.net/jdk/jdk/rev/13ec613f9373
- The webrev with the new change:
http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.03_11/
- The changes are not significant, I had just a few issues due to changes
that came in between to the ThreadHeapSampler class; the test being new is
unchanged

Thanks for all your help, let me know if I need another reviewer or if
someone can help push it for me!

Thanks again,
Jc


On Wed, Jul 29, 2020 at 2:37 PM Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Jc,
>
> the downport looks fine to me except the extra empty line you've
> inserted in threadHeapSampler.hpp:
>
>      _collectors_present = 0;
> +
> +
> +    // Call this after _rnd is initialized to initialize
> _bytes_until_sample.
>
> Thank you and best regards,
> Volker
>
> PS: as a general rule of thumb, a RFR for a downport should include
> the following:
> - a link to the original bug (JBS link)
> - a link to the original change (i.e. a link to the Mercurial change
> set, not to the original webrev)
> - a link to the webrev with the new change
> - if your changes to "original change" are significant an explanation
> why they are required. A diff in webrev format of the "new change"
> against "original change" might be helpful in such a case.
>
> On Wed, Jul 29, 2020 at 8:09 PM Jean Christophe Beyler
> <jcbeyler at google.com> wrote:
> >
> > Hi all,
> >
> > Any chance to get a review on this? Did I perhaps missed something?
> >
> > Thanks again for your help!
> > Jc
> >
> > On Thu, Jul 23, 2020 at 10:43 AM Jean Christophe Beyler <
> jcbeyler at google.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > First time I request a backport so if I am missing anything, please
> let me
> > > know :)
> > >
> > > I am trying to port this webrev into 11u:
> > >
> > > Summary:
> > > This fixes a sampling bias for the first allocations and ensures that
> the
> > > sampling rate is correct from the start.
> > > It is safe to apply as the whole code is protected behind flags and
> only
> > > is used when JVMTI enables the heap monitoring.
> > > We added a test that tickles this code on purpose.
> > >
> > > Porting issues:
> > > Finally, the patch does not apply cleanly due to slight differences
> with
> > > the files. This webrev provides the clean to JDK11u:
> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02_11/
> > >
> > > - That webrev compiles and tests for HeapMonitor (with the new test)
> pass:
> > >     make run-test
> > > TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor"
> > >
> > > compared to what I submitted to head:
> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02/
> > >
> > > Let me know what else I can do or provide!
> > >
> > > Thanks for all your help,
> > > Jc
> > >
> > > Ps: I sent this email before I subscribed so one is waiting in
> moderation;
> > > if this shows up in double, I apologize :)
> > >
> >
> >
> > --
> >
> > Thanks,
> > Jc
>


-- 

Thanks,
Jc

From shade at redhat.com  Mon Aug 10 07:29:19 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 10 Aug 2020 09:29:19 +0200
Subject: [11u] RFR 8230000: some httpclients testng tests run zero test
In-Reply-To: <1e1bc197c0343e09dc3fe1d2f8bd63a8efcfcd5a.camel@redhat.com>
References: <66eeba15-035d-588e-cc4f-8c832d095fc7@redhat.com>
 <1e1bc197c0343e09dc3fe1d2f8bd63a8efcfcd5a.camel@redhat.com>
Message-ID: <21064532-b888-846e-d23b-13c896489e03@redhat.com>

On 8/6/20 10:01 AM, Severin Gehwolf wrote:
> On Mon, 2020-08-03 at 12:27 +0200, Aleksey Shipilev wrote:
>> Original fix:
>>   https://bugs.openjdk.java.net/browse/JDK-8230000
>>   https://hg.openjdk.java.net/jdk/jdk/rev/ff08db52ad92
>>
>> The patch applies to 11u with a minor conflict in AbstractThrowingPushPromises.java, which I
>> resolved by reapplying the hunks by hand.
>>
>> 11u webrev:
>>   https://cr.openjdk.java.net/~shade/8230000/webrev.11u.01/
>>
>> Testing: jdk/java/net/httpclient tests
> 
> Patch seems fine.

Thanks, added tags.

-- 
-Aleksey


From shade at redhat.com  Mon Aug 10 08:17:12 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 10 Aug 2020 10:17:12 +0200
Subject: [11] RFR 8249560: Shenandoah: Fix racy GC request handling
Message-ID: <49242da4-3bf3-3ed7-2780-cca593aaeaf7@redhat.com>

Original fix:
  https://bugs.openjdk.java.net/browse/JDK-8249560
  https://hg.openjdk.java.net/jdk/jdk15/rev/0fbc72a46860

It does not apply cleanly to 11u, because MutexLockerEx is used in the middle of the hunk. I
reapplied it by hand:

diff -r 1584484e8128 src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp       Thu Jul 23 12:46:24 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp       Mon Aug 10 09:37:04 2020 +0200
@@ -505,17 +505,19 @@
   // This is especially important for weak references cleanup and/or native
   // resources (e.g. DirectByteBuffers) machinery: when explicit GC request
   // comes very late in the already running cycle, it would miss lots of new
   // opportunities for cleanup that were made available before the caller
   // requested the GC.
-  size_t required_gc_id = get_gc_id() + 1;

   MonitorLockerEx ml(&_gc_waiters_lock);
-  while (get_gc_id() < required_gc_id) {
+  size_t current_gc_id = get_gc_id();
+  size_t required_gc_id = current_gc_id + 1;
+  while (current_gc_id < required_gc_id) {
     _gc_requested.set();
     _requested_gc_cause = cause;
     ml.wait();
+    current_gc_id = get_gc_id();
   }
 }

 void ShenandoahControlThread::handle_alloc_failure(ShenandoahAllocRequest& req) {
   ShenandoahHeap* heap = ShenandoahHeap::heap();


Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Mon Aug 10 10:31:51 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 10 Aug 2020 12:31:51 +0200
Subject: [11] RFR 8249560: Shenandoah: Fix racy GC request handling
In-Reply-To: <49242da4-3bf3-3ed7-2780-cca593aaeaf7@redhat.com>
References: <49242da4-3bf3-3ed7-2780-cca593aaeaf7@redhat.com>
Message-ID: <a4a10dc4ed97cd1e2c6c4b5a25f6cd6f59b6bddd.camel@redhat.com>

Looks good to me!

Thanks,
Roman

On Mon, 2020-08-10 at 10:17 +0200, Aleksey Shipilev wrote:
> 	Error verifying signature: Cannot verify message signature:
> Incorrect message format
> Original fix:
>   https://bugs.openjdk.java.net/browse/JDK-8249560
>   https://hg.openjdk.java.net/jdk/jdk15/rev/0fbc72a46860
> 
> It does not apply cleanly to 11u, because MutexLockerEx is used in
> the middle of the hunk. I
> reapplied it by hand:
> 
> diff -r 1584484e8128
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
> ---
> a/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp       T
> hu Jul 23 12:46:24 2020 +0200
> +++
> b/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp       M
> on Aug 10 09:37:04 2020 +0200
> @@ -505,17 +505,19 @@
>    // This is especially important for weak references cleanup and/or
> native
>    // resources (e.g. DirectByteBuffers) machinery: when explicit GC
> request
>    // comes very late in the already running cycle, it would miss
> lots of new
>    // opportunities for cleanup that were made available before the
> caller
>    // requested the GC.
> -  size_t required_gc_id = get_gc_id() + 1;
> 
>    MonitorLockerEx ml(&_gc_waiters_lock);
> -  while (get_gc_id() < required_gc_id) {
> +  size_t current_gc_id = get_gc_id();
> +  size_t required_gc_id = current_gc_id + 1;
> +  while (current_gc_id < required_gc_id) {
>      _gc_requested.set();
>      _requested_gc_cause = cause;
>      ml.wait();
> +    current_gc_id = get_gc_id();
>    }
>  }
> 
>  void
> ShenandoahControlThread::handle_alloc_failure(ShenandoahAllocRequest&
> req) {
>    ShenandoahHeap* heap = ShenandoahHeap::heap();
> 
> 
> Testing: hotspot_gc_shenandoah
> 


From christoph.langer at sap.com  Mon Aug 10 12:25:08 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 10 Aug 2020 12:25:08 +0000
Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <4DB5E2A1-2FC5-4C7C-AD35-328CEE9FF790@amazon.com>
References: <4DB5E2A1-2FC5-4C7C-AD35-328CEE9FF790@amazon.com>
Message-ID: <AM4PR02MB31388C0CAF803E52425A3D3F8A440@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

as I'm in parallel working on an 11u backport and have the same requirement for a CSR, I added release 11-pool to the CSR item (JDK-8251270). I think we can have one CSR for both releases. The user-visible change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the same, so I guess it is most convenient.

Hope you're all ok with that? (I'll take no answer as a yes ??)

I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
> Hohensee, Paul
> Sent: Freitag, 7. August 2020 18:15
> To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
> <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>;
> Andrew Hughes <gnu.andrew at redhat.com>
> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain
> names within the default JNDI LDAP provider
> 
> We do, because any behavioral/API change needs one, even to platform
> dependent classes.
> 
> ?On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
> 
>     On 8/7/20 9:55 AM, Hohensee, Paul wrote:
>     > You can backport this to 8u. As Michael Osipov wrote (and Alan as a
> comment on the 8u CSR), you just need to change the 8u CSR and patch to
> move the new functionality to com.sun.jndi.ldap  and com.sun.jndi.ldap.spi.
> 
>     Right. But we don't need CSR for that, correct?
> 
>     Thanks,
> 
>     -Zhengyu
> 
>     >
>     > Thanks,
>     > Paul
>     >
>     > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>     >
>     >      CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender and
> know the content is safe.
>     >
>     >
>     >
>     >      Hi Paul,
>     >
>     >      Based on Alan Bateman's comment, we can not backport public API to
> 8u. I
>     >      guess LdapDnsProvider.java and LdapDnsProviderResult.java have to
> be
>     >      moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages.
>     >
>     >      I will withdraw this CSR, ok?
>     >
>     >      Thanks,
>     >
>     >      -Zhengyu
>     >
>     >
>     >
>     >
>     >
>     >      On 8/6/20 5:32 PM, Hohensee, Paul wrote:
>     >      > I filed a backport issue
>     >      >
>     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
>     >      >
>     >      > and corresponding CSR
>     >      >
>     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
>     >      >
>     >      > and assigned them to Zhengyu.
>     >      >
>     >      > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
> <jdk8u-dev-retn at openjdk.java.net on behalf of hohensee at amazon.com>
> wrote:
>     >      >
>     >      >      +1 on needing a CSR for the backport. I'd missed the CSR link
> because it was buried under "Show 5 more links".
>     >      >
>     >      >      I posted an RFO (Request for Opinion) on the same topic of
> approving strictly additive CSRs for backport.
>     >      >
>     >      >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
> August/012319.html
>     >      >
>     >      >      Thanks,
>     >      >      Paul
>     >      >
>     >      >      On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf"
> <jdk8u-dev-retn at openjdk.java.net on behalf of sgehwolf at redhat.com>
> wrote:
>     >      >
>     >      >          On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
>     >      >          > > The original patch required a CSR[1], so we should file one
> for JDK 8u
>     >      >          > > too. I wonder where the CSR is for Oracle JDK 8, though.
>     >      >          >
>     >      >          > It does not seem to have a CSR for 11u backport(?) Do 8u need
> one?
>     >      >
>     >      >          Right. I don't know about what happened there for Oracle JDK.
> You could
>     >      >          try to ask.
>     >      >
>     >      >          I believe we need one since this is changing the 8 SE API by
> adding:
>     >      >
>     >      >          javax/naming/ldap/spi/LdapDnsProvider.java
>     >      >          javax/naming/ldap/spi/LdapDnsProviderResult.java
>     >      >
>     >      >          Thanks,
>     >      >          Severin
>     >      >
>     >      >
>     >      >
>     >
>     >
> 


From hohensee at amazon.com  Mon Aug 10 14:44:41 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 10 Aug 2020 14:44:41 +0000
Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
Message-ID: <AF35FC42-35E1-484E-A474-145F17D8A655@amazon.com>

I don't think you can have the same CSR for both releases because it messes up the accounting. I.e., there's a backport issues for 8u and another one for 11u, and each of these needs its own CSR. The two CSRs will have identical content in this case. :)

Paul

?On 8/10/20, 5:25 AM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi,

    as I'm in parallel working on an 11u backport and have the same requirement for a CSR, I added release 11-pool to the CSR item (JDK-8251270). I think we can have one CSR for both releases. The user-visible change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the same, so I guess it is most convenient.

    Hope you're all ok with that? (I'll take no answer as a yes ??)

    I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi.

    Best regards
    Christoph

    > -----Original Message-----
    > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
    > Hohensee, Paul
    > Sent: Freitag, 7. August 2020 18:15
    > To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
    > <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>;
    > Andrew Hughes <gnu.andrew at redhat.com>
    > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain
    > names within the default JNDI LDAP provider
    >
    > We do, because any behavioral/API change needs one, even to platform
    > dependent classes.
    >
    > On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
    >
    >     On 8/7/20 9:55 AM, Hohensee, Paul wrote:
    >     > You can backport this to 8u. As Michael Osipov wrote (and Alan as a
    > comment on the 8u CSR), you just need to change the 8u CSR and patch to
    > move the new functionality to com.sun.jndi.ldap  and com.sun.jndi.ldap.spi.
    >
    >     Right. But we don't need CSR for that, correct?
    >
    >     Thanks,
    >
    >     -Zhengyu
    >
    >     >
    >     > Thanks,
    >     > Paul
    >     >
    >     > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
    >     >
    >     >      CAUTION: This email originated from outside of the organization. Do
    > not click links or open attachments unless you can confirm the sender and
    > know the content is safe.
    >     >
    >     >
    >     >
    >     >      Hi Paul,
    >     >
    >     >      Based on Alan Bateman's comment, we can not backport public API to
    > 8u. I
    >     >      guess LdapDnsProvider.java and LdapDnsProviderResult.java have to
    > be
    >     >      moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages.
    >     >
    >     >      I will withdraw this CSR, ok?
    >     >
    >     >      Thanks,
    >     >
    >     >      -Zhengyu
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >      On 8/6/20 5:32 PM, Hohensee, Paul wrote:
    >     >      > I filed a backport issue
    >     >      >
    >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
    >     >      >
    >     >      > and corresponding CSR
    >     >      >
    >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
    >     >      >
    >     >      > and assigned them to Zhengyu.
    >     >      >
    >     >      > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
    > <jdk8u-dev-retn at openjdk.java.net on behalf of hohensee at amazon.com>
    > wrote:
    >     >      >
    >     >      >      +1 on needing a CSR for the backport. I'd missed the CSR link
    > because it was buried under "Show 5 more links".
    >     >      >
    >     >      >      I posted an RFO (Request for Opinion) on the same topic of
    > approving strictly additive CSRs for backport.
    >     >      >
    >     >      >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
    > August/012319.html
    >     >      >
    >     >      >      Thanks,
    >     >      >      Paul
    >     >      >
    >     >      >      On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf"
    > <jdk8u-dev-retn at openjdk.java.net on behalf of sgehwolf at redhat.com>
    > wrote:
    >     >      >
    >     >      >          On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
    >     >      >          > > The original patch required a CSR[1], so we should file one
    > for JDK 8u
    >     >      >          > > too. I wonder where the CSR is for Oracle JDK 8, though.
    >     >      >          >
    >     >      >          > It does not seem to have a CSR for 11u backport(?) Do 8u need
    > one?
    >     >      >
    >     >      >          Right. I don't know about what happened there for Oracle JDK.
    > You could
    >     >      >          try to ask.
    >     >      >
    >     >      >          I believe we need one since this is changing the 8 SE API by
    > adding:
    >     >      >
    >     >      >          javax/naming/ldap/spi/LdapDnsProvider.java
    >     >      >          javax/naming/ldap/spi/LdapDnsProviderResult.java
    >     >      >
    >     >      >          Thanks,
    >     >      >          Severin
    >     >      >
    >     >      >
    >     >      >
    >     >
    >     >
    >



From rkennke at redhat.com  Mon Aug 10 15:28:24 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 10 Aug 2020 17:28:24 +0200
Subject: RFR: 8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java test
 failure
Message-ID: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>

Please review the following issue and fix. This is a 11u-only and
Shenandoah-only bug, but affects shared code.

With the recent Shenandoah backport to jdk11u, we decided to optionally
split metadata.xml so that Shenandoah can provide its own metadata-
shenandoah.xml in a separate file. This avoids generating code for
Shenandoah when Shenandoah is not present in the build.

However, the metadata.xml is also read at run-time, but metadata-
shenandoah.xml is not present at run-time, nor would it be read with
the current implementation of MetadataHandler.java. This makes the test
jdk/jfr/tool/TestPrintJSON.java fail.

I propose to revert the parts of the Shenandoah patch that allows
breaking-up metadata.xml. The downside is that it spills a tiny amount
of (empty) Shenandoah-related code in builds without Shenandoah.
However, it is the exact same thing that also happens for any other GC.
On the positive side, this seems the most conservative approach because
that is what has been tested for a very long time before we integrated
Shenandoah into 11u.

Alternatively, we could further extend the makefile machinery and the
MetadataHandler.java to also (optionally) read metadata-shenandoah.xml
at run-time. It would have the advantage of cleanliness in non-
Shenandoah builds, and the disadvangate of further divergence from
upstream jdk16, and risk of rather untested code, and uncertainty
whether or not this would be the last such issue.

Bug:https://bugs.openjdk.java.net/browse/JDK-8251354
Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8251354/webrev.00/
Testing: build with and without Shenandoah, JFR tests with and without
Shenandoah

What do you think?

Roman


From thomas.stuefe at gmail.com  Mon Aug 10 17:40:59 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 10 Aug 2020 19:40:59 +0200
Subject: RFR: 8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java
 test failure
In-Reply-To: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>
References: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>
Message-ID: <CAA-vtUz5kwXm3Vc+WhMqH03C8GkcxKKWSA6BnXsbcYtHx0jS_w@mail.gmail.com>

Hi Roman,

On Mon, Aug 10, 2020 at 5:28 PM Roman Kennke <rkennke at redhat.com> wrote:

> Please review the following issue and fix. This is a 11u-only and
> Shenandoah-only bug, but affects shared code.
>
> With the recent Shenandoah backport to jdk11u, we decided to optionally
> split metadata.xml so that Shenandoah can provide its own metadata-
> shenandoah.xml in a separate file. This avoids generating code for
> Shenandoah when Shenandoah is not present in the build.
>
> However, the metadata.xml is also read at run-time,


by whom?


> but metadata-
> shenandoah.xml is not present at run-time, nor would it be read with
> the current implementation of MetadataHandler.java. This makes the test
> jdk/jfr/tool/TestPrintJSON.java fail.
>
> I propose to revert the parts of the Shenandoah patch that allows
> breaking-up metadata.xml. The downside is that it spills a tiny amount
> of (empty) Shenandoah-related code in builds without Shenandoah.



> However, it is the exact same thing that also happens for any other GC.

On the positive side, this seems the most conservative approach because
> that is what has been tested for a very long time before we integrated
> Shenandoah into 11u.
>
> Alternatively, we could further extend the makefile machinery and the
> MetadataHandler.java to also (optionally) read metadata-shenandoah.xml
> at run-time. It would have the advantage of cleanliness in non-
> Shenandoah builds, and the disadvangate of further divergence from
> upstream jdk16, and risk of rather untested code, and uncertainty
> whether or not this would be the last such issue.
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8251354
> Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8251354/webrev.00/
> Testing: build with and without Shenandoah, JFR tests with and without
> Shenandoah
>
> What do you think?
>

Had a look at the fix, and it looks reasonable to me. To me this minimal
shenandoah-related tainting of shared code seems acceptable. You guys went
through great lengths keeping out of shared code, I think this is fine.


>
> Roman
>
>
..Thomas

From christoph.langer at sap.com  Mon Aug 10 19:00:13 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 10 Aug 2020 19:00:13 +0000
Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AF35FC42-35E1-484E-A474-145F17D8A655@amazon.com>
References: <AF35FC42-35E1-484E-A474-145F17D8A655@amazon.com>
Message-ID: <AM4PR02MB31388CA980D1AC596A798A4C8A440@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Paul,

well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead...

Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know...

Cheers
Christoph

> -----Original Message-----
> From: Hohensee, Paul <hohensee at amazon.com>
> Sent: Montag, 10. August 2020 16:45
> To: Langer, Christoph <christoph.langer at sap.com>; Zhengyu Gu
> <zgu at redhat.com>; Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-dev
> <jdk8u-dev at openjdk.java.net>; Andrew Hughes
> <gnu.andrew at redhat.com>; jdk-updates-dev at openjdk.java.net
> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain
> names within the default JNDI LDAP provider
> 
> I don't think you can have the same CSR for both releases because it messes
> up the accounting. I.e., there's a backport issues for 8u and another one for
> 11u, and each of these needs its own CSR. The two CSRs will have identical
> content in this case. :)
> 
> Paul
> 
> ?On 8/10/20, 5:25 AM, "Langer, Christoph" <christoph.langer at sap.com>
> wrote:
> 
>     Hi,
> 
>     as I'm in parallel working on an 11u backport and have the same
> requirement for a CSR, I added release 11-pool to the CSR item (JDK-
> 8251270). I think we can have one CSR for both releases. The user-visible
> change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi.
> LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the
> same, so I guess it is most convenient.
> 
>     Hope you're all ok with that? (I'll take no answer as a yes ??)
> 
>     I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead
> of javax.naming.ldap.spi.
> 
>     Best regards
>     Christoph
> 
>     > -----Original Message-----
>     > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
>     > Hohensee, Paul
>     > Sent: Freitag, 7. August 2020 18:15
>     > To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
>     > <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>;
>     > Andrew Hughes <gnu.andrew at redhat.com>
>     > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve
> host/domain
>     > names within the default JNDI LDAP provider
>     >
>     > We do, because any behavioral/API change needs one, even to platform
>     > dependent classes.
>     >
>     > On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>     >
>     >     On 8/7/20 9:55 AM, Hohensee, Paul wrote:
>     >     > You can backport this to 8u. As Michael Osipov wrote (and Alan as a
>     > comment on the 8u CSR), you just need to change the 8u CSR and patch
> to
>     > move the new functionality to com.sun.jndi.ldap  and
> com.sun.jndi.ldap.spi.
>     >
>     >     Right. But we don't need CSR for that, correct?
>     >
>     >     Thanks,
>     >
>     >     -Zhengyu
>     >
>     >     >
>     >     > Thanks,
>     >     > Paul
>     >     >
>     >     > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>     >     >
>     >     >      CAUTION: This email originated from outside of the organization.
> Do
>     > not click links or open attachments unless you can confirm the sender
> and
>     > know the content is safe.
>     >     >
>     >     >
>     >     >
>     >     >      Hi Paul,
>     >     >
>     >     >      Based on Alan Bateman's comment, we can not backport public API
> to
>     > 8u. I
>     >     >      guess LdapDnsProvider.java and LdapDnsProviderResult.java have
> to
>     > be
>     >     >      moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages.
>     >     >
>     >     >      I will withdraw this CSR, ok?
>     >     >
>     >     >      Thanks,
>     >     >
>     >     >      -Zhengyu
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >      On 8/6/20 5:32 PM, Hohensee, Paul wrote:
>     >     >      > I filed a backport issue
>     >     >      >
>     >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
>     >     >      >
>     >     >      > and corresponding CSR
>     >     >      >
>     >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
>     >     >      >
>     >     >      > and assigned them to Zhengyu.
>     >     >      >
>     >     >      > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
>     > <jdk8u-dev-retn at openjdk.java.net on behalf of
> hohensee at amazon.com>
>     > wrote:
>     >     >      >
>     >     >      >      +1 on needing a CSR for the backport. I'd missed the CSR link
>     > because it was buried under "Show 5 more links".
>     >     >      >
>     >     >      >      I posted an RFO (Request for Opinion) on the same topic of
>     > approving strictly additive CSRs for backport.
>     >     >      >
>     >     >      >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
>     > August/012319.html
>     >     >      >
>     >     >      >      Thanks,
>     >     >      >      Paul
>     >     >      >
>     >     >      >      On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf"
>     > <jdk8u-dev-retn at openjdk.java.net on behalf of sgehwolf at redhat.com>
>     > wrote:
>     >     >      >
>     >     >      >          On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
>     >     >      >          > > The original patch required a CSR[1], so we should file
> one
>     > for JDK 8u
>     >     >      >          > > too. I wonder where the CSR is for Oracle JDK 8, though.
>     >     >      >          >
>     >     >      >          > It does not seem to have a CSR for 11u backport(?) Do 8u
> need
>     > one?
>     >     >      >
>     >     >      >          Right. I don't know about what happened there for Oracle
> JDK.
>     > You could
>     >     >      >          try to ask.
>     >     >      >
>     >     >      >          I believe we need one since this is changing the 8 SE API by
>     > adding:
>     >     >      >
>     >     >      >          javax/naming/ldap/spi/LdapDnsProvider.java
>     >     >      >          javax/naming/ldap/spi/LdapDnsProviderResult.java
>     >     >      >
>     >     >      >          Thanks,
>     >     >      >          Severin
>     >     >      >
>     >     >      >
>     >     >      >
>     >     >
>     >     >
>     >
> 


From hohensee at amazon.com  Mon Aug 10 20:31:03 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 10 Aug 2020 20:31:03 +0000
Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
Message-ID: <CF9ED578-9264-4C23-B1C8-AF6D508D28D7@amazon.com>

I've no problem with using the same CSR as long as the language is identical. :)

?On 8/10/20, 12:01 PM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi Paul,

    well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead...

    Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know...

    Cheers
    Christoph

    > -----Original Message-----
    > From: Hohensee, Paul <hohensee at amazon.com>
    > Sent: Montag, 10. August 2020 16:45
    > To: Langer, Christoph <christoph.langer at sap.com>; Zhengyu Gu
    > <zgu at redhat.com>; Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-dev
    > <jdk8u-dev at openjdk.java.net>; Andrew Hughes
    > <gnu.andrew at redhat.com>; jdk-updates-dev at openjdk.java.net
    > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain
    > names within the default JNDI LDAP provider
    >
    > I don't think you can have the same CSR for both releases because it messes
    > up the accounting. I.e., there's a backport issues for 8u and another one for
    > 11u, and each of these needs its own CSR. The two CSRs will have identical
    > content in this case. :)
    >
    > Paul
    >
    > On 8/10/20, 5:25 AM, "Langer, Christoph" <christoph.langer at sap.com>
    > wrote:
    >
    >     Hi,
    >
    >     as I'm in parallel working on an 11u backport and have the same
    > requirement for a CSR, I added release 11-pool to the CSR item (JDK-
    > 8251270). I think we can have one CSR for both releases. The user-visible
    > change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi.
    > LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the
    > same, so I guess it is most convenient.
    >
    >     Hope you're all ok with that? (I'll take no answer as a yes ??)
    >
    >     I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead
    > of javax.naming.ldap.spi.
    >
    >     Best regards
    >     Christoph
    >
    >     > -----Original Message-----
    >     > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
    >     > Hohensee, Paul
    >     > Sent: Freitag, 7. August 2020 18:15
    >     > To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
    >     > <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>;
    >     > Andrew Hughes <gnu.andrew at redhat.com>
    >     > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve
    > host/domain
    >     > names within the default JNDI LDAP provider
    >     >
    >     > We do, because any behavioral/API change needs one, even to platform
    >     > dependent classes.
    >     >
    >     > On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
    >     >
    >     >     On 8/7/20 9:55 AM, Hohensee, Paul wrote:
    >     >     > You can backport this to 8u. As Michael Osipov wrote (and Alan as a
    >     > comment on the 8u CSR), you just need to change the 8u CSR and patch
    > to
    >     > move the new functionality to com.sun.jndi.ldap  and
    > com.sun.jndi.ldap.spi.
    >     >
    >     >     Right. But we don't need CSR for that, correct?
    >     >
    >     >     Thanks,
    >     >
    >     >     -Zhengyu
    >     >
    >     >     >
    >     >     > Thanks,
    >     >     > Paul
    >     >     >
    >     >     > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
    >     >     >
    >     >     >      CAUTION: This email originated from outside of the organization.
    > Do
    >     > not click links or open attachments unless you can confirm the sender
    > and
    >     > know the content is safe.
    >     >     >
    >     >     >
    >     >     >
    >     >     >      Hi Paul,
    >     >     >
    >     >     >      Based on Alan Bateman's comment, we can not backport public API
    > to
    >     > 8u. I
    >     >     >      guess LdapDnsProvider.java and LdapDnsProviderResult.java have
    > to
    >     > be
    >     >     >      moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages.
    >     >     >
    >     >     >      I will withdraw this CSR, ok?
    >     >     >
    >     >     >      Thanks,
    >     >     >
    >     >     >      -Zhengyu
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >      On 8/6/20 5:32 PM, Hohensee, Paul wrote:
    >     >     >      > I filed a backport issue
    >     >     >      >
    >     >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
    >     >     >      >
    >     >     >      > and corresponding CSR
    >     >     >      >
    >     >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
    >     >     >      >
    >     >     >      > and assigned them to Zhengyu.
    >     >     >      >
    >     >     >      > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
    >     > <jdk8u-dev-retn at openjdk.java.net on behalf of
    > hohensee at amazon.com>
    >     > wrote:
    >     >     >      >
    >     >     >      >      +1 on needing a CSR for the backport. I'd missed the CSR link
    >     > because it was buried under "Show 5 more links".
    >     >     >      >
    >     >     >      >      I posted an RFO (Request for Opinion) on the same topic of
    >     > approving strictly additive CSRs for backport.
    >     >     >      >
    >     >     >      >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
    >     > August/012319.html
    >     >     >      >
    >     >     >      >      Thanks,
    >     >     >      >      Paul
    >     >     >      >
    >     >     >      >      On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf"
    >     > <jdk8u-dev-retn at openjdk.java.net on behalf of sgehwolf at redhat.com>
    >     > wrote:
    >     >     >      >
    >     >     >      >          On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
    >     >     >      >          > > The original patch required a CSR[1], so we should file
    > one
    >     > for JDK 8u
    >     >     >      >          > > too. I wonder where the CSR is for Oracle JDK 8, though.
    >     >     >      >          >
    >     >     >      >          > It does not seem to have a CSR for 11u backport(?) Do 8u
    > need
    >     > one?
    >     >     >      >
    >     >     >      >          Right. I don't know about what happened there for Oracle
    > JDK.
    >     > You could
    >     >     >      >          try to ask.
    >     >     >      >
    >     >     >      >          I believe we need one since this is changing the 8 SE API by
    >     > adding:
    >     >     >      >
    >     >     >      >          javax/naming/ldap/spi/LdapDnsProvider.java
    >     >     >      >          javax/naming/ldap/spi/LdapDnsProviderResult.java
    >     >     >      >
    >     >     >      >          Thanks,
    >     >     >      >          Severin
    >     >     >      >
    >     >     >      >
    >     >     >      >
    >     >     >
    >     >     >
    >     >
    >



From joe.darcy at oracle.com  Mon Aug 10 21:22:08 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 10 Aug 2020 14:22:08 -0700
Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AM4PR02MB31388CA980D1AC596A798A4C8A440@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AF35FC42-35E1-484E-A474-145F17D8A655@amazon.com>
 <AM4PR02MB31388CA980D1AC596A798A4C8A440@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <048c8ca1-c9c4-d04b-e657-edd5fb11be41@oracle.com>

Hello,

The practices of CSR and multiple releases have evolved slightly as the 
system has been in use for a few years now.

The CSR FAQ https://wiki.openjdk.java.net/display/csr/CSR+FAQs covers 
some of the conditions as quoted below [1].

In cases where

 ??? 1) the exact same change is being made in multiple release trains

and

 ??? 2) the decision to but the change in multiple releases is being 
made at the same time

then a single CSR can be shared by putting multiple releases (or release 
families) in the fixVesion field.

In this case, it sounds like there are some minor differences so two CSR 
should be filed.

Criteria 2) means that if, say, there is a CSR to put a change in 11u 
and that change is pushed and three months later there is a desire to 
put the change into 8u, a separate CSR would be needed. I treat the CSRs 
as updatable until the underlying bug is pushed to a repo. After that 
point, it should generally not be further modified or reused.

HTH,

-Joe

[1] Q: How should I get CSR review for multiple release trains?
A: Say you want to get an interface change into JDK N and later decide 
the change is also desirable and appropriate for the JDK (N-1) update 
release and that update release is using the CSR process. First a CSR 
should be created from the main bug targeted at JDK N. Afterward, if a 
backport of the main bug covering JDK (N-1) does not already exist, a 
backport of the main bug covering JDK (N-1) should be created. Then, a 
CSR can be created from that backport. The CSR for the backport should 
explicitly state how the interface change for the backport relates to 
the interface change for the main release: either the interface change 
is the same or, if it differs, what the difference is.

On 8/10/2020 12:00 PM, Langer, Christoph wrote:
> Hi Paul,
>
> well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead...
>
> Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know...
>
> Cheers
> Christoph
>
>> -----Original Message-----
>> From: Hohensee, Paul <hohensee at amazon.com>
>> Sent: Montag, 10. August 2020 16:45
>> To: Langer, Christoph <christoph.langer at sap.com>; Zhengyu Gu
>> <zgu at redhat.com>; Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-dev
>> <jdk8u-dev at openjdk.java.net>; Andrew Hughes
>> <gnu.andrew at redhat.com>; jdk-updates-dev at openjdk.java.net
>> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain
>> names within the default JNDI LDAP provider
>>
>> I don't think you can have the same CSR for both releases because it messes
>> up the accounting. I.e., there's a backport issues for 8u and another one for
>> 11u, and each of these needs its own CSR. The two CSRs will have identical
>> content in this case. :)
>>
>> Paul
>>
>> ?On 8/10/20, 5:25 AM, "Langer, Christoph" <christoph.langer at sap.com>
>> wrote:
>>
>>      Hi,
>>
>>      as I'm in parallel working on an 11u backport and have the same
>> requirement for a CSR, I added release 11-pool to the CSR item (JDK-
>> 8251270). I think we can have one CSR for both releases. The user-visible
>> change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi.
>> LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the
>> same, so I guess it is most convenient.
>>
>>      Hope you're all ok with that? (I'll take no answer as a yes ??)
>>
>>      I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead
>> of javax.naming.ldap.spi.
>>
>>      Best regards
>>      Christoph
>>
>>      > -----Original Message-----
>>      > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
>>      > Hohensee, Paul
>>      > Sent: Freitag, 7. August 2020 18:15
>>      > To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
>>      > <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>;
>>      > Andrew Hughes <gnu.andrew at redhat.com>
>>      > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve
>> host/domain
>>      > names within the default JNDI LDAP provider
>>      >
>>      > We do, because any behavioral/API change needs one, even to platform
>>      > dependent classes.
>>      >
>>      > On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>>      >
>>      >     On 8/7/20 9:55 AM, Hohensee, Paul wrote:
>>      >     > You can backport this to 8u. As Michael Osipov wrote (and Alan as a
>>      > comment on the 8u CSR), you just need to change the 8u CSR and patch
>> to
>>      > move the new functionality to com.sun.jndi.ldap  and
>> com.sun.jndi.ldap.spi.
>>      >
>>      >     Right. But we don't need CSR for that, correct?
>>      >
>>      >     Thanks,
>>      >
>>      >     -Zhengyu
>>      >
>>      >     >
>>      >     > Thanks,
>>      >     > Paul
>>      >     >
>>      >     > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>>      >     >
>>      >     >      CAUTION: This email originated from outside of the organization.
>> Do
>>      > not click links or open attachments unless you can confirm the sender
>> and
>>      > know the content is safe.
>>      >     >
>>      >     >
>>      >     >
>>      >     >      Hi Paul,
>>      >     >
>>      >     >      Based on Alan Bateman's comment, we can not backport public API
>> to
>>      > 8u. I
>>      >     >      guess LdapDnsProvider.java and LdapDnsProviderResult.java have
>> to
>>      > be
>>      >     >      moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages.
>>      >     >
>>      >     >      I will withdraw this CSR, ok?
>>      >     >
>>      >     >      Thanks,
>>      >     >
>>      >     >      -Zhengyu
>>      >     >
>>      >     >
>>      >     >
>>      >     >
>>      >     >
>>      >     >      On 8/6/20 5:32 PM, Hohensee, Paul wrote:
>>      >     >      > I filed a backport issue
>>      >     >      >
>>      >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
>>      >     >      >
>>      >     >      > and corresponding CSR
>>      >     >      >
>>      >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
>>      >     >      >
>>      >     >      > and assigned them to Zhengyu.
>>      >     >      >
>>      >     >      > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
>>      > <jdk8u-dev-retn at openjdk.java.net on behalf of
>> hohensee at amazon.com>
>>      > wrote:
>>      >     >      >
>>      >     >      >      +1 on needing a CSR for the backport. I'd missed the CSR link
>>      > because it was buried under "Show 5 more links".
>>      >     >      >
>>      >     >      >      I posted an RFO (Request for Opinion) on the same topic of
>>      > approving strictly additive CSRs for backport.
>>      >     >      >
>>      >     >      >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
>>      > August/012319.html
>>      >     >      >
>>      >     >      >      Thanks,
>>      >     >      >      Paul
>>      >     >      >
>>      >     >      >      On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf"
>>      > <jdk8u-dev-retn at openjdk.java.net on behalf of sgehwolf at redhat.com>
>>      > wrote:
>>      >     >      >
>>      >     >      >          On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
>>      >     >      >          > > The original patch required a CSR[1], so we should file
>> one
>>      > for JDK 8u
>>      >     >      >          > > too. I wonder where the CSR is for Oracle JDK 8, though.
>>      >     >      >          >
>>      >     >      >          > It does not seem to have a CSR for 11u backport(?) Do 8u
>> need
>>      > one?
>>      >     >      >
>>      >     >      >          Right. I don't know about what happened there for Oracle
>> JDK.
>>      > You could
>>      >     >      >          try to ask.
>>      >     >      >
>>      >     >      >          I believe we need one since this is changing the 8 SE API by
>>      > adding:
>>      >     >      >
>>      >     >      >          javax/naming/ldap/spi/LdapDnsProvider.java
>>      >     >      >          javax/naming/ldap/spi/LdapDnsProviderResult.java
>>      >     >      >
>>      >     >      >          Thanks,
>>      >     >      >          Severin
>>      >     >      >
>>      >     >      >
>>      >     >      >
>>      >     >
>>      >     >
>>      >
>>

From christoph.langer at sap.com  Tue Aug 11 05:55:42 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 11 Aug 2020 05:55:42 +0000
Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <048c8ca1-c9c4-d04b-e657-edd5fb11be41@oracle.com>
References: <AF35FC42-35E1-484E-A474-145F17D8A655@amazon.com>
 <AM4PR02MB31388CA980D1AC596A798A4C8A440@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <048c8ca1-c9c4-d04b-e657-edd5fb11be41@oracle.com>
Message-ID: <AM4PR02MB3138B9B2DAAC7FC1C23E8AE88A450@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Joe,

thanks for the clarification.

So for this change I'll file a separate CSR for 11u, due to the implementation differences. But generally sharing CSRs between 8u and 11u would be possible. Good to know.

Cheers
Christoph

> -----Original Message-----
> From: Joe Darcy <joe.darcy at oracle.com>
> Sent: Montag, 10. August 2020 23:22
> To: Langer, Christoph <christoph.langer at sap.com>; Hohensee, Paul
> <hohensee at amazon.com>; Zhengyu Gu <zgu at redhat.com>; Severin
> Gehwolf <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-
> dev at openjdk.java.net>; Andrew Hughes <gnu.andrew at redhat.com>; jdk-
> updates-dev at openjdk.java.net
> Subject: Re: [8u] RFR 8160768: Add capability to custom resolve host/domain
> names within the default JNDI LDAP provider
> 
> Hello,
> 
> The practices of CSR and multiple releases have evolved slightly as the
> system has been in use for a few years now.
> 
> The CSR FAQ https://wiki.openjdk.java.net/display/csr/CSR+FAQs covers
> some of the conditions as quoted below [1].
> 
> In cases where
> 
>  ??? 1) the exact same change is being made in multiple release trains
> 
> and
> 
>  ??? 2) the decision to but the change in multiple releases is being
> made at the same time
> 
> then a single CSR can be shared by putting multiple releases (or release
> families) in the fixVesion field.
> 
> In this case, it sounds like there are some minor differences so two CSR
> should be filed.
> 
> Criteria 2) means that if, say, there is a CSR to put a change in 11u
> and that change is pushed and three months later there is a desire to
> put the change into 8u, a separate CSR would be needed. I treat the CSRs
> as updatable until the underlying bug is pushed to a repo. After that
> point, it should generally not be further modified or reused.
> 
> HTH,
> 
> -Joe
> 
> [1] Q: How should I get CSR review for multiple release trains?
> A: Say you want to get an interface change into JDK N and later decide
> the change is also desirable and appropriate for the JDK (N-1) update
> release and that update release is using the CSR process. First a CSR
> should be created from the main bug targeted at JDK N. Afterward, if a
> backport of the main bug covering JDK (N-1) does not already exist, a
> backport of the main bug covering JDK (N-1) should be created. Then, a
> CSR can be created from that backport. The CSR for the backport should
> explicitly state how the interface change for the backport relates to
> the interface change for the main release: either the interface change
> is the same or, if it differs, what the difference is.
> 
> On 8/10/2020 12:00 PM, Langer, Christoph wrote:
> > Hi Paul,
> >
> > well, I've seen Oracle doing such Multi-Release CSRs. E.g.
> https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for
> clarification. @Joe: Was this an accident or a correct way to use the CSR
> process? Generally I would welcome this as I believe it could reduce some
> process overhead...
> >
> > Nevertheless, in this case, while the backport service implementation
> classes are the same, there are minor differences in the implementation
> (e.g. addition of module jdk.naming.ldap in 11u and different package for
> LdapDnsProviderService) that would speak for two separate CSRs. I don't
> know...
> >
> > Cheers
> > Christoph
> >
> >> -----Original Message-----
> >> From: Hohensee, Paul <hohensee at amazon.com>
> >> Sent: Montag, 10. August 2020 16:45
> >> To: Langer, Christoph <christoph.langer at sap.com>; Zhengyu Gu
> >> <zgu at redhat.com>; Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-
> dev
> >> <jdk8u-dev at openjdk.java.net>; Andrew Hughes
> >> <gnu.andrew at redhat.com>; jdk-updates-dev at openjdk.java.net
> >> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve
> host/domain
> >> names within the default JNDI LDAP provider
> >>
> >> I don't think you can have the same CSR for both releases because it
> messes
> >> up the accounting. I.e., there's a backport issues for 8u and another one
> for
> >> 11u, and each of these needs its own CSR. The two CSRs will have identical
> >> content in this case. :)
> >>
> >> Paul
> >>
> >> ?On 8/10/20, 5:25 AM, "Langer, Christoph" <christoph.langer at sap.com>
> >> wrote:
> >>
> >>      Hi,
> >>
> >>      as I'm in parallel working on an 11u backport and have the same
> >> requirement for a CSR, I added release 11-pool to the CSR item (JDK-
> >> 8251270). I think we can have one CSR for both releases. The user-visible
> >> change that we want to do, that is, the introduction of
> com.sun.jndi.ldap.spi.
> >> LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the
> >> same, so I guess it is most convenient.
> >>
> >>      Hope you're all ok with that? (I'll take no answer as a yes ??)
> >>
> >>      I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi
> instead
> >> of javax.naming.ldap.spi.
> >>
> >>      Best regards
> >>      Christoph
> >>
> >>      > -----Original Message-----
> >>      > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
> >>      > Hohensee, Paul
> >>      > Sent: Freitag, 7. August 2020 18:15
> >>      > To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
> >>      > <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-
> dev at openjdk.java.net>;
> >>      > Andrew Hughes <gnu.andrew at redhat.com>
> >>      > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve
> >> host/domain
> >>      > names within the default JNDI LDAP provider
> >>      >
> >>      > We do, because any behavioral/API change needs one, even to
> platform
> >>      > dependent classes.
> >>      >
> >>      > On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
> >>      >
> >>      >     On 8/7/20 9:55 AM, Hohensee, Paul wrote:
> >>      >     > You can backport this to 8u. As Michael Osipov wrote (and Alan as
> a
> >>      > comment on the 8u CSR), you just need to change the 8u CSR and
> patch
> >> to
> >>      > move the new functionality to com.sun.jndi.ldap  and
> >> com.sun.jndi.ldap.spi.
> >>      >
> >>      >     Right. But we don't need CSR for that, correct?
> >>      >
> >>      >     Thanks,
> >>      >
> >>      >     -Zhengyu
> >>      >
> >>      >     >
> >>      >     > Thanks,
> >>      >     > Paul
> >>      >     >
> >>      >     > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
> >>      >     >
> >>      >     >      CAUTION: This email originated from outside of the
> organization.
> >> Do
> >>      > not click links or open attachments unless you can confirm the sender
> >> and
> >>      > know the content is safe.
> >>      >     >
> >>      >     >
> >>      >     >
> >>      >     >      Hi Paul,
> >>      >     >
> >>      >     >      Based on Alan Bateman's comment, we can not backport public
> API
> >> to
> >>      > 8u. I
> >>      >     >      guess LdapDnsProvider.java and LdapDnsProviderResult.java
> have
> >> to
> >>      > be
> >>      >     >      moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi
> packages.
> >>      >     >
> >>      >     >      I will withdraw this CSR, ok?
> >>      >     >
> >>      >     >      Thanks,
> >>      >     >
> >>      >     >      -Zhengyu
> >>      >     >
> >>      >     >
> >>      >     >
> >>      >     >
> >>      >     >
> >>      >     >      On 8/6/20 5:32 PM, Hohensee, Paul wrote:
> >>      >     >      > I filed a backport issue
> >>      >     >      >
> >>      >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
> >>      >     >      >
> >>      >     >      > and corresponding CSR
> >>      >     >      >
> >>      >     >      > https://bugs.openjdk.java.net/browse/JDK-8251270
> >>      >     >      >
> >>      >     >      > and assigned them to Zhengyu.
> >>      >     >      >
> >>      >     >      > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
> >>      > <jdk8u-dev-retn at openjdk.java.net on behalf of
> >> hohensee at amazon.com>
> >>      > wrote:
> >>      >     >      >
> >>      >     >      >      +1 on needing a CSR for the backport. I'd missed the CSR
> link
> >>      > because it was buried under "Show 5 more links".
> >>      >     >      >
> >>      >     >      >      I posted an RFO (Request for Opinion) on the same topic of
> >>      > approving strictly additive CSRs for backport.
> >>      >     >      >
> >>      >     >      >      https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
> >>      > August/012319.html
> >>      >     >      >
> >>      >     >      >      Thanks,
> >>      >     >      >      Paul
> >>      >     >      >
> >>      >     >      >      On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin
> Gehwolf"
> >>      > <jdk8u-dev-retn at openjdk.java.net on behalf of
> sgehwolf at redhat.com>
> >>      > wrote:
> >>      >     >      >
> >>      >     >      >          On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
> >>      >     >      >          > > The original patch required a CSR[1], so we should file
> >> one
> >>      > for JDK 8u
> >>      >     >      >          > > too. I wonder where the CSR is for Oracle JDK 8,
> though.
> >>      >     >      >          >
> >>      >     >      >          > It does not seem to have a CSR for 11u backport(?) Do
> 8u
> >> need
> >>      > one?
> >>      >     >      >
> >>      >     >      >          Right. I don't know about what happened there for
> Oracle
> >> JDK.
> >>      > You could
> >>      >     >      >          try to ask.
> >>      >     >      >
> >>      >     >      >          I believe we need one since this is changing the 8 SE API
> by
> >>      > adding:
> >>      >     >      >
> >>      >     >      >          javax/naming/ldap/spi/LdapDnsProvider.java
> >>      >     >      >          javax/naming/ldap/spi/LdapDnsProviderResult.java
> >>      >     >      >
> >>      >     >      >          Thanks,
> >>      >     >      >          Severin
> >>      >     >      >
> >>      >     >      >
> >>      >     >      >
> >>      >     >
> >>      >     >
> >>      >
> >>

From yifei.zhang1992 at outlook.com  Tue Aug 11 06:10:13 2020
From: yifei.zhang1992 at outlook.com (Yifei Zhang)
Date: Tue, 11 Aug 2020 06:10:13 +0000
Subject: Handling invokedynamic in jaotc of OpenJDK 11
Message-ID: <F29F5FED-CA6C-41C3-A62F-692C58C5321D@outlook.com>

Dear all,
jaotc in OpenJDK 11 does not handle the invokedynamic bytecode due to the issue [1]. It generates a DeoptimizeNode to fall back to the interpreter, which causes performance degradation.
After looking into the JVMCI Java-side code of OpenJDK 11 and 14, I find that it is possible to turn on invokedynamic in OpenJDK 11 (but 14 still not).

In OpenJDK 14, If the commit [2] is reverted, jaotc complains in [3] when compiling the java.base module, since HotSpotConstantPoolObject introduced in [4] is not a subtype of neither HotSpotObjectConstant nor HotSpotMetaspaceConstant. However, those subtyping relations still hold in OpenJDK 11, so that no error reported when compiling the java.base with OpenJDK 11.

According to this, I was wondering if it is possible to turn on inovkedynamic in OpenJDK 11 so that unnecessary performance penalty caused by deoptimization can be avoided.

Please feel free to give any suggestions.

Cheers,
Yifei

[1] https://bugs.openjdk.java.net/browse/JDK-8223533
[2] http://hg.openjdk.java.net/jdk/jdk/rev/80dd2b549354
[3] https://hg.openjdk.java.net/jdk-updates/jdk14u/file/680a974138a1/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/LoadConstantIndirectlyNode.java#l91
[4] https://hg.openjdk.java.net/jdk-updates/jdk14u/file/680a974138a1/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTDynamicTypeStore.java#l140


From matthias.baesken at sap.com  Tue Aug 11 11:59:24 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 11 Aug 2020 11:59:24 +0000
Subject: RFR [jdk11u-dev]:  8246094: [macos] Sound Recording and playback is
 not working
Message-ID: <AM0PR02MB5412D3F319A73835E5263CB993450@AM0PR02MB5412.eurprd02.prod.outlook.com>


Hi, please review  the jdk11 backport of  8246094 .
In jdk11 the makefile changes go to another file make/launcher/LauncherCommon.gmk  , and need slight adjustments in the makefile .


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8246094_jdk11_0/

jdk15 webrev :
https://hg.openjdk.java.net/jdk/jdk15/rev/d847a98a32cf

Thanks, Matthias

From christoph.langer at sap.com  Tue Aug 11 15:51:55 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 11 Aug 2020 15:51:55 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
Message-ID: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

I've been working on backporting JDK- 8160768: "Add capability to custom resolve host/domain names within the default JNDI LDAP provider" to OpenJDK 11u. This seems to be quite an important enhancement for usage in more complex LDAP setups so there is a certain demand for this backport. Oracle has backported it to their JDK8 and 11 releases already.

Backporting is not so trivial, though, as the original change introduced a new package with two classes in the javax namespace: javax.naming.ldap.spi with classes LdapDnsProvider and LdapDnsProviderResult. To facilitate backporting without having to change the spec, this backport creates package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide the new service interface. So people wanting to leverage the feature in a JDK < 12 will have to build against the com.sun.jndi.ldap.spi implementation. Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from module java.naming as this is not allowed for a module in the java namespace. So I introduced a new module jdk.naming.ldap for being able to export the new service interface. The service is hooked into java.naming's class LdapCtxFactory by reflective lookup of class com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its initialization. This in turn will register the LdapDnsProviderServiceInternal singleton for accessing com.sun.jndi.ldap.spi service implementations from java.naming. If a JDK was jlink'ed without module jdk.naming.ldap, the missing LdapDnsProvider facility would then just be ignored quietly.

In my backport I also include the adaptations to the test from the already backported change of JDK-8139965 to improve test stability.

I had to create a backport CSR as well for which I'd also need a review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/

Thanks in advance for looking at this.

Best regards
Christoph


From hohensee at amazon.com  Tue Aug 11 17:20:29 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 11 Aug 2020 17:20:29 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
Message-ID: <7A93C442-51C1-46F3-95CA-39E3C5FF4179@amazon.com>

Oracle folks, can we get verification that this CSR matches what Oracle has done?

Thanks,
Paul

?On 8/11/20, 8:55 AM, "jdk-updates-dev on behalf of Langer, Christoph" <jdk-updates-dev-retn at openjdk.java.net on behalf of christoph.langer at sap.com> wrote:

    Hi,

    I've been working on backporting JDK- 8160768: "Add capability to custom resolve host/domain names within the default JNDI LDAP provider" to OpenJDK 11u. This seems to be quite an important enhancement for usage in more complex LDAP setups so there is a certain demand for this backport. Oracle has backported it to their JDK8 and 11 releases already.

    Backporting is not so trivial, though, as the original change introduced a new package with two classes in the javax namespace: javax.naming.ldap.spi with classes LdapDnsProvider and LdapDnsProviderResult. To facilitate backporting without having to change the spec, this backport creates package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide the new service interface. So people wanting to leverage the feature in a JDK < 12 will have to build against the com.sun.jndi.ldap.spi implementation. Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from module java.naming as this is not allowed for a module in the java namespace. So I introduced a new module jdk.naming.ldap for being able to export the new service interface. The service is hooked into java.naming's class LdapCtxFactory by reflective lookup of class com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its initialization. This in turn will register the LdapDnsProviderServiceInternal singleton for accessing com.sun.jndi.ldap.spi service implementations from java.naming. If a JDK was jlink'ed without module jdk.naming.ldap, the missing LdapDnsProvider facility would then just be ignored quietly.

    In my backport I also include the adaptations to the test from the already backported change of JDK-8139965 to improve test stability.

    I had to create a backport CSR as well for which I'd also need a review.

    Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
    Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
    Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
    Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
    Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/

    Thanks in advance for looking at this.

    Best regards
    Christoph



From rkennke at redhat.com  Tue Aug 11 19:45:43 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 11 Aug 2020 21:45:43 +0200
Subject: RFR: 8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java
 test failure
In-Reply-To: <CAA-vtUz5kwXm3Vc+WhMqH03C8GkcxKKWSA6BnXsbcYtHx0jS_w@mail.gmail.com>
References: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>
 <CAA-vtUz5kwXm3Vc+WhMqH03C8GkcxKKWSA6BnXsbcYtHx0jS_w@mail.gmail.com>
Message-ID: <c46edc46d5e7812b066e6af5948196f119684135.camel@redhat.com>

On Mon, 2020-08-10 at 19:40 +0200, Thomas St?fe wrote:
> Hi Roman,
> 
> On Mon, Aug 10, 2020 at 5:28 PM Roman Kennke <rkennke at redhat.com>
> wrote:
> > Please review the following issue and fix. This is a 11u-only and
> > Shenandoah-only bug, but affects shared code.
> > 
> > With the recent Shenandoah backport to jdk11u, we decided to
> > optionally
> > split metadata.xml so that Shenandoah can provide its own metadata-
> > shenandoah.xml in a separate file. This avoids generating code for
> > Shenandoah when Shenandoah is not present in the build.
> > 
> > However, the metadata.xml is also read at run-time,
> 
> by whom?
>  

src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataHandler.java
> > but metadata-
> > shenandoah.xml is not present at run-time, nor would it be read
> > with
> > the current implementation of MetadataHandler.java. This makes the
> > test
> > jdk/jfr/tool/TestPrintJSON.java fail.
> > 
> > I propose to revert the parts of the Shenandoah patch that allows
> > breaking-up metadata.xml. The downside is that it spills a tiny
> > amount
> > of (empty) Shenandoah-related code in builds without Shenandoah.
> 
>  
> > However, it is the exact same thing that also happens for any other
> > GC.
> > On the positive side, this seems the most conservative approach
> > because
> > that is what has been tested for a very long time before we
> > integrated
> > Shenandoah into 11u.
> > 
> > Alternatively, we could further extend the makefile machinery and
> > the
> > MetadataHandler.java to also (optionally) read metadata-
> > shenandoah.xml
> > at run-time. It would have the advantage of cleanliness in non-
> > Shenandoah builds, and the disadvangate of further divergence from
> > upstream jdk16, and risk of rather untested code, and uncertainty
> > whether or not this would be the last such issue.
> > 
> > Bug:https://bugs.openjdk.java.net/browse/JDK-8251354
> > Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8251354/webrev.00/
> > Testing: build with and without Shenandoah, JFR tests with and
> > without
> > Shenandoah
> > 
> > What do you think?
> 
> Had a look at the fix, and it looks reasonable to me. To me this
> minimal shenandoah-related tainting of shared code seems acceptable.
> You guys went through great lengths keeping out of shared code, I
> think this is fine.

Ok, thanks for the review.

It is a bit ironic that it was actually all that work to make it
squeaky-clean that caused this regression. ;-)

Thanks,
Roman


From shade at redhat.com  Wed Aug 12 10:24:08 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 12 Aug 2020 12:24:08 +0200
Subject: [11] RFC 8247824: CTW: C2 (Shenandoah) compilation fails with SEGV in
 SBC2Support::pin_and_expand
Message-ID: <31506535-ecd3-cd49-6ade-0a4b65484a2d@redhat.com>

Hi,

We have this bug:
  https://bugs.openjdk.java.net/browse/JDK-8247824
  https://hg.openjdk.java.net/jdk/jdk15/rev/95946afeaad1

...and it reproduces with 11u, so backporting it is in order. The patch applies cleanly to 11u, but
one of the hunks adds new code in loopnode.hpp. My question is: should it be protected by
INCLUDE_SHENANDOAHGC and/or UseShenandoahGC?

-- 
Thanks,
-Aleksey


From hohensee at amazon.com  Wed Aug 12 14:00:27 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 12 Aug 2020 14:00:27 +0000
Subject: [11] RFC 8247824: CTW: C2 (Shenandoah) compilation fails with
 SEGV in SBC2Support::pin_and_expand
Message-ID: <D75D7576-F398-4A36-B72E-2762FBC82AF6@amazon.com>

I'd say no, since while it's only used by Shenandoah right now, it's not specific to Shenandoah, and won't change the Shenandoah/no-Shenandoah binary invariant.

Thanks,
Paul

?On 8/12/20, 3:26 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" <jdk-updates-dev-retn at openjdk.java.net on behalf of shade at redhat.com> wrote:

    Hi,

    We have this bug:
      https://bugs.openjdk.java.net/browse/JDK-8247824
      https://hg.openjdk.java.net/jdk/jdk15/rev/95946afeaad1

    ...and it reproduces with 11u, so backporting it is in order. The patch applies cleanly to 11u, but
    one of the hunks adds new code in loopnode.hpp. My question is: should it be protected by
    INCLUDE_SHENANDOAHGC and/or UseShenandoahGC?

    --
    Thanks,
    -Aleksey



From zgu at redhat.com  Wed Aug 12 18:10:37 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 12 Aug 2020 14:10:37 -0400
Subject: [11u] RFR 8251487: Shenandoah: missing detail timing tracking for
 final mark cleaning phase
Message-ID: <74e0916d-738f-c8b1-001a-17607b0b23f4@redhat.com>

Please review this small enhancement that adds detail timing tracking 
for final mark cleaning phase. The timing information is very useful to 
diagnose latency issues.

The patch is 11u specific, since 11u code structure is quite different 
from jdk/jdk, mainly due to concurrent class unloading in jdk/jdk.
The change is completed isolated in Shenandoah.


Bug: https://bugs.openjdk.java.net/browse/JDK-8251487
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8251487/webrev.00/

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From christoph.langer at sap.com  Thu Aug 13 20:21:33 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 13 Aug 2020 20:21:33 +0000
Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which comes
 from Substrate VM
In-Reply-To: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
References: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
Message-ID: <AM4PR02MB31382EFADD13D260BBEAC6B58A430@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Yasumasa,

I've got one question here: Why do you skip the Mac part in the backport? Does it not affect 11u?

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Yasumasa Suenaga
> Sent: Mittwoch, 5. August 2020 04:31
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which
> comes from Substrate VM
> 
> Hi all,
> 
> Please approve backport of JDK-8250826:
> 
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8250826
>    Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2727e4c78f04
>    webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-
> 8250826/jdk11u/webrev.00/
> 
> This change affects GraalVM. Please see
> https://github.com/oracle/graal/issues/2579 for more details.
> 
> Original fix changes both SA for Linux and macOS, however this backport
> request would change only Linux because I confirmed this issue on Linux.
> jdk/jdk has been separated common code to ps_core_common.{c,h}
> between Linux and macOS since JDK-8231986.
> 
> 
> Thanks,
> 
> Yasumasa

From rkennke at redhat.com  Thu Aug 13 21:24:50 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 13 Aug 2020 23:24:50 +0200
Subject: [11u] RFR 8251487: Shenandoah: missing detail timing tracking
 for final mark cleaning phase
In-Reply-To: <74e0916d-738f-c8b1-001a-17607b0b23f4@redhat.com>
References: <74e0916d-738f-c8b1-001a-17607b0b23f4@redhat.com>
Message-ID: <2625bca69b582ad901afdfb350fb9b134f6ce325.camel@redhat.com>

Hi Zhengyu,

- the order of placement of _phase and its initializer don't match.
Some compilers are not going to like this.
- the indentation of _phase wrt the other fields doesn't match
- Alignment don't match here:

+  ParallelCleaningTask(ShenandoahPhaseTimings::Phase phase,
BoolObjectClosure* is_alive, bool process_strings,
+    bool process_symbols, uint num_workers, bool unloading_occurred);


The rest looks good to me.

Thank you!
Roman

On Wed, 2020-08-12 at 14:10 -0400, Zhengyu Gu wrote:
> Please review this small enhancement that adds detail timing
> tracking 
> for final mark cleaning phase. The timing information is very useful
> to 
> diagnose latency issues.
> 
> The patch is 11u specific, since 11u code structure is quite
> different 
> from jdk/jdk, mainly due to concurrent class unloading in jdk/jdk.
> The change is completed isolated in Shenandoah.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251487
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8251487/webrev.00/
> 
> Test:
>    hotspot_gc_shenandoah
> 
> Thanks,
> 
> -Zhengyu
> 


From suenaga at oss.nttdata.com  Thu Aug 13 23:49:34 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Fri, 14 Aug 2020 08:49:34 +0900
Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which comes
 from Substrate VM
In-Reply-To: <AM4PR02MB31382EFADD13D260BBEAC6B58A430@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
 <AM4PR02MB31382EFADD13D260BBEAC6B58A430@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <5a5fd3da-c9a4-ce21-b50b-783b069ae54b@oss.nttdata.com>

Hi Christoph,

I think this issue will appear on Linux only because Mac does not use ELF.
Upstream change does not affect the behavior on Mac because the change for Mac is just adjust interface change.


Thanks,

Yasumasa


On 2020/08/14 5:21, Langer, Christoph wrote:
> Hi Yasumasa,
> 
> I've got one question here: Why do you skip the Mac part in the backport? Does it not affect 11u?
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
>> Behalf Of Yasumasa Suenaga
>> Sent: Mittwoch, 5. August 2020 04:31
>> To: jdk-updates-dev at openjdk.java.net
>> Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which
>> comes from Substrate VM
>>
>> Hi all,
>>
>> Please approve backport of JDK-8250826:
>>
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8250826
>>     Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2727e4c78f04
>>     webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-
>> 8250826/jdk11u/webrev.00/
>>
>> This change affects GraalVM. Please see
>> https://github.com/oracle/graal/issues/2579 for more details.
>>
>> Original fix changes both SA for Linux and macOS, however this backport
>> request would change only Linux because I confirmed this issue on Linux.
>> jdk/jdk has been separated common code to ps_core_common.{c,h}
>> between Linux and macOS since JDK-8231986.
>>
>>
>> Thanks,
>>
>> Yasumasa

From christoph.langer at sap.com  Fri Aug 14 04:21:07 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Aug 2020 04:21:07 +0000
Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which comes
 from Substrate VM
In-Reply-To: <5a5fd3da-c9a4-ce21-b50b-783b069ae54b@oss.nttdata.com>
References: <cf00d2a1-b545-3a88-fb76-1f99ac79d781@oss.nttdata.com>
 <AM4PR02MB31382EFADD13D260BBEAC6B58A430@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <5a5fd3da-c9a4-ce21-b50b-783b069ae54b@oss.nttdata.com>
Message-ID: <AM4PR02MB31385D66B745A3D3519921548A400@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Yasumasa,

I see. Thanks for the explanation. I've approved it.

Cheers
Christoph

> -----Original Message-----
> From: Yasumasa Suenaga <suenaga at oss.nttdata.com>
> Sent: Freitag, 14. August 2020 01:50
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8250826: jhsdb does not work with coredump which
> comes from Substrate VM
> 
> Hi Christoph,
> 
> I think this issue will appear on Linux only because Mac does not use ELF.
> Upstream change does not affect the behavior on Mac because the change
> for Mac is just adjust interface change.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2020/08/14 5:21, Langer, Christoph wrote:
> > Hi Yasumasa,
> >
> > I've got one question here: Why do you skip the Mac part in the backport?
> Does it not affect 11u?
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> >> Behalf Of Yasumasa Suenaga
> >> Sent: Mittwoch, 5. August 2020 04:31
> >> To: jdk-updates-dev at openjdk.java.net
> >> Subject: [11u] RFR: 8250826: jhsdb does not work with coredump which
> >> comes from Substrate VM
> >>
> >> Hi all,
> >>
> >> Please approve backport of JDK-8250826:
> >>
> >>     JBS: https://bugs.openjdk.java.net/browse/JDK-8250826
> >>     Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2727e4c78f04
> >>     webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-
> >> 8250826/jdk11u/webrev.00/
> >>
> >> This change affects GraalVM. Please see
> >> https://github.com/oracle/graal/issues/2579 for more details.
> >>
> >> Original fix changes both SA for Linux and macOS, however this backport
> >> request would change only Linux because I confirmed this issue on Linux.
> >> jdk/jdk has been separated common code to ps_core_common.{c,h}
> >> between Linux and macOS since JDK-8231986.
> >>
> >>
> >> Thanks,
> >>
> >> Yasumasa

From christoph.langer at sap.com  Fri Aug 14 04:30:57 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Aug 2020 04:30:57 +0000
Subject: RFR: 8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java
 test failure
In-Reply-To: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>
References: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>
Message-ID: <AM4PR02MB31385D7336C47472F75B6ED18A400@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Roman,

I think your proposed change is ok.

While building without Shenandoah, we see an error in test jdk/jfr/event/metadata/TestDefaultConfigurations.java.

This is the log:
java.lang.Exception: Preset 'default' reference unknown event 'jdk.ShenandoahHeapRegionInformation'
Preset 'default' reference unknown event 'jdk.ShenandoahHeapRegionStateChange'
Preset 'profile' reference unknown event 'jdk.ShenandoahHeapRegionInformation'
Preset 'profile' reference unknown event 'jdk.ShenandoahHeapRegionStateChange'

	at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:117)
	at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:78)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:834)

JavaTest Message: Test threw exception: java.lang.Exception: Preset 'default' reference unknown event 'jdk.ShenandoahHeapRegionInformation'
Preset 'default' reference unknown event 'jdk.ShenandoahHeapRegionStateChange'
Preset 'profile' reference unknown event 'jdk.ShenandoahHeapRegionInformation'
Preset 'profile' reference unknown event 'jdk.ShenandoahHeapRegionStateChange'

I guess your change introduces these events for builds with Shenandoah turned off, so I hope this is fixed then, too ??

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Roman Kennke
> Sent: Montag, 10. August 2020 17:28
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: RFR: 8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java test
> failure
> 
> Please review the following issue and fix. This is a 11u-only and
> Shenandoah-only bug, but affects shared code.
> 
> With the recent Shenandoah backport to jdk11u, we decided to optionally
> split metadata.xml so that Shenandoah can provide its own metadata-
> shenandoah.xml in a separate file. This avoids generating code for
> Shenandoah when Shenandoah is not present in the build.
> 
> However, the metadata.xml is also read at run-time, but metadata-
> shenandoah.xml is not present at run-time, nor would it be read with
> the current implementation of MetadataHandler.java. This makes the test
> jdk/jfr/tool/TestPrintJSON.java fail.
> 
> I propose to revert the parts of the Shenandoah patch that allows
> breaking-up metadata.xml. The downside is that it spills a tiny amount
> of (empty) Shenandoah-related code in builds without Shenandoah.
> However, it is the exact same thing that also happens for any other GC.
> On the positive side, this seems the most conservative approach because
> that is what has been tested for a very long time before we integrated
> Shenandoah into 11u.
> 
> Alternatively, we could further extend the makefile machinery and the
> MetadataHandler.java to also (optionally) read metadata-shenandoah.xml
> at run-time. It would have the advantage of cleanliness in non-
> Shenandoah builds, and the disadvangate of further divergence from
> upstream jdk16, and risk of rather untested code, and uncertainty
> whether or not this would be the last such issue.
> 
> Bug:https://bugs.openjdk.java.net/browse/JDK-8251354
> Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8251354/webrev.00/
> Testing: build with and without Shenandoah, JFR tests with and without
> Shenandoah
> 
> What do you think?
> 
> Roman


From matthias.baesken at sap.com  Fri Aug 14 05:37:14 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 14 Aug 2020 05:37:14 +0000
Subject: RFR [jdk11u-dev]: 8246094: [macos] Sound Recording and playback
 is not working
Message-ID: <AM0PR02MB5412281A3E480BE649CEC3B493400@AM0PR02MB5412.eurprd02.prod.outlook.com>

Ping - still   looking for a review .

Thanks, Matthias

From: Baesken, Matthias
Sent: Dienstag, 11. August 2020 13:59
To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
Subject: RFR [jdk11u-dev]: 8246094: [macos] Sound Recording and playback is not working


Hi, please review  the jdk11 backport of  8246094 .
In jdk11 the makefile changes go to another file make/launcher/LauncherCommon.gmk  , and need slight adjustments in the makefile .


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8246094_jdk11_0/

jdk15 webrev :
https://hg.openjdk.java.net/jdk/jdk15/rev/d847a98a32cf

Thanks, Matthias

From christoph.langer at sap.com  Fri Aug 14 06:27:52 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Aug 2020 06:27:52 +0000
Subject: RFR [jdk11u-dev]: 8246094: [macos] Sound Recording and playback
 is not working
In-Reply-To: <AM0PR02MB5412281A3E480BE649CEC3B493400@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB5412281A3E480BE649CEC3B493400@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB31387D5BE6AE3746842AD5178A400@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Matthias,

the backport looks good to me. Thanks for doing it!

Best regards
Christoph

From: Baesken, Matthias <matthias.baesken at sap.com>
Sent: Freitag, 14. August 2020 07:37
To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com>; Doerr, Martin <martin.doerr at sap.com>
Subject: RE: RFR [jdk11u-dev]: 8246094: [macos] Sound Recording and playback is not working

Ping - still   looking for a review .

Thanks, Matthias

From: Baesken, Matthias
Sent: Dienstag, 11. August 2020 13:59
To: 'jdk-updates-dev at openjdk.java.net' <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Subject: RFR [jdk11u-dev]: 8246094: [macos] Sound Recording and playback is not working


Hi, please review  the jdk11 backport of  8246094 .
In jdk11 the makefile changes go to another file make/launcher/LauncherCommon.gmk  , and need slight adjustments in the makefile .


Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8246094_jdk11_0/

jdk15 webrev :
https://hg.openjdk.java.net/jdk/jdk15/rev/d847a98a32cf

Thanks, Matthias

From rkennke at redhat.com  Fri Aug 14 12:00:11 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 14 Aug 2020 14:00:11 +0200
Subject: RFR: 8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java
 test failure
In-Reply-To: <AM4PR02MB31385D7336C47472F75B6ED18A400@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <47be1ef80796a76caa00995244e3702bcec2e0df.camel@redhat.com>
 <AM4PR02MB31385D7336C47472F75B6ED18A400@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <1d0086f712616c1a5bcc883ace896778f9612131.camel@redhat.com>

Hi Christoph,

yes, the big Shenandoah patch caused a several JFR tests to fail
(that's why I changed the bug synopsis), and I verified that this patch
fixes them all. I've run jdk/jfr tests in Shenandoah disabled builds
with no failures, and jdk/jfr tests in Shenandoah enabled builds with
and without Shenandoah, without failures. We should be good.

Thanks for the review!

Cheers,
Roman


On Fri, 2020-08-14 at 04:30 +0000, Langer, Christoph wrote:
> Hi Roman,
> 
> I think your proposed change is ok.
> 
> While building without Shenandoah, we see an error in test
> jdk/jfr/event/metadata/TestDefaultConfigurations.java.
> 
> This is the log:
> java.lang.Exception: Preset 'default' reference unknown event
> 'jdk.ShenandoahHeapRegionInformation'
> Preset 'default' reference unknown event
> 'jdk.ShenandoahHeapRegionStateChange'
> Preset 'profile' reference unknown event
> 'jdk.ShenandoahHeapRegionInformation'
> Preset 'profile' reference unknown event
> 'jdk.ShenandoahHeapRegionStateChange'
> 
> 	at
> jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithEr
> rors(TestDefaultConfigurations.java:117)
> 	at
> jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConf
> igurations.java:78)
> 	at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Nativ
> e Method)
> 	at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Native
> MethodAccessorImpl.java:62)
> 	at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(De
> legatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 	at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper
> .java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:834)
> 
> JavaTest Message: Test threw exception: java.lang.Exception: Preset
> 'default' reference unknown event
> 'jdk.ShenandoahHeapRegionInformation'
> Preset 'default' reference unknown event
> 'jdk.ShenandoahHeapRegionStateChange'
> Preset 'profile' reference unknown event
> 'jdk.ShenandoahHeapRegionInformation'
> Preset 'profile' reference unknown event
> 'jdk.ShenandoahHeapRegionStateChange'
> 
> I guess your change introduces these events for builds with
> Shenandoah turned off, so I hope this is fixed then, too ??
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Roman Kennke
> > Sent: Montag, 10. August 2020 17:28
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: RFR: 8251354: Shenandoah: Fix
> > jdk/jfr/tool/TestPrintJSON.java test
> > failure
> > 
> > Please review the following issue and fix. This is a 11u-only and
> > Shenandoah-only bug, but affects shared code.
> > 
> > With the recent Shenandoah backport to jdk11u, we decided to
> > optionally
> > split metadata.xml so that Shenandoah can provide its own metadata-
> > shenandoah.xml in a separate file. This avoids generating code for
> > Shenandoah when Shenandoah is not present in the build.
> > 
> > However, the metadata.xml is also read at run-time, but metadata-
> > shenandoah.xml is not present at run-time, nor would it be read
> > with
> > the current implementation of MetadataHandler.java. This makes the
> > test
> > jdk/jfr/tool/TestPrintJSON.java fail.
> > 
> > I propose to revert the parts of the Shenandoah patch that allows
> > breaking-up metadata.xml. The downside is that it spills a tiny
> > amount
> > of (empty) Shenandoah-related code in builds without Shenandoah.
> > However, it is the exact same thing that also happens for any other
> > GC.
> > On the positive side, this seems the most conservative approach
> > because
> > that is what has been tested for a very long time before we
> > integrated
> > Shenandoah into 11u.
> > 
> > Alternatively, we could further extend the makefile machinery and
> > the
> > MetadataHandler.java to also (optionally) read metadata-
> > shenandoah.xml
> > at run-time. It would have the advantage of cleanliness in non-
> > Shenandoah builds, and the disadvangate of further divergence from
> > upstream jdk16, and risk of rather untested code, and uncertainty
> > whether or not this would be the last such issue.
> > 
> > Bug:https://bugs.openjdk.java.net/browse/JDK-8251354
> > Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8251354/webrev.00/
> > Testing: build with and without Shenandoah, JFR tests with and
> > without
> > Shenandoah
> > 
> > What do you think?
> > 
> > Roman


From zgu at redhat.com  Mon Aug 17 13:29:57 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 17 Aug 2020 09:29:57 -0400
Subject: [11u] RFR 8251487: Shenandoah: missing detail timing tracking for
 final mark cleaning phase
In-Reply-To: <2625bca69b582ad901afdfb350fb9b134f6ce325.camel@redhat.com>
References: <74e0916d-738f-c8b1-001a-17607b0b23f4@redhat.com>
 <2625bca69b582ad901afdfb350fb9b134f6ce325.camel@redhat.com>
Message-ID: <f3570156-a673-d26b-8d28-3ab3af662d47@redhat.com>



On 8/13/20 5:24 PM, Roman Kennke wrote:
> Hi Zhengyu,
> 
> - the order of placement of _phase and its initializer don't match.
> Some compilers are not going to like this.
> - the indentation of _phase wrt the other fields doesn't match
> - Alignment don't match here:
> 
> +  ParallelCleaningTask(ShenandoahPhaseTimings::Phase phase,
> BoolObjectClosure* is_alive, bool process_strings,
> +    bool process_symbols, uint num_workers, bool unloading_occurred);

Updated: http://cr.openjdk.java.net/~zgu/JDK-8251487/webrev.01/index.html

Okay now?

Thanks,

-Zhengyu

> 
> 
> The rest looks good to me.
> 
> Thank you!
> Roman
> 
> On Wed, 2020-08-12 at 14:10 -0400, Zhengyu Gu wrote:
>> Please review this small enhancement that adds detail timing
>> tracking
>> for final mark cleaning phase. The timing information is very useful
>> to
>> diagnose latency issues.
>>
>> The patch is 11u specific, since 11u code structure is quite
>> different
>> from jdk/jdk, mainly due to concurrent class unloading in jdk/jdk.
>> The change is completed isolated in Shenandoah.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251487
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8251487/webrev.00/
>>
>> Test:
>>     hotspot_gc_shenandoah
>>
>> Thanks,
>>
>> -Zhengyu
>>
> 


From martin.doerr at sap.com  Mon Aug 17 21:54:32 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 17 Aug 2020 21:54:32 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
Message-ID: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

I'd like to backport https://bugs.openjdk.java.net/browse/JDK-8241234 to JDK11u.

Original JDK15 patch (https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63) doesn't fit to JDK11u because the locking code has been reworked by https://bugs.openjdk.java.net/browse/JDK-8229844
As mentioned by Vladimir, there's already a GraalVM version available which consists of 2 patches (original + addon) and which can be applied:
https://github.com/graalvm/labs-openjdk-11/commit/6c162cb15262e6aa77e36eb3a268320ef0a206a4
https://github.com/graalvm/labs-openjdk-11/commit/6a28a618cdbe595f9a3993e0eb63c01ccae1a528
Only JVMCI part from GraalVM doesn't apply automatically. The version of this file from JDK15 is very simple and fits perfectly.

Please review the JDK11u backport webrev:
http://cr.openjdk.java.net/~mdoerr/8241234_monitorenterexit_11u/webrev.00/

Thanks and best regards,
Martin


From shade at redhat.com  Tue Aug 18 10:12:01 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 12:12:01 +0200
Subject: [11u] RFR (S) 8251451: Shenandoah: Remark ObjectSynchronizer roots
 with I-U
Message-ID: <25550ae9-f314-e95f-3750-d57c5dfb5428@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8251451
   https://cr.openjdk.java.net/~shade/8251451/webrev.11u.01/

The patch does apply cleanly to 11u, because the usual MutexLockerEx -> MutexLocker change, 
ShenandoahTaskTerminator -> TaskTerminator rename, indenting differences. Reapplied the hunks by hand.

11u webrev:
   https://cr.openjdk.java.net/~shade/8251451/webrev.11u.01/

Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Aug 18 10:22:58 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 12:22:58 +0200
Subject: [11u] RFR (S) 8245880: Shenandoah: check class unloading flag early
 in concurrent code root scan
Message-ID: <d941b341-62b3-d19b-c90a-f448b8f515eb@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8245880
   https://hg.openjdk.java.net/jdk/jdk/rev/3a8634555a01

The patch does apply cleanly to 11u, because the usual MutexLockerEx -> MutexLocker change. 
Reapplied the hunk by hand.

11u webrev:
   https://cr.openjdk.java.net/~shade/8245880/webrev.11u.01/

Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Tue Aug 18 10:29:31 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 18 Aug 2020 12:29:31 +0200
Subject: [11u] RFR (S) 8245880: Shenandoah: check class unloading flag
 early in concurrent code root scan
In-Reply-To: <d941b341-62b3-d19b-c90a-f448b8f515eb@redhat.com>
References: <d941b341-62b3-d19b-c90a-f448b8f515eb@redhat.com>
Message-ID: <fca83e57db4a1dc5961a7d2979a4145451accb23.camel@redhat.com>

Looks good to me! Thanks!

Roman

On Tue, 2020-08-18 at 12:22 +0200, Aleksey Shipilev wrote:
> Original bug:
>    https://bugs.openjdk.java.net/browse/JDK-8245880
>    https://hg.openjdk.java.net/jdk/jdk/rev/3a8634555a01
> 
> The patch does apply cleanly to 11u, because the usual MutexLockerEx
> -> MutexLocker change. 
> Reapplied the hunk by hand.
> 
> 11u webrev:
>    https://cr.openjdk.java.net/~shade/8245880/webrev.11u.01/
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with
> Shenandoah
> 


From shade at redhat.com  Tue Aug 18 10:31:03 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 12:31:03 +0200
Subject: [11u] 8244729: Shenandoah: remove resolve paths from
 SBSA::generate_shenandoah_lrb
Message-ID: <993c0eba-00f3-9365-7c6e-c562e6786423@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8244729
   https://hg.openjdk.java.net/jdk/jdk/rev/b0b93374fde6

The patch does not apply cleanly because of markOopDesc -> markWord rename. Otherwise the hunks seem 
the same. I reapplied them by hand.

11u webrev:
   https://cr.openjdk.java.net/~shade/8244729/webrev.11u.01/

Testing: Linux x86_64 hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah; Linux 
aarch64 build

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Aug 18 10:34:01 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 12:34:01 +0200
Subject: [11u] RFR 8244729: Shenandoah: remove resolve paths from
 SBSA::generate_shenandoah_lrb
In-Reply-To: <993c0eba-00f3-9365-7c6e-c562e6786423@redhat.com>
References: <993c0eba-00f3-9365-7c6e-c562e6786423@redhat.com>
Message-ID: <525a845a-1597-5786-2d9c-1e72be092f76@redhat.com>

Added "RFR" to subject line.

On 8/18/20 12:31 PM, Aleksey Shipilev wrote:
> Original bug:
>     https://bugs.openjdk.java.net/browse/JDK-8244729
>     https://hg.openjdk.java.net/jdk/jdk/rev/b0b93374fde6
> 
> The patch does not apply cleanly because of markOopDesc -> markWord rename. Otherwise the hunks seem
> the same. I reapplied them by hand.
> 
> 11u webrev:
>     https://cr.openjdk.java.net/~shade/8244729/webrev.11u.01/
> 
> Testing: Linux x86_64 hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah; Linux
> aarch64 build
> 


-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Tue Aug 18 11:50:43 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 18 Aug 2020 13:50:43 +0200
Subject: [11u] 8244729: Shenandoah: remove resolve paths from
 SBSA::generate_shenandoah_lrb
In-Reply-To: <993c0eba-00f3-9365-7c6e-c562e6786423@redhat.com>
References: <993c0eba-00f3-9365-7c6e-c562e6786423@redhat.com>
Message-ID: <8f7d68404b6d7c4a998e782e307b2234bd525f4a.camel@redhat.com>

Looks good to me!

Thanks,
Roman

On Tue, 2020-08-18 at 12:31 +0200, Aleksey Shipilev wrote:
> Original bug:
>    https://bugs.openjdk.java.net/browse/JDK-8244729
>    https://hg.openjdk.java.net/jdk/jdk/rev/b0b93374fde6
> 
> The patch does not apply cleanly because of markOopDesc -> markWord
> rename. Otherwise the hunks seem 
> the same. I reapplied them by hand.
> 
> 11u webrev:
>    https://cr.openjdk.java.net/~shade/8244729/webrev.11u.01/
> 
> Testing: Linux x86_64 hotspot_gc_shenandoah {fastdebug,release},
> tier{1,2} with Shenandoah; Linux 
> aarch64 build
> 


From zgu at redhat.com  Tue Aug 18 12:33:04 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 18 Aug 2020 08:33:04 -0400
Subject: [11u] RFR (S) 8251451: Shenandoah: Remark ObjectSynchronizer
 roots with I-U
In-Reply-To: <25550ae9-f314-e95f-3750-d57c5dfb5428@redhat.com>
References: <25550ae9-f314-e95f-3750-d57c5dfb5428@redhat.com>
Message-ID: <42bb52c5-2100-2e60-5127-1adf302ffa4e@redhat.com>

Looks good.

Thanks,

-Zhengyu

On 8/18/20 6:12 AM, Aleksey Shipilev wrote:
> Original bug:
>  ? https://bugs.openjdk.java.net/browse/JDK-8251451
>  ? https://cr.openjdk.java.net/~shade/8251451/webrev.11u.01/
> 
> The patch does apply cleanly to 11u, because the usual MutexLockerEx -> 
> MutexLocker change, ShenandoahTaskTerminator -> TaskTerminator rename, 
> indenting differences. Reapplied the hunks by hand.
> 
> 11u webrev:
>  ? https://cr.openjdk.java.net/~shade/8251451/webrev.11u.01/
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with 
> Shenandoah
> 


From shade at redhat.com  Tue Aug 18 12:46:35 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 14:46:35 +0200
Subject: [11u] RFR (S) 8245880: Shenandoah: check class unloading flag
 early in concurrent code root scan
In-Reply-To: <fca83e57db4a1dc5961a7d2979a4145451accb23.camel@redhat.com>
References: <d941b341-62b3-d19b-c90a-f448b8f515eb@redhat.com>
 <fca83e57db4a1dc5961a7d2979a4145451accb23.camel@redhat.com>
Message-ID: <c7679671-d004-80d1-eb58-8ae47f2a5c82@redhat.com>

On 8/18/20 12:29 PM, Roman Kennke wrote:
> Looks good to me! Thanks!

Thanks, added the tags.

-- 
-Aleksey


From shade at redhat.com  Tue Aug 18 12:47:51 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 14:47:51 +0200
Subject: [11u] RFR (S) 8251451: Shenandoah: Remark ObjectSynchronizer
 roots with I-U
In-Reply-To: <42bb52c5-2100-2e60-5127-1adf302ffa4e@redhat.com>
References: <25550ae9-f314-e95f-3750-d57c5dfb5428@redhat.com>
 <42bb52c5-2100-2e60-5127-1adf302ffa4e@redhat.com>
Message-ID: <5f7dc594-7e94-e6a5-d78c-3764e1f8462b@redhat.com>

On 8/18/20 2:33 PM, Zhengyu Gu wrote:
> Looks good.

Thanks, added the tags.

-- 
-Aleksey


From shade at redhat.com  Tue Aug 18 12:48:50 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Aug 2020 14:48:50 +0200
Subject: [11u] 8244729: Shenandoah: remove resolve paths from
 SBSA::generate_shenandoah_lrb
In-Reply-To: <8f7d68404b6d7c4a998e782e307b2234bd525f4a.camel@redhat.com>
References: <993c0eba-00f3-9365-7c6e-c562e6786423@redhat.com>
 <8f7d68404b6d7c4a998e782e307b2234bd525f4a.camel@redhat.com>
Message-ID: <36ec5667-2411-7f22-580f-444e273bb9cb@redhat.com>

On 8/18/20 1:50 PM, Roman Kennke wrote:
> Looks good to me!

Thanks, tagged.

-- 
-Aleksey


From rkennke at redhat.com  Tue Aug 18 13:39:18 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 18 Aug 2020 15:39:18 +0200
Subject: [11u] RFR 8251487: Shenandoah: missing detail timing tracking
 for final mark cleaning phase
In-Reply-To: <f3570156-a673-d26b-8d28-3ab3af662d47@redhat.com>
References: <74e0916d-738f-c8b1-001a-17607b0b23f4@redhat.com>
 <2625bca69b582ad901afdfb350fb9b134f6ce325.camel@redhat.com>
 <f3570156-a673-d26b-8d28-3ab3af662d47@redhat.com>
Message-ID: <2fddb7b0edd38f78a2ffc4ea5c007214c88c0039.camel@redhat.com>

Hi Zhengyu,


> > - the order of placement of _phase and its initializer don't match.
> > Some compilers are not going to like this.
> > - the indentation of _phase wrt the other fields doesn't match
> > - Alignment don't match here:
> > 
> > +  ParallelCleaningTask(ShenandoahPhaseTimings::Phase phase,
> > BoolObjectClosure* is_alive, bool process_strings,
> > +    bool process_symbols, uint num_workers, bool
> > unloading_occurred);
> 
> Updated: 
> http://cr.openjdk.java.net/~zgu/JDK-8251487/webrev.01/index.html
> 
> Okay now?

Yes, looks good! Thank you!

Roman



From zgu at redhat.com  Tue Aug 18 14:26:11 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 18 Aug 2020 10:26:11 -0400
Subject: [11u] RFR 8251487: Shenandoah: missing detail timing tracking for
 final mark cleaning phase
In-Reply-To: <2fddb7b0edd38f78a2ffc4ea5c007214c88c0039.camel@redhat.com>
References: <74e0916d-738f-c8b1-001a-17607b0b23f4@redhat.com>
 <2625bca69b582ad901afdfb350fb9b134f6ce325.camel@redhat.com>
 <f3570156-a673-d26b-8d28-3ab3af662d47@redhat.com>
 <2fddb7b0edd38f78a2ffc4ea5c007214c88c0039.camel@redhat.com>
Message-ID: <90ca08ae-01b7-e063-cc1b-8ec58fd6d45a@redhat.com>



On 8/18/20 9:39 AM, Roman Kennke wrote:
> Hi Zhengyu,
> 
> 
>>> - the order of placement of _phase and its initializer don't match.
>>> Some compilers are not going to like this.
>>> - the indentation of _phase wrt the other fields doesn't match
>>> - Alignment don't match here:
>>>
>>> +  ParallelCleaningTask(ShenandoahPhaseTimings::Phase phase,
>>> BoolObjectClosure* is_alive, bool process_strings,
>>> +    bool process_symbols, uint num_workers, bool
>>> unloading_occurred);
>>
>> Updated:
>> http://cr.openjdk.java.net/~zgu/JDK-8251487/webrev.01/index.html
>>
>> Okay now?
> 
> Yes, looks good! Thank you!

Thanks, Roman.

-Zhengyu
> 
> Roman
> 
> 


From TOSHIONA at jp.ibm.com  Wed Aug 19 09:11:22 2020
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Wed, 19 Aug 2020 18:11:22 +0900
Subject: [11u] RFR 8233829: javac cannot find non-ASCII module name under
 non-UTF8 env
Message-ID: <OFEF2E0136.5B09B41A-ON002585C9.0031FEED-492585C9.00327AE6@notes.na.collabserv.com>


Hi,

I'd like to backport 8233829 to 11u.
Original patch does not apply cleanly to 11u, because the target file was
reworked. The logic of the fix is same.

Original bug:
https://bugs.openjdk.java.net/browse/JDK-8233829
https://hg.openjdk.java.net/jdk/jdk/rev/25551ba96f75

11u webrev:
http://cr.openjdk.java.net/~tnakamura/8233829-11u/webrev.00

Testing: tier1 and tier2

Thanks,
Toshio Nakamura

From shade at redhat.com  Wed Aug 19 14:23:55 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 19 Aug 2020 16:23:55 +0200
Subject: [11u] RFR (XS) 8251949: ZGC: Set explicit heap size for
 compiler/gcbarriers tests
Message-ID: <b7df9a94-5e64-b880-4068-503fae162ca7@redhat.com>

11u-specific bug:
   https://bugs.openjdk.java.net/browse/JDK-8251949

I suggested doing that in jdk/jdk initially, and then backport, but Per suggested it is best to do 
in 11u specifically.

11u webrev:
   https://cr.openjdk.java.net/~shade/8251949/webrev.11u.01/

Testing: affected tests

-- 
Thanks,
-Aleksey


From nick.gasson at arm.com  Fri Aug 21 10:02:23 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Fri, 21 Aug 2020 18:02:23 +0800
Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling
 vector register
In-Reply-To: <85imed1mm0.fsf@nicgas01-pc.shanghai.arm.com>
References: <85imed1mm0.fsf@nicgas01-pc.shanghai.arm.com>
Message-ID: <85wo1swc40.fsf@nicgas01-pc.shanghai.arm.com>

Hi,

Is anyone available to help with this backport?

--
Thanks,
Nick

On 07/24/20 13:57 pm, Nick Gasson wrote:
> Hi,
>
> Is anyone able to sponsor this backport for me?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248845
> Original change: https://hg.openjdk.java.net/jdk/jdk15/rev/d5be95758352
> Review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/038886.html
>
> The patch does not apply cleanly on 11u as the ScheduleAndBundle
> function has been moved and renamed. I've prepared another webrev that
> applies on 11u:
>
> http://cr.openjdk.java.net/~ngasson/8248845/webrev.11u.0/
>
> Tested tier1 on AArch64.


From rob.mckenna at oracle.com  Fri Aug 21 15:26:09 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 21 Aug 2020 16:26:09 +0100
Subject: [15u Communication] jdk15u repo available
In-Reply-To: <20200114142450.GG9097@yoga>
References: <20190624154130.GB19779@vimes>
 <20200114142450.GG9097@yoga>
Message-ID: <20200821152609.GA3065@DESKTOP-JNNKIHU.localdomain>

A belated note to announce the availibility of the JDK 15 Updates repo
at:

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

Note: If you want to get changes in for 15.0.1 you should try to do it
within the next week or two. The repo will be closed to all but
showstoppers and P1's from September 1st.

    -Rob


From gnu.andrew at redhat.com  Fri Aug 21 19:09:45 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 21 Aug 2020 20:09:45 +0100
Subject: Additional Labels for Backport Work
Message-ID: <20200821190945.GD31221@stopbrexit>

Hi all,

I've begun using a number of labels to help with 8u backport work,
that are documented as part of the OpenJDK 8u contribution process
[0]. As few people seem to have noted those additions, I thought it
worth an e-mail with more details. I'm also CCing jdk-updates-dev in
case maintainers on other OpenJDK update projects want to adopt
similar labels.

The primary two labels are:

1. jdk8u-needs-review

  This label should be added after an RFR is posted for a backport to
  8u. Please also add a link to the RFR.

  There is now a link to a filter for bugs marked with this label on the
  8u wiki [1]. Those of you who are 8u reviewers are encouraged to
  regularly triage this list and help with reviewing work submitted for
  backport.

  This should avoid RFRs getting lost in mail traffic. You may also
  notice that if you make a jdk8u-fix-request before there is a
  completed review, it will be changed to this label.

2. jdk8u-<username>

  This label is essentially intended to work as a lock on the bug,
  indicating someone is actively backporting the bug. The intention is
  to let others know that work is in progress, but is not yet ready for
  an RFR.

  When using this label, please keep it on the bug for the minimum
  possible time. Add it when work is actively started and remove it when
  the change is pushed. It is not intended as an 'I'm interested' label,
  as with others such as 'redhat-interest', but to avoid multiple people
  actively working on the same task.

  If the label does seem to be present for a long time, other developers
  are encouraged to query the developer concerned as to whether they are
  still active on this bug and to take over the work if there is no
  response for a prolonged period (>2 weeks).

A further occasionally used label is jdk8u-needs-deps, which
maintainers may use on occasion to indicate that a bug submitted using
jdk8u-fix-request needs other fixes to be present before it can be
considered.

I hope these additional labels prove useful and help in the process
of completing 8u backports. Feedback is welcome and, again, 8u reviewers
are encouraged to use the jdk8u-needs-review filter to find reviews
needing attention.

[0] https://wiki.openjdk.java.net/display/jdk8u/Main
[1] https://bugs.openjdk.java.net/issues/?filter=39384

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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

From hohensee at amazon.com  Fri Aug 21 20:39:14 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 21 Aug 2020 20:39:14 +0000
Subject: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
 compatibility
Message-ID: <3A477F3D-AB56-4B29-AD0E-318ED0D17FCE@amazon.com>

Please review a small binary compatibility fix that applies only to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8252157
Webrev: http://cr.openjdk.java.net/~phh/8252157/webrev.00/

Thanks,
Paul


From shade at redhat.com  Mon Aug 24 05:43:16 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 24 Aug 2020 07:43:16 +0200
Subject: [15u Communication] jdk15u repo available
In-Reply-To: <20200821152609.GA3065@DESKTOP-JNNKIHU.localdomain>
References: <20190624154130.GB19779@vimes> <20200114142450.GG9097@yoga>
 <20200821152609.GA3065@DESKTOP-JNNKIHU.localdomain>
Message-ID: <2dd779a5-8416-d6c9-7a28-a415e27eaf33@redhat.com>

On 8/21/20 5:26 PM, Rob McKenna wrote:
> A belated note to announce the availibility of the JDK 15 Updates repo
> at:
> 
> http://hg.openjdk.java.net/jdk-updates/jdk15u/

As usual, the relevant workspace bundle is:
   https://builds.shipilev.net/workspaces/jdk-updates-jdk15u.tar.xz

-- 
Thanks,
-Aleksey


From yan at azul.com  Mon Aug 24 15:01:26 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Mon, 24 Aug 2020 18:01:26 +0300
Subject: [13u notice] transition to Git, GitHub, and Skara
Message-ID: <9bba3d73-c075-e053-364c-0b8458c0d33d@azul.com>

Hi all,

as you know, the final transition of current jdk (JDK 16) to Git, GitHub, and Skara
will be early in September [1]. At that moment, jdk/jdk repository hosted in GitHub will become
read/write master for JDK 16.

Now, JDK 13u seems a natural candidate to try the similar transition
of an update repository. We plan to do it for 13.0.6 release.
So we'll close JDK 13u-dev Mercurial team repo for the current 13.0.5 release
approximately on September 20 (according to schedule) and soon re-open it for the next release
already in Git. The master repository JDK 13u will be transformed after the October release
approximately in early November.

That means the Mercurial repositories [2] and [3] will become read-only, and
new change requests for 13u will start as GitHub pullback requests.

Note that there already are read-only GitHub mirrors of JDK 13u repositories [4], [5].
The actual URLs, exact dates etc. will be announced later ASAP.

Thank you!
--yan

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-May/004322.html
[2] http://hg.openjdk.java.net/jdk-updates/jdk13u-dev/
[3] http://hg.openjdk.java.net/jdk-updates/jdk13u/
[4] https://github.com/openjdk/jdk13u-dev
[5] https://github.com/openjdk/jdk13u


From hohensee at amazon.com  Mon Aug 24 18:12:55 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 24 Aug 2020 18:12:55 +0000
Subject: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
 compatibility
In-Reply-To: <3A477F3D-AB56-4B29-AD0E-318ED0D17FCE@amazon.com>
References: <3A477F3D-AB56-4B29-AD0E-318ED0D17FCE@amazon.com>
Message-ID: <06A7C05B-D1D7-411C-8097-127C6D80B386@amazon.com>

Passed:

test/jdk/java/lang/management/ThreadMXBean
test/jdk/com/sun/management/ThreadMXBean
test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean

?On 8/21/20, 1:42 PM, "jdk-updates-dev on behalf of Hohensee, Paul" <jdk-updates-dev-retn at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    Please review a small binary compatibility fix that applies only to 11u.

    Bug: https://bugs.openjdk.java.net/browse/JDK-8252157
    Webrev: http://cr.openjdk.java.net/~phh/8252157/webrev.00/

    Thanks,
    Paul



From vicente.romero at oracle.com  Mon Aug 24 19:47:29 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 24 Aug 2020 15:47:29 -0400
Subject: [11u] RFR 8233829: javac cannot find non-ASCII module name under
 non-UTF8 env
In-Reply-To: <OFEF2E0136.5B09B41A-ON002585C9.0031FEED-492585C9.00327AE6@notes.na.collabserv.com>
References: <OFEF2E0136.5B09B41A-ON002585C9.0031FEED-492585C9.00327AE6@notes.na.collabserv.com>
Message-ID: <cede740b-4e9e-94ac-4cd1-d40da194937e@oracle.com>

looks good to me,
Vicente

On 8/19/20 5:11 AM, Toshio 5 Nakamura wrote:
> Hi,
>
> I'd like to backport 8233829 to 11u.
> Original patch does not apply cleanly to 11u, because the target file was
> reworked. The logic of the fix is same.
>
> Original bug:
> https://bugs.openjdk.java.net/browse/JDK-8233829
> https://hg.openjdk.java.net/jdk/jdk/rev/25551ba96f75
>
> 11u webrev:
> http://cr.openjdk.java.net/~tnakamura/8233829-11u/webrev.00
>
> Testing: tier1 and tier2
>
> Thanks,
> Toshio Nakamura


From TOSHIONA at jp.ibm.com  Tue Aug 25 02:00:29 2020
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 25 Aug 2020 11:00:29 +0900
Subject: [11u] RFR 8233829: javac cannot find non-ASCII module name under
 non-UTF8 env
In-Reply-To: <cede740b-4e9e-94ac-4cd1-d40da194937e@oracle.com>
References: <OFEF2E0136.5B09B41A-ON002585C9.0031FEED-492585C9.00327AE6@notes.na.collabserv.com>
 <cede740b-4e9e-94ac-4cd1-d40da194937e@oracle.com>
Message-ID: <OFE26A3B3F.95C38DD8-ON002585CF.000AA067-492585CF.000B0829@notes.na.collabserv.com>


Hi Vicente,

Thank you for the review. I'll add a tag for requesting approval.

Thanks,
Toshio

Vicente Romero <vicente.romero at oracle.com> wrote on 2020/08/25 04:47:29:

> From: Vicente Romero <vicente.romero at oracle.com>
> To: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>,
jdk-updates-dev at openjdk.java.net
> Cc: compiler-dev at openjdk.java.net
> Date: 2020/08/25 04:47
> Subject: [EXTERNAL] Re: [11u] RFR 8233829: javac cannot find non-
> ASCII module name under non-UTF8 env
>
> looks good to me,
> Vicente
>
> On 8/19/20 5:11 AM, Toshio 5 Nakamura wrote:
> > Hi,
> >
> > I'd like to backport 8233829 to 11u.
> > Original patch does not apply cleanly to 11u, because the target file
was
> > reworked. The logic of the fix is same.
> >
> > Original bug:
> >
https://bugs.openjdk.java.net/browse/JDK-8233829

> >
https://hg.openjdk.java.net/jdk/jdk/rev/25551ba96f75

> >
> > 11u webrev:
> >
http://cr.openjdk.java.net/~tnakamura/8233829-11u/webrev.00

> >
> > Testing: tier1 and tier2
> >
> > Thanks,
> > Toshio Nakamura
>

From volker.simonis at gmail.com  Tue Aug 25 10:44:10 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 25 Aug 2020 12:44:10 +0200
Subject: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
 compatibility
In-Reply-To: <06A7C05B-D1D7-411C-8097-127C6D80B386@amazon.com>
References: <3A477F3D-AB56-4B29-AD0E-318ED0D17FCE@amazon.com>
 <06A7C05B-D1D7-411C-8097-127C6D80B386@amazon.com>
Message-ID: <CA+3eh10UjuP0HPJyjnafJKUDAUSSdUkjL_tRU7SZgjTuoCT_TA@mail.gmail.com>

Hi Paul,

Thanks for catching and fixing this.
Your changes look right and pretty trivial to me.
Thumbs up from my side.

Best regards,
Volker

On Mon, Aug 24, 2020 at 8:23 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Passed:
>
> test/jdk/java/lang/management/ThreadMXBean
> test/jdk/com/sun/management/ThreadMXBean
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean
>
> ?On 8/21/20, 1:42 PM, "jdk-updates-dev on behalf of Hohensee, Paul" <jdk-updates-dev-retn at openjdk.java.net on behalf of hohensee at amazon.com> wrote:
>
>     Please review a small binary compatibility fix that applies only to 11u.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8252157
>     Webrev: http://cr.openjdk.java.net/~phh/8252157/webrev.00/
>
>     Thanks,
>     Paul
>
>

From hohensee at amazon.com  Tue Aug 25 11:48:35 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 25 Aug 2020 11:48:35 +0000
Subject: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
 compatibility
Message-ID: <201149B7-A7E1-4F92-8580-9D23D856DB70@amazon.com>

Thank you Volker. Issue tagged.

Paul

?On 8/25/20, 3:45 AM, "Volker Simonis" <volker.simonis at gmail.com> wrote:

    Hi Paul,

    Thanks for catching and fixing this.
    Your changes look right and pretty trivial to me.
    Thumbs up from my side.

    Best regards,
    Volker

    On Mon, Aug 24, 2020 at 8:23 PM Hohensee, Paul <hohensee at amazon.com> wrote:
    >
    > Passed:
    >
    > test/jdk/java/lang/management/ThreadMXBean
    > test/jdk/com/sun/management/ThreadMXBean
    > test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean
    >
    > On 8/21/20, 1:42 PM, "jdk-updates-dev on behalf of Hohensee, Paul" <jdk-updates-dev-retn at openjdk.java.net on behalf of hohensee at amazon.com> wrote:
    >
    >     Please review a small binary compatibility fix that applies only to 11u.
    >
    >     Bug: https://bugs.openjdk.java.net/browse/JDK-8252157
    >     Webrev: http://cr.openjdk.java.net/~phh/8252157/webrev.00/
    >
    >     Thanks,
    >     Paul
    >
    >


From jcbeyler at google.com  Tue Aug 25 19:58:45 2020
From: jcbeyler at google.com (Jean Christophe Beyler)
Date: Tue, 25 Aug 2020 15:58:45 -0400
Subject: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
 the heap sampler
In-Reply-To: <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>
References: <CAF9BGBxpWxqw2FHejUjNH8o8W0WSKs0c=3=GAPxKb-5rJ9nqKw@mail.gmail.com>
 <CAF9BGBzWFXhA91y02hU=TjezTTMPnuucLj5KjzkV3BrNLOnrEQ@mail.gmail.com>
 <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
 <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>
Message-ID: <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>

Hi all,

Does anybody have time to review this and help push it in per chance? Or am
I missing something that I need to do :-) ?

That would be much appreciated!

Thanks again!
Jc

On Fri, Aug 7, 2020 at 2:24 PM Jean Christophe Beyler <jcbeyler at google.com>
wrote:

> Hi Volker,
>
> Sorry for the delay in my answer!
>
> First off, thanks for the review! I think I need someone to help push this
> webrev though and I am not sure if I need a second reviewer. That being
> said, here is the request with the empty line removed:
>
> - The original bug is here:
> https://bugs.openjdk.java.net/browse/JDK-8247615
> - The original change is here:
> https://hg.openjdk.java.net/jdk/jdk/rev/13ec613f9373
> - The webrev with the new change:
> http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.03_11/
> - The changes are not significant, I had just a few issues due to changes
> that came in between to the ThreadHeapSampler class; the test being new is
> unchanged
>
> Thanks for all your help, let me know if I need another reviewer or if
> someone can help push it for me!
>
> Thanks again,
> Jc
>
>
> On Wed, Jul 29, 2020 at 2:37 PM Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> Hi Jc,
>>
>> the downport looks fine to me except the extra empty line you've
>> inserted in threadHeapSampler.hpp:
>>
>>      _collectors_present = 0;
>> +
>> +
>> +    // Call this after _rnd is initialized to initialize
>> _bytes_until_sample.
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: as a general rule of thumb, a RFR for a downport should include
>> the following:
>> - a link to the original bug (JBS link)
>> - a link to the original change (i.e. a link to the Mercurial change
>> set, not to the original webrev)
>> - a link to the webrev with the new change
>> - if your changes to "original change" are significant an explanation
>> why they are required. A diff in webrev format of the "new change"
>> against "original change" might be helpful in such a case.
>>
>> On Wed, Jul 29, 2020 at 8:09 PM Jean Christophe Beyler
>> <jcbeyler at google.com> wrote:
>> >
>> > Hi all,
>> >
>> > Any chance to get a review on this? Did I perhaps missed something?
>> >
>> > Thanks again for your help!
>> > Jc
>> >
>> > On Thu, Jul 23, 2020 at 10:43 AM Jean Christophe Beyler <
>> jcbeyler at google.com>
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > First time I request a backport so if I am missing anything, please
>> let me
>> > > know :)
>> > >
>> > > I am trying to port this webrev into 11u:
>> > >
>> > > Summary:
>> > > This fixes a sampling bias for the first allocations and ensures that
>> the
>> > > sampling rate is correct from the start.
>> > > It is safe to apply as the whole code is protected behind flags and
>> only
>> > > is used when JVMTI enables the heap monitoring.
>> > > We added a test that tickles this code on purpose.
>> > >
>> > > Porting issues:
>> > > Finally, the patch does not apply cleanly due to slight differences
>> with
>> > > the files. This webrev provides the clean to JDK11u:
>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02_11/
>> > >
>> > > - That webrev compiles and tests for HeapMonitor (with the new test)
>> pass:
>> > >     make run-test
>> > > TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor"
>> > >
>> > > compared to what I submitted to head:
>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02/
>> > >
>> > > Let me know what else I can do or provide!
>> > >
>> > > Thanks for all your help,
>> > > Jc
>> > >
>> > > Ps: I sent this email before I subscribed so one is waiting in
>> moderation;
>> > > if this shows up in double, I apologize :)
>> > >
>> >
>> >
>> > --
>> >
>> > Thanks,
>> > Jc
>>
>
>
> --
>
> Thanks,
> Jc
>


-- 

Thanks,
Jc

From felix.yang at huawei.com  Wed Aug 26 02:03:59 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Wed, 26 Aug 2020 02:03:59 +0000
Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling
 vector register
In-Reply-To: <85wo1swc40.fsf@nicgas01-pc.shanghai.arm.com>
References: <85imed1mm0.fsf@nicgas01-pc.shanghai.arm.com>
 <85wo1swc40.fsf@nicgas01-pc.shanghai.arm.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE7EC8FEE@dggeml507-mbx.china.huawei.com>

Hi Nick,

I see it was approved for jdk11u.  I will help push it for you.

Felix

> -----Original Message-----
> From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net] On
> Behalf Of Nick Gasson
> Sent: Friday, August 21, 2020 6:02 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8248845: AArch64: stack corruption after spilling
> vector register
> 
> Hi,
> 
> Is anyone available to help with this backport?
> 
> --
> Thanks,
> Nick
> 
> On 07/24/20 13:57 pm, Nick Gasson wrote:
> > Hi,
> >
> > Is anyone able to sponsor this backport for me?
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8248845
> > Original change:
> > https://hg.openjdk.java.net/jdk/jdk15/rev/d5be95758352
> > Review thread:
> > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July
> > /038886.html
> >
> > The patch does not apply cleanly on 11u as the ScheduleAndBundle
> > function has been moved and renamed. I've prepared another webrev
> that
> > applies on 11u:
> >
> > http://cr.openjdk.java.net/~ngasson/8248845/webrev.11u.0/
> >
> > Tested tier1 on AArch64.


From sgehwolf at redhat.com  Wed Aug 26 06:39:28 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 26 Aug 2020 08:39:28 +0200
Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling
 vector register
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE7EC8FEE@dggeml507-mbx.china.huawei.com>
References: <85imed1mm0.fsf@nicgas01-pc.shanghai.arm.com>
 <85wo1swc40.fsf@nicgas01-pc.shanghai.arm.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE7EC8FEE@dggeml507-mbx.china.huawei.com>
Message-ID: <45d2a65e481596756dad3ef118023efd39eb7269.camel@redhat.com>

Hi,

On Wed, 2020-08-26 at 02:03 +0000, Yangfei (Felix) wrote:
> Hi Nick,
> 
> I see it was approved for jdk11u.  I will help push it for you.

While it has jdk11u-fix-yes, there seem to be conflicting statements
being made. This thread says it doesn't apply cleanly hence this review
thread. The bug comment from 2020-07-08 says "Patch applies cleanly".
Which one is it? Assuming the former, we should get the review done
first before pushing.

Thanks,
Severin

> Felix
> 
> > -----Original Message-----
> > From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net] On
> > Behalf Of Nick Gasson
> > Sent: Friday, August 21, 2020 6:02 PM
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: Re: [11u] RFR: 8248845: AArch64: stack corruption after spilling
> > vector register
> > 
> > Hi,
> > 
> > Is anyone available to help with this backport?
> > 
> > --
> > Thanks,
> > Nick
> > 
> > On 07/24/20 13:57 pm, Nick Gasson wrote:
> > > Hi,
> > > 
> > > Is anyone able to sponsor this backport for me?
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248845
> > > Original change:
> > > https://hg.openjdk.java.net/jdk/jdk15/rev/d5be95758352
> > > Review thread:
> > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July
> > > /038886.html
> > > 
> > > The patch does not apply cleanly on 11u as the ScheduleAndBundle
> > > function has been moved and renamed. I've prepared another webrev
> > that
> > > applies on 11u:
> > > 
> > > http://cr.openjdk.java.net/~ngasson/8248845/webrev.11u.0/
> > > 
> > > Tested tier1 on AArch64.


From felix.yang at huawei.com  Wed Aug 26 06:48:09 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Wed, 26 Aug 2020 06:48:09 +0000
Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling
 vector register
In-Reply-To: <45d2a65e481596756dad3ef118023efd39eb7269.camel@redhat.com>
References: <85imed1mm0.fsf@nicgas01-pc.shanghai.arm.com>
 <85wo1swc40.fsf@nicgas01-pc.shanghai.arm.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE7EC8FEE@dggeml507-mbx.china.huawei.com>
 <45d2a65e481596756dad3ef118023efd39eb7269.camel@redhat.com>
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE7EC912A@dggeml507-mbx.china.huawei.com>

Hi,

> -----Original Message-----
> From: Severin Gehwolf [mailto:sgehwolf at redhat.com]
> Sent: Wednesday, August 26, 2020 2:39 PM
> To: Yangfei (Felix) <felix.yang at huawei.com>; Nick Gasson
> <nick.gasson at arm.com>; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8248845: AArch64: stack corruption after spilling
> vector register
> 
> Hi,
> 
> On Wed, 2020-08-26 at 02:03 +0000, Yangfei (Felix) wrote:
> > Hi Nick,
> >
> > I see it was approved for jdk11u.  I will help push it for you.
> 
> While it has jdk11u-fix-yes, there seem to be conflicting statements being
> made. This thread says it doesn't apply cleanly hence this review thread. The
> bug comment from 2020-07-08 says "Patch applies cleanly".
> Which one is it? Assuming the former, we should get the review done first
> before pushing.

True.  I also noticed this when I tried to apply the original patch. 
I will hold on pushing this before the backport webrev is reviewed.

Thanks,
Felix

> Thanks,
> Severin
> 
> > Felix
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net]
> > > On Behalf Of Nick Gasson
> > > Sent: Friday, August 21, 2020 6:02 PM
> > > To: jdk-updates-dev at openjdk.java.net
> > > Subject: Re: [11u] RFR: 8248845: AArch64: stack corruption after
> > > spilling vector register
> > >
> > > Hi,
> > >
> > > Is anyone available to help with this backport?
> > >
> > > --
> > > Thanks,
> > > Nick
> > >
> > > On 07/24/20 13:57 pm, Nick Gasson wrote:
> > > > Hi,
> > > >
> > > > Is anyone able to sponsor this backport for me?
> > > >
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248845
> > > > Original change:
> > > > https://hg.openjdk.java.net/jdk/jdk15/rev/d5be95758352
> > > > Review thread:
> > > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-
> > > > July
> > > > /038886.html
> > > >
> > > > The patch does not apply cleanly on 11u as the ScheduleAndBundle
> > > > function has been moved and renamed. I've prepared another webrev
> > > that
> > > > applies on 11u:
> > > >
> > > > http://cr.openjdk.java.net/~ngasson/8248845/webrev.11u.0/
> > > >
> > > > Tested tier1 on AArch64.


From nick.gasson at arm.com  Wed Aug 26 06:55:57 2020
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 26 Aug 2020 14:55:57 +0800
Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling
 vector register
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE7EC912A@dggeml507-mbx.china.huawei.com>
References: <85imed1mm0.fsf@nicgas01-pc.shanghai.arm.com>
 <85wo1swc40.fsf@nicgas01-pc.shanghai.arm.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE7EC8FEE@dggeml507-mbx.china.huawei.com>
 <45d2a65e481596756dad3ef118023efd39eb7269.camel@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE7EC912A@dggeml507-mbx.china.huawei.com>
Message-ID: <85tuwpew02.fsf@nicgas01-pc.shanghai.arm.com>

On 08/26/20 14:48 pm, Yangfei (Felix) wrote:
>> 
>> While it has jdk11u-fix-yes, there seem to be conflicting statements being
>> made. This thread says it doesn't apply cleanly hence this review thread. The
>> bug comment from 2020-07-08 says "Patch applies cleanly".
>> Which one is it? Assuming the former, we should get the review done first
>> before pushing.
>
> True.  I also noticed this when I tried to apply the original patch. 
> I will hold on pushing this before the backport webrev is reviewed.
>

Sorry the comment on the bug is wrong: the context for the diff needs
adjusting for 11u (although the actual change is identical).

--
Nick

From christoph.goettschkes at microdoc.com  Wed Aug 26 09:29:54 2020
From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=)
Date: Wed, 26 Aug 2020 11:29:54 +0200
Subject: [ping] [11u] RFR 8234535: Cross compilation fails due to missing
 CFLAGS for the BUILD_CC
In-Reply-To: <32d6e87j9y-1@aserp2040.oracle.com>
References: <32d6e87j9y-1@aserp2040.oracle.com>
Message-ID: <333phg5kt6-1@userp2020.oracle.com>

Hi,

the webrev below still applies cleanly to jdk11u-dev. Could someone 
please review this downport?

Thanks,
Christoph

On 2020-07-20 15:48, Christoph G?ttschkes wrote:
> Hi,
> 
> please review this downport of JDK-8234535 to jdk11u-dev.
> 
> The changeset does not apply cleanly because of unrelated differences in 
> the flags-cflags.m4 file surrounding the patch. Manually applying the 
> patch was trivial.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234535
> Commit: https://hg.openjdk.java.net/jdk/jdk/rev/eef0bf57357c
> Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/
> 
> Thanks,
> Christoph
> 


From sgehwolf at redhat.com  Wed Aug 26 10:10:14 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 26 Aug 2020 12:10:14 +0200
Subject: [ping] [11u] RFR 8234535: Cross compilation fails due to
 missing CFLAGS for the BUILD_CC
In-Reply-To: <333phg5kt6-1@userp2020.oracle.com>
References: <32d6e87j9y-1@aserp2040.oracle.com>
 <333phg5kt6-1@userp2020.oracle.com>
Message-ID: <4f70b51731937ba872035a01621ec11f39cea626.camel@redhat.com>

On Wed, 2020-08-26 at 11:29 +0200, Christoph G?ttschkes wrote:
> > Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/

This looks fine to me.

Thanks,
Severin


From christoph.goettschkes at microdoc.com  Wed Aug 26 11:08:04 2020
From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=)
Date: Wed, 26 Aug 2020 13:08:04 +0200
Subject: [ping] [11u] RFR 8234535: Cross compilation fails due to missing
 CFLAGS for the BUILD_CC
In-Reply-To: <4f70b51731937ba872035a01621ec11f39cea626.camel@redhat.com>
References: <32d6e87j9y-1@aserp2040.oracle.com>
 <333phg5kt6-1@userp2020.oracle.com>
 <4f70b51731937ba872035a01621ec11f39cea626.camel@redhat.com>
Message-ID: <333ptdwr0s-1@aserp2040.oracle.com>

Thank you for the quick review, Severin.

-- Christoph

On 2020-08-26 12:10, Severin Gehwolf wrote:
> On Wed, 2020-08-26 at 11:29 +0200, Christoph G?ttschkes wrote:
>>> Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/
> 
> This looks fine to me.
> 
> Thanks,
> Severin
> 


From zgu at redhat.com  Wed Aug 26 15:32:17 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 26 Aug 2020 11:32:17 -0400
Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are
 truncated
Message-ID: <097300d2-5517-7565-b2de-345c153187da@redhat.com>

I would like to backport this to 11u for parity with Oracle 11.0.10-oracle.

The original patch does not apply cleanly, but conflicts are minor.

1) PopupFactory.java
   Copyright year

2) StalePreferredSize.java
   Imports, @bug, @module and run lines

They are easy to fix manually.

The original bug:  https://bugs.openjdk.java.net/browse/JDK-8213535
The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/71df50d2926b

11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8213535-11u/webrev.00/

Thanks,

-Zhengyu


From martinrb at google.com  Wed Aug 26 22:53:37 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Aug 2020 15:53:37 -0700
Subject: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
 the heap sampler
In-Reply-To: <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>
References: <CAF9BGBxpWxqw2FHejUjNH8o8W0WSKs0c=3=GAPxKb-5rJ9nqKw@mail.gmail.com>
 <CAF9BGBzWFXhA91y02hU=TjezTTMPnuucLj5KjzkV3BrNLOnrEQ@mail.gmail.com>
 <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
 <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>
 <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>
Message-ID: <CA+kOe09Z_yppTnczVxS6VNV+VQ0F8fWDRji5XUbm2g5cp1+AtQ@mail.gmail.com>

LGTM

On Tue, Aug 25, 2020 at 12:59 PM Jean Christophe Beyler
<jcbeyler at google.com> wrote:
>
> Hi all,
>
> Does anybody have time to review this and help push it in per chance? Or am
> I missing something that I need to do :-) ?
>
> That would be much appreciated!
>
> Thanks again!
> Jc
>
> On Fri, Aug 7, 2020 at 2:24 PM Jean Christophe Beyler <jcbeyler at google.com>
> wrote:
>
> > Hi Volker,
> >
> > Sorry for the delay in my answer!
> >
> > First off, thanks for the review! I think I need someone to help push this
> > webrev though and I am not sure if I need a second reviewer. That being
> > said, here is the request with the empty line removed:
> >
> > - The original bug is here:
> > https://bugs.openjdk.java.net/browse/JDK-8247615
> > - The original change is here:
> > https://hg.openjdk.java.net/jdk/jdk/rev/13ec613f9373
> > - The webrev with the new change:
> > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.03_11/
> > - The changes are not significant, I had just a few issues due to changes
> > that came in between to the ThreadHeapSampler class; the test being new is
> > unchanged
> >
> > Thanks for all your help, let me know if I need another reviewer or if
> > someone can help push it for me!
> >
> > Thanks again,
> > Jc
> >
> >
> > On Wed, Jul 29, 2020 at 2:37 PM Volker Simonis <volker.simonis at gmail.com>
> > wrote:
> >
> >> Hi Jc,
> >>
> >> the downport looks fine to me except the extra empty line you've
> >> inserted in threadHeapSampler.hpp:
> >>
> >>      _collectors_present = 0;
> >> +
> >> +
> >> +    // Call this after _rnd is initialized to initialize
> >> _bytes_until_sample.
> >>
> >> Thank you and best regards,
> >> Volker
> >>
> >> PS: as a general rule of thumb, a RFR for a downport should include
> >> the following:
> >> - a link to the original bug (JBS link)
> >> - a link to the original change (i.e. a link to the Mercurial change
> >> set, not to the original webrev)
> >> - a link to the webrev with the new change
> >> - if your changes to "original change" are significant an explanation
> >> why they are required. A diff in webrev format of the "new change"
> >> against "original change" might be helpful in such a case.
> >>
> >> On Wed, Jul 29, 2020 at 8:09 PM Jean Christophe Beyler
> >> <jcbeyler at google.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > Any chance to get a review on this? Did I perhaps missed something?
> >> >
> >> > Thanks again for your help!
> >> > Jc
> >> >
> >> > On Thu, Jul 23, 2020 at 10:43 AM Jean Christophe Beyler <
> >> jcbeyler at google.com>
> >> > wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > First time I request a backport so if I am missing anything, please
> >> let me
> >> > > know :)
> >> > >
> >> > > I am trying to port this webrev into 11u:
> >> > >
> >> > > Summary:
> >> > > This fixes a sampling bias for the first allocations and ensures that
> >> the
> >> > > sampling rate is correct from the start.
> >> > > It is safe to apply as the whole code is protected behind flags and
> >> only
> >> > > is used when JVMTI enables the heap monitoring.
> >> > > We added a test that tickles this code on purpose.
> >> > >
> >> > > Porting issues:
> >> > > Finally, the patch does not apply cleanly due to slight differences
> >> with
> >> > > the files. This webrev provides the clean to JDK11u:
> >> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02_11/
> >> > >
> >> > > - That webrev compiles and tests for HeapMonitor (with the new test)
> >> pass:
> >> > >     make run-test
> >> > > TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor"
> >> > >
> >> > > compared to what I submitted to head:
> >> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02/
> >> > >
> >> > > Let me know what else I can do or provide!
> >> > >
> >> > > Thanks for all your help,
> >> > > Jc
> >> > >
> >> > > Ps: I sent this email before I subscribed so one is waiting in
> >> moderation;
> >> > > if this shows up in double, I apologize :)
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Thanks,
> >> > Jc
> >>
> >
> >
> > --
> >
> > Thanks,
> > Jc
> >
>
>
> --
>
> Thanks,
> Jc

From goetz.lindenmaier at sap.com  Thu Aug 27 07:34:40 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 27 Aug 2020 07:34:40 +0000
Subject: [11u reminder]: jdk 11.0.9 rampdown starts Tuesday, September 1st,
 18:00 CET.
Message-ID: <AM4PR0202MB2964EDC00F4889AAA28ED6E6EC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

I would like to remind everybody who is working on jdk 11 updates
that rampdown of 11.0.9 starts next Tuesday, Septemer 1st, at 18:00 CET.

At that point in time the last merge from jdk11u-dev to jdk11u
will take place.  Please push all changes you want to get to 11.0.9
before that date.

After that, changes for 11.0.9 must be requested with
jdk11u-critical-request tags, and they need to be pushed
directly to jdk11u.

Best regards,
  Goetz

See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

From goetz.lindenmaier at sap.com  Thu Aug 27 08:05:56 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 27 Aug 2020 08:05:56 +0000
Subject: [11u] RFR(XS): 8252415: Bump update version for OpenJDK: jdk-11.0.10
Message-ID: <AM4PR0202MB296496756C8E21C6AD276924EC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

to start development of jdk-11.0.10, we need to bump
the version:
http://cr.openjdk.java.net/~goetz/wr20/8252415-version_11.0.10-jdk11/

Please review.

Naturally, I will only push this after dev close of 11.0.9,
and after JBS was updated to tag for 11.0.10.

For the date, see also https://www.oracle.com/security-alerts/

Thanks,
  Goetz.

From shade at redhat.com  Thu Aug 27 08:08:26 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 27 Aug 2020 10:08:26 +0200
Subject: [11u] RFR(XS): 8252415: Bump update version for OpenJDK:
 jdk-11.0.10
In-Reply-To: <AM4PR0202MB296496756C8E21C6AD276924EC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB296496756C8E21C6AD276924EC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <7d2878b8-3c15-11af-cc23-461f298db58a@redhat.com>

On 8/27/20 10:05 AM, Lindenmaier, Goetz wrote:
> to start development of jdk-11.0.10, we need to bump
> the version:
> http://cr.openjdk.java.net/~goetz/wr20/8252415-version_11.0.10-jdk11/

Sure thing. Looks good.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Aug 27 08:50:46 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 27 Aug 2020 10:50:46 +0200
Subject: [11u] RFR (XS) 8210131:
 vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java
 failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected
 error code
Message-ID: <fd9288a7-b78c-10ef-eae0-e54491a985ff@redhat.com>

Hi,

I have already got the approval for this push to 11u, but when checking the patch queue, I realized 
the patch does not apply cleanly, because there is a problem list change from a subtask:
   http://hg.openjdk.java.net/jdk/jdk/rev/0cd55d573893

The problem list addition does not apply cleanly by itself. So for this backport, I opt to drop the 
problem list addition and removal.

Upstream version:
    http://hg.openjdk.java.net/jdk/jdk/rev/53e61697a020

11u version omits the problem list hunk:

diff -r 29196ae99fe5 src/hotspot/share/prims/jvmtiEnter.xsl
--- a/src/hotspot/share/prims/jvmtiEnter.xsl    Mon May 25 11:05:23 2020 +0200
+++ b/src/hotspot/share/prims/jvmtiEnter.xsl    Thu Aug 27 10:49:15 2020 +0200
@@ -403,11 +403,11 @@
        <xsl:text>if (this_thread == NULL || !this_thread->is_Java_thread()) {</xsl:text>
      </xsl:when>
      <xsl:otherwise>
        <xsl:choose>
          <xsl:when test="count(@phase)=0 or contains(@phase,'live') or contains(@phase,'start')">
-         <xsl:text>if (this_thread == NULL || (!this_thread->is_Java_thread() &amp;&amp; 
!this_thread->is_VM_thread())) {</xsl:text>
+         <xsl:text>if (this_thread == NULL || (!this_thread->is_Java_thread() &amp;&amp; 
!this_thread->is_Named_thread())) {</xsl:text>
          </xsl:when>
          <xsl:otherwise>
            <xsl:text>if (!this_thread->is_Java_thread()) {</xsl:text>
          </xsl:otherwise>
        </xsl:choose>

Any concerns?

-- 
Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Thu Aug 27 09:21:18 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 27 Aug 2020 09:21:18 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR02MB30576B90704501025D91FAFD9A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR02MB30576B90704501025D91FAFD9A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB29640626EB0FEC98B698BA1AEC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Martin, 

I had a look at your downport. 

I don't really understand which part you took from jdk15. 

I think you lost line
-  assert(thread->last_Java_sp(), "last_Java_sp must be set");
In jvmciRuntme.cpp, monitorexit().

Besides that it looks good.

I'll also post this to jdk-updates-dev.

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net> On Behalf Of Doerr, Martin
Sent: Montag, 17. August 2020 23:57
To: hotspot-runtime-dev at openjdk.java.net
Subject: [CAUTION] FW: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.

Forwarding to hotspot-runtime.


Hi,

I'd like to backport https://bugs.openjdk.java.net/browse/JDK-8241234 to JDK11u.

Original JDK15 patch (https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63) doesn't fit to JDK11u because the locking code has been reworked by https://bugs.openjdk.java.net/browse/JDK-8229844
As mentioned by Vladimir, there's already a GraalVM version available which consists of 2 patches (original + addon) and which can be applied:
https://github.com/graalvm/labs-openjdk-11/commit/6c162cb15262e6aa77e36eb3a268320ef0a206a4
https://github.com/graalvm/labs-openjdk-11/commit/6a28a618cdbe595f9a3993e0eb63c01ccae1a528
Only JVMCI part from GraalVM doesn't apply automatically. The version of this file from JDK15 is very simple and fits perfectly.

Please review the JDK11u backport webrev:
http://cr.openjdk.java.net/~mdoerr/8241234_monitorenterexit_11u/webrev.00/

Thanks and best regards,
Martin


From martin.doerr at sap.com  Thu Aug 27 09:38:35 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 27 Aug 2020 09:38:35 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR0202MB29640626EB0FEC98B698BA1AEC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR02MB30576B90704501025D91FAFD9A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR0202MB29640626EB0FEC98B698BA1AEC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057DC2000E04ED7BE1ECE6F9A550@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi G?tz,

thanks for looking at the backport.

> I don't really understand which part you took from jdk15.
I took the jvmciRuntime.cpp parts from the original change: https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63

Right, the assertion "assert(thread->last_Java_sp(), "last_Java_sp must be set");" should not get touched by this change.
I've added it back.

Are you ok with it?

Best regards,
Martin


> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Donnerstag, 27. August 2020 11:21
> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> Hi Martin,
> 
> I had a look at your downport.
> 
> I don't really understand which part you took from jdk15.
> 
> I think you lost line
> -  assert(thread->last_Java_sp(), "last_Java_sp must be set");
> In jvmciRuntme.cpp, monitorexit().
> 
> Besides that it looks good.
> 
> I'll also post this to jdk-updates-dev.
> 
> Best regards,
>   Goetz.
> 
> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
> On Behalf Of Doerr, Martin
> Sent: Montag, 17. August 2020 23:57
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: [CAUTION] FW: [11u] RFR(S): 8241234: Unify monitor enter/exit
> runtime entries.
> 
> Forwarding to hotspot-runtime.
> 
> 
> Hi,
> 
> I'd like to backport https://bugs.openjdk.java.net/browse/JDK-8241234 to
> JDK11u.
> 
> Original JDK15 patch
> (https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63) doesn't fit to
> JDK11u because the locking code has been reworked by
> https://bugs.openjdk.java.net/browse/JDK-8229844
> As mentioned by Vladimir, there's already a GraalVM version available which
> consists of 2 patches (original + addon) and which can be applied:
> https://github.com/graalvm/labs-openjdk-
> 11/commit/6c162cb15262e6aa77e36eb3a268320ef0a206a4
> https://github.com/graalvm/labs-openjdk-
> 11/commit/6a28a618cdbe595f9a3993e0eb63c01ccae1a528
> Only JVMCI part from GraalVM doesn't apply automatically. The version of
> this file from JDK15 is very simple and fits perfectly.
> 
> Please review the JDK11u backport webrev:
> http://cr.openjdk.java.net/~mdoerr/8241234_monitorenterexit_11u/webre
> v.00/
> 
> Thanks and best regards,
> Martin


From aph at redhat.com  Thu Aug 27 09:44:41 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 27 Aug 2020 10:44:41 +0100
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>

On 17/08/2020 22:54, Doerr, Martin wrote:
> Hi,
> 
> I'd like to backport https://bugs.openjdk.java.net/browse/JDK-8241234 to JDK11u.
> 
> Original JDK15 patch (https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63) doesn't fit to JDK11u because the locking code has been reworked by https://bugs.openjdk.java.net/browse/JDK-8229844
> As mentioned by Vladimir, there's already a GraalVM version available which consists of 2 patches (original + addon) and which can be applied:
> https://github.com/graalvm/labs-openjdk-11/commit/6c162cb15262e6aa77e36eb3a268320ef0a206a4
> https://github.com/graalvm/labs-openjdk-11/commit/6a28a618cdbe595f9a3993e0eb63c01ccae1a528
> Only JVMCI part from GraalVM doesn't apply automatically. The version of this file from JDK15 is very simple and fits perfectly.
> 
> Please review the JDK11u backport webrev:
> http://cr.openjdk.java.net/~mdoerr/8241234_monitorenterexit_11u/webrev.00/

Why is anyone backporting a P4 Enhancement? Seems weird.


-- 
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 martin.doerr at sap.com  Thu Aug 27 10:04:28 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 27 Aug 2020 10:04:28 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
Message-ID: <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Andrew,

> Why is anyone backporting a P4 Enhancement? Seems weird.
This is a good question in general. Personally, I'd vote for backporting fewer less important things to 11u in the future. We should better focus on 17 IMHO.

However, there are some arguments for backporting this one:
- Oracle has done so. There may be more backports in this area and I'd expect less effort if we have the same code in the open version.
- Performance is supposed to be better. (Though I didn't measure it.)
- New code is much cleaner. Let's keep in mind that we have to support it for quite a while.

Are you ok with it?

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Donnerstag, 27. August 2020 11:45
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; jdk-
> updates-dev at openjdk.java.net
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> On 17/08/2020 22:54, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to backport https://bugs.openjdk.java.net/browse/JDK-8241234 to
> JDK11u.
> >
> > Original JDK15 patch
> (https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63) doesn't fit to
> JDK11u because the locking code has been reworked by
> https://bugs.openjdk.java.net/browse/JDK-8229844
> > As mentioned by Vladimir, there's already a GraalVM version available
> which consists of 2 patches (original + addon) and which can be applied:
> > https://github.com/graalvm/labs-openjdk-
> 11/commit/6c162cb15262e6aa77e36eb3a268320ef0a206a4
> > https://github.com/graalvm/labs-openjdk-
> 11/commit/6a28a618cdbe595f9a3993e0eb63c01ccae1a528
> > Only JVMCI part from GraalVM doesn't apply automatically. The version of
> this file from JDK15 is very simple and fits perfectly.
> >
> > Please review the JDK11u backport webrev:
> >
> http://cr.openjdk.java.net/~mdoerr/8241234_monitorenterexit_11u/webre
> v.00/
> 
> Why is anyone backporting a P4 Enhancement? Seems weird.
> 
> 
> --
> 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  Thu Aug 27 10:45:24 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 27 Aug 2020 10:45:24 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR02MB3057DC2000E04ED7BE1ECE6F9A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR02MB30576B90704501025D91FAFD9A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR0202MB29640626EB0FEC98B698BA1AEC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB3057DC2000E04ED7BE1ECE6F9A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB29642121C1A4C9D69B3171A4EC550@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Martin, 

Yes, it's good then.  Ready to go. 

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Thursday, August 27, 2020 11:39 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> Hi G?tz,
> 
> thanks for looking at the backport.
> 
> > I don't really understand which part you took from jdk15.
> I took the jvmciRuntime.cpp parts from the original change:
> https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63
> 
> Right, the assertion "assert(thread->last_Java_sp(), "last_Java_sp must be
> set");" should not get touched by this change.
> I've added it back.
> 
> Are you ok with it?
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Sent: Donnerstag, 27. August 2020 11:21
> > To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
> > dev at openjdk.java.net
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: RE: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime
> entries.
> >
> > Hi Martin,
> >
> > I had a look at your downport.
> >
> > I don't really understand which part you took from jdk15.
> >
> > I think you lost line
> > -  assert(thread->last_Java_sp(), "last_Java_sp must be set");
> > In jvmciRuntme.cpp, monitorexit().
> >
> > Besides that it looks good.
> >
> > I'll also post this to jdk-updates-dev.
> >
> > Best regards,
> >   Goetz.
> >
> > -----Original Message-----
> > From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
> > On Behalf Of Doerr, Martin
> > Sent: Montag, 17. August 2020 23:57
> > To: hotspot-runtime-dev at openjdk.java.net
> > Subject: [CAUTION] FW: [11u] RFR(S): 8241234: Unify monitor enter/exit
> > runtime entries.
> >
> > Forwarding to hotspot-runtime.
> >
> >
> > Hi,
> >
> > I'd like to backport https://bugs.openjdk.java.net/browse/JDK-8241234 to
> > JDK11u.
> >
> > Original JDK15 patch
> > (https://hg.openjdk.java.net/jdk/jdk/rev/87c506c8be63) doesn't fit to
> > JDK11u because the locking code has been reworked by
> > https://bugs.openjdk.java.net/browse/JDK-8229844
> > As mentioned by Vladimir, there's already a GraalVM version available
> which
> > consists of 2 patches (original + addon) and which can be applied:
> > https://github.com/graalvm/labs-openjdk-
> > 11/commit/6c162cb15262e6aa77e36eb3a268320ef0a206a4
> > https://github.com/graalvm/labs-openjdk-
> > 11/commit/6a28a618cdbe595f9a3993e0eb63c01ccae1a528
> > Only JVMCI part from GraalVM doesn't apply automatically. The version of
> > this file from JDK15 is very simple and fits perfectly.
> >
> > Please review the JDK11u backport webrev:
> >
> http://cr.openjdk.java.net/~mdoerr/8241234_monitorenterexit_11u/webre
> > v.00/
> >
> > Thanks and best regards,
> > Martin


From volker.simonis at gmail.com  Thu Aug 27 13:45:08 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 27 Aug 2020 15:45:08 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <20200821190945.GD31221@stopbrexit>
References: <20200821190945.GD31221@stopbrexit>
Message-ID: <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>

Hi,

As two of the corresponding three 8u and 11u maintainers are actually
overlapping, I wonder if these new rules already automatically apply
to the 11u updates process as well or do they require an additional
approval of the 11u lead maintainer (Andrew H.)?

I'd personally welcome the use of the new tags in 11u.

Best regards,
Volker

On Fri, Aug 21, 2020 at 9:11 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> Hi all,
>
> I've begun using a number of labels to help with 8u backport work,
> that are documented as part of the OpenJDK 8u contribution process
> [0]. As few people seem to have noted those additions, I thought it
> worth an e-mail with more details. I'm also CCing jdk-updates-dev in
> case maintainers on other OpenJDK update projects want to adopt
> similar labels.
>
> The primary two labels are:
>
> 1. jdk8u-needs-review
>
>   This label should be added after an RFR is posted for a backport to
>   8u. Please also add a link to the RFR.
>
>   There is now a link to a filter for bugs marked with this label on the
>   8u wiki [1]. Those of you who are 8u reviewers are encouraged to
>   regularly triage this list and help with reviewing work submitted for
>   backport.
>
>   This should avoid RFRs getting lost in mail traffic. You may also
>   notice that if you make a jdk8u-fix-request before there is a
>   completed review, it will be changed to this label.
>
> 2. jdk8u-<username>
>
>   This label is essentially intended to work as a lock on the bug,
>   indicating someone is actively backporting the bug. The intention is
>   to let others know that work is in progress, but is not yet ready for
>   an RFR.
>
>   When using this label, please keep it on the bug for the minimum
>   possible time. Add it when work is actively started and remove it when
>   the change is pushed. It is not intended as an 'I'm interested' label,
>   as with others such as 'redhat-interest', but to avoid multiple people
>   actively working on the same task.
>
>   If the label does seem to be present for a long time, other developers
>   are encouraged to query the developer concerned as to whether they are
>   still active on this bug and to take over the work if there is no
>   response for a prolonged period (>2 weeks).
>
> A further occasionally used label is jdk8u-needs-deps, which
> maintainers may use on occasion to indicate that a bug submitted using
> jdk8u-fix-request needs other fixes to be present before it can be
> considered.
>
> I hope these additional labels prove useful and help in the process
> of completing 8u backports. Feedback is welcome and, again, 8u reviewers
> are encouraged to use the jdk8u-needs-review filter to find reviews
> needing attention.
>
> [0] https://wiki.openjdk.java.net/display/jdk8u/Main
> [1] https://bugs.openjdk.java.net/issues/?filter=39384
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> OpenJDK Package Owner
> 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

From volker.simonis at gmail.com  Thu Aug 27 14:04:21 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 27 Aug 2020 16:04:21 +0200
Subject: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
 the heap sampler
In-Reply-To: <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>
References: <CAF9BGBxpWxqw2FHejUjNH8o8W0WSKs0c=3=GAPxKb-5rJ9nqKw@mail.gmail.com>
 <CAF9BGBzWFXhA91y02hU=TjezTTMPnuucLj5KjzkV3BrNLOnrEQ@mail.gmail.com>
 <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
 <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>
 <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>
Message-ID: <CA+3eh11=wdozsWCDWGfrPThWuh+20-TTj8utFaEEFa3mFy63xQ@mail.gmail.com>

Hi Jc,

you need to record the review thread in the JBS issue, otherwise the
11u maintainers have no chance to know when a change which requires a
review has been reviewed. I've done that now for 8247615 and I can
also sponsor (i.e. push) the downport once it has been approved.

The general rules for 11u downports are described here:
http://openjdk.java.net/projects/jdk-updates/approval.html
http://openjdk.java.net/projects/jdk-updates/approval.html

Notice that the 8u updates project has recently introduced some new
rules which I expect to get adopted for 11u as well:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-August/003640.html

Best regards,
Volker

On Tue, Aug 25, 2020 at 9:58 PM Jean Christophe Beyler
<jcbeyler at google.com> wrote:
>
> Hi all,
>
> Does anybody have time to review this and help push it in per chance? Or am I missing something that I need to do :-) ?
>
> That would be much appreciated!
>
> Thanks again!
> Jc
>
> On Fri, Aug 7, 2020 at 2:24 PM Jean Christophe Beyler <jcbeyler at google.com> wrote:
>>
>> Hi Volker,
>>
>> Sorry for the delay in my answer!
>>
>> First off, thanks for the review! I think I need someone to help push this webrev though and I am not sure if I need a second reviewer. That being said, here is the request with the empty line removed:
>>
>> - The original bug is here: https://bugs.openjdk.java.net/browse/JDK-8247615
>> - The original change is here: https://hg.openjdk.java.net/jdk/jdk/rev/13ec613f9373
>> - The webrev with the new change: http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.03_11/
>> - The changes are not significant, I had just a few issues due to changes that came in between to the ThreadHeapSampler class; the test being new is unchanged
>>
>> Thanks for all your help, let me know if I need another reviewer or if someone can help push it for me!
>>
>> Thanks again,
>> Jc
>>
>>
>> On Wed, Jul 29, 2020 at 2:37 PM Volker Simonis <volker.simonis at gmail.com> wrote:
>>>
>>> Hi Jc,
>>>
>>> the downport looks fine to me except the extra empty line you've
>>> inserted in threadHeapSampler.hpp:
>>>
>>>      _collectors_present = 0;
>>> +
>>> +
>>> +    // Call this after _rnd is initialized to initialize _bytes_until_sample.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: as a general rule of thumb, a RFR for a downport should include
>>> the following:
>>> - a link to the original bug (JBS link)
>>> - a link to the original change (i.e. a link to the Mercurial change
>>> set, not to the original webrev)
>>> - a link to the webrev with the new change
>>> - if your changes to "original change" are significant an explanation
>>> why they are required. A diff in webrev format of the "new change"
>>> against "original change" might be helpful in such a case.
>>>
>>> On Wed, Jul 29, 2020 at 8:09 PM Jean Christophe Beyler
>>> <jcbeyler at google.com> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > Any chance to get a review on this? Did I perhaps missed something?
>>> >
>>> > Thanks again for your help!
>>> > Jc
>>> >
>>> > On Thu, Jul 23, 2020 at 10:43 AM Jean Christophe Beyler <jcbeyler at google.com>
>>> > wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > First time I request a backport so if I am missing anything, please let me
>>> > > know :)
>>> > >
>>> > > I am trying to port this webrev into 11u:
>>> > >
>>> > > Summary:
>>> > > This fixes a sampling bias for the first allocations and ensures that the
>>> > > sampling rate is correct from the start.
>>> > > It is safe to apply as the whole code is protected behind flags and only
>>> > > is used when JVMTI enables the heap monitoring.
>>> > > We added a test that tickles this code on purpose.
>>> > >
>>> > > Porting issues:
>>> > > Finally, the patch does not apply cleanly due to slight differences with
>>> > > the files. This webrev provides the clean to JDK11u:
>>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02_11/
>>> > >
>>> > > - That webrev compiles and tests for HeapMonitor (with the new test) pass:
>>> > >     make run-test
>>> > > TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor"
>>> > >
>>> > > compared to what I submitted to head:
>>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02/
>>> > >
>>> > > Let me know what else I can do or provide!
>>> > >
>>> > > Thanks for all your help,
>>> > > Jc
>>> > >
>>> > > Ps: I sent this email before I subscribed so one is waiting in moderation;
>>> > > if this shows up in double, I apologize :)
>>> > >
>>> >
>>> >
>>> > --
>>> >
>>> > Thanks,
>>> > Jc
>>
>>
>>
>> --
>>
>> Thanks,
>> Jc
>
>
>
> --
>
> Thanks,
> Jc

From aph at redhat.com  Thu Aug 27 15:25:16 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 27 Aug 2020 16:25:16 +0100
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>

Hi,

On 27/08/2020 11:04, Doerr, Martin wrote:
>
>> Why is anyone backporting a P4 Enhancement? Seems weird.

> This is a good question in general. Personally, I'd vote for
> backporting fewer less important things to 11u in the future. We
> should better focus on 17 IMHO.
>
> However, there are some arguments for backporting this one:
> - Oracle has done so. There may be more backports in this area and
> I'd expect less effort if we have the same code in the open version.
> - Performance is supposed to be better. (Though I didn't measure it.)
> - New code is much cleaner. Let's keep in mind that we have to
> support it for quite a while.
>
> Are you ok with it?

I'm unsure. While "Oracle has backported it" has been a slam-dunk
justification for many patches, I am concerned about the destabilizing
effect of the volume of patches we are processing.

"Better performance" is not in itself justification for a backport
unless the improvement is really compelling.

"Cleanups" are a red flag. The miserable history of code that has been
broken by seemingly innocuous cleanups is long. This is a big change
that affects some very delicate code, but the fact that there is
already a GraalVM patch we can use is quite persuasive.

So I'm not refusing it, I want people's opinions.

-- 
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 sgehwolf at redhat.com  Thu Aug 27 15:59:32 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 27 Aug 2020 17:59:32 +0200
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
Message-ID: <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>

On Thu, 2020-08-27 at 16:25 +0100, Andrew Haley wrote:
> Hi,
> 
> On 27/08/2020 11:04, Doerr, Martin wrote:
> > > Why is anyone backporting a P4 Enhancement? Seems weird.
> > This is a good question in general. Personally, I'd vote for
> > backporting fewer less important things to 11u in the future. We
> > should better focus on 17 IMHO.
> > 
> > However, there are some arguments for backporting this one:
> > - Oracle has done so. There may be more backports in this area and
> > I'd expect less effort if we have the same code in the open version.
> > - Performance is supposed to be better. (Though I didn't measure it.)
> > - New code is much cleaner. Let's keep in mind that we have to
> > support it for quite a while.
> > 
> > Are you ok with it?
> 
> I'm unsure. While "Oracle has backported it" has been a slam-dunk
> justification for many patches, I am concerned about the destabilizing
> effect of the volume of patches we are processing.
> 
> "Better performance" is not in itself justification for a backport
> unless the improvement is really compelling.
> 
> "Cleanups" are a red flag. The miserable history of code that has been
> broken by seemingly innocuous cleanups is long. This is a big change
> that affects some very delicate code, but the fact that there is
> already a GraalVM patch we can use is quite persuasive.
> 
> So I'm not refusing it, I want people's opinions.

It seems like a nice-to-have fix for OpenJDK 11 itself. Interest seems
to be coming from Graal. Until there is a more compelling reason to
backport this (other than performance for some JVMCI impl) we shouldn't
backport this. We already have a label for these: jdk11u-jvmci-defer.
We should apply that and re-evaluate later if needed.

My $0.02

Thanks,
Severin


From sgehwolf at redhat.com  Thu Aug 27 16:03:44 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 27 Aug 2020 18:03:44 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
Message-ID: <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>

On Thu, 2020-08-27 at 15:45 +0200, Volker Simonis wrote:
> I'd personally welcome the use of the new tags in 11u.

Personally, I've got no strong feeling about this. If it's helpful for
some, feel free to use them.

Thanks,
Severin

> Best regards,
> Volker
> 
> On Fri, Aug 21, 2020 at 9:11 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
> > Hi all,
> > 
> > I've begun using a number of labels to help with 8u backport work,
> > that are documented as part of the OpenJDK 8u contribution process
> > [0]. As few people seem to have noted those additions, I thought it
> > worth an e-mail with more details. I'm also CCing jdk-updates-dev in
> > case maintainers on other OpenJDK update projects want to adopt
> > similar labels.
> > 
> > The primary two labels are:
> > 
> > 1. jdk8u-needs-review
> > 
> >   This label should be added after an RFR is posted for a backport to
> >   8u. Please also add a link to the RFR.
> > 
> >   There is now a link to a filter for bugs marked with this label on the
> >   8u wiki [1]. Those of you who are 8u reviewers are encouraged to
> >   regularly triage this list and help with reviewing work submitted for
> >   backport.
> > 
> >   This should avoid RFRs getting lost in mail traffic. You may also
> >   notice that if you make a jdk8u-fix-request before there is a
> >   completed review, it will be changed to this label.
> > 
> > 2. jdk8u-<username>
> > 
> >   This label is essentially intended to work as a lock on the bug,
> >   indicating someone is actively backporting the bug. The intention is
> >   to let others know that work is in progress, but is not yet ready for
> >   an RFR.
> > 
> >   When using this label, please keep it on the bug for the minimum
> >   possible time. Add it when work is actively started and remove it when
> >   the change is pushed. It is not intended as an 'I'm interested' label,
> >   as with others such as 'redhat-interest', but to avoid multiple people
> >   actively working on the same task.
> > 
> >   If the label does seem to be present for a long time, other developers
> >   are encouraged to query the developer concerned as to whether they are
> >   still active on this bug and to take over the work if there is no
> >   response for a prolonged period (>2 weeks).
> > 
> > A further occasionally used label is jdk8u-needs-deps, which
> > maintainers may use on occasion to indicate that a bug submitted using
> > jdk8u-fix-request needs other fixes to be present before it can be
> > considered.
> > 
> > I hope these additional labels prove useful and help in the process
> > of completing 8u backports. Feedback is welcome and, again, 8u reviewers
> > are encouraged to use the jdk8u-needs-review filter to find reviews
> > needing attention.
> > 
> > [0] https://wiki.openjdk.java.net/display/jdk8u/Main
> > [1] https://bugs.openjdk.java.net/issues/?filter=39384
> > 
> > Thanks,
> > --
> > Andrew :)
> > 
> > Senior Free Java Software Engineer
> > OpenJDK Package Owner
> > 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


From christoph.langer at sap.com  Thu Aug 27 16:10:15 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Aug 2020 16:10:15 +0000
Subject: Additional Labels for Backport Work
In-Reply-To: <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
Message-ID: <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>

+1

I think the labels are a good way to get things sorted.

Regarding "Locking an item for working on it", I was encouraging people to add some comment. But a label doesn't seem bad as well.

I can create the jdk11u-needs-review filter and update the documentation in the 11 Wiki to align with 8u, if nobody opposes. Will wait a bit for feedback, though ??

Cheers
Christoph

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Donnerstag, 27. August 2020 18:04
> To: Volker Simonis <volker.simonis at gmail.com>; Andrew Hughes
> <gnu.andrew at redhat.com>; Andrew Haley <aph at redhat.com>; Langer,
> Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: Re: Additional Labels for Backport Work
> 
> On Thu, 2020-08-27 at 15:45 +0200, Volker Simonis wrote:
> > I'd personally welcome the use of the new tags in 11u.
> 
> Personally, I've got no strong feeling about this. If it's helpful for
> some, feel free to use them.
> 
> Thanks,
> Severin
> 
> > Best regards,
> > Volker
> >
> > On Fri, Aug 21, 2020 at 9:11 PM Andrew Hughes
> <gnu.andrew at redhat.com> wrote:
> > > Hi all,
> > >
> > > I've begun using a number of labels to help with 8u backport work,
> > > that are documented as part of the OpenJDK 8u contribution process
> > > [0]. As few people seem to have noted those additions, I thought it
> > > worth an e-mail with more details. I'm also CCing jdk-updates-dev in
> > > case maintainers on other OpenJDK update projects want to adopt
> > > similar labels.
> > >
> > > The primary two labels are:
> > >
> > > 1. jdk8u-needs-review
> > >
> > >   This label should be added after an RFR is posted for a backport to
> > >   8u. Please also add a link to the RFR.
> > >
> > >   There is now a link to a filter for bugs marked with this label on the
> > >   8u wiki [1]. Those of you who are 8u reviewers are encouraged to
> > >   regularly triage this list and help with reviewing work submitted for
> > >   backport.
> > >
> > >   This should avoid RFRs getting lost in mail traffic. You may also
> > >   notice that if you make a jdk8u-fix-request before there is a
> > >   completed review, it will be changed to this label.
> > >
> > > 2. jdk8u-<username>
> > >
> > >   This label is essentially intended to work as a lock on the bug,
> > >   indicating someone is actively backporting the bug. The intention is
> > >   to let others know that work is in progress, but is not yet ready for
> > >   an RFR.
> > >
> > >   When using this label, please keep it on the bug for the minimum
> > >   possible time. Add it when work is actively started and remove it when
> > >   the change is pushed. It is not intended as an 'I'm interested' label,
> > >   as with others such as 'redhat-interest', but to avoid multiple people
> > >   actively working on the same task.
> > >
> > >   If the label does seem to be present for a long time, other developers
> > >   are encouraged to query the developer concerned as to whether they
> are
> > >   still active on this bug and to take over the work if there is no
> > >   response for a prolonged period (>2 weeks).
> > >
> > > A further occasionally used label is jdk8u-needs-deps, which
> > > maintainers may use on occasion to indicate that a bug submitted using
> > > jdk8u-fix-request needs other fixes to be present before it can be
> > > considered.
> > >
> > > I hope these additional labels prove useful and help in the process
> > > of completing 8u backports. Feedback is welcome and, again, 8u
> reviewers
> > > are encouraged to use the jdk8u-needs-review filter to find reviews
> > > needing attention.
> > >
> > > [0] https://wiki.openjdk.java.net/display/jdk8u/Main
> > > [1] https://bugs.openjdk.java.net/issues/?filter=39384
> > >
> > > Thanks,
> > > --
> > > Andrew :)
> > >
> > > Senior Free Java Software Engineer
> > > OpenJDK Package Owner
> > > 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


From christoph.langer at sap.com  Thu Aug 27 16:21:04 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Aug 2020 16:21:04 +0000
Subject: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
 the heap sampler
In-Reply-To: <CA+3eh11=wdozsWCDWGfrPThWuh+20-TTj8utFaEEFa3mFy63xQ@mail.gmail.com>
References: <CAF9BGBxpWxqw2FHejUjNH8o8W0WSKs0c=3=GAPxKb-5rJ9nqKw@mail.gmail.com>
 <CAF9BGBzWFXhA91y02hU=TjezTTMPnuucLj5KjzkV3BrNLOnrEQ@mail.gmail.com>
 <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
 <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>
 <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>
 <CA+3eh11=wdozsWCDWGfrPThWuh+20-TTj8utFaEEFa3mFy63xQ@mail.gmail.com>
Message-ID: <AM4PR02MB313894E32693DFB7D5DE07BE8A550@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi JC,

I've approved the backport now.

Cheers
Christoph

PS: Your mails to jdk-updates-dev still don't make it into my inbox, while Martin's mails now arrive. Maybe you should sync up with him about his mail settings ??

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Volker Simonis
> Sent: Donnerstag, 27. August 2020 16:04
> To: Jean Christophe Beyler <jcbeyler at google.com>
> Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: Re: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
> the heap sampler
> 
> Hi Jc,
> 
> you need to record the review thread in the JBS issue, otherwise the
> 11u maintainers have no chance to know when a change which requires a
> review has been reviewed. I've done that now for 8247615 and I can
> also sponsor (i.e. push) the downport once it has been approved.
> 
> The general rules for 11u downports are described here:
> http://openjdk.java.net/projects/jdk-updates/approval.html
> http://openjdk.java.net/projects/jdk-updates/approval.html
> 
> Notice that the 8u updates project has recently introduced some new
> rules which I expect to get adopted for 11u as well:
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> August/003640.html
> 
> Best regards,
> Volker
> 
> On Tue, Aug 25, 2020 at 9:58 PM Jean Christophe Beyler
> <jcbeyler at google.com> wrote:
> >
> > Hi all,
> >
> > Does anybody have time to review this and help push it in per chance? Or
> am I missing something that I need to do :-) ?
> >
> > That would be much appreciated!
> >
> > Thanks again!
> > Jc
> >
> > On Fri, Aug 7, 2020 at 2:24 PM Jean Christophe Beyler
> <jcbeyler at google.com> wrote:
> >>
> >> Hi Volker,
> >>
> >> Sorry for the delay in my answer!
> >>
> >> First off, thanks for the review! I think I need someone to help push this
> webrev though and I am not sure if I need a second reviewer. That being
> said, here is the request with the empty line removed:
> >>
> >> - The original bug is here: https://bugs.openjdk.java.net/browse/JDK-
> 8247615
> >> - The original change is here:
> https://hg.openjdk.java.net/jdk/jdk/rev/13ec613f9373
> >> - The webrev with the new change:
> http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.03_11/
> >> - The changes are not significant, I had just a few issues due to changes
> that came in between to the ThreadHeapSampler class; the test being new is
> unchanged
> >>
> >> Thanks for all your help, let me know if I need another reviewer or if
> someone can help push it for me!
> >>
> >> Thanks again,
> >> Jc
> >>
> >>
> >> On Wed, Jul 29, 2020 at 2:37 PM Volker Simonis
> <volker.simonis at gmail.com> wrote:
> >>>
> >>> Hi Jc,
> >>>
> >>> the downport looks fine to me except the extra empty line you've
> >>> inserted in threadHeapSampler.hpp:
> >>>
> >>>      _collectors_present = 0;
> >>> +
> >>> +
> >>> +    // Call this after _rnd is initialized to initialize _bytes_until_sample.
> >>>
> >>> Thank you and best regards,
> >>> Volker
> >>>
> >>> PS: as a general rule of thumb, a RFR for a downport should include
> >>> the following:
> >>> - a link to the original bug (JBS link)
> >>> - a link to the original change (i.e. a link to the Mercurial change
> >>> set, not to the original webrev)
> >>> - a link to the webrev with the new change
> >>> - if your changes to "original change" are significant an explanation
> >>> why they are required. A diff in webrev format of the "new change"
> >>> against "original change" might be helpful in such a case.
> >>>
> >>> On Wed, Jul 29, 2020 at 8:09 PM Jean Christophe Beyler
> >>> <jcbeyler at google.com> wrote:
> >>> >
> >>> > Hi all,
> >>> >
> >>> > Any chance to get a review on this? Did I perhaps missed something?
> >>> >
> >>> > Thanks again for your help!
> >>> > Jc
> >>> >
> >>> > On Thu, Jul 23, 2020 at 10:43 AM Jean Christophe Beyler
> <jcbeyler at google.com>
> >>> > wrote:
> >>> >
> >>> > > Hi all,
> >>> > >
> >>> > > First time I request a backport so if I am missing anything, please let
> me
> >>> > > know :)
> >>> > >
> >>> > > I am trying to port this webrev into 11u:
> >>> > >
> >>> > > Summary:
> >>> > > This fixes a sampling bias for the first allocations and ensures that the
> >>> > > sampling rate is correct from the start.
> >>> > > It is safe to apply as the whole code is protected behind flags and
> only
> >>> > > is used when JVMTI enables the heap monitoring.
> >>> > > We added a test that tickles this code on purpose.
> >>> > >
> >>> > > Porting issues:
> >>> > > Finally, the patch does not apply cleanly due to slight differences
> with
> >>> > > the files. This webrev provides the clean to JDK11u:
> >>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02_11/
> >>> > >
> >>> > > - That webrev compiles and tests for HeapMonitor (with the new
> test) pass:
> >>> > >     make run-test
> >>> > > TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor"
> >>> > >
> >>> > > compared to what I submitted to head:
> >>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02/
> >>> > >
> >>> > > Let me know what else I can do or provide!
> >>> > >
> >>> > > Thanks for all your help,
> >>> > > Jc
> >>> > >
> >>> > > Ps: I sent this email before I subscribed so one is waiting in
> moderation;
> >>> > > if this shows up in double, I apologize :)
> >>> > >
> >>> >
> >>> >
> >>> > --
> >>> >
> >>> > Thanks,
> >>> > Jc
> >>
> >>
> >>
> >> --
> >>
> >> Thanks,
> >> Jc
> >
> >
> >
> > --
> >
> > Thanks,
> > Jc

From neugens at redhat.com  Thu Aug 27 16:48:46 2020
From: neugens at redhat.com (Mario Torre)
Date: Thu, 27 Aug 2020 18:48:46 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>

On Thu, Aug 27, 2020 at 6:11 PM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> +1
>
> I think the labels are a good way to get things sorted.
>
> Regarding "Locking an item for working on it", I was encouraging people to add some comment. But a label doesn't seem bad as well.

After a brief discussion today, it occurred to me that we can create
backport bugs manually and assign them directly, wouldn't this be a
better approach to track who is working on a specific backport?

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 jesper.wilhelmsson at oracle.com  Thu Aug 27 19:54:40 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 27 Aug 2020 21:54:40 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
Message-ID: <5ED78A4A-7B4A-4B7E-BF6D-E260DA6A8CED@oracle.com>

> On 27 Aug 2020, at 18:48, Mario Torre <neugens at redhat.com> wrote:
> 
> On Thu, Aug 27, 2020 at 6:11 PM Langer, Christoph
> <christoph.langer at sap.com> wrote:
>> 
>> +1
>> 
>> I think the labels are a good way to get things sorted.
>> 
>> Regarding "Locking an item for working on it", I was encouraging people to add some comment. But a label doesn't seem bad as well.
> 
> After a brief discussion today, it occurred to me that we can create
> backport bugs manually and assign them directly, wouldn't this be a
> better approach to track who is working on a specific backport?

As I read through this thread I was thinking the same thing. Why not use the facilities already in place in JBS instead of reinventing things?

The needs-review label don't have any counterpart in JBS, so as long as it's maintained (labels are removed once the review is done) this can be a good use of labels. I would suggest to put the label on the backport issue and use the same label ("needs-review") for all releases. (Queries would then look at fixVersion as well.) Reducing the number of different labels makes it easier to write verification queries to make sure things are well in JBS. A verification query for this could for instance check that there are no closed issues with the needs-review label. That query wouldn't have to be updated as new releases come and go.

Assigning issues are done using the assignee field and the correct way to do this is as Mario writes to create the backport issue and assign it to the engineer.

Dependencies between bugs are expressed using links ("blocks" etc). The "other fixes" that an issue is blocked by should have their own JBS issues and therefore using links would be the natural way to express this relationship.

/Jesper


> 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 mbalao at redhat.com  Thu Aug 27 19:58:28 2020
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 27 Aug 2020 16:58:28 -0300
Subject: Additional Labels for Backport Work
In-Reply-To: <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
Message-ID: <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>

On 8/27/20 1:48 PM, Mario Torre wrote:
> After a brief discussion today, it occurred to me that we can create
> backport bugs manually and assign them directly, wouldn't this be a
> better approach to track who is working on a specific backport?

Yes, I thought about this idea some time ago and discussing with Andrew
(@gnu_andrew) he raised a valid concern: end-up with lots of backport
bug duplicates when those manually created are not automatically
resolved when pushing the fix -and new ones being created-. We would
need to know exactly how to manually create bugs that are then resolved
when pushing. But then we need to rely on everybody getting it right.
I've seen duplicates already when manually creating backport bugs for CSRs.


From jesper.wilhelmsson at oracle.com  Thu Aug 27 20:03:48 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 27 Aug 2020 22:03:48 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
 <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>
Message-ID: <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>

> On 27 Aug 2020, at 21:58, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 8/27/20 1:48 PM, Mario Torre wrote:
>> After a brief discussion today, it occurred to me that we can create
>> backport bugs manually and assign them directly, wouldn't this be a
>> better approach to track who is working on a specific backport?
> 
> Yes, I thought about this idea some time ago and discussing with Andrew
> (@gnu_andrew) he raised a valid concern: end-up with lots of backport
> bug duplicates when those manually created are not automatically
> resolved when pushing the fix -and new ones being created-. We would
> need to know exactly how to manually create bugs that are then resolved
> when pushing. But then we need to rely on everybody getting it right.
> I've seen duplicates already when manually creating backport bugs for CSRs.

For an 8u backport set the fixVersion to 8-pool to have hg updater resolve the issue. This should be standard practice for all bugs/backports in update releases. Always set fixVersion to X-pool unless you know for sure what release you need it to go into and are requesting that the fix should be included in the release in the rampdown phase.

/Jesper


From mbalao at redhat.com  Thu Aug 27 19:59:45 2020
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 27 Aug 2020 16:59:45 -0300
Subject: Additional Labels for Backport Work
In-Reply-To: <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <abc28a6f-0996-1ef2-f4b5-080d6fbf5c73@redhat.com>

On 8/27/20 1:10 PM, Langer, Christoph wrote:
> Regarding "Locking an item for working on it", I was encouraging people to add some comment. But a label doesn't seem bad as well.

The label is a more 'normalized' way and easier to look up in my view,
when compared to comments.


From jesper.wilhelmsson at oracle.com  Thu Aug 27 20:05:53 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 27 Aug 2020 22:05:53 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
 <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>
 <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>
Message-ID: <D562BB53-60FA-4B34-B4ED-19A3691BBA1D@oracle.com>

> On 27 Aug 2020, at 22:03, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> 
>> On 27 Aug 2020, at 21:58, Martin Balao <mbalao at redhat.com> wrote:
>> 
>> On 8/27/20 1:48 PM, Mario Torre wrote:
>>> After a brief discussion today, it occurred to me that we can create
>>> backport bugs manually and assign them directly, wouldn't this be a
>>> better approach to track who is working on a specific backport?
>> 
>> Yes, I thought about this idea some time ago and discussing with Andrew
>> (@gnu_andrew) he raised a valid concern: end-up with lots of backport
>> bug duplicates when those manually created are not automatically
>> resolved when pushing the fix -and new ones being created-. We would
>> need to know exactly how to manually create bugs that are then resolved
>> when pushing. But then we need to rely on everybody getting it right.
>> I've seen duplicates already when manually creating backport bugs for CSRs.
> 
> For an 8u backport set the fixVersion to 8-pool to have hg updater resolve the issue. This should be standard practice for all bugs/backports in update releases. Always set fixVersion to X-pool unless you know for sure what release you need it to go into and are requesting that the fix should be included in the release in the rampdown phase.
> 
> /Jesper

Btw. I'd be happy to include some documentation around this in the OpenJDK Developers' Guide once it's settled how to do things.
/Jesper


From mbalao at redhat.com  Thu Aug 27 21:28:49 2020
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 27 Aug 2020 18:28:49 -0300
Subject: Additional Labels for Backport Work
In-Reply-To: <D562BB53-60FA-4B34-B4ED-19A3691BBA1D@oracle.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
 <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>
 <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>
 <D562BB53-60FA-4B34-B4ED-19A3691BBA1D@oracle.com>
Message-ID: <c0456a9f-c193-b7d9-93f4-e57028f8447c@redhat.com>

On 8/27/20 5:05 PM, Jesper Wilhelmsson wrote:
> Btw. I'd be happy to include some documentation around this in the OpenJDK Developers' Guide once it's settled how to do things.
> /Jesper
> 

Very helpful indeed, thanks.


From christoph.langer at sap.com  Thu Aug 27 21:43:08 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Aug 2020 21:43:08 +0000
Subject: Additional Labels for Backport Work
In-Reply-To: <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
 <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>
 <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>
Message-ID: <AM4PR02MB3138AFF12B00F977EEAEFAE48A550@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

> For an 8u backport set the fixVersion to 8-pool to have hg updater resolve
> the issue. This should be standard practice for all bugs/backports in update
> releases. Always set fixVersion to X-pool unless you know for sure what
> release you need it to go into and are requesting that the fix should be
> included in the release in the rampdown phase.

One thing to add here: Unfortunately 8-pool doesn't work for openjdk8* releases. I think there's still an issue in hgupdater.  It works for, e.g. 11-pool.

I also think that using manually created backport bugs will lead to quite some orphans... In most cases it's better to let hgupdater create the backport bug at the time of pushing.

/Christoph


From christoph.langer at sap.com  Thu Aug 27 21:53:19 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Aug 2020 21:53:19 +0000
Subject: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
 compatibility
In-Reply-To: <201149B7-A7E1-4F92-8580-9D23D856DB70@amazon.com>
References: <201149B7-A7E1-4F92-8580-9D23D856DB70@amazon.com>
Message-ID: <AM4PR02MB3138B7B8062868A067DBFBF88A550@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Paul,

looks correct and quite important, I'd say - needs to go into 11.0.9. Approved for 11u.

You should probably update the copyright years in the files as it's a new change.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Hohensee, Paul
> Sent: Dienstag, 25. August 2020 13:49
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
> compatibility
> 
> Thank you Volker. Issue tagged.
> 
> Paul
> 
> ?On 8/25/20, 3:45 AM, "Volker Simonis" <volker.simonis at gmail.com> wrote:
> 
>     Hi Paul,
> 
>     Thanks for catching and fixing this.
>     Your changes look right and pretty trivial to me.
>     Thumbs up from my side.
> 
>     Best regards,
>     Volker
> 
>     On Mon, Aug 24, 2020 at 8:23 PM Hohensee, Paul
> <hohensee at amazon.com> wrote:
>     >
>     > Passed:
>     >
>     > test/jdk/java/lang/management/ThreadMXBean
>     > test/jdk/com/sun/management/ThreadMXBean
>     > test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean
>     >
>     > On 8/21/20, 1:42 PM, "jdk-updates-dev on behalf of Hohensee, Paul"
> <jdk-updates-dev-retn at openjdk.java.net on behalf of
> hohensee at amazon.com> wrote:
>     >
>     >     Please review a small binary compatibility fix that applies only to 11u.
>     >
>     >     Bug: https://bugs.openjdk.java.net/browse/JDK-8252157
>     >     Webrev: http://cr.openjdk.java.net/~phh/8252157/webrev.00/
>     >
>     >     Thanks,
>     >     Paul
>     >
>     >


From christoph.langer at sap.com  Thu Aug 27 22:00:20 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Aug 2020 22:00:20 +0000
Subject: [11u] RFR (XS) 8210131:
 vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java
 failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected
 error code
In-Reply-To: <fd9288a7-b78c-10ef-eae0-e54491a985ff@redhat.com>
References: <fd9288a7-b78c-10ef-eae0-e54491a985ff@redhat.com>
Message-ID: <AM4PR02MB313881E563DF5DCAF339B1768A550@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Aleksey,

sure, looks good ??

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Donnerstag, 27. August 2020 10:51
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR (XS) 8210131:
> vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.
> java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned
> unexpected error code
> 
> Hi,
> 
> I have already got the approval for this push to 11u, but when checking the
> patch queue, I realized
> the patch does not apply cleanly, because there is a problem list change from
> a subtask:
>    http://hg.openjdk.java.net/jdk/jdk/rev/0cd55d573893
> 
> The problem list addition does not apply cleanly by itself. So for this backport,
> I opt to drop the
> problem list addition and removal.
> 
> Upstream version:
>     http://hg.openjdk.java.net/jdk/jdk/rev/53e61697a020
> 
> 11u version omits the problem list hunk:
> 
> diff -r 29196ae99fe5 src/hotspot/share/prims/jvmtiEnter.xsl
> --- a/src/hotspot/share/prims/jvmtiEnter.xsl    Mon May 25 11:05:23 2020
> +0200
> +++ b/src/hotspot/share/prims/jvmtiEnter.xsl    Thu Aug 27 10:49:15 2020
> +0200
> @@ -403,11 +403,11 @@
>         <xsl:text>if (this_thread == NULL || !this_thread->is_Java_thread())
> {</xsl:text>
>       </xsl:when>
>       <xsl:otherwise>
>         <xsl:choose>
>           <xsl:when test="count(@phase)=0 or contains(@phase,'live') or
> contains(@phase,'start')">
> -         <xsl:text>if (this_thread == NULL || (!this_thread->is_Java_thread()
> &amp;&amp;
> !this_thread->is_VM_thread())) {</xsl:text>
> +         <xsl:text>if (this_thread == NULL || (!this_thread->is_Java_thread()
> &amp;&amp;
> !this_thread->is_Named_thread())) {</xsl:text>
>           </xsl:when>
>           <xsl:otherwise>
>             <xsl:text>if (!this_thread->is_Java_thread()) {</xsl:text>
>           </xsl:otherwise>
>         </xsl:choose>
> 
> Any concerns?
> 
> --
> Thanks,
> -Aleksey


From hohensee at amazon.com  Fri Aug 28 00:11:29 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 28 Aug 2020 00:11:29 +0000
Subject: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
 compatibility
Message-ID: <7EC43FFE-D5E1-4726-842E-158DA06C8992@amazon.com>

Thanks, Christoph. Done, and pushed.

?On 8/27/20, 2:54 PM, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi Paul,

    looks correct and quite important, I'd say - needs to go into 11.0.9. Approved for 11u.

    You should probably update the copyright years in the files as it's a new change.

    Cheers
    Christoph

    > -----Original Message-----
    > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
    > Behalf Of Hohensee, Paul
    > Sent: Dienstag, 25. August 2020 13:49
    > To: Volker Simonis <volker.simonis at gmail.com>
    > Cc: jdk-updates-dev at openjdk.java.net
    > Subject: RE: RFR (XS): 8252157: JDK-8231209 11u backport breaks jmm binary
    > compatibility
    >
    > Thank you Volker. Issue tagged.
    >
    > Paul
    >
    > On 8/25/20, 3:45 AM, "Volker Simonis" <volker.simonis at gmail.com> wrote:
    >
    >     Hi Paul,
    >
    >     Thanks for catching and fixing this.
    >     Your changes look right and pretty trivial to me.
    >     Thumbs up from my side.
    >
    >     Best regards,
    >     Volker
    >
    >     On Mon, Aug 24, 2020 at 8:23 PM Hohensee, Paul
    > <hohensee at amazon.com> wrote:
    >     >
    >     > Passed:
    >     >
    >     > test/jdk/java/lang/management/ThreadMXBean
    >     > test/jdk/com/sun/management/ThreadMXBean
    >     > test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean
    >     >
    >     > On 8/21/20, 1:42 PM, "jdk-updates-dev on behalf of Hohensee, Paul"
    > <jdk-updates-dev-retn at openjdk.java.net on behalf of
    > hohensee at amazon.com> wrote:
    >     >
    >     >     Please review a small binary compatibility fix that applies only to 11u.
    >     >
    >     >     Bug: https://bugs.openjdk.java.net/browse/JDK-8252157
    >     >     Webrev: http://cr.openjdk.java.net/~phh/8252157/webrev.00/
    >     >
    >     >     Thanks,
    >     >     Paul
    >     >
    >     >



From yasuenag at gmail.com  Fri Aug 28 00:54:59 2020
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 28 Aug 2020 09:54:59 +0900
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS
Message-ID: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>

Hi all,

Please approve backport of JDK-8250598:

    JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
    Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924
    webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/jdk11u/webrev.00/

The patch does not apply cleanly on 11u due to additional enhancements to x86 / x86_64 processors.
So I've prepared another webrev for 11u.


Thanks,

Yasumasa

From matthias.baesken at sap.com  Fri Aug 28 07:22:27 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 28 Aug 2020 07:22:27 +0000
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
 host OS
In-Reply-To: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>
References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>
Message-ID: <AM0PR02MB54120CE54E9B2B3FDA13B67693520@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hi Yasumasa ,I suggest to let the  change  "rest"  in  jdk/jdk for  a couple of weeks  before  going for downports .
(not saying that downporting it is a bad thing) 

Best regards, Matthias

-----Original Message-----
From: Yasumasa Suenaga <yasuenag at gmail.com> 
Sent: Freitag, 28. August 2020 02:55
To: jdk-updates-dev at openjdk.java.net
Cc: Baesken, Matthias <matthias.baesken at sap.com>
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS

Hi all,

Please approve backport of JDK-8250598:

    JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
    Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924
    webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/jdk11u/webrev.00/

The patch does not apply cleanly on 11u due to additional enhancements to x86 / x86_64 processors.
So I've prepared another webrev for 11u.


Thanks,

Yasumasa

From christoph.goettschkes at microdoc.com  Fri Aug 28 07:34:36 2020
From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=)
Date: Fri, 28 Aug 2020 09:34:36 +0200
Subject: [11u] 8234535: Cross compilation fails due to missing CFLAGS for the
 BUILD_CC
Message-ID: <336wbng61p-1@userp2050.oracle.com>

Hi,

I requested the backport of 8234535 to 11u and it has been approved. 
Since I don't have commit access, could someone please sponsor this 
changeset for me? The backport required small modifications, please find 
the patch which applies cleanly to 11u-dev in the webrev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8234535
Original Commit: https://hg.openjdk.java.net/jdk/jdk/rev/eef0bf57357c
Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/

Thanks,
Christoph


From suenaga at oss.nttdata.com  Fri Aug 28 08:01:45 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Fri, 28 Aug 2020 17:01:45 +0900
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
 host OS
In-Reply-To: <AM0PR02MB54120CE54E9B2B3FDA13B67693520@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>
 <AM0PR02MB54120CE54E9B2B3FDA13B67693520@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com>

Hi Matthias,

On 2020/08/28 16:22, Baesken, Matthias wrote:
> Hi Yasumasa ,I suggest to let the  change  "rest"  in  jdk/jdk for  a couple of weeks  before  going for downports .
> (not saying that downporting it is a bad thing)

I understand what you say, but I want to backport it to 11.0.9 if possible.
11.0.9 will enter rampdown in 1 Sep...


Thanks,

Yasumasa


> Best regards, Matthias
> 
> -----Original Message-----
> From: Yasumasa Suenaga <yasuenag at gmail.com>
> Sent: Freitag, 28. August 2020 02:55
> To: jdk-updates-dev at openjdk.java.net
> Cc: Baesken, Matthias <matthias.baesken at sap.com>
> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS
> 
> Hi all,
> 
> Please approve backport of JDK-8250598:
> 
>      JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
>      Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924
>      webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/jdk11u/webrev.00/
> 
> The patch does not apply cleanly on 11u due to additional enhancements to x86 / x86_64 processors.
> So I've prepared another webrev for 11u.
> 
> 
> Thanks,
> 
> Yasumasa
> 

From goetz.lindenmaier at sap.com  Fri Aug 28 08:57:07 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 28 Aug 2020 08:57:07 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
Message-ID: <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

I'd prefer to push this.
I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
Unfortunately there is nobody in the open community to address this.
And there are enough other changes OpenJDK 11 lacks wrt. 11-oracle.
If this gap grows big, we can no more claim OpenJDK 11 is a valid replacement
for the Oracle vm. 

So I would continue to try to take all changes that go to 11-oracle
to OpenJDK 11, too.

And as this is now ported to 11, let's push it.
Anyways, it also affects C1 and other shared code, so it might
simplify integrating follow-ups.

Best regards,
  Goetz.


> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Thursday, August 27, 2020 6:00 PM
> To: Andrew Haley <aph at redhat.com>; Doerr, Martin
> <martin.doerr at sap.com>; 'hotspot-compiler-dev at openjdk.java.net'
> <hotspot-compiler-dev at openjdk.java.net>; jdk-updates-
> dev at openjdk.java.net
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> On Thu, 2020-08-27 at 16:25 +0100, Andrew Haley wrote:
> > Hi,
> >
> > On 27/08/2020 11:04, Doerr, Martin wrote:
> > > > Why is anyone backporting a P4 Enhancement? Seems weird.
> > > This is a good question in general. Personally, I'd vote for
> > > backporting fewer less important things to 11u in the future. We
> > > should better focus on 17 IMHO.
> > >
> > > However, there are some arguments for backporting this one:
> > > - Oracle has done so. There may be more backports in this area and
> > > I'd expect less effort if we have the same code in the open version.
> > > - Performance is supposed to be better. (Though I didn't measure it.)
> > > - New code is much cleaner. Let's keep in mind that we have to
> > > support it for quite a while.
> > >
> > > Are you ok with it?
> >
> > I'm unsure. While "Oracle has backported it" has been a slam-dunk
> > justification for many patches, I am concerned about the destabilizing
> > effect of the volume of patches we are processing.
> >
> > "Better performance" is not in itself justification for a backport
> > unless the improvement is really compelling.
> >
> > "Cleanups" are a red flag. The miserable history of code that has been
> > broken by seemingly innocuous cleanups is long. This is a big change
> > that affects some very delicate code, but the fact that there is
> > already a GraalVM patch we can use is quite persuasive.
> >
> > So I'm not refusing it, I want people's opinions.
> 
> It seems like a nice-to-have fix for OpenJDK 11 itself. Interest seems
> to be coming from Graal. Until there is a more compelling reason to
> backport this (other than performance for some JVMCI impl) we shouldn't
> backport this. We already have a label for these: jdk11u-jvmci-defer.
> We should apply that and re-evaluate later if needed.
> 
> My $0.02
> 
> Thanks,
> Severin


From neugens at redhat.com  Fri Aug 28 09:27:01 2020
From: neugens at redhat.com (Mario Torre)
Date: Fri, 28 Aug 2020 11:27:01 +0200
Subject: Additional Labels for Backport Work
In-Reply-To: <AM4PR02MB3138AFF12B00F977EEAEFAE48A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <20200821190945.GD31221@stopbrexit>
 <CA+3eh13KhQVdcW7-4obibCbKT_-49YFoa1VGo7pfkpHZiR6-Mg@mail.gmail.com>
 <d494de11cadee7043bc81ab5b658e34ac2ea825f.camel@redhat.com>
 <AM4PR02MB3138775EABCA580EDBD3C8108A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <CAJwKKmZh5dRjX8vNvapzc_dqDQmsj55hto=D56Yyra+svfUKLw@mail.gmail.com>
 <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com>
 <CDBDF926-7ED5-4225-850A-71DF6D30FD56@oracle.com>
 <AM4PR02MB3138AFF12B00F977EEAEFAE48A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <CAJwKKmaEVa+Ad1LWdJyMfwMdqW8Eu9bNC9BFnXi_fVHX4BZwCg@mail.gmail.com>

On Thu, Aug 27, 2020 at 11:45 PM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi,
>
> > For an 8u backport set the fixVersion to 8-pool to have hg updater resolve
> > the issue. This should be standard practice for all bugs/backports in update
> > releases. Always set fixVersion to X-pool unless you know for sure what
> > release you need it to go into and are requesting that the fix should be
> > included in the release in the rampdown phase.
>
> One thing to add here: Unfortunately 8-pool doesn't work for openjdk8* releases. I think there's still an issue in hgupdater.  It works for, e.g. 11-pool.


The problem is that it is usually difficult to organise work by just
the labeling system, especially with this quite high rate of bugs
we're backporting (incidentally, do we really need all of them?), I'm
often unsure what I should do myself and in more than a few instances
I found out that someone what working on the same backport just after
the facts.

The new labels Andrew proposes may mitigate this, but directly
assigning a bug to someone is a better and more scalable way, imho.

> I also think that using manually created backport bugs will lead to quite some orphans... In most cases it's better to let hgupdater create the backport bug at the time of pushing.

We could fix hgupdater to do what we need I think, it shouldn't be
much of a problem. Also, what do you mean by "will lead to quite some
orphans", as in bugs getting duplicated because the updated creates an
automatic backport bug and then only one fixed? Again, in that case we
could adapt hgupdater to not create bugs, but 8-pool/11-pool trick
does make sense to me (more than the labels).

It may also obsolete all those weird labels like "redhat-interest" or
"amazon-interest" etc.. that I always found quite... ehm, interesting?
:)

I have the impression we are using labels because we're hacking around
the process, but we could make the process just a bit more fluent.


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 volker.simonis at gmail.com  Fri Aug 28 09:49:10 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 28 Aug 2020 11:49:10 +0200
Subject: RFR (11u, S): backport JDK-8247615 Initialize the bytes left for
 the heap sampler
In-Reply-To: <AM4PR02MB313894E32693DFB7D5DE07BE8A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <CAF9BGBxpWxqw2FHejUjNH8o8W0WSKs0c=3=GAPxKb-5rJ9nqKw@mail.gmail.com>
 <CAF9BGBzWFXhA91y02hU=TjezTTMPnuucLj5KjzkV3BrNLOnrEQ@mail.gmail.com>
 <CA+3eh129PWz1_WrGz-fG_qr_y9-1Wpx0ZtrfXeXCdch-+Bg2Pw@mail.gmail.com>
 <CAF9BGByphQTbMGe0jP8VK7mq=B9mHh2oQLQh8wt1ikGx4AgaFQ@mail.gmail.com>
 <CAF9BGBwyfJocM5u8apiddJEx9w1eaQRDVuXET+WnnLFGOniDfA@mail.gmail.com>
 <CA+3eh11=wdozsWCDWGfrPThWuh+20-TTj8utFaEEFa3mFy63xQ@mail.gmail.com>
 <AM4PR02MB313894E32693DFB7D5DE07BE8A550@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <CA+3eh13KYcrRDOGgCfzb--og3ZJcdJrj0VzDidNuDZqO8pXbaA@mail.gmail.com>

Thanks Christoph!

Pushed.


On Thu, Aug 27, 2020 at 6:21 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi JC,
>
> I've approved the backport now.
>
> Cheers
> Christoph
>
> PS: Your mails to jdk-updates-dev still don't make it into my inbox, while
> Martin's mails now arrive. Maybe you should sync up with him about his mail
> settings ??
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Volker Simonis
> > Sent: Donnerstag, 27. August 2020 16:04
> > To: Jean Christophe Beyler <jcbeyler at google.com>
> > Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: Re: RFR (11u, S): backport JDK-8247615 Initialize the bytes
> left for
> > the heap sampler
> >
> > Hi Jc,
> >
> > you need to record the review thread in the JBS issue, otherwise the
> > 11u maintainers have no chance to know when a change which requires a
> > review has been reviewed. I've done that now for 8247615 and I can
> > also sponsor (i.e. push) the downport once it has been approved.
> >
> > The general rules for 11u downports are described here:
> > http://openjdk.java.net/projects/jdk-updates/approval.html
> > http://openjdk.java.net/projects/jdk-updates/approval.html
> >
> > Notice that the 8u updates project has recently introduced some new
> > rules which I expect to get adopted for 11u as well:
> > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> > August/003640.html
> >
> > Best regards,
> > Volker
> >
> > On Tue, Aug 25, 2020 at 9:58 PM Jean Christophe Beyler
> > <jcbeyler at google.com> wrote:
> > >
> > > Hi all,
> > >
> > > Does anybody have time to review this and help push it in per chance?
> Or
> > am I missing something that I need to do :-) ?
> > >
> > > That would be much appreciated!
> > >
> > > Thanks again!
> > > Jc
> > >
> > > On Fri, Aug 7, 2020 at 2:24 PM Jean Christophe Beyler
> > <jcbeyler at google.com> wrote:
> > >>
> > >> Hi Volker,
> > >>
> > >> Sorry for the delay in my answer!
> > >>
> > >> First off, thanks for the review! I think I need someone to help push
> this
> > webrev though and I am not sure if I need a second reviewer. That being
> > said, here is the request with the empty line removed:
> > >>
> > >> - The original bug is here: https://bugs.openjdk.java.net/browse/JDK-
> > 8247615
> > >> - The original change is here:
> > https://hg.openjdk.java.net/jdk/jdk/rev/13ec613f9373
> > >> - The webrev with the new change:
> > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.03_11/
> > >> - The changes are not significant, I had just a few issues due to
> changes
> > that came in between to the ThreadHeapSampler class; the test being new
> is
> > unchanged
> > >>
> > >> Thanks for all your help, let me know if I need another reviewer or if
> > someone can help push it for me!
> > >>
> > >> Thanks again,
> > >> Jc
> > >>
> > >>
> > >> On Wed, Jul 29, 2020 at 2:37 PM Volker Simonis
> > <volker.simonis at gmail.com> wrote:
> > >>>
> > >>> Hi Jc,
> > >>>
> > >>> the downport looks fine to me except the extra empty line you've
> > >>> inserted in threadHeapSampler.hpp:
> > >>>
> > >>>      _collectors_present = 0;
> > >>> +
> > >>> +
> > >>> +    // Call this after _rnd is initialized to initialize
> _bytes_until_sample.
> > >>>
> > >>> Thank you and best regards,
> > >>> Volker
> > >>>
> > >>> PS: as a general rule of thumb, a RFR for a downport should include
> > >>> the following:
> > >>> - a link to the original bug (JBS link)
> > >>> - a link to the original change (i.e. a link to the Mercurial change
> > >>> set, not to the original webrev)
> > >>> - a link to the webrev with the new change
> > >>> - if your changes to "original change" are significant an explanation
> > >>> why they are required. A diff in webrev format of the "new change"
> > >>> against "original change" might be helpful in such a case.
> > >>>
> > >>> On Wed, Jul 29, 2020 at 8:09 PM Jean Christophe Beyler
> > >>> <jcbeyler at google.com> wrote:
> > >>> >
> > >>> > Hi all,
> > >>> >
> > >>> > Any chance to get a review on this? Did I perhaps missed something?
> > >>> >
> > >>> > Thanks again for your help!
> > >>> > Jc
> > >>> >
> > >>> > On Thu, Jul 23, 2020 at 10:43 AM Jean Christophe Beyler
> > <jcbeyler at google.com>
> > >>> > wrote:
> > >>> >
> > >>> > > Hi all,
> > >>> > >
> > >>> > > First time I request a backport so if I am missing anything,
> please let
> > me
> > >>> > > know :)
> > >>> > >
> > >>> > > I am trying to port this webrev into 11u:
> > >>> > >
> > >>> > > Summary:
> > >>> > > This fixes a sampling bias for the first allocations and ensures
> that the
> > >>> > > sampling rate is correct from the start.
> > >>> > > It is safe to apply as the whole code is protected behind flags
> and
> > only
> > >>> > > is used when JVMTI enables the heap monitoring.
> > >>> > > We added a test that tickles this code on purpose.
> > >>> > >
> > >>> > > Porting issues:
> > >>> > > Finally, the patch does not apply cleanly due to slight
> differences
> > with
> > >>> > > the files. This webrev provides the clean to JDK11u:
> > >>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02_11/
> > >>> > >
> > >>> > > - That webrev compiles and tests for HeapMonitor (with the new
> > test) pass:
> > >>> > >     make run-test
> > >>> > > TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor"
> > >>> > >
> > >>> > > compared to what I submitted to head:
> > >>> > > http://cr.openjdk.java.net/~jcbeyler/8247615/webrev.02/
> > >>> > >
> > >>> > > Let me know what else I can do or provide!
> > >>> > >
> > >>> > > Thanks for all your help,
> > >>> > > Jc
> > >>> > >
> > >>> > > Ps: I sent this email before I subscribed so one is waiting in
> > moderation;
> > >>> > > if this shows up in double, I apologize :)
> > >>> > >
> > >>> >
> > >>> >
> > >>> > --
> > >>> >
> > >>> > Thanks,
> > >>> > Jc
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Thanks,
> > >> Jc
> > >
> > >
> > >
> > > --
> > >
> > > Thanks,
> > > Jc
>

From gouessej at orange.fr  Fri Aug 28 10:34:33 2020
From: gouessej at orange.fr (gouessej at orange.fr)
Date: Fri, 28 Aug 2020 12:34:33 +0200 (CEST)
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <778219306.3426.1598610873510.JavaMail.www@wwinf1p10>

Please can you elaborate about " there are enough other changes OpenJDK 11 lacks wrt. 11-oracle"?

?

?

> Message du 28/08/20 11:03
> De : "Lindenmaier, Goetz" 
> A : "'Severin Gehwolf'" , "Andrew Haley" , "Doerr, Martin" , "'hotspot-compiler-dev at openjdk.java.net'" , "jdk-updates-dev at openjdk.java.net" 
> Copie ? : 
> Objet : RE: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> Hi,
> 
> I'd prefer to push this.
> I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
> Unfortunately there is nobody in the open community to address this.
> And there are enough other changes OpenJDK 11 lacks wrt. 11-oracle.
> If this gap grows big, we can no more claim OpenJDK 11 is a valid replacement
> for the Oracle vm. 
> 
> So I would continue to try to take all changes that go to 11-oracle
> to OpenJDK 11, too.
> 
> And as this is now ported to 11, let's push it.
> Anyways, it also affects C1 and other shared code, so it might
> simplify integrating follow-ups.
> 
> Best regards,
> Goetz.
> 
> 
> > -----Original Message-----
> > From: Severin Gehwolf 
> > Sent: Thursday, August 27, 2020 6:00 PM
> > To: Andrew Haley ; Doerr, Martin
> > ; 'hotspot-compiler-dev at openjdk.java.net'
> > ; jdk-updates-
> > dev at openjdk.java.net
> > Cc: Lindenmaier, Goetz 
> > Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> > 
> > On Thu, 2020-08-27 at 16:25 +0100, Andrew Haley wrote:
> > > Hi,
> > >
> > > On 27/08/2020 11:04, Doerr, Martin wrote:
> > > > > Why is anyone backporting a P4 Enhancement? Seems weird.
> > > > This is a good question in general. Personally, I'd vote for
> > > > backporting fewer less important things to 11u in the future. We
> > > > should better focus on 17 IMHO.
> > > >
> > > > However, there are some arguments for backporting this one:
> > > > - Oracle has done so. There may be more backports in this area and
> > > > I'd expect less effort if we have the same code in the open version.
> > > > - Performance is supposed to be better. (Though I didn't measure it.)
> > > > - New code is much cleaner. Let's keep in mind that we have to
> > > > support it for quite a while.
> > > >
> > > > Are you ok with it?
> > >
> > > I'm unsure. While "Oracle has backported it" has been a slam-dunk
> > > justification for many patches, I am concerned about the destabilizing
> > > effect of the volume of patches we are processing.
> > >
> > > "Better performance" is not in itself justification for a backport
> > > unless the improvement is really compelling.
> > >
> > > "Cleanups" are a red flag. The miserable history of code that has been
> > > broken by seemingly innocuous cleanups is long. This is a big change
> > > that affects some very delicate code, but the fact that there is
> > > already a GraalVM patch we can use is quite persuasive.
> > >
> > > So I'm not refusing it, I want people's opinions.
> > 
> > It seems like a nice-to-have fix for OpenJDK 11 itself. Interest seems
> > to be coming from Graal. Until there is a more compelling reason to
> > backport this (other than performance for some JVMCI impl) we shouldn't
> > backport this. We already have a label for these: jdk11u-jvmci-defer.
> > We should apply that and re-evaluate later if needed.
> > 
> > My $0.02
> > 
> > Thanks,
> > Severin
> 
>

From goetz.lindenmaier at sap.com  Fri Aug 28 11:48:13 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 28 Aug 2020 11:48:13 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <778219306.3426.1598610873510.JavaMail.www@wwinf1p10>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <778219306.3426.1598610873510.JavaMail.www@wwinf1p10>
Message-ID: <AM4PR0202MB296461E5BB190751F2164E6EEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

There are queries for this on the jdk11 project page:
https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

e.g.
https://bugs.openjdk.java.net/issues/?filter=39054

Best regards,
 Goetz.

From: gouessej at orange.fr <gouessej at orange.fr>
Sent: Friday, August 28, 2020 12:35 PM
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; 'Severin Gehwolf' <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: RE: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.


Please can you elaborate about " there are enough other changes OpenJDK 11 lacks wrt. 11-oracle"?




> Message du 28/08/20 11:03
> De : "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
> A : "'Severin Gehwolf'" <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>, "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "Doerr, Martin" <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>, "'hotspot-compiler-dev at openjdk.java.net'" <hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>>, "jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>" <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Copie ? :
> Objet : RE: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
>
> Hi,
>
> I'd prefer to push this.
> I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
> Unfortunately there is nobody in the open community to address this.
> And there are enough other changes OpenJDK 11 lacks wrt. 11-oracle.
> If this gap grows big, we can no more claim OpenJDK 11 is a valid replacement
> for the Oracle vm.
>
> So I would continue to try to take all changes that go to 11-oracle
> to OpenJDK 11, too.
>
> And as this is now ported to 11, let's push it.
> Anyways, it also affects C1 and other shared code, so it might
> simplify integrating follow-ups.
>
> Best regards,
> Goetz.
>
>
> > -----Original Message-----
> > From: Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>
> > Sent: Thursday, August 27, 2020 6:00 PM
> > To: Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; Doerr, Martin
> > <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>; 'hotspot-compiler-dev at openjdk.java.net'
> > <hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>>; jdk-updates-
> > dev at openjdk.java.net<mailto:dev at openjdk.java.net>
> > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
> > Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> >
> > On Thu, 2020-08-27 at 16:25 +0100, Andrew Haley wrote:
> > > Hi,
> > >
> > > On 27/08/2020 11:04, Doerr, Martin wrote:
> > > > > Why is anyone backporting a P4 Enhancement? Seems weird.
> > > > This is a good question in general. Personally, I'd vote for
> > > > backporting fewer less important things to 11u in the future. We
> > > > should better focus on 17 IMHO.
> > > >
> > > > However, there are some arguments for backporting this one:
> > > > - Oracle has done so. There may be more backports in this area and
> > > > I'd expect less effort if we have the same code in the open version.
> > > > - Performance is supposed to be better. (Though I didn't measure it.)
> > > > - New code is much cleaner. Let's keep in mind that we have to
> > > > support it for quite a while.
> > > >
> > > > Are you ok with it?
> > >
> > > I'm unsure. While "Oracle has backported it" has been a slam-dunk
> > > justification for many patches, I am concerned about the destabilizing
> > > effect of the volume of patches we are processing.
> > >
> > > "Better performance" is not in itself justification for a backport
> > > unless the improvement is really compelling.
> > >
> > > "Cleanups" are a red flag. The miserable history of code that has been
> > > broken by seemingly innocuous cleanups is long. This is a big change
> > > that affects some very delicate code, but the fact that there is
> > > already a GraalVM patch we can use is quite persuasive.
> > >
> > > So I'm not refusing it, I want people's opinions.
> >
> > It seems like a nice-to-have fix for OpenJDK 11 itself. Interest seems
> > to be coming from Graal. Until there is a more compelling reason to
> > backport this (other than performance for some JVMCI impl) we shouldn't
> > backport this. We already have a label for these: jdk11u-jvmci-defer.
> > We should apply that and re-evaluate later if needed.
> >
> > My $0.02
> >
> > Thanks,
> > Severin
>
>

From aph at redhat.com  Fri Aug 28 12:52:18 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 28 Aug 2020 13:52:18 +0100
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>

On 28/08/2020 09:57, Lindenmaier, Goetz wrote:
> I'd prefer to push this.
> I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
> Unfortunately there is nobody in the open community to address this.
> And there are enough other changes OpenJDK 11 lacks wrt. 11-oracle.
> If this gap grows big, we can no more claim OpenJDK 11 is a valid replacement
> for the Oracle vm. 

What JVMCI issue is this? Please explain. All that I see is a faster
"slow" locking path for monitors.

> So I would continue to try to take all changes that go to 11-oracle
> to OpenJDK 11, too.
> 
> And as this is now ported to 11, let's push it.
> Anyways, it also affects C1 and other shared code, so it might
> simplify integrating follow-ups.

That is not a good reason for backporting.

-- 
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  Fri Aug 28 13:11:57 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 28 Aug 2020 13:11:57 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>
Message-ID: <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Andrew, 

> > I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue. 
> What JVMCI issue is this? Please explain. All that I see is a faster
> "slow" locking path for monitors.

This was meant as a more general comment. I wanted to 
address that we don't integrate many of the JVMCI changes
so the OpenJDK 11 is probably not usable with graal.
The comment was not tailored to this specific change.
Unfortunately our team has not the capacity to look at 
JVMCI/graal.  

Best regards,
  Goetz.



From sgehwolf at redhat.com  Fri Aug 28 13:30:51 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 28 Aug 2020 15:30:51 +0200
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>
 <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <a830b11033ff3c80769f740535ad8ece222e03e7.camel@redhat.com>

On Fri, 2020-08-28 at 13:11 +0000, Lindenmaier, Goetz wrote:
> I wanted to address that we don't integrate many of the JVMCI changes
> so the OpenJDK 11 is probably not usable with graal.

https://github.com/graalvm/mandrel#how-does-mandrel-differ-from-graal

Thanks,
Severin


From christoph.langer at sap.com  Fri Aug 28 14:28:18 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 28 Aug 2020 14:28:18 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB31385F39C53121D3AD8EE4B38A520@AM4PR02MB3138.eurprd02.prod.outlook.com>

Ping...

I still need reviews for the 11u backport of this change.

Thanks
Christoph

From: Langer, Christoph
Sent: Dienstag, 11. August 2020 17:52
To: jdk-updates-dev at openjdk.java.net
Cc: Osipov, Michael <michael.osipov at siemens.com>
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider

Hi,

I've been working on backporting JDK- 8160768: "Add capability to custom resolve host/domain names within the default JNDI LDAP provider" to OpenJDK 11u. This seems to be quite an important enhancement for usage in more complex LDAP setups so there is a certain demand for this backport. Oracle has backported it to their JDK8 and 11 releases already.

Backporting is not so trivial, though, as the original change introduced a new package with two classes in the javax namespace: javax.naming.ldap.spi with classes LdapDnsProvider and LdapDnsProviderResult. To facilitate backporting without having to change the spec, this backport creates package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide the new service interface. So people wanting to leverage the feature in a JDK < 12 will have to build against the com.sun.jndi.ldap.spi implementation. Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from module java.naming as this is not allowed for a module in the java namespace. So I introduced a new module jdk.naming.ldap for being able to export the new service interface. The service is hooked into java.naming's class LdapCtxFactory by reflective lookup of class com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its initialization. This in turn will register the LdapDnsProviderServiceInternal singleton for accessing com.sun.jndi.ldap.spi service implementations from java.naming. If a JDK was jlink'ed without module jdk.naming.ldap, the missing LdapDnsProvider facility would then just be ignored quietly.

In my backport I also include the adaptations to the test from the already backported change of JDK-8139965 to improve test stability.

I had to create a backport CSR as well for which I'd also need a review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/

Thanks in advance for looking at this.

Best regards
Christoph


From goetz.lindenmaier at sap.com  Fri Aug 28 14:30:32 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 28 Aug 2020 14:30:32 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <a830b11033ff3c80769f740535ad8ece222e03e7.camel@redhat.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>
 <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <a830b11033ff3c80769f740535ad8ece222e03e7.camel@redhat.com>
Message-ID: <AM4PR0202MB29649FD48737BA6C907E9C01EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>

That's cool. So it works ??
They would probably profit from '8241234: Unify monitor enter/exit runtime entries."

Best regards,
 Goetz.

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Friday, August 28, 2020 3:31 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; 'Andrew Haley'
> <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; 'hotspot-
> compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>;
> jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> On Fri, 2020-08-28 at 13:11 +0000, Lindenmaier, Goetz wrote:
> > I wanted to address that we don't integrate many of the JVMCI changes
> > so the OpenJDK 11 is probably not usable with graal.
> 
> https://github.com/graalvm/mandrel#how-does-mandrel-differ-from-graal
> 
> Thanks,
> Severin


From aph at redhat.com  Fri Aug 28 14:35:39 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 28 Aug 2020 15:35:39 +0100
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>
 <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <f5c01810-52f7-7030-fe3d-a91e488711a7@redhat.com>

Hi,

On 28/08/2020 14:11, Lindenmaier, Goetz wrote:
>
>>> I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
>> What JVMCI issue is this? Please explain. All that I see is a faster
>> "slow" locking path for monitors.
>
> This was meant as a more general comment. I wanted to address that
> we don't integrate many of the JVMCI changes so the OpenJDK 11 is
> probably not usable with graal.  The comment was not tailored to
> this specific change.  Unfortunately our team has not the capacity
> to look at JVMCI/graal.

Fair enough.

Now, let's think about the wider point.

Any change is bad because our users want, above all else,
stability. So first we should avoid change.

In order to justify any change, I want backport patches to have a real
justification. That is to say, they must have a real effect on a Java
user's experience.  Fixing visible bugs obviously qualifies, as does a
significant performance bump, as does meeting a new crypto
specification, etc, etc.

The other good reason is improved stability, which includes better
testing.

A real justification doesn't exclude "cleanups", as long as there is
some other benefit, such as making making a proposed backport
cleaner. But it has to be a backport that we are actually doing, not
some unknown backport that might happen some day.

It may well be that the 8241234 fix has a definite performance
advantage, in which case it might be a reasonable thing to do.
The provided justifications were:

- Oracle has done so. There may be more backports in this area and I'd
  expect less effort if we have the same code in the open version.
- Performance is supposed to be better.
- New code is much cleaner.

But even though the new code is much cleaner, it's a significant
change in a very delicate area. Bugs in this are can take a long time
to reveal themselves, usually under heavy load in a production
situation.

I am not saying no to this patch. I am asking "Are you sure that this
change is worth making the change?" Given that I doubt anyone will
ever notice this change unless it breaks something important, I have
my doubts.

So, anyone: is there any chance that this patch will break something?
Is this change worth the churn?

-- 
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  Fri Aug 28 15:14:46 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 28 Aug 2020 15:14:46 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB296423947E0ABCE66D6E6C24EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Christoph, 

You just pinged for a review, but I was looking at it anyways.

I think this looks good. The basic functionality is the same, 
you added functionality to access LdapDnsProviderService
without having it in the same module. 
Our jck tests are green with the change as you implemented it.

One nit, I think the comment here is too complicated, maybe
shorten the sentences a bit?
http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java.html

  34  * It is implemented by jdk.naming.ldap and the singleton instance is registered
  35  * in LdapCtxFactory to which provides access to the service mechanism
  36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
--> 
  34  * It is implemented by jdk.naming.ldap. LdapDnsProviderService. A singleton instance is registered
  35  * in LdapCtxFactory. This singleton provides access to the service mechanism
  36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf
> Of Langer, Christoph
> Sent: Tuesday, August 11, 2020 5:52 PM
> To: jdk-updates-dev at openjdk.java.net
> Cc: Osipov, Michael <michael.osipov at siemens.com>
> Subject: [CAUTION] RFR [11u]: 8160768: Add capability to custom resolve
> host/domain names within the default JNDI LDAP provider
> 
> Hi,
> 
> I've been working on backporting JDK- 8160768: "Add capability to custom
> resolve host/domain names within the default JNDI LDAP provider" to
> OpenJDK 11u. This seems to be quite an important enhancement for usage in
> more complex LDAP setups so there is a certain demand for this backport.
> Oracle has backported it to their JDK8 and 11 releases already.
> 
> Backporting is not so trivial, though, as the original change introduced a new
> package with two classes in the javax namespace: javax.naming.ldap.spi with
> classes LdapDnsProvider and LdapDnsProviderResult. To facilitate
> backporting without having to change the spec, this backport creates
> package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide
> the new service interface. So people wanting to leverage the feature in a JDK
> < 12 will have to build against the com.sun.jndi.ldap.spi implementation.
> Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from
> module java.naming as this is not allowed for a module in the java
> namespace. So I introduced a new module jdk.naming.ldap for being able to
> export the new service interface. The service is hooked into java.naming's
> class LdapCtxFactory by reflective lookup of class
> com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its initialization.
> This in turn will register the LdapDnsProviderServiceInternal singleton for
> accessing com.sun.jndi.ldap.spi service implementations from java.naming. If
> a JDK was jlink'ed without module jdk.naming.ldap, the missing
> LdapDnsProvider facility would then just be ignored quietly.
> 
> In my backport I also include the adaptations to the test from the already
> backported change of JDK-8139965 to improve test stability.
> 
> I had to create a backport CSR as well for which I'd also need a review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/
> 
> Thanks in advance for looking at this.
> 
> Best regards
> Christoph


From martin.doerr at sap.com  Fri Aug 28 16:19:35 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 28 Aug 2020 16:19:35 +0000
Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
In-Reply-To: <f5c01810-52f7-7030-fe3d-a91e488711a7@redhat.com>
References: <AM4PR02MB305739FDFF38E9432F27E7969A5F0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <fdb47a78-5b0e-f013-b5fc-7c9fcdf0cf2c@redhat.com>
 <AM4PR02MB30575C819AFC52A4F10127689A550@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com>
 <bafa778e83b01e497052778e58174b87d31d9f7e.camel@redhat.com>
 <AM4PR0202MB2964850BBDECC859BB802A77EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com>
 <AM4PR0202MB29645C3C9B82F82C8C72943CEC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <f5c01810-52f7-7030-fe3d-a91e488711a7@redhat.com>
Message-ID: <AM4PR02MB3057716FA68F210C14C5BFA69A520@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

seems like two different philosophies collide here.

1. Some people assume that all of Oracle's 11u changes should get integrated into the open version.
2. Others only want to take them on demand with a good reason.

I think there are good arguments for and against both ones.
Personally, I think approach 1. is better at the beginning of an updates branch while it may be reasonable to switch at some point of time.
At the moment, I still prefer to stay in sync with Oracle as far as we can.

Regarding this change, I don't see a high risk.
What it basically does is that it reuses better code which is already used by C2 for C1 and JVMCI compilers. So there's no substantial new code.
It's tested by GraalVM and by our internal testing. There are no known issues with it.

So I'd rather vote for taking it.

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Freitag, 28. August 2020 16:36
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; 'Severin Gehwolf'
> <sgehwolf at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; 'hotspot-
> compiler-dev at openjdk.java.net' <hotspot-compiler-
> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> Hi,
> 
> On 28/08/2020 14:11, Lindenmaier, Goetz wrote:
> >
> >>> I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
> >> What JVMCI issue is this? Please explain. All that I see is a faster
> >> "slow" locking path for monitors.
> >
> > This was meant as a more general comment. I wanted to address that
> > we don't integrate many of the JVMCI changes so the OpenJDK 11 is
> > probably not usable with graal.  The comment was not tailored to
> > this specific change.  Unfortunately our team has not the capacity
> > to look at JVMCI/graal.
> 
> Fair enough.
> 
> Now, let's think about the wider point.
> 
> Any change is bad because our users want, above all else,
> stability. So first we should avoid change.
> 
> In order to justify any change, I want backport patches to have a real
> justification. That is to say, they must have a real effect on a Java
> user's experience.  Fixing visible bugs obviously qualifies, as does a
> significant performance bump, as does meeting a new crypto
> specification, etc, etc.
> 
> The other good reason is improved stability, which includes better
> testing.
> 
> A real justification doesn't exclude "cleanups", as long as there is
> some other benefit, such as making making a proposed backport
> cleaner. But it has to be a backport that we are actually doing, not
> some unknown backport that might happen some day.
> 
> It may well be that the 8241234 fix has a definite performance
> advantage, in which case it might be a reasonable thing to do.
> The provided justifications were:
> 
> - Oracle has done so. There may be more backports in this area and I'd
>   expect less effort if we have the same code in the open version.
> - Performance is supposed to be better.
> - New code is much cleaner.
> 
> But even though the new code is much cleaner, it's a significant
> change in a very delicate area. Bugs in this are can take a long time
> to reveal themselves, usually under heavy load in a production
> situation.
> 
> I am not saying no to this patch. I am asking "Are you sure that this
> change is worth making the change?" Given that I doubt anyone will
> ever notice this change unless it breaks something important, I have
> my doubts.
> 
> So, anyone: is there any chance that this patch will break something?
> Is this change worth the churn?
> 
> --
> 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  Sat Aug 29 09:07:20 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 29 Aug 2020 09:07:20 +0000
Subject: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
Message-ID: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

please review this downport for parity with Oracle.
http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/01

In 11, the update from jquery 3.3.1 to 3.4.1 is missing.
Therefore the change does not apply.
Also, a change renaming the /jquery/ directory is missing 
in 11, another deleting some useless files and finally one
minifying the script. 

So I basically crafted the change anew:
 * I renamed jquery-3.3.1.js to jquery-3.5.1.js and replaced
   it by the new file.
 * I updated all the files referencing the file with the version in the name.
 * In addition, I updated APITest.java because else these test are failing.
 * I replaced jquery.js by the new file (jquery.js was deleted in jdk/jdk).
 * I omitted the minified version as 8236823 is not in 11.

Our tests are all green.

Best regards,
  Goetz.

Here all the related changes:

https://bugs.openjdk.java.net/browse/JDK-8204666 : javadoc should be updated to use jQuery 3.3.1
https://bugs.openjdk.java.net/browse/JDK-8221644 : jquery directory should be renamed
https://bugs.openjdk.java.net/browse/JDK-8222548 : Upgrading JDK 13 with the latest available jQuery 3.4.1
https://bugs.openjdk.java.net/browse/JDK-8238167 : Remove stray files from jdk.javadoc
https://bugs.openjdk.java.net/browse/JDK-8236823 : Ensure that API documentation uses minified libraries
https://bugs.openjdk.java.net/browse/JDK-8245981 : Upgrade to jQuery 3.5.1

From christoph.langer at sap.com  Mon Aug 31 08:05:17 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 08:05:17 +0000
Subject: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
In-Reply-To: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB313820F1E192DD54D94152978A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Goetz,

generally, your approach and patch look fine to me.

However, looking at the intermediate step of migrating from 3.3.1 to 3.4.1 which was missed out in OpenJDK11 so far (https://bugs.openjdk.java.net/browse/JDK-8222548), I can see that jquery-migrate-3.0.1.js was removed there. I think this part should be incorporated into this backport as well.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Samstag, 29. August 2020 11:07
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi,
> 
> please review this downport for parity with Oracle.
> http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/01
> 
> In 11, the update from jquery 3.3.1 to 3.4.1 is missing.
> Therefore the change does not apply.
> Also, a change renaming the /jquery/ directory is missing
> in 11, another deleting some useless files and finally one
> minifying the script.
> 
> So I basically crafted the change anew:
>  * I renamed jquery-3.3.1.js to jquery-3.5.1.js and replaced
>    it by the new file.
>  * I updated all the files referencing the file with the version in the name.
>  * In addition, I updated APITest.java because else these test are failing.
>  * I replaced jquery.js by the new file (jquery.js was deleted in jdk/jdk).
>  * I omitted the minified version as 8236823 is not in 11.
> 
> Our tests are all green.
> 
> Best regards,
>   Goetz.
> 
> Here all the related changes:
> 
> https://bugs.openjdk.java.net/browse/JDK-8204666 : javadoc should be
> updated to use jQuery 3.3.1
> https://bugs.openjdk.java.net/browse/JDK-8221644 : jquery directory
> should be renamed
> https://bugs.openjdk.java.net/browse/JDK-8222548 : Upgrading JDK 13 with
> the latest available jQuery 3.4.1
> https://bugs.openjdk.java.net/browse/JDK-8238167 : Remove stray files
> from jdk.javadoc
> https://bugs.openjdk.java.net/browse/JDK-8236823 : Ensure that API
> documentation uses minified libraries
> https://bugs.openjdk.java.net/browse/JDK-8245981 : Upgrade to jQuery
> 3.5.1

From christoph.langer at sap.com  Mon Aug 31 09:18:09 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 09:18:09 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AM4PR0202MB296423947E0ABCE66D6E6C24EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296423947E0ABCE66D6E6C24EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB313858B12225ED55301BFA968A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Goetz,

thanks for your review.

I tried to address your concerns regarding the class comment for java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java and it's hopefully a bit easier to read and understand now:
http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.1/

Ok for you?

Thanks
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Freitag, 28. August 2020 17:15
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: Osipov, Michael <michael.osipov at siemens.com>
> Subject: RE: RFR [11u]: 8160768: Add capability to custom resolve
> host/domain names within the default JNDI LDAP provider
> 
> Hi Christoph,
> 
> You just pinged for a review, but I was looking at it anyways.
> 
> I think this looks good. The basic functionality is the same,
> you added functionality to access LdapDnsProviderService
> without having it in the same module.
> Our jck tests are green with the change as you implemented it.
> 
> One nit, I think the comment here is too complicated, maybe
> shorten the sentences a bit?
> http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/src/java.namin
> g/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java.ht
> ml
> 
>   34  * It is implemented by jdk.naming.ldap and the singleton instance is
> registered
>   35  * in LdapCtxFactory to which provides access to the service mechanism
>   36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
> -->
>   34  * It is implemented by jdk.naming.ldap. LdapDnsProviderService. A
> singleton instance is registered
>   35  * in LdapCtxFactory. This singleton provides access to the service
> mechanism
>   36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf
> > Of Langer, Christoph
> > Sent: Tuesday, August 11, 2020 5:52 PM
> > To: jdk-updates-dev at openjdk.java.net
> > Cc: Osipov, Michael <michael.osipov at siemens.com>
> > Subject: [CAUTION] RFR [11u]: 8160768: Add capability to custom resolve
> > host/domain names within the default JNDI LDAP provider
> >
> > Hi,
> >
> > I've been working on backporting JDK- 8160768: "Add capability to custom
> > resolve host/domain names within the default JNDI LDAP provider" to
> > OpenJDK 11u. This seems to be quite an important enhancement for usage
> in
> > more complex LDAP setups so there is a certain demand for this backport.
> > Oracle has backported it to their JDK8 and 11 releases already.
> >
> > Backporting is not so trivial, though, as the original change introduced a
> new
> > package with two classes in the javax namespace: javax.naming.ldap.spi
> with
> > classes LdapDnsProvider and LdapDnsProviderResult. To facilitate
> > backporting without having to change the spec, this backport creates
> > package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide
> > the new service interface. So people wanting to leverage the feature in a
> JDK
> > < 12 will have to build against the com.sun.jndi.ldap.spi implementation.
> > Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from
> > module java.naming as this is not allowed for a module in the java
> > namespace. So I introduced a new module jdk.naming.ldap for being able
> to
> > export the new service interface. The service is hooked into java.naming's
> > class LdapCtxFactory by reflective lookup of class
> > com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its
> initialization.
> > This in turn will register the LdapDnsProviderServiceInternal singleton for
> > accessing com.sun.jndi.ldap.spi service implementations from java.naming.
> If
> > a JDK was jlink'ed without module jdk.naming.ldap, the missing
> > LdapDnsProvider facility would then just be ignored quietly.
> >
> > In my backport I also include the adaptations to the test from the already
> > backported change of JDK-8139965 to improve test stability.
> >
> > I had to create a backport CSR as well for which I'd also need a review.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
> > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
> > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
> > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/
> >
> > Thanks in advance for looking at this.
> >
> > Best regards
> > Christoph


From christoph.langer at sap.com  Mon Aug 31 09:31:14 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 09:31:14 +0000
Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed
 due to timeout on DeadServerNoTimeoutTest is incorrect
Message-ID: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

may I please have a review for the backport of test fix JDK-8151678 "com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect" as follow-up for JDK-8160768 (Add capability to custom resolve host/domain names within the default JNDI LDAP provider).

Bug: https://bugs.openjdk.java.net/browse/JDK-8151678
Original change: https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.0/

I had the following Rejects:
src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
    needed manual resolve, also copyright year was different
LdapDnsProviderService.java:
    File is in a different location in 11u, so I needed to manually resolve it:
    java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java -> jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderService.java
ProblemList.txt:
    Needed a manual resolve

Thanks
Christoph


From goetz.lindenmaier at sap.com  Mon Aug 31 09:35:19 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 09:35:19 +0000
Subject: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
In-Reply-To: <AM4PR02MB313820F1E192DD54D94152978A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB313820F1E192DD54D94152978A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB296496F99DB92E9D5E98AC50EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

Yes, removing that file is a good idea. New webrev:
http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/02/

Best regards,
  Goetz.

-----Original Message-----
From: Langer, Christoph <christoph.langer at sap.com> 
Sent: Montag, 31. August 2020 10:05
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: jdk-updates-dev at openjdk.java.net
Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1

Hi Goetz,

generally, your approach and patch look fine to me.

However, looking at the intermediate step of migrating from 3.3.1 to 3.4.1 which was missed out in OpenJDK11 so far (https://bugs.openjdk.java.net/browse/JDK-8222548), I can see that jquery-migrate-3.0.1.js was removed there. I think this part should be incorporated into this backport as well.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Samstag, 29. August 2020 11:07
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi,
> 
> please review this downport for parity with Oracle.
> http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/01
> 
> In 11, the update from jquery 3.3.1 to 3.4.1 is missing.
> Therefore the change does not apply.
> Also, a change renaming the /jquery/ directory is missing
> in 11, another deleting some useless files and finally one
> minifying the script.
> 
> So I basically crafted the change anew:
>  * I renamed jquery-3.3.1.js to jquery-3.5.1.js and replaced
>    it by the new file.
>  * I updated all the files referencing the file with the version in the name.
>  * In addition, I updated APITest.java because else these test are failing.
>  * I replaced jquery.js by the new file (jquery.js was deleted in jdk/jdk).
>  * I omitted the minified version as 8236823 is not in 11.
> 
> Our tests are all green.
> 
> Best regards,
>   Goetz.
> 
> Here all the related changes:
> 
> https://bugs.openjdk.java.net/browse/JDK-8204666 : javadoc should be
> updated to use jQuery 3.3.1
> https://bugs.openjdk.java.net/browse/JDK-8221644 : jquery directory
> should be renamed
> https://bugs.openjdk.java.net/browse/JDK-8222548 : Upgrading JDK 13 with
> the latest available jQuery 3.4.1
> https://bugs.openjdk.java.net/browse/JDK-8238167 : Remove stray files
> from jdk.javadoc
> https://bugs.openjdk.java.net/browse/JDK-8236823 : Ensure that API
> documentation uses minified libraries
> https://bugs.openjdk.java.net/browse/JDK-8245981 : Upgrade to jQuery
> 3.5.1

From christoph.langer at sap.com  Mon Aug 31 09:42:13 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 09:42:13 +0000
Subject: [11u] 8234535: Cross compilation fails due to missing CFLAGS for
 the BUILD_CC
In-Reply-To: <336wbng61p-1@userp2050.oracle.com>
References: <336wbng61p-1@userp2050.oracle.com>
Message-ID: <AM4PR02MB3138C1E347B674367C05A9BA8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Christoph,

I'll push it tomorrow after running it once again through our tests.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Christoph G?ttschkes
> Sent: Freitag, 28. August 2020 09:35
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] 8234535: Cross compilation fails due to missing CFLAGS for the
> BUILD_CC
> 
> Hi,
> 
> I requested the backport of 8234535 to 11u and it has been approved.
> Since I don't have commit access, could someone please sponsor this
> changeset for me? The backport required small modifications, please find
> the patch which applies cleanly to 11u-dev in the webrev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234535
> Original Commit: https://hg.openjdk.java.net/jdk/jdk/rev/eef0bf57357c
> Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/
> 
> Thanks,
> Christoph


From christoph.langer at sap.com  Mon Aug 31 10:02:24 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 10:02:24 +0000
Subject: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
In-Reply-To: <AM4PR0202MB296496F99DB92E9D5E98AC50EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB313820F1E192DD54D94152978A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296496F99DB92E9D5E98AC50EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138E9BD238CABA72B89884E8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Goetz,

looks good. You should also remove src/jdk.javadoc/share/legal/jquery-migrate.md as per http://hg.openjdk.java.net/jdk/jdk/rev/4f1f939d8f5d.

Best regards
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 31. August 2020 11:35
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi,
> 
> Yes, removing that file is a good idea. New webrev:
> http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/02/
> 
> Best regards,
>   Goetz.
> 
> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Montag, 31. August 2020 10:05
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi Goetz,
> 
> generally, your approach and patch look fine to me.
> 
> However, looking at the intermediate step of migrating from 3.3.1 to 3.4.1
> which was missed out in OpenJDK11 so far
> (https://bugs.openjdk.java.net/browse/JDK-8222548), I can see that jquery-
> migrate-3.0.1.js was removed there. I think this part should be incorporated
> into this backport as well.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Samstag, 29. August 2020 11:07
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> >
> > Hi,
> >
> > please review this downport for parity with Oracle.
> > http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/01
> >
> > In 11, the update from jquery 3.3.1 to 3.4.1 is missing.
> > Therefore the change does not apply.
> > Also, a change renaming the /jquery/ directory is missing
> > in 11, another deleting some useless files and finally one
> > minifying the script.
> >
> > So I basically crafted the change anew:
> >  * I renamed jquery-3.3.1.js to jquery-3.5.1.js and replaced
> >    it by the new file.
> >  * I updated all the files referencing the file with the version in the name.
> >  * In addition, I updated APITest.java because else these test are failing.
> >  * I replaced jquery.js by the new file (jquery.js was deleted in jdk/jdk).
> >  * I omitted the minified version as 8236823 is not in 11.
> >
> > Our tests are all green.
> >
> > Best regards,
> >   Goetz.
> >
> > Here all the related changes:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8204666 : javadoc should be
> > updated to use jQuery 3.3.1
> > https://bugs.openjdk.java.net/browse/JDK-8221644 : jquery directory
> > should be renamed
> > https://bugs.openjdk.java.net/browse/JDK-8222548 : Upgrading JDK 13
> with
> > the latest available jQuery 3.4.1
> > https://bugs.openjdk.java.net/browse/JDK-8238167 : Remove stray files
> > from jdk.javadoc
> > https://bugs.openjdk.java.net/browse/JDK-8236823 : Ensure that API
> > documentation uses minified libraries
> > https://bugs.openjdk.java.net/browse/JDK-8245981 : Upgrade to jQuery
> > 3.5.1

From christoph.langer at sap.com  Mon Aug 31 10:04:34 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 10:04:34 +0000
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
 host OS
In-Reply-To: <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com>
References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>
 <AM0PR02MB54120CE54E9B2B3FDA13B67693520@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com>
Message-ID: <AM4PR02MB3138FB7DC7A5122A807ABCF38A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Yasumasa,

is there any specific reason why it should be part of 11.0.9?

Without having more detailed knowledge of the matter, I'd say it's cautious enough to postpone this backport to 11.0.10, given that we're about to enter rampdown...

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Yasumasa Suenaga
> Sent: Freitag, 28. August 2020 10:02
> To: Baesken, Matthias <matthias.baesken at sap.com>; Yasumasa Suenaga
> <yasuenag at gmail.com>; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
> host OS
> 
> Hi Matthias,
> 
> On 2020/08/28 16:22, Baesken, Matthias wrote:
> > Hi Yasumasa ,I suggest to let the  change  "rest"  in  jdk/jdk for  a couple of
> weeks  before  going for downports .
> > (not saying that downporting it is a bad thing)
> 
> I understand what you say, but I want to backport it to 11.0.9 if possible.
> 11.0.9 will enter rampdown in 1 Sep...
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> > Best regards, Matthias
> >
> > -----Original Message-----
> > From: Yasumasa Suenaga <yasuenag at gmail.com>
> > Sent: Freitag, 28. August 2020 02:55
> > To: jdk-updates-dev at openjdk.java.net
> > Cc: Baesken, Matthias <matthias.baesken at sap.com>
> > Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host
> OS
> >
> > Hi all,
> >
> > Please approve backport of JDK-8250598:
> >
> >      JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
> >      Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924
> >      webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-
> 8250598/jdk11u/webrev.00/
> >
> > The patch does not apply cleanly on 11u due to additional enhancements to
> x86 / x86_64 processors.
> > So I've prepared another webrev for 11u.
> >
> >
> > Thanks,
> >
> > Yasumasa
> >

From christoph.goettschkes at microdoc.com  Mon Aug 31 10:04:32 2020
From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=)
Date: Mon, 31 Aug 2020 12:04:32 +0200
Subject: [11u] 8234535: Cross compilation fails due to missing CFLAGS for
 the BUILD_CC
In-Reply-To: <AM4PR02MB3138C1E347B674367C05A9BA8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <336wbng61p-1@userp2050.oracle.com>
 <AM4PR02MB3138C1E347B674367C05A9BA8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <337d2fn03q-1@userp2030.oracle.com>

Sure thing, thanks for sponsoring this one.

-- Christoph

On 2020-08-31 11:42, Langer, Christoph wrote:
> Hi Christoph,
> 
> I'll push it tomorrow after running it once again through our tests.
> 
> Cheers
> Christoph
> 
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
>> Behalf Of Christoph G?ttschkes
>> Sent: Freitag, 28. August 2020 09:35
>> To: jdk-updates-dev at openjdk.java.net
>> Subject: [11u] 8234535: Cross compilation fails due to missing CFLAGS for the
>> BUILD_CC
>>
>> Hi,
>>
>> I requested the backport of 8234535 to 11u and it has been approved.
>> Since I don't have commit access, could someone please sponsor this
>> changeset for me? The backport required small modifications, please find
>> the patch which applies cleanly to 11u-dev in the webrev.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234535
>> Original Commit: https://hg.openjdk.java.net/jdk/jdk/rev/eef0bf57357c
>> Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/
>>
>> Thanks,
>> Christoph
> 


From goetz.lindenmaier at sap.com  Mon Aug 31 10:35:24 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 10:35:24 +0000
Subject: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
In-Reply-To: <AM4PR02MB3138E9BD238CABA72B89884E8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB313820F1E192DD54D94152978A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296496F99DB92E9D5E98AC50EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB3138E9BD238CABA72B89884E8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB2964B7CBDBD18E0E4B04B533EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

I tried to remove it before, but somehow this got lost ...
http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/03/

In any case, I'll run the patch through our testing once more.

Best regards,
  Goetz.

-----Original Message-----
From: Langer, Christoph <christoph.langer at sap.com> 
Sent: Montag, 31. August 2020 12:02
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: jdk-updates-dev at openjdk.java.net
Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1

Hi Goetz,

looks good. You should also remove src/jdk.javadoc/share/legal/jquery-migrate.md as per http://hg.openjdk.java.net/jdk/jdk/rev/4f1f939d8f5d.

Best regards
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 31. August 2020 11:35
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi,
> 
> Yes, removing that file is a good idea. New webrev:
> http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/02/
> 
> Best regards,
>   Goetz.
> 
> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Montag, 31. August 2020 10:05
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi Goetz,
> 
> generally, your approach and patch look fine to me.
> 
> However, looking at the intermediate step of migrating from 3.3.1 to 3.4.1
> which was missed out in OpenJDK11 so far
> (https://bugs.openjdk.java.net/browse/JDK-8222548), I can see that jquery-
> migrate-3.0.1.js was removed there. I think this part should be incorporated
> into this backport as well.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Samstag, 29. August 2020 11:07
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> >
> > Hi,
> >
> > please review this downport for parity with Oracle.
> > http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/01
> >
> > In 11, the update from jquery 3.3.1 to 3.4.1 is missing.
> > Therefore the change does not apply.
> > Also, a change renaming the /jquery/ directory is missing
> > in 11, another deleting some useless files and finally one
> > minifying the script.
> >
> > So I basically crafted the change anew:
> >  * I renamed jquery-3.3.1.js to jquery-3.5.1.js and replaced
> >    it by the new file.
> >  * I updated all the files referencing the file with the version in the name.
> >  * In addition, I updated APITest.java because else these test are failing.
> >  * I replaced jquery.js by the new file (jquery.js was deleted in jdk/jdk).
> >  * I omitted the minified version as 8236823 is not in 11.
> >
> > Our tests are all green.
> >
> > Best regards,
> >   Goetz.
> >
> > Here all the related changes:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8204666 : javadoc should be
> > updated to use jQuery 3.3.1
> > https://bugs.openjdk.java.net/browse/JDK-8221644 : jquery directory
> > should be renamed
> > https://bugs.openjdk.java.net/browse/JDK-8222548 : Upgrading JDK 13
> with
> > the latest available jQuery 3.4.1
> > https://bugs.openjdk.java.net/browse/JDK-8238167 : Remove stray files
> > from jdk.javadoc
> > https://bugs.openjdk.java.net/browse/JDK-8236823 : Ensure that API
> > documentation uses minified libraries
> > https://bugs.openjdk.java.net/browse/JDK-8245981 : Upgrade to jQuery
> > 3.5.1

From goetz.lindenmaier at sap.com  Mon Aug 31 10:51:00 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 10:51:00 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AM4PR02MB313858B12225ED55301BFA968A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296423947E0ABCE66D6E6C24EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB313858B12225ED55301BFA968A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB29640DC87F65ED0E0D4EE704EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Yes, good, thanks!

Best regards,
  Goetz.

-----Original Message-----
From: Langer, Christoph <christoph.langer at sap.com> 
Sent: Montag, 31. August 2020 11:18
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: jdk-updates-dev at openjdk.java.net
Subject: RE: RFR [11u]: 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider

Hi Goetz,

thanks for your review.

I tried to address your concerns regarding the class comment for java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java and it's hopefully a bit easier to read and understand now:
http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.1/

Ok for you?

Thanks
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Freitag, 28. August 2020 17:15
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: Osipov, Michael <michael.osipov at siemens.com>
> Subject: RE: RFR [11u]: 8160768: Add capability to custom resolve
> host/domain names within the default JNDI LDAP provider
> 
> Hi Christoph,
> 
> You just pinged for a review, but I was looking at it anyways.
> 
> I think this looks good. The basic functionality is the same,
> you added functionality to access LdapDnsProviderService
> without having it in the same module.
> Our jck tests are green with the change as you implemented it.
> 
> One nit, I think the comment here is too complicated, maybe
> shorten the sentences a bit?
> http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/src/java.namin
> g/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java.ht
> ml
> 
>   34  * It is implemented by jdk.naming.ldap and the singleton instance is
> registered
>   35  * in LdapCtxFactory to which provides access to the service mechanism
>   36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
> -->
>   34  * It is implemented by jdk.naming.ldap. LdapDnsProviderService. A
> singleton instance is registered
>   35  * in LdapCtxFactory. This singleton provides access to the service
> mechanism
>   36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf
> > Of Langer, Christoph
> > Sent: Tuesday, August 11, 2020 5:52 PM
> > To: jdk-updates-dev at openjdk.java.net
> > Cc: Osipov, Michael <michael.osipov at siemens.com>
> > Subject: [CAUTION] RFR [11u]: 8160768: Add capability to custom resolve
> > host/domain names within the default JNDI LDAP provider
> >
> > Hi,
> >
> > I've been working on backporting JDK- 8160768: "Add capability to custom
> > resolve host/domain names within the default JNDI LDAP provider" to
> > OpenJDK 11u. This seems to be quite an important enhancement for usage
> in
> > more complex LDAP setups so there is a certain demand for this backport.
> > Oracle has backported it to their JDK8 and 11 releases already.
> >
> > Backporting is not so trivial, though, as the original change introduced a
> new
> > package with two classes in the javax namespace: javax.naming.ldap.spi
> with
> > classes LdapDnsProvider and LdapDnsProviderResult. To facilitate
> > backporting without having to change the spec, this backport creates
> > package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide
> > the new service interface. So people wanting to leverage the feature in a
> JDK
> > < 12 will have to build against the com.sun.jndi.ldap.spi implementation.
> > Furthermore, we can't publicly export package com.sun.jndi.ldap.spi from
> > module java.naming as this is not allowed for a module in the java
> > namespace. So I introduced a new module jdk.naming.ldap for being able
> to
> > export the new service interface. The service is hooked into java.naming's
> > class LdapCtxFactory by reflective lookup of class
> > com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its
> initialization.
> > This in turn will register the LdapDnsProviderServiceInternal singleton for
> > accessing com.sun.jndi.ldap.spi service implementations from java.naming.
> If
> > a JDK was jlink'ed without module jdk.naming.ldap, the missing
> > LdapDnsProvider facility would then just be ignored quietly.
> >
> > In my backport I also include the adaptations to the test from the already
> > backported change of JDK-8139965 to improve test stability.
> >
> > I had to create a backport CSR as well for which I'd also need a review.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
> > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
> > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
> > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/
> >
> > Thanks in advance for looking at this.
> >
> > Best regards
> > Christoph


From christoph.langer at sap.com  Mon Aug 31 10:57:55 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 10:57:55 +0000
Subject: RFR [11u]: 8160768: Add capability to custom resolve host/domain
 names within the default JNDI LDAP provider
In-Reply-To: <AM4PR0202MB29640DC87F65ED0E0D4EE704EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138ADC9249CBC2C354B45348A450@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296423947E0ABCE66D6E6C24EC520@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB313858B12225ED55301BFA968A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB29640DC87F65ED0E0D4EE704EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138DDF3E377B03DB88345BA8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Thanks for reviewing, Goetz!

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 31. August 2020 12:51
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: RFR [11u]: 8160768: Add capability to custom resolve
> host/domain names within the default JNDI LDAP provider
> 
> Yes, good, thanks!
> 
> Best regards,
>   Goetz.
> 
> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Montag, 31. August 2020 11:18
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: RFR [11u]: 8160768: Add capability to custom resolve
> host/domain names within the default JNDI LDAP provider
> 
> Hi Goetz,
> 
> thanks for your review.
> 
> I tried to address your concerns regarding the class comment for
> java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInter
> nal.java and it's hopefully a bit easier to read and understand now:
> http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.1/
> 
> Ok for you?
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Sent: Freitag, 28. August 2020 17:15
> > To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Cc: Osipov, Michael <michael.osipov at siemens.com>
> > Subject: RE: RFR [11u]: 8160768: Add capability to custom resolve
> > host/domain names within the default JNDI LDAP provider
> >
> > Hi Christoph,
> >
> > You just pinged for a review, but I was looking at it anyways.
> >
> > I think this looks good. The basic functionality is the same,
> > you added functionality to access LdapDnsProviderService
> > without having it in the same module.
> > Our jck tests are green with the change as you implemented it.
> >
> > One nit, I think the comment here is too complicated, maybe
> > shorten the sentences a bit?
> >
> http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/src/java.namin
> >
> g/share/classes/com/sun/jndi/ldap/LdapDnsProviderServiceInternal.java.ht
> > ml
> >
> >   34  * It is implemented by jdk.naming.ldap and the singleton instance is
> > registered
> >   35  * in LdapCtxFactory to which provides access to the service mechanism
> >   36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
> > -->
> >   34  * It is implemented by jdk.naming.ldap. LdapDnsProviderService. A
> > singleton instance is registered
> >   35  * in LdapCtxFactory. This singleton provides access to the service
> > mechanism
> >   36  * of jdk.naming.ldap/com.sun.jndi.ldap.spi for module java.naming.
> >
> > Best regards,
> >   Goetz.
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf
> > > Of Langer, Christoph
> > > Sent: Tuesday, August 11, 2020 5:52 PM
> > > To: jdk-updates-dev at openjdk.java.net
> > > Cc: Osipov, Michael <michael.osipov at siemens.com>
> > > Subject: [CAUTION] RFR [11u]: 8160768: Add capability to custom resolve
> > > host/domain names within the default JNDI LDAP provider
> > >
> > > Hi,
> > >
> > > I've been working on backporting JDK- 8160768: "Add capability to custom
> > > resolve host/domain names within the default JNDI LDAP provider" to
> > > OpenJDK 11u. This seems to be quite an important enhancement for
> usage
> > in
> > > more complex LDAP setups so there is a certain demand for this
> backport.
> > > Oracle has backported it to their JDK8 and 11 releases already.
> > >
> > > Backporting is not so trivial, though, as the original change introduced a
> > new
> > > package with two classes in the javax namespace: javax.naming.ldap.spi
> > with
> > > classes LdapDnsProvider and LdapDnsProviderResult. To facilitate
> > > backporting without having to change the spec, this backport creates
> > > package com.sun.jndi.ldap.spi instead of javax.naming.ldap.spi to provide
> > > the new service interface. So people wanting to leverage the feature in a
> > JDK
> > > < 12 will have to build against the com.sun.jndi.ldap.spi implementation.
> > > Furthermore, we can't publicly export package com.sun.jndi.ldap.spi
> from
> > > module java.naming as this is not allowed for a module in the java
> > > namespace. So I introduced a new module jdk.naming.ldap for being able
> > to
> > > export the new service interface. The service is hooked into
> java.naming's
> > > class LdapCtxFactory by reflective lookup of class
> > > com.sun.jndi.ldap.dns.LdapDnsProviderService and triggering its
> > initialization.
> > > This in turn will register the LdapDnsProviderServiceInternal singleton for
> > > accessing com.sun.jndi.ldap.spi service implementations from
> java.naming.
> > If
> > > a JDK was jlink'ed without module jdk.naming.ldap, the missing
> > > LdapDnsProvider facility would then just be ignored quietly.
> > >
> > > In my backport I also include the adaptations to the test from the already
> > > backported change of JDK-8139965 to improve test stability.
> > >
> > > I had to create a backport CSR as well for which I'd also need a review.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160768
> > > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8192975
> > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a
> > > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251380
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160768.11u.0/
> > >
> > > Thanks in advance for looking at this.
> > >
> > > Best regards
> > > Christoph


From christoph.langer at sap.com  Mon Aug 31 10:58:54 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 10:58:54 +0000
Subject: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
In-Reply-To: <AM4PR0202MB2964B7CBDBD18E0E4B04B533EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB2964E92F5A6716A4F2A174B3EC530@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB313820F1E192DD54D94152978A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296496F99DB92E9D5E98AC50EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB3138E9BD238CABA72B89884E8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB2964B7CBDBD18E0E4B04B533EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138C25651D6E471A19612C58A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

OK, looks good to me now. I'll approve it.

Cheers
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 31. August 2020 12:35
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> I tried to remove it before, but somehow this got lost ...
> http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/03/
> 
> In any case, I'll run the patch through our testing once more.
> 
> Best regards,
>   Goetz.
> 
> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Montag, 31. August 2020 12:02
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> 
> Hi Goetz,
> 
> looks good. You should also remove src/jdk.javadoc/share/legal/jquery-
> migrate.md as per http://hg.openjdk.java.net/jdk/jdk/rev/4f1f939d8f5d.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Sent: Montag, 31. August 2020 11:35
> > To: Langer, Christoph <christoph.langer at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> >
> > Hi,
> >
> > Yes, removing that file is a good idea. New webrev:
> > http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/02/
> >
> > Best regards,
> >   Goetz.
> >
> > -----Original Message-----
> > From: Langer, Christoph <christoph.langer at sap.com>
> > Sent: Montag, 31. August 2020 10:05
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: RE: [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> >
> > Hi Goetz,
> >
> > generally, your approach and patch look fine to me.
> >
> > However, looking at the intermediate step of migrating from 3.3.1 to 3.4.1
> > which was missed out in OpenJDK11 so far
> > (https://bugs.openjdk.java.net/browse/JDK-8222548), I can see that
> jquery-
> > migrate-3.0.1.js was removed there. I think this part should be
> incorporated
> > into this backport as well.
> >
> > Best regards
> > Christoph
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > > Behalf Of Lindenmaier, Goetz
> > > Sent: Samstag, 29. August 2020 11:07
> > > To: jdk-updates-dev at openjdk.java.net
> > > Subject: [CAUTION] [11u] RFR(M) 8245981: Upgrade to jQuery 3.5.1
> > >
> > > Hi,
> > >
> > > please review this downport for parity with Oracle.
> > > http://cr.openjdk.java.net/~goetz/wr20/8245981-jquery_3.5.1-jdk11/01
> > >
> > > In 11, the update from jquery 3.3.1 to 3.4.1 is missing.
> > > Therefore the change does not apply.
> > > Also, a change renaming the /jquery/ directory is missing
> > > in 11, another deleting some useless files and finally one
> > > minifying the script.
> > >
> > > So I basically crafted the change anew:
> > >  * I renamed jquery-3.3.1.js to jquery-3.5.1.js and replaced
> > >    it by the new file.
> > >  * I updated all the files referencing the file with the version in the name.
> > >  * In addition, I updated APITest.java because else these test are failing.
> > >  * I replaced jquery.js by the new file (jquery.js was deleted in jdk/jdk).
> > >  * I omitted the minified version as 8236823 is not in 11.
> > >
> > > Our tests are all green.
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > > Here all the related changes:
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8204666 : javadoc should be
> > > updated to use jQuery 3.3.1
> > > https://bugs.openjdk.java.net/browse/JDK-8221644 : jquery directory
> > > should be renamed
> > > https://bugs.openjdk.java.net/browse/JDK-8222548 : Upgrading JDK 13
> > with
> > > the latest available jQuery 3.4.1
> > > https://bugs.openjdk.java.net/browse/JDK-8238167 : Remove stray files
> > > from jdk.javadoc
> > > https://bugs.openjdk.java.net/browse/JDK-8236823 : Ensure that API
> > > documentation uses minified libraries
> > > https://bugs.openjdk.java.net/browse/JDK-8245981 : Upgrade to jQuery
> > > 3.5.1

From suenaga at oss.nttdata.com  Mon Aug 31 11:02:51 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Mon, 31 Aug 2020 20:02:51 +0900
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
 host OS
In-Reply-To: <AM4PR02MB3138FB7DC7A5122A807ABCF38A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>
 <AM0PR02MB54120CE54E9B2B3FDA13B67693520@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com>
 <AM4PR02MB3138FB7DC7A5122A807ABCF38A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com>

Hi Christoph,

JDK 11 is LTS version, so we might see hs_err logs which relates to this fix in production system. It is the reason why I want to backport it to 11.0.9 if possible.

OTOH it is not so critical and JDK 11 will enter rampdown, I understand that we have to be careful.
I will comply the timing when "jdk11u-fix-yes" is added to JBS.


Thanks,

Yasumasa


On 2020/08/31 19:04, Langer, Christoph wrote:
> Hi Yasumasa,
> 
> is there any specific reason why it should be part of 11.0.9?
> 
> Without having more detailed knowledge of the matter, I'd say it's cautious enough to postpone this backport to 11.0.10, given that we're about to enter rampdown...
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
>> Behalf Of Yasumasa Suenaga
>> Sent: Freitag, 28. August 2020 10:02
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Yasumasa Suenaga
>> <yasuenag at gmail.com>; jdk-updates-dev at openjdk.java.net
>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
>> host OS
>>
>> Hi Matthias,
>>
>> On 2020/08/28 16:22, Baesken, Matthias wrote:
>>> Hi Yasumasa ,I suggest to let the  change  "rest"  in  jdk/jdk for  a couple of
>> weeks  before  going for downports .
>>> (not saying that downporting it is a bad thing)
>>
>> I understand what you say, but I want to backport it to 11.0.9 if possible.
>> 11.0.9 will enter rampdown in 1 Sep...
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>>> Best regards, Matthias
>>>
>>> -----Original Message-----
>>> From: Yasumasa Suenaga <yasuenag at gmail.com>
>>> Sent: Freitag, 28. August 2020 02:55
>>> To: jdk-updates-dev at openjdk.java.net
>>> Cc: Baesken, Matthias <matthias.baesken at sap.com>
>>> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host
>> OS
>>>
>>> Hi all,
>>>
>>> Please approve backport of JDK-8250598:
>>>
>>>       JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
>>>       Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924
>>>       webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-
>> 8250598/jdk11u/webrev.00/
>>>
>>> The patch does not apply cleanly on 11u due to additional enhancements to
>> x86 / x86_64 processors.
>>> So I've prepared another webrev for 11u.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>

From sgehwolf at redhat.com  Mon Aug 31 11:16:46 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 31 Aug 2020 13:16:46 +0200
Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on
 host OS
In-Reply-To: <AM4PR02MB3138FB7DC7A5122A807ABCF38A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com>
 <AM0PR02MB54120CE54E9B2B3FDA13B67693520@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com>
 <AM4PR02MB3138FB7DC7A5122A807ABCF38A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <b4be40b37744f63437d660abcbdf03c6bfa224d1.camel@redhat.com>

On Mon, 2020-08-31 at 10:04 +0000, Langer, Christoph wrote:
> Without having more detailed knowledge of the matter, I'd say it's
> cautious enough to postpone this backport to 11.0.10, given that
> we're about to enter rampdown...

+1

Thanks,
Severin


From shade at redhat.com  Mon Aug 31 11:38:10 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 31 Aug 2020 13:38:10 +0200
Subject: [11u] RFR (XS) 8022535: [TEST BUG]
 javax/swing/text/html/parser/Test8017492.java fails
Message-ID: <da10390e-b9e6-09fd-a6eb-47293df00eb9@redhat.com>

Bug:
   https://bugs.openjdk.java.net/browse/JDK-8022535
   https://hg.openjdk.java.net/jdk/jdk/rev/e2dfcc1f04a3

Patch does not apply cleanly, because ProblemList.txt is very different.

11u webrev:

diff -r 22cbdebf83b8 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Fri Aug 07 11:23:24 2020 -0700
+++ b/test/jdk/ProblemList.txt  Mon Aug 31 13:27:28 2020 +0200
@@ -711,5 +711,4 @@
  javax/swing/JComponent/6683775/bug6683775.java 8172337 generic-all
  javax/swing/JComboBox/6236162/bug6236162.java 8028707 windows-all,macosx-all
-javax/swing/text/html/parser/Test8017492.java 8022535 generic-all
  javax/swing/JButton/8151303/PressedIconTest.java 8198689 macosx-all
  javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentCanvas.java 8081476 
windows-all,macosx-all
diff -r 22cbdebf83b8 test/jdk/javax/swing/text/html/parser/Test8017492.java
--- a/test/jdk/javax/swing/text/html/parser/Test8017492.java    Fri Aug 07 11:23:24 2020 -0700
+++ b/test/jdk/javax/swing/text/html/parser/Test8017492.java    Mon Aug 31 13:27:28 2020 +0200
@@ -1,4 +1,4 @@
  /*
- * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
@@ -72,4 +72,5 @@
          thread.join();
          // add error handling
+        SunToolkit.createNewAppContext();
          HTMLDocument document = new HTMLDocument() {
              @Override

Testing: affected test (passes)

-- 
Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Mon Aug 31 12:20:38 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 12:20:38 +0000
Subject: [11u] RFR (XS) 8022535: [TEST BUG]
 javax/swing/text/html/parser/Test8017492.java fails
In-Reply-To: <da10390e-b9e6-09fd-a6eb-47293df00eb9@redhat.com>
References: <da10390e-b9e6-09fd-a6eb-47293df00eb9@redhat.com>
Message-ID: <AM4PR0202MB296463DFB5BAFF6AF3361EEAEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Alexey, 

The change looks good to me. 

Best regards,
  Goetz.

-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf Of Aleksey Shipilev
Sent: Montag, 31. August 2020 13:38
To: jdk-updates-dev at openjdk.java.net
Subject: [11u] RFR (XS) 8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails

Bug:
   https://bugs.openjdk.java.net/browse/JDK-8022535
   https://hg.openjdk.java.net/jdk/jdk/rev/e2dfcc1f04a3

Patch does not apply cleanly, because ProblemList.txt is very different.

11u webrev:

diff -r 22cbdebf83b8 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Fri Aug 07 11:23:24 2020 -0700
+++ b/test/jdk/ProblemList.txt  Mon Aug 31 13:27:28 2020 +0200
@@ -711,5 +711,4 @@
  javax/swing/JComponent/6683775/bug6683775.java 8172337 generic-all
  javax/swing/JComboBox/6236162/bug6236162.java 8028707 windows-all,macosx-all
-javax/swing/text/html/parser/Test8017492.java 8022535 generic-all
  javax/swing/JButton/8151303/PressedIconTest.java 8198689 macosx-all
  javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentCanvas.java 8081476 
windows-all,macosx-all
diff -r 22cbdebf83b8 test/jdk/javax/swing/text/html/parser/Test8017492.java
--- a/test/jdk/javax/swing/text/html/parser/Test8017492.java    Fri Aug 07 11:23:24 2020 -0700
+++ b/test/jdk/javax/swing/text/html/parser/Test8017492.java    Mon Aug 31 13:27:28 2020 +0200
@@ -1,4 +1,4 @@
  /*
- * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
@@ -72,4 +72,5 @@
          thread.join();
          // add error handling
+        SunToolkit.createNewAppContext();
          HTMLDocument document = new HTMLDocument() {
              @Override

Testing: affected test (passes)

-- 
Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Mon Aug 31 14:07:20 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 14:07:20 +0000
Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java
 failed due to timeout on DeadServerNoTimeoutTest is incorrect
In-Reply-To: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB296493425D37D35976B2E14FEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Christoph, 

I had a look at your change.
One question:

Why do you use size() and not emtpy() here?

LdapDnsProviderService.java:
@@ -99,14 +101,16 @@
     LdapDnsProviderResult lookupEndpoints(String url, Hashtable<?,?> env)
         throws NamingException
     {
-        Iterator<LdapDnsProvider> iterator = providers.iterator();
-        Hashtable<?, ?> envCopy = new Hashtable<>(env);
         LdapDnsProviderResult result = null;
+        Hashtable<?, ?> envCopy = new Hashtable<>(env);
 
-        while (result == null && iterator.hasNext()) {
-            result = iterator.next().lookupEndpoints(url, envCopy)
-                    .filter(r -> r.getEndpoints().size() > 0)
-                    .orElse(null);
+        synchronized (LOCK) {
+            Iterator<LdapDnsProvider> iterator = providers.iterator();
+            while (result == null && iterator.hasNext()) {
+                result = iterator.next().lookupEndpoints(url, envCopy)
+                        .filter(r -> r.getEndpoints().size() > 0)                                                  <=======
+                        .orElse(null);
+            }
         }
 
         return result;

Besides that it looks good.

Best regards,
  Goetz.




-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf Of Langer, Christoph
Sent: Montag, 31. August 2020 11:31
To: jdk-updates-dev at openjdk.java.net
Subject: [CAUTION] [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

Hi,

may I please have a review for the backport of test fix JDK-8151678 "com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect" as follow-up for JDK-8160768 (Add capability to custom resolve host/domain names within the default JNDI LDAP provider).

Bug: https://bugs.openjdk.java.net/browse/JDK-8151678
Original change: https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.0/

I had the following Rejects:
src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
    needed manual resolve, also copyright year was different
LdapDnsProviderService.java:
    File is in a different location in 11u, so I needed to manually resolve it:
    java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java -> jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderService.java
ProblemList.txt:
    Needed a manual resolve

Thanks
Christoph


From goetz.lindenmaier at sap.com  Mon Aug 31 14:55:12 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 14:55:12 +0000
Subject: [11u] Input on 8250787 Provider.put no longer registering aliases in
 FIPS env
Message-ID: <AM4PR0202MB296405470F43185A0325DCD4EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

I had a look at
8250787 Provider.put no longer registering aliases in FIPS env
https://bugs.openjdk.java.net/browse/JDK-8250787

This is the last relevant open 11.0.9-oracle change in 11u.
Oracle rates it P2.
Unfortunately, no patch to downport exists. It is fixed only in 11
and 8 by Oracle.

Apparently the problem was introduced by
1.       7092821<https://bugs.openjdk.java.net/browse/JDK-7092821>: java.security.Provider.getService() is synchronized and became scalability bottleneck
2.       https://bugs.openjdk.java.net/browse/JDK-7092821
which was downported to 11.0.7.  Paul, do you maybe have an idea how to fix this?

Best regards,
  Goetz.



From christoph.langer at sap.com  Mon Aug 31 15:14:23 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 15:14:23 +0000
Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java
 failed due to timeout on DeadServerNoTimeoutTest is incorrect
In-Reply-To: <AM4PR0202MB296493425D37D35976B2E14FEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296493425D37D35976B2E14FEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138E2A40405378752909BAD8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Goetz,

good catch. Seems like I overlooked that one.

Here's an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.1/

Best regards
Christoph


> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 31. August 2020 16:07
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR (S): 8151678:
> com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> DeadServerNoTimeoutTest is incorrect
> 
> Hi Christoph,
> 
> I had a look at your change.
> One question:
> 
> Why do you use size() and not emtpy() here?
> 
> LdapDnsProviderService.java:
> @@ -99,14 +101,16 @@
>      LdapDnsProviderResult lookupEndpoints(String url, Hashtable<?,?> env)
>          throws NamingException
>      {
> -        Iterator<LdapDnsProvider> iterator = providers.iterator();
> -        Hashtable<?, ?> envCopy = new Hashtable<>(env);
>          LdapDnsProviderResult result = null;
> +        Hashtable<?, ?> envCopy = new Hashtable<>(env);
> 
> -        while (result == null && iterator.hasNext()) {
> -            result = iterator.next().lookupEndpoints(url, envCopy)
> -                    .filter(r -> r.getEndpoints().size() > 0)
> -                    .orElse(null);
> +        synchronized (LOCK) {
> +            Iterator<LdapDnsProvider> iterator = providers.iterator();
> +            while (result == null && iterator.hasNext()) {
> +                result = iterator.next().lookupEndpoints(url, envCopy)
> +                        .filter(r -> r.getEndpoints().size() > 0)
> <=======
> +                        .orElse(null);
> +            }
>          }
> 
>          return result;
> 
> Besides that it looks good.
> 
> Best regards,
>   Goetz.
> 
> 
> 
> 
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Montag, 31. August 2020 11:31
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR (S): 8151678:
> com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> DeadServerNoTimeoutTest is incorrect
> 
> Hi,
> 
> may I please have a review for the backport of test fix JDK-8151678
> "com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> DeadServerNoTimeoutTest is incorrect" as follow-up for JDK-8160768 (Add
> capability to custom resolve host/domain names within the default JNDI
> LDAP provider).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151678
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.0/
> 
> I had the following Rejects:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.j
> ava:
>     needed manual resolve, also copyright year was different
> LdapDnsProviderService.java:
>     File is in a different location in 11u, so I needed to manually resolve it:
> 
> java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java
> ->
> jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderSer
> vice.java
> ProblemList.txt:
>     Needed a manual resolve
> 
> Thanks
> Christoph


From goetz.lindenmaier at sap.com  Mon Aug 31 15:42:33 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 15:42:33 +0000
Subject: [11u] RFR: 8213400: Support choosing group name in keytool keypair
 generation
Message-ID: <AM4PR0202MB2964B1FEF99797D20D9EF3D3EC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi

I would like to downport this for parity with 11.0.10-oracle.
I had to resolve the code, especially CertAndKeyGen.
There already is a downport of the CSR which I will reuse.
Please review:
http://cr.openjdk.java.net/~goetz/wr20/8213400-keytool_keypair-jdk11/01/

Orig change:
https://bugs.openjdk.java.net/browse/JDK-8213400
http://hg.openjdk.java.net/jdk/jdk/rev/ddcbc20e8c6a

Best regards,
  Goetz.

From goetz.lindenmaier at sap.com  Mon Aug 31 15:44:34 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 31 Aug 2020 15:44:34 +0000
Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java
 failed due to timeout on DeadServerNoTimeoutTest is incorrect
In-Reply-To: <AM4PR02MB3138E2A40405378752909BAD8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296493425D37D35976B2E14FEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB3138E2A40405378752909BAD8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB29646AA18A347E52962CCC2DEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Looks good now, thanks!

Best regards,
  Goetz.

-----Original Message-----
From: Langer, Christoph <christoph.langer at sap.com> 
Sent: Montag, 31. August 2020 17:14
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev at openjdk.java.net
Subject: RE: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

Hi Goetz,

good catch. Seems like I overlooked that one.

Here's an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.1/

Best regards
Christoph


> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 31. August 2020 16:07
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR (S): 8151678:
> com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> DeadServerNoTimeoutTest is incorrect
> 
> Hi Christoph,
> 
> I had a look at your change.
> One question:
> 
> Why do you use size() and not emtpy() here?
> 
> LdapDnsProviderService.java:
> @@ -99,14 +101,16 @@
>      LdapDnsProviderResult lookupEndpoints(String url, Hashtable<?,?> env)
>          throws NamingException
>      {
> -        Iterator<LdapDnsProvider> iterator = providers.iterator();
> -        Hashtable<?, ?> envCopy = new Hashtable<>(env);
>          LdapDnsProviderResult result = null;
> +        Hashtable<?, ?> envCopy = new Hashtable<>(env);
> 
> -        while (result == null && iterator.hasNext()) {
> -            result = iterator.next().lookupEndpoints(url, envCopy)
> -                    .filter(r -> r.getEndpoints().size() > 0)
> -                    .orElse(null);
> +        synchronized (LOCK) {
> +            Iterator<LdapDnsProvider> iterator = providers.iterator();
> +            while (result == null && iterator.hasNext()) {
> +                result = iterator.next().lookupEndpoints(url, envCopy)
> +                        .filter(r -> r.getEndpoints().size() > 0)
> <=======
> +                        .orElse(null);
> +            }
>          }
> 
>          return result;
> 
> Besides that it looks good.
> 
> Best regards,
>   Goetz.
> 
> 
> 
> 
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Montag, 31. August 2020 11:31
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR (S): 8151678:
> com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> DeadServerNoTimeoutTest is incorrect
> 
> Hi,
> 
> may I please have a review for the backport of test fix JDK-8151678
> "com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> DeadServerNoTimeoutTest is incorrect" as follow-up for JDK-8160768 (Add
> capability to custom resolve host/domain names within the default JNDI
> LDAP provider).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151678
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.0/
> 
> I had the following Rejects:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.j
> ava:
>     needed manual resolve, also copyright year was different
> LdapDnsProviderService.java:
>     File is in a different location in 11u, so I needed to manually resolve it:
> 
> java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java
> ->
> jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderSer
> vice.java
> ProblemList.txt:
>     Needed a manual resolve
> 
> Thanks
> Christoph


From hohensee at amazon.com  Mon Aug 31 16:43:03 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 31 Aug 2020 16:43:03 +0000
Subject: [11u] Input on 8250787 Provider.put no longer registering aliases
 in FIPS env
Message-ID: <C9630751-E9B1-4E2B-9517-9FB0A8725312@amazon.com>

We?ll take a look.

Thanks,
Paul

From: "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
Date: Monday, August 31, 2020 at 7:55 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>, "Hohensee, Paul" <hohensee at amazon.com>
Subject: [11u] Input on 8250787 Provider.put no longer registering aliases in FIPS env

Hi,

I had a look at
8250787 Provider.put no longer registering aliases in FIPS env
https://bugs.openjdk.java.net/browse/JDK-8250787

This is the last relevant open 11.0.9-oracle change in 11u.
Oracle rates it P2.
Unfortunately, no patch to downport exists. It is fixed only in 11
and 8 by Oracle.

Apparently the problem was introduced by
1.       7092821<https://bugs.openjdk.java.net/browse/JDK-7092821>: java.security.Provider.getService() is synchronized and became scalability bottleneck
2.       https://bugs.openjdk.java.net/browse/JDK-7092821
which was downported to 11.0.7.  Paul, do you maybe have an idea how to fix this?

Best regards,
  Goetz.



From sgehwolf at redhat.com  Mon Aug 31 17:07:26 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 31 Aug 2020 19:07:26 +0200
Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java
 failed due to timeout on DeadServerNoTimeoutTest is incorrect
In-Reply-To: <AM4PR02MB3138E2A40405378752909BAD8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296493425D37D35976B2E14FEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB3138E2A40405378752909BAD8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <6adda6d77994f1a3dde60e9bb375ad80979bc7a8.camel@redhat.com>

Hi Christoph,

On Mon, 2020-08-31 at 15:14 +0000, Langer, Christoph wrote:
> Hi Goetz,
> 
> good catch. Seems like I overlooked that one.
> 
> Here's an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.1/

I had a look at this for 11u approval and this jumped out at me:

src/jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderService.java

 107         synchronized (LOCK) {
 108             Iterator<LdapDnsProvider> iterator = providers.iterator();
 109             while (result == null && iterator.hasNext()) {
 110                 result = iterator.next().lookupEndpoints(url, envCopy)
 111                         .filter(r -> r.getEndpoints().isEmpty())
 112                         .orElse(null);
 113             }

Line 111 inverses the filter from the original change[1]. This looks
wrong.

Thanks,
Severin

[1] https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93#l2.59

> Best regards
> Christoph
> 
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Sent: Montag, 31. August 2020 16:07
> > To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: RE: [11u] RFR (S): 8151678:
> > com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> > DeadServerNoTimeoutTest is incorrect
> > 
> > Hi Christoph,
> > 
> > I had a look at your change.
> > One question:
> > 
> > Why do you use size() and not emtpy() here?
> > 
> > LdapDnsProviderService.java:
> > @@ -99,14 +101,16 @@
> >      LdapDnsProviderResult lookupEndpoints(String url, Hashtable<?,?> env)
> >          throws NamingException
> >      {
> > -        Iterator<LdapDnsProvider> iterator = providers.iterator();
> > -        Hashtable<?, ?> envCopy = new Hashtable<>(env);
> >          LdapDnsProviderResult result = null;
> > +        Hashtable<?, ?> envCopy = new Hashtable<>(env);
> > 
> > -        while (result == null && iterator.hasNext()) {
> > -            result = iterator.next().lookupEndpoints(url, envCopy)
> > -                    .filter(r -> r.getEndpoints().size() > 0)
> > -                    .orElse(null);
> > +        synchronized (LOCK) {
> > +            Iterator<LdapDnsProvider> iterator = providers.iterator();
> > +            while (result == null && iterator.hasNext()) {
> > +                result = iterator.next().lookupEndpoints(url, envCopy)
> > +                        .filter(r -> r.getEndpoints().size() > 0)
> > <=======
> > +                        .orElse(null);
> > +            }
> >          }
> > 
> >          return result;
> > 
> > Besides that it looks good.
> > 
> > Best regards,
> >   Goetz.
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Langer, Christoph
> > Sent: Montag, 31. August 2020 11:31
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [11u] RFR (S): 8151678:
> > com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> > DeadServerNoTimeoutTest is incorrect
> > 
> > Hi,
> > 
> > may I please have a review for the backport of test fix JDK-8151678
> > "com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on
> > DeadServerNoTimeoutTest is incorrect" as follow-up for JDK-8160768 (Add
> > capability to custom resolve host/domain names within the default JNDI
> > LDAP provider).
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8151678
> > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.0/
> > 
> > I had the following Rejects:
> > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.j
> > ava:
> >     needed manual resolve, also copyright year was different
> > LdapDnsProviderService.java:
> >     File is in a different location in 11u, so I needed to manually resolve it:
> > 
> > java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java
> > ->
> > jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderSer
> > vice.java
> > ProblemList.txt:
> >     Needed a manual resolve
> > 
> > Thanks
> > Christoph


From christoph.langer at sap.com  Mon Aug 31 17:32:26 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 31 Aug 2020 17:32:26 +0000
Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java
 failed due to timeout on DeadServerNoTimeoutTest is incorrect
In-Reply-To: <6adda6d77994f1a3dde60e9bb375ad80979bc7a8.camel@redhat.com>
References: <AM4PR02MB313830B2A375FEF2728811DF8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR0202MB296493425D37D35976B2E14FEC510@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <AM4PR02MB3138E2A40405378752909BAD8A510@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <6adda6d77994f1a3dde60e9bb375ad80979bc7a8.camel@redhat.com>
Message-ID: <AM4PR02MB313834ED02D76CE78EC55E138A510@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Severin,

> I had a look at this for 11u approval and this jumped out at me:
> 
> src/jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProvider
> Service.java
> 
>  107         synchronized (LOCK) {
>  108             Iterator<LdapDnsProvider> iterator = providers.iterator();
>  109             while (result == null && iterator.hasNext()) {
>  110                 result = iterator.next().lookupEndpoints(url, envCopy)
>  111                         .filter(r -> r.getEndpoints().isEmpty())
>  112                         .orElse(null);
>  113             }
> 
> Line 111 inverses the filter from the original change[1]. This looks
> wrong.

Oops, you're right. I believe the nightlies would have shown this regression, but anyway, thanks for spotting it.

Here's the fix: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.2/

Thanks
Christoph