From gnu.andrew at redhat.com  Mon Jun  1 12:39:05 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Jun 2020 13:39:05 +0100
Subject: [8u] RFR 8244407: JVM crashes after transformation in C2
 IdealLoopTree::split_fall_in
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE7E0EA68@dggeml527-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE7E0BD3F@dggeml527-mbx.china.huawei.com>
 <818cc8fa-99e2-2f58-b2f0-3f1d9e3a8055@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE7E0E0EC@dggeml527-mbx.china.huawei.com>
 <d99373c0-58a8-ef11-cd18-67bd025e2c9b@redhat.com>
 <DA41BE1DDCA941489001C7FBD7A8820EE7E0EA68@dggeml527-mbx.china.huawei.com>
Message-ID: <66f1eaac-3f3b-77fa-88ba-f773bdf924e2@redhat.com>



On 25/05/2020 12:05, Yangfei (Felix) wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Andrew Hughes [mailto:gnu.andrew at redhat.com]
>> Sent: Monday, May 25, 2020 1:33 PM
>> To: Yangfei (Felix) <felix.yang at huawei.com>; 'jdk8u-dev at openjdk.java.net'
>> <jdk8u-dev at openjdk.java.net>
>> Subject: Re: [8u] RFR 8244407: JVM crashes after transformation in C2
>> IdealLoopTree::split_fall_in
>>
>>
> 
> Snip...
> 
>>>
>>
>> I believe that was in reference to a copyright change being created for the
>> backport.
>>
>> In this case, the copyright header change has wrongly been removed, when
>> compared to the original patch. It should be reinstated.
> 
> Thanks.  Now I see the point.
> 
> New webrev: http://cr.openjdk.java.net/~fyang/8244407-8u-backport/webrev.01 
> 
> Felix
> 

Thanks. That looks fine. I've pushed it so it just makes 8u252-b05
before rampdown.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Jun  1 12:41:37 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Jun 2020 13:41:37 +0100
Subject: [RAMPDOWN] 8u & 8u-dev Forests FROZEN
Message-ID: <2cf4e00e-4586-deca-3e2b-ef4434b4a06c@redhat.com>

We are now entering rampdown for the 8u262 release.

8u-dev is now frozen until it is switched to make commits for 8u272.
Please do not push to 8u-dev until a further notification which states
that this process is complete.

8u will be frozen until the promotion of 8u262-b05 is complete
(hopefully later today). After that, fixes may be pushed to 8u for 8u262
which have jdk8u-critical-yes.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Jun  1 12:53:43 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Jun 2020 13:53:43 +0100
Subject: [8u] RFR: 8237951: CTW: C2 compilation fails with "malformed
 control flow"
In-Reply-To: <871rp8ek1x.fsf@redhat.com>
References: <871rp8ek1x.fsf@redhat.com>
Message-ID: <1ed737d5-a71a-4df6-00c5-befea79d4754@redhat.com>



On 31/03/2020 14:22, Roland Westrelin wrote:
> 
> The patch from the fix applies cleanly but it relies on
> Node::find_out_with() that's missing from 8. The backport below cherry
> picks that method from 8066312 (Add new Node* Node::find_out(int opc)
> method).
> 
> http://cr.openjdk.java.net/~roland/8237951.8u/webrev.00/
> 
> Initial change:
> https://bugs.openjdk.java.net/browse/JDK-8237951
> https://hg.openjdk.java.net/jdk/jdk/rev/c7152f7e01a6
> 
> Tested with tier1.
> 
> Roland.
> 

Hmm, I'm not sure we should be cherry-picking this function for just the
one use case. For consistency, we should either bring in JDK-8066312
(which doesn't amount to much more than is cherry-picked here) or
replace the call in this patch with the function body, as is the case in
other places in the code e.g.

https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/f7691a80458c/src/share/vm/opto/escape.cpp#l3105

Thanks,
-- 
Andrew :)

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

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


From aph at redhat.com  Mon Jun  1 13:40:20 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 1 Jun 2020 14:40:20 +0100
Subject: [8u] RFR: 8237951: CTW: C2 compilation fails with "malformed
 control flow"
In-Reply-To: <1ed737d5-a71a-4df6-00c5-befea79d4754@redhat.com>
References: <871rp8ek1x.fsf@redhat.com>
 <1ed737d5-a71a-4df6-00c5-befea79d4754@redhat.com>
Message-ID: <684fa615-dc7b-f92e-6c92-a0289ed58bdc@redhat.com>

On 01/06/2020 13:53, Andrew Hughes wrote:
> Hmm, I'm not sure we should be cherry-picking this function for just the
> one use case. For consistency, we should either bring in JDK-8066312
> (which doesn't amount to much more than is cherry-picked here) or
> replace the call in this patch with the function body

I already approved the patch. Bringing in all of 8066312 would be
excessive, but if Roland prefers to use the function body rather than
cheery pick the function I don't object.

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


From gnu.andrew at redhat.com  Mon Jun  1 17:05:51 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Jun 2020 18:05:51 +0100
Subject: Backport of JDK-8178374 to jdk8u
In-Reply-To: <CA+kOe0_vJ4QA2oDbMqQRWHqoNrZdqamUw6BJf77Easgm5MzH3g@mail.gmail.com>
References: <CACz-JM6N_nQpG93-7YeVVSYJOUSeL_Nc=ED5fCOmiR-pi-599A@mail.gmail.com>
 <CA+kOe0-RWEk9EKPZq8_YPQS=tnyS+g=6nv3mt1-ZWm7BeSiY7g@mail.gmail.com>
 <CACz-JM74gc-yU3mK=exm0KoBCX5zsnUaK8Zhc1eAC0Q8dC0qzQ@mail.gmail.com>
 <CA+kOe0_vJ4QA2oDbMqQRWHqoNrZdqamUw6BJf77Easgm5MzH3g@mail.gmail.com>
Message-ID: <a41c721d-5029-56dc-81e0-8b9330f44247@redhat.com>



On 30/05/2020 00:53, Martin Buchholz wrote:
> I removed the line breaks in the obvious way manually.
> 
> I created a webrev for Jonathan's change here:
> http://cr.openjdk.java.net/~martin/webrevs/jdk8/backport-JDK-8178374/
> 
> Further work over at https://bugs.openjdk.java.net/browse/JDK-8178374
> 

Hi Jonathan & Martin,

For a change like this which just needs automated path shuffling,
there's no need to go through the review process. The bug can just be
flagged directly for approval with jdk8u-fix-request. See:

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

I've approved and pushed this. It'll be part of 8u262-b05.

Thanks for the contribution!
-- 
Andrew :)

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

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


From mbalao at redhat.com  Mon Jun  1 19:59:17 2020
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 1 Jun 2020 16:59:17 -0300
Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues
In-Reply-To: <70AC9E7E-280D-412D-AA4C-A527DCC87165@azul.com>
References: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com>
 <13d50c06-6c26-2f78-9d09-0408b7725b6e@redhat.com>
 <70AC9E7E-280D-412D-AA4C-A527DCC87165@azul.com>
Message-ID: <3a2914a8-6286-a5cb-5229-bf7e64166fc9@redhat.com>

Hi Alexey,

Thanks for having a look at this.

I've seen that v1 removes methods from
src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java, which were
not removed by v0. Was this by mistake? Otherwise, please let me know of
additional change between revisions because I may overlook something.

My other comments inline.

Regards,
Martin.-

On 5/30/20 4:40 PM, Alexey Bakhtin wrote:
>> A few questions and comments below:
>>
>> * I found several compilation errors. Isn't Step 3 supposed to be the
>> one that makes the code compile in JDK-8? In case it's not, I wish you
>> could clarify what are the expectations for Step 3 and where are will
>> these errors be addressed.
> 
> It was not supposed to make all classes compilable on this step
> A lot of classes will be changed in subsequent steps and I did not want to make double work:
> - Fix compilation errors in methods that will be changed in the next steps
> - Double task for reviewer : review changes that will be excluded later
> The name of the step could be misleading but at this step I just fixed general compilation errors.
> The known issues that fixed in later steps:
> - Finished.java
>   Fixed in JDK-8245471: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245471/webrev.v0/
> - KerberosClientKeyExchange.java krb5/KerberosClientKeyExchangeImpl.java and krb5/KerberosPreMasterSecret.java
>   Fixed in JDK-8245474 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245474/webrev.v0/
> - X509TrustManagerImpl.java
>   Fixed in JDK-8245473 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245473/webrev.v0/
>          and JDK-8245472 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v0/
> 

Thanks for your clarification. Yes, makes sense to me. I'll stick to the
actual change more than to what be missing. Compilation will not be an
expectation for this intermediate step then (as it was not for the
previous steps).

>>
>> * HandshakeContext.java
>>
>> Why is casting needed in JDK-8 and not needed in JDK-11? (I was going to
>> check this myself compiling but found several compilation errors, and I
>> do not realize of the difference looking at the ByteBuffer API only). I
>> guess this question applies to SSLCipher.java, SSLSocketInputRecord.java
>> and SSLEngineInputRecord.java too.
> 
> Actually, I do not know Why JDK11 allows such downcasting without explicit cast
> 

Aha, found the mystery!

JDK-11:
      22: invokevirtual #4                  // Method
java/nio/ByteBuffer.rewind:()Ljava/nio/ByteBuffer;

JDK-8:
      22: invokevirtual #4                  // Method
java/nio/ByteBuffer.rewind:()Ljava/nio/Buffer;
      25: checkcast     #5                  // class java/nio/ByteBuffer

In JDK-11, ByteBuffer::rewind overrides rewind with a compatible return
type: ByteBuffer. JDK-8 declares Buffer::rewind to be final and the
return type is Buffer, so there is not an override.

I'm okay with your cast because we know that 'fragment' is of type
ByteBuffer and rewind won't change that -in fact, it returns 'this'-. I
do not expect a runtime failure here and there shouldn't be a noticeable
performance impact either.

>>
>> * HandshakeHash.java
> Thank you
> You are absolutely right. I have to use JDK8 implementation of digestKey
> Fixed

Can we apply JDK-11's approach with MessageDigestSpi2?

>> * JsseJce.java
>>
>> Have you considered backporting SecurityConstants.java part of 8130181
>> [5] and use PROVIDER_VER in JsseJce.java
>>
> Thank you. Fixed.
> PROVIDER_VER is added to SecurityConstants.
> SunJSSE.jave is also updated

Can't we use JDK-11's approach with
"GetPropertyAction.privilegedGetProperty("java.specification.version");"? I
guess the string is not exactly the same and you want to keep JDK-8
compatibility here. But please confirm the reason so we leave a record.

> 
>> * SSLLogger.java
>>
>> Can't we leverage on PlatformLogger values directly? For each value,
>> there should be a corresponding one. In case there is a good reason why
>> not, we might want to think of moving the code to a more reusable place.
> 
> I have updated it to use java.util.logging.Logger
> Internal Level enum is changed to java.util.logging.Level
> Also, I?ve made possible to register app Logger. It was not possible in the first version.

Looks good to me. Well done! Remind me of asking for log examples at the
end of this series :-)

>>
>> * RandomCookie.java / RenegoInfoExtension.java
>>
>> Have you analyzed the performance implication of not having vectorized /
>> intrinsics for the comparison?
> 
> No, I did not analyzed it. I understand possible performance impact but it could be
> optimized later.
> 

Right. Given the effort and risk involved in the 'vectorized' backport,
I won't suggest it now. However, we should keep an eye on this and if
any performance downgrade is noticed, here we have something to look at.
The RandomCookie use is for a few bytes only, so it shouldn't be a big
deal. The Renegotiation Extension does not look like a big deal either,
at first glance at least.

>>
>> * SSLSessionContextImpl.java
>>
>> Can't we use GetPropertyAction::privilegedGetProperty?
> 
> I have updated it as recommended in the JDK8 GetIntegerAction class
> 

Even though the documentation gives an example with an Integer cast and
an intValue call, that shouldn't be necessary.

>>
>> * X509TrustManagerImpl.java
>>
>> Why is this change needed?
>>
> ExtendedSSLSession does not contain getStatusResponses() public API method.
> This method is part of JEP-249 : OCSP Stapling for TLS [1]
> It is possible to implement and use OCSP Stapling without public API.
> However, these changes should be moved to the step responsible for
> OCSP stapling support - JDK-8245473
> 
> Fixed

Good.



From denghui.ddh at alibaba-inc.com  Tue Jun  2 06:18:00 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Tue, 02 Jun 2020 14:18:00 +0800
Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIDgyMjU3OTc6IFtiYWNrcG9ydF0gT2xkT2JqZWN0U2FtcGxlIGV2ZW50?=
 =?UTF-8?B?IGNyZWF0ZXMgdW5leHBlY3RlZCBhbW91bnQgb2YgY2hlY2twb2ludCBkYXRh?=
In-Reply-To: <8cb4655f-541d-653c-2c8c-05d5cb8e083e@redhat.com>
References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com>
 <CAPb8aJ7LjHr-hSzfe5yt=sWmUBSAYcdXAiXs7CUy__K4GuS=zA@mail.gmail.com>
 <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com>
 <8225cc35-fa62-4df2-b7a4-689b9f0726e6.>
 <0be06b28-6912-4f5d-84e5-5edf8833f92b.denghui.ddh@alibaba-inc.com>
 <4b66d9ea-6e80-47da-87f9-030da0a8845b.denghui.ddh@alibaba-inc.com>
 <923950d4f0c4bd8e50ec02a79d43b87aa8014d6a.camel@redhat.com>,
 <8cb4655f-541d-653c-2c8c-05d5cb8e083e@redhat.com>
Message-ID: <07d34773-4040-40b5-a3d1-997a2c72e5d5.denghui.ddh@alibaba-inc.com>

Hi Mario and Andrew,

Sorry for the late reply, and thank you very much for the comments.

I will file a new bug to clean the useless code about PackageEntry and ModuleEntry first,
and then refine this patch.

Thanks,
Denghui Dong


------------------------------------------------------------------
From:Andrew Dinn <adinn at redhat.com>
Send Time:2020?5?28?(???) 18:06
To:Mario Torre <neugens at redhat.com>; ???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data

Hi Denghui,

On 13/05/2020 12:07, Mario Torre wrote:
> On Wed, 2020-05-13 at 09:56 +0800, Denghui Dong wrote:
>> Gentle ping?
>>
> 
> Hi Denghui,
> 
> Sorry, the patch is really big so it's taking some time, but I asked
> some help ;)

This is a very complex patch which has been very hard to review. The
difficulty is not just the obvious problem of the complexity of the code
under modification. It is compounded by the fact that the diff algorithm
used to construct the patch files has selected different 'match lines'
when distinguishing the start and extent of jdk8u differences from those
used to establish the start and extent of jdk11u differences.

So, although the two patches mostly contain the same additions in the
same order and the same deletions in the same order these additions and
deletions are interleaved differently from one patch file to the other.
That has made it very hard to subtract apparent changes which in reality
turn out to be no-ops from the changes actually needed to make the
jdk11u fix work on jdk8u.

Also, retention/update of all the commented out code relating to modules
and packages has not helped. I agree with Mario that this commented out
code is best deleted (and arguably should have been in the initial
backport). Retaining commented out code in a downstream repo in order to
mark omissions from the upstream version is always going to be a losing
game. It simply introduces noise and code/comment-rot into the process.
It is much clearer and simpler to have no module-related code in the
jdk8u repo and not have to review edits to commented out module code in
backport patches.

Arguably this problem could be handled as a separate issue -- there may
well be commented out code blocks that are not updated by this patch.
However, I'd like to see the process started here by ensuring that any
commented out blocks that are updated or replaced with new commented
code by the current patch are instead just replaced with nothing. Any
remaining cleanup can happen later.

Finally, while the set of .rej files linked in the original post does
help to clarify locations where application the jdk11u patch to jdk8u
was not straightforward that isn't really enough to explain 1) why the
patch failed to apply and 2) what needed to be done to remedy the
situation. I would very much prefer an account of both of those before
accepting this patch. For example, was the failure down to a minor
difference in layout, a failure to match because an upstream change was
not present or a difference arising because of a disparity in design or
features between the jdk8u and jdk11u JVMs. At the very least a few
lines of explanation  per .rej file would be helpful. That would allow
me to make a much more confident assessment of the correctness of the
backport and will also stand as a record of what was needed for later
reference in case any problems arise when this goes into production use.

On the plus side this change is pretty much self-contained, only really
affecting the JFR code and, in particular, the leak analysis part of
that code. So, whatever risk the lack of clarity over precisely what has
been changed implies is /probably/ fairly tightly localized to users of
JFR who enable leak analysis. Since that function is effectively broken
anyway I'm not extremely concerned about allowing this patch to go into
the release. I'd still like to see the rationale for the changes before
agreeing that though.

So, to sum up before this can be pushed I'd like to see 1) a revised
patch with the commented out code deleted and 2) for each .rej file a
summary of what was changed between jdk11u and jdk8u and why. I'll take
another look once those are provided.

regards,


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

From denghui.ddh at alibaba-inc.com  Tue Jun  2 07:22:00 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Tue, 02 Jun 2020 15:22:00 +0800
Subject: =?UTF-8?B?Wzh1XSBbSkZSXSA4MjQ2MzEwIDogQ2xlYW4gY29tbWVudGVkLW91dCBjb2RlIGFib3V0IE1v?=
 =?UTF-8?B?ZHVsZUVudHJ5IGFuZFBhY2thZ2VFbnRyeSBpbiBKRlI=?=
Message-ID: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>

Hi,
Could I have a review of this small patch that deletes the commented-out code about ModuleEntry andPackageEntry in JFR.
Most of the deleted code is commented out, except 
```
<XmlType name="Package" parameterType="const PackageEntry*" fieldType="const PackageEntry*"/>
```
in metadata.xml.
PackageEntry doesn't exist in 8u, so it's safe to delete this line.

Bugs: https://bugs.openjdk.java.net/browse/JDK-8246310
Webrev: http://cr.openjdk.java.net/~ddong/8246310/webrev.00/
Testing: jdk/jfr, no extra failure

Thanks,
Denghui Dong

From alexey at azul.com  Tue Jun  2 09:13:14 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 2 Jun 2020 09:13:14 +0000
Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues
In-Reply-To: <3a2914a8-6286-a5cb-5229-bf7e64166fc9@redhat.com>
References: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com>
 <13d50c06-6c26-2f78-9d09-0408b7725b6e@redhat.com>
 <70AC9E7E-280D-412D-AA4C-A527DCC87165@azul.com>
 <3a2914a8-6286-a5cb-5229-bf7e64166fc9@redhat.com>
Message-ID: <0F659D7C-38CD-4E55-83F1-B16BB4A5C95D@azul.com>

Hello Martin,

Thank you for review.
Updated webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245470/webrev.v2/

Please see comments inline

Regards
Alexey

> On 1 Jun 2020, at 22:59, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> Thanks for having a look at this.
> 
> I've seen that v1 removes methods from
> src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java, which were
> not removed by v0. Was this by mistake? Otherwise, please let me know of
> additional change between revisions because I may overlook something.
> 
This class were changed as part of JDK-8245469 [1]
Later, after discussion in [2] I?ve moved modification to JDK-8245470 [3]
This is a reason BaseSSLSocketImpl was not changed in the v0 and changed in v1

> My other comments inline.
> 
> Regards,
> Martin.-
> 
> On 5/30/20 4:40 PM, Alexey Bakhtin wrote:
>>> A few questions and comments below:
>>> 
>>> * I found several compilation errors. Isn't Step 3 supposed to be the
>>> one that makes the code compile in JDK-8? In case it's not, I wish you
>>> could clarify what are the expectations for Step 3 and where are will
>>> these errors be addressed.
>> 
>> It was not supposed to make all classes compilable on this step
>> A lot of classes will be changed in subsequent steps and I did not want to make double work:
>> - Fix compilation errors in methods that will be changed in the next steps
>> - Double task for reviewer : review changes that will be excluded later
>> The name of the step could be misleading but at this step I just fixed general compilation errors.
>> The known issues that fixed in later steps:
>> - Finished.java
>>  Fixed in JDK-8245471: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245471/webrev.v0/
>> - KerberosClientKeyExchange.java krb5/KerberosClientKeyExchangeImpl.java and krb5/KerberosPreMasterSecret.java
>>  Fixed in JDK-8245474 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245474/webrev.v0/
>> - X509TrustManagerImpl.java
>>  Fixed in JDK-8245473 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245473/webrev.v0/
>>         and JDK-8245472 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v0/
>> 
> 
> Thanks for your clarification. Yes, makes sense to me. I'll stick to the
> actual change more than to what be missing. Compilation will not be an
> expectation for this intermediate step then (as it was not for the
> previous steps).
> 
>>> 
>>> * HandshakeContext.java
>>> 
>>> Why is casting needed in JDK-8 and not needed in JDK-11? (I was going to
>>> check this myself compiling but found several compilation errors, and I
>>> do not realize of the difference looking at the ByteBuffer API only). I
>>> guess this question applies to SSLCipher.java, SSLSocketInputRecord.java
>>> and SSLEngineInputRecord.java too.
>> 
>> Actually, I do not know Why JDK11 allows such downcasting without explicit cast
>> 
> 
> Aha, found the mystery!
> 
> JDK-11:
>      22: invokevirtual #4                  // Method
> java/nio/ByteBuffer.rewind:()Ljava/nio/ByteBuffer;
> 
> JDK-8:
>      22: invokevirtual #4                  // Method
> java/nio/ByteBuffer.rewind:()Ljava/nio/Buffer;
>      25: checkcast     #5                  // class java/nio/ByteBuffer
> 
> In JDK-11, ByteBuffer::rewind overrides rewind with a compatible return
> type: ByteBuffer. JDK-8 declares Buffer::rewind to be final and the
> return type is Buffer, so there is not an override.
> 
> I'm okay with your cast because we know that 'fragment' is of type
> ByteBuffer and rewind won't change that -in fact, it returns 'this'-. I
> do not expect a runtime failure here and there shouldn't be a noticeable
> performance impact either.
> 
O, Thank you.
It is interesting. I?ve missed changes in final declaration between JDK8 and JDK11

>>> 
>>> * HandshakeHash.java
>> Thank you
>> You are absolutely right. I have to use JDK8 implementation of digestKey
>> Fixed
> 
> Can we apply JDK-11's approach with MessageDigestSpi2?

OK. I did not apply JDK11 approach because of changes outside of sun.security.ssl
Also, this code is for SSLv3.0 only and marked as subject to remove in the future.
But OK. I?ve backported JDK-8165275 [4], so it is similar to JDK11 now. It?ll make easy
to backport TLS and PKCS11 functionality
This backport adds changes in classes:
java/security/MessageDigest.java - changed
sun/security/pkcs11/P11Digest.java - changed
sun/security/util/MessageDigestSpi2.java - added
sun/security/ssl/HandshakeHash.java - no changes, identical to JDK11

> 
>>> * JsseJce.java
>>> 
>>> Have you considered backporting SecurityConstants.java part of 8130181
>>> [5] and use PROVIDER_VER in JsseJce.java
>>> 
>> Thank you. Fixed.
>> PROVIDER_VER is added to SecurityConstants.
>> SunJSSE.jave is also updated
> 
> Can't we use JDK-11's approach with
> "GetPropertyAction.privilegedGetProperty("java.specification.version");"? I
> guess the string is not exactly the same and you want to keep JDK-8
> compatibility here. But please confirm the reason so we leave a record.
There are several reasons I do not like JDK11 approach here:
1. JDK11 and later have the same code base, so PROVIDER_VER from system property
 has clear advantage - correct value for every JDK11+ version.
It is not a case for JDK8.
Provider class in JD8 does not allow version as String, so we have to convert it to double.
 It means we still have different code in JDK8 and JDK11+
2. JDK8 code base will not be used for later JDK versions, so no reasons to create
 PROVIDER_VER from system property
3. Additional unnecessary code to read system property, and convert it to double

> 
>> 
>>> * SSLLogger.java
>>> 
>>> Can't we leverage on PlatformLogger values directly? For each value,
>>> there should be a corresponding one. In case there is a good reason why
>>> not, we might want to think of moving the code to a more reusable place.
>> 
>> I have updated it to use java.util.logging.Logger
>> Internal Level enum is changed to java.util.logging.Level
>> Also, I?ve made possible to register app Logger. It was not possible in the first version.
> 
> Looks good to me. Well done! Remind me of asking for log examples at the
> end of this series :-)
> 
>>> 
>>> * RandomCookie.java / RenegoInfoExtension.java
>>> 
>>> Have you analyzed the performance implication of not having vectorized /
>>> intrinsics for the comparison?
>> 
>> No, I did not analyzed it. I understand possible performance impact but it could be
>> optimized later.
>> 
> 
> Right. Given the effort and risk involved in the 'vectorized' backport,
> I won't suggest it now. However, we should keep an eye on this and if
> any performance downgrade is noticed, here we have something to look at.
> The RandomCookie use is for a few bytes only, so it shouldn't be a big
> deal. The Renegotiation Extension does not look like a big deal either,
> at first glance at least.
> 
>>> 
>>> * SSLSessionContextImpl.java
>>> 
>>> Can't we use GetPropertyAction::privilegedGetProperty?
>> 
>> I have updated it as recommended in the JDK8 GetIntegerAction class
>> 
> 
> Even though the documentation gives an example with an Integer cast and
> an intValue call, that shouldn't be necessary.

Thank you. Updated.

> 
>>> 
>>> * X509TrustManagerImpl.java
>>> 
>>> Why is this change needed?
>>> 
>> ExtendedSSLSession does not contain getStatusResponses() public API method.
>> This method is part of JEP-249 : OCSP Stapling for TLS [1]
>> It is possible to implement and use OCSP Stapling without public API.
>> However, these changes should be moved to the step responsible for
>> OCSP stapling support - JDK-8245473
>> 
>> Fixed
> 
> Good.
> 
> 


[1] - http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245469/webrev.v0/src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java.udiff.html
[2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011799.html
[3] - http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245470/webrev.v1/src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java.udiff.html
[4] - https://bugs.openjdk.java.net/browse/JDK-8165275



From adinn at redhat.com  Tue Jun  2 10:20:28 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 2 Jun 2020 11:20:28 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
Message-ID: <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>

Hi Denghui,

On 02/06/2020 08:22, Denghui Dong wrote:
> Hi,
> Could I have a review of this small patch that deletes the commented-out
> code about?ModuleEntry?andPackageEntry?in?JFR.
> Most of the deleted code is commented out, except?
> ```
> <XmlType?name="Package"?parameterType="const?PackageEntry*"?fieldType="const?PackageEntry*"/>
> ```
> in?metadata.xml.
> PackageEntry doesn't exist in 8u, so it's safe to delete this line.
> 
> Bugs:?https://bugs.openjdk.java.net/browse/JDK-8246310
> Webrev:?http://cr.openjdk.java.net/~ddong/8246310/webrev.00/
> Testing: jdk/jfr, no extra failure

Thanks. This is a good thing to get out of the way first.

The deletions all look fine. However, you missed a few things (I am
using line numbers in the /original/ file):

  jfrTypeSet.cpp:171-193 (method write__artifact__package())

  jfrTypeSet.cpp:295 (declaration of method package_symbols())

  jfrTypeSet.cpp:349-393 (template methods package_symbols() and
module_symbols())

  jfrWriterHost.inline.hpp:36 (include of typeArrayOop.inline.hpp)

I don't need to see another webrev,

regards,


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


From denghui.ddh at alibaba-inc.com  Tue Jun  2 11:26:36 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Tue, 02 Jun 2020 19:26:36 +0800
Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gODI0NjMxMCA6IENsZWFuIGNvbW1lbnRlZC1vdXQgY29kZSBhYm91?=
 =?UTF-8?B?dCBNb2R1bGVFbnRyeSBhbmRQYWNrYWdlRW50cnkgaW4gSkZS?=
In-Reply-To: <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>,
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
Message-ID: <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>

Thank you!

Webrev has been updated. Some other related code missing in the previous patch was also removed in the new patch.

Denghui Dong
------------------------------------------------------------------
From:Andrew Dinn <adinn at redhat.com>
Send Time:2020?6?2?(???) 18:20
To:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrey Petushkov <andrey at azul.com>
Subject:Re: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry andPackageEntry in JFR

Hi Denghui,

On 02/06/2020 08:22, Denghui Dong wrote:
> Hi,
> Could I have a review of this small patch that deletes the commented-out
> code about ModuleEntry andPackageEntry in JFR.
> Most of the deleted code is commented out, except 
> ```
> <XmlType name="Package" parameterType="const PackageEntry*" fieldType="const PackageEntry*"/>
> ```
> in metadata.xml.
> PackageEntry doesn't exist in 8u, so it's safe to delete this line.
> 
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8246310
> Webrev: http://cr.openjdk.java.net/~ddong/8246310/webrev.00/
> Testing: jdk/jfr, no extra failure

Thanks. This is a good thing to get out of the way first.

The deletions all look fine. However, you missed a few things (I am
using line numbers in the /original/ file):

  jfrTypeSet.cpp:171-193 (method write__artifact__package())

  jfrTypeSet.cpp:295 (declaration of method package_symbols())

  jfrTypeSet.cpp:349-393 (template methods package_symbols() and
module_symbols())

  jfrWriterHost.inline.hpp:36 (include of typeArrayOop.inline.hpp)

I don't need to see another webrev,

regards,


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

From adinn at redhat.com  Tue Jun  2 12:25:34 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 2 Jun 2020 13:25:34 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
Message-ID: <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>

On 02/06/2020 12:26, Denghui Dong wrote:
> Thank you!
> 
> Webrev has been updated. Some other related code missing in the previous
> patch was also removed in the new patch.
Ok, I think that counts as reviewed.

I am not sure if it can be pushed just yet. jdk8u-dev was frozen
yesterday and I have not see a note from Andrew Hughes to say it has
been re-opened. Perhaps he can confirm.

regards,


Andrew Dinn
-----------


From mbalao at redhat.com  Tue Jun  2 15:56:26 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 2 Jun 2020 12:56:26 -0300
Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues
In-Reply-To: <0F659D7C-38CD-4E55-83F1-B16BB4A5C95D@azul.com>
References: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com>
 <13d50c06-6c26-2f78-9d09-0408b7725b6e@redhat.com>
 <70AC9E7E-280D-412D-AA4C-A527DCC87165@azul.com>
 <3a2914a8-6286-a5cb-5229-bf7e64166fc9@redhat.com>
 <0F659D7C-38CD-4E55-83F1-B16BB4A5C95D@azul.com>
Message-ID: <9f6cf6ca-4e62-2ce9-69fe-9b68dca5c9f3@redhat.com>

Hi,

Step 3 (8245470) is a series of assorted changes needed to adapt the
newly imported JDK 11.0.7 code to JDK-8. Many of the issues fixed by
Step 3 were found at compilation time. To name a few examples, there are
changes needed because some APIs -such as List::of- used by 11.0.7 code
are not available in JDK-8. We required idioms to consistently replace
these APIs. Other changes are because packages are located in different
directories in JDK-8. In example, sun.security.util.HexDumpEncoder is
sun.misc.HexDumpEncoder. Then we have changes needed to adapt the code
to the JDK-8 logging system and so on.

Note: it's still not the goal of Step 3 to fix all compilation errors.
That will come in a later step.

Note 2: previous comments that are part of this review can be found here
[1] [2].

This is the list of files affected by 8245470 (Step 3):

 * classes/sun/security/ssl/CertSignAlgsExtension.java (modified)
  * Ok
 * classes/sun/security/ssl/CertStatusExtension.java (modified)
  * Ok
 * classes/sun/security/ssl/CertificateVerify.java (modified)
  * Ok
 * classes/sun/security/ssl/CookieExtension.java (modified)
  * Ok
 * classes/sun/security/ssl/DHClientKeyExchange.java (modified)
  * Ok
 * classes/sun/security/ssl/DHServerKeyExchange.java (modified)
  * Ok
 * classes/sun/security/ssl/ECDHClientKeyExchange.java (modified)
  * Ok
 * classes/sun/security/ssl/ECDHServerKeyExchange.java (modified)
  * Ok
 * classes/sun/security/ssl/Finished.java (modified)
  * Ok
 * classes/sun/security/ssl/HandshakeContext.java (modified)
  * Ok
 * classes/sun/security/ssl/HandshakeHash.java (modified)
  * Ok - No changes in v2
 * classes/sun/security/ssl/JsseJce.java (modified)
  * Ok - No changes in v2
 * classes/sun/security/ssl/KeyShareExtension.java (modified)
  * Ok
 * classes/sun/security/ssl/PredefinedDHParameterSpecs.java (modified)
  * Ok
 * classes/sun/security/ssl/RSAClientKeyExchange.java (modified)
  * Ok
 * classes/sun/security/ssl/RSAServerKeyExchange.java (modified)
  * Ok
 * classes/sun/security/ssl/RandomCookie.java (modified)
  * Ok. No vectorization optimizations but okay for now.
 * classes/sun/security/ssl/RenegoInfoExtension.java (modified)
  * Ok. See comment in RandomCookie.java
 * classes/sun/security/ssl/SSLCipher.java (modified)
  * Ok
 * classes/sun/security/ssl/SSLEngineInputRecord.java (modified)
  * Ok
 * classes/sun/security/ssl/SSLExtension.java (modified)
  * Ok
 * classes/sun/security/ssl/SSLExtensions.java (modified)
  * Ok
 * classes/sun/security/ssl/SSLLogger.java (modified)
  * Ok. Backported to JDK-8 logging system.
 * classes/sun/security/ssl/SSLSessionContextImpl.java (modified)
  * Ok
 * classes/sun/security/ssl/SSLSocketImpl.java (modified)
  * Ok
 * classes/sun/security/ssl/SSLSocketInputRecord.java (modified)
  * Ok
 * classes/sun/security/ssl/SignatureAlgorithmsExtension.java (modified)
  * Ok
 * classes/sun/security/ssl/TransportContext.java (modified)
  * Ok
 * classes/sun/security/ssl/Utilities.java (modified)
  * Ok
 * classes/sun/security/ssl/X509TrustManagerImpl.java (modified)
  * Ok. Not modified in v2.
 * classes/java/security/MessageDigest.java (modified)
  * Ok
 * classes/sun/security/pkcs11/P11Digest.java (modified)
  * Ok
 * classes/sun/security/ssl/BaseSSLSocketImpl.java (modified)
  * Ok

With that said, Step 3 (8245470) v2 looks good to me. Please hold on the
push until we review-approve and maintainer-approve the whole series.

Thanks,
Martin.-

--
[1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011831.html
[2] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011843.html


From mbalao at redhat.com  Tue Jun  2 16:34:22 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 2 Jun 2020 13:34:22 -0300
Subject: [8u] TLSv1.3 RFR: 8245471: Revert JDK-8148188
In-Reply-To: <747A85CF-F4F9-48C2-8218-6B5D94D09BD0@azul.com>
References: <747A85CF-F4F9-48C2-8218-6B5D94D09BD0@azul.com>
Message-ID: <d95935ee-3fd9-810e-17e3-8b1f9fcad79c@redhat.com>

On 5/21/20 10:42 AM, Alexey Bakhtin wrote:
> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u
> 

Hi Alexey,

 * classes/sun/security/ssl/Finished.java
  * "import javax.net.ssl.SSLPeerUnverifiedException;" should probably
be removed. I don't see it being required in the future either -for
anything different than 8148188-.

Thanks,
Martin.-


From alexey at azul.com  Tue Jun  2 17:42:47 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 2 Jun 2020 17:42:47 +0000
Subject: [8u] TLSv1.3 RFR: 8245471: Revert JDK-8148188
In-Reply-To: <d95935ee-3fd9-810e-17e3-8b1f9fcad79c@redhat.com>
References: <747A85CF-F4F9-48C2-8218-6B5D94D09BD0@azul.com>
 <d95935ee-3fd9-810e-17e3-8b1f9fcad79c@redhat.com>
Message-ID: <3593ADFE-862A-4192-84DA-656DEAA48413@azul.com>

Hello Martin,

You are right. Fixed.

Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245471/webrev.v1/

Regards
Alexey

> On 2 Jun 2020, at 19:34, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 5/21/20 10:42 AM, Alexey Bakhtin wrote:
>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u
>> 
> 
> Hi Alexey,
> 
> * classes/sun/security/ssl/Finished.java
>  * "import javax.net.ssl.SSLPeerUnverifiedException;" should probably
> be removed. I don't see it being required in the future either -for
> anything different than 8148188-.
> 
> Thanks,
> Martin.-
> 


From mbalao at redhat.com  Tue Jun  2 18:12:46 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 2 Jun 2020 15:12:46 -0300
Subject: [8u] TLSv1.3 RFR: 8245471: Revert JDK-8148188
In-Reply-To: <747A85CF-F4F9-48C2-8218-6B5D94D09BD0@azul.com>
References: <747A85CF-F4F9-48C2-8218-6B5D94D09BD0@azul.com>
Message-ID: <448f3624-6326-de43-a892-1702e04212fd@redhat.com>

On 5/21/20 10:42 AM, Alexey Bakhtin wrote:
> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u

Hi,

Step 4 (8245471) is needed because a change from 8148188 was introduced
when importing the file sun/security/ssl/Finished.java from 11.0.7. Most
of 8148188 changes are out of sun/security/ssl so its backport will be
handled separately from TLS 1.3 backport.

 * No changes from 8148188 out of sun/security/ssl other than Finished.java
  * Ok

 * Finished.java changes reverted
  * Ok

Note: comment here [1] is part of this review.

With that said, Step 4 (8245471) v1 looks good to me. Please hold on the
push until all changes in this series are review-approved and
maintainer-approved.

Thanks,
Martin.-

--
[1] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011851.html


From akashche at redhat.com  Tue Jun  2 19:03:52 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 2 Jun 2020 20:03:52 +0100
Subject: [8u] RFR: 8072722: add stream support to Scanner
Message-ID: <920b858d-e13e-5c74-7e1c-f22331647fb9@redhat.com>

Hi,

Note: the subject is misleading regarding 8u, there are no intentions to 
actually change public API of Scanner in 8u, only internal changes are 
backported.

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

Jira issue: https://bugs.openjdk.java.net/browse/JDK-8072722

RFC thread: 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011826.html

9 commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b997ba72d8d4

8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8072722/webrev.00/

Backport depends on JDK-8132206 and JDK-8132745, that apply cleanly to 8u.

Change to Scanner includes only changes to private methods 
findPatternInBuffer and matchPatternInBuffer and their usage. These impl 
changes should allow to do the following Scanner backports more easy. 
New methods for stream support, modCount counter and spec changes are 
excluded.

Change to ScanTest includes everything except streamCloseTest() and 
streamComodTest() methods.

Testing: checked that ScanTest passes, ran relevant subset of JCK.

-- 
-Alex


From gnu.andrew at redhat.com  Wed Jun  3 00:29:26 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 3 Jun 2020 01:29:26 +0100
Subject: [RAMPDOWN] 8u open for 8u262 (jdk8u-critical-yes required) & 8u-dev
 open for 8u272 (jdk8u-fix-yes required)
Message-ID: <071ad37f-deaf-17c7-bd4e-9003ae83a26b@redhat.com>

8u-dev is now open for development on 8u272-b01. Pushes require
jdk8u-fix-yes as usual.

8u is now open until Friday, June 26th for critical fixes for 8u262.
Pushes required jdk8u-critical-yes and should be high priority fixes and
regressions.

Note that JFR is now enabled by default in 8u-dev for the October 2020
release of 8u272 (JDK-8246384)

For further details, including the full timeline, see the OpenJDK 8u wiki:

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

Thanks,
-- 
Andrew :)

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

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


From jaroslav.bachorik at datadoghq.com  Wed Jun  3 07:52:07 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 3 Jun 2020 09:52:07 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmZPwxVKNgvcgW1HH50c2D8CXZf9_Pu5SFBkC5_1jDY2tA@mail.gmail.com>
 <CAJwKKmZ_TFu0RDXnqxrfA4Rxaaq3hadQST8_ZuwGNAyKOsXBJQ@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
Message-ID: <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>

Hi!

On Fri, May 29, 2020 at 10:58 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 28/05/2020 17:25, Jaroslav Bachor?k wrote:
> > On Thu, May 28, 2020 at 3:10 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
> >>
> >>
> >>
> >> On 28/05/2020 13:34, Andrew Haley wrote:
> >>> On 28/05/2020 10:08, Jaroslav Bachor?k wrote:
> >>>> I guess so. But such a test is not a part of the original changeset.
> >>>> Is it necessary to be extending the scope of the original patch
> >>>> (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)?
> >>>
> >>> Yes please. 8u is old code, and your first task is not to break it. If
> >>> this involves being more defensive than upstream, that's fine. Class
> >>> initialization order at startup is notoriously sensitive and responsible
> >>> for breaking things in subtle ways.
> >>
> >> There's also no reason such a change could not then be forwardported to
> >> later versions. If a bug is filed for this, the 8u fix can be committed
> >> under both 8233197 & the new ID, and then the test change alone posted
> >> for review in later versions.
> >
> > Well, there might be a reason - there is no 'native test' support in
> > JDK 8 AFAIK. There are not even any JVMTI native agent jtreg tests -
> > so no harness for building a native agent (on all supported
> > platforms). And to be honest, I don't feel like writing all that
> > support from scratch. If I am missing something and there indeed is a
> > support for testing JVMTI agents, please let me know and I will add a
> > test.
>
> No problem. Like I said, there's no reason that 8u shouldn't have this
> even when upstream doesn't, and there's a very good reason we need it.

Thanks to Mario Torre for pointing me the right direction! I was able
to add a rudimentary test which exhibits JVM crash without this patch
applied and passes with this patch (with an exception and error
message as specified - no JVM crash).

Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.03/
(also including the requested indentation change)

BTW, since this patch missed the cutoff date for 8u262 mostly due to
review would it be ok to consider it still as a part of the critical
fix process?

Cheers,

-JB-

>
> --
> 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 jaroslav.bachorik at datadoghq.com  Wed Jun  3 08:40:48 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 3 Jun 2020 10:40:48 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
Message-ID: <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>

Hi,

would it be possible to move this forward? Also, since this patch is
adding quite valuable information to JFR recordings and it missed the
8u262 cutoff very narrowly would it be possible to even consider it as
a part of critical fix process?

Thanks!

-JB-

On Wed, May 27, 2020 at 1:46 PM Mario Torre <neugens at redhat.com> wrote:
>
> Hi Andrey,
>
> I went through the patch and it looks good.
>
> As we discussed offline, I have doubts and concerns about the handling
> in "package_from_name" of packages that start with L but this is part
> of the original patch and not specific to the backport, so I think
> this should be handled upstream later and explore if there are indeed
> issues.
>
> I'm CC'ing Andrew Haley and Andrew Dinn to request the approval and a
> second eye if necessary.
>
> Cheers,
> Mario
>
>
> On Mon, May 18, 2020 at 12:30 PM Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Dear All,
> >
> > please consider the following patch to add missing package information
> > into JFR backport
> > https://cr.openjdk.java.net/~apetushkov/8245167/
> >
> > Originally the package info was omitted due to dependency on jigsaw
> > functionality and hence it was thought it's not much relevant for jdk8.
> > However it turns out it's widely used (e.g. by JMC). So it makes sense
> > to implement it in jdk8-specific way
> >
> > The author of the code is Aleksei Semenov <asemenov at azul.com>
> >
> > Verified by JMC and jfr jtreg tests, including the fixed
> > jdk/jfr/event/runtime/TestClassLoadEvent
> >
> > Thanks,
> > Andrey
> >
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From adinn at redhat.com  Wed Jun  3 09:15:52 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 3 Jun 2020 10:15:52 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
Message-ID: <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>

On 02/06/2020 13:25, Andrew Dinn wrote:
> On 02/06/2020 12:26, Denghui Dong wrote:
>> Thank you!
>>
>> Webrev has been updated. Some other related code missing in the previous
>> patch was also removed in the new patch.
> Ok, I think that counts as reviewed.
> 
> I am not sure if it can be pushed just yet. jdk8u-dev was frozen
> yesterday and I have not see a note from Andrew Hughes to say it has
> been re-opened. Perhaps he can confirm.
Andrew Hughes has opened up the jdk8u repo today for critical fixes.

Clearly, this current patch is not in itself a critical fix. However, it
does pave the way for the follow-up JFR leak analysis fix. My view is
that the follow-up patch also should not be regarded as critical. The
performance problem the follow-up patch fixes can be avoided by not
using leak analysis. Clearly users of jdk8u should be able to continue
to operate their deployments without leak analysis if they are already
doing so.

So, I suggest that this patch and the follow-up are not pushed until
after the next jdk8u release. I'll be happy to review the follow-up once
you provide the extra requested details of the changes made.

Of course, I am not a jdk8u maintainer. If you disagree with me about
the criticality of these patches you can ask one of the maintainers to
comment.

regards,


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


From neugens at redhat.com  Wed Jun  3 09:41:48 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 3 Jun 2020 11:41:48 +0200
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
 <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
Message-ID: <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>

On Wed, Jun 3, 2020 at 11:18 AM Andrew Dinn <adinn at redhat.com> wrote:
>
> On 02/06/2020 13:25, Andrew Dinn wrote:
> > On 02/06/2020 12:26, Denghui Dong wrote:
> >> Thank you!
> >>
> >> Webrev has been updated. Some other related code missing in the previous
> >> patch was also removed in the new patch.
> > Ok, I think that counts as reviewed.
> >
> > I am not sure if it can be pushed just yet. jdk8u-dev was frozen
> > yesterday and I have not see a note from Andrew Hughes to say it has
> > been re-opened. Perhaps he can confirm.
> Andrew Hughes has opened up the jdk8u repo today for critical fixes.
>
> Clearly, this current patch is not in itself a critical fix. However, it
> does pave the way for the follow-up JFR leak analysis fix. My view is
> that the follow-up patch also should not be regarded as critical. The
> performance problem the follow-up patch fixes can be avoided by not
> using leak analysis. Clearly users of jdk8u should be able to continue
> to operate their deployments without leak analysis if they are already
> doing so.
>
> So, I suggest that this patch and the follow-up are not pushed until
> after the next jdk8u release. I'll be happy to review the follow-up once
> you provide the extra requested details of the changes made.
>
> Of course, I am not a jdk8u maintainer. If you disagree with me about
> the criticality of these patches you can ask one of the maintainers to
> comment.

We can push to jdk8u-dev normally, I understand this is open for
business as usual, so we don't need to wait the release. I agree the
patch is not critical for jdk8u (the actual July release), and given
the complexity we need more time.

Cheers,
Mario

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


From neugens at redhat.com  Wed Jun  3 09:46:00 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 3 Jun 2020 11:46:00 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
Message-ID: <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>

I think this should be in by release, so I support the use of a
critical fix label.

Cheers,
Mario

On Wed, Jun 3, 2020 at 10:41 AM Jaroslav Bachor?k
<jaroslav.bachorik at datadoghq.com> wrote:
>
> Hi,
>
> would it be possible to move this forward? Also, since this patch is
> adding quite valuable information to JFR recordings and it missed the
> 8u262 cutoff very narrowly would it be possible to even consider it as
> a part of critical fix process?
>
> Thanks!
>
> -JB-
>
> On Wed, May 27, 2020 at 1:46 PM Mario Torre <neugens at redhat.com> wrote:
> >
> > Hi Andrey,
> >
> > I went through the patch and it looks good.
> >
> > As we discussed offline, I have doubts and concerns about the handling
> > in "package_from_name" of packages that start with L but this is part
> > of the original patch and not specific to the backport, so I think
> > this should be handled upstream later and explore if there are indeed
> > issues.
> >
> > I'm CC'ing Andrew Haley and Andrew Dinn to request the approval and a
> > second eye if necessary.
> >
> > Cheers,
> > Mario
> >
> >
> > On Mon, May 18, 2020 at 12:30 PM Andrey Petushkov <andrey at azul.com> wrote:
> > >
> > > Dear All,
> > >
> > > please consider the following patch to add missing package information
> > > into JFR backport
> > > https://cr.openjdk.java.net/~apetushkov/8245167/
> > >
> > > Originally the package info was omitted due to dependency on jigsaw
> > > functionality and hence it was thought it's not much relevant for jdk8.
> > > However it turns out it's widely used (e.g. by JMC). So it makes sense
> > > to implement it in jdk8-specific way
> > >
> > > The author of the code is Aleksei Semenov <asemenov at azul.com>
> > >
> > > Verified by JMC and jfr jtreg tests, including the fixed
> > > jdk/jfr/event/runtime/TestClassLoadEvent
> > >
> > > Thanks,
> > > Andrey
> > >
> >
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >
>


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


From adinn at redhat.com  Wed Jun  3 10:03:22 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 3 Jun 2020 11:03:22 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
 <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
 <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>
Message-ID: <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>

On 03/06/2020 10:41, Mario Torre wrote:
> We can push to jdk8u-dev normally, I understand this is open for
> business as usual, so we don't need to wait the release. I agree the
> patch is not critical for jdk8u (the actual July release), and given
> the complexity we need more time.
Doh, yes! I misread Andrew's post.

So this patch can be pushed and the next one once the extra work is done
and checked.

regards,


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


From adinn at redhat.com  Wed Jun  3 10:08:03 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 3 Jun 2020 11:08:03 +0100
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
Message-ID: <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>

On 03/06/2020 10:46, Mario Torre wrote:
> I think this should be in by release, so I support the use of a
> critical fix label.

I'm happy with that even though I agree with Mario that the check for
names beginning with L in the original patch is over-restrictive. That L
could legitimately be the start of a package name. However, it is very
unlikely to affect any real code (package names don't usually start with
a capital letter) and if it does it will be little more than an
inconvenience.

regards,


Andrew Dinn
-----------


From andrey at azul.com  Wed Jun  3 10:15:10 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 3 Jun 2020 13:15:10 +0300
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
Message-ID: <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>

Hi Andrew,

This 'L' -checking code is activated only when the method in question is
given the array (i.e. the FQN of the class is something "[L...").
However the caller never applies the method to array classes, only
instance classes.
(and I've actually checked that "L.Main" class has appeared in the JMC's
"Top packages" window)

Andrey

On 03.06.2020 13:08, Andrew Dinn wrote:
> On 03/06/2020 10:46, Mario Torre wrote:
>> I think this should be in by release, so I support the use of a
>> critical fix label.
> I'm happy with that even though I agree with Mario that the check for
> names beginning with L in the original patch is over-restrictive. That L
> could legitimately be the start of a package name. However, it is very
> unlikely to affect any real code (package names don't usually start with
> a capital letter) and if it does it will be little more than an
> inconvenience.
>
> regards,
>
>
> Andrew Dinn
> -----------



From denghui.ddh at alibaba-inc.com  Wed Jun  3 10:49:54 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Wed, 03 Jun 2020 18:49:54 +0800
Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gODI0NjMxMCA6IENsZWFuIGNvbW1lbnRlZC1vdXQgY29kZSBhYm91?=
 =?UTF-8?B?dCBNb2R1bGVFbnRyeSBhbmRQYWNrYWdlRW50cnkgaW4gSkZS?=
In-Reply-To: <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
 <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
 <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>,
 <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>
Message-ID: <9770eb40-7c42-4d19-bf9d-7c555453ae6a.denghui.ddh@alibaba-inc.com>

Thanks.
Could I push it now or need to wait for the label "jdk8u-fix-yes"?

Denghui Dong


------------------------------------------------------------------
From:Andrew Dinn <adinn at redhat.com>
Send Time:2020?6?3?(???) 18:03
To:Mario Torre <neugens at redhat.com>
Cc:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry andPackageEntry in JFR

On 03/06/2020 10:41, Mario Torre wrote:
> We can push to jdk8u-dev normally, I understand this is open for
> business as usual, so we don't need to wait the release. I agree the
> patch is not critical for jdk8u (the actual July release), and given
> the complexity we need more time.
Doh, yes! I misread Andrew's post.

So this patch can be pushed and the next one once the extra work is done
and checked.

regards,


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

From neugens at redhat.com  Wed Jun  3 11:05:09 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 3 Jun 2020 13:05:09 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
Message-ID: <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>

On Wed, Jun 3, 2020 at 12:15 PM Andrey Petushkov <andrey at azul.com> wrote:
>
> Hi Andrew,
>
> This 'L' -checking code is activated only when the method in question is
> given the array (i.e. the FQN of the class is something "[L...").
> However the caller never applies the method to array classes, only
> instance classes.
> (and I've actually checked that "L.Main" class has appeared in the JMC's
> "Top packages" window)

Yeah, however it's not clear to me if this may change in the future
since the function has a side effect that it's not entirely specified,
that said however I think, if any, this is a bug in mainline and an
eventual fix should come in via an additional backport and not hold
this fix in 8u.

Can you perhaps send an email to jdk-dev to check?

Cheers,
Mario

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


From neugens at redhat.com  Wed Jun  3 11:08:10 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 3 Jun 2020 13:08:10 +0200
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <9770eb40-7c42-4d19-bf9d-7c555453ae6a.denghui.ddh@alibaba-inc.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
 <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
 <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>
 <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>
 <9770eb40-7c42-4d19-bf9d-7c555453ae6a.denghui.ddh@alibaba-inc.com>
Message-ID: <CAJwKKmaZxQjqisKzYQY2W-1b5VFMK0u6FEtS-mtQGj=AiN8Y8Q@mail.gmail.com>

Yeah, you still need to wait for the label.

I'm CC'ing Andrew Hughes for reference.

Cheers,
Mario

On Wed, Jun 3, 2020 at 12:50 PM Denghui Dong
<denghui.ddh at alibaba-inc.com> wrote:
>
> Thanks.
> Could I push it now or need to wait for the label "jdk8u-fix-yes"?
>
> Denghui Dong
>
> ------------------------------------------------------------------
> From:Andrew Dinn <adinn at redhat.com>
> Send Time:2020?6?3?(???) 18:03
> To:Mario Torre <neugens at redhat.com>
> Cc:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject:Re: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry andPackageEntry in JFR
>
> On 03/06/2020 10:41, Mario Torre wrote:
> > We can push to jdk8u-dev normally, I understand this is open for
> > business as usual, so we don't need to wait the release. I agree the
> > patch is not critical for jdk8u (the actual July release), and given
> > the complexity we need more time.
> Doh, yes! I misread Andrew's post.
>
> So this patch can be pushed and the next one once the extra work is done
> and checked.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill



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


From neugens at redhat.com  Wed Jun  3 11:15:48 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 3 Jun 2020 13:15:48 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmZPwxVKNgvcgW1HH50c2D8CXZf9_Pu5SFBkC5_1jDY2tA@mail.gmail.com>
 <CAJwKKmZ_TFu0RDXnqxrfA4Rxaaq3hadQST8_ZuwGNAyKOsXBJQ@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
Message-ID: <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>

On Wed, Jun 3, 2020 at 9:52 AM Jaroslav Bachor?k
<jaroslav.bachorik at datadoghq.com> wrote:
> Thanks to Mario Torre for pointing me the right direction! I was able
> to add a rudimentary test which exhibits JVM crash without this patch
> applied and passes with this patch (with an exception and error
> message as specified - no JVM crash).
>
> Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.03/
> (also including the requested indentation change)

There's something weird about this:
--- a/test/runtime/8001071/Test8001071.sh
+++ b/test/runtime/8233197/Test8233197.sh

It's registered as a copy/replacement. I think it should be a new file though.

One more nit, is that you don't need the printfs, i.e.:

printf("Agent_OnLoad\n");

The test case looks good otherwise for our purposes, but I'll let
Andrew have the final words.

> BTW, since this patch missed the cutoff date for 8u262 mostly due to
> review would it be ok to consider it still as a part of the critical
> fix process?

I most certainly support this.

Cheers,
Mario

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


From aph at redhat.com  Wed Jun  3 12:19:19 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 3 Jun 2020 13:19:19 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
Message-ID: <02dc03b4-defb-113f-91e7-4016450b29c3@redhat.com>

On 02/06/2020 11:20, Andrew Dinn wrote:
> I don't need to see another webrev,

The bug entry doesn't explain why the 8u backport is necessary. It must
do so. This is true for all backports.

-- 
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 aph at redhat.com  Wed Jun  3 12:51:04 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 3 Jun 2020 13:51:04 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
 <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
 <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>
 <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>
Message-ID: <3ea8e4e9-9aba-50b1-2c05-2dd63593e36c@redhat.com>

On 03/06/2020 11:03, Andrew Dinn wrote:
> So this patch can be pushed and the next one once the extra work is done
> and checked.

It looks like you know why this is necessary for jdk8u. If so, please
feel free to add the justification to the bug report and I'll approve
it.

-- 
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 adinn at redhat.com  Wed Jun  3 13:16:21 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 3 Jun 2020 14:16:21 +0100
Subject: [8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry
 andPackageEntry in JFR
In-Reply-To: <3ea8e4e9-9aba-50b1-2c05-2dd63593e36c@redhat.com>
References: <2ca61fbf-1978-4d7a-a891-223f9be74962.denghui.ddh@alibaba-inc.com>
 <eccaca80-f6b3-9710-3bb3-cc867b481e6a@redhat.com>
 <60c2afef-33a6-439e-ab89-cca0c3874df1.denghui.ddh@alibaba-inc.com>
 <6434b6cc-65ad-08a3-c9f3-6201bf6b9c75@redhat.com>
 <ea6af0e4-93f6-316f-0899-31f9178950b8@redhat.com>
 <CAJwKKmZp8x+78R82+S3TExCYEUCmZPvQsD1UpnJY7h+Y3rbfsA@mail.gmail.com>
 <85928a0a-9709-cd9b-caa2-3ea4ef490e79@redhat.com>
 <3ea8e4e9-9aba-50b1-2c05-2dd63593e36c@redhat.com>
Message-ID: <1a45febc-9da0-1351-8c5c-cde4ad6cda80@redhat.com>



On 03/06/2020 13:51, Andrew Haley wrote:
> On 03/06/2020 11:03, Andrew Dinn wrote:
>> So this patch can be pushed and the next one once the extra work is done
>> and checked.
> 
> It looks like you know why this is necessary for jdk8u. If so, please
> feel free to add the justification to the bug report and I'll approve
> it.
I have updated JDK-8246310 with a rationale for the fix request.

regards,


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


From aph at redhat.com  Wed Jun  3 14:25:45 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 3 Jun 2020 15:25:45 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
Message-ID: <c56849de-8371-7867-c388-d1cd21596b07@redhat.com>

On 03/06/2020 08:52, Jaroslav Bachor?k wrote:
> BTW, since this patch missed the cutoff date for 8u262 mostly due to
> review would it be ok to consider it still as a part of the critical
> fix process?

Yes, but why is "Without this patch JVM will crash if a recording is
started from agent premain" important? Is that something that
frequently happens?

-- 
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 neugens at redhat.com  Wed Jun  3 14:32:29 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 3 Jun 2020 16:32:29 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <c56849de-8371-7867-c388-d1cd21596b07@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <c56849de-8371-7867-c388-d1cd21596b07@redhat.com>
Message-ID: <CAJwKKmZKZApFMSfW1s=c_cZyvTs_e59r1gANgv1++ZwstAgAZg@mail.gmail.com>

On Wed, Jun 3, 2020 at 4:25 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 03/06/2020 08:52, Jaroslav Bachor?k wrote:
> > BTW, since this patch missed the cutoff date for 8u262 mostly due to
> > review would it be ok to consider it still as a part of the critical
> > fix process?
>
> Yes, but why is "Without this patch JVM will crash if a recording is
> started from agent premain" important? Is that something that
> frequently happens?

I'll let Jaroslav discuss the use case in details, but some tools that
retrieve system performance statistics may want to install themselves
via an agent. I think requiring the JFR subsystem to be available only
after pre-main is a bug, JFR should be there at JVM startup already,
or, in the worst case, not be available but also not core dump the
jvm.

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 jaroslav.bachorik at datadoghq.com  Wed Jun  3 14:55:30 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 3 Jun 2020 16:55:30 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <c56849de-8371-7867-c388-d1cd21596b07@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <c56849de-8371-7867-c388-d1cd21596b07@redhat.com>
Message-ID: <CAPb8aJ5H9PxrZU=bM-MLA3h7D_c201=6C3xJiO+vasbNPUUE5g@mail.gmail.com>

On Wed, Jun 3, 2020 at 4:25 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 03/06/2020 08:52, Jaroslav Bachor?k wrote:
> > BTW, since this patch missed the cutoff date for 8u262 mostly due to
> > review would it be ok to consider it still as a part of the critical
> > fix process?
>
> Yes, but why is "Without this patch JVM will crash if a recording is
> started from agent premain" important? Is that something that
> frequently happens?

I don't know about the frequency but it basically prevents dynamically
turning on JFR recording and reliably collecting the startup data.

-JB-

>
> --
> 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  Wed Jun  3 16:26:26 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 03 Jun 2020 18:26:26 +0200
Subject: FYI: jdk8u262-b05 fails to build on Windows
Message-ID: <e70859fc55a289a3602b9b8d3d0a72c91c746d7a.camel@redhat.com>

Hi,

We've noticed that the latest build promotion of jdk8u/jdk8u -
jdk8u262-b05 - doesn't build on Windows. The issue is being tracked by:

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

The cause is a recent backport:
https://bugs.openjdk.java.net/browse/JDK-8227269

We are looking into it.

Thanks,
Severin


From mbalao at redhat.com  Wed Jun  3 19:11:19 2020
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 3 Jun 2020 16:11:19 -0300
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
Message-ID: <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>

On 5/21/20 10:54 AM, Alexey Bakhtin wrote:
> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u

Hi,

I've some concerns regarding this proposal.

My understanding is that the need for a JDK-8 backport of 8038893
derives -originally- from the fact that the file
sun/security/ssl/X509TrustManagerImpl.java (imported to JDK-8 by 'file
replacement') includes some changes from it. So this crosses the
sun/security/ssl boundary and has to be handled either by removing
8038893 traces from X509TrustManagerImpl.java or backporting it fully.

You've taken the decision of backporting 8038893 instead of removing it
from X509TrustManagerImpl.java. What are the reasons behind that? And
what would be the cons of the opposite approach? I'm still trying to
understand that but your input would be appreciated.

I don't want to get into the patch specifics before being clear on the
previous. However, at first glance, looks to me that the patch is taking
changes from 8201815 and omitting changes in 8038893. This leads to the
existence of two RegisteredDomain.java files in JDK-8. This may not be a
problem on its own but reveals that there can be unintended and
overlooked consequences. Given that we are out of sun/security/ssl, we
would probably want full and independent backports if we decide to go
that way.

Thanks,
Martin.-


From jvanek at redhat.com  Wed Jun  3 20:01:16 2020
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 3 Jun 2020 22:01:16 +0200
Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all
 over the place
In-Reply-To: <e026a9d6-f667-b940-ed7e-424ad4149e1c@redhat.com>
References: <b2d7006c-ccea-72fc-ee6d-7e05c2354f84@redhat.com>
 <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com>
 <bce3bd1d-1d9d-868d-7a81-eda998e73fe1@redhat.com>
 <a55bcd92-123f-6e4a-8666-b4d5d436df13@redhat.com>
 <e026a9d6-f667-b940-ed7e-424ad4149e1c@redhat.com>
Message-ID: <f098bba8-715a-7c4a-16dd-5cfcfd6b671f@redhat.com>

ping?
On 5/21/20 8:43 AM, Jiri Vanek wrote:
> ping
> 
> please do not let it rot!
> On 5/19/20 2:32 PM, Jiri Vanek wrote:
>> On 5/19/20 9:44 AM, Jiri Vanek wrote:
>>> On 5/19/20 3:24 AM, Andrew Hughes wrote:
>>>>
>>>>
>>>> On 18/05/2020 15:03, Jiri Vanek wrote:
>>>>> hi!
>>>>>
>>>>> This is third, hopefully last, reincarnation of this backport.
>>>>> Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time.
>>>>> It is  jdk11-like version of the patch.
>>>>>
>>>>> However after above was agreed, an issue concerning backport of
>>>>> https://bugs.openjdk.java.net/browse/JDK-8168772 (
>>>>> http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised.
>>>>>
>>>>> If there is no intention to backport 8168772  ever, then my current patch is good to go. If not,
>>>>> then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was
>>>>> commited, but 8168772 have to follow after it.
>>>>> I do not feel exactly voulenteered ino backporting of 8168772
>>>>>
>>>>> Thanx!
>>>>>   J.
>>>>>
>>>>
>>>> Thanks for looking into this again.
>>>>
>>>> I'll have a look at the feasibility of JDK-8168772 and get back to you.
>>>>
>>>> I'm tending towards just applying this as previously reviewed, but it
>>>> may be that JDK-8168772, though long, applies nearly cleanly and it's
>>>> preferable to have 8u & 11u working the same.
>>>
>>> Ok. Will try that too. Thanx!
>> Afer applying 8154313 as jdk8 as possible, applying 8168772:
>>
>> atching file common/autoconf/generated-configure.sh
>> Hunk #1 FAILED at 5093.
>> 1 out of 1 hunk FAILED -- saving rejects to file common/autoconf/generated-configure.sh.rej
>> patching file common/autoconf/spec.gmk.in
>> Hunk #1 FAILED at 265.
>> Hunk #2 FAILED at 788.
>> 2 out of 2 hunks FAILED -- saving rejects to file common/autoconf/spec.gmk.in.rej
>> patching file make/Javadoc.gmk
>> Hunk #1 FAILED at 22.
>> Hunk #2 FAILED at 171.
>> Hunk #3 FAILED at 355.
>> Hunk #4 FAILED at 1742.
>> 4 out of 4 hunks FAILED -- saving rejects to file make/Javadoc.gmk.rej
>> patching file make/Main.gmk
>> Hunk #1 FAILED at 341.
>> Hunk #2 FAILED at 683.
>> Hunk #3 FAILED at 812.
>> Hunk #4 FAILED at 860.
>> Hunk #5 FAILED at 872.
>> Hunk #6 FAILED at 911.
>> 6 out of 6 hunks FAILED -- saving rejects to file make/Main.gmk.rej
>> can't find file to patch at input line 2731
>> Perhaps you used the wrong -p or --strip option?
>> The text leading up to this was:
>> --------------------------
>> |diff -r f37e46c2e8f6 -r db49e4e492e0 make/MainSupport.gmk
>> |--- a/make/MainSupport.gmk	Wed Oct 26 09:44:20 2016 +0200
>> |+++ b/make/MainSupport.gmk	Wed Oct 26 16:00:26 2016 +0200
>> --------------------------
>> File to patch:
>> Skip this patch? [y] y
>> Skipping patch.
>> 2 out of 2 hunks ignored
>>
>>
>> That backport moreover means to rewrite it.
>>>>
>>>> Thanks,
>>>>
>>>
>>>
>>
>>
> 
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com    M: +420775390109


From gnu.andrew at redhat.com  Wed Jun  3 20:48:47 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 3 Jun 2020 21:48:47 +0100
Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all
 over the place
In-Reply-To: <f098bba8-715a-7c4a-16dd-5cfcfd6b671f@redhat.com>
References: <b2d7006c-ccea-72fc-ee6d-7e05c2354f84@redhat.com>
 <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com>
 <bce3bd1d-1d9d-868d-7a81-eda998e73fe1@redhat.com>
 <a55bcd92-123f-6e4a-8666-b4d5d436df13@redhat.com>
 <e026a9d6-f667-b940-ed7e-424ad4149e1c@redhat.com>
 <f098bba8-715a-7c4a-16dd-5cfcfd6b671f@redhat.com>
Message-ID: <8d7761ca-e14a-2e47-93fe-cdbf7140b55d@redhat.com>



On 03/06/2020 21:01, Jiri Vanek wrote:
> ping?
> On 5/21/20 8:43 AM, Jiri Vanek wrote:
>> ping
>>
>> please do not let it rot!
>> On 5/19/20 2:32 PM, Jiri Vanek wrote:
>>> On 5/19/20 9:44 AM, Jiri Vanek wrote:
>>>> On 5/19/20 3:24 AM, Andrew Hughes wrote:
>>>>>
>>>>>
>>>>> On 18/05/2020 15:03, Jiri Vanek wrote:
>>>>>> hi!
>>>>>>
>>>>>> This is third, hopefully last, reincarnation of this backport.
>>>>>> Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time.
>>>>>> It is  jdk11-like version of the patch.
>>>>>>
>>>>>> However after above was agreed, an issue concerning backport of
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8168772 (
>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised.
>>>>>>
>>>>>> If there is no intention to backport 8168772  ever, then my current patch is good to go. If not,
>>>>>> then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was
>>>>>> commited, but 8168772 have to follow after it.
>>>>>> I do not feel exactly voulenteered ino backporting of 8168772
>>>>>>
>>>>>> Thanx!
>>>>>>   J.
>>>>>>
>>>>>
>>>>> Thanks for looking into this again.
>>>>>
>>>>> I'll have a look at the feasibility of JDK-8168772 and get back to you.
>>>>>
>>>>> I'm tending towards just applying this as previously reviewed, but it
>>>>> may be that JDK-8168772, though long, applies nearly cleanly and it's
>>>>> preferable to have 8u & 11u working the same.
>>>>
>>>> Ok. Will try that too. Thanx!
>>> Afer applying 8154313 as jdk8 as possible, applying 8168772:
>>>
>>> atching file common/autoconf/generated-configure.sh
>>> Hunk #1 FAILED at 5093.
>>> 1 out of 1 hunk FAILED -- saving rejects to file common/autoconf/generated-configure.sh.rej
>>> patching file common/autoconf/spec.gmk.in
>>> Hunk #1 FAILED at 265.
>>> Hunk #2 FAILED at 788.
>>> 2 out of 2 hunks FAILED -- saving rejects to file common/autoconf/spec.gmk.in.rej
>>> patching file make/Javadoc.gmk
>>> Hunk #1 FAILED at 22.
>>> Hunk #2 FAILED at 171.
>>> Hunk #3 FAILED at 355.
>>> Hunk #4 FAILED at 1742.
>>> 4 out of 4 hunks FAILED -- saving rejects to file make/Javadoc.gmk.rej
>>> patching file make/Main.gmk
>>> Hunk #1 FAILED at 341.
>>> Hunk #2 FAILED at 683.
>>> Hunk #3 FAILED at 812.
>>> Hunk #4 FAILED at 860.
>>> Hunk #5 FAILED at 872.
>>> Hunk #6 FAILED at 911.
>>> 6 out of 6 hunks FAILED -- saving rejects to file make/Main.gmk.rej
>>> can't find file to patch at input line 2731
>>> Perhaps you used the wrong -p or --strip option?
>>> The text leading up to this was:
>>> --------------------------
>>> |diff -r f37e46c2e8f6 -r db49e4e492e0 make/MainSupport.gmk
>>> |--- a/make/MainSupport.gmk	Wed Oct 26 09:44:20 2016 +0200
>>> |+++ b/make/MainSupport.gmk	Wed Oct 26 16:00:26 2016 +0200
>>> --------------------------
>>> File to patch:
>>> Skip this patch? [y] y
>>> Skipping patch.
>>> 2 out of 2 hunks ignored
>>>
>>>
>>> That backport moreover means to rewrite it.
>>>>>
>>>>> Thanks,
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 

I haven't had a chance to look at JDK-8168772. I'll try some time in the
8u272 dev cycle, but this next month will be busy with the CPU.

Yeah, the build systems have diverged a lot, though I'm surprised there
is so much change here just in OpenJDK 9.  If JDK-8154313 is applied
first, why do we need JDK-8168772?

Thanks,
-- 
Andrew :)

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

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


From akashche at redhat.com  Wed Jun  3 20:50:02 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 3 Jun 2020 21:50:02 +0100
Subject: [8u] RFR: 8246223: Windows build fails after JDK-8227269
Message-ID: <dbbeeeee-8368-65e8-8d2b-d7d3532ceaeb@redhat.com>

Hi,

Please review the fix to JDK-8246223:

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

Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8246223/webrev.00/

Problem appeared to be caused by C99 syntax used in JDK-8227269 that is 
not supported by VS2010 compiler (newer VS versions were not affected).

This patch fixes the compatibility of classTrack.c with C89 moving 
variable declarations to the beginning of corresponding scope blocks.

Testing: checked that it can be compiled with VS2010 and newer toolchains.

-- 
-Alex


From gnu.andrew at redhat.com  Wed Jun  3 20:59:30 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 3 Jun 2020 21:59:30 +0100
Subject: OpenJDK 8u262-b05 EA Released
Message-ID: <95ffcc5b-272f-c8ae-8490-569f27d35010@redhat.com>

I've made available an early access source bundle for 8u262, based on
the tag jdk8u262-b05:

https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b05-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b05-ea.tar.xz.sig

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

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

SHA256 checksums:

f2118c76b17e749d2a46abeaaf13433b88309c7b5f8a77ea9292bae78f1afc2b
openjdk8u262-b05-ea.tar.xz
d98a906109041b6892b9024f2737b01c2e8ec229c9d455f6aef9a81ab1801c68
openjdk8u262-b05-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b05-ea.sha256

Changes in 8u262-b05:
  - JDK-7147060:
com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java
doesn't run in agentvm mode
  - JDK-8178374: Problematic ByteBuffer handling in
CipherSpi.bufferCrypt method
  - JDK-8181841: A TSA server returns timestamp with precision higher
than milliseconds
  - JDK-8227269: Slow class loading when running with JDWP
  - JDK-8229899: Make java.io.File.isInvalid() less racy
  - JDK-8236996: Incorrect Roboto font rendering on Windows with
subpixel antialiasing
  - JDK-8238842: AIOOBE in GIFImageReader.initializeStringTable
  - JDK-8241750: x86_32 build failure after JDK-8227269
  - JDK-8244407: JVM crashes after transformation in C2
IdealLoopTree::split_fall_in
  - JDK-8244843: JapanEraNameCompatTest fails

Thanks,
--
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Jun  4 05:49:37 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 4 Jun 2020 06:49:37 +0100
Subject: [8u] RFR: 8246223: Windows build fails after JDK-8227269
In-Reply-To: <dbbeeeee-8368-65e8-8d2b-d7d3532ceaeb@redhat.com>
References: <dbbeeeee-8368-65e8-8d2b-d7d3532ceaeb@redhat.com>
Message-ID: <b3429258-9c59-28a6-6de0-ae17533d02ec@redhat.com>

On 03/06/2020 21:50, Alex Kashchenko wrote:
> Hi,
> 
> Please review the fix to JDK-8246223:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246223
> 
> Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8246223/webrev.00/
> 
> Problem appeared to be caused by C99 syntax used in JDK-8227269 that is
> not supported by VS2010 compiler (newer VS versions were not affected).
> 
> This patch fixes the compatibility of classTrack.c with C89 moving
> variable declarations to the beginning of corresponding scope blocks.
> 
> Testing: checked that it can be compiled with VS2010 and newer toolchains.
> 

I managed to get the same build failure on gcc with
-Werror=declaration-after-statement. I'll propose a patch to add that to
the build so we can catch these failures earlier in future.

It seems VS2010 doesn't conform to either standard exactly. When I first
tried to build with -std=c89, I got failures due to the use of C++-style
comments, which VS2010 is allowing.

Applying your patch fixes the failures and looks good to go.
Please flag the bug with jdk8u-critical-fix.

Thanks,
-- 
Andrew :)

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

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


From alexey at azul.com  Thu Jun  4 11:21:24 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 4 Jun 2020 11:21:24 +0000
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
 <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
Message-ID: <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>

Hello Martin,

You are right. We have two options:
1. backport JDK-8038893 to all packages
2. revert JDK-8038893 from X509TrustManagerImpl

I decided to backport JDK-803889 because of :
1. I decided this functionality valuable for server certificate validation
2. Without JDK-8038893 X509TrustManagerImpl should be significantly modified.
It could causes issues in subsequent backports from JDK11 to JDK8.

You are right, the first patch includes unnecessary changes from 8201815 and
does not include required changes in the SocketPermission class.

I?ve fixed it.
Please verify updated webrev at:
http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v1/

If you think this functionality still should be reverted and backported separately - it?s OK, I?ll do it

Regards
Alexey

> On 3 Jun 2020, at 22:11, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 5/21/20 10:54 AM, Alexey Bakhtin wrote:
>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u
> 
> Hi,
> 
> I've some concerns regarding this proposal.
> 
> My understanding is that the need for a JDK-8 backport of 8038893
> derives -originally- from the fact that the file
> sun/security/ssl/X509TrustManagerImpl.java (imported to JDK-8 by 'file
> replacement') includes some changes from it. So this crosses the
> sun/security/ssl boundary and has to be handled either by removing
> 8038893 traces from X509TrustManagerImpl.java or backporting it fully.
> 
> You've taken the decision of backporting 8038893 instead of removing it
> from X509TrustManagerImpl.java. What are the reasons behind that? And
> what would be the cons of the opposite approach? I'm still trying to
> understand that but your input would be appreciated.
> 
> I don't want to get into the patch specifics before being clear on the
> previous. However, at first glance, looks to me that the patch is taking
> changes from 8201815 and omitting changes in 8038893. This leads to the
> existence of two RegisteredDomain.java files in JDK-8. This may not be a
> problem on its own but reveals that there can be unintended and
> overlooked consequences. Given that we are out of sun/security/ssl, we
> would probably want full and independent backports if we decide to go
> that way.
> 
> Thanks,
> Martin.-
> 


From akashche at redhat.com  Thu Jun  4 14:02:41 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Thu, 4 Jun 2020 15:02:41 +0100
Subject: [8u] RFR: 8246223: Windows build fails after JDK-8227269
In-Reply-To: <b3429258-9c59-28a6-6de0-ae17533d02ec@redhat.com>
References: <dbbeeeee-8368-65e8-8d2b-d7d3532ceaeb@redhat.com>
 <b3429258-9c59-28a6-6de0-ae17533d02ec@redhat.com>
Message-ID: <87131553-8090-aaa9-02ee-6f912b9ff1f8@redhat.com>

On 06/04/2020 06:49 AM, Andrew Hughes wrote:
> On 03/06/2020 21:50, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review the fix to JDK-8246223:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246223
>>
>> Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8246223/webrev.00/
>>
>> Problem appeared to be caused by C99 syntax used in JDK-8227269 that is
>> not supported by VS2010 compiler (newer VS versions were not affected).
>>
>> This patch fixes the compatibility of classTrack.c with C89 moving
>> variable declarations to the beginning of corresponding scope blocks.
>>
>> Testing: checked that it can be compiled with VS2010 and newer toolchains.
>>
> 
> I managed to get the same build failure on gcc with
> -Werror=declaration-after-statement. I'll propose a patch to add that to
> the build so we can catch these failures earlier in future.
> 
> It seems VS2010 doesn't conform to either standard exactly. When I first
> tried to build with -std=c89, I got failures due to the use of C++-style
> comments, which VS2010 is allowing.
> 
> Applying your patch fixes the failures and looks good to go.
> Please flag the bug with jdk8u-critical-fix.

Thanks for the review! I've added critical request to the bug.


-- 
-Alex


From mbalao at redhat.com  Thu Jun  4 18:27:41 2020
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 4 Jun 2020 15:27:41 -0300
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
 <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
 <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>
Message-ID: <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com>

Hi Alexey,

Thanks for your feedback. We want 8038893 to be backported to JDK-8. I
cannot comment more on the reasons at this time, though.

Comments on v1:

 * java/net/SocketPermission.java
  * My understanding is that we bump the copyright date to the one in
the backported patch if newer than the one in the actual file.

 * sun/security/util/HostnameChecker.java
  * Shouldn't "SSLLogger.isOn" be "SSLLogger.isOn && SSLLogger.isOn("ssl")"?
  * Things being logged do not look for a "fine" level to me, as they
are errors on the certificate DNS name. In 8038893, these messages were
sent to "System.err". What do you think?

Regards,
Martin.-


From alexey at azul.com  Thu Jun  4 19:30:19 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 4 Jun 2020 19:30:19 +0000
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
 <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
 <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>
 <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com>
Message-ID: <FD8021DC-40F8-4571-92D2-8FFDF664729C@azul.com>

Hello Martin,

Thank you a lot for review
New webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v2/

Regards
Alexey

> On 4 Jun 2020, at 21:27, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> Thanks for your feedback. We want 8038893 to be backported to JDK-8. I
> cannot comment more on the reasons at this time, though.
> 
> Comments on v1:
> 
> * java/net/SocketPermission.java
>  * My understanding is that we bump the copyright date to the one in
> the backported patch if newer than the one in the actual file.

Changed to 2017.

> 
> * sun/security/util/HostnameChecker.java
>  * Shouldn't "SSLLogger.isOn" be "SSLLogger.isOn && SSLLogger.isOn("ssl")"?

Yes, you are right. Fixed

>  * Things being logged do not look for a "fine" level to me, as they
> are errors on the certificate DNS name. In 8038893, these messages were
> sent to "System.err". What do you think?

In the original patch for JDK9 it is logged as debug.println
In the JDK11 it was changed to SSLLogger.fine()
So, I think we should keep it ?fine?

> 
> Regards,
> Martin.-
> 


From mbalao at redhat.com  Thu Jun  4 19:41:17 2020
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 4 Jun 2020 16:41:17 -0300
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <FD8021DC-40F8-4571-92D2-8FFDF664729C@azul.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
 <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
 <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>
 <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com>
 <FD8021DC-40F8-4571-92D2-8FFDF664729C@azul.com>
Message-ID: <669919ac-0dfb-3d43-39d8-4608363d43f7@redhat.com>

On 6/4/20 4:30 PM, Alexey Bakhtin wrote:
>> * sun/security/util/HostnameChecker.java
>>  * Shouldn't "SSLLogger.isOn" be "SSLLogger.isOn && SSLLogger.isOn("ssl")"?
> 
> Yes, you are right. Fixed

Actually, you were right (see below).

> 
>>  * Things being logged do not look for a "fine" level to me, as they
>> are errors on the certificate DNS name. In 8038893, these messages were
>> sent to "System.err". What do you think?
> 
> In the original patch for JDK9 it is logged as debug.println
> In the JDK11 it was changed to SSLLogger.fine()
> So, I think we should keep it ?fine?
> 

Ah, you are right! It's "fine" and "SSLLogger.isOn" in JDK-11,
introduced by 8196584. I got lost in the patch-to-patch comparison.
Would you mind reverting the "SSLLogger.isOn("ssl")" part? Sorry about
that. Last thing I ask before approval.


From alexey at azul.com  Fri Jun  5 06:17:31 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Fri, 5 Jun 2020 06:17:31 +0000
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <669919ac-0dfb-3d43-39d8-4608363d43f7@redhat.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
 <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
 <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>
 <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com>
 <FD8021DC-40F8-4571-92D2-8FFDF664729C@azul.com>
 <669919ac-0dfb-3d43-39d8-4608363d43f7@redhat.com>
Message-ID: <F491ADDC-40ED-4569-A1BE-B55E55EF38F9@azul.com>

Hello Martin

Please verify the update patch :
http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v3/

Thank you
Alexey

> On 4 Jun 2020, at 22:41, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 6/4/20 4:30 PM, Alexey Bakhtin wrote:
>>> * sun/security/util/HostnameChecker.java
>>> * Shouldn't "SSLLogger.isOn" be "SSLLogger.isOn && SSLLogger.isOn("ssl")"?
>> 
>> Yes, you are right. Fixed
> 
> Actually, you were right (see below).
> 
>> 
>>> * Things being logged do not look for a "fine" level to me, as they
>>> are errors on the certificate DNS name. In 8038893, these messages were
>>> sent to "System.err". What do you think?
>> 
>> In the original patch for JDK9 it is logged as debug.println
>> In the JDK11 it was changed to SSLLogger.fine()
>> So, I think we should keep it ?fine?
>> 
> 
> Ah, you are right! It's "fine" and "SSLLogger.isOn" in JDK-11,
> introduced by 8196584. I got lost in the patch-to-patch comparison.
> Would you mind reverting the "SSLLogger.isOn("ssl")" part? Sorry about
> that. Last thing I ask before approval.
> 


From mbalao at redhat.com  Fri Jun  5 15:03:18 2020
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 5 Jun 2020 12:03:18 -0300
Subject: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine
In-Reply-To: <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com>
References: <828504cf-47d4-283d-5910-b7e0edfc23eb@redhat.com>
 <2c8386ac-acbe-7eae-853f-4cd6d3955a68@redhat.com>
 <1F1915CC-9110-461D-8F3C-F5D6394D2F33@azul.com>
 <7dab1baa-6dca-bf8a-1ced-6c639df85467@redhat.com>
 <8daa7c35-1280-5822-d820-3bfe58d29241@redhat.com>
 <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com>
Message-ID: <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>

Hi,

The JDK-8 backport of the new SunJSSE TLS engine (that includes support
for TLS 1.3) is expected to land in the first 8u272 Early Access (EA)
release. As you may have already noticed, we are still in the process of
reviewing each step in which we broke down the patch.

Considering the risks associated to backporting such a critical and
complex component, we started an internal discussion yesterday about a
fallback scheme in case something goes wrong. Given that this might be
of interest and impact the whole community, we agreed on moving the
discussion to the public and encouraging everyone to participate.

What you will find below this email is a rebuild of the previous
conversation, in chronological order (from older to newer).

Thanks,
Martin.-

--

============ Gil Tene (2020-06-04) ============

On the Azul side, we are still considering including the new
implementation in a July Zulu update. We have also built a fallback JSSE
implementation, which is a "sideport" ("outport"?) of the current (now
legacy) 8u JSSE implementation and is aimed to be used as a separate,
optional jar in case there is some reason to go back to the old
functionality. We've been testing it, and will probably end up placing
it under something like org.openjsse.legacy8ujsse. I don't know if it
makes sense to add this fallback artifact to the OpenJDK 8u project
itself, but it would be useful to have it out there as an escape hatch
for people to use if 11u-driven regressions do show up.





============ Martin Balao (2020-06-04) ============

It's a hard choice. I'm more inclined not to push that into the upstream
repository. A parallel TLS engine will need to be updated regularly
-against security issues at least- and supported, increasing the
maintenance burden. The integration itself may create unexpected
trouble. In addition, we will be introducing a non-standard Security
Provider that breaks compatibility with Oracle's JDK and creates some
expectations on our users of what is available in JDK-8 (if we decide to
remove it later, we will certainly break code).

One thing that came to my mind to address this problem was having an
'emergency 8u272 build' with all the security patches applied but
without the TLS 1.3 engine. In case things go horribly wrong, we can ask
our users to use that build until 8u282.

I'm perfectly aware of the risks we are taking. With that said, I'm also
confident in the technical capabilities we have in the community to
workaround possible issues in a reasonable time.





============ Gil Tene (2020-06-04) ============

>>> On 6/4/20 3:52 PM, Martin Balao wrote:
>>> It's a hard choice. I'm more inclined not to push that into the upstream
>>> repository. A parallel TLS engine will need to be updated regularly
>>> -against security issues at least- and supported, increasing the
>>> maintenance burden. The integration itself may create unexpected
>>> trouble. In addition, we will be introducing a non-standard Security
>>> Provider that breaks compatibility with Oracle's JDK and creates some
>>> expectations on our users of what is available in JDK-8 (if we decide to
>>> remove it later, we will certainly break code).

I think that (in the balance) I agree that we don't want this fallback
provider in the project itself. The fact that we will want to quickly
deprecate and remove it (once the new stuff has been around for a while
and works well) is a good hint that we should not put it in.

But I do think that it would be useful, and it looks to be working well.
What we can do is put it up under openjsse on github, so it is ready to
go if people need it. This way it acts as interim insurance, is
available for everyone (and e.g. for distros that want to bundle it) but
does not contaminate the project with the long term legacy of a
temporary bandaid...

>>>
>>> One thing that came to my mind to address this problem was having an
>>> 'emergency 8u272 build' with all the security patches applied but
>>> without the TLS 1.3 engine. In case things go horribly wrong, we can ask
>>> our users to use that build until 8u282.

That's definitely an alternative, but it also risks the long term
bifurcation with two builds needed every quarter. i.e. of both builds
are available in 8u272, most people may choose to go with the no-new-TLS
mode to contain risk, and only people that actually want TLS 1.3 will
adopt the new builds. We will then be faced with the need to keep
building both every quarter for a while.

My hope is that offering a fallback option for use if there is a
regression, and that can be downloaded from github, would be enough to
cover the risk...

>>>
>>> I'm perfectly aware of the risks we are taking. With that said, I'm also
>>> confident in the technical capabilities we have in the community to
>>> workaround possible issues in a reasonable time.

I agree. I'm confident that we will fix whatever needs fixing. This is
just about the time between.



From mbalao at redhat.com  Fri Jun  5 15:14:39 2020
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 5 Jun 2020 12:14:39 -0300
Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3
In-Reply-To: <F491ADDC-40ED-4569-A1BE-B55E55EF38F9@azul.com>
References: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com>
 <ce38a325-1bfb-de26-8877-d069c99552be@redhat.com>
 <2165C249-6694-4BC7-AD5A-92D3337AA11C@azul.com>
 <0f3678a0-c53d-5101-9d56-61aa5d84ffb1@redhat.com>
 <FD8021DC-40F8-4571-92D2-8FFDF664729C@azul.com>
 <669919ac-0dfb-3d43-39d8-4608363d43f7@redhat.com>
 <F491ADDC-40ED-4569-A1BE-B55E55EF38F9@azul.com>
Message-ID: <d23beed0-792c-41f2-bd7b-f8d6c6e20cd7@redhat.com>

On 6/5/20 3:17 AM, Alexey Bakhtin wrote:
> Please verify the update patch :
> http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v3/

Hi,

Step 5 (8245472) is the backport of 8038893 to JDK-8.

Comments here [1] [2] [3] are part of this review.

V3 looks good to me.

Please hold-on before pushing until we review the whole series and the
JDK-8 maintainer approves the backport.

Thanks,
Martin.-

--
[1] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011875.html
[2] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011883.html
[3] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011885.html


From jaroslav.bachorik at datadoghq.com  Fri Jun  5 15:36:08 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 5 Jun 2020 17:36:08 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmZPwxVKNgvcgW1HH50c2D8CXZf9_Pu5SFBkC5_1jDY2tA@mail.gmail.com>
 <CAJwKKmZ_TFu0RDXnqxrfA4Rxaaq3hadQST8_ZuwGNAyKOsXBJQ@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
Message-ID: <CAPb8aJ5Z01Y7UDs3jQSYcXBLwAnWkqSNdMNvKK1YTwSwmtqR3g@mail.gmail.com>

Hi Mario,

On Wed, Jun 3, 2020 at 1:16 PM Mario Torre <neugens at redhat.com> wrote:
>
> On Wed, Jun 3, 2020 at 9:52 AM Jaroslav Bachor?k
> <jaroslav.bachorik at datadoghq.com> wrote:
> > Thanks to Mario Torre for pointing me the right direction! I was able
> > to add a rudimentary test which exhibits JVM crash without this patch
> > applied and passes with this patch (with an exception and error
> > message as specified - no JVM crash).
> >
> > Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.03/
> > (also including the requested indentation change)
>
> There's something weird about this:
> --- a/test/runtime/8001071/Test8001071.sh
> +++ b/test/runtime/8233197/Test8233197.sh
>
> It's registered as a copy/replacement. I think it should be a new file though.
>
> One more nit, is that you don't need the printfs, i.e.:
>
> printf("Agent_OnLoad\n");

These issues have been fixed
http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04/

-JB-

>
> The test case looks good otherwise for our purposes, but I'll let
> Andrew have the final words.
>
> > BTW, since this patch missed the cutoff date for 8u262 mostly due to
> > review would it be ok to consider it still as a part of the critical
> > fix process?
>
> I most certainly support this.
>
> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From gnu.andrew at redhat.com  Fri Jun  5 15:36:32 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 5 Jun 2020 16:36:32 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmZPwxVKNgvcgW1HH50c2D8CXZf9_Pu5SFBkC5_1jDY2tA@mail.gmail.com>
 <CAJwKKmZ_TFu0RDXnqxrfA4Rxaaq3hadQST8_ZuwGNAyKOsXBJQ@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
Message-ID: <c76e2893-5cb7-b35f-4edb-f0662575999a@redhat.com>

On 28/05/2020 17:25, Jaroslav Bachor?k wrote:
> On Thu, May 28, 2020 at 3:10 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>
>>
>>
>> On 28/05/2020 13:34, Andrew Haley wrote:
>>> On 28/05/2020 10:08, Jaroslav Bachor?k wrote:
>>>> I guess so. But such a test is not a part of the original changeset.
>>>> Is it necessary to be extending the scope of the original patch
>>>> (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)?
>>>
>>> Yes please. 8u is old code, and your first task is not to break it. If
>>> this involves being more defensive than upstream, that's fine. Class
>>> initialization order at startup is notoriously sensitive and responsible
>>> for breaking things in subtle ways.
>>>
>>
>> There's also no reason such a change could not then be forwardported to
>> later versions. If a bug is filed for this, the 8u fix can be committed
>> under both 8233197 & the new ID, and then the test change alone posted
>> for review in later versions.
> 
> Well, there might be a reason - there is no 'native test' support in
> JDK 8 AFAIK. There are not even any JVMTI native agent jtreg tests -
> so no harness for building a native agent (on all supported
> platforms). And to be honest, I don't feel like writing all that
> support from scratch. If I am missing something and there indeed is a
> support for testing JVMTI agents, please let me know and I will add a
> test.
> 
> Thanks!
> 
> -JB-
> 

Sorry, I'm lost here. How does a lack of support for testing in 8u mean
it can't be forwardported to later JDK versions?

As I see there now is a test for 8u, could a bug be filed so we can
track getting this test into all currently supported versions?

Thanks,
-- 
Andrew :)

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

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


From jaroslav.bachorik at datadoghq.com  Fri Jun  5 15:57:25 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 5 Jun 2020 17:57:25 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <c76e2893-5cb7-b35f-4edb-f0662575999a@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmZPwxVKNgvcgW1HH50c2D8CXZf9_Pu5SFBkC5_1jDY2tA@mail.gmail.com>
 <CAJwKKmZ_TFu0RDXnqxrfA4Rxaaq3hadQST8_ZuwGNAyKOsXBJQ@mail.gmail.com>
 <CAPb8aJ47+cChB0ROduYY=U9GiR-f=_9q_CWVVNV75Y5e1-0dmg@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <c76e2893-5cb7-b35f-4edb-f0662575999a@redhat.com>
Message-ID: <CAPb8aJ6gcPMiQyUt6GoaTZ_hswF55snGWxtNLF7+pzy5a-EiDg@mail.gmail.com>

On Fri, Jun 5, 2020 at 5:36 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 28/05/2020 17:25, Jaroslav Bachor?k wrote:
> > On Thu, May 28, 2020 at 3:10 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
> >>
> >>
> >>
> >> On 28/05/2020 13:34, Andrew Haley wrote:
> >>> On 28/05/2020 10:08, Jaroslav Bachor?k wrote:
> >>>> I guess so. But such a test is not a part of the original changeset.
> >>>> Is it necessary to be extending the scope of the original patch
> >>>> (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)?
> >>>
> >>> Yes please. 8u is old code, and your first task is not to break it. If
> >>> this involves being more defensive than upstream, that's fine. Class
> >>> initialization order at startup is notoriously sensitive and responsible
> >>> for breaking things in subtle ways.
> >>>
> >>
> >> There's also no reason such a change could not then be forwardported to
> >> later versions. If a bug is filed for this, the 8u fix can be committed
> >> under both 8233197 & the new ID, and then the test change alone posted
> >> for review in later versions.
> >
> > Well, there might be a reason - there is no 'native test' support in
> > JDK 8 AFAIK. There are not even any JVMTI native agent jtreg tests -
> > so no harness for building a native agent (on all supported
> > platforms). And to be honest, I don't feel like writing all that
> > support from scratch. If I am missing something and there indeed is a
> > support for testing JVMTI agents, please let me know and I will add a
> > test.
> >
> > Thanks!
> >
> > -JB-
> >
>
> Sorry, I'm lost here. How does a lack of support for testing in 8u mean
> it can't be forwardported to later JDK versions?

Never mind. I think we just misunderstood each other.

>
> As I see there now is a test for 8u, could a bug be filed so we can
> track getting this test into all currently supported versions?

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

Cheers,

-JB-

>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From mbalao at redhat.com  Fri Jun  5 20:44:13 2020
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 5 Jun 2020 17:44:13 -0300
Subject: [8u] TLSv1.3 RFR: 8245473: OCSP stapling support
In-Reply-To: <A6932CAA-9ED3-489C-A9FB-C956BBF1D24E@azul.com>
References: <A6932CAA-9ED3-489C-A9FB-C956BBF1D24E@azul.com>
Message-ID: <d7928299-6914-4375-5961-ba9fcfc012f2@redhat.com>

On 5/21/20 11:02 AM, Alexey Bakhtin wrote:
> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u

Hi Alexey,

A few questions and comments.

 * test/*

Will tests be handled in later steps? I guess so but please confirm.
This is probably not ideal but okay -we have managed them separately
anyways in previous steps-.

 * SSLContextImpl.java

Why did you turn 'jdk.tls.client.enableStatusRequestExtension' to
'false' by default?

A CSR will be needed if we are introducing new properties anyways.

 * X509TrustManagerImpl.java

You probably want to make some changes here after I asked you to remove
changes introduced for Step 3 (8245470). However, before casting to
SSLSessionImpl I'd suggest to add a 'instanceof' check. If, for any
reason, it's a JDK-8 ExtendedSSLSession implementation class different
than SSLSessionImpl, we shouldn't fail because having the
getStatusResponses method was not part of the contract at that time.

 * OCSP.java

Why are these changes not included?

 * OCSPRequest.java

Why are these changes not included?

 * OCSPResponse.java

Why are these changes not included?

 * ResponderId.java

Why are these changes not included?

 * Validator.java

Seems to be including changes from 8154015. Why? Looks to me that
8154015 was introduced to JDK-8 and then backed out.

I suggest not to bump the copyright end date.

 * PKIXExtensions.java

Why are these changes not included?

 * RevocationChecker.java

Why are we including changes from 8161973 here? Please propose 8161973
as an independent backport.

Step 6 (8245473) is the JDK-8 backport of 8046321. Don't forget to add a
reference to 8046321 in the commit message.

Thanks,
Martin.-


From tianshi at amazon.com  Sat Jun  6 14:30:03 2020
From: tianshi at amazon.com (Shi, Tianmin)
Date: Sat, 6 Jun 2020 14:30:03 +0000
Subject: 8006205: [TESTBUG] NEED_TEST: please JTREGIFY
 test/compiler/7177917/Test7177917.java
In-Reply-To: <81225DA4-6BC0-45CD-9C4B-F244487C57FA@amazon.com>
References: <B355E6B9-738A-49F0-9F64-96106D9A156D@amazon.com>
 <81225DA4-6BC0-45CD-9C4B-F244487C57FA@amazon.com>
Message-ID: <5D2A5E7C-DDD2-493F-81E9-C48AB0BBD623@amazon.com>

Please review this test bug backport to 8u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8006205
Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c2304140ed64
Original file change from commit:https://hg.openjdk.java.net/jdk/jdk/file/c2304140ed64/hotspot/test/compiler/c2/Test7177917.java
Webrev: http://cr.openjdk.java.net/~phh/8006205/webrev.8u.00/

The backport is simple, but is not clean because in 8 there is no @module and no need for @library to run the test.


Test:

jtreg -jdk:[testjdk] jdk8u-dev/hotspot/test/compiler/7177917

Test results: passed: 1



From hohensee at amazon.com  Sat Jun  6 16:43:51 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Sat, 6 Jun 2020 16:43:51 +0000
Subject: 8006205: [TESTBUG] NEED_TEST: please JTREGIFY
 test/compiler/7177917/Test7177917.java
In-Reply-To: <5D2A5E7C-DDD2-493F-81E9-C48AB0BBD623@amazon.com>
References: <B355E6B9-738A-49F0-9F64-96106D9A156D@amazon.com>
 <81225DA4-6BC0-45CD-9C4B-F244487C57FA@amazon.com>
 <5D2A5E7C-DDD2-493F-81E9-C48AB0BBD623@amazon.com>
Message-ID: <22875E2C-67F8-4D4C-B01F-6D0AD7833612@amazon.com>

Lgtm.

Paul

?On 6/6/20, 7:31 AM, "jdk8u-dev on behalf of Shi, Tianmin" <jdk8u-dev-bounces at openjdk.java.net on behalf of tianshi at amazon.com> wrote:

    Please review this test bug backport to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8006205
    Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c2304140ed64
    Original file change from commit:https://hg.openjdk.java.net/jdk/jdk/file/c2304140ed64/hotspot/test/compiler/c2/Test7177917.java
    Webrev: http://cr.openjdk.java.net/~phh/8006205/webrev.8u.00/

    The backport is simple, but is not clean because in 8 there is no @module and no need for @library to run the test.


    Test:

    jtreg -jdk:[testjdk] jdk8u-dev/hotspot/test/compiler/7177917

    Test results: passed: 1




From alexey at azul.com  Sat Jun  6 21:14:31 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Sat, 6 Jun 2020 21:14:31 +0000
Subject: [8u] TLSv1.3 RFR: 8245473: OCSP stapling support
In-Reply-To: <d7928299-6914-4375-5961-ba9fcfc012f2@redhat.com>
References: <A6932CAA-9ED3-489C-A9FB-C956BBF1D24E@azul.com>
 <d7928299-6914-4375-5961-ba9fcfc012f2@redhat.com>
Message-ID: <A4A56321-60A3-4FBD-8A7E-9223E4AF7A1E@azul.com>

Hello Martin,

Thank you for review.
Please see my comments below

Regards
Alexey

> On 5 Jun 2020, at 23:44, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 5/21/20 11:02 AM, Alexey Bakhtin wrote:
>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u
> 
> Hi Alexey,
> 
> A few questions and comments.
> 
> * test/*
> 
> Will tests be handled in later steps? I guess so but please confirm.
> This is probably not ideal but okay -we have managed them separately
> anyways in previous steps-.

Yes, OCSP stapling related test are added in JDK-8245681:
- test/java/security/testlibrary/CertificateBuilder.java
- test/java/security/testlibrary/SimpleOCSPServer.java
- test/javax/net/ssl/Stapling/*
- sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java
- sun/security/provider/certpath/ResponderId/ResponderIdTests.java
- sun/security/ssl/Stapling/StatusResponseManagerTests.java

> 
> * SSLContextImpl.java
> 
> Why did you turn 'jdk.tls.client.enableStatusRequestExtension' to
> 'false' by default?
> 
> A CSR will be needed if we are introducing new properties anyways.
> 
OCSP Stapling should be disabled by default to minimise possible difference for
existing 8u applications.
You are right. It should be documented in CSR

> * X509TrustManagerImpl.java
> 
> You probably want to make some changes here after I asked you to remove
> changes introduced for Step 3 (8245470). However, before casting to
> SSLSessionImpl I'd suggest to add a 'instanceof' check. If, for any
> reason, it's a JDK-8 ExtendedSSLSession implementation class different
> than SSLSessionImpl, we shouldn't fail because having the
> getStatusResponses method was not part of the contract at that time.
> 
Agree. You are right. Will be fixed

> * OCSP.java
> 
> Why are these changes not included?

OCSP.java is identical in JDK8 and JDK11.
No changes required

> 
> * OCSPRequest.java
> 
OCSPRequest.java is identical in JDK8 and JDK11.
No changes required

> Why are these changes not included?
> 
> * OCSPResponse.java
> 
OCSPResponse.java is identical in JDK8 and JDK11.
No changes required

> Why are these changes not included?
> 
> * ResponderId.java

ResponderId.java  is identical in JDK8 and JDK11.
No changes required
> 
> Why are these changes not included?
> 
> * Validator.java
> 
> Seems to be including changes from 8154015. Why? Looks to me that
> 8154015 was introduced to JDK-8 and then backed out.
> 
Do you mean changes in comments ? Yes, I can revert them. Will be fixed
The rest changes should be fine and identical to JDK-8046321 changes.

> I suggest not to bump the copyright end date.
> 
> * PKIXExtensions.java
PKIXExtensions.java is identical in JDK8 and JDK11.
No changes required

> 
> Why are these changes not included?
> 
> * RevocationChecker.java
> 
> Why are we including changes from 8161973 here? Please propose 8161973
> as an independent backport.

It is important fix. Without this fix OCSP functionality works incorrectly and several test fails.
I?d like this fix is ported as part of this OCSP backport.
Otherwise we?ll ship TLS functionality with known bug
Possible solution - additional step for this fix in terms of JDK-8245466

> 
> Step 6 (8245473) is the JDK-8 backport of 8046321. Don't forget to add a
> reference to 8046321 in the commit message.
> 
> Thanks,
> Martin.-
> 


From gnu.andrew at redhat.com  Sat Jun  6 21:40:30 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 6 Jun 2020 22:40:30 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
Message-ID: <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>



On 03/06/2020 12:15, Mario Torre wrote:

snip...
> 
>> BTW, since this patch missed the cutoff date for 8u262 mostly due to
>> review would it be ok to consider it still as a part of the critical
>> fix process?
> 
> I most certainly support this.
> 
> Cheers,
> Mario
> 

My initial thought is that, if a patch takes a long time in review,
that's probably a sign that it required a lot of debate and alteration,
and so shouldn't be going into a release late, rather than the opposite.

However, I'm of course open to hearing why this is critical to the 8u262
release and can't wait until 8u272.

Thanks,
-- 
Andrew :)

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

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


From neugens at redhat.com  Sat Jun  6 22:32:13 2020
From: neugens at redhat.com (Mario Torre)
Date: Sun, 7 Jun 2020 00:32:13 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
Message-ID: <CAJwKKmaAxmX619XW8YkCOsaWSZLym9ZdC1sJXGABBMaG279mww@mail.gmail.com>

Hi Andrew,

Without this patch the JVM segfaults when an agent tries to use JFR while
collecting startup events.

I agree on the general case but this one seems important to have it in, but
this of course unless there are issues with the actual code.

Cheers,
Mario

On Saturday, June 6, 2020, Andrew Hughes <gnu.andrew at redhat.com> wrote:

>
>
> On 03/06/2020 12:15, Mario Torre wrote:
>
> snip...
> >
> >> BTW, since this patch missed the cutoff date for 8u262 mostly due to
> >> review would it be ok to consider it still as a part of the critical
> >> fix process?
> >
> > I most certainly support this.
> >
> > Cheers,
> > Mario
> >
>
> My initial thought is that, if a patch takes a long time in review,
> that's probably a sign that it required a lot of debate and alteration,
> and so shouldn't be going into a release late, rather than the opposite.
>
> However, I'm of course open to hearing why this is critical to the 8u262
> release and can't wait until 8u272.
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>
>

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

From gnu.andrew at redhat.com  Sun Jun  7 17:21:32 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 7 Jun 2020 18:21:32 +0100
Subject: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine
In-Reply-To: <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>
References: <828504cf-47d4-283d-5910-b7e0edfc23eb@redhat.com>
 <2c8386ac-acbe-7eae-853f-4cd6d3955a68@redhat.com>
 <1F1915CC-9110-461D-8F3C-F5D6394D2F33@azul.com>
 <7dab1baa-6dca-bf8a-1ced-6c639df85467@redhat.com>
 <8daa7c35-1280-5822-d820-3bfe58d29241@redhat.com>
 <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com>
 <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>
Message-ID: <8451478a-8610-0460-9b09-43763e51d006@redhat.com>

On 05/06/2020 16:03, Martin Balao wrote:

snip...

> 
> One thing that came to my mind to address this problem was having an
> 'emergency 8u272 build' with all the security patches applied but
> without the TLS 1.3 engine. In case things go horribly wrong, we can ask
> our users to use that build until 8u282.
> 

I don't think this is feasible. It seems to assume that the only change
in 8u272 will be the TLS 1.3 engine. The reality is that the period from
now until rampdown will be a mix of TLS 1.3 patches interleaved with
other backports, so one would have to cherry-pick out all the non-TLS
work and reapply it somewhere else.

My suggestion would be to follow the JFR route:

1. Now: Setup a TLS incubator tree and apply the patches there.

2. Monday, August 24th, 2020: Decide whether to merge the incubator tree
into 8u-dev before rampdown on Friday, 28th.

3. Assuming it is integrated, test TLS 1.3 in 8u272 during September.

The benefits of this are:

1. You can handle the commit policy for the incubator (just reviews, no
need for individual approvals)

2. One single approval can be used to merge TLS 1.3 in rampdown week.

3. Merging just before rampdown makes your proposal feasible, assuming
low traffic during rampdown.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Sun Jun  7 17:47:38 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 7 Jun 2020 18:47:38 +0100
Subject: RFR: backport of 8239819
In-Reply-To: <CAJwKKmbm3r4ozYcvfQ9k7ZeLpVMPkuJhLi0XRYdG0pY8VSdObg@mail.gmail.com>
References: <CAJwKKmbm3r4ozYcvfQ9k7ZeLpVMPkuJhLi0XRYdG0pY8VSdObg@mail.gmail.com>
Message-ID: <94729d7f-fbf2-de37-27e3-a00f810abbcd@redhat.com>

On 25/05/2020 13:15, Mario Torre wrote:
> Hi all,
> 
> i would like to backpor the following bug to jdk8u:
> 
> https://bugs.openjdk.java.net/browse/JDK-8239819
> 
> The patch applies almost cleanly, the obvious exception is the
> copyright year but also a line in the
> src/solaris/classes/sun/awt/X11/XToolkit.java caused by the presence
> of a field that isn't there anymore in the original patch, so this
> probably needs a quick review:
> 
> http://cr.openjdk.java.net/~neugens/8239819/webrev.00/
> 
> I tested with the usual jtregs and manually and can't see any problem.
> 
> 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
> 

This looks fine. Patch is the same, bar a few context differences.

Please don't add jdk8u-fix-request until the patch is reviewed, though.
It helps to keep the queue clear for those fixes that are ready for the
approval stage.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Jun  8 00:05:38 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 8 Jun 2020 01:05:38 +0100
Subject: [8u] RFR 8238225: Issues reported after replacing symlink at
 Contents/MacOS/libjli.dylib with binary
In-Reply-To: <5e7890f6-2a8c-b551-58b0-02c67df0b544@azul.com>
References: <5e7890f6-2a8c-b551-58b0-02c67df0b544@azul.com>
Message-ID: <abdede5a-015a-6ca4-9e26-4fc40a619150@redhat.com>

On 17/04/2020 13:57, Dmitry Cherepanov wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8238225
> original review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064561.html
> 
> patch for 11u:
> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/128739be82b6
> 
> webrev for 8u:
> http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v0/
> 
> 1) src/macosx/bin/java_md_macosx.c
> 
> This part applies cleanly but needs refinement. The logic has been
> expanded to cover 8u-specifics: if the libjli.dylib library was loaded
> from MacOS bundle (i.e. realPathToSelf ends with ?/MacOS/libjli.dylib?),
> then check if it?s a JDK bundle (private JRE is in ../Home/jre) and then
> check if it?s a JRE bundle (public JRE is in ../Home)
> 
> 2) testing part
> 
> Given that support for building native part of jtpeg tests is currently
> missing in 8u (8072842), new shell script was created and used for
> testing.? The java part of the test also includes additional changes
> relative to 11u version
> (http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/JliLaunchTest.java.diff.v0).
> The test fails without a fix and passes from the fixes (for JRE/JDK
> bundles)
> 
> Thanks,
> 
> Dmitry
> 

The patch:

https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v0/jdk.changeset

appears to contain both 8235687 & 8238225. Which of these is actually
being submitted for review?

Thanks,
-- 
Andrew :)

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

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


From jaroslav.bachorik at datadoghq.com  Mon Jun  8 10:34:00 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 8 Jun 2020 12:34:00 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmaMZyJ1ezoG3p_c7KmH+wVo-4KTyPAhWzZFod-Qikra7w@mail.gmail.com>
 <c0be6c2e-7dd6-5aa7-47ff-e6b3dddc6e0f@redhat.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
Message-ID: <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>

On Sat, Jun 6, 2020 at 11:40 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
>
>
> On 03/06/2020 12:15, Mario Torre wrote:
>
> snip...
> >
> >> BTW, since this patch missed the cutoff date for 8u262 mostly due to
> >> review would it be ok to consider it still as a part of the critical
> >> fix process?
> >
> > I most certainly support this.
> >
> > Cheers,
> > Mario
> >
>
> My initial thought is that, if a patch takes a long time in review,
> that's probably a sign that it required a lot of debate and alteration,
> and so shouldn't be going into a release late, rather than the opposite.

I do not think this is a good example of a contentious issue. The RFR
spent most of its time being idle waiting for review - the only issues
were related to formatting and non-existent test (which does not exist
upstream either). So the point about debate and alteration is rather
moot here.

>
> However, I'm of course open to hearing why this is critical to the 8u262
> release and can't wait until 8u272.

Well, not having JVM segfault on a valid use of JFR would be nice. But
it's your call as the maintainer.

Cheers,

-JB-

>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From jaroslav.bachorik at datadoghq.com  Mon Jun  8 11:27:19 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 8 Jun 2020 13:27:19 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
Message-ID: <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>

On Wed, Jun 3, 2020 at 1:05 PM Mario Torre <neugens at redhat.com> wrote:
>
> On Wed, Jun 3, 2020 at 12:15 PM Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Hi Andrew,
> >
> > This 'L' -checking code is activated only when the method in question is
> > given the array (i.e. the FQN of the class is something "[L...").
> > However the caller never applies the method to array classes, only
> > instance classes.
> > (and I've actually checked that "L.Main" class has appeared in the JMC's
> > "Top packages" window)
>
> Yeah, however it's not clear to me if this may change in the future
> since the function has a side effect that it's not entirely specified,
> that said however I think, if any, this is a bug in mainline and an
> eventual fix should come in via an additional backport and not hold
> this fix in 8u.

Totally agreed - this should be done asynchronously and not held back
by an issue in the mainline.

>
> Can you perhaps send an email to jdk-dev to check?

Andrey, can you start the discussion on jdk-dev?

Cheers,

-JB-

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

From andrey at azul.com  Mon Jun  8 15:02:04 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Mon, 8 Jun 2020 18:02:04 +0300
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
 <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
Message-ID: <bc82b6f5-9a08-f0df-f763-67cab7d2cf49@azul.com>

Sure. hotspot-runtime looks better candidate for me, indeed. Also, check
out JDK-8241294

Andrey

On 08.06.2020 14:27, Jaroslav Bachor?k wrote:
> On Wed, Jun 3, 2020 at 1:05 PM Mario Torre <neugens at redhat.com> wrote:
>> On Wed, Jun 3, 2020 at 12:15 PM Andrey Petushkov <andrey at azul.com> wrote:
>>> Hi Andrew,
>>>
>>> This 'L' -checking code is activated only when the method in question is
>>> given the array (i.e. the FQN of the class is something "[L...").
>>> However the caller never applies the method to array classes, only
>>> instance classes.
>>> (and I've actually checked that "L.Main" class has appeared in the JMC's
>>> "Top packages" window)
>> Yeah, however it's not clear to me if this may change in the future
>> since the function has a side effect that it's not entirely specified,
>> that said however I think, if any, this is a bug in mainline and an
>> eventual fix should come in via an additional backport and not hold
>> this fix in 8u.
> Totally agreed - this should be done asynchronously and not held back
> by an issue in the mainline.
>
>> Can you perhaps send an email to jdk-dev to check?
> Andrey, can you start the discussion on jdk-dev?
>
> Cheers,
>
> -JB-
>
>> Cheers,
>> Mario
>>
>> --
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>


From gnu.andrew at redhat.com  Mon Jun  8 15:08:01 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 8 Jun 2020 16:08:01 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
Message-ID: <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>

On 08/06/2020 11:34, Jaroslav Bachor?k wrote:

snip...

>>
>> My initial thought is that, if a patch takes a long time in review,
>> that's probably a sign that it required a lot of debate and alteration,
>> and so shouldn't be going into a release late, rather than the opposite.
> 
> I do not think this is a good example of a contentious issue. The RFR
> spent most of its time being idle waiting for review - the only issues
> were related to formatting and non-existent test (which does not exist
> upstream either). So the point about debate and alteration is rather
> moot here.
> 

Ok. I was speaking generally with regard to your comment "this patch
missed the cutoff date for 8u262 mostly due to review". In many cases,
that alone would be a reason not to include, rather than to include.

I haven't followed the discussion that closely, but what you say about
this particular patch seems acceptable.

>>
>> However, I'm of course open to hearing why this is critical to the 8u262
>> release and can't wait until 8u272.
> 
> Well, not having JVM segfault on a valid use of JFR would be nice. But
> it's your call as the maintainer.
> 

Well, I need information to make such a decision :-)

So it would help if you could answer the following:

1. How prolific is such usage of JFR?

2. What are the risks of including this patch?

3. Do we now have a final version of this patch, with test?

4. Was a bug filed for the additional test?

I've no issue with this going in before the test makes it into later JDK
versions, but we should be tracking that this happens.

Thanks,
-- 
Andrew :)

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

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


From andrey.petushkov at gmail.com  Mon Jun  8 15:20:06 2020
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Mon, 8 Jun 2020 18:20:06 +0300
Subject: follow-up to 8241294: Examine input checking in
 ClassLoader::package_from_class_name
Message-ID: <CADV+1JpwoXn2UMa=aEVcX9Gg_tXEpmzvCrHRGREwhVHD3oq9JQ@mail.gmail.com>

Dear Claes, All,

one question related to the subject. Even though it's considered
legitimate for the method to accept '['s at the start of the input
IMHO the check for subsequent 'L' is wrong and the related comment is
misleading.

JLS does not prohibit class and package names to start from capital L,
so it's unclear why arrays of those, and only those (considering these
appear here in internal form) being banned?

Moreover, given that this function is widely used it's even more
important that if there is some internal special case which passes
such forms as argument it's better to be clearly documented, instead
of saying false things like "Fully qualified class names should not
contain a 'L'." (1).

However this this code seem to pass quite number of editorials by
different people and still has the same check. So there might be a
reason. Given that may I ask for kind clarification of the matter?

Thank you,
Andrey

[1] https://hg.openjdk.java.net/jdk/jdk/file/5efafa45f3b8/src/hotspot/share/classfile/classLoader.cpp#l201

From jaroslav.bachorik at datadoghq.com  Mon Jun  8 16:41:04 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 8 Jun 2020 18:41:04 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
Message-ID: <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>

Hi Andrew,

On Mon, Jun 8, 2020 at 5:08 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 08/06/2020 11:34, Jaroslav Bachor?k wrote:
>
> snip...
>
> >>
> >> My initial thought is that, if a patch takes a long time in review,
> >> that's probably a sign that it required a lot of debate and alteration,
> >> and so shouldn't be going into a release late, rather than the opposite.
> >
> > I do not think this is a good example of a contentious issue. The RFR
> > spent most of its time being idle waiting for review - the only issues
> > were related to formatting and non-existent test (which does not exist
> > upstream either). So the point about debate and alteration is rather
> > moot here.
> >
>
> Ok. I was speaking generally with regard to your comment "this patch
> missed the cutoff date for 8u262 mostly due to review". In many cases,
> that alone would be a reason not to include, rather than to include.
>
> I haven't followed the discussion that closely, but what you say about
> this particular patch seems acceptable.
>
> >>
> >> However, I'm of course open to hearing why this is critical to the 8u262
> >> release and can't wait until 8u272.
> >
> > Well, not having JVM segfault on a valid use of JFR would be nice. But
> > it's your call as the maintainer.
> >
>
> Well, I need information to make such a decision :-)
>
> So it would help if you could answer the following:
>
> 1. How prolific is such usage of JFR?

I guess not much since till recently each attempt would have resulted
in segfault.
But in general I would say that any APM/Profiler based on JFR would be
happy not to run a special delay code to prevent segfaults.

>
> 2. What are the risks of including this patch?

In general, changing the initialization order for java.lang.Class
could cause problems for a code that would operate with assumption of
the java.lang.Class not being initialized very early on in the JVM
startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
tests are still passing after adding this change


>
> 3. Do we now have a final version of this patch, with test?

Yes. The webrev.04 version is the final one.


>
> 4. Was a bug filed for the additional test?

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


>
> I've no issue with this going in before the test makes it into later JDK
> versions, but we should be tracking that this happens.

Sure, will do.

Cheers,

-JB-

>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From claes.redestad at oracle.com  Mon Jun  8 16:59:31 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 8 Jun 2020 18:59:31 +0200
Subject: follow-up to 8241294: Examine input checking in
 ClassLoader::package_from_class_name
In-Reply-To: <CADV+1JpwoXn2UMa=aEVcX9Gg_tXEpmzvCrHRGREwhVHD3oq9JQ@mail.gmail.com>
References: <CADV+1JpwoXn2UMa=aEVcX9Gg_tXEpmzvCrHRGREwhVHD3oq9JQ@mail.gmail.com>
Message-ID: <dd794f8a-9968-ebf3-7eda-8f0a65391a0d@oracle.com>

Hi,

the method in question has historically been tangled up with use sites
that pass either fully qualified class names ('java/lang/Thread') or
class name signatures (e.g., '[Ljava/lang/Thread').

I have no clarifications to give other than I think the way forward is
to ensure signatures are always parsed into their constituent parts as
they are read from the constant pool and not allowed to roam around in
the VM code acting as fully qualified class names (which they aren't).

/Claes

On 2020-06-08 17:20, Andrey Petushkov wrote:
> Dear Claes, All,
> 
> one question related to the subject. Even though it's considered
> legitimate for the method to accept '['s at the start of the input
> IMHO the check for subsequent 'L' is wrong and the related comment is
> misleading.
> 
> JLS does not prohibit class and package names to start from capital L,
> so it's unclear why arrays of those, and only those (considering these
> appear here in internal form) being banned?
> 
> Moreover, given that this function is widely used it's even more
> important that if there is some internal special case which passes
> such forms as argument it's better to be clearly documented, instead
> of saying false things like "Fully qualified class names should not
> contain a 'L'." (1).
> 
> However this this code seem to pass quite number of editorials by
> different people and still has the same check. So there might be a
> reason. Given that may I ask for kind clarification of the matter?
> 
> Thank you,
> Andrey
> 
> [1] https://hg.openjdk.java.net/jdk/jdk/file/5efafa45f3b8/src/hotspot/share/classfile/classLoader.cpp#l201
> 

From neugens at redhat.com  Mon Jun  8 18:41:19 2020
From: neugens at redhat.com (Mario Torre)
Date: Mon, 8 Jun 2020 20:41:19 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ40gZKksd+7hrzGksvULbvSXALG8=c5bYF0FMARmtKgDQ@mail.gmail.com>
 <CAPb8aJ7092+zvaq02rhcU-SO3U8fSTM_P7xGpg5BRWKfyhT3sg@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
Message-ID: <CAJwKKmbgSmbbn9+ocDhgNKfdWP7GxEuqMWn8yF-GB8=fDSDWaA@mail.gmail.com>

On Mon, Jun 8, 2020 at 6:41 PM Jaroslav Bachor?k
<jaroslav.bachorik at datadoghq.com> wrote:
>
> Hi Andrew,
>
> On Mon, Jun 8, 2020 at 5:08 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
> >
> > On 08/06/2020 11:34, Jaroslav Bachor?k wrote:
> >
> > snip...
> >
> > >>
> > >> My initial thought is that, if a patch takes a long time in review,
> > >> that's probably a sign that it required a lot of debate and alteration,
> > >> and so shouldn't be going into a release late, rather than the opposite.
> > >
> > > I do not think this is a good example of a contentious issue. The RFR
> > > spent most of its time being idle waiting for review - the only issues
> > > were related to formatting and non-existent test (which does not exist
> > > upstream either). So the point about debate and alteration is rather
> > > moot here.
> > >
> >
> > Ok. I was speaking generally with regard to your comment "this patch
> > missed the cutoff date for 8u262 mostly due to review". In many cases,
> > that alone would be a reason not to include, rather than to include.
> >
> > I haven't followed the discussion that closely, but what you say about
> > this particular patch seems acceptable.
> >
> > >>
> > >> However, I'm of course open to hearing why this is critical to the 8u262
> > >> release and can't wait until 8u272.
> > >
> > > Well, not having JVM segfault on a valid use of JFR would be nice. But
> > > it's your call as the maintainer.
> > >
> >
> > Well, I need information to make such a decision :-)
> >
> > So it would help if you could answer the following:
> >
> > 1. How prolific is such usage of JFR?
>
> I guess not much since till recently each attempt would have resulted
> in segfault.
> But in general I would say that any APM/Profiler based on JFR would be
> happy not to run a special delay code to prevent segfaults.

I think at this stage there's probably no code that segfaults on 8u
because JFR is only available since the next release ;)

But 11 has been patched:

https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9982cb61e9ca

Also 13 is in the process.

So I think eventually without this patch 8u would be the only one
failing, and we don't really have the safeguard that the same failures
happen in the other releases.

Cheers,
Mario

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


From neugens at redhat.com  Mon Jun  8 18:54:54 2020
From: neugens at redhat.com (Mario Torre)
Date: Mon, 8 Jun 2020 20:54:54 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
 <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
Message-ID: <CAJwKKmZFRucTFg6yHLtLK6846Nr3EiZL8QDW13TSQ3MZCuo_qw@mail.gmail.com>

On Mon, Jun 8, 2020 at 1:27 PM Jaroslav Bachor?k
<jaroslav.bachorik at datadoghq.com> wrote:
>
> On Wed, Jun 3, 2020 at 1:05 PM Mario Torre <neugens at redhat.com> wrote:
> >
> > On Wed, Jun 3, 2020 at 12:15 PM Andrey Petushkov <andrey at azul.com> wrote:
> > >
> > > Hi Andrew,
> > >
> > > This 'L' -checking code is activated only when the method in question is
> > > given the array (i.e. the FQN of the class is something "[L...").
> > > However the caller never applies the method to array classes, only
> > > instance classes.
> > > (and I've actually checked that "L.Main" class has appeared in the JMC's
> > > "Top packages" window)
> >
> > Yeah, however it's not clear to me if this may change in the future
> > since the function has a side effect that it's not entirely specified,
> > that said however I think, if any, this is a bug in mainline and an
> > eventual fix should come in via an additional backport and not hold
> > this fix in 8u.
>
> Totally agreed - this should be done asynchronously and not held back
> by an issue in the mainline.

Absolutely, from my side this patch is reviewed and approved, but we
need a maintainer to approve the merge in JDK8u.

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 snazarkin at azul.com  Mon Jun  8 19:23:07 2020
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Mon, 8 Jun 2020 19:23:07 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
Message-ID: <7C7FFE9F-DC0C-4A84-A65B-29EEED31B43D@azul.com>

Original change
https://jira.azulsystems.com/browse/JDK-8234617

I?m not sure 8u need this but the fix reminds me recent BBB issue. 

If we need this the patch is following
webrev
http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/

c1_GraphBuilder is patched cleanly after path correction
TestPrimitiveConversions.java needs correct Asserts.java path


Sergey





From hohensee at amazon.com  Mon Jun  8 21:10:50 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 8 Jun 2020 21:10:50 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
Message-ID: <B2DE9CA8-754A-419B-AC55-72DD1FBCA8A3@amazon.com>

Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.

Thanks,
Paul

?On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:

    Original change
    https://jira.azulsystems.com/browse/JDK-8234617

    I?m not sure 8u need this but the fix reminds me recent BBB issue.

    If we need this the patch is following
    webrev
    http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/

    c1_GraphBuilder is patched cleanly after path correction
    TestPrimitiveConversions.java needs correct Asserts.java path


    Sergey






From david.holmes at oracle.com  Tue Jun  9 05:00:51 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 9 Jun 2020 15:00:51 +1000
Subject: follow-up to 8241294: Examine input checking in
 ClassLoader::package_from_class_name
In-Reply-To: <dd794f8a-9968-ebf3-7eda-8f0a65391a0d@oracle.com>
References: <CADV+1JpwoXn2UMa=aEVcX9Gg_tXEpmzvCrHRGREwhVHD3oq9JQ@mail.gmail.com>
 <dd794f8a-9968-ebf3-7eda-8f0a65391a0d@oracle.com>
Message-ID: <c037632f-aba4-f595-8dcf-3e772c96f31e@oracle.com>

On 9/06/2020 2:59 am, Claes Redestad wrote:
> Hi,
> 
> the method in question has historically been tangled up with use sites
> that pass either fully qualified class names ('java/lang/Thread') or
> class name signatures (e.g., '[Ljava/lang/Thread').

I certainly find the code in question very confusing when looking at it 
now. It seems to be expecting the FQN form, yet is within logic that 
already found the array [ and so should always expect that to be 
followed by 'L'. The code was added in 2016 under JDK-8153858:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019767.html

I reviewed it at the time, but now I am at a loss to explain it. :(

David
-----

> I have no clarifications to give other than I think the way forward is
> to ensure signatures are always parsed into their constituent parts as
> they are read from the constant pool and not allowed to roam around in
> the VM code acting as fully qualified class names (which they aren't).
> 
> /Claes
> 
> On 2020-06-08 17:20, Andrey Petushkov wrote:
>> Dear Claes, All,
>>
>> one question related to the subject. Even though it's considered
>> legitimate for the method to accept '['s at the start of the input
>> IMHO the check for subsequent 'L' is wrong and the related comment is
>> misleading.
>>
>> JLS does not prohibit class and package names to start from capital L,
>> so it's unclear why arrays of those, and only those (considering these
>> appear here in internal form) being banned?
>>
>> Moreover, given that this function is widely used it's even more
>> important that if there is some internal special case which passes
>> such forms as argument it's better to be clearly documented, instead
>> of saying false things like "Fully qualified class names should not
>> contain a 'L'." (1).
>>
>> However this this code seem to pass quite number of editorials by
>> different people and still has the same check. So there might be a
>> reason. Given that may I ask for kind clarification of the matter?
>>
>> Thank you,
>> Andrey
>>
>> [1] 
>> https://hg.openjdk.java.net/jdk/jdk/file/5efafa45f3b8/src/hotspot/share/classfile/classLoader.cpp#l201 
>>
>>

From andrey.petushkov at gmail.com  Tue Jun  9 08:28:43 2020
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Tue, 9 Jun 2020 11:28:43 +0300
Subject: follow-up to 8241294: Examine input checking in
 ClassLoader::package_from_class_name
In-Reply-To: <c037632f-aba4-f595-8dcf-3e772c96f31e@oracle.com>
References: <CADV+1JpwoXn2UMa=aEVcX9Gg_tXEpmzvCrHRGREwhVHD3oq9JQ@mail.gmail.com>
 <dd794f8a-9968-ebf3-7eda-8f0a65391a0d@oracle.com>
 <c037632f-aba4-f595-8dcf-3e772c96f31e@oracle.com>
Message-ID: <CADV+1Joys+HhpdFYMTbAFYc=AxEo2juHLxmDvJVR3maaf8O7=Q@mail.gmail.com>

Hi,

AFAICT, it's in fact not the JDK-8153858, it has only moved this code around.
The '[' and 'L' checks appeared in the initial jigsaw commit by Alan,
just in a different file (instanceKlass.cpp, (1))
It would probably be too much for me to take the task Claes
describing, of cleaning up the array class name representations
globally.
But something simpler, like trying to duplicate the method into two
forms (one for "A[]" and one for "[LA;"), I should be able to handle,
if you'd like.

Andrey

(1) https://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/c558850fac57/src/share/vm/oops/instanceKlass.cpp#l2201

On Tue, Jun 9, 2020 at 8:03 AM David Holmes <david.holmes at oracle.com> wrote:
>
> On 9/06/2020 2:59 am, Claes Redestad wrote:
> > Hi,
> >
> > the method in question has historically been tangled up with use sites
> > that pass either fully qualified class names ('java/lang/Thread') or
> > class name signatures (e.g., '[Ljava/lang/Thread').
>
> I certainly find the code in question very confusing when looking at it
> now. It seems to be expecting the FQN form, yet is within logic that
> already found the array [ and so should always expect that to be
> followed by 'L'. The code was added in 2016 under JDK-8153858:
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019767.html
>
> I reviewed it at the time, but now I am at a loss to explain it. :(
>
> David
> -----
>
> > I have no clarifications to give other than I think the way forward is
> > to ensure signatures are always parsed into their constituent parts as
> > they are read from the constant pool and not allowed to roam around in
> > the VM code acting as fully qualified class names (which they aren't).
> >
> > /Claes
> >
> > On 2020-06-08 17:20, Andrey Petushkov wrote:
> >> Dear Claes, All,
> >>
> >> one question related to the subject. Even though it's considered
> >> legitimate for the method to accept '['s at the start of the input
> >> IMHO the check for subsequent 'L' is wrong and the related comment is
> >> misleading.
> >>
> >> JLS does not prohibit class and package names to start from capital L,
> >> so it's unclear why arrays of those, and only those (considering these
> >> appear here in internal form) being banned?
> >>
> >> Moreover, given that this function is widely used it's even more
> >> important that if there is some internal special case which passes
> >> such forms as argument it's better to be clearly documented, instead
> >> of saying false things like "Fully qualified class names should not
> >> contain a 'L'." (1).
> >>
> >> However this this code seem to pass quite number of editorials by
> >> different people and still has the same check. So there might be a
> >> reason. Given that may I ask for kind clarification of the matter?
> >>
> >> Thank you,
> >> Andrey
> >>
> >> [1]
> >> https://hg.openjdk.java.net/jdk/jdk/file/5efafa45f3b8/src/hotspot/share/classfile/classLoader.cpp#l201
> >>
> >>

From aph at redhat.com  Tue Jun  9 09:51:23 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 9 Jun 2020 10:51:23 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
Message-ID: <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>

On 08/06/2020 17:41, Jaroslav Bachor?k wrote:
>> 2. What are the risks of including this patch?
>
> In general, changing the initialization order for java.lang.Class
> could cause problems for a code that would operate with assumption of
> the java.lang.Class not being initialized very early on in the JVM
> startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
> tests are still passing after adding this change

On May 15 I asked for the early initialization of java.lang.class to
be made conditional on JFR being in use. It seems this has still not
been done, even in
http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04.

-- 
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 david.holmes at oracle.com  Tue Jun  9 09:59:45 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 9 Jun 2020 19:59:45 +1000
Subject: follow-up to 8241294: Examine input checking in
 ClassLoader::package_from_class_name
In-Reply-To: <CADV+1Joys+HhpdFYMTbAFYc=AxEo2juHLxmDvJVR3maaf8O7=Q@mail.gmail.com>
References: <CADV+1JpwoXn2UMa=aEVcX9Gg_tXEpmzvCrHRGREwhVHD3oq9JQ@mail.gmail.com>
 <dd794f8a-9968-ebf3-7eda-8f0a65391a0d@oracle.com>
 <c037632f-aba4-f595-8dcf-3e772c96f31e@oracle.com>
 <CADV+1Joys+HhpdFYMTbAFYc=AxEo2juHLxmDvJVR3maaf8O7=Q@mail.gmail.com>
Message-ID: <3f53102c-5844-7534-1d38-ff51bc59a578@oracle.com>

Hi Andrey,

On 9/06/2020 6:28 pm, Andrey Petushkov wrote:
> Hi,
> 
> AFAICT, it's in fact not the JDK-8153858, it has only moved this code around.
> The '[' and 'L' checks appeared in the initial jigsaw commit by Alan,
> just in a different file (instanceKlass.cpp, (1))

Yep I missed that. Thanks.

Looking at the history there we had:

       // Skip over '['s
       if (*name1 == '[') {
         do {
           name1++;
         } while (*name1 == '[');
         if (*name1 != 'L') {
           // Something is terribly wrong.  Shouldn't be here.
           return false;
         }
       }

(and similarly for name2) which makes a lot more sense. Then the module 
system introduced:

       // Skip over '['s
       if (*base_name == '[') {
         do {
           base_name++;
         } while (*base_name == '[');
         if (*base_name != 'L') {
           // Fully qualified class names should not contain a 'L'.
           // Set length to -1 to indicate that the package name
           // could not be obtained due to an error condition.
           // In this situtation, is_same_class_package returns false.
           length = -1;
           return NULL;
         }
       }

which introduces the strange comment, but checks correctly that [ is 
followed by 'L'. Then 8153858 gave us the code we have today, where the 
comment seems to have been used to change to != to == !!!

> It would probably be too much for me to take the task Claes
> describing, of cleaning up the array class name representations
> globally.
> But something simpler, like trying to duplicate the method into two
> forms (one for "A[]" and one for "[LA;"), I should be able to handle,
> if you'd like.

I'm not at all clear what remains to be done in this area after recent 
signature code changes.

Cheers,
David
-----


> Andrey
> 
> (1) https://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/c558850fac57/src/share/vm/oops/instanceKlass.cpp#l2201
> 
> On Tue, Jun 9, 2020 at 8:03 AM David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 9/06/2020 2:59 am, Claes Redestad wrote:
>>> Hi,
>>>
>>> the method in question has historically been tangled up with use sites
>>> that pass either fully qualified class names ('java/lang/Thread') or
>>> class name signatures (e.g., '[Ljava/lang/Thread').
>>
>> I certainly find the code in question very confusing when looking at it
>> now. It seems to be expecting the FQN form, yet is within logic that
>> already found the array [ and so should always expect that to be
>> followed by 'L'. The code was added in 2016 under JDK-8153858:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019767.html
>>
>> I reviewed it at the time, but now I am at a loss to explain it. :(
>>
>> David
>> -----
>>
>>> I have no clarifications to give other than I think the way forward is
>>> to ensure signatures are always parsed into their constituent parts as
>>> they are read from the constant pool and not allowed to roam around in
>>> the VM code acting as fully qualified class names (which they aren't).
>>>
>>> /Claes
>>>
>>> On 2020-06-08 17:20, Andrey Petushkov wrote:
>>>> Dear Claes, All,
>>>>
>>>> one question related to the subject. Even though it's considered
>>>> legitimate for the method to accept '['s at the start of the input
>>>> IMHO the check for subsequent 'L' is wrong and the related comment is
>>>> misleading.
>>>>
>>>> JLS does not prohibit class and package names to start from capital L,
>>>> so it's unclear why arrays of those, and only those (considering these
>>>> appear here in internal form) being banned?
>>>>
>>>> Moreover, given that this function is widely used it's even more
>>>> important that if there is some internal special case which passes
>>>> such forms as argument it's better to be clearly documented, instead
>>>> of saying false things like "Fully qualified class names should not
>>>> contain a 'L'." (1).
>>>>
>>>> However this this code seem to pass quite number of editorials by
>>>> different people and still has the same check. So there might be a
>>>> reason. Given that may I ask for kind clarification of the matter?
>>>>
>>>> Thank you,
>>>> Andrey
>>>>
>>>> [1]
>>>> https://hg.openjdk.java.net/jdk/jdk/file/5efafa45f3b8/src/hotspot/share/classfile/classLoader.cpp#l201
>>>>
>>>>

From mbalao at redhat.com  Tue Jun  9 16:07:04 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 9 Jun 2020 13:07:04 -0300
Subject: [8u] TLSv1.3 RFR: 8245473: OCSP stapling support
In-Reply-To: <A4A56321-60A3-4FBD-8A7E-9223E4AF7A1E@azul.com>
References: <A6932CAA-9ED3-489C-A9FB-C956BBF1D24E@azul.com>
 <d7928299-6914-4375-5961-ba9fcfc012f2@redhat.com>
 <A4A56321-60A3-4FBD-8A7E-9223E4AF7A1E@azul.com>
Message-ID: <e61aeb6d-7411-be11-8715-098e85936ddc@redhat.com>

Hi Alexey,

My reply inline.

Thanks,
Martin.-


On 6/6/20 6:14 PM, Alexey Bakhtin wrote:
> Yes, OCSP stapling related test are added in JDK-8245681:
> - test/java/security/testlibrary/CertificateBuilder.java
> - test/java/security/testlibrary/SimpleOCSPServer.java
> - test/javax/net/ssl/Stapling/*
> - sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java
> - sun/security/provider/certpath/ResponderId/ResponderIdTests.java
> - sun/security/ssl/Stapling/StatusResponseManagerTests.java
> 

Good, I'll analyze them later then.

>>
>> * SSLContextImpl.java
>>
>> Why did you turn 'jdk.tls.client.enableStatusRequestExtension' to
>> 'false' by default?
>>
>> A CSR will be needed if we are introducing new properties anyways.
>>
> OCSP Stapling should be disabled by default to minimise possible difference for
> existing 8u applications.
> You are right. It should be documented in CSR

Hmm.. okay. I see your point but OCSP stapling on the server side is
still important for performance reasons. We need to turn this 'on' at
some point. Please keep that in your backlog.

> 
>> * X509TrustManagerImpl.java
>>
>> You probably want to make some changes here after I asked you to remove
>> changes introduced for Step 3 (8245470). However, before casting to
>> SSLSessionImpl I'd suggest to add a 'instanceof' check. If, for any
>> reason, it's a JDK-8 ExtendedSSLSession implementation class different
>> than SSLSessionImpl, we shouldn't fail because having the
>> getStatusResponses method was not part of the contract at that time.
>>
> Agree. You are right. Will be fixed

Let me know if you have a new Webrev.

> 
>> * OCSP.java
>>
>> Why are these changes not included?
> 
> OCSP.java is identical in JDK8 and JDK11.
> No changes required
> 

Ah, ok. Seems like 8176536 introduced many of the changes needed for the
files to be identical.

>>
>> * OCSPRequest.java
>>
> OCSPRequest.java is identical in JDK8 and JDK11.
> No changes required

Good.

> 
>> Why are these changes not included?
>>
>> * OCSPResponse.java
>>
> OCSPResponse.java is identical in JDK8 and JDK11.
> No changes required

Good.

> 
>> Why are these changes not included?
>>
>> * ResponderId.java
> 
> ResponderId.java  is identical in JDK8 and JDK11.
> No changes required

Yes, only a typo fixed by 8190323. Not a big deal and it's not worth to
backport it separately. If you want to fix it here, I'm okay too.

>>
>> Why are these changes not included?
>>
>> * Validator.java
>>
>> Seems to be including changes from 8154015. Why? Looks to me that
>> 8154015 was introduced to JDK-8 and then backed out.
>>
> Do you mean changes in comments ? Yes, I can revert them. Will be fixed
> The rest changes should be fine and identical to JDK-8046321 changes.
> 

All the differences visible when comparing 8245473 with 8046321 in
Validator.java, unless there is a good reason to have them. Looks to me
that there shouldn't be traces from 8154015, but let me know if I'm wrong.

>> I suggest not to bump the copyright end date.
>>
>> * PKIXExtensions.java
> PKIXExtensions.java is identical in JDK8 and JDK11.
> No changes required
> 

Good.

>>
>> * RevocationChecker.java
>>
>> Why are we including changes from 8161973 here? Please propose 8161973
>> as an independent backport.
> 
> It is important fix. Without this fix OCSP functionality works incorrectly and several test fails.
> I?d like this fix is ported as part of this OCSP backport.
> Otherwise we?ll ship TLS functionality with known bug
> Possible solution - additional step for this fix in terms of JDK-8245466

Yes, I wish we could have a separate step for this fix. 8245473 should
be referred in the commit message as the backport of 8046321, while
there should be a separate commit for the backport of 8161973. Sorry
about the overhead but this will make it easier to understand the
changes in the future: instead of a single backport with both patches
mixed we will have 2 separate -and almost straightforward- backports.

Note: it's very important to have a reference to 8046321 in the commit
message so we can find it in the repo. That reference must be: "8046321:
OCSP Stapling for TLS", as we do with all the backports.


From snazarkin at azul.com  Tue Jun  9 16:39:56 2020
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Tue, 9 Jun 2020 16:39:56 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
In-Reply-To: <B2DE9CA8-754A-419B-AC55-72DD1FBCA8A3@amazon.com>
References: <B2DE9CA8-754A-419B-AC55-72DD1FBCA8A3@amazon.com>
Message-ID: <39DFD70C-F44B-4792-878A-A9CF53E5CC1F@azul.com>

Thanks, Paul

One question regarding new tests path. The files are placed according to non-jdk8 rules. Shouldn?t them be placed under test/compiler/conversions/ folder?

 
Sergey Nazarkin




> On Jun 9, 2020, at 00:10, Hohensee, Paul <hohensee at amazon.com> wrote:
> 
> Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.
> 
> Thanks,
> Paul
> 
> ?On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:
> 
>    Original change
>    https://jira.azulsystems.com/browse/JDK-8234617
> 
>    I?m not sure 8u need this but the fix reminds me recent BBB issue.
> 
>    If we need this the patch is following
>    webrev
>    http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/
> 
>    c1_GraphBuilder is patched cleanly after path correction
>    TestPrimitiveConversions.java needs correct Asserts.java path
> 
> 
>    Sergey
> 
> 
> 
> 
> 


From hohensee at amazon.com  Tue Jun  9 17:38:02 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 9 Jun 2020 17:38:02 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
Message-ID: <19813190-AB77-46F6-9CD5-55A0E93D5020@amazon.com>

You're correct, I missed that. They should indeed go under hotspot/test/compiler/conversions, which is a new directory in jdk8. There's no global test directory and no hotspot/jtreg directory in jdk8.

Thanks,
Paul

?On 6/9/20, 9:45 AM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:

    Thanks, Paul

    One question regarding new tests path. The files are placed according to non-jdk8 rules. Shouldn?t them be placed under test/compiler/conversions/ folder?


    Sergey Nazarkin




    > On Jun 9, 2020, at 00:10, Hohensee, Paul <hohensee at amazon.com> wrote:
    >
    > Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.
    >
    > Thanks,
    > Paul
    >
    > On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:
    >
    >    Original change
    >    https://jira.azulsystems.com/browse/JDK-8234617
    >
    >    I?m not sure 8u need this but the fix reminds me recent BBB issue.
    >
    >    If we need this the patch is following
    >    webrev
    >    http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/
    >
    >    c1_GraphBuilder is patched cleanly after path correction
    >    TestPrimitiveConversions.java needs correct Asserts.java path
    >
    >
    >    Sergey
    >
    >
    >
    >
    >



From alexey at azul.com  Tue Jun  9 20:00:15 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 9 Jun 2020 20:00:15 +0000
Subject: [8u] TLSv1.3 RFR: 8245473: OCSP stapling support
In-Reply-To: <e61aeb6d-7411-be11-8715-098e85936ddc@redhat.com>
References: <A6932CAA-9ED3-489C-A9FB-C956BBF1D24E@azul.com>
 <d7928299-6914-4375-5961-ba9fcfc012f2@redhat.com>
 <A4A56321-60A3-4FBD-8A7E-9223E4AF7A1E@azul.com>
 <e61aeb6d-7411-be11-8715-098e85936ddc@redhat.com>
Message-ID: <9B6CCFE9-AD17-4D74-8E52-32C8EC2797E5@azul.com>

Hello Martin,

Please find the updated version of the patch:
http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245473/webrev.v1/


In this version :
- Added instanceof verification in the X509TrustManagerImpl.java
- JDK-8154015 changes are excluded from the Validator.java
- RevocationChecker.java is reverted. It will be fixed as separate backport of JDK-8161973
  JDK-8247276 subtask is submitted
- commit message changed to ?8046321: OCSP Stapling for TLS"

Regards
Alexey


> On 9 Jun 2020, at 19:07, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> My reply inline.
> 
> Thanks,
> Martin.-
> 
> 
> On 6/6/20 6:14 PM, Alexey Bakhtin wrote:
>> Yes, OCSP stapling related test are added in JDK-8245681:
>> - test/java/security/testlibrary/CertificateBuilder.java
>> - test/java/security/testlibrary/SimpleOCSPServer.java
>> - test/javax/net/ssl/Stapling/*
>> - sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java
>> - sun/security/provider/certpath/ResponderId/ResponderIdTests.java
>> - sun/security/ssl/Stapling/StatusResponseManagerTests.java
>> 
> 
> Good, I'll analyze them later then.
> 
>>> 
>>> * SSLContextImpl.java
>>> 
>>> Why did you turn 'jdk.tls.client.enableStatusRequestExtension' to
>>> 'false' by default?
>>> 
>>> A CSR will be needed if we are introducing new properties anyways.
>>> 
>> OCSP Stapling should be disabled by default to minimise possible difference for
>> existing 8u applications.
>> You are right. It should be documented in CSR
> 
> Hmm.. okay. I see your point but OCSP stapling on the server side is
> still important for performance reasons. We need to turn this 'on' at
> some point. Please keep that in your backlog.
> 
>> 
>>> * X509TrustManagerImpl.java
>>> 
>>> You probably want to make some changes here after I asked you to remove
>>> changes introduced for Step 3 (8245470). However, before casting to
>>> SSLSessionImpl I'd suggest to add a 'instanceof' check. If, for any
>>> reason, it's a JDK-8 ExtendedSSLSession implementation class different
>>> than SSLSessionImpl, we shouldn't fail because having the
>>> getStatusResponses method was not part of the contract at that time.
>>> 
>> Agree. You are right. Will be fixed
> 
> Let me know if you have a new Webrev.
> 
>> 
>>> * OCSP.java
>>> 
>>> Why are these changes not included?
>> 
>> OCSP.java is identical in JDK8 and JDK11.
>> No changes required
>> 
> 
> Ah, ok. Seems like 8176536 introduced many of the changes needed for the
> files to be identical.
> 
>>> 
>>> * OCSPRequest.java
>>> 
>> OCSPRequest.java is identical in JDK8 and JDK11.
>> No changes required
> 
> Good.
> 
>> 
>>> Why are these changes not included?
>>> 
>>> * OCSPResponse.java
>>> 
>> OCSPResponse.java is identical in JDK8 and JDK11.
>> No changes required
> 
> Good.
> 
>> 
>>> Why are these changes not included?
>>> 
>>> * ResponderId.java
>> 
>> ResponderId.java  is identical in JDK8 and JDK11.
>> No changes required
> 
> Yes, only a typo fixed by 8190323. Not a big deal and it's not worth to
> backport it separately. If you want to fix it here, I'm okay too.
> 
>>> 
>>> Why are these changes not included?
>>> 
>>> * Validator.java
>>> 
>>> Seems to be including changes from 8154015. Why? Looks to me that
>>> 8154015 was introduced to JDK-8 and then backed out.
>>> 
>> Do you mean changes in comments ? Yes, I can revert them. Will be fixed
>> The rest changes should be fine and identical to JDK-8046321 changes.
>> 
> 
> All the differences visible when comparing 8245473 with 8046321 in
> Validator.java, unless there is a good reason to have them. Looks to me
> that there shouldn't be traces from 8154015, but let me know if I'm wrong.
> 
>>> I suggest not to bump the copyright end date.
>>> 
>>> * PKIXExtensions.java
>> PKIXExtensions.java is identical in JDK8 and JDK11.
>> No changes required
>> 
> 
> Good.
> 
>>> 
>>> * RevocationChecker.java
>>> 
>>> Why are we including changes from 8161973 here? Please propose 8161973
>>> as an independent backport.
>> 
>> It is important fix. Without this fix OCSP functionality works incorrectly and several test fails.
>> I?d like this fix is ported as part of this OCSP backport.
>> Otherwise we?ll ship TLS functionality with known bug
>> Possible solution - additional step for this fix in terms of JDK-8245466
> 
> Yes, I wish we could have a separate step for this fix. 8245473 should
> be referred in the commit message as the backport of 8046321, while
> there should be a separate commit for the backport of 8161973. Sorry
> about the overhead but this will make it easier to understand the
> changes in the future: instead of a single backport with both patches
> mixed we will have 2 separate -and almost straightforward- backports.
> 
> Note: it's very important to have a reference to 8046321 in the commit
> message so we can find it in the repo. That reference must be: "8046321:
> OCSP Stapling for TLS", as we do with all the backports.
> 


From snazarkin at azul.com  Tue Jun  9 20:01:15 2020
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Tue, 9 Jun 2020 20:01:15 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
In-Reply-To: <19813190-AB77-46F6-9CD5-55A0E93D5020@amazon.com>
References: <19813190-AB77-46F6-9CD5-55A0E93D5020@amazon.com>
Message-ID: <7EA626C7-2967-45AF-9A7F-72B91761B745@azul.com>

Updated review and marked the bug


Sergey Nazarkin




> On Jun 9, 2020, at 20:38, Hohensee, Paul <hohensee at amazon.com> wrote:
> 
> You're correct, I missed that. They should indeed go under hotspot/test/compiler/conversions, which is a new directory in jdk8. There's no global test directory and no hotspot/jtreg directory in jdk8.
> 
> Thanks,
> Paul
> 
> ?On 6/9/20, 9:45 AM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:
> 
>    Thanks, Paul
> 
>    One question regarding new tests path. The files are placed according to non-jdk8 rules. Shouldn?t them be placed under test/compiler/conversions/ folder?
> 
> 
>    Sergey Nazarkin
> 
> 
> 
> 
>> On Jun 9, 2020, at 00:10, Hohensee, Paul <hohensee at amazon.com> wrote:
>> 
>> Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.
>> 
>> Thanks,
>> Paul
>> 
>> On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:
>> 
>>   Original change
>>   https://jira.azulsystems.com/browse/JDK-8234617
>> 
>>   I?m not sure 8u need this but the fix reminds me recent BBB issue.
>> 
>>   If we need this the patch is following
>>   webrev
>>   http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/
>> 
>>   c1_GraphBuilder is patched cleanly after path correction
>>   TestPrimitiveConversions.java needs correct Asserts.java path
>> 
>> 
>>   Sergey
>> 
>> 
>> 
>> 
>> 
> 
> 


From hohensee at amazon.com  Tue Jun  9 20:10:51 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 9 Jun 2020 20:10:51 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
Message-ID: <1FBBB428-6396-47DF-8972-8B629EA023CA@amazon.com>

Need to update the webrev with the correct test location.

Paul

?On 6/9/20, 1:02 PM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:

    Updated review and marked the bug


    Sergey Nazarkin




    > On Jun 9, 2020, at 20:38, Hohensee, Paul <hohensee at amazon.com> wrote:
    >
    > You're correct, I missed that. They should indeed go under hotspot/test/compiler/conversions, which is a new directory in jdk8. There's no global test directory and no hotspot/jtreg directory in jdk8.
    >
    > Thanks,
    > Paul
    >
    > On 6/9/20, 9:45 AM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:
    >
    >    Thanks, Paul
    >
    >    One question regarding new tests path. The files are placed according to non-jdk8 rules. Shouldn?t them be placed under test/compiler/conversions/ folder?
    >
    >
    >    Sergey Nazarkin
    >
    >
    >
    >
    >> On Jun 9, 2020, at 00:10, Hohensee, Paul <hohensee at amazon.com> wrote:
    >>
    >> Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.
    >>
    >> Thanks,
    >> Paul
    >>
    >> On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:
    >>
    >>   Original change
    >>   https://jira.azulsystems.com/browse/JDK-8234617
    >>
    >>   I?m not sure 8u need this but the fix reminds me recent BBB issue.
    >>
    >>   If we need this the patch is following
    >>   webrev
    >>   http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/
    >>
    >>   c1_GraphBuilder is patched cleanly after path correction
    >>   TestPrimitiveConversions.java needs correct Asserts.java path
    >>
    >>
    >>   Sergey
    >>
    >>
    >>
    >>
    >>
    >
    >



From snazarkin at azul.com  Tue Jun  9 20:14:07 2020
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Tue, 9 Jun 2020 20:14:07 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
In-Reply-To: <1FBBB428-6396-47DF-8972-8B629EA023CA@amazon.com>
References: <1FBBB428-6396-47DF-8972-8B629EA023CA@amazon.com>
Message-ID: <A4044B45-ADAA-465C-AEF5-37F5CBF1BF6A@azul.com>

It is updated and placed under the same webrev

http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/



Sergey Nazarkin




> On Jun 9, 2020, at 23:10, Hohensee, Paul <hohensee at amazon.com> wrote:
> 
> Need to update the webrev with the correct test location.
> 
> Paul
> 
> ?On 6/9/20, 1:02 PM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:
> 
>    Updated review and marked the bug
> 
> 
>    Sergey Nazarkin
> 
> 
> 
> 
>> On Jun 9, 2020, at 20:38, Hohensee, Paul <hohensee at amazon.com> wrote:
>> 
>> You're correct, I missed that. They should indeed go under hotspot/test/compiler/conversions, which is a new directory in jdk8. There's no global test directory and no hotspot/jtreg directory in jdk8.
>> 
>> Thanks,
>> Paul
>> 
>> On 6/9/20, 9:45 AM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:
>> 
>>   Thanks, Paul
>> 
>>   One question regarding new tests path. The files are placed according to non-jdk8 rules. Shouldn?t them be placed under test/compiler/conversions/ folder?
>> 
>> 
>>   Sergey Nazarkin
>> 
>> 
>> 
>> 
>>> On Jun 9, 2020, at 00:10, Hohensee, Paul <hohensee at amazon.com> wrote:
>>> 
>>> Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.
>>> 
>>> Thanks,
>>> Paul
>>> 
>>> On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:
>>> 
>>>  Original change
>>>  https://jira.azulsystems.com/browse/JDK-8234617
>>> 
>>>  I?m not sure 8u need this but the fix reminds me recent BBB issue.
>>> 
>>>  If we need this the patch is following
>>>  webrev
>>>  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/
>>> 
>>>  c1_GraphBuilder is patched cleanly after path correction
>>>  TestPrimitiveConversions.java needs correct Asserts.java path
>>> 
>>> 
>>>  Sergey
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 


From gnu.andrew at redhat.com  Tue Jun  9 23:51:22 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Jun 2020 00:51:22 +0100
Subject: [RFR] [8u262] JDK-8243541: (tz) Upgrade time-zone data to tzdata2020a
Message-ID: <884e54f6-8383-b6ad-2420-50d34606f06b@redhat.com>

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

This patch updates the tzdata in OpenJDK 8u to the 2020a release. Unlike
in OpenJDK 11 and later, this version uses the rearguard format. I did
start looking at backporting JDK-8212970 to switch 8u to vanguard
format, but it ended up developing into more of a rewrite than a
backport. As such, I'll finish that up & propose it for 8u272, while
this update is for 8u262 and I'll flag with jdk8u-critical-fix once
reviewed.

Differences from the 11u/15u version:

* The rules for Morocco and Namibia are in rearguard format (no negative
offsets). This data was generated from the tzdata2020a release and
running 'make rearguard_tarballs' as specified in the copy of the
release notes in the bug. The updated files were then concatenated onto
the appropriate Oracle boilerplate and copied over the 8u tzdata2019c files.
* test/java/time/test/java/time/format/ZoneName.java in 8u is a mess. I
added the new aliases to the alias map for this update, but I'll look
whether JDK-8189784 (or at least the test part, as it's an 8->9
regression) & JDK-8201507 are worth backporting.
* We also update the copy of the tzdata in test/sun/util/calendar/zi.
JDK-8212970, the vanguard patch, also removes this and makes the test
use the make/data/tzdata copy instead. This is why updating this was
missed when backporting tzdata2019b & tzdata2019c, leading to this being
an update from tzdata2019a to tzdata2020a.

The test/sun/util/calendar/zi & test/java/time/test/java/time tests
passed after applying this patch.

Thanks,
-- 
Andrew :)

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

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


From martinrb at google.com  Wed Jun 10 00:34:07 2020
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Jun 2020 17:34:07 -0700
Subject: [RFR] [8u262] JDK-8243541: (tz) Upgrade time-zone data to
 tzdata2020a
In-Reply-To: <884e54f6-8383-b6ad-2420-50d34606f06b@redhat.com>
References: <884e54f6-8383-b6ad-2420-50d34606f06b@redhat.com>
Message-ID: <CA+kOe09krMmDRsauTbFrUu36Q+MQRj4F-98ut4URJc5gPnQaXQ@mail.gmail.com>

Looks good.  At Google we also unsurprisingly used rearguard tzdata for jdk8.

On Tue, Jun 9, 2020 at 4:52 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8243541
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8243541/webrev.01/
>
> This patch updates the tzdata in OpenJDK 8u to the 2020a release. Unlike
> in OpenJDK 11 and later, this version uses the rearguard format. I did
> start looking at backporting JDK-8212970 to switch 8u to vanguard
> format, but it ended up developing into more of a rewrite than a
> backport. As such, I'll finish that up & propose it for 8u272, while
> this update is for 8u262 and I'll flag with jdk8u-critical-fix once
> reviewed.
>
> Differences from the 11u/15u version:
>
> * The rules for Morocco and Namibia are in rearguard format (no negative
> offsets). This data was generated from the tzdata2020a release and
> running 'make rearguard_tarballs' as specified in the copy of the
> release notes in the bug. The updated files were then concatenated onto
> the appropriate Oracle boilerplate and copied over the 8u tzdata2019c files.
> * test/java/time/test/java/time/format/ZoneName.java in 8u is a mess. I
> added the new aliases to the alias map for this update, but I'll look
> whether JDK-8189784 (or at least the test part, as it's an 8->9
> regression) & JDK-8201507 are worth backporting.
> * We also update the copy of the tzdata in test/sun/util/calendar/zi.
> JDK-8212970, the vanguard patch, also removes this and makes the test
> use the make/data/tzdata copy instead. This is why updating this was
> missed when backporting tzdata2019b & tzdata2019c, leading to this being
> an update from tzdata2019a to tzdata2020a.
>
> The test/sun/util/calendar/zi & test/java/time/test/java/time tests
> passed after applying this patch.
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From jaroslav.bachorik at datadoghq.com  Wed Jun 10 08:27:39 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 10 Jun 2020 10:27:39 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
Message-ID: <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>

On Tue, Jun 9, 2020 at 11:51 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 08/06/2020 17:41, Jaroslav Bachor?k wrote:
> >> 2. What are the risks of including this patch?
> >
> > In general, changing the initialization order for java.lang.Class
> > could cause problems for a code that would operate with assumption of
> > the java.lang.Class not being initialized very early on in the JVM
> > startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
> > tests are still passing after adding this change
>
> On May 15 I asked for the early initialization of java.lang.class to
> be made conditional on JFR being in use. It seems this has still not
> been done, even in
> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04.

http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04/src/share/vm/runtime/thread.cpp.sdiff.html
L3505-3508 is not sufficient?
The JFR specific earlier initialization is guarded by if-block. Then,
the original initialization block is at L3521-3524 and will be run if
JFR is not enabled.

-JB-

>
> --
> 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 aph at redhat.com  Wed Jun 10 09:38:46 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Jun 2020 10:38:46 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
Message-ID: <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>

On 10/06/2020 09:27, Jaroslav Bachor?k wrote:
> On Tue, Jun 9, 2020 at 11:51 AM Andrew Haley <aph at redhat.com> wrote:
>>
>> On 08/06/2020 17:41, Jaroslav Bachor?k wrote:
>>>> 2. What are the risks of including this patch?
>>>
>>> In general, changing the initialization order for java.lang.Class
>>> could cause problems for a code that would operate with assumption of
>>> the java.lang.Class not being initialized very early on in the JVM
>>> startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
>>> tests are still passing after adding this change
>>
>> On May 15 I asked for the early initialization of java.lang.class to
>> be made conditional on JFR being in use. It seems this has still not
>> been done, even in
>> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04.
> 
> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04/src/share/vm/runtime/thread.cpp.sdiff.html
> L3505-3508 is not sufficient?
> The JFR specific earlier initialization is guarded by if-block. Then,
> the original initialization block is at L3521-3524 and will be run if
> JFR is not enabled.

I'm looking at this:

3505 #if INCLUDE_JFR
3506     // The VM creates & returns objects of this class. Make sure it's initialized.
3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
3508 #endif

ISTM that this code is run unconditionally if INCLUDE_JFR is set at compile
time. Am I misunderstanding something?

If this is not true, and the initialize_class only runs if JFR is
enabled, how does that work?

-- 
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 jaroslav.bachorik at datadoghq.com  Wed Jun 10 12:31:38 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 10 Jun 2020 14:31:38 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
Message-ID: <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>

On Wed, Jun 10, 2020 at 11:38 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 10/06/2020 09:27, Jaroslav Bachor?k wrote:
> > On Tue, Jun 9, 2020 at 11:51 AM Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 08/06/2020 17:41, Jaroslav Bachor?k wrote:
> >>>> 2. What are the risks of including this patch?
> >>>
> >>> In general, changing the initialization order for java.lang.Class
> >>> could cause problems for a code that would operate with assumption of
> >>> the java.lang.Class not being initialized very early on in the JVM
> >>> startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
> >>> tests are still passing after adding this change
> >>
> >> On May 15 I asked for the early initialization of java.lang.class to
> >> be made conditional on JFR being in use. It seems this has still not
> >> been done, even in
> >> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04.
> >
> > http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.04/src/share/vm/runtime/thread.cpp.sdiff.html
> > L3505-3508 is not sufficient?
> > The JFR specific earlier initialization is guarded by if-block. Then,
> > the original initialization block is at L3521-3524 and will be run if
> > JFR is not enabled.
>
> I'm looking at this:
>
> 3505 #if INCLUDE_JFR
> 3506     // The VM creates & returns objects of this class. Make sure it's initialized.
> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
> 3508 #endif
>
> ISTM that this code is run unconditionally if INCLUDE_JFR is set at compile
> time. Am I misunderstanding something?

Ok. I misunderstood the original request. I thought it was supposed to
be in-line with other JFR specific changes which are guarded with
compile-time conditional blocks.

>
> If this is not true, and the initialize_class only runs if JFR is
> enabled, how does that work?

This thing you ask (runtime check for whether JFR is enabled) is
impossible at that place, AFAIK. The affected code is in 'create_vm'
block so JVM is not really alive. Checking the JFR enabled status
requires parsing JFR configs which happens to be done in Java and that
requires java.lang.Class to be already linked and initialized - making
it impossible to check the JFR enablement status before initializing
java.lang.Class.

-JB-

>
> --
> 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 aph at redhat.com  Wed Jun 10 13:14:54 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Jun 2020 14:14:54 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
Message-ID: <4156b995-3d2f-73d8-4b18-8da95d698380@redhat.com>

On 10/06/2020 13:31, Jaroslav Bachor?k wrote:
>> ISTM that this code is run unconditionally if INCLUDE_JFR is set at compile
>> time. Am I misunderstanding something?
>
> Ok. I misunderstood the original request. I thought it was supposed to
> be in-line with other JFR specific changes which are guarded with
> compile-time conditional blocks.
> 
>> If this is not true, and the initialize_class only runs if JFR is
>> enabled, how does that work?
>
> This thing you ask (runtime check for whether JFR is enabled) is
> impossible at that place, AFAIK. The affected code is in 'create_vm'
> block so JVM is not really alive. Checking the JFR enabled status
> requires parsing JFR configs which happens to be done in Java and that
> requires java.lang.Class to be already linked and initialized - making
> it impossible to check the JFR enablement status before initializing
> java.lang.Class.

So, then, I take it that the JFR configs are always opened and run,
regardless of whether JFR is in use, in order to determine whether JFR
is in use? Please point me to the code that does this.

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


From gnu.andrew at redhat.com  Wed Jun 10 13:41:21 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Jun 2020 14:41:21 +0100
Subject: [RFR] [8u262] JDK-8243541: (tz) Upgrade time-zone data to
 tzdata2020a
In-Reply-To: <CA+kOe09krMmDRsauTbFrUu36Q+MQRj4F-98ut4URJc5gPnQaXQ@mail.gmail.com>
References: <884e54f6-8383-b6ad-2420-50d34606f06b@redhat.com>
 <CA+kOe09krMmDRsauTbFrUu36Q+MQRj4F-98ut4URJc5gPnQaXQ@mail.gmail.com>
Message-ID: <1f179f65-2f6c-e8a8-ec39-cea6208575cd@redhat.com>

On 10/06/2020 01:34, Martin Buchholz wrote:
> Looks good.  At Google we also unsurprisingly used rearguard tzdata for jdk8.
> 

Thanks for the quick review, Martin.

What are your thoughts on moving 8u over to vanguard? The patch so far
is looking relatively straight-forward (the difficulty is a bunch of
refactoring in 11u, plus some superfluous changes in the changeset) and
I don't fancy relying on rearguard being continually available, given 8u
may be around for a while yet.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Wed Jun 10 13:45:22 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Jun 2020 14:45:22 +0100
Subject: OpenJDK 8u262-b06 EA Released
Message-ID: <85db79a5-1f8c-1e5f-4a9a-408b3f2b023c@redhat.com>

I've made available an early access source bundle for 8u262, based on
the tag jdk8u262-b06:

https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b06-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b06-ea.tar.xz.sig

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

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

SHA256 checksums:

398f67fe6be6b190977805d3f6373cd31a14edd337fa964dc8231b3426d67367
openjdk8u262-b06-ea.tar.xz
998d628874596f2f81963435ed931c49aede893fa3936b4d41db8b44e21cff22
openjdk8u262-b06-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b06-ea.sha256

Changes in 8u262-b06:
  - S8246223: Windows build fails after JDK-8227269

Thanks,
-- 
Andrew :)

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

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


From martinrb at google.com  Wed Jun 10 15:36:09 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Jun 2020 08:36:09 -0700
Subject: [RFR] [8u262] JDK-8243541: (tz) Upgrade time-zone data to
 tzdata2020a
In-Reply-To: <1f179f65-2f6c-e8a8-ec39-cea6208575cd@redhat.com>
References: <884e54f6-8383-b6ad-2420-50d34606f06b@redhat.com>
 <CA+kOe09krMmDRsauTbFrUu36Q+MQRj4F-98ut4URJc5gPnQaXQ@mail.gmail.com>
 <1f179f65-2f6c-e8a8-ec39-cea6208575cd@redhat.com>
Message-ID: <CA+kOe0-MOb2m1icgWtSQn0ktp02RjKR-V=Qe-yO1RJTumMV02A@mail.gmail.com>

On Wed, Jun 10, 2020 at 6:41 AM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 10/06/2020 01:34, Martin Buchholz wrote:
> > Looks good.  At Google we also unsurprisingly used rearguard tzdata for jdk8.
> >
>
> Thanks for the quick review, Martin.
>
> What are your thoughts on moving 8u over to vanguard? The patch so far
> is looking relatively straight-forward (the difficulty is a bunch of
> refactoring in 11u, plus some superfluous changes in the changeset) and
> I don't fancy relying on rearguard being continually available, given 8u
> may be around for a while yet.

I am biased because I was opposed to the changes that are part of IANA
vanguard (along with many other people), and I've already invested
effort into staying on rearguard, and I'm more conservative about
adding new features to old releases.  But of course the world has to
migrate to vanguard.

I would choose to keep jdk8 (and jdk7, and jdk6 !) on rearguard
forever, and switch newer ones to vanguard.
If upstream IANA drops support for rearguard, it's probably easy
enough to do it ourselves.

>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From hohensee at amazon.com  Wed Jun 10 15:44:50 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 10 Jun 2020 15:44:50 +0000
Subject: RFR: 8234617: C1: Incorrect result of field load due to missing
 narrowing conversion
Message-ID: <37052FE6-F112-4742-9467-0C25583CD154@amazon.com>

Thanks,

Paul

?On 6/9/20, 1:14 PM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:

    It is updated and placed under the same webrev

    http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/



    Sergey Nazarkin




    > On Jun 9, 2020, at 23:10, Hohensee, Paul <hohensee at amazon.com> wrote:
    >
    > Need to update the webrev with the correct test location.
    >
    > Paul
    >
    > On 6/9/20, 1:02 PM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:
    >
    >    Updated review and marked the bug
    >
    >
    >    Sergey Nazarkin
    >
    >
    >
    >
    >> On Jun 9, 2020, at 20:38, Hohensee, Paul <hohensee at amazon.com> wrote:
    >>
    >> You're correct, I missed that. They should indeed go under hotspot/test/compiler/conversions, which is a new directory in jdk8. There's no global test directory and no hotspot/jtreg directory in jdk8.
    >>
    >> Thanks,
    >> Paul
    >>
    >> On 6/9/20, 9:45 AM, "Sergey Nazarkin" <snazarkin at azul.com> wrote:
    >>
    >>   Thanks, Paul
    >>
    >>   One question regarding new tests path. The files are placed according to non-jdk8 rules. Shouldn?t them be placed under test/compiler/conversions/ folder?
    >>
    >>
    >>   Sergey Nazarkin
    >>
    >>
    >>
    >>
    >>> On Jun 9, 2020, at 00:10, Hohensee, Paul <hohensee at amazon.com> wrote:
    >>>
    >>> Lgtm, assuming TestPrimitiveConversions.java passes. Worth doing because it's a simple fix, for a bug which can manifest as data corruption.
    >>>
    >>> Thanks,
    >>> Paul
    >>>
    >>> On 6/8/20, 12:24 PM, "jdk8u-dev on behalf of Sergey Nazarkin" <jdk8u-dev-bounces at openjdk.java.net on behalf of snazarkin at azul.com> wrote:
    >>>
    >>>  Original change
    >>>  https://jira.azulsystems.com/browse/JDK-8234617
    >>>
    >>>  I?m not sure 8u need this but the fix reminds me recent BBB issue.
    >>>
    >>>  If we need this the patch is following
    >>>  webrev
    >>>  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8234617/
    >>>
    >>>  c1_GraphBuilder is patched cleanly after path correction
    >>>  TestPrimitiveConversions.java needs correct Asserts.java path
    >>>
    >>>
    >>>  Sergey
    >>>
    >>>
    >>>
    >>>
    >>>
    >>
    >>
    >
    >



From adinn at redhat.com  Wed Jun 10 15:46:06 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 10 Jun 2020 16:46:06 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
Message-ID: <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>

On 10/06/2020 13:31, Jaroslav Bachor?k wrote:
>> 3505 #if INCLUDE_JFR
>> 3506     // The VM creates & returns objects of this class. Make sure it's initialized.
>> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
>> 3508 #endif
>>
>> ISTM that this code is run unconditionally if INCLUDE_JFR is set at compile
>> time. Am I misunderstanding something?
> 
> Ok. I misunderstood the original request. I thought it was supposed to
> be in-line with other JFR specific changes which are guarded with
> compile-time conditional blocks.
> 
>>
>> If this is not true, and the initialize_class only runs if JFR is
>> enabled, how does that work?
> 
> This thing you ask (runtime check for whether JFR is enabled) is
> impossible at that place, AFAIK. The affected code is in 'create_vm'
> block so JVM is not really alive. Checking the JFR enabled status
> requires parsing JFR configs which happens to be done in Java and that
> requires java.lang.Class to be already linked and initialized - making
> it impossible to check the JFR enablement status before initializing
> java.lang.Class.
How is that so? I believe command line arguments will have been
processed at this stage. If so then you can easily detect whether or not
JFR has been enabled on the command line. The simplest thing is to check
global boolean FlightRecorder. This global is set from the command line
using -X:+FlightRecorder and cleared using -X:-FlightRecorder. If not
specified it defaults to false.

So, in the case where JFR is conditionally compiled in you can call
initialize_class() early if FlightRecorder is true and call it at the
normal point of FlightRecorder is false.

In the case where JFR is conditionally compiled out then the call should
happen late as happened before this patch.

Is there any reason why that won't work?

regards,


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


From neugens.limasoftware at gmail.com  Wed Jun 10 16:05:55 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 10 Jun 2020 18:05:55 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
Message-ID: <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>

Doesn?t that create an issue when JFR is not started but then enabled at
runtime via the agent?

So far the only use case for this was attaching via JMX but an agent could
still request JFR, I?m not sure if creating a recording in pre-main is a
legal use case or not though.

Btw, this patch has been backported in 11 and 13 without this level of
discussion, I guess we should revisit those patches too at this point.

Cheers,
Mario

On Wed 10. Jun 2020 at 17:48, Andrew Dinn <adinn at redhat.com> wrote:

> On 10/06/2020 13:31, Jaroslav Bachor?k wrote:
> >> 3505 #if INCLUDE_JFR
> >> 3506     // The VM creates & returns objects of this class. Make sure
> it's initialized.
> >> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
> >> 3508 #endif
> >>
> >> ISTM that this code is run unconditionally if INCLUDE_JFR is set at
> compile
> >> time. Am I misunderstanding something?
> >
> > Ok. I misunderstood the original request. I thought it was supposed to
> > be in-line with other JFR specific changes which are guarded with
> > compile-time conditional blocks.
> >
> >>
> >> If this is not true, and the initialize_class only runs if JFR is
> >> enabled, how does that work?
> >
> > This thing you ask (runtime check for whether JFR is enabled) is
> > impossible at that place, AFAIK. The affected code is in 'create_vm'
> > block so JVM is not really alive. Checking the JFR enabled status
> > requires parsing JFR configs which happens to be done in Java and that
> > requires java.lang.Class to be already linked and initialized - making
> > it impossible to check the JFR enablement status before initializing
> > java.lang.Class.
> How is that so? I believe command line arguments will have been
> processed at this stage. If so then you can easily detect whether or not
> JFR has been enabled on the command line. The simplest thing is to check
> global boolean FlightRecorder. This global is set from the command line
> using -X:+FlightRecorder and cleared using -X:-FlightRecorder. If not
> specified it defaults to false.
>
> So, in the case where JFR is conditionally compiled in you can call
> initialize_class() early if FlightRecorder is true and call it at the
> normal point of FlightRecorder is false.
>
> In the case where JFR is conditionally compiled out then the call should
> happen late as happened before this patch.
>
> Is there any reason why that won't work?
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>
> --
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

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

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

From andrey at azul.com  Wed Jun 10 16:20:49 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 10 Jun 2020 19:20:49 +0300
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
Message-ID: <b830e4bf-aecc-b8ad-fae7-f368516a21ff@azul.com>

Just in case, starting a recording in pre-main works flawlessly with the
current state of the code (in fact AFAICT recording which is started via
command line is in fact started earlier than agent's premain is executed)

And yes, it's typical use-case that that JFR is not activated on the
command line but some time later the recording is requested with
jcmd/JMC/JMX. In this it's enabled via management

Andrey

On 10.06.2020 19:05, Mario Torre wrote:
> Doesn?t that create an issue when JFR is not started but then enabled at
> runtime via the agent?
>
> So far the only use case for this was attaching via JMX but an agent could
> still request JFR, I?m not sure if creating a recording in pre-main is a
> legal use case or not though.
>
> Btw, this patch has been backported in 11 and 13 without this level of
> discussion, I guess we should revisit those patches too at this point.
>
> Cheers,
> Mario
>
> On Wed 10. Jun 2020 at 17:48, Andrew Dinn <adinn at redhat.com> wrote:
>
>> On 10/06/2020 13:31, Jaroslav Bachor?k wrote:
>>>> 3505 #if INCLUDE_JFR
>>>> 3506     // The VM creates & returns objects of this class. Make sure
>> it's initialized.
>>>> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
>>>> 3508 #endif
>>>>
>>>> ISTM that this code is run unconditionally if INCLUDE_JFR is set at
>> compile
>>>> time. Am I misunderstanding something?
>>> Ok. I misunderstood the original request. I thought it was supposed to
>>> be in-line with other JFR specific changes which are guarded with
>>> compile-time conditional blocks.
>>>
>>>> If this is not true, and the initialize_class only runs if JFR is
>>>> enabled, how does that work?
>>> This thing you ask (runtime check for whether JFR is enabled) is
>>> impossible at that place, AFAIK. The affected code is in 'create_vm'
>>> block so JVM is not really alive. Checking the JFR enabled status
>>> requires parsing JFR configs which happens to be done in Java and that
>>> requires java.lang.Class to be already linked and initialized - making
>>> it impossible to check the JFR enablement status before initializing
>>> java.lang.Class.
>> How is that so? I believe command line arguments will have been
>> processed at this stage. If so then you can easily detect whether or not
>> JFR has been enabled on the command line. The simplest thing is to check
>> global boolean FlightRecorder. This global is set from the command line
>> using -X:+FlightRecorder and cleared using -X:-FlightRecorder. If not
>> specified it defaults to false.
>>
>> So, in the case where JFR is conditionally compiled in you can call
>> initialize_class() early if FlightRecorder is true and call it at the
>> normal point of FlightRecorder is false.
>>
>> In the case where JFR is conditionally compiled out then the call should
>> happen late as happened before this patch.
>>
>> Is there any reason why that won't work?
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>>
>> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/


From adinn at redhat.com  Wed Jun 10 16:56:02 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 10 Jun 2020 17:56:02 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
Message-ID: <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>

On 10/06/2020 17:05, Mario Torre wrote:
> Doesn?t that create an issue when JFR is not started but then enabled at
> runtime via the agent?

I don't know? Does it? You tell me.

No one has yet explained why it is necessary to promote initialization
of java_lang_Class before initialization of other classes when JFR is
included in the build. Needless to say Andrew Haley is very wary of
changing class init order in jdk8u because in the past doing so has
caused subtle, nasty bugs.

So, please explain to me: is there is a good reason why that class init
re-ordering has to happen /whether or not/ FlightRecorder is enabled?
Does initializing java_lang_Class before other classes have some side
effect that makes JFR work correctly even when it is enabled later on?

If so then I think that must mean that it changes the way that the init
of the classes that were normally processed before java_lang_Class
proceeds. In which case that means we really need to know what that side
effect is in order to be sure it won't create any unnecessary risk.

Is this perhaps to do with JFR redefining the bytecode for java_lang_Class?

> Btw, this patch has been backported in 11 and 13 without this level of
> discussion, I guess we should revisit those patches too at this point.
Well yes, probably. Are you sure the same re-ordering was done as part
of the 11 and 13 backports? Startup order does vary from one release to
the next.

regards,


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


From gnu.andrew at redhat.com  Wed Jun 10 17:17:02 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Jun 2020 18:17:02 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
 <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>
Message-ID: <c17f9426-4429-d490-6f0f-bdda27685e92@redhat.com>



On 10/06/2020 17:56, Andrew Dinn wrote:

snip...

> 
>> Btw, this patch has been backported in 11 and 13 without this level of
>> discussion, I guess we should revisit those patches too at this point.
> Well yes, probably. Are you sure the same re-ordering was done as part
> of the 11 and 13 backports? Startup order does vary from one release to
> the next.
> 

11u & 13u are modular JDKs, so I would expect the class loading to be
substantially different to 8u, to begin with.
-- 
Andrew :)

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

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


From neugens.limasoftware at gmail.com  Wed Jun 10 17:50:18 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 10 Jun 2020 19:50:18 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <b830e4bf-aecc-b8ad-fae7-f368516a21ff@azul.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
 <b830e4bf-aecc-b8ad-fae7-f368516a21ff@azul.com>
Message-ID: <CAGUMyaQmicKY8_Drd6iV00xBrsUxv+zAN8j8UmfQ9x-PjyrpEQ@mail.gmail.com>

Il giorno mer 10 giu 2020 alle ore 18:21 Andrey Petushkov
<andrey at azul.com> ha scritto:
>
> Just in case, starting a recording in pre-main works flawlessly with the
> current state of the code (in fact AFAICT recording which is started via
> command line is in fact started earlier than agent's premain is executed)

You mean with Jaroslav's patch?

Cheers,
Mario

> And yes, it's typical use-case that that JFR is not activated on the
> command line but some time later the recording is requested with
> jcmd/JMC/JMX. In this it's enabled via management
>
> Andrey
>
> On 10.06.2020 19:05, Mario Torre wrote:
> > Doesn?t that create an issue when JFR is not started but then enabled at
> > runtime via the agent?
> >
> > So far the only use case for this was attaching via JMX but an agent could
> > still request JFR, I?m not sure if creating a recording in pre-main is a
> > legal use case or not though.
> >
> > Btw, this patch has been backported in 11 and 13 without this level of
> > discussion, I guess we should revisit those patches too at this point.
> >
> > Cheers,
> > Mario
> >
> > On Wed 10. Jun 2020 at 17:48, Andrew Dinn <adinn at redhat.com> wrote:
> >
> >> On 10/06/2020 13:31, Jaroslav Bachor?k wrote:
> >>>> 3505 #if INCLUDE_JFR
> >>>> 3506     // The VM creates & returns objects of this class. Make sure
> >> it's initialized.
> >>>> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
> >>>> 3508 #endif
> >>>>
> >>>> ISTM that this code is run unconditionally if INCLUDE_JFR is set at
> >> compile
> >>>> time. Am I misunderstanding something?
> >>> Ok. I misunderstood the original request. I thought it was supposed to
> >>> be in-line with other JFR specific changes which are guarded with
> >>> compile-time conditional blocks.
> >>>
> >>>> If this is not true, and the initialize_class only runs if JFR is
> >>>> enabled, how does that work?
> >>> This thing you ask (runtime check for whether JFR is enabled) is
> >>> impossible at that place, AFAIK. The affected code is in 'create_vm'
> >>> block so JVM is not really alive. Checking the JFR enabled status
> >>> requires parsing JFR configs which happens to be done in Java and that
> >>> requires java.lang.Class to be already linked and initialized - making
> >>> it impossible to check the JFR enablement status before initializing
> >>> java.lang.Class.
> >> How is that so? I believe command line arguments will have been
> >> processed at this stage. If so then you can easily detect whether or not
> >> JFR has been enabled on the command line. The simplest thing is to check
> >> global boolean FlightRecorder. This global is set from the command line
> >> using -X:+FlightRecorder and cleared using -X:-FlightRecorder. If not
> >> specified it defaults to false.
> >>
> >> So, in the case where JFR is conditionally compiled in you can call
> >> initialize_class() early if FlightRecorder is true and call it at the
> >> normal point of FlightRecorder is false.
> >>
> >> In the case where JFR is conditionally compiled out then the call should
> >> happen late as happened before this patch.
> >>
> >> Is there any reason why that won't work?
> >>
> >> regards,
> >>
> >>
> >> Andrew Dinn
> >> -----------
> >> Senior Principal Software Engineer
> >> Red Hat UK Ltd
> >> Registered in England and Wales under Company Registration No. 03798903
> >> Directors: Michael Cunningham, Michael ("Mike") O'Neill
> >>
> >> --
> > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> >
> > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > Proud GNU Classpath developer: http://www.classpath.org/
> > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> >
> > Please, support open standards:
> > http://endsoftpatents.org/
>


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

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

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

From neugens.limasoftware at gmail.com  Wed Jun 10 17:52:36 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 10 Jun 2020 19:52:36 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
 <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>
Message-ID: <CAGUMyaTEwuDosTei+cCL-fTmA6E0oh5CGA3VBaPf0JnbWge+jg@mail.gmail.com>

Andrew, Jaroslav,

One thing I just realised is this change:

3494   // Always call even when there are not JVMTI environments yet,
since environments
3495   // may be attached late and JVMTI must track phases of VM execution
3496   JvmtiExport::enter_start_phase();
3497
3498   // Notify JVMTI agents that VM has started (JNI is up) - nop if
no agents.
3499   JvmtiExport::post_vm_start();

I think we want to keep this code earlier when JFR is not compiled in,
it should be ifdefed too, right now we move it unconditionally if I
read this right.

Cheers,
Mario

Il giorno mer 10 giu 2020 alle ore 18:56 Andrew Dinn
<adinn at redhat.com> ha scritto:
>
> On 10/06/2020 17:05, Mario Torre wrote:
> > Doesn?t that create an issue when JFR is not started but then enabled at
> > runtime via the agent?
>
> I don't know? Does it? You tell me.
>
> No one has yet explained why it is necessary to promote initialization
> of java_lang_Class before initialization of other classes when JFR is
> included in the build. Needless to say Andrew Haley is very wary of
> changing class init order in jdk8u because in the past doing so has
> caused subtle, nasty bugs.
>
> So, please explain to me: is there is a good reason why that class init
> re-ordering has to happen /whether or not/ FlightRecorder is enabled?
> Does initializing java_lang_Class before other classes have some side
> effect that makes JFR work correctly even when it is enabled later on?
>
> If so then I think that must mean that it changes the way that the init
> of the classes that were normally processed before java_lang_Class
> proceeds. In which case that means we really need to know what that side
> effect is in order to be sure it won't create any unnecessary risk.
>
> Is this perhaps to do with JFR redefining the bytecode for java_lang_Class?
>
> > Btw, this patch has been backported in 11 and 13 without this level of
> > discussion, I guess we should revisit those patches too at this point.
> Well yes, probably. Are you sure the same re-ordering was done as part
> of the 11 and 13 backports? Startup order does vary from one release to
> the next.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>


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

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

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

From neugens.limasoftware at gmail.com  Wed Jun 10 18:04:34 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 10 Jun 2020 20:04:34 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAGUMyaTEwuDosTei+cCL-fTmA6E0oh5CGA3VBaPf0JnbWge+jg@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
 <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>
 <CAGUMyaTEwuDosTei+cCL-fTmA6E0oh5CGA3VBaPf0JnbWge+jg@mail.gmail.com>
Message-ID: <CAGUMyaSN4K1yw4hiVaqGVoyKXnQ8BLVmzaKnB_44zCtgn0a1DQ@mail.gmail.com>

Jaroslav,

Isn't the requirement here to prevent the segfault only to call

Jfr::on_create_vm_2()

After the java_lang_Class has been initialized?

In that case we could avoid moving the initialisation around and only
move the JvmtiExport block, I'm not sure I understand the startup
sequence in full, but I think this is a lot safer than rearranging the
init for java_lang_Class.

Cheers,
Mario

Il giorno mer 10 giu 2020 alle ore 19:52 Mario Torre
<neugens.limasoftware at gmail.com> ha scritto:
>
> Andrew, Jaroslav,
>
> One thing I just realised is this change:
>
> 3494   // Always call even when there are not JVMTI environments yet,
> since environments
> 3495   // may be attached late and JVMTI must track phases of VM execution
> 3496   JvmtiExport::enter_start_phase();
> 3497
> 3498   // Notify JVMTI agents that VM has started (JNI is up) - nop if
> no agents.
> 3499   JvmtiExport::post_vm_start();
>
> I think we want to keep this code earlier when JFR is not compiled in,
> it should be ifdefed too, right now we move it unconditionally if I
> read this right.
>
> Cheers,
> Mario
>
> Il giorno mer 10 giu 2020 alle ore 18:56 Andrew Dinn
> <adinn at redhat.com> ha scritto:
> >
> > On 10/06/2020 17:05, Mario Torre wrote:
> > > Doesn?t that create an issue when JFR is not started but then enabled at
> > > runtime via the agent?
> >
> > I don't know? Does it? You tell me.
> >
> > No one has yet explained why it is necessary to promote initialization
> > of java_lang_Class before initialization of other classes when JFR is
> > included in the build. Needless to say Andrew Haley is very wary of
> > changing class init order in jdk8u because in the past doing so has
> > caused subtle, nasty bugs.
> >
> > So, please explain to me: is there is a good reason why that class init
> > re-ordering has to happen /whether or not/ FlightRecorder is enabled?
> > Does initializing java_lang_Class before other classes have some side
> > effect that makes JFR work correctly even when it is enabled later on?
> >
> > If so then I think that must mean that it changes the way that the init
> > of the classes that were normally processed before java_lang_Class
> > proceeds. In which case that means we really need to know what that side
> > effect is in order to be sure it won't create any unnecessary risk.
> >
> > Is this perhaps to do with JFR redefining the bytecode for java_lang_Class?
> >
> > > Btw, this patch has been backported in 11 and 13 without this level of
> > > discussion, I guess we should revisit those patches too at this point.
> > Well yes, probably. Are you sure the same re-ordering was done as part
> > of the 11 and 13 backports? Startup order does vary from one release to
> > the next.
> >
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> > Senior Principal Software Engineer
> > Red Hat UK Ltd
> > Registered in England and Wales under Company Registration No. 03798903
> > Directors: Michael Cunningham, Michael ("Mike") O'Neill
> >
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/



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

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

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

From jaroslav.bachorik at datadoghq.com  Wed Jun 10 18:17:16 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 10 Jun 2020 20:17:16 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAGUMyaSN4K1yw4hiVaqGVoyKXnQ8BLVmzaKnB_44zCtgn0a1DQ@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
 <7703998f-36b5-392a-2e80-c81cfeffe1fa@redhat.com>
 <CAGUMyaTEwuDosTei+cCL-fTmA6E0oh5CGA3VBaPf0JnbWge+jg@mail.gmail.com>
 <CAGUMyaSN4K1yw4hiVaqGVoyKXnQ8BLVmzaKnB_44zCtgn0a1DQ@mail.gmail.com>
Message-ID: <CAPb8aJ6bxKV72FHCnxgriaKYWDNkPrEykVWmQ1tgn=PVqzSErQ@mail.gmail.com>

Hi Mario,

On Wed, Jun 10, 2020 at 8:05 PM Mario Torre
<neugens.limasoftware at gmail.com> wrote:
>
> Jaroslav,
>
> Isn't the requirement here to prevent the segfault only to call
>
> Jfr::on_create_vm_2()
>
> After the java_lang_Class has been initialized?
>
> In that case we could avoid moving the initialisation around and only
> move the JvmtiExport block, I'm not sure I understand the startup
> sequence in full, but I think this is a lot safer than rearranging the
> init for java_lang_Class.

Yes, it looks pretty much like that. I am re-running all tests with
the java_lang_Class initialization being at the original place and so
far the results seem good.

As for why it was shuffled - it was mostly to mimic what happens in
JDK11 (https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/thread.cpp#l3508)

I am also almost sure I was getting errors related to java_lang_Class
not being linked from JFR tests at the time I was working on the
backport. But I don't see those errors now even when I put the
java_lang_Class initialization back.

>
> Cheers,
> Mario
>
> Il giorno mer 10 giu 2020 alle ore 19:52 Mario Torre
> <neugens.limasoftware at gmail.com> ha scritto:
> >
> > Andrew, Jaroslav,
> >
> > One thing I just realised is this change:
> >
> > 3494   // Always call even when there are not JVMTI environments yet,
> > since environments
> > 3495   // may be attached late and JVMTI must track phases of VM execution
> > 3496   JvmtiExport::enter_start_phase();
> > 3497
> > 3498   // Notify JVMTI agents that VM has started (JNI is up) - nop if
> > no agents.
> > 3499   JvmtiExport::post_vm_start();
> >
> > I think we want to keep this code earlier when JFR is not compiled in,
> > it should be ifdefed too, right now we move it unconditionally if I
> > read this right.

Ok, let me take a look at it.

-JB-

> >
> > Cheers,
> > Mario
> >
> > Il giorno mer 10 giu 2020 alle ore 18:56 Andrew Dinn
> > <adinn at redhat.com> ha scritto:
> > >
> > > On 10/06/2020 17:05, Mario Torre wrote:
> > > > Doesn?t that create an issue when JFR is not started but then enabled at
> > > > runtime via the agent?
> > >
> > > I don't know? Does it? You tell me.
> > >
> > > No one has yet explained why it is necessary to promote initialization
> > > of java_lang_Class before initialization of other classes when JFR is
> > > included in the build. Needless to say Andrew Haley is very wary of
> > > changing class init order in jdk8u because in the past doing so has
> > > caused subtle, nasty bugs.
> > >
> > > So, please explain to me: is there is a good reason why that class init
> > > re-ordering has to happen /whether or not/ FlightRecorder is enabled?
> > > Does initializing java_lang_Class before other classes have some side
> > > effect that makes JFR work correctly even when it is enabled later on?
> > >
> > > If so then I think that must mean that it changes the way that the init
> > > of the classes that were normally processed before java_lang_Class
> > > proceeds. In which case that means we really need to know what that side
> > > effect is in order to be sure it won't create any unnecessary risk.
> > >
> > > Is this perhaps to do with JFR redefining the bytecode for java_lang_Class?
> > >
> > > > Btw, this patch has been backported in 11 and 13 without this level of
> > > > discussion, I guess we should revisit those patches too at this point.
> > > Well yes, probably. Are you sure the same re-ordering was done as part
> > > of the 11 and 13 backports? Startup order does vary from one release to
> > > the next.
> > >
> > > regards,
> > >
> > >
> > > Andrew Dinn
> > > -----------
> > > Senior Principal Software Engineer
> > > Red Hat UK Ltd
> > > Registered in England and Wales under Company Registration No. 03798903
> > > Directors: Michael Cunningham, Michael ("Mike") O'Neill
> > >
> >
> >
> > --
> > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> >
> > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > Proud GNU Classpath developer: http://www.classpath.org/
> > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> >
> > Please, support open standards:
> > http://endsoftpatents.org/
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/

From gnu.andrew at redhat.com  Wed Jun 10 19:54:51 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Jun 2020 20:54:51 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
Message-ID: <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>

On 08/06/2020 17:41, Jaroslav Bachor?k wrote:
> Hi Andrew,
> 


snip...

>>
>> 1. How prolific is such usage of JFR?
> 
> I guess not much since till recently each attempt would have resulted
> in segfault.
> But in general I would say that any APM/Profiler based on JFR would be
> happy not to run a special delay code to prevent segfaults.
> 

Ok, I guess that applies to JFR in later OpenJDK versions (i.e. those in
releases) as well as 8u.

>>
>> 2. What are the risks of including this patch?
> 
> In general, changing the initialization order for java.lang.Class
> could cause problems for a code that would operate with assumption of
> the java.lang.Class not being initialized very early on in the JVM
> startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
> tests are still passing after adding this change
> 

It's still pretty worrying to be altering this in a very stable release
(though, adding JFR itself is worrying as well)

I'll let Andrew Haley make the final call on whether he is happy to
allow this or not.

> 
>>
>> 3. Do we now have a final version of this patch, with test?
> 
> Yes. The webrev.04 version is the final one.
> 
> 
>>
>> 4. Was a bug filed for the additional test?
> 
> https://bugs.openjdk.java.net/browse/JDK-8246703
> 

Thanks for this follow-up.

Cheers,
-- 
Andrew :)

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

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


From aph at redhat.com  Thu Jun 11 09:49:15 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Jun 2020 10:49:15 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
Message-ID: <395fc0f9-ad71-c0c4-9805-7d3bfd87ad70@redhat.com>

On 10/06/2020 17:05, Mario Torre wrote:
> 
> Btw, this patch has been backported in 11 and 13 without this level of discussion, I guess we should revisit those patches too at this point.

It's because upstream is different from 8u; a lot of reorganization
has happened. It's not appropriate at this stage to make dramatic
changes to 8u startup code, an least not unless it can be turned off.

-- 
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 andrey at azul.com  Thu Jun 11 09:50:16 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Thu, 11 Jun 2020 12:50:16 +0300
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAGUMyaQmicKY8_Drd6iV00xBrsUxv+zAN8j8UmfQ9x-PjyrpEQ@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <437790a1-03b7-70c4-9d4a-6b1032d395c4@redhat.com>
 <CAPb8aJ44AEL558Kpz+KYbdeMyBwrNj7Fi2+=tW+o0=0Nc3vmBg@mail.gmail.com>
 <3be6b777-669c-de64-233c-e49ce02f42eb@redhat.com>
 <CAPb8aJ4E1uzZ5MyUPKZvO6ATn61m8CNoQ1X6b84qtUSVGjuAMg@mail.gmail.com>
 <b6012ea6-3792-7a05-d7e8-4430e43b7981@redhat.com>
 <CAGUMyaT1hLWWcM_yDYn_r4ryiP1=Lcvn2PN8igWD7H3y+Up5rw@mail.gmail.com>
 <b830e4bf-aecc-b8ad-fae7-f368516a21ff@azul.com>
 <CAGUMyaQmicKY8_Drd6iV00xBrsUxv+zAN8j8UmfQ9x-PjyrpEQ@mail.gmail.com>
Message-ID: <183c9735-a636-a01b-8787-c1599f1f77b9@azul.com>

No, it was about before the patch. Just wanted to point that regardless
whether this legal
or not, it works, so it sets expectations among the users

Andrey

On 10.06.2020 20:50, Mario Torre wrote:
> Il giorno mer 10 giu 2020 alle ore 18:21 Andrey Petushkov
> <andrey at azul.com> ha scritto:
>> Just in case, starting a recording in pre-main works flawlessly with the
>> current state of the code (in fact AFAICT recording which is started via
>> command line is in fact started earlier than agent's premain is executed)
> You mean with Jaroslav's patch?
>
> Cheers,
> Mario
>
>> And yes, it's typical use-case that that JFR is not activated on the
>> command line but some time later the recording is requested with
>> jcmd/JMC/JMX. In this it's enabled via management
>>
>> Andrey
>>
>> On 10.06.2020 19:05, Mario Torre wrote:
>>> Doesn?t that create an issue when JFR is not started but then enabled at
>>> runtime via the agent?
>>>
>>> So far the only use case for this was attaching via JMX but an agent could
>>> still request JFR, I?m not sure if creating a recording in pre-main is a
>>> legal use case or not though.
>>>
>>> Btw, this patch has been backported in 11 and 13 without this level of
>>> discussion, I guess we should revisit those patches too at this point.
>>>
>>> Cheers,
>>> Mario
>>>
>>> On Wed 10. Jun 2020 at 17:48, Andrew Dinn <adinn at redhat.com> wrote:
>>>
>>>> On 10/06/2020 13:31, Jaroslav Bachor?k wrote:
>>>>>> 3505 #if INCLUDE_JFR
>>>>>> 3506     // The VM creates & returns objects of this class. Make sure
>>>> it's initialized.
>>>>>> 3507     initialize_class(vmSymbols::java_lang_Class(), CHECK_0);
>>>>>> 3508 #endif
>>>>>>
>>>>>> ISTM that this code is run unconditionally if INCLUDE_JFR is set at
>>>> compile
>>>>>> time. Am I misunderstanding something?
>>>>> Ok. I misunderstood the original request. I thought it was supposed to
>>>>> be in-line with other JFR specific changes which are guarded with
>>>>> compile-time conditional blocks.
>>>>>
>>>>>> If this is not true, and the initialize_class only runs if JFR is
>>>>>> enabled, how does that work?
>>>>> This thing you ask (runtime check for whether JFR is enabled) is
>>>>> impossible at that place, AFAIK. The affected code is in 'create_vm'
>>>>> block so JVM is not really alive. Checking the JFR enabled status
>>>>> requires parsing JFR configs which happens to be done in Java and that
>>>>> requires java.lang.Class to be already linked and initialized - making
>>>>> it impossible to check the JFR enablement status before initializing
>>>>> java.lang.Class.
>>>> How is that so? I believe command line arguments will have been
>>>> processed at this stage. If so then you can easily detect whether or not
>>>> JFR has been enabled on the command line. The simplest thing is to check
>>>> global boolean FlightRecorder. This global is set from the command line
>>>> using -X:+FlightRecorder and cleared using -X:-FlightRecorder. If not
>>>> specified it defaults to false.
>>>>
>>>> So, in the case where JFR is conditionally compiled in you can call
>>>> initialize_class() early if FlightRecorder is true and call it at the
>>>> normal point of FlightRecorder is false.
>>>>
>>>> In the case where JFR is conditionally compiled out then the call should
>>>> happen late as happened before this patch.
>>>>
>>>> Is there any reason why that won't work?
>>>>
>>>> regards,
>>>>
>>>>
>>>> Andrew Dinn
>>>> -----------
>>>> Senior Principal Software Engineer
>>>> Red Hat UK Ltd
>>>> Registered in England and Wales under Company Registration No. 03798903
>>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>>>>
>>>> --
>>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
>>> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>>>
>>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
>>> Proud GNU Classpath developer: http://www.classpath.org/
>>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>>>
>>> Please, support open standards:
>>> http://endsoftpatents.org/
>


From jaroslav.bachorik at datadoghq.com  Thu Jun 11 10:50:42 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Thu, 11 Jun 2020 12:50:42 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ65SNgwk4go4jFFT2CV9+1mvfD-KmeKeeFH9VdXo5c4Cw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
Message-ID: <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>

snip ...

I have reverted the change in the class initialization order and put
the JvmtiExport change in a guarded block as requested.
All tests are passing.

I have also experimented with using Jfr::is_disabled() which basically
translates to check whether -XX:-FlightRecorder is set but that makes
the original patch for 8233197 to fail because correct handling of an
attempt to initialize JFR from JVMTI_VM_EVENT_START handling requires
reordering of the JvmtiExport calls in thread.cpp - and that does not
happen if JVM is started with -XX:-FlightRecorder.

Perhaps, it would be possible to modify jfrJvmtiAgent.cpp to check
whether JFR is disabled before attempting to initialize the JFR agent
but that might turn out to be not the only place requiring adjustments
and that would lead to rather large diversion between the original fix
and the backport.

The latest webrev:
http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.05

Cheers,

-JB-


On Wed, Jun 10, 2020 at 9:55 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 08/06/2020 17:41, Jaroslav Bachor?k wrote:
> > Hi Andrew,
> >
>
>
> snip...
>
> >>
> >> 1. How prolific is such usage of JFR?
> >
> > I guess not much since till recently each attempt would have resulted
> > in segfault.
> > But in general I would say that any APM/Profiler based on JFR would be
> > happy not to run a special delay code to prevent segfaults.
> >
>
> Ok, I guess that applies to JFR in later OpenJDK versions (i.e. those in
> releases) as well as 8u.
>
> >>
> >> 2. What are the risks of including this patch?
> >
> > In general, changing the initialization order for java.lang.Class
> > could cause problems for a code that would operate with assumption of
> > the java.lang.Class not being initialized very early on in the JVM
> > startup. This sounds pretty unlikely, though - eg tier1, tier2 and jfr
> > tests are still passing after adding this change
> >
>
> It's still pretty worrying to be altering this in a very stable release
> (though, adding JFR itself is worrying as well)
>
> I'll let Andrew Haley make the final call on whether he is happy to
> allow this or not.
>
> >
> >>
> >> 3. Do we now have a final version of this patch, with test?
> >
> > Yes. The webrev.04 version is the final one.
> >
> >
> >>
> >> 4. Was a bug filed for the additional test?
> >
> > https://bugs.openjdk.java.net/browse/JDK-8246703
> >
>
> Thanks for this follow-up.
>
> Cheers,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From adinn at redhat.com  Thu Jun 11 14:36:39 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 11 Jun 2020 15:36:39 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
Message-ID: <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>

Hi Jaroslav,
On 11/06/2020 11:50, Jaroslav Bachor?k wrote:
> I have reverted the change in the class initialization order and put
> the JvmtiExport change in a guarded block as requested.
> All tests are passing.
. . .
> The latest webrev:
> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.05
As discussed on the call we had with Mario and Andrew Haley a few
minutes ago we are all happy that this latest webrev minimizes the
changes to startup order and, in particular, avoids any change to the
order of class initialization.

Andrew Haley sked me to confirm that  happy for it to be backported. So,
this note counts as both a reviewer and maintainer approval.

Andrew Hughes, could you please include this in the release as soon as
possible.

regards,


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


From jaroslav.bachorik at datadoghq.com  Thu Jun 11 15:44:12 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Thu, 11 Jun 2020 17:44:12 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAJwKKmb0qjB6ThTveAxWTS4QYRe+DJgBZCKHOKtDneu0AkC7+Q@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
 <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
Message-ID: <CAPb8aJ449n-S6s_4z3i5o00ngR6jci8n=aRAubSK+1GbRTCx8g@mail.gmail.com>

Hi,

On Thu, Jun 11, 2020 at 4:36 PM Andrew Dinn <adinn at redhat.com> wrote:
>
> Hi Jaroslav,
> On 11/06/2020 11:50, Jaroslav Bachor?k wrote:
> > I have reverted the change in the class initialization order and put
> > the JvmtiExport change in a guarded block as requested.
> > All tests are passing.
> . . .
> > The latest webrev:
> > http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.05
> As discussed on the call we had with Mario and Andrew Haley a few
> minutes ago we are all happy that this latest webrev minimizes the
> changes to startup order and, in particular, avoids any change to the
> order of class initialization.
>
> Andrew Haley sked me to confirm that  happy for it to be backported. So,
> this note counts as both a reviewer and maintainer approval.
>
> Andrew Hughes, could you please include this in the release as soon as
> possible.

Thanks everyone involved in this review! I have pushed the changeset
to jdk8u-dev/hotspot - is there anything else I need to do? Adding
'jdk8u-critical-request' label perhaps?

Cheers,

-JB-

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

From aph at redhat.com  Thu Jun 11 16:15:07 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Jun 2020 17:15:07 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ449n-S6s_4z3i5o00ngR6jci8n=aRAubSK+1GbRTCx8g@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
 <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
 <CAPb8aJ449n-S6s_4z3i5o00ngR6jci8n=aRAubSK+1GbRTCx8g@mail.gmail.com>
Message-ID: <2b61b3db-50d1-4249-1a25-27418df4a2b1@redhat.com>

On 11/06/2020 16:44, Jaroslav Bachor?k wrote:
> Thanks everyone involved in this review! I have pushed the changeset
> to jdk8u-dev/hotspot - is there anything else I need to do? Adding
> 'jdk8u-critical-request' label perhaps?

Please do that.

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


From gnu.andrew at redhat.com  Thu Jun 11 16:38:19 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 11 Jun 2020 17:38:19 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
 <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
Message-ID: <99bba940-34c0-0caa-73d1-ce0db7cee460@redhat.com>

On 11/06/2020 15:36, Andrew Dinn wrote:
> Hi Jaroslav,
> On 11/06/2020 11:50, Jaroslav Bachor?k wrote:
>> I have reverted the change in the class initialization order and put
>> the JvmtiExport change in a guarded block as requested.
>> All tests are passing.
> . . .
>> The latest webrev:
>> http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.05
> As discussed on the call we had with Mario and Andrew Haley a few
> minutes ago we are all happy that this latest webrev minimizes the
> changes to startup order and, in particular, avoids any change to the
> order of class initialization.
> 
> Andrew Haley sked me to confirm that  happy for it to be backported. So,
> this note counts as both a reviewer and maintainer approval.
> 
> Andrew Hughes, could you please include this in the release as soon as
> possible.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
> 

If this is for 8u262, it needs to be flagged with
jdk8u-critical-request. It looks like it was flagged with
jdk8u-fix-request and then pushed to 8u272 with jdk8u-fix-yes instead.

Jaroslav, can you please flag the bug with the appropriate
jdk8u-critical-fix label and I'll then formally approve it with
jdk8u-critical-yes. It can then be pushed to jdk8/jdk8 [0].

Note that the changeset should mention both 8233197 & the test bug
8246703, so that both will be marked as fixed in 8u262 i.e.

8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start()
start-up order for correct option parsing
8246703: [TESTBUG] Add test for JDK-8233197
Reviewed-by: aph, adinn, neugens

The current version in 8u-dev only seems to list the one bug and the
wrong reviewers.

Note that critical fixes for 8u262 don't need to be pushed to 8u272 as
well, as each build promotion for 8u262 is merged back into 8u-dev [1].

[0] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/
[1] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description

Thanks,
-- 
Andrew :)

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

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


From jaroslav.bachorik at datadoghq.com  Thu Jun 11 16:59:58 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Thu, 11 Jun 2020 18:59:58 +0200
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <99bba940-34c0-0caa-73d1-ce0db7cee460@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com>
 <CAPb8aJ5QKH6HCRdB=USekzPrc=zgRCofNAyi_8BCOcE3ADR=DA@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
 <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
 <99bba940-34c0-0caa-73d1-ce0db7cee460@redhat.com>
Message-ID: <CAPb8aJ4=RVn9VFntN2ZTizaaw5ZSm_sRuemt4eAEjD06xRU9Bg@mail.gmail.com>

snip ...

>
> Note that the changeset should mention both 8233197 & the test bug
> 8246703, so that both will be marked as fixed in 8u262 i.e.
>
> 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start()
> start-up order for correct option parsing
> 8246703: [TESTBUG] Add test for JDK-8233197
> Reviewed-by: aph, adinn, neugens
>
> The current version in 8u-dev only seems to list the one bug and the
> wrong reviewers.

Hmh, I was operating under an assumption that the backports should
have the original reviewers and authors (which I admit I did wrong in
this changeset - it slipped with me as an author and I noticed it only
after pushing the changeset :( ).

I will fix the metadata for 8u262 push then.

Cheers,

-JB-

>
> Note that critical fixes for 8u262 don't need to be pushed to 8u272 as
> well, as each build promotion for 8u262 is merged back into 8u-dev [1].
>
> [0] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/
> [1] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From gnu.andrew at redhat.com  Thu Jun 11 17:41:20 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 11 Jun 2020 18:41:20 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ4=RVn9VFntN2ZTizaaw5ZSm_sRuemt4eAEjD06xRU9Bg@mail.gmail.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
 <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
 <99bba940-34c0-0caa-73d1-ce0db7cee460@redhat.com>
 <CAPb8aJ4=RVn9VFntN2ZTizaaw5ZSm_sRuemt4eAEjD06xRU9Bg@mail.gmail.com>
Message-ID: <2af53b05-863e-9548-b538-a3b174f70250@redhat.com>

On 11/06/2020 17:59, Jaroslav Bachor?k wrote:
> snip ...
> 
>>
>> Note that the changeset should mention both 8233197 & the test bug
>> 8246703, so that both will be marked as fixed in 8u262 i.e.
>>
>> 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start()
>> start-up order for correct option parsing
>> 8246703: [TESTBUG] Add test for JDK-8233197
>> Reviewed-by: aph, adinn, neugens
>>
>> The current version in 8u-dev only seems to list the one bug and the
>> wrong reviewers.
> 
> Hmh, I was operating under an assumption that the backports should
> have the original reviewers and authors (which I admit I did wrong in
> this changeset - it slipped with me as an author and I noticed it only
> after pushing the changeset :( ).
> 

No problem. There is some ambiguity here that I've tried to explain on
the OpenJDK wiki (step #13, [0]).

Your assumption is correct where the backport is either clean (and so
you shouldn't even need to touch it anyway) or only requires minimal
context changes. In this case, the same patch is just being committed to
a different repository, so the only amendment necessary is to append any
additional reviewers (if any) from the 8u backport process.

For a patch like this that has had considerable development work and
review discussion, it seems inappropriate to not credit the people
involved in that process (both the committer and those who reviewed it).
It also seems incorrect to retain a review attribution to someone who
has probably not seen the backported version.

In this case, I think treating it as a new patch with its own committer
and reviewers is appropriate. The original credits are still there in
the jdk/jdk repositories and will live on longer than those in the
update projects. We should be crediting those who undertake backporting
work.

This becomes of most importance when it comes to proposing candidates
for committer or reviewer status. Backport patches that retain the
original metadata will not show up for those candidates.

> I will fix the metadata for 8u262 push then.

Thanks.

[0] https://wiki.openjdk.java.net/display/jdk8u/Main
-- 
Andrew :)

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

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


From neugens.limasoftware at gmail.com  Thu Jun 11 18:47:05 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 11 Jun 2020 20:47:05 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAJwKKmZFRucTFg6yHLtLK6846Nr3EiZL8QDW13TSQ3MZCuo_qw@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
 <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
 <CAJwKKmZFRucTFg6yHLtLK6846Nr3EiZL8QDW13TSQ3MZCuo_qw@mail.gmail.com>
Message-ID: <CAGUMyaSQZpD=eHxsFM4h18Mivqv59aWysJ-w+P2+Tm9pxHWYqQ@mail.gmail.com>

Hi Andrey,

I think we need a similar treatment as for 8233197. Can you please flag the
bug as jdk8u-critical-fix?

Cheers,
Mario

On Mon 8. Jun 2020 at 20:58, Mario Torre <neugens at redhat.com> wrote:

> On Mon, Jun 8, 2020 at 1:27 PM Jaroslav Bachor?k
> <jaroslav.bachorik at datadoghq.com> wrote:
> >
> > On Wed, Jun 3, 2020 at 1:05 PM Mario Torre <neugens at redhat.com> wrote:
> > >
> > > On Wed, Jun 3, 2020 at 12:15 PM Andrey Petushkov <andrey at azul.com>
> wrote:
> > > >
> > > > Hi Andrew,
> > > >
> > > > This 'L' -checking code is activated only when the method in
> question is
> > > > given the array (i.e. the FQN of the class is something "[L...").
> > > > However the caller never applies the method to array classes, only
> > > > instance classes.
> > > > (and I've actually checked that "L.Main" class has appeared in the
> JMC's
> > > > "Top packages" window)
> > >
> > > Yeah, however it's not clear to me if this may change in the future
> > > since the function has a side effect that it's not entirely specified,
> > > that said however I think, if any, this is a bug in mainline and an
> > > eventual fix should come in via an additional backport and not hold
> > > this fix in 8u.
> >
> > Totally agreed - this should be done asynchronously and not held back
> > by an issue in the mainline.
>
> Absolutely, from my side this patch is reviewed and approved, but we
> need a maintainer to approve the merge in JDK8u.
>
> 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
>
> --
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

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

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

From jaroslav.bachorik at datadoghq.com  Fri Jun 12 08:37:09 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 12 Jun 2020 10:37:09 +0200
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAGUMyaSQZpD=eHxsFM4h18Mivqv59aWysJ-w+P2+Tm9pxHWYqQ@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
 <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
 <CAJwKKmZFRucTFg6yHLtLK6846Nr3EiZL8QDW13TSQ3MZCuo_qw@mail.gmail.com>
 <CAGUMyaSQZpD=eHxsFM4h18Mivqv59aWysJ-w+P2+Tm9pxHWYqQ@mail.gmail.com>
Message-ID: <CAPb8aJ5N=Nmu37GWyivWYTtj=LkOG8DnpkACoXU2N40tpgpaqQ@mail.gmail.com>

Hi,

I have labelled the JIRA issue.

Cheers,

-JB-

On Thu, Jun 11, 2020 at 8:50 PM Mario Torre
<neugens.limasoftware at gmail.com> wrote:
>
> Hi Andrey,
>
> I think we need a similar treatment as for 8233197. Can you please flag the bug as jdk8u-critical-fix?
>
> Cheers,
> Mario
>
> On Mon 8. Jun 2020 at 20:58, Mario Torre <neugens at redhat.com> wrote:
>>
>> On Mon, Jun 8, 2020 at 1:27 PM Jaroslav Bachor?k
>> <jaroslav.bachorik at datadoghq.com> wrote:
>> >
>> > On Wed, Jun 3, 2020 at 1:05 PM Mario Torre <neugens at redhat.com> wrote:
>> > >
>> > > On Wed, Jun 3, 2020 at 12:15 PM Andrey Petushkov <andrey at azul.com> wrote:
>> > > >
>> > > > Hi Andrew,
>> > > >
>> > > > This 'L' -checking code is activated only when the method in question is
>> > > > given the array (i.e. the FQN of the class is something "[L...").
>> > > > However the caller never applies the method to array classes, only
>> > > > instance classes.
>> > > > (and I've actually checked that "L.Main" class has appeared in the JMC's
>> > > > "Top packages" window)
>> > >
>> > > Yeah, however it's not clear to me if this may change in the future
>> > > since the function has a side effect that it's not entirely specified,
>> > > that said however I think, if any, this is a bug in mainline and an
>> > > eventual fix should come in via an additional backport and not hold
>> > > this fix in 8u.
>> >
>> > Totally agreed - this should be done asynchronously and not held back
>> > by an issue in the mainline.
>>
>> Absolutely, from my side this patch is reviewed and approved, but we
>> need a maintainer to approve the merge in JDK8u.
>>
>> 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
>>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/

From gnu.andrew at redhat.com  Fri Jun 12 14:38:06 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 12 Jun 2020 15:38:06 +0100
Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <2af53b05-863e-9548-b538-a3b174f70250@redhat.com>
References: <CAPb8aJ4tf0y1gGDYOXT+xBU6Q1Y9-=zwMPiHFFT8kWxu2B=guw@mail.gmail.com>
 <cb4884c7-2a64-899e-a51b-b1c1469aef9e@redhat.com>
 <CAPb8aJ5YNG=hz8CC0Aw8vyoEZKbk_TEtLR7abVhv9Zjd3DFCSw@mail.gmail.com>
 <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com>
 <CAPb8aJ69J7Vn5bj1Arnu9nAOQd=iVwEPc92EOsWMkMxf-X=NpQ@mail.gmail.com>
 <CAJwKKmYTTUa6K2vCBH_Ty0==HqrojHmpFMWcupO0-BSD4sHCYQ@mail.gmail.com>
 <2955bbf2-2a09-d334-d1d5-2de4a3aa9247@redhat.com>
 <CAPb8aJ78XEx-fsBsMURntZ5mdfKTcj4Tzu=+vrzonwEdUR4+yA@mail.gmail.com>
 <d4573846-991b-ac8e-fe2c-199cee5fe374@redhat.com>
 <CAPb8aJ6TvmhDf13uK0xtG=vCvpdxUsz0irQz6zWDnHGR9zi5aw@mail.gmail.com>
 <93eee651-9a4c-0f10-0f38-2d041ea87077@redhat.com>
 <CAPb8aJ5vxpT6WBzd5ThSgtrF2e_e-iW+z15ErhQSA+inotbxjA@mail.gmail.com>
 <7f8c2178-5746-1690-317a-07e308eac4e5@redhat.com>
 <99bba940-34c0-0caa-73d1-ce0db7cee460@redhat.com>
 <CAPb8aJ4=RVn9VFntN2ZTizaaw5ZSm_sRuemt4eAEjD06xRU9Bg@mail.gmail.com>
 <2af53b05-863e-9548-b538-a3b174f70250@redhat.com>
Message-ID: <772110d6-d55a-b304-2837-fd00ab911635@redhat.com>

On 11/06/2020 18:41, Andrew Hughes wrote:
> On 11/06/2020 17:59, Jaroslav Bachor?k wrote:
>> snip ...
>>
>>>
>>> Note that the changeset should mention both 8233197 & the test bug
>>> 8246703, so that both will be marked as fixed in 8u262 i.e.
>>>
>>> 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start()
>>> start-up order for correct option parsing
>>> 8246703: [TESTBUG] Add test for JDK-8233197
>>> Reviewed-by: aph, adinn, neugens
>>>
>>> The current version in 8u-dev only seems to list the one bug and the
>>> wrong reviewers.
>>
>> Hmh, I was operating under an assumption that the backports should
>> have the original reviewers and authors (which I admit I did wrong in
>> this changeset - it slipped with me as an author and I noticed it only
>> after pushing the changeset :( ).
>>
> 
> No problem. There is some ambiguity here that I've tried to explain on
> the OpenJDK wiki (step #13, [0]).
> 
> Your assumption is correct where the backport is either clean (and so
> you shouldn't even need to touch it anyway) or only requires minimal
> context changes. In this case, the same patch is just being committed to
> a different repository, so the only amendment necessary is to append any
> additional reviewers (if any) from the 8u backport process.
> 
> For a patch like this that has had considerable development work and
> review discussion, it seems inappropriate to not credit the people
> involved in that process (both the committer and those who reviewed it).
> It also seems incorrect to retain a review attribution to someone who
> has probably not seen the backported version.
> 
> In this case, I think treating it as a new patch with its own committer
> and reviewers is appropriate. The original credits are still there in
> the jdk/jdk repositories and will live on longer than those in the
> update projects. We should be crediting those who undertake backporting
> work.
> 
> This becomes of most importance when it comes to proposing candidates
> for committer or reviewer status. Backport patches that retain the
> original metadata will not show up for those candidates.
> 
>> I will fix the metadata for 8u262 push then.
> 
> Thanks.
> 
> [0] https://wiki.openjdk.java.net/display/jdk8u/Main
> 

I've now pushed it on your behalf.

It actually broke the build with JFR disabled, due to this stray brace:

https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/26d1803768c7#l11.31

I've fixed that in 8u, as well as restoring the original indentation:

https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/30fb8c8cceb9#l11.16

It'll get fixed in 8u-dev when I merged b07 early next week.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Fri Jun 12 14:55:25 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 12 Jun 2020 15:55:25 +0100
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <CAPb8aJ5N=Nmu37GWyivWYTtj=LkOG8DnpkACoXU2N40tpgpaqQ@mail.gmail.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
 <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
 <CAJwKKmZFRucTFg6yHLtLK6846Nr3EiZL8QDW13TSQ3MZCuo_qw@mail.gmail.com>
 <CAGUMyaSQZpD=eHxsFM4h18Mivqv59aWysJ-w+P2+Tm9pxHWYqQ@mail.gmail.com>
 <CAPb8aJ5N=Nmu37GWyivWYTtj=LkOG8DnpkACoXU2N40tpgpaqQ@mail.gmail.com>
Message-ID: <28e0cf6a-1c52-bd6f-6ca6-b12cb4b4c829@redhat.com>

On 12/06/2020 09:37, Jaroslav Bachor?k wrote:
> Hi,
> 
> I have labelled the JIRA issue.
> 
> Cheers,
> 
> -JB-
> 

I've approved this. However, in future, please add a comment when adding
the label in future, stating why it should be approved. This is
especially important when you're requesting a critical approval during
rampdown.

In this case, I think the patch is safe, as it adds a function which is
then only called from JFR code, which is new in 8u262 (and thus, by
definition, can't regress).

But, please try to get such changes in before rampdown in future. I
realise this was held up waiting for reviewers, so that's as much an
appeal to reviewers to be pro-active as it is those submitting patches
for review.

Thanks,
-- 
Andrew :)

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

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


From mbalao at redhat.com  Fri Jun 12 20:56:02 2020
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 12 Jun 2020 17:56:02 -0300
Subject: [8u] TLSv1.3 RFR: 8245473: OCSP stapling support
In-Reply-To: <9B6CCFE9-AD17-4D74-8E52-32C8EC2797E5@azul.com>
References: <A6932CAA-9ED3-489C-A9FB-C956BBF1D24E@azul.com>
 <d7928299-6914-4375-5961-ba9fcfc012f2@redhat.com>
 <A4A56321-60A3-4FBD-8A7E-9223E4AF7A1E@azul.com>
 <e61aeb6d-7411-be11-8715-098e85936ddc@redhat.com>
 <9B6CCFE9-AD17-4D74-8E52-32C8EC2797E5@azul.com>
Message-ID: <ba8fd6e4-48c7-a06b-6873-37fae066cda1@redhat.com>

Hi,

When importing new 11.0.7 files to the sun/security/ssl directory (see
8245468 - Step 1), we included changes from 8046321 [1] (JEP 249 [2]) in
some of the files. 8046321 goes beyond the sun/security/ssl boundary so
we either needed to backport it fully or remove its traces from
sun/security/ssl files. Given that OSCP stappling is highly desirable
for the SunJSSE engine, we decided to backport it fully in Step 6 (8245473).

Files added, modified or deleted by 8046321 in the sun/security/ssl
directory should not require changes in Step 6 (8245473) because
file-replacement in Step 1 (8245468) already did that. These files are:

 * classes/sun/security/ssl/CertStatusReqExtension.java
 * classes/sun/security/ssl/CertStatusReqItemV2.java
 * classes/sun/security/ssl/CertStatusReqListV2Extension.java
 * classes/sun/security/ssl/ClientHandshaker.java
 * classes/sun/security/ssl/ExtensionType.java
 * classes/sun/security/ssl/HandshakeMessage.java
 * classes/sun/security/ssl/HandshakeStateManager.java
 * classes/sun/security/ssl/HelloExtensions.java
 * classes/sun/security/ssl/OCSPStatusRequest.java
 * classes/sun/security/ssl/SSLContextImpl.java
  * Changes on this file are an exception.
'jdk.tls.client.enableStatusRequestExtension' set to 'false' by default
to minimize risks. We should turn this to 'true' in the future, once the
new TLS engine is stable in JDK-8.
 * classes/sun/security/ssl/SSLSessionImpl.java
  * Changes on this file are an exception. Step 6 (8245473) required a
minor change for compilation in JDK-8.
 * classes/sun/security/ssl/ServerHandshaker.java
 * classes/sun/security/ssl/StatusRequest.java
 * classes/sun/security/ssl/StatusRequestType.java
 * classes/sun/security/ssl/StatusResponseManager.java
 * classes/sun/security/ssl/UnknownStatusRequest.java
 * classes/sun/security/ssl/X509TrustManagerImpl.java
  * Changes on this file are an exception. We cast to SSLSessionImpl
instead of ExtendedSSLSession because the public API was not modified to
include ExtendedSSLSession::getStatusResponses.

Test files (under test/*) will be handled by later steps, so we won't
consider them at this point.

The files and changes in 8046321 that need to be reviewed against Step 6
(8245473) are:

 * classes/javax/net/ssl/ExtendedSSLSession.java (modified)
  * We are not going to modify the JDK-8
javax.net.ssl.ExtendedSSLSession API adding a new method. OSCP stappling
will be used SunJSSE internally only (with SunJSSE's X509 Trust Manager).
 * classes/sun/security/provider/certpath/OCSP.java (modified)
  * Ok: no modifications needed because the file was already in JDK-8
 * classes/sun/security/provider/certpath/OCSPNonceExtension.java (new)
  * Ok
 * classes/sun/security/provider/certpath/OCSPRequest.java (modified)
  * Ok: no modifications needed because the file was already in JDK-8
 * classes/sun/security/provider/certpath/OCSPResponse.java (modified)
  * Ok: no modifications needed because the file was already in JDK-8
 * classes/sun/security/provider/certpath/ResponderId.java (new)
  * Ok: no modifications needed because the file was already in JDK-8
 * classes/sun/security/validator/PKIXValidator.java (modified)
  * Ok
 * classes/sun/security/validator/SimpleValidator.java (modified)
  * Ok
 * classes/sun/security/validator/Validator.java (modified)
  * Ok
 * classes/sun/security/x509/PKIXExtensions.java (modified)
  * Ok

Note: Step 6 (8245473) v1 does not include any other change out of the
previous set of files. This is what we expect.

Files modified in Step 6 (8245473) v0 that are not part of 8046321:

 * classes/sun/security/provider/certpath/RevocationChecker.java
  * Ok, this was reverted in v1 and the backport of 8161973 will be
proposed separately.
   * See: https://bugs.openjdk.java.net/browse/JDK-8247276

Step 6 (8245473) v1 looks good to me.

The following comments are part of this review too: [3] [4].

We need a CSR process because new properties are being introduced as
part of this change.

Please hold-on the push to the repository until the whole series is
reviewed, CSR-approved and maintainer approved.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8046321
[2] - https://openjdk.java.net/jeps/249
[3] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011892.html
[4] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011916.html


From shade at redhat.com  Mon Jun 15 08:04:04 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Jun 2020 10:04:04 +0200
Subject: [8u] 8247570: Build failure with -JFR after JDK-8233197 backport
Message-ID: <96eba24c-29bc-45fe-3850-830cc04bcbf3@redhat.com>

8u-specific bug, recently introduced:
  https://bugs.openjdk.java.net/browse/JDK-8247570

Look at this block to spot the issue:
  https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/26d1803768c7#l11.22

I believe the trailing "}" is excessive, so I removed it and unindented the block back:

diff -r 26d1803768c7 src/share/vm/runtime/thread.cpp
--- a/src/share/vm/runtime/thread.cpp   Thu Jun 11 12:17:25 2020 +0200
+++ b/src/share/vm/runtime/thread.cpp   Mon Jun 15 09:56:30 2020 +0200
@@ -3490,19 +3490,18 @@
     MetaspaceShared::preload_and_dump(CHECK_0);
     ShouldNotReachHere();
   }

 #if !INCLUDE_JFR
-    // if JFR is not enabled at the build time keep the original JvmtiExport location
-
-    // Always call even when there are not JVMTI environments yet, since environments
-    // may be attached late and JVMTI must track phases of VM execution
-    JvmtiExport::enter_start_phase();
-
-    // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
-    JvmtiExport::post_vm_start();
-  }
+  // if JFR is not enabled at the build time keep the original JvmtiExport location
+
+  // Always call even when there are not JVMTI environments yet, since environments
+  // may be attached late and JVMTI must track phases of VM execution
+  JvmtiExport::enter_start_phase();
+
+  // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
+  JvmtiExport::post_vm_start();
 #endif

   {
     TraceTime timer("Initialize java.lang classes", TraceStartupTime);


Testing: x86_64 {server,zero} builds

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Mon Jun 15 08:26:56 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 15 Jun 2020 10:26:56 +0200
Subject: [8u] 8247570: Build failure with -JFR after JDK-8233197 backport
In-Reply-To: <96eba24c-29bc-45fe-3850-830cc04bcbf3@redhat.com>
References: <96eba24c-29bc-45fe-3850-830cc04bcbf3@redhat.com>
Message-ID: <75bafcb0046e4741f7a24780084bb1abebed2e64.camel@redhat.com>

Hi Aleksey,

On Mon, 2020-06-15 at 10:04 +0200, Aleksey Shipilev wrote:
> 8u-specific bug, recently introduced:
>   https://bugs.openjdk.java.net/browse/JDK-8247570

jdk8u/jdk8u-dev specific, actually :-)

> Look at this block to spot the issue:
>   https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/26d1803768c7#l11.22
> 
> I believe the trailing "}" is excessive, so I removed it and unindented the block back:
> 
> diff -r 26d1803768c7 src/share/vm/runtime/thread.cpp
> --- a/src/share/vm/runtime/thread.cpp   Thu Jun 11 12:17:25 2020 +0200
> +++ b/src/share/vm/runtime/thread.cpp   Mon Jun 15 09:56:30 2020 +0200
> @@ -3490,19 +3490,18 @@
>      MetaspaceShared::preload_and_dump(CHECK_0);
>      ShouldNotReachHere();
>    }
> 
>  #if !INCLUDE_JFR
> -    // if JFR is not enabled at the build time keep the original JvmtiExport location
> -
> -    // Always call even when there are not JVMTI environments yet, since environments
> -    // may be attached late and JVMTI must track phases of VM execution
> -    JvmtiExport::enter_start_phase();
> -
> -    // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
> -    JvmtiExport::post_vm_start();
> -  }
> +  // if JFR is not enabled at the build time keep the original JvmtiExport location
> +
> +  // Always call even when there are not JVMTI environments yet, since environments
> +  // may be attached late and JVMTI must track phases of VM execution
> +  JvmtiExport::enter_start_phase();
> +
> +  // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
> +  JvmtiExport::post_vm_start();
>  #endif
> 
>    {
>      TraceTime timer("Initialize java.lang classes", TraceStartupTime);
> 
> 
> Testing: x86_64 {server,zero} builds

Seems to be the same fix than Andrew Hughes did for jdk8u/jdk8u[1]. 

Looks good. Please coordinate with him to get this pushed.

Thanks,
Severin

[1] https://bugs.openjdk.java.net/browse/JDK-8247448
    http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011954.html


From akashche at redhat.com  Mon Jun 15 10:22:28 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 15 Jun 2020 11:22:28 +0100
Subject: [8u] RFR: 8132376: Add @requires os.family to the client tests with
 access to internal OS-specific API
Message-ID: <330fc46e-e06c-df1c-dfe2-2820bbb0a98f@redhat.com>

Hi,

Please review the backport of JDK-8132376 to 8u.

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

9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176

8u-dev webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8132376/webrev.00/

This change introduces two new Windows-specific tests. 8u patch removes 
@modules jtreg tag, and adds a type cast to getPeer() call [1][2], that 
is necessary due to changes introduced in 9 with JDK-8074028.

Testing: checked that new tests pass on Windows. Checked that tests 
marked with "@requires (os.family == "mac")" are selected on macOS.


[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176#l2.73
[2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176#l3.76

-- 
-Alex


From andrey at azul.com  Mon Jun 15 11:21:34 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Mon, 15 Jun 2020 14:21:34 +0300
Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC
In-Reply-To: <28e0cf6a-1c52-bd6f-6ca6-b12cb4b4c829@redhat.com>
References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com>
 <CAJwKKmaPC_fjfRovhKS6U3KMfF90f+qKraL9QvD=Lb5R3e7EFg@mail.gmail.com>
 <CAPb8aJ76-8tssfsyfX-8JanZoqveA8MXHgmOjxt7wv8Xv4hc5g@mail.gmail.com>
 <CAJwKKmaLvKGRKLiD9nWCf=9O81emZ7HESLLOCR2Kt7Um6rgd4A@mail.gmail.com>
 <8ba227c7-a697-49ff-42da-b7529ecdef57@redhat.com>
 <379bdc67-88e2-2ac4-66ce-39e21cd76cdc@azul.com>
 <CAJwKKmaE7iq2CixrcFKzgWobN=W_euWkrxyJYUGSk5iHC12SJw@mail.gmail.com>
 <CAPb8aJ4BTHx_ffwguB3J7AtEWXiOSyesHjQB22NrH7f2mz=9Yg@mail.gmail.com>
 <CAJwKKmZFRucTFg6yHLtLK6846Nr3EiZL8QDW13TSQ3MZCuo_qw@mail.gmail.com>
 <CAGUMyaSQZpD=eHxsFM4h18Mivqv59aWysJ-w+P2+Tm9pxHWYqQ@mail.gmail.com>
 <CAPb8aJ5N=Nmu37GWyivWYTtj=LkOG8DnpkACoXU2N40tpgpaqQ@mail.gmail.com>
 <28e0cf6a-1c52-bd6f-6ca6-b12cb4b4c829@redhat.com>
Message-ID: <9afa139d-5698-4831-a4d6-99a43d05cbb6@azul.com>

Pushed

Sorry for the delay, there were state holidays.
Thank you all, especially Jaroslav for not letting this slip away from
8u262!

Regards,
Andrey

On 12.06.2020 17:55, Andrew Hughes wrote:
> On 12/06/2020 09:37, Jaroslav Bachor?k wrote:
>> Hi,
>>
>> I have labelled the JIRA issue.
>>
>> Cheers,
>>
>> -JB-
>>
> I've approved this. However, in future, please add a comment when adding
> the label in future, stating why it should be approved. This is
> especially important when you're requesting a critical approval during
> rampdown.
>
> In this case, I think the patch is safe, as it adds a function which is
> then only called from JFR code, which is new in 8u262 (and thus, by
> definition, can't regress).
>
> But, please try to get such changes in before rampdown in future. I
> realise this was held up waiting for reviewers, so that's as much an
> appeal to reviewers to be pro-active as it is those submitting patches
> for review.
>
> Thanks,


From zgu at redhat.com  Mon Jun 15 12:59:31 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 15 Jun 2020 08:59:31 -0400
Subject: [8u] RFR: 8132376: Add @requires os.family to the client tests
 with access to internal OS-specific API
In-Reply-To: <330fc46e-e06c-df1c-dfe2-2820bbb0a98f@redhat.com>
References: <330fc46e-e06c-df1c-dfe2-2820bbb0a98f@redhat.com>
Message-ID: <27d4a1b8-780d-aa8a-5c31-c18b395be6fe@redhat.com>

Looks good to me.

Thanks,

-Zhengyu

On 6/15/20 6:22 AM, Alex Kashchenko wrote:
> Hi,
> 
> Please review the backport of JDK-8132376 to 8u.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8132376
> 
> 9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176
> 
> 8u-dev webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8132376/webrev.00/
> 
> This change introduces two new Windows-specific tests. 8u patch removes 
> @modules jtreg tag, and adds a type cast to getPeer() call [1][2], that 
> is necessary due to changes introduced in 9 with JDK-8074028.
> 
> Testing: checked that new tests pass on Windows. Checked that tests 
> marked with "@requires (os.family == "mac")" are selected on macOS.
> 
> 
> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176#l2.73
> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176#l3.76
> 


From akashche at redhat.com  Mon Jun 15 14:41:33 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 15 Jun 2020 15:41:33 +0100
Subject: [8u] RFR: 8132376: Add @requires os.family to the client tests
 with access to internal OS-specific API
In-Reply-To: <27d4a1b8-780d-aa8a-5c31-c18b395be6fe@redhat.com>
References: <330fc46e-e06c-df1c-dfe2-2820bbb0a98f@redhat.com>
 <27d4a1b8-780d-aa8a-5c31-c18b395be6fe@redhat.com>
Message-ID: <dc1619ce-c7cf-7d57-bdb4-751a28126cb9@redhat.com>

On 06/15/2020 01:59 PM, Zhengyu Gu wrote:
> Looks good to me.

Thanks for the review! I've added jdk8u-fix-request label to the issue.

> 
> Thanks,
> 
> -Zhengyu
> 
> On 6/15/20 6:22 AM, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review the backport of JDK-8132376 to 8u.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132376
>>
>> 9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176
>>
>> 8u-dev webrev: 
>> http://cr.openjdk.java.net/~akasko/jdk8u/8132376/webrev.00/
>>
>> This change introduces two new Windows-specific tests. 8u patch 
>> removes @modules jtreg tag, and adds a type cast to getPeer() call 
>> [1][2], that is necessary due to changes introduced in 9 with 
>> JDK-8074028.
>>
>> Testing: checked that new tests pass on Windows. Checked that tests 
>> marked with "@requires (os.family == "mac")" are selected on macOS.
>>
>>
>> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176#l2.73
>> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3aef124b3176#l3.76
>>
> 


-- 
-Alex


From zgu at redhat.com  Mon Jun 15 15:36:12 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 15 Jun 2020 11:36:12 -0400
Subject: [8u] RFR (XS) 8153430: jdk regression test MletParserLocaleTest, 
 ParserInfiniteLoopTest reduce default timeout
In-Reply-To: <2f9c5aab-e053-84e3-bdf4-168b1e2cc521@redhat.com>
References: <a3a66df2-0b2c-e09f-089f-acf2a1596883@redhat.com>
 <2f9c5aab-e053-84e3-bdf4-168b1e2cc521@redhat.com>
Message-ID: <3df900f7-5300-ffbc-7c09-203664d3bbcb@redhat.com>

Hi Aleksey,

I reviewed this patch, could you please request for an approval?

Thanks,

-Zhengyu

On 5/21/20 8:31 AM, Zhengyu Gu wrote:
> Backport looks good.
> 
> -Zhengyu
> 
> On 3/16/20 6:15 AM, Aleksey Shipilev wrote:
>> Original fix:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8153430
>> ?? https://hg.openjdk.java.net/jdk/jdk/rev/92cf8efd381d
>>
>> MletParserLocaleTest.java was added by JDK-7065236 only in 9, so that 
>> hunk does not apply.
>> ParserInfiniteLoopTest.java hunk applies cleanly.
>>
>> 8u webrev:
>> ?? https://cr.openjdk.java.net/~shade/8153430/webrev.8u.01/
>>
>> Testing: affected test
>>


From gnu.andrew at redhat.com  Mon Jun 15 15:45:43 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 15 Jun 2020 16:45:43 +0100
Subject: [8u] 8247570: Build failure with -JFR after JDK-8233197 backport
In-Reply-To: <75bafcb0046e4741f7a24780084bb1abebed2e64.camel@redhat.com>
References: <96eba24c-29bc-45fe-3850-830cc04bcbf3@redhat.com>
 <75bafcb0046e4741f7a24780084bb1abebed2e64.camel@redhat.com>
Message-ID: <bfccc898-d6a1-70ce-4904-c8ba7a2d055f@redhat.com>



On 15/06/2020 09:26, Severin Gehwolf wrote:
> Hi Aleksey,
> 
> On Mon, 2020-06-15 at 10:04 +0200, Aleksey Shipilev wrote:
>> 8u-specific bug, recently introduced:
>>   https://bugs.openjdk.java.net/browse/JDK-8247570
> 
> jdk8u/jdk8u-dev specific, actually :-)
> 
>> Look at this block to spot the issue:
>>   https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/26d1803768c7#l11.22
>>
>> I believe the trailing "}" is excessive, so I removed it and unindented the block back:
>>
>> diff -r 26d1803768c7 src/share/vm/runtime/thread.cpp
>> --- a/src/share/vm/runtime/thread.cpp   Thu Jun 11 12:17:25 2020 +0200
>> +++ b/src/share/vm/runtime/thread.cpp   Mon Jun 15 09:56:30 2020 +0200
>> @@ -3490,19 +3490,18 @@
>>      MetaspaceShared::preload_and_dump(CHECK_0);
>>      ShouldNotReachHere();
>>    }
>>
>>  #if !INCLUDE_JFR
>> -    // if JFR is not enabled at the build time keep the original JvmtiExport location
>> -
>> -    // Always call even when there are not JVMTI environments yet, since environments
>> -    // may be attached late and JVMTI must track phases of VM execution
>> -    JvmtiExport::enter_start_phase();
>> -
>> -    // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
>> -    JvmtiExport::post_vm_start();
>> -  }
>> +  // if JFR is not enabled at the build time keep the original JvmtiExport location
>> +
>> +  // Always call even when there are not JVMTI environments yet, since environments
>> +  // may be attached late and JVMTI must track phases of VM execution
>> +  JvmtiExport::enter_start_phase();
>> +
>> +  // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
>> +  JvmtiExport::post_vm_start();
>>  #endif
>>
>>    {
>>      TraceTime timer("Initialize java.lang classes", TraceStartupTime);
>>
>>
>> Testing: x86_64 {server,zero} builds
> 
> Seems to be the same fix than Andrew Hughes did for jdk8u/jdk8u[1]. 
> 
> Looks good. Please coordinate with him to get this pushed.
> 
> Thanks,
> Severin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8247448
>     http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011954.html
> 

Nothing needs to be pushed. This will be fixed when b07 is merged back
into 8u-dev, as I said here:

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011954.html
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Mon Jun 15 16:52:57 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 15 Jun 2020 17:52:57 +0100
Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to
 Apache Santuario 2.1.1
In-Reply-To: <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com>
References: <acc3e996-34b6-3e20-8593-61630a0bb6ea@redhat.com>
 <c23ef2c1-faa1-8d9a-0a9a-a93513843d3b@redhat.com>
 <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com>
Message-ID: <106cb997-5693-c24b-f0e0-c70e8e21d877@redhat.com>



On 25/05/2020 21:53, Elliott Baron wrote:
> Hi,
> 
> On 2020-05-08 2:58 p.m., Elliott Baron wrote:
>> Hi,
>>
>> On 2020-04-16 7:54 p.m., Elliott Baron wrote:
>>> Hi,
>>>
>>> I'd like to request a review to backport 8177334 to 8u.
>>>
>>> Original fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8177334
>>> http://hg.openjdk.java.net/jdk/jdk/rev/3810c9a2efa1
>>>
>>> The JDK 11 fix did not apply cleanly. Below, I have detailed the
>>> modifications I made in order to backport this fix to 8u. There are
>>> some major changes that I believe may require some discussion, and
>>> many minor changes outlined after those. The changes within each
>>> section are listed roughly in order of the patch.
>>>
>>> Thank you to Martin Balao for his assistance in tracking down the
>>> dependencies for this fix.
>>>
>>> I should point out that there are some known bugfixes that fix
>>> problems introduced by this update. These should probably go into the
>>> same 8u update as this fix. They are:
>>> - 8217878: ENVELOPING XML signature no longer works
>>> - 8218629: XML Digital Signature throws NAMESPACE_ERR exception on
>>> OpenJDK 11, works 8/9/10 (I believe this is the same fix as above)
>>> - 8236645: JDK 8u231 introduces a regression with incompatible
>>> handling of XML messages
>>>
>>> 8u webrev:
>>> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.00/
>>
>> Has anyone had a chance to take a look at this yet?
>>
>>>
>>> [snip]
> 
> Here is an updated webrev that fixes conflicts introduced by
> 8231415: Better signatures in XML.
> 
> 8u webrev:
> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.01/
> 
> Thanks,
> Elliott
> 

Thanks for completing what is a huge backport.

Can you comment more on what changes you believe require discussion?
>From comparing with the 11u version, most of it seems fine:

* Movement of checkRegisterPermission in JavaUtils.java is omitted as
it's already been moved to its current location in 8u
* Omission of new 11u algorithms in DigestMethod.java and
SignatureMethod.java seems appropriate
* Leaving out the type checking in e.g. DOMKeyInfo.java seems
appropriate as these API methods did not previously throw ClassCastException

My main concern is that, although we don't add the new algorithms to
DigestMethod & SignatureMethod, or their tests, we do seem to be adding
support in e.g. JCEMapper for new algorithms like SHA3. I think we
should be consistent here and if we're not going to put new algorithms
in DigestMethod & SignatureMethod, and not include tests of them, they
shouldn't be being implemented.

I also wonder why getSignature was pulled into DOMSignatureMethod.java
from JDK-8042967. Why was this needed?

Thanks,
-- 
Andrew :)

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

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


From zgu at redhat.com  Mon Jun 15 18:17:43 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 15 Jun 2020 14:17:43 -0400
Subject: [8u] RFR 8060721: Test
 runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new
 platforms/compiler
Message-ID: <f6ad8e49-1538-f4cd-8d04-53f43a491b6e@redhat.com>

Hi,

I would like to backport this patch to OpenJDK 8u as Oracle parity.

The original patch does not apply cleanly, as it was preceded by 
JDK-8148630 (unify logging [1]) that is not backportable to 8u.

Original bug:  https://bugs.openjdk.java.net/browse/JDK-8060721
Original patch: 
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8666e625f2a4

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

Thanks,

-Zhengyu


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


From shade at redhat.com  Mon Jun 15 18:25:25 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Jun 2020 20:25:25 +0200
Subject: [8u] 8247570: Build failure with -JFR after JDK-8233197 backport
In-Reply-To: <bfccc898-d6a1-70ce-4904-c8ba7a2d055f@redhat.com>
References: <96eba24c-29bc-45fe-3850-830cc04bcbf3@redhat.com>
 <75bafcb0046e4741f7a24780084bb1abebed2e64.camel@redhat.com>
 <bfccc898-d6a1-70ce-4904-c8ba7a2d055f@redhat.com>
Message-ID: <ba5070f5-2f83-8305-56b2-28c59dfc000e@redhat.com>

On 6/15/20 5:45 PM, Andrew Hughes wrote:
>> Seems to be the same fix than Andrew Hughes did for jdk8u/jdk8u[1]. 
>>
>> Looks good. Please coordinate with him to get this pushed.
>>
>> Thanks,
>> Severin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8247448
>>     http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011954.html
>>
> 
> Nothing needs to be pushed. This will be fixed when b07 is merged back
> into 8u-dev, as I said here:
> 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011954.html

Okay then! It is a bit awkward to make a change during the merge, but oh well.

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Mon Jun 15 21:05:25 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 15 Jun 2020 17:05:25 -0400
Subject: [8u] RFR 8151788: NullPointerException from ntlm.Client.type3
Message-ID: <1e03882e-b9ef-69ae-5c80-2fa8782bb3cc@redhat.com>

Hi,

I would like to backport this patch to 8u, as Oracle parity.

The original patch applies cleanly after file path change. However, I 
modified the new test, removed its @modules annotation.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8151788
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3b503af253a4


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

Test:
   New test on Linux x86_64


Thanks,

-Zhengyu


From mbalao at redhat.com  Mon Jun 15 22:44:17 2020
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 15 Jun 2020 19:44:17 -0300
Subject: [8u] RFR : TLSv1.3 protocol support
In-Reply-To: <B85DE79B-9FD1-49BC-8C2B-D293E8A61013@azul.com>
References: <B85DE79B-9FD1-49BC-8C2B-D293E8A61013@azul.com>
Message-ID: <07083b85-1c69-923f-06a0-d896681a9977@redhat.com>

Hi Alexey,

Below this email you'll find my independent list of the bugs covered
under Step 1 (8245468). This list is based on what Oracle backported to
their closed 8u261 (related to TLS 1.3). There may be bugs missing
because our file-replacement approach may have dragged more things
implicitly.

Can you please merge this list with the list you have and tell me the
diff? (so I can double-check the additions)

We need this list to be part of the commit message, so we document -in a
best-effort manner- what is under the scope.

In addition to documentation, going through each of these bugs was
useful to check that: 1) nothing was missing, and 2) find patches that
may have impact out of sun/security/ssl directory.

NOTE: the list does not include purely-test patches because they are not
covered under Step 1. I'll have a separate list later.

Below this email you'll also find a list of (non-vulnerability) patches
introduced between 11.0.7 and 11.0.8, which are not under the scope of
the work being done. We will need to backport each of them independently.

Thanks,
Martin.-

--

Step 1 (8245468) COVERED - 11.0.7
..............................

 * JDK-8212885: TLS 1.3 resumed session does not retain peer certificate
chain
 * JDK-8211806: TLS 1.3 handshake server name indication is missing on a
session resume
 * JDK-8207009: TLS 1.3 half-close and synchronization issues
 * JDK-8211866: TLS 1.3 CertificateRequest message sometimes offers
disallowed signature algorithms
 * JDK-8210334: TLS 1.3 server fails if ClientHello doesn't have
pre_shared_key and psk_key_exchange_modes
 * JDK-8214688: TLS 1.3 session resumption with hello retry request
failed with "illegal_parameter"
 * JDK-8210846: TLSv.1.3 interop problems with OpenSSL 1.1.1 when used
on the client side with mutual auth
 * JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored
in PKCS11
 * JDK-8221253: TLSv1.3 may generate TLSInnerPlainText longer than
2^14+1 bytes
 * JDK-8216045: The size of key_exchange may be wrong on FFDHE
 * JDK-8209965: The "supported_groups" extension in ServerHellos
 * JDK-8214098: sun.security.ssl.HandshakeHash.T12HandshakeHash
constructor check backwards.
 * JDK-8208166: Still unable to use custom SSLEngine with default
TrustManagerFactory after JDK-8207029
 * JDK-8214339: SSLSocketImpl erroneously wraps SocketException
 * JDK-8207237: SSLSocket#setEnabledCipherSuites is accepting empty string
 * JDK-8216326: SSLSocket stream close() does not close the associated
socket
 * JDK-8206355: SSLSessionImpl.getLocalPrincipal() throws NPE
 * JDK-8207317: SSLEngine negotiation fail exception behavior changed
from fail-fast to fail-lazy
 * JDK-8145854: SSLContextImpl.statusResponseManager should be generated
if required
 * JDK-8214129: SSL session resumption/SNI with TLS1.2 causes
StackOverflowError
 * JDK-8207223: SSL Handshake failures are reported with more generic
SSLException
 * JDK-8210989: RSASSA-PSS certificate cannot be selected for client
auth on TLSv1.2
 * JDK-8165275: Replace the reflective call to the implUpdate method in
HandshakeMessage::digestKey
 * JDK-8206176: Remove the temporary tls13VN field
 * JDK-8213202: Possible race condition in TLS 1.3 session resumption
 * JDK-8213782: NullPointerException in
sun.security.ssl.OutputRecord.changeWriteCiphers
 * JDK-8209916: NPE in SupportedGroupsExtension
 * JDK-8210974: No extensions debug log for ClientHello
 * JDK-8214321: Misleading code in SSLCipher
 * JDK-8236039: JSSE Client does not accept status_request extension in
CertificateRequest messages for TLS 1.3
 * JDK-8028518: Increase the priorities of GCM cipher suites
 * JDK-8212738: Incorrectly named signature scheme ecdsa_secp512r1_sha512
 * JDK-8215524: Finished message validation failure should be
decrypt_error alert
 * JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl
 * JDK-8215790: Delegated task created by SSLEngine throws
java.nio.BufferUnderflowException
 * JDK-8219389: Delegated task created by SSLEngine throws
BufferUnderflowException
 * JDK-8225766: Curve in certificate should not affect signature scheme
when using TLSv1.3
 * JDK-8206929: Check session context for TLS 1.3 session resumption
 * JDK-8229733: TLS message handling improvements
 * JDK-8207029: Unable to use custom SSLEngine with default
TrustManagerFactory after updating to JDK 11 b21
 * JDK-8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after
removing sunec.dll
 * JDK-8223482: Unsupported ciphersuites may be offered by a TLS client
 * JDK-4919790: Errors in alert ssl message does not reflect the actual
certificate status
 * JDK-8218889: Improperly use of the Optional API

MISSING 11.0.8 - important
..............................

 * JDK-8239798: SSLSocket closes socket both socket endpoints on a
SocketTimeoutException
 * JDK-8223940: Private key not supported by chosen signature algorithm
 * JDK-8211339: NPE during SSL handshake caused by HostnameChecker
 * JDK-8242141: New System Properties to configure the TLS signature schemes
 * JDK-8215711: Missing key_share extension for (EC)DHE key exchange
should alert missing_extension
 * JDK-8237474: Default SSLEngine should create in server role
 * JDK-8234728: Some security tests should support TLSv1.3
 * JDK-8234725: sun/security/ssl/SSLContextImpl tests support TLSv1.3
 * JDK-8205653:
test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and
RmiSslBootstrapTest.sh fail with handshake_failure
 * JDK-8209333: Socket reset issue for TLS 1.3 socket close
 * JDK-8228757: Fail fast if the handshake type is unknown
 * JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions
 * JDK-8235311: Tag mismatch may alert bad_record_mac
 * JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3
 * JDK-8235874: The ordering of Cipher Suites is not maintained provided
through "jdk.tls.client.cipherSuites" and "jdk.tls.server.cipherSuites"
system property.
 * JDK-8205111: Develop new Test to verify different key types for
supported TLS protocols.
 * JDK-8235183: Remove the "HACK CODE" in comment

MISSING 11.0.8 - not SSL strictly but related
..............................

 * JDK-7092821: java.security.Provider.getService() is synchronized and
became scalability bottleneck
 * JDK-8148188: Enhance the security libraries to record events of interest


From mbalao at redhat.com  Mon Jun 15 22:51:30 2020
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 15 Jun 2020 19:51:30 -0300
Subject: [8u] TLSv1.3 RFR: 8245468: Add TLSv1.3 implementation classes
 from 11.0.7
In-Reply-To: <7c094555-de0d-7b40-0abd-81dc30fb8236@redhat.com>
References: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com>
 <7c094555-de0d-7b40-0abd-81dc30fb8236@redhat.com>
Message-ID: <ab25c8b8-327d-75f3-9290-de099b1f7248@redhat.com>

On 5/22/20 4:41 PM, Martin Balao wrote:
> 
> 8245468 (Step 1) webrev.v0 looks good to me. Please hold the push until
> the whole series is review-approved and approved by a JDK-8 maintainer.

Before pushing this change please have a look at the request here:
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011969.html

Thanks,
Martin.-


From mbalao at redhat.com  Mon Jun 15 22:58:22 2020
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 15 Jun 2020 19:58:22 -0300
Subject: [8u] RFR : TLSv1.3 protocol support
In-Reply-To: <07083b85-1c69-923f-06a0-d896681a9977@redhat.com>
References: <B85DE79B-9FD1-49BC-8C2B-D293E8A61013@azul.com>
 <07083b85-1c69-923f-06a0-d896681a9977@redhat.com>
Message-ID: <0ae019ce-bd34-ad35-ef07-80a2ce99371c@redhat.com>

On 6/15/20 7:44 PM, Martin Balao wrote:
> 
> Step 1 (8245468) COVERED - 11.0.7
> ..............................

Ah, forgot to include the most important (and obvious) one: JDK-8196584:
TLS 1.3 Implementation


From mbalao at redhat.com  Tue Jun 16 00:10:55 2020
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 15 Jun 2020 21:10:55 -0300
Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support
 according to RFC-2712
In-Reply-To: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com>
References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com>
Message-ID: <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com>

On 5/21/20 11:12 AM, Alexey Bakhtin wrote:
> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u

Hi Alexey,

A few comments / questions regarding Step 7 (8245474) v0:

 * Do we have tests covering this functionality?

 * CipherSuite.java

  * TLS_KRB5_WITH_3DES_EDE_CBC_SHA
   * Shouldn't this be enabled for protocols previous to TLS 1.2 too?
    * Note: I'm okay with TLS 1.2 being the upper limit.
   * Shouldn't we check whether SunJSSE::isFIPS is true or not before
setting isDefaultEnabled to 'true'?
    * I'm more inclined to set the isDefaultEnabled value to 'false',
even while not in FIPS mode. I've seen many ciphersuites which were 'N'
in the old TLS engine and are now isDefaultEnabled == false. Even if we
change the 'default behavior', I believe we should disable everything
not secure by default. That's precisely one of the points of upgrading
the TLS engine, and what we are doing for other non-KRB5 ciphersuites
already (since Step 1). What do you think?
     * Looks to me that jdk.tls.client.cipherSuites and
jdk.tls.server.cipherSuites properties can be used to override the default
      * We should document in a CSR all these changes so users can
understand how the default configuration is different from the previous
and how to enable a 'non-secure' but 'backward-compatible' behavior.
     * Please have a look at the tests that may be affected by any of
these changes.

  * With the previous comments in mind, please have a look at the other
KRB5 ciphersuites added.

 * ClientHello.java

  * I've seen there is a copyright line addition. If you want to keep it
there, please get approval from 8u maintainers because I'm not sure of
the policy there.
   * Same comment for SSLKeyExchange.java, SSLSessionImpl.java and
ServerHello.java
   * This comment does not apply to new files, which look okay to me

  * I suggest to be explicit in what we import, instead of "java.security.*"

  * I've seen a double-spacing in "} else  if (suite.keyExchange ==
K_KRB5 ||"

  * Are changes needed for previous versions of the protocol? TLS 1.1,
TLS 1.0, etc.

  * I suggest to follow the pattern. Create a new condition of type "if
(resumingSession && ..." instead of hooking "Validate that the cached
cipher suite" one

  * No gain in inserting a newline after "return"

 * ServerHello.java

  * Are changes needed for previous versions of the protocol? TLS 1.1,
TLS 1.0, etc.

 * HandshakeContext.java

  * I suggest to move sun/security/ssl/krb5/* files to sun/security/ssl
so we can keep HandshakeContext and other classes visibility unchanged.
This change will probably eliminate the need to add getMajor and
getMinor methods in ProtocolVersion, as well as changing valueOf method
visibility.

 * KrbClientKeyExchange.java

  * Can we make it more similar to DHClientKeyExchange.java /
ECDHClientKeyExchange.java / RSAClientKeyExchange.java?
   * I.e.: can we make the class final? can we have analogous comments
in the same locations? can we refer to the constructor through
KrbClientKeyExchangeConsumer instead of
KrbClientKeyExchange.KrbClientKeyExchangeConsumer? etc. None of these
examples are critical but I wish we could stick to the 'template' as
much as possible. More on this below.

 * Why do we have KerberosClientKeyExchange.java and
KrbClientKeyExchange.java files?
  * I see that for other key exchange methods there is only one file,
containing the class that inherits from HandshakeMessage. This makes me
think that KerberosClientKeyExchange class should probably be renamed to
KrbClientKeyExchangeMessage (having KerberosClientKeyExchange and
KrbClientKeyExchange classes simulateneously looks confusing to me and
does not follow the previous *ClientKeyExchange template).

 * KerberosClientKeyExchangeImpl.java
  * I wonder if it makes sense to have a separate "Impl" class. None of
the other key exchange methods are designed this way. I don't see how
KerberosClientKeyExchange::implClass could be assigned to null or to
something different than KerberosClientKeyExchangeImpl class. I could
track this to 6885204 and 6894643. Unless there is a good reason, I
suggest to get rid of this complexity and stick to the 'template'.

As a general criteria, I suggest to adapt-to/do-not-modify the new TLS
engine over keeping the old files/code unchanged. Looks to me that
handling this as a new feature is easier and more clear to review. This
would be a different strategy to what we have been doing in previous
Steps, and I see two reasons: 1) we are not re-introducing a specific
change because the TLS KRB5 has been in the old TLS engine since the
beginning of OpenJDK -so this cannot be a patch vs patch review-, and 2)
it's better for clarity and consistency to analyze this feature in the
context of the new engine, as an instance of a key exchange method such
as RSA, DH, etc.

There may be more comments but wish we could focus on these things
first. Thus, I expect at least a couple of iterations more.

Please feel free to comment / argue on any of the previous points before
working on a new webrev, so we are in the same page first.

Thanks,
Martin.-



From denghui.ddh at alibaba-inc.com  Tue Jun 16 03:44:27 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Tue, 16 Jun 2020 11:44:27 +0800
Subject: =?UTF-8?B?UkZSIDgyMTc2NDc6IFtiYWNrcG9ydF0gSkZSOiByZWNvcmRpbmdzIG9uIDMyLWJpdCBzeXN0?=
 =?UTF-8?B?ZW1zIHVucmVhZGFibGU=?=
Message-ID: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>

Could I have a review of this backport?

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

Original fix from 11u:
  http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893

Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/

Backport reasons:
1. Fix the unreadable problem on 32-bit in 8u
2. Make subsequent backport more smoothly

The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:

 a) Conflict in jfrRecorderService.cpp. Patch wants this:

-static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
-  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
-  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
+static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
+  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
+  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
   cw.reserve(sizeof(u4));
   cw.write<u8>(EVENT_CHECKPOINT);
   cw.write(JfrTicks::now());
-  cw.write<jlong>((jlong)0);
+  cw.write((int64_t)0);
   cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
   cw.write<bool>(false); // flushpoint
-  cw.write<u4>((u4)1); // nof types in this checkpoint
-  cw.write<u8>(type_id);
-  const intptr_t number_of_elements_offset = cw.current_offset();
+  cw.write((u4)1); // nof types in this checkpoint
+  cw.write(type_id);
+  const int64_t number_of_elements_offset = cw.current_offset();
   cw.reserve(sizeof(u4));
   return number_of_elements_offset;
 }

 ... but the 8u code is:

static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
  cw.reserve(sizeof(u4));
  cw.write<u8>(EVENT_CHECKPOINT);
  cw.write(JfrTicks::now());
  cw.write<jlong>((jlong)0);
  cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
  cw.write<bool>(false); // flushpoint
  cw.write<u4>((u4)1); // nof types in this checkpoint
  cw.write<u8>(type_id);
  const intptr_t number_of_elements_offset = cw.current_offset();
  cw.reserve(sizeof(u4));
  return number_of_elements_offset;
}

 ... I did a manual adjustment: 
    cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);

 b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:

 template <typename BE, typename IE, typename WriterPolicyImpl>
 inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
-  be_write(*(uintptr_t*)&(value));
+  be_write(*(u8*)&(value));
 }

 ... but the 8u code is:

template <typename BE, typename IE, typename WriterPolicyImpl>
inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
  be_write(*(u8*)&(value));
}

 ... so I skipped it.

 c) Build failure. Patch wants this in jfrRepository.cpp:

+            log_info(jfr) ( // For user, should not be "jfr, system"
+              "Unable to recover JFR data");
+            break;

 ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"


 d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)

Thanks,
Denghui Dong

From mbalao at redhat.com  Tue Jun 16 04:22:42 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 16 Jun 2020 01:22:42 -0300
Subject: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine
In-Reply-To: <8451478a-8610-0460-9b09-43763e51d006@redhat.com>
References: <828504cf-47d4-283d-5910-b7e0edfc23eb@redhat.com>
 <2c8386ac-acbe-7eae-853f-4cd6d3955a68@redhat.com>
 <1F1915CC-9110-461D-8F3C-F5D6394D2F33@azul.com>
 <7dab1baa-6dca-bf8a-1ced-6c639df85467@redhat.com>
 <8daa7c35-1280-5822-d820-3bfe58d29241@redhat.com>
 <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com>
 <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>
 <8451478a-8610-0460-9b09-43763e51d006@redhat.com>
Message-ID: <3217278f-d7d9-7a8a-1506-904973b0976b@redhat.com>

Hi Andrew,

On 6/7/20 2:21 PM, Andrew Hughes wrote:
> 
> I don't think this is feasible. It seems to assume that the only change
> in 8u272 will be the TLS 1.3 engine. The reality is that the period from
> now until rampdown will be a mix of TLS 1.3 patches interleaved with
> other backports, so one would have to cherry-pick out all the non-TLS
> work and reapply it somewhere else.

That's a valid point. It might be the case that the TLS engine cannot be
plugged-in/out easily because of dependencies with other patches pushed
for the release. My understanding, though, is that the risk is not that
high because the TLS engine is pretty much self-contained within
sun/security/ssl boundaries. Perhaps certificate validation or a couple
of things related to Security providers are the weakest fronts.

Note: we should integrate as soon as possible to minimize risk by having
enough time to test and to avoid last minute rebasing of the TLS 1.3
series of patches -which may even cascade between steps and cause a lot
of rework-. Also because there are quite a few patches that went to
11.0.8 (instead of 11.0.7 or before) which are currently blocked and we
need to independently backport for October's CPU.

> 
> My suggestion would be to follow the JFR route:
> 
> 1. Now: Setup a TLS incubator tree and apply the patches there.
> 
> 2. Monday, August 24th, 2020: Decide whether to merge the incubator tree
> into 8u-dev before rampdown on Friday, 28th.
> 
> 3. Assuming it is integrated, test TLS 1.3 in 8u272 during September.
> 
> The benefits of this are:
> 
> 1. You can handle the commit policy for the incubator (just reviews, no
> need for individual approvals)
> 
> 2. One single approval can be used to merge TLS 1.3 in rampdown week.
> 
> 3. Merging just before rampdown makes your proposal feasible, assuming
> low traffic during rampdown.

I'm okay with this approach.

Thanks,
Martin.-


From mbalao at redhat.com  Tue Jun 16 04:48:45 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 16 Jun 2020 01:48:45 -0300
Subject: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine
In-Reply-To: <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>
References: <828504cf-47d4-283d-5910-b7e0edfc23eb@redhat.com>
 <2c8386ac-acbe-7eae-853f-4cd6d3955a68@redhat.com>
 <1F1915CC-9110-461D-8F3C-F5D6394D2F33@azul.com>
 <7dab1baa-6dca-bf8a-1ced-6c639df85467@redhat.com>
 <8daa7c35-1280-5822-d820-3bfe58d29241@redhat.com>
 <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com>
 <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>
Message-ID: <c6feaa62-52e1-e9e3-9116-489f9bac1185@redhat.com>

> ============ Gil Tene (2020-06-04) ============
> 
>>>> On 6/4/20 3:52 PM, Martin Balao wrote:
>>>> It's a hard choice. I'm more inclined not to push that into the upstream
>>>> repository. A parallel TLS engine will need to be updated regularly
>>>> -against security issues at least- and supported, increasing the
>>>> maintenance burden. The integration itself may create unexpected
>>>> trouble. In addition, we will be introducing a non-standard Security
>>>> Provider that breaks compatibility with Oracle's JDK and creates some
>>>> expectations on our users of what is available in JDK-8 (if we decide to
>>>> remove it later, we will certainly break code).
> 
> I think that (in the balance) I agree that we don't want this fallback
> provider in the project itself. The fact that we will want to quickly
> deprecate and remove it (once the new stuff has been around for a while
> and works well) is a good hint that we should not put it in.
> 
> But I do think that it would be useful, and it looks to be working well.
> What we can do is put it up under openjsse on github, so it is ready to
> go if people need it. This way it acts as interim insurance, is
> available for everyone (and e.g. for distros that want to bundle it) but
> does not contaminate the project with the long term legacy of a
> temporary bandaid...

We are on the same page, then.

> 
>>>>
>>>> One thing that came to my mind to address this problem was having an
>>>> 'emergency 8u272 build' with all the security patches applied but
>>>> without the TLS 1.3 engine. In case things go horribly wrong, we can ask
>>>> our users to use that build until 8u282.
> 
> That's definitely an alternative, but it also risks the long term
> bifurcation with two builds needed every quarter. i.e. of both builds
> are available in 8u272, most people may choose to go with the no-new-TLS
> mode to contain risk, and only people that actually want TLS 1.3 will
> adopt the new builds. We will then be faced with the need to keep
> building both every quarter for a while.
> 

Let me clarify a bit the idea, because there is some misunderstanding. I
was not proposing to release or maintain both builds: only one at a time.

The 8u repository will have the new TLS engine pushed. We can release
8u272-build-<N> with new TLS engine and have 8u272-build-<N+1> with the
old TLS engine ready but unreleased.

If thing go okay, 8u272-build-<N+1> will be dropped without being ever
published.

If things go wrong -to the point that we have a major/blocker issue that
cannot be quickly resolved-, we release 8u272-build-<N+1> immediately as
the successor of 8u272-build-<N>.

That would give us 3 months to fix the problem and release 8u282 with
the new TLS engine.

Note: there cannot be much time between 8u272-build-<N> and
8u272-build-<N+1> because even if the change should be transparent for
most of the users, some of them may need to modify their applications
for backward compatibility.

I see a couple of downsides:

1) As @gnu_andrew pointed out, there may be dependencies that make
'backing out the new TLS engine patches' to generate build-<N+1> not
that trivial.

2) We need to somehow publish the source code upon which
8u272-build-<N+1> was built for license compliance reasons.

Regards,
Martin.-


From ecki at zusammenkunft.net  Tue Jun 16 04:59:51 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 16 Jun 2020 04:59:51 +0000
Subject: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine
In-Reply-To: <c6feaa62-52e1-e9e3-9116-489f9bac1185@redhat.com>
References: <828504cf-47d4-283d-5910-b7e0edfc23eb@redhat.com>
 <2c8386ac-acbe-7eae-853f-4cd6d3955a68@redhat.com>
 <1F1915CC-9110-461D-8F3C-F5D6394D2F33@azul.com>
 <7dab1baa-6dca-bf8a-1ced-6c639df85467@redhat.com>
 <8daa7c35-1280-5822-d820-3bfe58d29241@redhat.com>
 <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com>
 <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com>,
 <c6feaa62-52e1-e9e3-9116-489f9bac1185@redhat.com>
Message-ID: <AM6PR03MB4389995726DB4504684DB2F3FF9D0@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

I would expect that Oracle will include the new JSSE provider in their PSU but not in their CPU release. And since at least Azul also follows that convention, why not make this a OpenJDK Release as well (i.e. the opposite of the below mentioned sequence, release 8uN without TLS changes and N+1 as well as (later) N+10 with the backport.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> im Auftrag von Martin Balao <mbalao at redhat.com>
Gesendet: Tuesday, June 16, 2020 6:48:45 AM
An: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Cc: Pavel Petroshenko <pavel at azul.com>; Gil Tene <gil at azul.com>
Betreff: Re: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine

> ============ Gil Tene (2020-06-04) ============
>
>>>> On 6/4/20 3:52 PM, Martin Balao wrote:
>>>> It's a hard choice. I'm more inclined not to push that into the upstream
>>>> repository. A parallel TLS engine will need to be updated regularly
>>>> -against security issues at least- and supported, increasing the
>>>> maintenance burden. The integration itself may create unexpected
>>>> trouble. In addition, we will be introducing a non-standard Security
>>>> Provider that breaks compatibility with Oracle's JDK and creates some
>>>> expectations on our users of what is available in JDK-8 (if we decide to
>>>> remove it later, we will certainly break code).
>
> I think that (in the balance) I agree that we don't want this fallback
> provider in the project itself. The fact that we will want to quickly
> deprecate and remove it (once the new stuff has been around for a while
> and works well) is a good hint that we should not put it in.
>
> But I do think that it would be useful, and it looks to be working well.
> What we can do is put it up under openjsse on github, so it is ready to
> go if people need it. This way it acts as interim insurance, is
> available for everyone (and e.g. for distros that want to bundle it) but
> does not contaminate the project with the long term legacy of a
> temporary bandaid...

We are on the same page, then.

>
>>>>
>>>> One thing that came to my mind to address this problem was having an
>>>> 'emergency 8u272 build' with all the security patches applied but
>>>> without the TLS 1.3 engine. In case things go horribly wrong, we can ask
>>>> our users to use that build until 8u282.
>
> That's definitely an alternative, but it also risks the long term
> bifurcation with two builds needed every quarter. i.e. of both builds
> are available in 8u272, most people may choose to go with the no-new-TLS
> mode to contain risk, and only people that actually want TLS 1.3 will
> adopt the new builds. We will then be faced with the need to keep
> building both every quarter for a while.
>

Let me clarify a bit the idea, because there is some misunderstanding. I
was not proposing to release or maintain both builds: only one at a time.

The 8u repository will have the new TLS engine pushed. We can release
8u272-build-<N> with new TLS engine and have 8u272-build-<N+1> with the
old TLS engine ready but unreleased.

If thing go okay, 8u272-build-<N+1> will be dropped without being ever
published.

If things go wrong -to the point that we have a major/blocker issue that
cannot be quickly resolved-, we release 8u272-build-<N+1> immediately as
the successor of 8u272-build-<N>.

That would give us 3 months to fix the problem and release 8u282 with
the new TLS engine.

Note: there cannot be much time between 8u272-build-<N> and
8u272-build-<N+1> because even if the change should be transparent for
most of the users, some of them may need to modify their applications
for backward compatibility.

I see a couple of downsides:

1) As @gnu_andrew pointed out, there may be dependencies that make
'backing out the new TLS engine patches' to generate build-<N+1> not
that trivial.

2) We need to somehow publish the source code upon which
8u272-build-<N+1> was built for license compliance reasons.

Regards,
Martin.-


From alexey at azul.com  Tue Jun 16 05:12:41 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 16 Jun 2020 05:12:41 +0000
Subject: [8u] RFR : TLSv1.3 protocol support
In-Reply-To: <0ae019ce-bd34-ad35-ef07-80a2ce99371c@redhat.com>
References: <B85DE79B-9FD1-49BC-8C2B-D293E8A61013@azul.com>
 <07083b85-1c69-923f-06a0-d896681a9977@redhat.com>
 <0ae019ce-bd34-ad35-ef07-80a2ce99371c@redhat.com>
Message-ID: <D646D431-0325-4824-AC90-7535BC8F3853@azul.com>

Hello Martin,

Thank you for summarising all related patches.

It seems two more issues are missed in the list :
JDK-8161973 : PKIXRevocationChecker.getSoftFailExceptions() not working
JDK-8242294: JSSE Client does not throw SSLException when an alert occurs during handshaking

Regards
Alexey

From neugens at redhat.com  Tue Jun 16 08:12:55 2020
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Jun 2020 10:12:55 +0200
Subject: RFR 8217647: [backport] JFR: recordings on 32-bit systems
 unreadable
In-Reply-To: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
Message-ID: <CAJwKKmb_uXUE1b6p=QrXVvAgqyUOpKmUe7Ohyc4OmKtuRTJWzg@mail.gmail.com>

Hi Denghui,

The patch looks good, I can't test on 32bit if all the results are
correct though, but I tested on 64 bit and all seems to be working
like usual.

Cheers,
Mario

On Tue, Jun 16, 2020 at 5:44 AM Denghui Dong
<denghui.ddh at alibaba-inc.com> wrote:
>
> Could I have a review of this backport?
>
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8217647
>
> Original fix from 11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
>
> Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
>
> Backport reasons:
> 1. Fix the unreadable problem on 32-bit in 8u
> 2. Make subsequent backport more smoothly
>
> The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:
>
>  a) Conflict in jfrRecorderService.cpp. Patch wants this:
>
> -static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> -  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
> -  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
> +static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> +  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
> +  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>    cw.reserve(sizeof(u4));
>    cw.write<u8>(EVENT_CHECKPOINT);
>    cw.write(JfrTicks::now());
> -  cw.write<jlong>((jlong)0);
> +  cw.write((int64_t)0);
>    cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
>    cw.write<bool>(false); // flushpoint
> -  cw.write<u4>((u4)1); // nof types in this checkpoint
> -  cw.write<u8>(type_id);
> -  const intptr_t number_of_elements_offset = cw.current_offset();
> +  cw.write((u4)1); // nof types in this checkpoint
> +  cw.write(type_id);
> +  const int64_t number_of_elements_offset = cw.current_offset();
>    cw.reserve(sizeof(u4));
>    return number_of_elements_offset;
>  }
>
>  ... but the 8u code is:
>
> static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
>   const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
>   const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>   cw.reserve(sizeof(u4));
>   cw.write<u8>(EVENT_CHECKPOINT);
>   cw.write(JfrTicks::now());
>   cw.write<jlong>((jlong)0);
>   cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
>   cw.write<bool>(false); // flushpoint
>   cw.write<u4>((u4)1); // nof types in this checkpoint
>   cw.write<u8>(type_id);
>   const intptr_t number_of_elements_offset = cw.current_offset();
>   cw.reserve(sizeof(u4));
>   return number_of_elements_offset;
> }
>
>  ... I did a manual adjustment:
>     cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);
>
>  b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:
>
>  template <typename BE, typename IE, typename WriterPolicyImpl>
>  inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
> -  be_write(*(uintptr_t*)&(value));
> +  be_write(*(u8*)&(value));
>  }
>
>  ... but the 8u code is:
>
> template <typename BE, typename IE, typename WriterPolicyImpl>
> inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
>   be_write(*(u8*)&(value));
> }
>
>  ... so I skipped it.
>
>  c) Build failure. Patch wants this in jfrRepository.cpp:
>
> +            log_info(jfr) ( // For user, should not be "jfr, system"
> +              "Unable to recover JFR data");
> +            break;
>
>  ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"
>
>
>  d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
>
> Thanks,
> Denghui Dong



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


From aph at redhat.com  Tue Jun 16 09:33:08 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 16 Jun 2020 10:33:08 +0100
Subject: [8u] RFR 8151788: NullPointerException from ntlm.Client.type3
In-Reply-To: <1e03882e-b9ef-69ae-5c80-2fa8782bb3cc@redhat.com>
References: <1e03882e-b9ef-69ae-5c80-2fa8782bb3cc@redhat.com>
Message-ID: <85bf593c-acb5-437f-36a7-0886d32f5c9f@redhat.com>

On 15/06/2020 22:05, Zhengyu Gu wrote:
> The original patch applies cleanly after file path change. However, I 
> modified the new test, removed its @modules annotation.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8151788
> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3b503af253a4
> 
> 
> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8151788-8u/webrev.00/
> 
> Test:
>    New test on Linux x86_64

OK, thanks.

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


From andrey at azul.com  Tue Jun 16 10:11:35 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 16 Jun 2020 13:11:35 +0300
Subject: RFR 8217647: [backport] JFR: recordings on 32-bit systems
 unreadable
In-Reply-To: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
Message-ID: <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>

Hi Denghui,

Just in case, do you actually observe any problems on 32-bit systems, or
it's just for a sake of unification of the code?

Andrey

On 16.06.2020 06:44, Denghui Dong wrote:
> Could I have a review of this backport?
>
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8217647
>
> Original fix from 11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
>
> Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
>
> Backport reasons:
> 1. Fix the unreadable problem on 32-bit in 8u
> 2. Make subsequent backport more smoothly
>
> The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:
>
>  a) Conflict in jfrRecorderService.cpp. Patch wants this:
>
> -static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> -  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
> -  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
> +static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> +  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
> +  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>    cw.reserve(sizeof(u4));
>    cw.write<u8>(EVENT_CHECKPOINT);
>    cw.write(JfrTicks::now());
> -  cw.write<jlong>((jlong)0);
> +  cw.write((int64_t)0);
>    cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
>    cw.write<bool>(false); // flushpoint
> -  cw.write<u4>((u4)1); // nof types in this checkpoint
> -  cw.write<u8>(type_id);
> -  const intptr_t number_of_elements_offset = cw.current_offset();
> +  cw.write((u4)1); // nof types in this checkpoint
> +  cw.write(type_id);
> +  const int64_t number_of_elements_offset = cw.current_offset();
>    cw.reserve(sizeof(u4));
>    return number_of_elements_offset;
>  }
>
>  ... but the 8u code is:
>
> static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
>   const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
>   const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>   cw.reserve(sizeof(u4));
>   cw.write<u8>(EVENT_CHECKPOINT);
>   cw.write(JfrTicks::now());
>   cw.write<jlong>((jlong)0);
>   cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
>   cw.write<bool>(false); // flushpoint
>   cw.write<u4>((u4)1); // nof types in this checkpoint
>   cw.write<u8>(type_id);
>   const intptr_t number_of_elements_offset = cw.current_offset();
>   cw.reserve(sizeof(u4));
>   return number_of_elements_offset;
> }
>
>  ... I did a manual adjustment: 
>     cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);
>
>  b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:
>
>  template <typename BE, typename IE, typename WriterPolicyImpl>
>  inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
> -  be_write(*(uintptr_t*)&(value));
> +  be_write(*(u8*)&(value));
>  }
>
>  ... but the 8u code is:
>
> template <typename BE, typename IE, typename WriterPolicyImpl>
> inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
>   be_write(*(u8*)&(value));
> }
>
>  ... so I skipped it.
>
>  c) Build failure. Patch wants this in jfrRepository.cpp:
>
> +            log_info(jfr) ( // For user, should not be "jfr, system"
> +              "Unable to recover JFR data");
> +            break;
>
>  ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"
>
>
>  d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
>
> Thanks,
> Denghui Dong


From denghui.ddh at alibaba-inc.com  Tue Jun 16 10:50:45 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Tue, 16 Jun 2020 18:50:45 +0800
Subject: =?UTF-8?B?UmU6IFJGUiA4MjE3NjQ3OiBbYmFja3BvcnRdIEpGUjogcmVjb3JkaW5ncyBvbiAzMi1iaXQg?=
 =?UTF-8?B?c3lzdGVtcyB1bnJlYWRhYmxl?=
In-Reply-To: <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>,
 <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>
Message-ID: <951f1745-e1e2-4c1f-a5f2-b34cc4003852.denghui.ddh@alibaba-inc.com>

Hi Andrey,

I haven't encountered this problem(I don't have any 32-bit environment).

For me, this patch is mainly for code unification, but I think this problem exists in 8u.

Denghui

------------------------------------------------------------------
From:Andrey Petushkov <andrey at azul.com>
Send Time:2020?6?16?(???) 18:11
To:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable

Hi Denghui,

Just in case, do you actually observe any problems on 32-bit systems, or
it's just for a sake of unification of the code?

Andrey

On 16.06.2020 06:44, Denghui Dong wrote:
> Could I have a review of this backport?
>
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8217647
>
> Original fix from 11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
>
> Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
>
> Backport reasons:
> 1. Fix the unreadable problem on 32-bit in 8u
> 2. Make subsequent backport more smoothly
>
> The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:
>
>  a) Conflict in jfrRecorderService.cpp. Patch wants this:
>
> -static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> -  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
> -  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
> +static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> +  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
> +  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>    cw.reserve(sizeof(u4));
>    cw.write<u8>(EVENT_CHECKPOINT);
>    cw.write(JfrTicks::now());
> -  cw.write<jlong>((jlong)0);
> +  cw.write((int64_t)0);
>    cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
>    cw.write<bool>(false); // flushpoint
> -  cw.write<u4>((u4)1); // nof types in this checkpoint
> -  cw.write<u8>(type_id);
> -  const intptr_t number_of_elements_offset = cw.current_offset();
> +  cw.write((u4)1); // nof types in this checkpoint
> +  cw.write(type_id);
> +  const int64_t number_of_elements_offset = cw.current_offset();
>    cw.reserve(sizeof(u4));
>    return number_of_elements_offset;
>  }
>
>  ... but the 8u code is:
>
> static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
>   const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
>   const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>   cw.reserve(sizeof(u4));
>   cw.write<u8>(EVENT_CHECKPOINT);
>   cw.write(JfrTicks::now());
>   cw.write<jlong>((jlong)0);
>   cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
>   cw.write<bool>(false); // flushpoint
>   cw.write<u4>((u4)1); // nof types in this checkpoint
>   cw.write<u8>(type_id);
>   const intptr_t number_of_elements_offset = cw.current_offset();
>   cw.reserve(sizeof(u4));
>   return number_of_elements_offset;
> }
>
>  ... I did a manual adjustment: 
>     cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);
>
>  b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:
>
>  template <typename BE, typename IE, typename WriterPolicyImpl>
>  inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
> -  be_write(*(uintptr_t*)&(value));
> +  be_write(*(u8*)&(value));
>  }
>
>  ... but the 8u code is:
>
> template <typename BE, typename IE, typename WriterPolicyImpl>
> inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
>   be_write(*(u8*)&(value));
> }
>
>  ... so I skipped it.
>
>  c) Build failure. Patch wants this in jfrRepository.cpp:
>
> +            log_info(jfr) ( // For user, should not be "jfr, system"
> +              "Unable to recover JFR data");
> +            break;
>
>  ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"
>
>
>  d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
>
> Thanks,
> Denghui Dong

From andrey at azul.com  Tue Jun 16 11:00:58 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 16 Jun 2020 14:00:58 +0300
Subject: RFR 8217647: [backport] JFR: recordings on 32-bit systems
 unreadable
In-Reply-To: <951f1745-e1e2-4c1f-a5f2-b34cc4003852.denghui.ddh@alibaba-inc.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
 <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>
 <951f1745-e1e2-4c1f-a5f2-b34cc4003852.denghui.ddh@alibaba-inc.com>
Message-ID: <db0c79bd-065b-131d-a43f-2c607342d044@azul.com>

Ok. I fully do support idea of code unification.
Just one note on the problem, it definitely has existed early on. During
backporting to 8u all known to Azul problems have been fixed (in all
open code bases which are relevant to 8u). Later, these problems were
addressed in upstream separately by the community, and what you're
backporting is what, I believe, these fixes in upstream brought. The
approach of addressing the problems is different between the two, hence
you see the difference and merge conflicts.
So in my understanding 8u codebase does not need this fix per se, but as
I said, it's beneficial to have it for the purpose of code unification
and simplification of further backports

Andrey

On 16.06.2020 13:50, Denghui Dong wrote:
> Hi?Andrey,
>
> I?haven't?encountered?this?problem(I don't?have any 32-bit?environment).
>
> For?me,?this?patch?is?mainly?for?code?unification, but I think this
> problem exists in 8u.
>
> Denghui
>
>     ------------------------------------------------------------------
>     From:Andrey Petushkov <andrey at azul.com>
>     Send Time:2020?6?16?(???) 18:11
>     To:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev
>     <jdk8u-dev at openjdk.java.net>
>     Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit
>     systems unreadable
>
>     Hi?Denghui,
>
>     Just?in?case,?do?you?actually?observe?any?problems?on?32-bit?systems,?or
>     it's?just?for?a?sake?of?unification?of?the?code?
>
>     Andrey
>
>     On?16.06.2020?06:44,?Denghui?Dong?wrote:
>     >?Could?I?have?a?review?of?this?backport?
>     >
>     >?Original?bug:
>     >???https://bugs.openjdk.java.net/browse/JDK-8217647
>     >
>     >?Original?fix?from?11u:
>     >???http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
>     >
>     >?Webrev:?http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
>     >
>     >?Backport?reasons:
>     >?1.?Fix?the?unreadable?problem?on?32-bit?in?8u
>     >?2.?Make?subsequent?backport?more?smoothly
>     >
>     >?The?patch?cannot?apply?to?8u?cleanly,?there?are?two?rejection?part?and?one?build?failure:
>     >
>     >??a)?Conflict?in?jfrRecorderService.cpp.?Patch?wants?this:
>     >
>     >?-static?intptr_t?write_checkpoint_event_prologue(JfrChunkWriter&?cw,?u8?type_id)?{
>     >?-??const?intptr_t?prev_cp_offset?=?cw.previous_checkpoint_offset();
>     >?-??const?intptr_t?prev_cp_relative_offset?=?0?==?prev_cp_offset???0?:?prev_cp_offset?-?cw.current_offset();
>     >?+static?int64_t?write_checkpoint_event_prologue(JfrChunkWriter&?cw,?u8?type_id)?{
>     >?+??const?int64_t?prev_cp_offset?=?cw.previous_checkpoint_offset();
>     >?+??const?int64_t?prev_cp_relative_offset?=?0?==?prev_cp_offset???0?:?prev_cp_offset?-?cw.current_offset();
>     >????cw.reserve(sizeof(u4));
>     >????cw.write<u8>(EVENT_CHECKPOINT);
>     >????cw.write(JfrTicks::now());
>     >?-??cw.write<jlong>((jlong)0);
>     >?+??cw.write((int64_t)0);
>     >????cw.write(prev_cp_relative_offset);?//?write?previous?checkpoint?offset?delta
>     >????cw.write<bool>(false);?//?flushpoint
>     >?-??cw.write<u4>((u4)1);?//?nof?types?in?this?checkpoint
>     >?-??cw.write<u8>(type_id);
>     >?-??const?intptr_t?number_of_elements_offset?=?cw.current_offset();
>     >?+??cw.write((u4)1);?//?nof?types?in?this?checkpoint
>     >?+??cw.write(type_id);
>     >?+??const?int64_t?number_of_elements_offset?=?cw.current_offset();
>     >????cw.reserve(sizeof(u4));
>     >????return?number_of_elements_offset;
>     >??}
>     >
>     >??...?but?the?8u?code?is:
>     >
>     >?static?intptr_t?write_checkpoint_event_prologue(JfrChunkWriter&?cw,?u8?type_id)?{
>     >???const?intptr_t?prev_cp_offset?=?cw.previous_checkpoint_offset();
>     >???const?intptr_t?prev_cp_relative_offset?=?0?==?prev_cp_offset???0?:?prev_cp_offset?-?cw.current_offset();
>     >???cw.reserve(sizeof(u4));
>     >???cw.write<u8>(EVENT_CHECKPOINT);
>     >???cw.write(JfrTicks::now());
>     >???cw.write<jlong>((jlong)0);
>     >???cw.write<jlong>((jlong)prev_cp_relative_offset);?//?write?previous?checkpoint?offset?delta
>     >???cw.write<bool>(false);?//?flushpoint
>     >???cw.write<u4>((u4)1);?//?nof?types?in?this?checkpoint
>     >???cw.write<u8>(type_id);
>     >???const?intptr_t?number_of_elements_offset?=?cw.current_offset();
>     >???cw.reserve(sizeof(u4));
>     >???return?number_of_elements_offset;
>     >?}
>     >
>     >??...?I?did?a?manual?adjustment:?
>     >?????cw.write<jlong>((jlong)prev_cp_relative_offset);?=>?cw.write(prev_cp_relative_offset);
>     >
>     >??b)?Conflict?in?jfrWriterHost.inline.hpp.?Patch?wants?this:
>     >
>     >??template?<typename?BE,?typename?IE,?typename?WriterPolicyImpl>
>     >??inline?void?WriterHost<BE,?IE,?WriterPolicyImpl>::write(double?value)?{
>     >?-??be_write(*(uintptr_t*)&(value));
>     >?+??be_write(*(u8*)&(value));
>     >??}
>     >
>     >??...?but?the?8u?code?is:
>     >
>     >?template?<typename?BE,?typename?IE,?typename?WriterPolicyImpl>
>     >?inline?void?WriterHost<BE,?IE,?WriterPolicyImpl>::write(double?value)?{
>     >???be_write(*(u8*)&(value));
>     >?}
>     >
>     >??...?so?I?skipped?it.
>     >
>     >??c)?Build?failure.?Patch?wants?this?in?jfrRepository.cpp:
>     >
>     >?+????????????log_info(jfr)?(?//?For?user,?should?not?be?"jfr,?system"
>     >?+??????????????"Unable?to?recover?JFR?data");
>     >?+????????????break;
>     >
>     >??...?but?8u?didn't?support?unified?logging,?so?I?added?"if?(LogJFR)?tty->print_cr("Unable?to?recover?JFR?data");"
>     >
>     >
>     >??d)?Other?Problem:?the?original?patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2)?also?modified?jfrChunkRotation.hpp?jfrChunkRotation.cpp?and?jfrJniMethod.cpp,?but?the?backport?patch?for?11u?ignored?them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
>     >
>     >?Thanks,
>     >?Denghui?Dong
>


From rwestrel at redhat.com  Tue Jun 16 11:22:58 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 16 Jun 2020 13:22:58 +0200
Subject: [8u] RFR: 8167615: Opensource unit/regression tests for JavaSound
Message-ID: <877dw7xnjh.fsf@redhat.com>


The patch applies cleanly but I had to change the path to a couple test
files:
test/javax/sound/midi/MidiSystem/testdata/conf/sound.properties to test/javax/sound/midi/MidiSystem/testdata/lib/conf/sound.properties
test/javax/sound/sampled/AudioSystem/testdata/conf/sound.properties to test/javax/sound/sampled/AudioSystem/testdata/lib/conf/sound.properties

so it the library code in 8u finds those files where it expects them.

For the record, the webrev:
http://cr.openjdk.java.net/~roland/8167615.8u/webrev.00/

Initial change:
https://bugs.openjdk.java.net/browse/JDK-8167615
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5445b9413d9d

I ran the entire javax/sound test suite and I see a few failures that I
can either reproduce with 11u or are part of the problem list.

Roland.


From neugens at redhat.com  Tue Jun 16 11:36:50 2020
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Jun 2020 13:36:50 +0200
Subject: RFR 8217647: [backport] JFR: recordings on 32-bit systems
 unreadable
In-Reply-To: <db0c79bd-065b-131d-a43f-2c607342d044@azul.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
 <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>
 <951f1745-e1e2-4c1f-a5f2-b34cc4003852.denghui.ddh@alibaba-inc.com>
 <db0c79bd-065b-131d-a43f-2c607342d044@azul.com>
Message-ID: <CAJwKKma12iYfXwVfULeyY2SGfQGRwVU-k=XsxH_kho4COJhO9A@mail.gmail.com>

On Tue, Jun 16, 2020 at 1:02 PM Andrey Petushkov <andrey at azul.com> wrote:
>
> Ok. I fully do support idea of code unification.
> Just one note on the problem, it definitely has existed early on. During
> backporting to 8u all known to Azul problems have been fixed (in all
> open code bases which are relevant to 8u). Later, these problems were
> addressed in upstream separately by the community, and what you're
> backporting is what, I believe, these fixes in upstream brought. The
> approach of addressing the problems is different between the two, hence
> you see the difference and merge conflicts.

I noticed this while reading the code as well, there are lots of
consolidation but some data types are already 64bits and the few
places where they would be truncated seem that were already addressed
before hand.

> So in my understanding 8u codebase does not need this fix per se, but as
> I said, it's beneficial to have it for the purpose of code unification
> and simplification of further backports

I can't test 32bit right now, if there are no pending issues and this
patch doesn't fix anything other than some code consolidation, then I
suggest to only push this in jdk8u-dev and skip the release train for
this round (i.e. no critical-fix label).

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 hubert.debordeaux at thalesgroup.com  Tue Jun 16 13:09:36 2020
From: hubert.debordeaux at thalesgroup.com (DEBORDEAUX Hubert)
Date: Tue, 16 Jun 2020 13:09:36 +0000
Subject: SunPKCS11 connection lost after Decrypt doFinal 
Message-ID: <PR2P264MB09276C496E823F3377F33ED4EC9D0@PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM>

Hello,

We did notice that, from JDK_8 232, the PKCS11 connection to a network HSM is closed after a decrypt() doFinal when no padding is used.
An issue had been created last December and it has been fixed since then.
Full history can be found at https://bugs.openjdk.java.net/browse/JDK-8235215

Unfortunately, this fix cannot be found in latest JDK 8 releases.

What is the process to promote or to ask for the promotion of a particular fix into the JDK 8 roadmap ?

Note: The JDK-8235215 fix has been added to the JDK 15 release and we did successfully test it.

Thanks for your answers.

Hubert

From mbalao at redhat.com  Tue Jun 16 14:50:07 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 16 Jun 2020 11:50:07 -0300
Subject: [8u] RFR : TLSv1.3 protocol support
In-Reply-To: <D646D431-0325-4824-AC90-7535BC8F3853@azul.com>
References: <B85DE79B-9FD1-49BC-8C2B-D293E8A61013@azul.com>
 <07083b85-1c69-923f-06a0-d896681a9977@redhat.com>
 <0ae019ce-bd34-ad35-ef07-80a2ce99371c@redhat.com>
 <D646D431-0325-4824-AC90-7535BC8F3853@azul.com>
Message-ID: <4bfef666-b649-f135-57e1-b72eda3fcb34@redhat.com>

On 6/16/20 2:12 AM, Alexey Bakhtin wrote:
> It seems two more issues are missed in the list :
> JDK-8161973 : PKIXRevocationChecker.getSoftFailExceptions() not working

Is that part of Step 1? If I remember correctly, 8161973 will be an
independent backport after Step 1.

> JDK-8242294: JSSE Client does not throw SSLException when an alert occurs during handshaking
> 

Good catch. I'll add it to the list of bugs to be backported later (not
in Step 1).

Updated lists below. Let me know if anything else.

Regards,
Martin.-


--

Step 1 (8245468) COVERED - 11.0.7
..............................

 * JDK-8196584: TLS 1.3 Implementation
 * JDK-8212885: TLS 1.3 resumed session does not retain peer certificate
chain
 * JDK-8211806: TLS 1.3 handshake server name indication is missing on a
session resume
 * JDK-8207009: TLS 1.3 half-close and synchronization issues
 * JDK-8211866: TLS 1.3 CertificateRequest message sometimes offers
disallowed signature algorithms
 * JDK-8210334: TLS 1.3 server fails if ClientHello doesn't have
pre_shared_key and psk_key_exchange_modes
 * JDK-8214688: TLS 1.3 session resumption with hello retry request
failed with "illegal_parameter"
 * JDK-8210846: TLSv.1.3 interop problems with OpenSSL 1.1.1 when used
on the client side with mutual auth
 * JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored
in PKCS11
 * JDK-8221253: TLSv1.3 may generate TLSInnerPlainText longer than
2^14+1 bytes
 * JDK-8216045: The size of key_exchange may be wrong on FFDHE
 * JDK-8209965: The "supported_groups" extension in ServerHellos
 * JDK-8214098: sun.security.ssl.HandshakeHash.T12HandshakeHash
constructor check backwards.
 * JDK-8208166: Still unable to use custom SSLEngine with default
TrustManagerFactory after JDK-8207029
 * JDK-8214339: SSLSocketImpl erroneously wraps SocketException
 * JDK-8207237: SSLSocket#setEnabledCipherSuites is accepting empty string
 * JDK-8216326: SSLSocket stream close() does not close the associated
socket
 * JDK-8206355: SSLSessionImpl.getLocalPrincipal() throws NPE
 * JDK-8207317: SSLEngine negotiation fail exception behavior changed
from fail-fast to fail-lazy
 * JDK-8145854: SSLContextImpl.statusResponseManager should be generated
if required
 * JDK-8214129: SSL session resumption/SNI with TLS1.2 causes
StackOverflowError
 * JDK-8207223: SSL Handshake failures are reported with more generic
SSLException
 * JDK-8210989: RSASSA-PSS certificate cannot be selected for client
auth on TLSv1.2
 * JDK-8165275: Replace the reflective call to the implUpdate method in
HandshakeMessage::digestKey
 * JDK-8206176: Remove the temporary tls13VN field
 * JDK-8213202: Possible race condition in TLS 1.3 session resumption
 * JDK-8213782: NullPointerException in
sun.security.ssl.OutputRecord.changeWriteCiphers
 * JDK-8209916: NPE in SupportedGroupsExtension
 * JDK-8210974: No extensions debug log for ClientHello
 * JDK-8214321: Misleading code in SSLCipher
 * JDK-8236039: JSSE Client does not accept status_request extension in
CertificateRequest messages for TLS 1.3
 * JDK-8028518: Increase the priorities of GCM cipher suites
 * JDK-8212738: Incorrectly named signature scheme ecdsa_secp512r1_sha512
 * JDK-8215524: Finished message validation failure should be
decrypt_error alert
 * JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl
 * JDK-8215790: Delegated task created by SSLEngine throws
java.nio.BufferUnderflowException
 * JDK-8219389: Delegated task created by SSLEngine throws
BufferUnderflowException
 * JDK-8225766: Curve in certificate should not affect signature scheme
when using TLSv1.3
 * JDK-8206929: Check session context for TLS 1.3 session resumption
 * JDK-8229733: TLS message handling improvements
 * JDK-8207029: Unable to use custom SSLEngine with default
TrustManagerFactory after updating to JDK 11 b21
 * JDK-8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after
removing sunec.dll
 * JDK-8223482: Unsupported ciphersuites may be offered by a TLS client
 * JDK-4919790: Errors in alert ssl message does not reflect the actual
certificate status
 * JDK-8218889: Improperly use of the Optional API

MISSING 11.0.8 - important
..............................

 * JDK-8239798: SSLSocket closes socket both socket endpoints on a
SocketTimeoutException
 * JDK-8223940: Private key not supported by chosen signature algorithm
 * JDK-8211339: NPE during SSL handshake caused by HostnameChecker
 * JDK-8242141: New System Properties to configure the TLS signature schemes
 * JDK-8215711: Missing key_share extension for (EC)DHE key exchange
should alert missing_extension
 * JDK-8237474: Default SSLEngine should create in server role
 * JDK-8234728: Some security tests should support TLSv1.3
 * JDK-8234725: sun/security/ssl/SSLContextImpl tests support TLSv1.3
 * JDK-8205653:
test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and
RmiSslBootstrapTest.sh fail with handshake_failure
 * JDK-8209333: Socket reset issue for TLS 1.3 socket close
 * JDK-8228757: Fail fast if the handshake type is unknown
 * JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions
 * JDK-8235311: Tag mismatch may alert bad_record_mac
 * JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3
 * JDK-8235874: The ordering of Cipher Suites is not maintained provided
through "jdk.tls.client.cipherSuites" and "jdk.tls.server.cipherSuites"
system property.
 * JDK-8205111: Develop new Test to verify different key types for
supported TLS protocols.
 * JDK-8235183: Remove the "HACK CODE" in comment
 * JDK-8242294: JSSE Client does not throw SSLException when an alert
occurs during handshaking

MISSING 11.0.8 - not SSL strictly but related
..............................

 * JDK-7092821: java.security.Provider.getService() is synchronized and
became scalability bottleneck
 * JDK-8148188: Enhance the security libraries to record events of interest


From adam.farley at uk.ibm.com  Tue Jun 16 15:41:04 2020
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 16 Jun 2020 16:41:04 +0100
Subject: RFR: JDK-8229378: jdwp library loader in linker_md.c quietly
 truncates on buffer overflow
Message-ID: <OFDD2D65E2.AE5E996B-ON00258589.004DDC97-80258589.00562900@notes.na.collabserv.com>

Hello All,

Is this the correct list to request a review on a backport?

This one has been waiting for acceptance/rejection for a while now.

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

Best Regards

Adam Farley 
IBM Runtimes

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From sgehwolf at redhat.com  Tue Jun 16 16:02:12 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 16 Jun 2020 18:02:12 +0200
Subject: RFR: JDK-8229378: jdwp library loader in linker_md.c quietly
 truncates on buffer overflow
In-Reply-To: <OFDD2D65E2.AE5E996B-ON00258589.004DDC97-80258589.00562900@notes.na.collabserv.com>
References: <OFDD2D65E2.AE5E996B-ON00258589.004DDC97-80258589.00562900@notes.na.collabserv.com>
Message-ID: <32d8ff68cada537cd8603c824f2bb640a9433c92.camel@redhat.com>

Hi Adam,

On Tue, 2020-06-16 at 16:41 +0100, Adam Farley8 wrote:
> Hello All,
> 
> Is this the correct list to request a review on a backport?
> 
> This one has been waiting for acceptance/rejection for a while now.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229378

It's the right list, yes.

I'll look at it today. FWIW, the bug has jdk11u-fix-yes for a while now
but I don't see a push to jdk11u-dev. Intentional?

Thanks,
Severin


From alexey at azul.com  Tue Jun 16 18:07:51 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 16 Jun 2020 18:07:51 +0000
Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support
 according to RFC-2712
In-Reply-To: <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com>
References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com>
 <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com>
Message-ID: <DE68AD11-4147-4563-88F2-D35F072BB867@azul.com>

Hello Martin,

Thank you for review.
Please see my answer below.

Updated webrev at: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245474/webrev.v1/

Regards Alexey

> On 16 Jun 2020, at 03:10, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 5/21/20 11:12 AM, Alexey Bakhtin wrote:
>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u
> 
> Hi Alexey,
> 
> A few comments / questions regarding Step 7 (8245474) v0:
> 
> * Do we have tests covering this functionality?
> 
> * CipherSuite.java
> 
Yes. The tests are located in sun/security/krb5/auto directory
It is part of JDK-8245681 subtask.
Also, some regular ciphersuite tests also test TLS_KRB cipher suites

>  * TLS_KRB5_WITH_3DES_EDE_CBC_SHA
>   * Shouldn't this be enabled for protocols previous to TLS 1.2 too?
>    * Note: I'm okay with TLS 1.2 being the upper limit.
Yes. You are right. Fixed to enable for TLS_KRB for early TLS versions
Maximum supported version is TLSv1.2
>   * Shouldn't we check whether SunJSSE::isFIPS is true or not before
> setting isDefaultEnabled to 'true'?
>    * I'm more inclined to set the isDefaultEnabled value to 'false',
> even while not in FIPS mode. I've seen many ciphersuites which were 'N'
> in the old TLS engine and are now isDefaultEnabled == false. Even if we
> change the 'default behavior', I believe we should disable everything
> not secure by default. That's precisely one of the points of upgrading
> the TLS engine, and what we are doing for other non-KRB5 ciphersuites
> already (since Step 1). What do you think?
>     * Looks to me that jdk.tls.client.cipherSuites and
> jdk.tls.server.cipherSuites properties can be used to override the default
>      * We should document in a CSR all these changes so users can
> understand how the default configuration is different from the previous
> and how to enable a 'non-secure' but 'backward-compatible' behavior.
>     * Please have a look at the tests that may be affected by any of
> these changes.
> 
Agree. These suites should be disabled by default. Fixed.
Also, the tests will be updated to enable TLS_KRB5 suites where it is required.

>  * With the previous comments in mind, please have a look at the other
> KRB5 ciphersuites added.

Sure. All TLS_KRB5 cipher suites are updated accordingly
> 
> * ClientHello.java
> 
>  * I've seen there is a copyright line addition. If you want to keep it
> there, please get approval from 8u maintainers because I'm not sure of
> the policy there.
>   * Same comment for SSLKeyExchange.java, SSLSessionImpl.java and
> ServerHello.java
>   * This comment does not apply to new files, which look okay to me
I've added copyrights to the files with new TLS_KRB5 code, not a backport.
But sure, I?ll check if it is possible to add copyright lines to these files

> 
>  * I suggest to be explicit in what we import, instead of "java.security.*?
OK. Added explicit declaration
> 
>  * I've seen a double-spacing in "} else  if (suite.keyExchange ==
> K_KRB5 ||?
Fixed
> 
>  * Are changes needed for previous versions of the protocol? TLS 1.1,
> TLS 1.0, etc.
> 
T12ClientHelloConsumer is used for TLSv1.2 and prior protocol versions.
I think it is right place for all non-TLSv1.3 protocols

>  * I suggest to follow the pattern. Create a new condition of type "if
> (resumingSession && ..." instead of hooking "Validate that the cached
> cipher suite" one

OK. Updated the code to follow the pattern.

> 
>  * No gain in inserting a newline after ?return?
Fixed.
> 
> * ServerHello.java
> 
>  * Are changes needed for previous versions of the protocol? TLS 1.1,
> TLS 1.0, etc.

T12ServerHelloConsumer is used for TLSv1.2 and prior protocol versions.
I think it is right place for all non-TLSv1.3 protocols
> 
> * HandshakeContext.java
> 
>  * I suggest to move sun/security/ssl/krb5/* files to sun/security/ssl
> so we can keep HandshakeContext and other classes visibility unchanged.
> This change will probably eliminate the need to add getMajor and
> getMinor methods in ProtocolVersion, as well as changing valueOf method
> visibility.
> 
Separation of the Kerberos functionality was done intentionally.
JDK8 compact profile1 does not include Kerberos API and implementation.
So, such separation allows to detect Kerberos presence at runtime
and support TLS_KRB cipher suites if implementation exist only.
Also, this is a reason we have different classes: KerberosClientKeyExchange,
KerberosClientKeyExchangeImpl and KrbClientKeyExchange
We can not merge them together without breaking compact profile.
I?ll try to make KrbClientKeyExchange more similar to template but
proxy and delegation classes are still required.
This issue and listed below are not included in updated webrev.

> * KrbClientKeyExchange.java
> 
>  * Can we make it more similar to DHClientKeyExchange.java /
> ECDHClientKeyExchange.java / RSAClientKeyExchange.java?
>   * I.e.: can we make the class final? can we have analogous comments
> in the same locations? can we refer to the constructor through
> KrbClientKeyExchangeConsumer instead of
> KrbClientKeyExchange.KrbClientKeyExchangeConsumer? etc. None of these
> examples are critical but I wish we could stick to the 'template' as
> much as possible. More on this below.
> 
> * Why do we have KerberosClientKeyExchange.java and
> KrbClientKeyExchange.java files?
>  * I see that for other key exchange methods there is only one file,
> containing the class that inherits from HandshakeMessage. This makes me
> think that KerberosClientKeyExchange class should probably be renamed to
> KrbClientKeyExchangeMessage (having KerberosClientKeyExchange and
> KrbClientKeyExchange classes simulateneously looks confusing to me and
> does not follow the previous *ClientKeyExchange template).
> 
> * KerberosClientKeyExchangeImpl.java
>  * I wonder if it makes sense to have a separate "Impl" class. None of
> the other key exchange methods are designed this way. I don't see how
> KerberosClientKeyExchange::implClass could be assigned to null or to
> something different than KerberosClientKeyExchangeImpl class. I could
> track this to 6885204 and 6894643. Unless there is a good reason, I
> suggest to get rid of this complexity and stick to the 'template'.
> 
> As a general criteria, I suggest to adapt-to/do-not-modify the new TLS
> engine over keeping the old files/code unchanged. Looks to me that
> handling this as a new feature is easier and more clear to review. This
> would be a different strategy to what we have been doing in previous
> Steps, and I see two reasons: 1) we are not re-introducing a specific
> change because the TLS KRB5 has been in the old TLS engine since the
> beginning of OpenJDK -so this cannot be a patch vs patch review-, and 2)
> it's better for clarity and consistency to analyze this feature in the
> context of the new engine, as an instance of a key exchange method such
> as RSA, DH, etc.
> 
> There may be more comments but wish we could focus on these things
> first. Thus, I expect at least a couple of iterations more.
> 
> Please feel free to comment / argue on any of the previous points before
> working on a new webrev, so we are in the same page first.
> 
> Thanks,
> Martin.-
> 
> 


From neugens at redhat.com  Tue Jun 16 19:53:21 2020
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Jun 2020 21:53:21 +0200
Subject: RFR: 8220293: Deadlock in JFR string pool
In-Reply-To: <b75f37cf-e4c4-d804-b666-4963fc1e1474@azul.com>
References: <b75f37cf-e4c4-d804-b666-4963fc1e1474@azul.com>
Message-ID: <CAJwKKmYYYUuwd62Hiw6XLeLyuZWnL=2cQJtLLyiFHNrUO7WxsA@mail.gmail.com>

Adding Andrew for reference.

I already reviewed this offline I think the patch is good to go, I
recommend getting it in the release train.

Cheers,
Mario

On Tuesday, June 16, 2020, Andrey Petushkov <andrey at azul.com> wrote:

> Dear All,
>
> As suggested by Mario may I ask to include the backport of the
> https://bugs.openjdk.java.net/browse/JDK-8220293 into 8u262 (that is,
> critical request). The reason is that this is single severe (VM
> deadlock) JFR bug we are aware of
> The patch applies cleanly, except for file locations change. Just in
> case here is the webrev https://cr.openjdk.java.net/~apetushkov/8220293/
> (one actual code change is .hpp guard macro name change due to file
> location change)
>
> Verified by the test in the bug (deadlock in about 1 minute without the
> fix, running fine for about 15 minutes a few times with the fix)
>
> Thanks,
> Andrey
>
>

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

From andrey at azul.com  Tue Jun 16 18:12:39 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Tue, 16 Jun 2020 21:12:39 +0300
Subject: RFR: 8220293: Deadlock in JFR string pool
Message-ID: <b75f37cf-e4c4-d804-b666-4963fc1e1474@azul.com>

Dear All,

As suggested by Mario may I ask to include the backport of the
https://bugs.openjdk.java.net/browse/JDK-8220293 into 8u262 (that is,
critical request). The reason is that this is single severe (VM
deadlock) JFR bug we are aware of
The patch applies cleanly, except for file locations change. Just in
case here is the webrev https://cr.openjdk.java.net/~apetushkov/8220293/
(one actual code change is .hpp guard macro name change due to file
location change)

Verified by the test in the bug (deadlock in about 1 minute without the
fix, running fine for about 15 minutes a few times with the fix)

Thanks,
Andrey


From zgu at redhat.com  Tue Jun 16 21:09:04 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 16 Jun 2020 17:09:04 -0400
Subject: [8u] RFR 8183349: Better cleanup for
 jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and
 WriteAfterAbort.java
Message-ID: <c9219c97-69c2-74a0-95b3-f33338e51426@redhat.com>

Please review this backport for parity with Oracle 8u271.

The original patch does not apply cleanly. The conflicts are minor, as 
8u version of CanWriteSequence.test() method format is slightly off.

Original bug:  https://bugs.openjdk.java.net/browse/JDK-8183349
Original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/93b7bd25273e

8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8183349-8u/webrev.00/

Test:
   Passed both tests on Linux x86_64


Thanks,

-Zhengyu


From gnu.andrew at redhat.com  Tue Jun 16 22:37:13 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 16 Jun 2020 23:37:13 +0100
Subject: SunPKCS11 connection lost after Decrypt doFinal
In-Reply-To: <PR2P264MB09276C496E823F3377F33ED4EC9D0@PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM>
References: <PR2P264MB09276C496E823F3377F33ED4EC9D0@PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com>



On 16/06/2020 14:09, DEBORDEAUX Hubert wrote:
> Hello,
> 
> We did notice that, from JDK_8 232, the PKCS11 connection to a network HSM is closed after a decrypt() doFinal when no padding is used.
> An issue had been created last December and it has been fixed since then.
> Full history can be found at https://bugs.openjdk.java.net/browse/JDK-8235215
> 
> Unfortunately, this fix cannot be found in latest JDK 8 releases.
> 
> What is the process to promote or to ask for the promotion of a particular fix into the JDK 8 roadmap ?
> 
> Note: The JDK-8235215 fix has been added to the JDK 15 release and we did successfully test it.
> 
> Thanks for your answers.
> 
> Hubert
> 

According to the bug, JDK-8235215, it was marked as a duplicate of
JDK-6946830. 6946830 was resolved in 8u232-b01 nearly a year ago.

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

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Tue Jun 16 23:21:20 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Jun 2020 00:21:20 +0100
Subject: RFR: 8220293: Deadlock in JFR string pool
In-Reply-To: <b75f37cf-e4c4-d804-b666-4963fc1e1474@azul.com>
References: <b75f37cf-e4c4-d804-b666-4963fc1e1474@azul.com>
Message-ID: <10c43eae-1330-6b9c-730b-e289e01f2ac4@redhat.com>



On 16/06/2020 19:12, Andrey Petushkov wrote:
> Dear All,
> 
> As suggested by Mario may I ask to include the backport of the
> https://bugs.openjdk.java.net/browse/JDK-8220293 into 8u262 (that is,
> critical request). The reason is that this is single severe (VM
> deadlock) JFR bug we are aware of
> The patch applies cleanly, except for file locations change. Just in
> case here is the webrev https://cr.openjdk.java.net/~apetushkov/8220293/
> (one actual code change is .hpp guard macro name change due to file
> location change)

This is confusing. Is the 8u patch different or not?

Shuffling the 11u changeset gave me the same patch as in your webrev,
and that applied to 8u cleanly, so I'm inclined to think no changes are
necessary here.

> 
> Verified by the test in the bug (deadlock in about 1 minute without the
> fix, running fine for about 15 minutes a few times with the fix)
> 
> Thanks,
> Andrey
> 

Approved for 8u262, assuming it is a clean backport.

Thanks,
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Tue Jun 16 23:43:54 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Jun 2020 00:43:54 +0100
Subject: [8u] RFR 8183349: Better cleanup for
 jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and
 WriteAfterAbort.java
In-Reply-To: <c9219c97-69c2-74a0-95b3-f33338e51426@redhat.com>
References: <c9219c97-69c2-74a0-95b3-f33338e51426@redhat.com>
Message-ID: <658073af-3313-61e5-7f42-f6889f53774f@redhat.com>



On 16/06/2020 22:09, Zhengyu Gu wrote:
> Please review this backport for parity with Oracle 8u271.
> 
> The original patch does not apply cleanly. The conflicts are minor, as
> 8u version of CanWriteSequence.test() method format is slightly off.
> 
> Original bug:? https://bugs.openjdk.java.net/browse/JDK-8183349
> Original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/93b7bd25273e
> 
> 8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8183349-8u/webrev.00/
> 
> Test:
> ? Passed both tests on Linux x86_64
> 
> 
> Thanks,
> 
> -Zhengyu
> 

Where are the indentation differences coming from in this patch? The
only difference between the 8u and 10u version of this file prior to the
patch is the latter has a newline at the end.

The attached is what I get from backporting the 11u changeset to 8u. It
is nearly identical to the 11u version.

Thanks,
-- 
Andrew :)

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

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
diff --git a/test/javax/imageio/plugins/shared/CanWriteSequence.java b/test/javax/imageio/plugins/shared/CanWriteSequence.java
--- a/test/javax/imageio/plugins/shared/CanWriteSequence.java
+++ b/test/javax/imageio/plugins/shared/CanWriteSequence.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -23,6 +23,7 @@
 
 import java.io.File;
 import java.io.FileOutputStream;
+import java.nio.file.Files;
 import java.util.Iterator;
 
 import javax.imageio.ImageIO;
@@ -34,11 +35,18 @@
 
 /**
  * @test
- * @bug 4958064
- * @author Sergey Bylokhov
+ * @bug     4958064 8183349
+ * @summary Test verifies that when we try to forcefully run
+ *          prepareWriteSequence() where it is not supported
+ *          will ImageIO throws an UnsupportedOperationException
+ *          or not.
+ * @run     main CanWriteSequence
  */
 public final class CanWriteSequence {
 
+    private static File file;
+    private static FileOutputStream fos;
+
     public static void main(final String[] args) throws Exception {
         final IIORegistry registry = IIORegistry.getDefaultInstance();
         final Iterator<ImageWriterSpi> iter =
@@ -54,25 +62,32 @@
     }
 
     private static void test(final ImageWriter writer) throws Exception {
-        final File file = File.createTempFile("temp", ".img");
-        file.deleteOnExit();
-        final FileOutputStream fos = new FileOutputStream(file);
-        final ImageOutputStream ios = ImageIO.createImageOutputStream(fos);
-        writer.setOutput(ios);
-        final IIOMetadata data = writer.getDefaultStreamMetadata(null);
+        try {
+            file = File.createTempFile("temp", ".img");
+            fos = new FileOutputStream(file);
+            final ImageOutputStream ios = ImageIO.createImageOutputStream(fos);
+            writer.setOutput(ios);
+            final IIOMetadata data = writer.getDefaultStreamMetadata(null);
 
-        if (writer.canWriteSequence()) {
-            writer.prepareWriteSequence(data);
-        } else {
-            try {
+            if (writer.canWriteSequence()) {
                 writer.prepareWriteSequence(data);
-                throw new RuntimeException(
-                        "UnsupportedOperationException was not thrown");
-            } catch (final UnsupportedOperationException ignored) {
+            } else {
+                try {
+                    writer.prepareWriteSequence(data);
+                    throw new RuntimeException(
+                            "UnsupportedOperationException was not thrown");
+                } catch (final UnsupportedOperationException ignored) {
                 // expected
+                }
+            }
+        } finally {
+            writer.dispose();
+            if (file != null) {
+                if (fos != null) {
+                    fos.close();
+                }
+                Files.delete(file.toPath());
             }
         }
-        writer.dispose();
-        ios.close();
     }
-}
\ No newline at end of file
+}
diff --git a/test/javax/imageio/plugins/shared/WriteAfterAbort.java b/test/javax/imageio/plugins/shared/WriteAfterAbort.java
--- a/test/javax/imageio/plugins/shared/WriteAfterAbort.java
+++ b/test/javax/imageio/plugins/shared/WriteAfterAbort.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -29,6 +29,7 @@
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.util.Iterator;
+import java.nio.file.Files;
 
 import javax.imageio.ImageIO;
 import javax.imageio.ImageWriter;
@@ -41,9 +42,9 @@
 
 /**
  * @test
- * @bug 4952954
+ * @bug     4952954 8183349
  * @summary abortFlag must be cleared for every ImageWriter.write operation
- * @author Sergey Bylokhov
+ * @run     main WriteAfterAbort
  */
 public final class WriteAfterAbort implements IIOWriteProgressListener {
 
@@ -54,73 +55,85 @@
     private volatile boolean isStartedCalled;
     private static final int WIDTH = 100;
     private static final int HEIGHT = 100;
+    private static FileOutputStream fos;
+    private static File file;
 
     private void test(final ImageWriter writer) throws IOException {
-        // Image initialization
-        final BufferedImage imageWrite = new BufferedImage(WIDTH, HEIGHT,
-                                                           TYPE_BYTE_BINARY);
-        final Graphics2D g = imageWrite.createGraphics();
-        g.setColor(Color.WHITE);
-        g.fillRect(0, 0, WIDTH, HEIGHT);
-        g.dispose();
+        try {
+            // Image initialization
+            final BufferedImage imageWrite =
+                    new BufferedImage(WIDTH, HEIGHT, TYPE_BYTE_BINARY);
+            final Graphics2D g = imageWrite.createGraphics();
+            g.setColor(Color.WHITE);
+            g.fillRect(0, 0, WIDTH, HEIGHT);
+            g.dispose();
+
+            // File initialization
+            file = File.createTempFile("temp", ".img");
+            fos = new SkipWriteOnAbortOutputStream(file);
+            final ImageOutputStream ios = ImageIO.createImageOutputStream(fos);
+            writer.setOutput(ios);
+            writer.addIIOWriteProgressListener(this);
 
-        // File initialization
-        final File file = File.createTempFile("temp", ".img");
-        file.deleteOnExit();
-        final FileOutputStream fos = new SkipWriteOnAbortOutputStream(file);
-        final ImageOutputStream ios = ImageIO.createImageOutputStream(fos);
-        writer.setOutput(ios);
-        writer.addIIOWriteProgressListener(this);
+            // This write will be aborted, and file will not be touched
+            writer.write(imageWrite);
+            if (!isStartedCalled) {
+                throw new RuntimeException("Started should be called");
+            }
+            if (!isProgressCalled) {
+                throw new RuntimeException("Progress should be called");
+            }
+            if (!isAbortCalled) {
+                throw new RuntimeException("Abort should be called");
+            }
+            if (isCompleteCalled) {
+                throw new RuntimeException("Complete should not be called");
+            }
+            // Flush aborted data
+            ios.flush();
 
-        // This write will be aborted, and file will not be touched
-        writer.write(imageWrite);
-        if (!isStartedCalled) {
-            throw new RuntimeException("Started should be called");
-        }
-        if (!isProgressCalled) {
-            throw new RuntimeException("Progress should be called");
-        }
-        if (!isAbortCalled) {
-            throw new RuntimeException("Abort should be called");
-        }
-        if (isCompleteCalled) {
-            throw new RuntimeException("Complete should not be called");
-        }
-        // Flush aborted data
-        ios.flush();
+            /*
+             * This write should be completed successfully and the file should
+             * contain correct image data.
+             */
+            abortFlag = false;
+            isAbortCalled = false;
+            isCompleteCalled = false;
+            isProgressCalled = false;
+            isStartedCalled = false;
+            writer.write(imageWrite);
 
-        // This write should be completed successfully and the file should
-        // contain correct image data.
-        abortFlag = false;
-        isAbortCalled = false;
-        isCompleteCalled = false;
-        isProgressCalled = false;
-        isStartedCalled = false;
-        writer.write(imageWrite);
+            if (!isStartedCalled) {
+                throw new RuntimeException("Started should be called");
+            }
+            if (!isProgressCalled) {
+                throw new RuntimeException("Progress should be called");
+            }
+            if (isAbortCalled) {
+                throw new RuntimeException("Abort should not be called");
+            }
+            if (!isCompleteCalled) {
+                throw new RuntimeException("Complete should be called");
+            }
+            ios.close();
 
-        if (!isStartedCalled) {
-            throw new RuntimeException("Started should be called");
-        }
-        if (!isProgressCalled) {
-            throw new RuntimeException("Progress should be called");
-        }
-        if (isAbortCalled) {
-            throw new RuntimeException("Abort should not be called");
-        }
-        if (!isCompleteCalled) {
-            throw new RuntimeException("Complete should be called");
-        }
-        writer.dispose();
-        ios.close();
-
-        // Validates content of the file.
-        final BufferedImage imageRead = ImageIO.read(file);
-        for (int x = 0; x < WIDTH; ++x) {
-            for (int y = 0; y < HEIGHT; ++y) {
-                if (imageRead.getRGB(x, y) != imageWrite.getRGB(x, y)) {
-                    throw new RuntimeException("Test failed.");
+            // Validates content of the file.
+            final BufferedImage imageRead = ImageIO.read(file);
+            for (int x = 0; x < WIDTH; ++x) {
+                for (int y = 0; y < HEIGHT; ++y) {
+                    if (imageRead.getRGB(x, y) != imageWrite.getRGB(x, y)) {
+                        throw new RuntimeException("Test failed.");
+                    }
                 }
             }
+        } finally {
+            writer.dispose();
+            if (file != null) {
+                if (fos != null) {
+                    fos.close();
+                }
+                Files.delete(file.toPath());
+            }
         }
     }
 

From zgu at redhat.com  Wed Jun 17 00:48:16 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 16 Jun 2020 20:48:16 -0400
Subject: [8u] RFR 8183349: Better cleanup for
 jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and
 WriteAfterAbort.java
In-Reply-To: <658073af-3313-61e5-7f42-f6889f53774f@redhat.com>
References: <c9219c97-69c2-74a0-95b3-f33338e51426@redhat.com>
 <658073af-3313-61e5-7f42-f6889f53774f@redhat.com>
Message-ID: <636bc897-f52a-c3ec-badf-765e502d1181@redhat.com>



On 6/16/20 7:43 PM, Andrew Hughes wrote:
> 
> 
> On 16/06/2020 22:09, Zhengyu Gu wrote:
>> Please review this backport for parity with Oracle 8u271.
>>
>> The original patch does not apply cleanly. The conflicts are minor, as
>> 8u version of CanWriteSequence.test() method format is slightly off.
>>
>> Original bug:? https://bugs.openjdk.java.net/browse/JDK-8183349
>> Original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/93b7bd25273e
>>
>> 8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8183349-8u/webrev.00/
>>
>> Test:
>>  ? Passed both tests on Linux x86_64
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
> 
> Where are the indentation differences coming from in this patch? The
> only difference between the 8u and 10u version of this file prior to the
> patch is the latter has a newline at the end.
>
Right. Adding a newline in 8u version, then patch applied cleanly.

Do I still need a review?

Thanks,

-Zhengyu


> The attached is what I get from backporting the 11u changeset to 8u. It
> is nearly identical to the 11u version.
> 
> Thanks,
> 


From valerie.peng at oracle.com  Wed Jun 17 04:24:09 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 16 Jun 2020 21:24:09 -0700
Subject: SunPKCS11 connection lost after Decrypt doFinal
In-Reply-To: <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com>
References: <PR2P264MB09276C496E823F3377F33ED4EC9D0@PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM>
 <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com>
Message-ID: <073918b1-75d1-305e-5054-c663aa360306@oracle.com>

Well, JDK-8235215 is relevant to JDK-6946830 but not a duplicate of it.

I should have added a duplicate-of-issue link to make it clear - 
JDK-8235215 is closed as a duplicate of JDK-8236512.

Sorry for the confusion and hope all is clear now.

Thanks,
Valerie

On 6/16/2020 3:37 PM, Andrew Hughes wrote:
>
> On 16/06/2020 14:09, DEBORDEAUX Hubert wrote:
>> Hello,
>>
>> We did notice that, from JDK_8 232, the PKCS11 connection to a network HSM is closed after a decrypt() doFinal when no padding is used.
>> An issue had been created last December and it has been fixed since then.
>> Full history can be found at https://bugs.openjdk.java.net/browse/JDK-8235215
>>
>> Unfortunately, this fix cannot be found in latest JDK 8 releases.
>>
>> What is the process to promote or to ask for the promotion of a particular fix into the JDK 8 roadmap ?
>>
>> Note: The JDK-8235215 fix has been added to the JDK 15 release and we did successfully test it.
>>
>> Thanks for your answers.
>>
>> Hubert
>>
> According to the bug, JDK-8235215, it was marked as a duplicate of
> JDK-6946830. 6946830 was resolved in 8u232-b01 nearly a year ago.
>
> https://bugs.openjdk.java.net/browse/JDK-6946830
>
> Thanks,

From denghui.ddh at alibaba-inc.com  Wed Jun 17 07:47:07 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Wed, 17 Jun 2020 15:47:07 +0800
Subject: =?UTF-8?B?UmU6IFJGUiA4MjE3NjQ3OiBbYmFja3BvcnRdIEpGUjogcmVjb3JkaW5ncyBvbiAzMi1iaXQg?=
 =?UTF-8?B?c3lzdGVtcyB1bnJlYWRhYmxl?=
In-Reply-To: <CAJwKKma12iYfXwVfULeyY2SGfQGRwVU-k=XsxH_kho4COJhO9A@mail.gmail.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
 <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>
 <951f1745-e1e2-4c1f-a5f2-b34cc4003852.denghui.ddh@alibaba-inc.com>
 <db0c79bd-065b-131d-a43f-2c607342d044@azul.com>,
 <CAJwKKma12iYfXwVfULeyY2SGfQGRwVU-k=XsxH_kho4COJhO9A@mail.gmail.com>
Message-ID: <f82593ea-2663-4bbd-9731-ad8490012726.denghui.ddh@alibaba-inc.com>

In fact, the main reason I backport this issue to 8u is to make the backport of JDK-8225797 more cleaner,
so it's okay for me to only push it to jdk8u-dev.

Thank you
Denghui
------------------------------------------------------------------
From:Mario Torre <neugens at redhat.com>
Send Time:2020?6?16?(???) 19:37
To:Andrey Petushkov <andrey at azul.com>
Cc:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable

On Tue, Jun 16, 2020 at 1:02 PM Andrey Petushkov <andrey at azul.com> wrote:
>
> Ok. I fully do support idea of code unification.
> Just one note on the problem, it definitely has existed early on. During
> backporting to 8u all known to Azul problems have been fixed (in all
> open code bases which are relevant to 8u). Later, these problems were
> addressed in upstream separately by the community, and what you're
> backporting is what, I believe, these fixes in upstream brought. The
> approach of addressing the problems is different between the two, hence
> you see the difference and merge conflicts.

I noticed this while reading the code as well, there are lots of
consolidation but some data types are already 64bits and the few
places where they would be truncated seem that were already addressed
before hand.

> So in my understanding 8u codebase does not need this fix per se, but as
> I said, it's beneficial to have it for the purpose of code unification
> and simplification of further backports

I can't test 32bit right now, if there are no pending issues and this
patch doesn't fix anything other than some code consolidation, then I
suggest to only push this in jdk8u-dev and skip the release train for
this round (i.e. no critical-fix label).

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

From neugens at redhat.com  Wed Jun 17 08:02:44 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 17 Jun 2020 10:02:44 +0200
Subject: RFR 8217647: [backport] JFR: recordings on 32-bit systems
 unreadable
In-Reply-To: <f82593ea-2663-4bbd-9731-ad8490012726.denghui.ddh@alibaba-inc.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
 <fd5f1069-5196-a436-7090-81eaa10515ef@azul.com>
 <951f1745-e1e2-4c1f-a5f2-b34cc4003852.denghui.ddh@alibaba-inc.com>
 <db0c79bd-065b-131d-a43f-2c607342d044@azul.com>
 <CAJwKKma12iYfXwVfULeyY2SGfQGRwVU-k=XsxH_kho4COJhO9A@mail.gmail.com>
 <f82593ea-2663-4bbd-9731-ad8490012726.denghui.ddh@alibaba-inc.com>
Message-ID: <CAJwKKmZZA83S+eqz8QB9Ym9icXAphH6q4+sufeJo60ONvi1NNA@mail.gmail.com>

That makes sense to me.

Patch is OK for jdk8u-dev, we need to get a maintainer's approval still.

Cheers,
Mario

On Wed, Jun 17, 2020 at 9:47 AM Denghui Dong
<denghui.ddh at alibaba-inc.com> wrote:
>
> In fact, the main reason I backport this issue to 8u is to make the backport of JDK-8225797 more cleaner,
> so it's okay for me to only push it to jdk8u-dev.
>
> Thank you
> Denghui
>
> ------------------------------------------------------------------
> From:Mario Torre <neugens at redhat.com>
> Send Time:2020?6?16?(???) 19:37
> To:Andrey Petushkov <andrey at azul.com>
> Cc:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable
>
> On Tue, Jun 16, 2020 at 1:02 PM Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Ok. I fully do support idea of code unification.
> > Just one note on the problem, it definitely has existed early on. During
> > backporting to 8u all known to Azul problems have been fixed (in all
> > open code bases which are relevant to 8u). Later, these problems were
> > addressed in upstream separately by the community, and what you're
> > backporting is what, I believe, these fixes in upstream brought. The
> > approach of addressing the problems is different between the two, hence
> > you see the difference and merge conflicts.
>
> I noticed this while reading the code as well, there are lots of
> consolidation but some data types are already 64bits and the few
> places where they would be truncated seem that were already addressed
> before hand.
>
> > So in my understanding 8u codebase does not need this fix per se, but as
> > I said, it's beneficial to have it for the purpose of code unification
> > and simplification of further backports
>
> I can't test 32bit right now, if there are no pending issues and this
> patch doesn't fix anything other than some code consolidation, then I
> suggest to only push this in jdk8u-dev and skip the release train for
> this round (i.e. no critical-fix label).
>
> Cheers
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898



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


From neugens at redhat.com  Wed Jun 17 08:27:56 2020
From: neugens at redhat.com (Mario Torre)
Date: Wed, 17 Jun 2020 10:27:56 +0200
Subject: [8u] 8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java
 fails
In-Reply-To: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
References: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
Message-ID: <CAJwKKmbttD=pxdm7v2bsR35JO748pT+aTRbAyv=5JeWr26xb0A@mail.gmail.com>

Hi Zhengyu,

Patch looks good.  Could you perhaps add the @key headful, although
this is part of 8196196, your change will generate a conflict anyway
and I'm not yet ready to push it.

I won't need a second look.

Cheers,
Mario

On Wed, Mar 25, 2020 at 10:13 PM Zhengyu Gu <zgu at redhat.com> wrote:
>
> Hi,
>
> I would like to backport this patch to 8u, as it is in Oracle's 8u261.
>
> The original patch does not applies cleanly, the only conflict is the
> bug id line.
>
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8200313
> Original patch: http://hg.openjdk.java.net/jdk/client/rev/a4a0d0ece022
>
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8200313_8u/webrev.00/
>
> Test:
>    Tested on Linux x86_64.
>
> Thanks,
>
> -Zhengyu
>


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


From andrey at azul.com  Wed Jun 17 08:39:38 2020
From: andrey at azul.com (Andrey Petushkov)
Date: Wed, 17 Jun 2020 11:39:38 +0300
Subject: RFR: 8220293: Deadlock in JFR string pool
In-Reply-To: <10c43eae-1330-6b9c-730b-e289e01f2ac4@redhat.com>
References: <b75f37cf-e4c4-d804-b666-4963fc1e1474@azul.com>
 <10c43eae-1330-6b9c-730b-e289e01f2ac4@redhat.com>
Message-ID: <bfe50046-4741-ee04-5226-65d46c0c7712@azul.com>

Hi Andrew,

On 17.06.2020 02:21, Andrew Hughes wrote:
>
> On 16/06/2020 19:12, Andrey Petushkov wrote:
>> Dear All,
>>
>> As suggested by Mario may I ask to include the backport of the
>> https://bugs.openjdk.java.net/browse/JDK-8220293 into 8u262 (that is,
>> critical request). The reason is that this is single severe (VM
>> deadlock) JFR bug we are aware of
>> The patch applies cleanly, except for file locations change. Just in
>> case here is the webrev https://cr.openjdk.java.net/~apetushkov/8220293/
>> (one actual code change is .hpp guard macro name change due to file
>> location change)
> This is confusing. Is the 8u patch different or not?
Ah, sorry. for confusion Yes, the patch is the same. The line in
question is part of diff context I was looking at, not the changed line
So yes, this is absolutely clean backport
>
> Shuffling the 11u changeset gave me the same patch as in your webrev,
> and that applied to 8u cleanly, so I'm inclined to think no changes are
> necessary here.
>
>> Verified by the test in the bug (deadlock in about 1 minute without the
>> fix, running fine for about 15 minutes a few times with the fix)
>>
>> Thanks,
>> Andrey
>>
> Approved for 8u262, assuming it is a clean backport.
Thank you,
Andrey
>
> Thanks,


From aph at redhat.com  Wed Jun 17 09:04:27 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Jun 2020 10:04:27 +0100
Subject: Best practices for OpenJDK 8 updates
Message-ID: <c4cc4196-f6e4-85a1-9e68-b068d3b640fd@redhat.com>

Best practices for OpenJDK 8 updates
====================================

Where we are
------------

OpenJDK 8 is a mature project, well into its middle age. As time
passes, OpenJDK 8 inevitably diverges from mainline OpenJDK
development, and back-porting patches becomes increasingly
difficult. However, we expect to continue to maintain it in some form
for years to come.

Also, back-porting patches becomes not only difficult but increasingly
risky: subsystems are redesigned, and the assumptions on which a patch
to mainline was based are less likely to apply to OpenJDK 8. It may
not be apparent to a back-porting engineer that a patch is
inappropriate.

People still using OpenJDK 8 deserve, above all else, to know that it
will continue to work for their application. Guaranteeing this for
certain is beyond the state of the art, not least because some Java
code makes assumptions that are not guaranteed by the Java
Specification. Nonetheless, we try to keep everything working.

So, the question arises: what patches are appropriate for back-porting
to OpenJDK 8u, and how should that back-porting be done?

[OpenJDK 11 is not yet at this stage in its life cycle, but it will be
before very long.]

What kinds of patches should be back-ported?
--------------------------------------------

Bug fixes may be back-ported if they fix a significant customer-
visible bug. So, a bug that caused an incorrect result to be returned
from a standard method would generally be accepted. However, a bug
that could only have an effect if the user specified arcane -XX:
options on the Java command line probably wouldn't be. Most bugs are
somewhat in between these extremes, so it's necessary to make
judgment calls; it was ever thus.

We must also consider the complexity of the patch to be back-ported.
A thousand-line patch for a minor bug that is unlikely to cause
problems in real-world use is unlikely to be accepted. It is always
appropriate for an engineer working on back-ports to decide that a
patch is too risky.

Bug fixes for parity with Oracle's proprietary releases are generally
acceptable because our users look at a release version number and
expect it to behave in much the same way that the Oracle release of
the same number does. However, even then we should look long and hard
at marginal cases that, for example, touch sensitive parts of HotSpot.

New features should not generally be back-ported to 8u, except where
it is necessary to adapt OpenJDK to new computing environments. For
example, new crypto algorithms might qualify, as might ports to new
hardware or operating systems. These are necessary for JDK 8u to
remain relevant.

Having said that, in some rare cases we might decide that a feature
back-port is sufficiently important to our target audience that we'll
do it anyway.  Such decisions must be discussed in the public list in
order to achieve a broad consensus, and must be signed off by the
Project Lead.

More testing is always good. Additional tests and improvements to the
test infrastructure are welcome, as long as they don't require
significant changes to the project being tested.

Security backports should almost always be accepted.

What form should back-ported patches take?
------------------------------------------

In general, back-ported patches should be minimal. This reduces the
amount of churn in the source code, itself a very important
consideration.

This guideline has some consequences. If a patch to be back-ported
depends on some earlier patches applied to mainline (as is
increasingly likely as time passes) it is not appropriate to pull in
the earlier patches as dependencies unless those patches also fix a
significant bug, or are certain to be needed by several other patches
for significant bugs. It is almost always better to re-work a patch in
order to reduce its complexity, even if that causes it to diverge from
mainline. It may sometimes be appropriate to work around the problem
in an entirely different way, if that reduces the complexity (and
risk) of the patch.

-- 
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 zgu at redhat.com  Wed Jun 17 12:41:59 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 17 Jun 2020 08:41:59 -0400
Subject: [8u] 8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java
 fails
In-Reply-To: <CAJwKKmbttD=pxdm7v2bsR35JO748pT+aTRbAyv=5JeWr26xb0A@mail.gmail.com>
References: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
 <CAJwKKmbttD=pxdm7v2bsR35JO748pT+aTRbAyv=5JeWr26xb0A@mail.gmail.com>
Message-ID: <d63949c6-d358-6a82-63c7-249b6146439f@redhat.com>

Hi Mario,

Thanks for reviewing.

> 
> Patch looks good.  Could you perhaps add the @key headful, although
> this is part of 8196196, your change will generate a conflict anyway
> and I'm not yet ready to push it.

I think @key change should go in with JDK-8196196 backport.

-Zhengyu

> 
> I won't need a second look.
> 
> Cheers,
> Mario
> 
> On Wed, Mar 25, 2020 at 10:13 PM Zhengyu Gu <zgu at redhat.com> wrote:
>>
>> Hi,
>>
>> I would like to backport this patch to 8u, as it is in Oracle's 8u261.
>>
>> The original patch does not applies cleanly, the only conflict is the
>> bug id line.
>>
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8200313
>> Original patch: http://hg.openjdk.java.net/jdk/client/rev/a4a0d0ece022
>>
>>
>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8200313_8u/webrev.00/
>>
>> Test:
>>     Tested on Linux x86_64.
>>
>> Thanks,
>>
>> -Zhengyu
>>
> 
> 


From zgu at redhat.com  Wed Jun 17 14:51:48 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 17 Jun 2020 10:51:48 -0400
Subject: [8u] RFR: 8167615: Opensource unit/regression tests for JavaSound
In-Reply-To: <877dw7xnjh.fsf@redhat.com>
References: <877dw7xnjh.fsf@redhat.com>
Message-ID: <614f1194-cbad-5a35-b54e-76ac61bd4a90@redhat.com>

Backport looks good to me.

Thanks,

-Zhengyu

On 6/16/20 7:22 AM, Roland Westrelin wrote:
> 
> The patch applies cleanly but I had to change the path to a couple test
> files:
> test/javax/sound/midi/MidiSystem/testdata/conf/sound.properties to test/javax/sound/midi/MidiSystem/testdata/lib/conf/sound.properties
> test/javax/sound/sampled/AudioSystem/testdata/conf/sound.properties to test/javax/sound/sampled/AudioSystem/testdata/lib/conf/sound.properties
> 
> so it the library code in 8u finds those files where it expects them.
> 
> For the record, the webrev:
> http://cr.openjdk.java.net/~roland/8167615.8u/webrev.00/
> 
> Initial change:
> https://bugs.openjdk.java.net/browse/JDK-8167615
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5445b9413d9d
> 
> I ran the entire javax/sound test suite and I see a few failures that I
> can either reproduce with 11u or are part of the problem list.
> 
> Roland.
> 


From ebaron at redhat.com  Wed Jun 17 21:22:42 2020
From: ebaron at redhat.com (Elliott Baron)
Date: Wed, 17 Jun 2020 17:22:42 -0400
Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to
 Apache Santuario 2.1.1
In-Reply-To: <106cb997-5693-c24b-f0e0-c70e8e21d877@redhat.com>
References: <acc3e996-34b6-3e20-8593-61630a0bb6ea@redhat.com>
 <c23ef2c1-faa1-8d9a-0a9a-a93513843d3b@redhat.com>
 <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com>
 <106cb997-5693-c24b-f0e0-c70e8e21d877@redhat.com>
Message-ID: <fa0bee7a-e88a-035a-20dc-301ee88b5166@redhat.com>

Hi Andrew,

On 2020-06-15 12:52 p.m., Andrew Hughes wrote:
> 
> 
> On 25/05/2020 21:53, Elliott Baron wrote:
>> Hi,
>>
>> On 2020-05-08 2:58 p.m., Elliott Baron wrote:
>>> Hi,
>>>
>>> On 2020-04-16 7:54 p.m., Elliott Baron wrote:
>>>> Hi,
>>>>
>>>> I'd like to request a review to backport 8177334 to 8u.
>>>>
>>>> Original fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8177334
>>>> http://hg.openjdk.java.net/jdk/jdk/rev/3810c9a2efa1
>>>>
>>>> The JDK 11 fix did not apply cleanly. Below, I have detailed the
>>>> modifications I made in order to backport this fix to 8u. There are
>>>> some major changes that I believe may require some discussion, and
>>>> many minor changes outlined after those. The changes within each
>>>> section are listed roughly in order of the patch.
>>>>
>>>> Thank you to Martin Balao for his assistance in tracking down the
>>>> dependencies for this fix.
>>>>
>>>> I should point out that there are some known bugfixes that fix
>>>> problems introduced by this update. These should probably go into the
>>>> same 8u update as this fix. They are:
>>>> - 8217878: ENVELOPING XML signature no longer works
>>>> - 8218629: XML Digital Signature throws NAMESPACE_ERR exception on
>>>> OpenJDK 11, works 8/9/10 (I believe this is the same fix as above)
>>>> - 8236645: JDK 8u231 introduces a regression with incompatible
>>>> handling of XML messages
>>>>
>>>> 8u webrev:
>>>> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.00/
>>>
>>> Has anyone had a chance to take a look at this yet?
>>>
>>>>
>>>> [snip]
>>
>> Here is an updated webrev that fixes conflicts introduced by
>> 8231415: Better signatures in XML.
>>
>> 8u webrev:
>> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.01/
>>
>> Thanks,
>> Elliott
>>
> 
> Thanks for completing what is a huge backport.

Thanks for the review!

> 
> Can you comment more on what changes you believe require discussion?

Yes, of course. These were in my original patch email [1] along with all 
of the minor changes as well, but I truncated them when I sent out the 
ping. Most of them you've already discovered yourself:

> Major changes
> ---------------
> javax/xml/crypto/dsig/DigestMethod:
> - New string constants referencing new algorithms have been removed, in 
> order to not introduce new public API. I'm not sure if this would 
> technically be a breakage.
> 
> javax/xml/crypto/dsig/SignatureMethod:
> - New string constants have been removed, as in DigestMethod mentioned 
> above.
> 
> org/jcp/xml/dsig/internal/dom/DOMSignatureMethod:
> - There is no "8042967: Add variant of DSA Signature algorithms that do 
> not ASN.1 encode the signature bytes" in 8u. This was a messy backport 
> and it appears to add a new feature. To limit the amount of 
> modifications done to this class, I opted to backport the "getSignature" 
> method only from 8042967.
> - The class hierarchies of various nested DOMSignatureMethods have been 
> changed to exclude abstract classes that were introduced by 8042967.
> - I'm a bit on the fence about these modifications, perhaps it would be 
> better to backport 8042967 after all.
> 
> test/javax/xml/crypto/dsig/GenerationTests:
> - jtreg tag differs because of newer tests already in 8u, lack of 
> modules, and argument added by "8210736: 
> jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux".
> - Test cases using missing SHA-3 algorithm have been removed, since 
> there is no support for it in 8u. This would require a backport of 
> "8000415: Add support for SHA-3" and possibly others.
> - Constants in javax/xml/crypto/dsig/{Digest,Signature}Method that were 
> not backported are substituted with their String values.
> - List.of, which doesn't exist in JDK 8, has been replaced with a static 
> initializer.
> - For code added by "8206911: javax/xml/crypto/dsig/GenerationTests.java 
> fails in 8u-dev", rename call from "test_create_detached_signature" to 
> "test_create_detached_signature0". This reflects the method name change 
> introduced by this fix.
> - Some context also required changes due to 8206911.

Of these, I think the removal of new algorithm constants, and opting not 
to backport "8042967: Add variant of DSA Signature algorithms that do 
not ASN.1 encode the signature bytes" along with my workaround using 
"getSignature" were what I was most concerned about.

>  From comparing with the 11u version, most of it seems fine:
> 
> * Movement of checkRegisterPermission in JavaUtils.java is omitted as
> it's already been moved to its current location in 8u
> * Omission of new 11u algorithms in DigestMethod.java and
> SignatureMethod.java seems appropriate
> * Leaving out the type checking in e.g. DOMKeyInfo.java seems
> appropriate as these API methods did not previously throw ClassCastException
> 
> My main concern is that, although we don't add the new algorithms to
> DigestMethod & SignatureMethod, or their tests, we do seem to be adding
> support in e.g. JCEMapper for new algorithms like SHA3. I think we
> should be consistent here and if we're not going to put new algorithms
> in DigestMethod & SignatureMethod, and not include tests of them, they
> shouldn't be being implemented.

Makes sense to me. I've removed the code related to SHA-3 algorithms, 
and also Whirlpool, which also seems to not be unimplemented.

Revised 8u Webrev: 
https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.02/

I noticed that RIPEMD-160 is already present, but not provided by any 
default crypto provider. I suppose this is to allow the XML-DSig code to 
work with third-party providers. We could follow suit and include the 
new algorithms after all, but as you said, there's no good way to test 
them as part of the JDK.

> 
> I also wonder why getSignature was pulled into DOMSignatureMethod.java
> from JDK-8042967. Why was this needed?
> 

This allowed a cleaner backport for the new RSASSA-PSS 
DOMSignatureMethods. They worked in the original by overriding the 
getSignature method to insert special handling for the PSSParameterSpec. 
Maybe I could add an instanceof special case to the original 8u code 
instead to do this?

Thanks,
Elliott

[1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011571.html


From ebaron at redhat.com  Wed Jun 17 21:26:08 2020
From: ebaron at redhat.com (Elliott Baron)
Date: Wed, 17 Jun 2020 17:26:08 -0400
Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to
 Apache Santuario 2.1.1
In-Reply-To: <fa0bee7a-e88a-035a-20dc-301ee88b5166@redhat.com>
References: <acc3e996-34b6-3e20-8593-61630a0bb6ea@redhat.com>
 <c23ef2c1-faa1-8d9a-0a9a-a93513843d3b@redhat.com>
 <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com>
 <106cb997-5693-c24b-f0e0-c70e8e21d877@redhat.com>
 <fa0bee7a-e88a-035a-20dc-301ee88b5166@redhat.com>
Message-ID: <4753295d-9c3b-5695-d161-9934032b09ef@redhat.com>

On 2020-06-17 5:22 p.m., Elliott Baron wrote:
>>
>> My main concern is that, although we don't add the new algorithms to
>> DigestMethod & SignatureMethod, or their tests, we do seem to be adding
>> support in e.g. JCEMapper for new algorithms like SHA3. I think we
>> should be consistent here and if we're not going to put new algorithms
>> in DigestMethod & SignatureMethod, and not include tests of them, they
>> shouldn't be being implemented.
> 
> Makes sense to me. I've removed the code related to SHA-3 algorithms, 
> and also Whirlpool, which also seems to not be unimplemented.

*seems to be unimplemented.


From xxinliu at amazon.com  Thu Jun 18 00:28:05 2020
From: xxinliu at amazon.com (Liu, Xin)
Date: Thu, 18 Jun 2020 00:28:05 +0000
Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib
Message-ID: <d43ecb73-e1e6-a21f-27ba-930d2cde56b4@amazon.com>

Hi, maintainers,

Could you review this webrev for jdk8u-dev/jdk?

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

Webrev: http://cr.openjdk.java.net/~xliu/8247817/00/webrev/


Description:

I ran into these problems when I try to use jdk/test/lib of jdk repo,? 
which was introduced for JFR testing,? to run hotspot/test/vmtestbase.

I guess the JFR testing doesn't cover them. IMHO, we'd better fix them 
for jdk8u, Otherwise we will observe something strange when we really 
use them.

eg. The whitebox api isMethodCompilable doesn't work. It's because 
CompLevel_any=-1 in jdk8u. Whitebox APIs must be consistent with the 
implementation of hotspot.

thanks,

--lx



From rwestrel at redhat.com  Thu Jun 18 07:53:33 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 18 Jun 2020 09:53:33 +0200
Subject: [8u] RFR: 8167615: Opensource unit/regression tests for JavaSound
In-Reply-To: <614f1194-cbad-5a35-b54e-76ac61bd4a90@redhat.com>
References: <877dw7xnjh.fsf@redhat.com>
 <614f1194-cbad-5a35-b54e-76ac61bd4a90@redhat.com>
Message-ID: <87v9jox11e.fsf@redhat.com>


> Backport looks good to me.

Thanks. I requested backport approval.

Roland.


From sgehwolf at redhat.com  Thu Jun 18 08:29:46 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 18 Jun 2020 10:29:46 +0200
Subject: [8u] 8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java
 fails
In-Reply-To: <d63949c6-d358-6a82-63c7-249b6146439f@redhat.com>
References: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
 <CAJwKKmbttD=pxdm7v2bsR35JO748pT+aTRbAyv=5JeWr26xb0A@mail.gmail.com>
 <d63949c6-d358-6a82-63c7-249b6146439f@redhat.com>
Message-ID: <bb836206fda1c039e864041d32f6576535c54f71.camel@redhat.com>

On Wed, 2020-06-17 at 08:41 -0400, Zhengyu Gu wrote:
> I think @key change should go in with JDK-8196196 backport.

+1

Thanks,
Severin


From sgehwolf at redhat.com  Thu Jun 18 08:31:06 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 18 Jun 2020 10:31:06 +0200
Subject: [8u] 8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java
 fails
In-Reply-To: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
References: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
Message-ID: <f4541f108c234c008e3e4436baa2fe9d3a835f16.camel@redhat.com>

Hi,

On Wed, 2020-03-25 at 17:12 -0400, Zhengyu Gu wrote:
> Hi,
> 
> I would like to backport this patch to 8u, as it is in Oracle's 8u261.
> 
> The original patch does not applies cleanly, the only conflict is the 
> bug id line.

I stared at this for a while. It's the context which is different
(@headful) not yet there in 8u. OK.

> Original bug: https://bugs.openjdk.java.net/browse/JDK-8200313
> Original patch: http://hg.openjdk.java.net/jdk/client/rev/a4a0d0ece022
> 
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8200313_8u/webrev.00/

Looks fine to me.

Thanks,
Severin


From dcherepanov at azul.com  Thu Jun 18 10:47:18 2020
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 18 Jun 2020 13:47:18 +0300
Subject: [8u] RFR 8238225: Issues reported after replacing symlink at
 Contents/MacOS/libjli.dylib with binary
In-Reply-To: <abdede5a-015a-6ca4-9e26-4fc40a619150@redhat.com>
References: <5e7890f6-2a8c-b551-58b0-02c67df0b544@azul.com>
 <abdede5a-015a-6ca4-9e26-4fc40a619150@redhat.com>
Message-ID: <4cd88584-abfc-0868-bdfa-4ccad2873e0a@azul.com>


On 6/8/20 3:05 AM, Andrew Hughes wrote:
> On 17/04/2020 13:57, Dmitry Cherepanov wrote:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238225
>> original review:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064561.html
>>
>> patch for 11u:
>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/128739be82b6
>>
>> webrev for 8u:
>> http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v0/
>>
>> 1) src/macosx/bin/java_md_macosx.c
>>
>> This part applies cleanly but needs refinement. The logic has been
>> expanded to cover 8u-specifics: if the libjli.dylib library was loaded
>> from MacOS bundle (i.e. realPathToSelf ends with ?/MacOS/libjli.dylib?),
>> then check if it?s a JDK bundle (private JRE is in ../Home/jre) and then
>> check if it?s a JRE bundle (public JRE is in ../Home)
>>
>> 2) testing part
>>
>> Given that support for building native part of jtpeg tests is currently
>> missing in 8u (8072842), new shell script was created and used for
>> testing.? The java part of the test also includes additional changes
>> relative to 11u version
>> (http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/JliLaunchTest.java.diff.v0).
>> The test fails without a fix and passes from the fixes (for JRE/JDK
>> bundles)
>>
>> Thanks,
>>
>> Dmitry
>>
> The patch:
>
> https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v0/jdk.changeset
>
> appears to contain both 8235687 & 8238225. Which of these is actually
> being submitted for review?

This is review request for 8238225 only.
Review for 8235687 (for which 8238225 is a follow-up) was submitted 
separately [1] and it appears that 8235687 accidentally leaked into this 
patch.

It should be fixed at: 
http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v1/

Thanks for catching this.

Dmitry

[1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011576.html


From zgu at redhat.com  Thu Jun 18 11:50:54 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 18 Jun 2020 07:50:54 -0400
Subject: [8u] 8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java
 fails
In-Reply-To: <f4541f108c234c008e3e4436baa2fe9d3a835f16.camel@redhat.com>
References: <73fee1fe-a044-9035-8a7f-677373a26d0b@redhat.com>
 <f4541f108c234c008e3e4436baa2fe9d3a835f16.camel@redhat.com>
Message-ID: <7d07e32e-bb2b-f518-d65e-a871330688a2@redhat.com>

Thanks, Severin

-Zhengyu

On 6/18/20 4:31 AM, Severin Gehwolf wrote:
> Hi,
> 
> On Wed, 2020-03-25 at 17:12 -0400, Zhengyu Gu wrote:
>> Hi,
>>
>> I would like to backport this patch to 8u, as it is in Oracle's 8u261.
>>
>> The original patch does not applies cleanly, the only conflict is the
>> bug id line.
> 
> I stared at this for a while. It's the context which is different
> (@headful) not yet there in 8u. OK.
> 
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8200313
>> Original patch: http://hg.openjdk.java.net/jdk/client/rev/a4a0d0ece022
>>
>>
>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8200313_8u/webrev.00/
> 
> Looks fine to me.
> 
> Thanks,
> Severin
> 


From zgu at redhat.com  Thu Jun 18 14:06:27 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 18 Jun 2020 10:06:27 -0400
Subject: [8u] RFR 8177628: Opensource unit/regression tests for ImageIO
Message-ID: <d2e4e64a-be70-6a67-90fe-a89a6a2ce044@redhat.com>

Hi,

I would like to backport these tests to 8u. Although, it does not show 
up as Oracle parity, but a few Oracle parities depend on it.

The original JDK9 patch applies cleanly, but I modified some of tests, 
removed @modules annotations.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8177628
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e748c6a2d2e6

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

Test:
   Ran new tests on Linux x86_64, all passed


Thanks,

-Zhengyu


From lutkerd at amazon.com  Thu Jun 18 16:32:39 2020
From: lutkerd at amazon.com (Lutker, Dan)
Date: Thu, 18 Jun 2020 16:32:39 +0000
Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in
 revokeall.exe on Windows
Message-ID: <3B8B8599-D9CC-4BDC-A7DA-F61BE65129DE@amazon.com>

Hi all,
I am backporting this to fix an issue with revokeall.exe hanging on Windows systems.

http://cr.openjdk.java.net/~phh/8214545/webrev.8u.01/

The new revokeall.exe was built on the test machine and the README was updated with the build command used for the new source file to create the old binary name.

The original change is here: http://hg.openjdk.java.net/jdk/jdk/rev/2ffbc00d87ae

Testing done:
Built images on Windows x64 and ran the jdk/sun/management tests, which all passed.

Thanks,
Dan


From gnu.andrew at redhat.com  Thu Jun 18 16:48:33 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 18 Jun 2020 17:48:33 +0100
Subject: SunPKCS11 connection lost after Decrypt doFinal
In-Reply-To: <073918b1-75d1-305e-5054-c663aa360306@oracle.com>
References: <PR2P264MB09276C496E823F3377F33ED4EC9D0@PR2P264MB0927.FRAP264.PROD.OUTLOOK.COM>
 <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com>
 <073918b1-75d1-305e-5054-c663aa360306@oracle.com>
Message-ID: <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com>

On 17/06/2020 05:24, Valerie Peng wrote:
> Well, JDK-8235215 is relevant to JDK-6946830 but not a duplicate of it.
> 
> I should have added a duplicate-of-issue link to make it clear -
> JDK-8235215 is closed as a duplicate of JDK-8236512.
> 
> Sorry for the confusion and hope all is clear now.
> 
> Thanks,
> Valerie
> 

Thanks, Valerie. Yes, it is now. I'll look into backporting 8236512.
-- 
Andrew :)

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

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


From gnu.andrew at redhat.com  Thu Jun 18 18:00:28 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 18 Jun 2020 19:00:28 +0100
Subject: RFR 8217647: [backport] JFR: recordings on 32-bit systems
 unreadable
In-Reply-To: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>
Message-ID: <190b0f8e-7858-c7c0-8601-7c574c08536e@redhat.com>

On 16/06/2020 04:44, Denghui Dong wrote:
> Could I have a review of this backport?
> 
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8217647
> 
> Original fix from 11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
> 
> Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
> 
> Backport reasons:
> 1. Fix the unreadable problem on 32-bit in 8u
> 2. Make subsequent backport more smoothly
> 
> The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:
> 
>  a) Conflict in jfrRecorderService.cpp. Patch wants this:
> 
> -static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> -  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
> -  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
> +static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> +  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
> +  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>    cw.reserve(sizeof(u4));
>    cw.write<u8>(EVENT_CHECKPOINT);
>    cw.write(JfrTicks::now());
> -  cw.write<jlong>((jlong)0);
> +  cw.write((int64_t)0);
>    cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
>    cw.write<bool>(false); // flushpoint
> -  cw.write<u4>((u4)1); // nof types in this checkpoint
> -  cw.write<u8>(type_id);
> -  const intptr_t number_of_elements_offset = cw.current_offset();
> +  cw.write((u4)1); // nof types in this checkpoint
> +  cw.write(type_id);
> +  const int64_t number_of_elements_offset = cw.current_offset();
>    cw.reserve(sizeof(u4));
>    return number_of_elements_offset;
>  }
> 
>  ... but the 8u code is:
> 
> static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
>   const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
>   const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>   cw.reserve(sizeof(u4));
>   cw.write<u8>(EVENT_CHECKPOINT);
>   cw.write(JfrTicks::now());
>   cw.write<jlong>((jlong)0);
>   cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
>   cw.write<bool>(false); // flushpoint
>   cw.write<u4>((u4)1); // nof types in this checkpoint
>   cw.write<u8>(type_id);
>   const intptr_t number_of_elements_offset = cw.current_offset();
>   cw.reserve(sizeof(u4));
>   return number_of_elements_offset;
> }
> 
>  ... I did a manual adjustment: 
>     cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);
> 
>  b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:
> 
>  template <typename BE, typename IE, typename WriterPolicyImpl>
>  inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
> -  be_write(*(uintptr_t*)&(value));
> +  be_write(*(u8*)&(value));
>  }
> 
>  ... but the 8u code is:
> 
> template <typename BE, typename IE, typename WriterPolicyImpl>
> inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
>   be_write(*(u8*)&(value));
> }
> 
>  ... so I skipped it.
> 
>  c) Build failure. Patch wants this in jfrRepository.cpp:
> 
> +            log_info(jfr) ( // For user, should not be "jfr, system"
> +              "Unable to recover JFR data");
> +            break;
> 
>  ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"
> 
> 
>  d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
> 
> Thanks,
> Denghui Dong
> 

Thanks for the comprehensive analysis. It's really helpful in reviewing
this.

The changes in the patch look fine. I see you also omitted the changes
not in 11u. Was this intentional? I compared with the 11u version, so I
didn't notice this in reviewing the patch itself.

Incidentally, we haven't been building JFR on x86 so far, because it
crashed when I tried to build it:

/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.262.b02-0.2.ea.el7.i386/openjdk/build/jdk8.build-debug/images/j2sdk-image/bin/javac
-d . /builddir/build/SOURCES/TestCryptoLevel.java
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:1281
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.262.b02-0.2.ea.el7.i386/openjdk/hotspot/src/share/vm/runtime/os.cpp:1281),
pid=93916, tid=0xf6431b40
#  assert(SerializePageShiftCount == count) failed: thread size changed,
fix SerializePageShiftCount constant

TestCryptoLevel.java is a simple Java test we run on the just-built JDK
to check unlimited crypto is in use:

https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/master/f/TestCryptoLevel.java

I assumed from this that x86 wasn't supported, but if it should be
working, maybe we should look into this more.

Thanks,
-- 
Andrew :)

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

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


From hohensee at amazon.com  Thu Jun 18 19:48:32 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 18 Jun 2020 19:48:32 +0000
Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in
 revokeall.exe on Windows
In-Reply-To: <3B8B8599-D9CC-4BDC-A7DA-F61BE65129DE@amazon.com>
References: <3B8B8599-D9CC-4BDC-A7DA-F61BE65129DE@amazon.com>
Message-ID: <1403EDF5-4E92-4645-9992-09F55BE40B7A@amazon.com>

I assume (some of) the 8u jdk/test/sun/management/jmxremote/bootstrap tests were hanging without this patch.

https://bugs.openjdk.java.net/browse/JDK-8214545 corresponding to the patch isn't accessible. Oracle engineer(s), would it be possible to open it?

The original patch updates JtregNativeJdk.gmk, but I couldn't find the mechanism implemented by that file in 8 (perhaps another reviewer can comment), so omitting it seems correct.

There is an extra (duplicate) file test/jdk/sun/management/windows/exerevokeall.c in your webrev. Other than that, lgtm.

Thanks,
Paul

?On 6/18/20, 9:38 AM, "jdk8u-dev on behalf of Lutker, Dan" <jdk8u-dev-bounces at openjdk.java.net on behalf of lutkerd at amazon.com> wrote:

    Hi all,
    I am backporting this to fix an issue with revokeall.exe hanging on Windows systems.

    http://cr.openjdk.java.net/~phh/8214545/webrev.8u.01/

    The new revokeall.exe was built on the test machine and the README was updated with the build command used for the new source file to create the old binary name.

    The original change is here: http://hg.openjdk.java.net/jdk/jdk/rev/2ffbc00d87ae

    Testing done:
    Built images on Windows x64 and ran the jdk/sun/management tests, which all passed.

    Thanks,
    Dan



From hohensee at amazon.com  Thu Jun 18 21:27:36 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 18 Jun 2020 21:27:36 +0000
Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib
In-Reply-To: <d43ecb73-e1e6-a21f-27ba-930d2cde56b4@amazon.com>
References: <d43ecb73-e1e6-a21f-27ba-930d2cde56b4@amazon.com>
Message-ID: <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com>

Would you describe the problems you encountered that this patch solves please? The Whitebox issue is obvious, but the purpose of the other changes isn't.

Thanks,
Paul

?On 6/17/20, 5:29 PM, "jdk8u-dev on behalf of Liu, Xin" <jdk8u-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote:

    Hi, maintainers,

    Could you review this webrev for jdk8u-dev/jdk?

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

    Webrev: http://cr.openjdk.java.net/~xliu/8247817/00/webrev/


    Description:

    I ran into these problems when I try to use jdk/test/lib of jdk repo,  
    which was introduced for JFR testing,  to run hotspot/test/vmtestbase.

    I guess the JFR testing doesn't cover them. IMHO, we'd better fix them 
    for jdk8u, Otherwise we will observe something strange when we really 
    use them.

    eg. The whitebox api isMethodCompilable doesn't work. It's because 
    CompLevel_any=-1 in jdk8u. Whitebox APIs must be consistent with the 
    implementation of hotspot.

    thanks,

    --lx




From lutkerd at amazon.com  Thu Jun 18 22:46:13 2020
From: lutkerd at amazon.com (Lutker, Dan)
Date: Thu, 18 Jun 2020 22:46:13 +0000
Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in
 revokeall.exe on Windows
In-Reply-To: <1403EDF5-4E92-4645-9992-09F55BE40B7A@amazon.com>
References: <3B8B8599-D9CC-4BDC-A7DA-F61BE65129DE@amazon.com>
 <1403EDF5-4E92-4645-9992-09F55BE40B7A@amazon.com>
Message-ID: <040F52CE-24CE-464E-B785-89933371D4E6@amazon.com>

Thanks Paul,
Updated webrev without the extra file is here: http://cr.openjdk.java.net/~phh/8214545/webrev.8u.02/

Yes, we starting hitting the hang during our Tier2 runs in a new test bed we are spinning up, with this patch the runs complete fine.

-Dan

?On 6/18/20, 12:48 PM, "Hohensee, Paul" <hohensee at amazon.com> wrote:

    I assume (some of) the 8u jdk/test/sun/management/jmxremote/bootstrap tests were hanging without this patch.
    
    https://bugs.openjdk.java.net/browse/JDK-8214545 corresponding to the patch isn't accessible. Oracle engineer(s), would it be possible to open it?
    
    The original patch updates JtregNativeJdk.gmk, but I couldn't find the mechanism implemented by that file in 8 (perhaps another reviewer can comment), so omitting it seems correct.
    
    There is an extra (duplicate) file test/jdk/sun/management/windows/exerevokeall.c in your webrev. Other than that, lgtm.
    
    Thanks,
    Paul
    
    On 6/18/20, 9:38 AM, "jdk8u-dev on behalf of Lutker, Dan" <jdk8u-dev-bounces at openjdk.java.net on behalf of lutkerd at amazon.com> wrote:
    
        Hi all,
        I am backporting this to fix an issue with revokeall.exe hanging on Windows systems.
    
        http://cr.openjdk.java.net/~phh/8214545/webrev.8u.01/
    
        The new revokeall.exe was built on the test machine and the README was updated with the build command used for the new source file to create the old binary name.
    
        The original change is here: http://hg.openjdk.java.net/jdk/jdk/rev/2ffbc00d87ae
    
        Testing done:
        Built images on Windows x64 and ran the jdk/sun/management tests, which all passed.
    
        Thanks,
        Dan
    
    
    


From xxinliu at amazon.com  Thu Jun 18 23:00:50 2020
From: xxinliu at amazon.com (Liu, Xin)
Date: Thu, 18 Jun 2020 23:00:50 +0000
Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib
In-Reply-To: <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com>
References: <d43ecb73-e1e6-a21f-27ba-930d2cde56b4@amazon.com>
 <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com>
Message-ID: <22c7e7db-229f-1631-39c7-60ee4ad958a6@amazon.com>

hi, Paul,

I believe those code were brought in from upstream for JFR, but JFR 
testing may not cover them.
I am working a new patchset which allows users to run vmtestbase using 
jdk/test/lib of jdk repo. I ran into those problems when I execute 
vmtestcase.

for example, 
http://cr.openjdk.java.net/~xliu/8247817/00/webrev/test/lib/jdk/test/lib/util/JarUtils.java.udiff.html
This class makes use InputStream.transferTo, which is available since jdk9
(https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream) 

It can't be compiled with the runtime of jdk8u.

Other 3 symbols like Platform.sharedLibraryPathVariableName(), 
Utils.TEST_ROOT and jtreg.SkippedException are all symbols referred by 
hotspot/test/vmTestbase.
yes, we can recursively backport them, but it is time-consuming and 
introduce a lot of less irrelevant code. They are all incremental 
changes which won't incur any conflict.

thanks,
--lx

On 6/18/20 2:27 PM, Hohensee, Paul wrote:
> Would you describe the problems you encountered that this patch solves please? The Whitebox issue is obvious, but the purpose of the other changes isn't.
>
> Thanks,
> Paul
>
> ?On 6/17/20, 5:29 PM, "jdk8u-dev on behalf of Liu, Xin" <jdk8u-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote:
>
>      Hi, maintainers,
>
>      Could you review this webrev for jdk8u-dev/jdk?
>
>      Bug: https://bugs.openjdk.java.net/browse/JDK-8247817
>
>      Webrev: http://cr.openjdk.java.net/~xliu/8247817/00/webrev/
>
>
>      Description:
>
>      I ran into these problems when I try to use jdk/test/lib of jdk repo,
>      which was introduced for JFR testing,  to run hotspot/test/vmtestbase.
>
>      I guess the JFR testing doesn't cover them. IMHO, we'd better fix them
>      for jdk8u, Otherwise we will observe something strange when we really
>      use them.
>
>      eg. The whitebox api isMethodCompilable doesn't work. It's because
>      CompLevel_any=-1 in jdk8u. Whitebox APIs must be consistent with the
>      implementation of hotspot.
>
>      thanks,
>
>      --lx
>
>
>


From denghui.ddh at alibaba-inc.com  Fri Jun 19 02:23:15 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Fri, 19 Jun 2020 10:23:15 +0800
Subject: =?UTF-8?B?UmU6IFJGUiA4MjE3NjQ3OiBbYmFja3BvcnRdIEpGUjogcmVjb3JkaW5ncyBvbiAzMi1iaXQg?=
 =?UTF-8?B?c3lzdGVtcyB1bnJlYWRhYmxl?=
In-Reply-To: <190b0f8e-7858-c7c0-8601-7c574c08536e@redhat.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>,
 <190b0f8e-7858-c7c0-8601-7c574c08536e@redhat.com>
Message-ID: <62706560-e9c5-47b2-9c53-51a51369baee.denghui.ddh@alibaba-inc.com>

> The changes in the patch look fine. I see you also omitted the changes
> not in 11u. Was this intentional? I compared with the 11u version, so I
> didn't notice this in reviewing the patch itself.

yes, it's intentional. I hope that the jfr code of jdk8u and jdk11u are as consistent as possible, which is good to the later backport work(e.g. 8225797)


> Incidentally, we haven't been building JFR on x86 so far, because it
> crashed when I tried to build it:
> ...

Thanks for sharing.
After I finish the preparation of the environment, I will try to build JFR on the 32bit system and will take a look at this issue.
------------------------------------------------------------------
From:Andrew Hughes <gnu.andrew at redhat.com>
Send Time:2020?6?19?(???) 02:00
To:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable

On 16/06/2020 04:44, Denghui Dong wrote:
> Could I have a review of this backport?
> 
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8217647
> 
> Original fix from 11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
> 
> Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
> 
> Backport reasons:
> 1. Fix the unreadable problem on 32-bit in 8u
> 2. Make subsequent backport more smoothly
> 
> The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:
> 
>  a) Conflict in jfrRecorderService.cpp. Patch wants this:
> 
> -static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> -  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
> -  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
> +static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> +  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
> +  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>    cw.reserve(sizeof(u4));
>    cw.write<u8>(EVENT_CHECKPOINT);
>    cw.write(JfrTicks::now());
> -  cw.write<jlong>((jlong)0);
> +  cw.write((int64_t)0);
>    cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
>    cw.write<bool>(false); // flushpoint
> -  cw.write<u4>((u4)1); // nof types in this checkpoint
> -  cw.write<u8>(type_id);
> -  const intptr_t number_of_elements_offset = cw.current_offset();
> +  cw.write((u4)1); // nof types in this checkpoint
> +  cw.write(type_id);
> +  const int64_t number_of_elements_offset = cw.current_offset();
>    cw.reserve(sizeof(u4));
>    return number_of_elements_offset;
>  }
> 
>  ... but the 8u code is:
> 
> static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
>   const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
>   const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>   cw.reserve(sizeof(u4));
>   cw.write<u8>(EVENT_CHECKPOINT);
>   cw.write(JfrTicks::now());
>   cw.write<jlong>((jlong)0);
>   cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
>   cw.write<bool>(false); // flushpoint
>   cw.write<u4>((u4)1); // nof types in this checkpoint
>   cw.write<u8>(type_id);
>   const intptr_t number_of_elements_offset = cw.current_offset();
>   cw.reserve(sizeof(u4));
>   return number_of_elements_offset;
> }
> 
>  ... I did a manual adjustment: 
>     cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);
> 
>  b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:
> 
>  template <typename BE, typename IE, typename WriterPolicyImpl>
>  inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
> -  be_write(*(uintptr_t*)&(value));
> +  be_write(*(u8*)&(value));
>  }
> 
>  ... but the 8u code is:
> 
> template <typename BE, typename IE, typename WriterPolicyImpl>
> inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
>   be_write(*(u8*)&(value));
> }
> 
>  ... so I skipped it.
> 
>  c) Build failure. Patch wants this in jfrRepository.cpp:
> 
> +            log_info(jfr) ( // For user, should not be "jfr, system"
> +              "Unable to recover JFR data");
> +            break;
> 
>  ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"
> 
> 
>  d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
> 
> Thanks,
> Denghui Dong
> 

Thanks for the comprehensive analysis. It's really helpful in reviewing
this.

The changes in the patch look fine. I see you also omitted the changes
not in 11u. Was this intentional? I compared with the 11u version, so I
didn't notice this in reviewing the patch itself.

Incidentally, we haven't been building JFR on x86 so far, because it
crashed when I tried to build it:

/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.262.b02-0.2.ea.el7.i386/openjdk/build/jdk8.build-debug/images/j2sdk-image/bin/javac
-d . /builddir/build/SOURCES/TestCryptoLevel.java
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:1281
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.262.b02-0.2.ea.el7.i386/openjdk/hotspot/src/share/vm/runtime/os.cpp:1281),
pid=93916, tid=0xf6431b40
#  assert(SerializePageShiftCount == count) failed: thread size changed,
fix SerializePageShiftCount constant

TestCryptoLevel.java is a simple Java test we run on the just-built JDK
to check unlimited crypto is in use:

https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/master/f/TestCryptoLevel.java

I assumed from this that x86 wasn't supported, but if it should be
working, maybe we should look into this more.

Thanks,
-- 
Andrew :)

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

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


From aph at redhat.com  Fri Jun 19 07:22:39 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Jun 2020 08:22:39 +0100
Subject: [8u] RFR 8177628: Opensource unit/regression tests for ImageIO
In-Reply-To: <d2e4e64a-be70-6a67-90fe-a89a6a2ce044@redhat.com>
References: <d2e4e64a-be70-6a67-90fe-a89a6a2ce044@redhat.com>
Message-ID: <37e89728-3f3d-b17e-648f-f911a3dd98c8@redhat.com>

On 18/06/2020 15:06, Zhengyu Gu wrote:
> I would like to backport these tests to 8u. Although, it does not show 
> up as Oracle parity, but a few Oracle parities depend on it.
> 
> The original JDK9 patch applies cleanly, but I modified some of tests, 
> removed @modules annotations.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8177628
> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e748c6a2d2e6
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8177628-8u/webrev.00/

OK, thanks.

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


From jaroslav.bachorik at datadoghq.com  Fri Jun 19 11:09:43 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 19 Jun 2020 13:09:43 +0200
Subject: RFR 8243489: Thread CPU Load event may contain wrong data for CPU
 time under certain conditions
Message-ID: <CAPb8aJ4w6BEbkKEGyYW-1-cmJKAWvbB5nJiL5tAvSTNNzZb5fg@mail.gmail.com>

Please, review the following backport

JIRA.    : https://bugs.openjdk.java.net/browse/JDK-8243489
Webrev: http://cr.openjdk.java.net/~jbachorik/8243489/8u/hotspot/webrev/


The backport applies cleanly but the accompanying test had to be
dropped because it is using gTest and MockOs facilities which are not
available in JDK8u. Recreating the test without MockOs is near to
impossible because it is relying on being able to modify the reported
thread CPU time to assert the correct functionality.

Cheers,

-JB-

From akashche at redhat.com  Fri Jun 19 11:56:17 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Fri, 19 Jun 2020 12:56:17 +0100
Subject: [8u] RFR: 8137087: [TEST_BUG] Cygwin failure of
 java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
Message-ID: <670e40b6-6353-eeb8-2a59-facc17443871@redhat.com>

Hi,

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

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

9 commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cdb6ac2b8a25

8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8137087/webrev.00/

8u change is slightly different (copyright year, @modules tag), because 
8u doesn't include changes introduced in JDK-8076468. Testing: checked 
that this test passes with the patch.

-- 
-Alex


From akashche at redhat.com  Fri Jun 19 11:56:49 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Fri, 19 Jun 2020 12:56:49 +0100
Subject: [8u] RFR: 8210147: adjust some WSAGetLastError usages in windows
 network coding
Message-ID: <4dd7bab1-aa49-935e-a3ec-13e511ae7972@redhat.com>

Hi,

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

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

jdk/jdk commit: https://hg.openjdk.java.net/jdk/jdk/rev/9aa7ac61e68c

8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8210147/webrev.00/

8u patch is slightly different (SocketInputStream.c part) because 8u 
doesn't include the changes introduced in JDK-8166584.

-- 
-Alex


From zgu at redhat.com  Fri Jun 19 12:14:44 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 19 Jun 2020 08:14:44 -0400
Subject: [8u] RFR: 8137087: [TEST_BUG] Cygwin failure of
 java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
In-Reply-To: <670e40b6-6353-eeb8-2a59-facc17443871@redhat.com>
References: <670e40b6-6353-eeb8-2a59-facc17443871@redhat.com>
Message-ID: <c015d79d-1384-67d4-2e82-e09f6b3188bd@redhat.com>

Looks good.

Thanks,

-Zhengyu

On 6/19/20 7:56 AM, Alex Kashchenko wrote:
> Hi,
> 
> Please review the backport of JDK-8137087 to 8u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137087
> 
> 9 commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cdb6ac2b8a25
> 
> 8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8137087/webrev.00/
> 
> 8u change is slightly different (copyright year, @modules tag), because 
> 8u doesn't include changes introduced in JDK-8076468. Testing: checked 
> that this test passes with the patch.
> 


From zgu at redhat.com  Fri Jun 19 12:19:44 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 19 Jun 2020 08:19:44 -0400
Subject: [8u] RFR: 8210147: adjust some WSAGetLastError usages in windows
 network coding
In-Reply-To: <4dd7bab1-aa49-935e-a3ec-13e511ae7972@redhat.com>
References: <4dd7bab1-aa49-935e-a3ec-13e511ae7972@redhat.com>
Message-ID: <b5619c91-efb6-aa08-6ef8-3ab8824c5711@redhat.com>

Looks good.

-Zhengyu

On 6/19/20 7:56 AM, Alex Kashchenko wrote:
> Hi,
> 
> Please review the backport of JDK-8210147 to 8u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210147
> 
> jdk/jdk commit: https://hg.openjdk.java.net/jdk/jdk/rev/9aa7ac61e68c
> 
> 8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8210147/webrev.00/
> 
> 8u patch is slightly different (SocketInputStream.c part) because 8u 
> doesn't include the changes introduced in JDK-8166584.
> 


From aph at redhat.com  Fri Jun 19 12:29:32 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Jun 2020 13:29:32 +0100
Subject: RFR 8243489: Thread CPU Load event may contain wrong data for CPU
 time under certain conditions
In-Reply-To: <CAPb8aJ4w6BEbkKEGyYW-1-cmJKAWvbB5nJiL5tAvSTNNzZb5fg@mail.gmail.com>
References: <CAPb8aJ4w6BEbkKEGyYW-1-cmJKAWvbB5nJiL5tAvSTNNzZb5fg@mail.gmail.com>
Message-ID: <1795910a-d752-a711-40c5-7338bacdba52@redhat.com>

On 19/06/2020 12:09, Jaroslav Bachor?k wrote:
> JIRA.    : https://bugs.openjdk.java.net/browse/JDK-8243489
> Webrev: http://cr.openjdk.java.net/~jbachorik/8243489/8u/hotspot/webrev/
> 
> 
> The backport applies cleanly but the accompanying test had to be
> dropped because it is using gTest and MockOs facilities which are not
> available in JDK8u. Recreating the test without MockOs is near to
> impossible because it is relying on being able to modify the reported
> thread CPU time to assert the correct functionality.

OK, thanks.

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


From aph at redhat.com  Fri Jun 19 12:30:19 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Jun 2020 13:30:19 +0100
Subject: [8u] RFR: 8137087: [TEST_BUG] Cygwin failure of
 java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
In-Reply-To: <670e40b6-6353-eeb8-2a59-facc17443871@redhat.com>
References: <670e40b6-6353-eeb8-2a59-facc17443871@redhat.com>
Message-ID: <ee7f8099-382b-1de0-d0d7-d233dd2a8db0@redhat.com>

On 19/06/2020 12:56, Alex Kashchenko wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137087
> 
> 9 commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cdb6ac2b8a25
> 
> 8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8137087/webrev.00/
> 
> 8u change is slightly different (copyright year, @modules tag), because 
> 8u doesn't include changes introduced in JDK-8076468. Testing: checked 
> that this test passes with the patch.

OK, thanks.

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


From akashche at redhat.com  Fri Jun 19 15:56:43 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Fri, 19 Jun 2020 16:56:43 +0100
Subject: [8u] RFR: 8210147: adjust some WSAGetLastError usages in windows
 network coding
In-Reply-To: <b5619c91-efb6-aa08-6ef8-3ab8824c5711@redhat.com>
References: <4dd7bab1-aa49-935e-a3ec-13e511ae7972@redhat.com>
 <b5619c91-efb6-aa08-6ef8-3ab8824c5711@redhat.com>
Message-ID: <ba12d889-9c9f-2b15-4c0b-78102ec03a2c@redhat.com>

On 06/19/2020 01:19 PM, Zhengyu Gu wrote:
> Looks good.

Thanks for the review! I've added 8u fix request to the issue.

> 
> -Zhengyu
> 
> On 6/19/20 7:56 AM, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review the backport of JDK-8210147 to 8u:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210147
>>
>> jdk/jdk commit: https://hg.openjdk.java.net/jdk/jdk/rev/9aa7ac61e68c
>>
>> 8u-dev webrev: 
>> https://cr.openjdk.java.net/~akasko/jdk8u/8210147/webrev.00/
>>
>> 8u patch is slightly different (SocketInputStream.c part) because 8u 
>> doesn't include the changes introduced in JDK-8166584.
>>
> 


-- 
-Alex


From akashche at redhat.com  Fri Jun 19 15:57:13 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Fri, 19 Jun 2020 16:57:13 +0100
Subject: [8u] RFR: 8137087: [TEST_BUG] Cygwin failure of
 java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
In-Reply-To: <ee7f8099-382b-1de0-d0d7-d233dd2a8db0@redhat.com>
References: <670e40b6-6353-eeb8-2a59-facc17443871@redhat.com>
 <ee7f8099-382b-1de0-d0d7-d233dd2a8db0@redhat.com>
Message-ID: <a625eb10-ea1b-4d7f-eb4f-6bdf44cf6f1b@redhat.com>

On 06/19/2020 01:30 PM, Andrew Haley wrote:
> On 19/06/2020 12:56, Alex Kashchenko wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137087
>>
>> 9 commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cdb6ac2b8a25
>>
>> 8u-dev webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8137087/webrev.00/
>>
>> 8u change is slightly different (copyright year, @modules tag), because
>> 8u doesn't include changes introduced in JDK-8076468. Testing: checked
>> that this test passes with the patch.
> 
> OK, thanks.

Thanks for the review! I've added 8u fix request to the issue.


-- 
-Alex


From hohensee at amazon.com  Fri Jun 19 17:01:15 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 19 Jun 2020 17:01:15 +0000
Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in
 revokeall.exe on Windows
In-Reply-To: <040F52CE-24CE-464E-B785-89933371D4E6@amazon.com>
References: <3B8B8599-D9CC-4BDC-A7DA-F61BE65129DE@amazon.com>
 <1403EDF5-4E92-4645-9992-09F55BE40B7A@amazon.com>
 <040F52CE-24CE-464E-B785-89933371D4E6@amazon.com>
Message-ID: <C952B660-6B89-4785-89C1-08FF858A3765@amazon.com>

Lgtm. Andrew and Severin, I can't tag the JBS issue, so would you approve/disapprove here on the list please?

Thanks,
Paul

?On 6/18/20, 3:46 PM, "Lutker, Dan" <lutkerd at amazon.com> wrote:

    Thanks Paul,
    Updated webrev without the extra file is here: http://cr.openjdk.java.net/~phh/8214545/webrev.8u.02/

    Yes, we starting hitting the hang during our Tier2 runs in a new test bed we are spinning up, with this patch the runs complete fine.

    -Dan

    On 6/18/20, 12:48 PM, "Hohensee, Paul" <hohensee at amazon.com> wrote:

        I assume (some of) the 8u jdk/test/sun/management/jmxremote/bootstrap tests were hanging without this patch.

        https://bugs.openjdk.java.net/browse/JDK-8214545 corresponding to the patch isn't accessible. Oracle engineer(s), would it be possible to open it?

        The original patch updates JtregNativeJdk.gmk, but I couldn't find the mechanism implemented by that file in 8 (perhaps another reviewer can comment), so omitting it seems correct.

        There is an extra (duplicate) file test/jdk/sun/management/windows/exerevokeall.c in your webrev. Other than that, lgtm.

        Thanks,
        Paul

        On 6/18/20, 9:38 AM, "jdk8u-dev on behalf of Lutker, Dan" <jdk8u-dev-bounces at openjdk.java.net on behalf of lutkerd at amazon.com> wrote:

            Hi all,
            I am backporting this to fix an issue with revokeall.exe hanging on Windows systems.

            http://cr.openjdk.java.net/~phh/8214545/webrev.8u.01/

            The new revokeall.exe was built on the test machine and the README was updated with the build command used for the new source file to create the old binary name.

            The original change is here: http://hg.openjdk.java.net/jdk/jdk/rev/2ffbc00d87ae

            Testing done:
            Built images on Windows x64 and ran the jdk/sun/management tests, which all passed.

            Thanks,
            Dan






From hohensee at amazon.com  Fri Jun 19 17:04:48 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 19 Jun 2020 17:04:48 +0000
Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib
In-Reply-To: <22c7e7db-229f-1631-39c7-60ee4ad958a6@amazon.com>
References: <d43ecb73-e1e6-a21f-27ba-930d2cde56b4@amazon.com>
 <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com>
 <22c7e7db-229f-1631-39c7-60ee4ad958a6@amazon.com>
Message-ID: <0EEB7BC0-F348-4182-9DCB-4303DFF671D5@amazon.com>

Thank you, Xin. Lgtm.

Paul

?On 6/18/20, 4:00 PM, "Liu, Xin" <xxinliu at amazon.com> wrote:

    hi, Paul,

    I believe those code were brought in from upstream for JFR, but JFR 
    testing may not cover them.
    I am working a new patchset which allows users to run vmtestbase using 
    jdk/test/lib of jdk repo. I ran into those problems when I execute 
    vmtestcase.

    for example, 
    http://cr.openjdk.java.net/~xliu/8247817/00/webrev/test/lib/jdk/test/lib/util/JarUtils.java.udiff.html
    This class makes use InputStream.transferTo, which is available since jdk9
    (https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream) 

    It can't be compiled with the runtime of jdk8u.

    Other 3 symbols like Platform.sharedLibraryPathVariableName(), 
    Utils.TEST_ROOT and jtreg.SkippedException are all symbols referred by 
    hotspot/test/vmTestbase.
    yes, we can recursively backport them, but it is time-consuming and 
    introduce a lot of less irrelevant code. They are all incremental 
    changes which won't incur any conflict.

    thanks,
    --lx

    On 6/18/20 2:27 PM, Hohensee, Paul wrote:
    > Would you describe the problems you encountered that this patch solves please? The Whitebox issue is obvious, but the purpose of the other changes isn't.
    >
    > Thanks,
    > Paul
    >
    > On 6/17/20, 5:29 PM, "jdk8u-dev on behalf of Liu, Xin" <jdk8u-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote:
    >
    >      Hi, maintainers,
    >
    >      Could you review this webrev for jdk8u-dev/jdk?
    >
    >      Bug: https://bugs.openjdk.java.net/browse/JDK-8247817
    >
    >      Webrev: http://cr.openjdk.java.net/~xliu/8247817/00/webrev/
    >
    >
    >      Description:
    >
    >      I ran into these problems when I try to use jdk/test/lib of jdk repo,
    >      which was introduced for JFR testing,  to run hotspot/test/vmtestbase.
    >
    >      I guess the JFR testing doesn't cover them. IMHO, we'd better fix them
    >      for jdk8u, Otherwise we will observe something strange when we really
    >      use them.
    >
    >      eg. The whitebox api isMethodCompilable doesn't work. It's because
    >      CompLevel_any=-1 in jdk8u. Whitebox APIs must be consistent with the
    >      implementation of hotspot.
    >
    >      thanks,
    >
    >      --lx
    >
    >
    >



From zgu at redhat.com  Fri Jun 19 18:58:09 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 19 Jun 2020 14:58:09 -0400
Subject: [8u] RFR 8177560: @headful key can be removed from the tests for
 JavaSound
Message-ID: <a1b65408-03cd-b83a-4e47-d5d0aeabdbd7@redhat.com>

Hi,

Please review this 8u backport for Oracle parity.

The original patch does not apply cleanly.

The only conflicts are in 
test/javax/sound/midi/Devices/InitializationHang.java file.
1) Copyright year does not match
2) 8u version does not have @headful key

Original bug: https://bugs.openjdk.java.net/browse/JDK-8177560
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/41703cb17ee1

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

Test:
   javax/sound on Linux x86_64

Thanks,

-Zhengyu



From gnu.andrew at redhat.com  Fri Jun 19 20:16:13 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 19 Jun 2020 21:16:13 +0100
Subject: Result: New OpenJDK 8 Updates Committer: Alex Kashchenko
Message-ID: <b6031f98-1291-c751-3d99-3b67f06cb60d@redhat.com>

Voting for Alex Kashchenko [0] is now closed.

Yes: 6
Veto: 0
Abstain: 0

Turnout: 3% (6/227)

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

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011806.html
[1] https://openjdk.java.net/bylaws#lazy-consensus
-- 
Andrew :)

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

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


From denghui.ddh at alibaba-inc.com  Sat Jun 20 11:09:14 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Sat, 20 Jun 2020 19:09:14 +0800
Subject: =?UTF-8?B?UmU6IFJGUiA4MjE3NjQ3OiBbYmFja3BvcnRdIEpGUjogcmVjb3JkaW5ncyBvbiAzMi1iaXQg?=
 =?UTF-8?B?c3lzdGVtcyB1bnJlYWRhYmxl?=
In-Reply-To: <190b0f8e-7858-c7c0-8601-7c574c08536e@redhat.com>
References: <4a094b57-300a-40d3-9def-4b83ac184a1a.denghui.ddh@alibaba-inc.com>,
 <190b0f8e-7858-c7c0-8601-7c574c08536e@redhat.com>
Message-ID: <cdb64e61-3349-4573-8ffc-62cc49bd385e.denghui.ddh@alibaba-inc.com>

Hi Andrew,
I have successfully built JFR on CentOS 7 i386, but I can't reproduce the problem.

According to the crash information you provided, it may be that JfrThreadLocal causes the JavaThread to become larger, 
but in my builds(fastdebug & slowdebug), the size of the java thread does not exceed 1024, so I did not encounter this problem.
And I guess it might be the compilation environment that causes this problem.

------------------------------------------------------------------
From:Andrew Hughes <gnu.andrew at redhat.com>
Send Time:2020?6?19?(???) 02:00
To:???(??) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable

On 16/06/2020 04:44, Denghui Dong wrote:
> Could I have a review of this backport?
> 
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8217647
> 
> Original fix from 11u:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/df5487678893
> 
> Webrev: http://cr.openjdk.java.net/~ddong/8217647/webrev.00/
> 
> Backport reasons:
> 1. Fix the unreadable problem on 32-bit in 8u
> 2. Make subsequent backport more smoothly
> 
> The patch cannot apply to 8u cleanly, there are two rejection part and one build failure:
> 
>  a) Conflict in jfrRecorderService.cpp. Patch wants this:
> 
> -static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> -  const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
> -  const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
> +static int64_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
> +  const int64_t prev_cp_offset = cw.previous_checkpoint_offset();
> +  const int64_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>    cw.reserve(sizeof(u4));
>    cw.write<u8>(EVENT_CHECKPOINT);
>    cw.write(JfrTicks::now());
> -  cw.write<jlong>((jlong)0);
> +  cw.write((int64_t)0);
>    cw.write(prev_cp_relative_offset); // write previous checkpoint offset delta
>    cw.write<bool>(false); // flushpoint
> -  cw.write<u4>((u4)1); // nof types in this checkpoint
> -  cw.write<u8>(type_id);
> -  const intptr_t number_of_elements_offset = cw.current_offset();
> +  cw.write((u4)1); // nof types in this checkpoint
> +  cw.write(type_id);
> +  const int64_t number_of_elements_offset = cw.current_offset();
>    cw.reserve(sizeof(u4));
>    return number_of_elements_offset;
>  }
> 
>  ... but the 8u code is:
> 
> static intptr_t write_checkpoint_event_prologue(JfrChunkWriter& cw, u8 type_id) {
>   const intptr_t prev_cp_offset = cw.previous_checkpoint_offset();
>   const intptr_t prev_cp_relative_offset = 0 == prev_cp_offset ? 0 : prev_cp_offset - cw.current_offset();
>   cw.reserve(sizeof(u4));
>   cw.write<u8>(EVENT_CHECKPOINT);
>   cw.write(JfrTicks::now());
>   cw.write<jlong>((jlong)0);
>   cw.write<jlong>((jlong)prev_cp_relative_offset); // write previous checkpoint offset delta
>   cw.write<bool>(false); // flushpoint
>   cw.write<u4>((u4)1); // nof types in this checkpoint
>   cw.write<u8>(type_id);
>   const intptr_t number_of_elements_offset = cw.current_offset();
>   cw.reserve(sizeof(u4));
>   return number_of_elements_offset;
> }
> 
>  ... I did a manual adjustment: 
>     cw.write<jlong>((jlong)prev_cp_relative_offset); => cw.write(prev_cp_relative_offset);
> 
>  b) Conflict in jfrWriterHost.inline.hpp. Patch wants this:
> 
>  template <typename BE, typename IE, typename WriterPolicyImpl>
>  inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
> -  be_write(*(uintptr_t*)&(value));
> +  be_write(*(u8*)&(value));
>  }
> 
>  ... but the 8u code is:
> 
> template <typename BE, typename IE, typename WriterPolicyImpl>
> inline void WriterHost<BE, IE, WriterPolicyImpl>::write(double value) {
>   be_write(*(u8*)&(value));
> }
> 
>  ... so I skipped it.
> 
>  c) Build failure. Patch wants this in jfrRepository.cpp:
> 
> +            log_info(jfr) ( // For user, should not be "jfr, system"
> +              "Unable to recover JFR data");
> +            break;
> 
>  ... but 8u didn't support unified logging, so I added "if (LogJFR) tty->print_cr("Unable to recover JFR data");"
> 
> 
>  d) Other Problem: the original patch(http://hg.openjdk.java.net/jdk/jdk/rev/0abec72a3ac2) also modified jfrChunkRotation.hpp?jfrChunkRotation.cpp and jfrJniMethod.cpp, but the backport patch for 11u ignored them(http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000921.html)
> 
> Thanks,
> Denghui Dong
> 

Thanks for the comprehensive analysis. It's really helpful in reviewing
this.

The changes in the patch look fine. I see you also omitted the changes
not in 11u. Was this intentional? I compared with the 11u version, so I
didn't notice this in reviewing the patch itself.

Incidentally, we haven't been building JFR on x86 so far, because it
crashed when I tried to build it:

/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.262.b02-0.2.ea.el7.i386/openjdk/build/jdk8.build-debug/images/j2sdk-image/bin/javac
-d . /builddir/build/SOURCES/TestCryptoLevel.java
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:1281
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.262.b02-0.2.ea.el7.i386/openjdk/hotspot/src/share/vm/runtime/os.cpp:1281),
pid=93916, tid=0xf6431b40
#  assert(SerializePageShiftCount == count) failed: thread size changed,
fix SerializePageShiftCount constant

TestCryptoLevel.java is a simple Java test we run on the just-built JDK
to check unlimited crypto is in use:

https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/master/f/TestCryptoLevel.java

I assumed from this that x86 wasn't supported, but if it should be
working, maybe we should look into this more.

Thanks,
-- 
Andrew :)

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

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


From zgu at redhat.com  Mon Jun 22 19:34:56 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 22 Jun 2020 15:34:56 -0400
Subject: [8u] RFR 8156169: Some sound tests rarely hangs because of incorrect
 synchronization
Message-ID: <62c24472-2657-bbc1-fc49-f0ebb2916ef8@redhat.com>

I would like to backport this patch, as Oracle 8u271 parity.

The original patch does not apply cleanly. Other than file path changes, 
there are a few copyright line conflicts.

One code conflict is in 
src/share/classes/javax/sound/midi/Sequence.java's getTracks() method. 
It appears 8u and 9u have different implementations.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8156169
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3dc009028cab


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

Test:
   javax/sound


Thanks,

-Zhengyu


From zgu at redhat.com  Tue Jun 23 01:00:03 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 22 Jun 2020 21:00:03 -0400
Subject: [8u] 8160217: JavaSound should clean up resources better
Message-ID: <e97c34fe-4d51-f68a-f7c4-5a46bf55a67e@redhat.com>

I would like to backport this patch to 8u, as Oracle 8u271 parity.

The original patch does not apply cleanly. Other than copyright line 
conflicts, following two tests [1][2] in 9u patch, do not exist in 8u.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8160217
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3c2bb0f0f129

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

Test:
   javax/sound

Thanks,

-Zhengyu



[1] 
test/javax/sound/sampled/AudioInputStream/FrameLengthAfterConversion.java
[2] 
test/javax/sound/sampled/spi/AudioFileWriter/WriteUnsupportedAudioFormat.java


From rwestrel at redhat.com  Tue Jun 23 07:44:21 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 23 Jun 2020 09:44:21 +0200
Subject: [8u] RFR 8156169: Some sound tests rarely hangs because of
 incorrect synchronization
In-Reply-To: <62c24472-2657-bbc1-fc49-f0ebb2916ef8@redhat.com>
References: <62c24472-2657-bbc1-fc49-f0ebb2916ef8@redhat.com>
Message-ID: <87366mw7je.fsf@redhat.com>


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

Looks good to me.

Roland.


From rwestrel at redhat.com  Tue Jun 23 07:57:42 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 23 Jun 2020 09:57:42 +0200
Subject: [8u] 8160217: JavaSound should clean up resources better
In-Reply-To: <e97c34fe-4d51-f68a-f7c4-5a46bf55a67e@redhat.com>
References: <e97c34fe-4d51-f68a-f7c4-5a46bf55a67e@redhat.com>
Message-ID: <87zh8uuscp.fsf@redhat.com>


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

That looks good.

Roland.


From sgehwolf at redhat.com  Tue Jun 23 07:53:38 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 23 Jun 2020 09:53:38 +0200
Subject: [8u] 8160217: JavaSound should clean up resources better
In-Reply-To: <e97c34fe-4d51-f68a-f7c4-5a46bf55a67e@redhat.com>
References: <e97c34fe-4d51-f68a-f7c4-5a46bf55a67e@redhat.com>
Message-ID: <4244c13ae0ac18bbf5918309aa2975e49ffcb085.camel@redhat.com>

On Mon, 2020-06-22 at 21:00 -0400, Zhengyu Gu wrote:
> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8160217-8u/webrev.00/

Some files are missing the Copyright update as done in the original
patch. We should add them, even though they might need to be done
manually.

Thanks,
Severin


From christoph.langer at sap.com  Tue Jun 23 09:45:51 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Jun 2020 09:45:51 +0000
Subject: RFD: What do we do about programs which set sys_paths to null?
In-Reply-To: <b80fdaff-403f-78ed-df2d-d0e5f39174f9@redhat.com>
References: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
 <AM0PR02MB5714E185E674D556F2F171898AD50@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com>
 <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com>
 <b80fdaff-403f-78ed-df2d-d0e5f39174f9@redhat.com>
Message-ID: <AM0PR02MB43375086FE1635EB240F2FD08A940@AM0PR02MB4337.eurprd02.prod.outlook.com>

Hi,

I was going through my mail backlog: Thanks for replying. I agree to keep the backport of JDK-8231584 in 11u, hoping that people transitioning to 11 can fix/update their code.

Cheers
Christoph

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Dienstag, 21. April 2020 18:05
> To: Severin Gehwolf <sgehwolf at redhat.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: RFD: What do we do about programs which set sys_paths to
> null?
> 
> On 4/21/20 4:40 PM, Severin Gehwolf wrote:
> > On Tue, 2020-04-21 at 16:19 +0100, Andrew Haley wrote:
> >> I think that we'd better keep 11 as it is, in the hope that people
> >> transitioning to 8 will also transition to fixing the code.
> >
> > s/8/11/
> 
> Ah, yes, transitioning to 11. Thx.
> 
> --
> 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 zgu at redhat.com  Tue Jun 23 16:40:29 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 23 Jun 2020 12:40:29 -0400
Subject: [8u] 8160217: JavaSound should clean up resources better
In-Reply-To: <4244c13ae0ac18bbf5918309aa2975e49ffcb085.camel@redhat.com>
References: <e97c34fe-4d51-f68a-f7c4-5a46bf55a67e@redhat.com>
 <4244c13ae0ac18bbf5918309aa2975e49ffcb085.camel@redhat.com>
Message-ID: <3245cc41-402b-2e05-f19e-02a36a9c4500@redhat.com>

Thanks for the reviews.

Indeed, I missed quite a few Copyright updates.

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

-Zhengyu

On 6/23/20 3:53 AM, Severin Gehwolf wrote:
> On Mon, 2020-06-22 at 21:00 -0400, Zhengyu Gu wrote:
>> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8160217-8u/webrev.00/
> 
> Some files are missing the Copyright update as done in the original
> patch. We should add them, even though they might need to be done
> manually.
> 
> Thanks,
> Severin
> 


From zgu at redhat.com  Tue Jun 23 18:17:33 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 23 Jun 2020 14:17:33 -0400
Subject: [8u] RFR 8156169: Some sound tests rarely hangs because of
 incorrect synchronization
In-Reply-To: <87366mw7je.fsf@redhat.com>
References: <62c24472-2657-bbc1-fc49-f0ebb2916ef8@redhat.com>
 <87366mw7je.fsf@redhat.com>
Message-ID: <1a542562-ffef-deed-dd37-168940169082@redhat.com>

Thanks, Roland.

-Zhengyu


On 6/23/20 3:44 AM, Roland Westrelin wrote:
> 
>> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8156169-8u/webrev.00/
> 
> Looks good to me.
> 
> Roland.
> 


From sgehwolf at redhat.com  Thu Jun 25 13:39:38 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 25 Jun 2020 15:39:38 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
Message-ID: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>

Hi,

Please review this OpenJDK 8u backport of JDK-8194298 which adds socket
configuration options for TCP keepalive. It's one of the Oracle JDK
parity patches.

As with the OpenJDK 11u change, this includes Linux and Mac only
changes. This backport is pretty much a rewrite as the JDK 11u codebase
is rather different in this area.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8194298
8u CSR: https://bugs.openjdk.java.net/browse/JDK-8236187
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/04/webrev/

Testing:
 * Build/test on Linux x86_64 and Mac OS x (thanks to Simon Tooke).
   Build on Windows x86_64 (also thanks to Simon Tooke)
 * tier1 tests,?test/java/nio test/java/net/ test/jdk/net/ on Linux
   x86_64. No regressions noted.

Thoughts?

Thanks,
Severin



From ecki at zusammenkunft.net  Thu Jun 25 23:55:04 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 25 Jun 2020 23:55:04 +0000
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
Message-ID: <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

This would be a great addition. I do not understand why it does not support the options available for Windows. Especially given the fact that it actually implements 6 native methods to print "Unsupported".

But I guess that's less a question to the backport and more to the general implementation.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Severin Gehwolf <sgehwolf at redhat.com>
Gesendet: Thursday, June 25, 2020 3:39:38 PM
An: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Cc: net-dev <net-dev at openjdk.java.net>
Betreff: [8u] RFR(m): 8194298: Add support for per Socket configuration of TCP keepalive

Hi,

Please review this OpenJDK 8u backport of JDK-8194298 which adds socket
configuration options for TCP keepalive. It's one of the Oracle JDK
parity patches.

As with the OpenJDK 11u change, this includes Linux and Mac only
changes. This backport is pretty much a rewrite as the JDK 11u codebase
is rather different in this area.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8194298
8u CSR: https://bugs.openjdk.java.net/browse/JDK-8236187
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/04/webrev/

Testing:
 * Build/test on Linux x86_64 and Mac OS x (thanks to Simon Tooke).
   Build on Windows x86_64 (also thanks to Simon Tooke)
 * tier1 tests, test/java/nio test/java/net/ test/jdk/net/ on Linux
   x86_64. No regressions noted.

Thoughts?

Thanks,
Severin



From sgehwolf at redhat.com  Fri Jun 26 07:35:03 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 26 Jun 2020 09:35:03 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>

Hi,

On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> This would be a great addition.

Thanks.

> I do not understand why it does not support the options available for
> Windows. Especially given the fact that it actually implements 6
> native methods to print "Unsupported".
> 
> But I guess that's less a question to the backport and more to the
> general implementation.

Yes, indeed. This should be brought up for discussion in JDK head first
and implemented there before we can consider a backport.

Thanks,
Severin



From gnu.andrew at redhat.com  Fri Jun 26 14:25:15 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 26 Jun 2020 15:25:15 +0100
Subject: [RFR] [8u262] JDK-8248399: Build installs jfr binary when JFR is
 disabled
Message-ID: <3d67dc76-2900-1cf2-36c9-06e86c3073d7@redhat.com>

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

At present, the build still creates and installs a jfr binary even when
JFR is disabled. Without jfr.jar, it is useless:

$ ~/builder/8u/images/j2sdk-image/bin/jfr
Error: Could not find or load main class jdk.jfr.internal.tool.Main

The fix is a simple conditional around the jfr launcher, as was added
for the profiles in CopyFiles.gmk, but missed in the backport of
JDK-8205516.

This should go into 8u262 before freeze at end of today, so I'll flag
with jdk8u-critical-request once reviewed.

Thanks,
-- 
Andrew :)

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

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


From sgehwolf at redhat.com  Fri Jun 26 15:37:01 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 26 Jun 2020 17:37:01 +0200
Subject: [RFR] [8u262] JDK-8248399: Build installs jfr binary when JFR
 is disabled
In-Reply-To: <ac16b3e7-eadb-7207-5fdf-edb398210de6@redhat.com>
References: <3d67dc76-2900-1cf2-36c9-06e86c3073d7@redhat.com>
 <ac16b3e7-eadb-7207-5fdf-edb398210de6@redhat.com>
Message-ID: <2cd8cc00ec9ef181fdbce9e5bf35ac781e2a6f0a.camel@redhat.com>

Hi Andrew,

On Fri, 2020-06-26 at 16:30 +0100, Andrew Hughes wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248399
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8248399/webrev.01/

This looks good to me.

> At present, the build still creates and installs a jfr binary even when
> JFR is disabled. Without jfr.jar, it is useless:
> 
> $ ~/builder/8u/images/j2sdk-image/bin/jfr
> Error: Could not find or load main class jdk.jfr.internal.tool.Main

Nice find.

> The fix is a simple conditional around the jfr launcher, as was added
> for the profiles in CopyFiles.gmk, but missed in the backport of
> JDK-8205516.
> 
> This should go into 8u262 before freeze at end of today, so I'll flag
> with jdk8u-critical-request once reviewed.

Please do.

Thanks,
Severin


From akashche at redhat.com  Fri Jun 26 22:30:51 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Fri, 26 Jun 2020 23:30:51 +0100
Subject: [8u] RFR: 8146215: (fs)
 java/nio/file/Files/probeContentType/Basic.java failed frequently on
 Solaris-sparc with Unexpected type: text/plain
Message-ID: <55ba423a-fec5-c67f-6f91-441dda37b9e5@redhat.com>

Hi,

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

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

9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/44bb7c7997ca

8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8146215/webrev.00/

8u code change is almost identical to 9, only copyright year is changed 
in AbstractFileTypeDetector.java. Test part doesn't apply cleanly, 
because probeContentType/Basic.java in 9 contains changes that are not 
in 8u (JDK-8129632 and others), it is adjusted for 8u. Testing: included 
test, jck:api/java_net;api/java_nio.


-- 
-Alex


From gnu.andrew at redhat.com  Mon Jun 29 06:27:10 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Jun 2020 07:27:10 +0100
Subject: [FREEZE] 8u262 NOW FROZEN
Message-ID: <12068e9e-7e07-9a93-e9a6-de9eedc2d0ec@redhat.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
The release forest:

https://hg.openjdk.java.net/jdk8u/jdk8u (and friends)

is now frozen in preparation for release on 2020-07-14.

I will push the final pre-release tag, jdk8u262-b09, once testing completes.

The final release tag will be no lower than jdk8u262-b10.

Thanks,
-- 
Andrew :)

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

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


From sgehwolf at redhat.com  Mon Jun 29 08:54:17 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Jun 2020 10:54:17 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
Message-ID: <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>

Hi Vyom!

On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> Hi Severin,
> 
> Overall code changes looks ok to me, I build & tested at my local REL
> it worked fine for me.

Thanks for the review!

> Below are few minor comments.
> 
> 1-> Net.java
>     1.1-> I think you don't need to explicitly convert value to integer and then pass it. You can avoid the local int variable creation as follows.
>       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd, (Integer)value);
>    1.2-> In getSocketOption you don't need to explicitly cast it to Integer.
>              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> 2-> PlainSocketImpl.java
>     1.1 -> In setOption(SocketOption<T> name, T value) you can avoid the local int variable.

Should all be fixed.

> 3-> Any specific reason for two set of functions "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three socket options ?

Not really, other than keeping the backport aligned to the JDK 11u
patch. I've updated it in the latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/

Thanks,
Severin


> Thanks,
> Vyom
> 
> On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi,
> > 
> > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > This would be a great addition.
> > 
> > Thanks.
> > 
> > > I do not understand why it does not support the options available for
> > > Windows. Especially given the fact that it actually implements 6
> > > native methods to print "Unsupported".
> > > 
> > > But I guess that's less a question to the backport and more to the
> > > general implementation.
> > 
> > Yes, indeed. This should be brought up for discussion in JDK head first
> > and implemented there before we can consider a backport.
> > 
> > Thanks,
> > Severin
> > 
> > 
> 
> 


From vyommani at gmail.com  Mon Jun 29 11:41:34 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Mon, 29 Jun 2020 17:11:34 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
Message-ID: <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>

Hi Severin,

Latest code looks good, I think in
src/solaris/native/java/net/ExtendedOptionsImpl.c, you don't need #ifdef
blocks. In case of "flowOption" it was required because flow is specific to
Solaris.

In case of KEEPALIVE we are using the POSIX api(setsockopt/getsockopt)
which exists on all POSIX OS's. If a  OS does not support KEEPALIVE then

Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will return
false and #else will never execute.

For Windows we have different files and for all other platforms same
code will work without explicit #ifdef.

Please do let me know if i am missing something.

Thanks,

Vyom



On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi Vyom!
>
> On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > Hi Severin,
> >
> > Overall code changes looks ok to me, I build & tested at my local REL
> > it worked fine for me.
>
> Thanks for the review!
>
> > Below are few minor comments.
> >
> > 1-> Net.java
> >     1.1-> I think you don't need to explicitly convert value to integer
> and then pass it. You can avoid the local int variable creation as follows.
> >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd, (Integer)value);
> >    1.2-> In getSocketOption you don't need to explicitly cast it to
> Integer.
> >              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > 2-> PlainSocketImpl.java
> >     1.1 -> In setOption(SocketOption<T> name, T value) you can avoid the
> local int variable.
>
> Should all be fixed.
>
> > 3-> Any specific reason for two set of functions "setTcpKeepAliveTime0
> and setTcpKeepAliveTime" for all three socket options ?
>
> Not really, other than keeping the backport aligned to the JDK 11u
> patch. I've updated it in the latest webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
>
> Thanks,
> Severin
>
>
> > Thanks,
> > Vyom
> >
> > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > > Hi,
> > >
> > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > This would be a great addition.
> > >
> > > Thanks.
> > >
> > > > I do not understand why it does not support the options available for
> > > > Windows. Especially given the fact that it actually implements 6
> > > > native methods to print "Unsupported".
> > > >
> > > > But I guess that's less a question to the backport and more to the
> > > > general implementation.
> > >
> > > Yes, indeed. This should be brought up for discussion in JDK head first
> > > and implemented there before we can consider a backport.
> > >
> > > Thanks,
> > > Severin
> > >
> > >
> >
> >
>
>

-- 
Thanks,
Vyom

From sgehwolf at redhat.com  Mon Jun 29 11:57:30 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Jun 2020 13:57:30 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
Message-ID: <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>

Hi Vyom,

On Mon, 2020-06-29 at 17:11 +0530, Vyom Tiwari wrote:
> Hi Severin,
> 
> Latest code looks good

Thanks!

> I think in src/solaris/native/java/net/ExtendedOptionsImpl.c, you
> don't need #ifdef blocks. In case of "flowOption" it was required
> because flow is specific to Solaris.
> 
> In case of KEEPALIVE we are using the POSIX
> api(setsockopt/getsockopt) which exists on all POSIX OS's. If a  OS
> does not support KEEPALIVE then 
> Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will
> return false and #else will never execute.
> For Windows we have different files and for all other platforms same
> code will work without explicit #ifdef.

Not quite.

For example, on MACOSX some macros have a diferent name than on Linux.
Thus, the ifdef magic to work around that. I don't have any insight as
to what they're called on, say, solaris or aix, or, if they're
different at all. Anyway, I'd rely on somebody else doing the testing.
Without that, I don't think we can add this to other platforms and
potentially break them. Support for them could get added later if
somebody with the relevant systems steps up to do it.

> Please do let me know if i am missing something.

FWIW, those options are only enabled on Linux/Mac for JDK 11u and
jdk/jdk. Those changes would have to be done there first and then
backported.

Thanks,
Severin

> 
> On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > Hi Vyom!
> > 
> > On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > > Hi Severin,
> > > 
> > > Overall code changes looks ok to me, I build & tested at my local
> > REL
> > > it worked fine for me.
> > 
> > Thanks for the review!
> > 
> > > Below are few minor comments.
> > > 
> > > 1-> Net.java
> > >     1.1-> I think you don't need to explicitly convert value to
> > integer and then pass it. You can avoid the local int variable
> > creation as follows.
> > >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd,
> > (Integer)value);
> > >    1.2-> In getSocketOption you don't need to explicitly cast it
> > to Integer.
> > >              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > > 2-> PlainSocketImpl.java
> > >     1.1 -> In setOption(SocketOption<T> name, T value) you can
> > avoid the local int variable.
> > 
> > Should all be fixed.
> > 
> > > 3-> Any specific reason for two set of functions
> > "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three socket
> > options ?
> > 
> > Not really, other than keeping the backport aligned to the JDK 11u
> > patch. I've updated it in the latest webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
> > 
> > Thanks,
> > Severin
> > 
> > 
> > > Thanks,
> > > Vyom
> > > 
> > > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <
> > sgehwolf at redhat.com> wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > > This would be a great addition.
> > > > 
> > > > Thanks.
> > > > 
> > > > > I do not understand why it does not support the options
> > available for
> > > > > Windows. Especially given the fact that it actually
> > implements 6
> > > > > native methods to print "Unsupported".
> > > > > 
> > > > > But I guess that's less a question to the backport and more
> > to the
> > > > > general implementation.
> > > > 
> > > > Yes, indeed. This should be brought up for discussion in JDK
> > head first
> > > > and implemented there before we can consider a backport.
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 


From gnu.andrew at redhat.com  Mon Jun 29 12:47:37 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Jun 2020 13:47:37 +0100
Subject: [8u] RFR: 8146215: (fs)
 java/nio/file/Files/probeContentType/Basic.java failed frequently on
 Solaris-sparc with Unexpected type: text/plain
In-Reply-To: <55ba423a-fec5-c67f-6f91-441dda37b9e5@redhat.com>
References: <55ba423a-fec5-c67f-6f91-441dda37b9e5@redhat.com>
Message-ID: <ff8d0ad5-d298-76eb-1bfb-5172ed1846f3@redhat.com>

On 26/06/2020 23:30, Alex Kashchenko wrote:
> Hi,
> 
> Please review the backport of JDK-8146215 to 8u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146215
> 
> 9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/44bb7c7997ca
> 
> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8146215/webrev.00/
> 
> 8u code change is almost identical to 9, only copyright year is changed
> in AbstractFileTypeDetector.java. Test part doesn't apply cleanly,
> because probeContentType/Basic.java in 9 contains changes that are not
> in 8u (JDK-8129632 and others), it is adjusted for 8u. Testing: included
> test, jck:api/java_net;api/java_nio.
> 
> 

Hi Alex,

The class library code changes look fine.

For the testing, I think JDK-8150204 should at least be backported
first. It's a test-only change, and you're effectively doing that in
this patch, but uncredited. I can understand the reluctance to backport
the Mac OS X fix, JDK-8129632, so I'm happy for the 8150204 backport to
just take the testing changes from 8129632 as part of it, or work around
them as you have here.

Once 8150204 is in place, this backport should be close to the 11u version.

Thanks,
-- 
Andrew :)

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

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


From vyommani at gmail.com  Mon Jun 29 15:48:07 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Mon, 29 Jun 2020 21:18:07 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
 <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
Message-ID: <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>

Hi Severin,

thanks for clarification, we can still simplify the ExtendedOptionsImpl.c.
Please have a look on below change and do let me know if it makes sense.

I moved the "#if defined(__linux__) || defined(MACOSX)" inside the
corresponding  methods and this way we will eliminate lot's of duplicate
code.

Thanks,
Vyom
diff -r beb15266ba1a src/solaris/native/java/net/ExtendedOptionsImpl.c
--- a/src/solaris/native/java/net/ExtendedOptionsImpl.c Thu Feb 27 19:01:36
2020 +0000
+++ b/src/solaris/native/java/net/ExtendedOptionsImpl.c Mon Jun 29 21:12:16
2020 +0530
@@ -25,6 +25,10 @@

 #include <jni.h>
 #include <string.h>
+#if defined(__linux__) || defined(MACOSX)
+#include <netinet/tcp.h>
+#include <netinet/in.h>
+#endif

 #include "net_util.h"
 #include "jdk_net_SocketFlow.h"
@@ -328,9 +332,204 @@
     return JNI_FALSE;
 }

+// Keep alive options are available for MACOSX and Linux only for
+// the time being.
+#if defined(__linux__) || defined(MACOSX)
+
+// Map socket option level/name to OS specific constant
+#ifdef __linux__
+#define SOCK_OPT_LEVEL SOL_TCP
+#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPIDLE
+#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPIDLE"
+#endif
+#ifdef MACOSX
+#define SOCK_OPT_LEVEL IPPROTO_TCP
+#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPALIVE
+#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPALIVE"
+#endif
+
+static jint socketOptionSupported(jint sockopt) {
+    jint one = 1;
+    jint rv, s;
+    s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
+    if (s < 0) {
+        return 0;
+    }
+    rv = setsockopt(s, SOCK_OPT_LEVEL, sockopt, (void *) &one, sizeof
(one));
+    if (rv != 0 && errno == ENOPROTOOPT) {
+        rv = 0;
+    } else {
+        rv = 1;
+    }
+    close(s);
+    return rv;
+}
+
+static void handleError(JNIEnv *env, jint rv, const char *errmsg) {
+    if (rv < 0) {
+        if (errno == ENOPROTOOPT) {
+            JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
+                    "unsupported socket option");
+        } else {
+            JNU_ThrowByNameWithLastError(env, "java/net/SocketException",
errmsg);
+        }
+    }
+}
+
+#endif /* __linux__ || MACOSX*/
+
 #endif /* __solaris__ */

 JNIEXPORT jboolean JNICALL Java_sun_net_ExtendedOptionsImpl_flowSupported
   (JNIEnv *env, jclass UNUSED) {
     return flowSupported0();
 }
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    keepAliveOptionsSupported
+ * Signature: ()Z
+ */
+JNIEXPORT jboolean JNICALL
Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported
+(JNIEnv *env, jobject unused) {
+    #if defined(__linux__) || defined(MACOSX)
+        return socketOptionSupported(SOCK_OPT_NAME_KEEPIDLE) &&
socketOptionSupported(TCP_KEEPCNT)
+                && socketOptionSupported(TCP_KEEPINTVL);
+    #else
+        return JNI_FALSE;
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    setTcpKeepAliveProbes
+ * Signature: (Ljava/io/FileDescriptor;I)V
+ */
+JNIEXPORT void JNICALL
Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveProbes
+(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return;
+        } else {
+            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT, &optval,
sizeof (optval));
+            handleError(env, rv, "set option TCP_KEEPCNT failed");
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    setTcpKeepAliveTime
+ * Signature: (Ljava/io/FileDescriptor;I)V
+ */
+JNIEXPORT void JNICALL Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveTime
+(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return;
+        } else {
+            jint rv = setsockopt(fd, SOCK_OPT_LEVEL,
SOCK_OPT_NAME_KEEPIDLE, &optval, sizeof (optval));
+            handleError(env, rv, "set option " SOCK_OPT_NAME_KEEPIDLE_STR
" failed");
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    setTcpKeepAliveIntvl
+ * Signature: (Ljava/io/FileDescriptor;I)V
+ */
+JNIEXPORT void JNICALL
Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveIntvl
+(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return;
+        } else {
+            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL,
&optval, sizeof (optval));
+            handleError(env, rv, "set option TCP_KEEPINTVL failed");
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    getTcpKeepAliveProbes
+ * Signature: (Ljava/io/FileDescriptor;)I
+ */
+JNIEXPORT jint JNICALL
Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveProbes
+(JNIEnv *env, jobject unused, jobject fileDesc) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return -1;
+        } else {
+            jint optval, rv;
+            socklen_t sz = sizeof (optval);
+            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT, &optval, &sz);
+            handleError(env, rv, "get option TCP_KEEPCNT failed");
+            return optval;
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    getTcpKeepAliveTime
+ * Signature: (Ljava/io/FileDescriptor;)I
+ */
+JNIEXPORT jint JNICALL Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveTime
+(JNIEnv *env, jobject unused, jobject fileDesc) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return -1;
+        } else {
+            jint optval, rv;
+            socklen_t sz = sizeof (optval);
+            rv = getsockopt(fd, SOCK_OPT_LEVEL, SOCK_OPT_NAME_KEEPIDLE,
&optval, &sz);
+            handleError(env, rv, "get option " SOCK_OPT_NAME_KEEPIDLE_STR
" failed");
+            return optval;
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    getTcpKeepAliveIntvl
+ * Signature: (Ljava/io/FileDescriptor;)I
+ */
+JNIEXPORT jint JNICALL
Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveIntvl
+(JNIEnv *env, jobject unused, jobject fileDesc) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return -1;
+        } else {
+            jint optval, rv;
+            socklen_t sz = sizeof (optval);
+            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL, &optval,
&sz);
+            handleError(env, rv, "get option TCP_KEEPINTVL failed");
+            return optval;
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}

On Mon, Jun 29, 2020 at 5:27 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi Vyom,
>
> On Mon, 2020-06-29 at 17:11 +0530, Vyom Tiwari wrote:
> > Hi Severin,
> >
> > Latest code looks good
>
> Thanks!
>
> > I think in src/solaris/native/java/net/ExtendedOptionsImpl.c, you
> > don't need #ifdef blocks. In case of "flowOption" it was required
> > because flow is specific to Solaris.
> >
> > In case of KEEPALIVE we are using the POSIX
> > api(setsockopt/getsockopt) which exists on all POSIX OS's. If a  OS
> > does not support KEEPALIVE then
> > Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will
> > return false and #else will never execute.
> > For Windows we have different files and for all other platforms same
> > code will work without explicit #ifdef.
>
> Not quite.
>
> For example, on MACOSX some macros have a diferent name than on Linux.
> Thus, the ifdef magic to work around that. I don't have any insight as
> to what they're called on, say, solaris or aix, or, if they're
> different at all. Anyway, I'd rely on somebody else doing the testing.
> Without that, I don't think we can add this to other platforms and
> potentially break them. Support for them could get added later if
> somebody with the relevant systems steps up to do it.
>
> > Please do let me know if i am missing something.
>
> FWIW, those options are only enabled on Linux/Mac for JDK 11u and
> jdk/jdk. Those changes would have to be done there first and then
> backported.
>
> Thanks,
> Severin
>
> >
> > On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <sgehwolf at redhat.com>
> > wrote:
> > > Hi Vyom!
> > >
> > > On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > > > Hi Severin,
> > > >
> > > > Overall code changes looks ok to me, I build & tested at my local
> > > REL
> > > > it worked fine for me.
> > >
> > > Thanks for the review!
> > >
> > > > Below are few minor comments.
> > > >
> > > > 1-> Net.java
> > > >     1.1-> I think you don't need to explicitly convert value to
> > > integer and then pass it. You can avoid the local int variable
> > > creation as follows.
> > > >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd,
> > > (Integer)value);
> > > >    1.2-> In getSocketOption you don't need to explicitly cast it
> > > to Integer.
> > > >              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > > > 2-> PlainSocketImpl.java
> > > >     1.1 -> In setOption(SocketOption<T> name, T value) you can
> > > avoid the local int variable.
> > >
> > > Should all be fixed.
> > >
> > > > 3-> Any specific reason for two set of functions
> > > "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three socket
> > > options ?
> > >
> > > Not really, other than keeping the backport aligned to the JDK 11u
> > > patch. I've updated it in the latest webrev:
> > >
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
> > >
> > > Thanks,
> > > Severin
> > >
> > >
> > > > Thanks,
> > > > Vyom
> > > >
> > > > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <
> > > sgehwolf at redhat.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > > > This would be a great addition.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > > I do not understand why it does not support the options
> > > available for
> > > > > > Windows. Especially given the fact that it actually
> > > implements 6
> > > > > > native methods to print "Unsupported".
> > > > > >
> > > > > > But I guess that's less a question to the backport and more
> > > to the
> > > > > > general implementation.
> > > > >
> > > > > Yes, indeed. This should be brought up for discussion in JDK
> > > head first
> > > > > and implemented there before we can consider a backport.
> > > > >
> > > > > Thanks,
> > > > > Severin
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>

-- 
Thanks,
Vyom

From sgehwolf at redhat.com  Mon Jun 29 16:06:09 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Jun 2020 18:06:09 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
 <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
 <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>
Message-ID: <26e51ac19f9e9fc445d95f4180bf5da5e3b32c87.camel@redhat.com>

Hi Yyom,

On Mon, 2020-06-29 at 21:18 +0530, Vyom Tiwari wrote:
> Hi Severin,
> 
> thanks for clarification, we can still simplify the
> ExtendedOptionsImpl.c. Please have a look on below change and do let
> me know if it makes sense.
> 
> I moved the "#if defined(__linux__) || defined(MACOSX)" inside the
> corresponding  methods and this way we will eliminate lot's of
> duplicate code.

It's a possibility. IMHO, it doesn't really make the code easier to
read, though. Some duplication for clarity seems OK to me in this case.
I'm not too fond of over-use of ifdef so I'd rather keep it at v5.
YMMV.

Let's see what others think.

Thanks,
Severin

> Thanks,
> Vyom
> diff -r beb15266ba1a
> src/solaris/native/java/net/ExtendedOptionsImpl.c
> --- a/src/solaris/native/java/net/ExtendedOptionsImpl.c Thu Feb 27
> 19:01:36 2020 +0000
> +++ b/src/solaris/native/java/net/ExtendedOptionsImpl.c Mon Jun 29
> 21:12:16 2020 +0530
> @@ -25,6 +25,10 @@
>  
>  #include <jni.h>
>  #include <string.h>
> +#if defined(__linux__) || defined(MACOSX)
> +#include <netinet/tcp.h>
> +#include <netinet/in.h>
> +#endif
>  
>  #include "net_util.h"
>  #include "jdk_net_SocketFlow.h"
> @@ -328,9 +332,204 @@
>      return JNI_FALSE;
>  }
>  
> +// Keep alive options are available for MACOSX and Linux only for
> +// the time being.
> +#if defined(__linux__) || defined(MACOSX)
> +
> +// Map socket option level/name to OS specific constant
> +#ifdef __linux__
> +#define SOCK_OPT_LEVEL SOL_TCP
> +#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPIDLE
> +#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPIDLE"
> +#endif
> +#ifdef MACOSX
> +#define SOCK_OPT_LEVEL IPPROTO_TCP
> +#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPALIVE
> +#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPALIVE"
> +#endif
> +
> +static jint socketOptionSupported(jint sockopt) {
> +    jint one = 1;
> +    jint rv, s;
> +    s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
> +    if (s < 0) {
> +        return 0;
> +    }
> +    rv = setsockopt(s, SOCK_OPT_LEVEL, sockopt, (void *) &one,
> sizeof (one));
> +    if (rv != 0 && errno == ENOPROTOOPT) {
> +        rv = 0;
> +    } else {
> +        rv = 1;
> +    }
> +    close(s);
> +    return rv;
> +}
> +
> +static void handleError(JNIEnv *env, jint rv, const char *errmsg) {
> +    if (rv < 0) {
> +        if (errno == ENOPROTOOPT) {
> +            JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException",
> +                    "unsupported socket option");
> +        } else {
> +            JNU_ThrowByNameWithLastError(env,
> "java/net/SocketException", errmsg);
> +        }
> +    }
> +}
> +
> +#endif /* __linux__ || MACOSX*/
> +
>  #endif /* __solaris__ */
>  
>  JNIEXPORT jboolean JNICALL
> Java_sun_net_ExtendedOptionsImpl_flowSupported
>    (JNIEnv *env, jclass UNUSED) {
>      return flowSupported0();
>  }
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    keepAliveOptionsSupported
> + * Signature: ()Z
> + */
> +JNIEXPORT jboolean JNICALL
> Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported
> +(JNIEnv *env, jobject unused) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        return socketOptionSupported(SOCK_OPT_NAME_KEEPIDLE) &&
> socketOptionSupported(TCP_KEEPCNT)
> +                && socketOptionSupported(TCP_KEEPINTVL);
> +    #else
> +        return JNI_FALSE;
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    setTcpKeepAliveProbes
> + * Signature: (Ljava/io/FileDescriptor;I)V
> + */
> +JNIEXPORT void JNICALL
> Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveProbes
> +(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return;
> +        } else {
> +            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT,
> &optval, sizeof (optval));
> +            handleError(env, rv, "set option TCP_KEEPCNT failed");
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    setTcpKeepAliveTime
> + * Signature: (Ljava/io/FileDescriptor;I)V
> + */
> +JNIEXPORT void JNICALL
> Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveTime
> +(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return;
> +        } else {
> +            jint rv = setsockopt(fd, SOCK_OPT_LEVEL,
> SOCK_OPT_NAME_KEEPIDLE, &optval, sizeof (optval));
> +            handleError(env, rv, "set option "
> SOCK_OPT_NAME_KEEPIDLE_STR " failed");
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    setTcpKeepAliveIntvl
> + * Signature: (Ljava/io/FileDescriptor;I)V
> + */
> +JNIEXPORT void JNICALL
> Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveIntvl
> +(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return;
> +        } else {
> +            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL,
> &optval, sizeof (optval));
> +            handleError(env, rv, "set option TCP_KEEPINTVL failed");
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    getTcpKeepAliveProbes
> + * Signature: (Ljava/io/FileDescriptor;)I
> + */
> +JNIEXPORT jint JNICALL
> Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveProbes
> +(JNIEnv *env, jobject unused, jobject fileDesc) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return -1;
> +        } else {
> +            jint optval, rv;
> +            socklen_t sz = sizeof (optval);
> +            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT,
> &optval, &sz);
> +            handleError(env, rv, "get option TCP_KEEPCNT failed");
> +            return optval;
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    getTcpKeepAliveTime
> + * Signature: (Ljava/io/FileDescriptor;)I
> + */
> +JNIEXPORT jint JNICALL
> Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveTime
> +(JNIEnv *env, jobject unused, jobject fileDesc) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return -1;
> +        } else {
> +            jint optval, rv;
> +            socklen_t sz = sizeof (optval);
> +            rv = getsockopt(fd, SOCK_OPT_LEVEL,
> SOCK_OPT_NAME_KEEPIDLE, &optval, &sz);
> +            handleError(env, rv, "get option "
> SOCK_OPT_NAME_KEEPIDLE_STR " failed");
> +            return optval;
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    getTcpKeepAliveIntvl
> + * Signature: (Ljava/io/FileDescriptor;)I
> + */
> +JNIEXPORT jint JNICALL
> Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveIntvl
> +(JNIEnv *env, jobject unused, jobject fileDesc) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return -1;
> +        } else {
> +            jint optval, rv;
> +            socklen_t sz = sizeof (optval);
> +            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL,
> &optval, &sz);
> +            handleError(env, rv, "get option TCP_KEEPINTVL failed");
> +            return optval;
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> 
> On Mon, Jun 29, 2020 at 5:27 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > Hi Vyom,
> > 
> > On Mon, 2020-06-29 at 17:11 +0530, Vyom Tiwari wrote:
> > > Hi Severin,
> > > 
> > > Latest code looks good
> > 
> > Thanks!
> > 
> > > I think in src/solaris/native/java/net/ExtendedOptionsImpl.c, you
> > > don't need #ifdef blocks. In case of "flowOption" it was required
> > > because flow is specific to Solaris.
> > > 
> > > In case of KEEPALIVE we are using the POSIX
> > > api(setsockopt/getsockopt) which exists on all POSIX OS's. If a 
> > OS
> > > does not support KEEPALIVE then 
> > > Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will
> > > return false and #else will never execute.
> > > For Windows we have different files and for all other platforms
> > same
> > > code will work without explicit #ifdef.
> > 
> > Not quite.
> > 
> > For example, on MACOSX some macros have a diferent name than on
> > Linux.
> > Thus, the ifdef magic to work around that. I don't have any insight
> > as
> > to what they're called on, say, solaris or aix, or, if they're
> > different at all. Anyway, I'd rely on somebody else doing the
> > testing.
> > Without that, I don't think we can add this to other platforms and
> > potentially break them. Support for them could get added later if
> > somebody with the relevant systems steps up to do it.
> > 
> > > Please do let me know if i am missing something.
> > 
> > FWIW, those options are only enabled on Linux/Mac for JDK 11u and
> > jdk/jdk. Those changes would have to be done there first and then
> > backported.
> > 
> > Thanks,
> > Severin
> > 
> > > 
> > > On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <
> > sgehwolf at redhat.com>
> > > wrote:
> > > > Hi Vyom!
> > > > 
> > > > On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > > > > Hi Severin,
> > > > > 
> > > > > Overall code changes looks ok to me, I build & tested at my
> > local
> > > > REL
> > > > > it worked fine for me.
> > > > 
> > > > Thanks for the review!
> > > > 
> > > > > Below are few minor comments.
> > > > > 
> > > > > 1-> Net.java
> > > > >     1.1-> I think you don't need to explicitly convert value
> > to
> > > > integer and then pass it. You can avoid the local int variable
> > > > creation as follows.
> > > > >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd,
> > > > (Integer)value);
> > > > >    1.2-> In getSocketOption you don't need to explicitly cast
> > it
> > > > to Integer.
> > > > >              return
> > ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > > > > 2-> PlainSocketImpl.java
> > > > >     1.1 -> In setOption(SocketOption<T> name, T value) you
> > can
> > > > avoid the local int variable.
> > > > 
> > > > Should all be fixed.
> > > > 
> > > > > 3-> Any specific reason for two set of functions
> > > > "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three
> > socket
> > > > options ?
> > > > 
> > > > Not really, other than keeping the backport aligned to the JDK
> > 11u
> > > > patch. I've updated it in the latest webrev:
> > > > 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> > > > > Thanks,
> > > > > Vyom
> > > > > 
> > > > > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <
> > > > sgehwolf at redhat.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > > > > This would be a great addition.
> > > > > > 
> > > > > > Thanks.
> > > > > > 
> > > > > > > I do not understand why it does not support the options
> > > > available for
> > > > > > > Windows. Especially given the fact that it actually
> > > > implements 6
> > > > > > > native methods to print "Unsupported".
> > > > > > > 
> > > > > > > But I guess that's less a question to the backport and
> > more
> > > > to the
> > > > > > > general implementation.
> > > > > > 
> > > > > > Yes, indeed. This should be brought up for discussion in
> > JDK
> > > > head first
> > > > > > and implemented there before we can consider a backport.
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 


From aph at redhat.com  Mon Jun 29 17:34:19 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 29 Jun 2020 18:34:19 +0100
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <26e51ac19f9e9fc445d95f4180bf5da5e3b32c87.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
 <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
 <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>
 <26e51ac19f9e9fc445d95f4180bf5da5e3b32c87.camel@redhat.com>
Message-ID: <d1294037-8b96-6c01-a563-75ae75a6ce63@redhat.com>

On 29/06/2020 17:06, Severin Gehwolf wrote:
> It's a possibility. IMHO, it doesn't really make the code easier to
> read, though. Some duplication for clarity seems OK to me in this case.
> I'm not too fond of over-use of ifdef so I'd rather keep it at v5.
> YMMV.

OK.

-- 
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 zgu at redhat.com  Mon Jun 29 18:08:28 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 29 Jun 2020 14:08:28 -0400
Subject: [8u] RFR 8240295: hs_err elapsed time in seconds is not accurate
 enough
Message-ID: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com>

I would like to backport this patch to 11u for parity with Oracle 8u271.

The original patch does not apply cleanly.

There is one conflict, where 8u (unpatched) misses leading space on 
following message:

st->print_cr(" elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, 
eldays, elhours, elmins, elsecs);


Original bug: https://bugs.openjdk.java.net/browse/JDK-8240295
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/8a14919d365d

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

Thanks,

-Zhengyu


From zgu at redhat.com  Mon Jun 29 19:55:41 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 29 Jun 2020 15:55:41 -0400
Subject: [8u] 8217606: LdapContext#reconnect always opens a new connection
Message-ID: <2839b24f-a29c-3f4a-edef-97a9ac3bc06a@redhat.com>

Hi,

I would like to backport this patch to 8u for Oracle 8u271 parity.

The original patch does not apply cleanly.

LdapCtx.java:
8u does not have 'reconnect' member, so removing the variable lines do 
not apply.

Reconnect.java:
Uses try-catch-with-resource statement, which does not exist in 8u. 
Converted to try-catch-finally.
Uses 'var' language feature, which does not exist in 8u. Converted 
accordingly.

BaseLdapServer.java:
The same issues as Reconnect.java, fixed accordingly.
Uses System.Logger, which does not exist in 8u. Converted to 
java.util.logging.Logger.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8217606
Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4

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

Test:
   test/com/sun/jndi/ldap/LdapCtx/Reconnect.java

Thanks,

-Zhengyu





From sergei.tsypanov at yandex.ru  Tue Jun 30 06:57:07 2020
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 30 Jun 2020 08:57:07 +0200
Subject: [PATCH] Gentle reminder about backport of JDK-8054221 into JDK 8u
Message-ID: <966041593499986@mail.yandex.ru>

Hello,

on the 8th of May I sent the email regarding backport of JDK-8054221 into JDK 8u.

Here's the link: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011665.html

There is a patch attached to that mail, so I'd like to ask is there any problem with that patch
 and if it is, then could someone point it out?

In case there's no problem can we accept it and include into the next JDK 8u release?

With best regards,
Sergey Tsypanov



From thomas.schatzl at oracle.com  Tue Jun 30 08:35:49 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Jun 2020 10:35:49 +0200
Subject: [8u] RFR 8240295: hs_err elapsed time in seconds is not accurate
 enough
In-Reply-To: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com>
References: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com>
Message-ID: <28e3a485-bb2a-9489-c54c-2fd165017ac9@oracle.com>

Hi,

On 29.06.20 20:08, Zhengyu Gu wrote:
> I would like to backport this patch to 11u for parity with Oracle 8u271.
> 
> The original patch does not apply cleanly.
> 
> There is one conflict, where 8u (unpatched) misses leading space on 
> following message:
> 
> st->print_cr(" elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, 
> eldays, elhours, elmins, elsecs);
> 
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8240295
> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/8a14919d365d
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8243029-8u/webrev.00/
> 
> Thanks,
> 
> -Zhengyu
> 

   lgtm.

Thomas

From akashche at redhat.com  Tue Jun 30 12:15:21 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 30 Jun 2020 13:15:21 +0100
Subject: [8u] RFR: 8150204: (fs) Enhance
 java/nio/file/Files/probeContentType/Basic.java debugging output
Message-ID: <e890ce04-e470-eeb7-74ab-65dc12f21c0b@redhat.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
Hi,

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

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

Related thread: 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012055.html

9 change: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e4af8119eba4

8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8150204/webrev.00/

This change is a prerequisite to JDK-8146215, only test code is changed, 
patch requires adjustments for 8u because it includes changes from 
JDK-8129632 that is not in 8u, macOS-specific part is omitted.

-- 
-Alex


From zgu at redhat.com  Tue Jun 30 12:15:05 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 30 Jun 2020 08:15:05 -0400
Subject: [8u] RFR 8240295: hs_err elapsed time in seconds is not accurate
 enough
In-Reply-To: <28e3a485-bb2a-9489-c54c-2fd165017ac9@oracle.com>
References: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com>
 <28e3a485-bb2a-9489-c54c-2fd165017ac9@oracle.com>
Message-ID: <169c67c9-8720-b656-e4d6-1671cb49c0dc@redhat.com>

Thanks for reviewing, Thomas

-Zhengyu

On 6/30/20 4:35 AM, Thomas Schatzl wrote:
> Hi,
> 
> On 29.06.20 20:08, Zhengyu Gu wrote:
>> I would like to backport this patch to 11u for parity with Oracle 8u271.
>>
>> The original patch does not apply cleanly.
>>
>> There is one conflict, where 8u (unpatched) misses leading space on 
>> following message:
>>
>> st->print_cr(" elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, 
>> eldays, elhours, elmins, elsecs);
>>
>>
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8240295
>> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/8a14919d365d
>>
>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8243029-8u/webrev.00/
>>
>> Thanks,
>>
>> -Zhengyu
>>
> 
>  ? lgtm.
> 
> Thomas
> 


From akashche at redhat.com  Tue Jun 30 12:19:41 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 30 Jun 2020 13:19:41 +0100
Subject: [8u] RFR: 8146215: (fs)
 java/nio/file/Files/probeContentType/Basic.java failed frequently on
 Solaris-sparc with Unexpected type: text/plain
In-Reply-To: <ff8d0ad5-d298-76eb-1bfb-5172ed1846f3@redhat.com>
References: <55ba423a-fec5-c67f-6f91-441dda37b9e5@redhat.com>
 <ff8d0ad5-d298-76eb-1bfb-5172ed1846f3@redhat.com>
Message-ID: <69a581fe-4067-56bb-1d22-80ea2b7ac277@redhat.com>

On 06/29/2020 01:47 PM, Andrew Hughes wrote:
> On 26/06/2020 23:30, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review the backport of JDK-8146215 to 8u:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146215
>>
>> 9 commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/44bb7c7997ca
>>
>> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8146215/webrev.00/
>>
>> 8u code change is almost identical to 9, only copyright year is changed
>> in AbstractFileTypeDetector.java. Test part doesn't apply cleanly,
>> because probeContentType/Basic.java in 9 contains changes that are not
>> in 8u (JDK-8129632 and others), it is adjusted for 8u. Testing: included
>> test, jck:api/java_net;api/java_nio.
>>
>>
> 
> Hi Alex,
> 
> The class library code changes look fine.
> 
> For the testing, I think JDK-8150204 should at least be backported
> first. It's a test-only change, and you're effectively doing that in
> this patch, but uncredited. I can understand the reluctance to backport
> the Mac OS X fix, JDK-8129632, so I'm happy for the 8150204 backport to
> just take the testing changes from 8129632 as part of it, or work around
> them as you have here.
> 
> Once 8150204 is in place, this backport should be close to the 11u version.

Thanks for your comments! I've posted 8150204 for review:

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012063.html


-- 
-Alex


From kliberti at redhat.com  Mon Jun 22 21:11:21 2020
From: kliberti at redhat.com (Kyle Liberti)
Date: Mon, 22 Jun 2020 17:11:21 -0400
Subject: OperatingSystemMXBean backport to OpenJDK 8u261
Message-ID: <CAFrocT0cGt8HJA6+6HpgB4QgXMEcGs84=OpoDtnavDSPoMBEcw@mail.gmail.com>

Hi all,

I was looking at the "OperatingSystemMXBean should be made container aware"
issue here [1] and noticed that the patch was listed to be backported to
openjdk 8u261 [2] However, I can't seem to find the commit or patch in the
OpenJDK 8 source [3] [4]

   - Was the OperatingSystemMXBean patch [1] backported to OpenJDK 8?
   - Is 8u261 a real version? I can't seem to find the release in the
   OpenJDK source tags

All the best,

Kyle

[1] https://bugs.openjdk.java.net/browse/JDK-8226575
[2] https://bugs.openjdk.java.net/browse/JDK-8242287
[3] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/
[4] http://hg.openjdk.java.net/jdk8u/jdk8u/

From vyommani at gmail.com  Fri Jun 26 07:11:39 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 26 Jun 2020 12:41:39 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <CAKysZ8yC71tjT2V6rc=-n6H2KGDMw-=FdtyHKgDmfihu=m2Tmg@mail.gmail.com>

Hi Bernd,

When we added these socket options to JDK, that time these options were not
available on Windows.

Thanks,
Vyom


On Fri, Jun 26, 2020 at 7:12 AM Bernd Eckenfels <ecki at zusammenkunft.net>
wrote:

> Hello,
>
> This would be a great addition. I do not understand why it does not
> support the options available for Windows. Especially given the fact that
> it actually implements 6 native methods to print "Unsupported".
>
> But I guess that's less a question to the backport and more to the general
> implementation.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ------------------------------
> *Von:* net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Severin
> Gehwolf <sgehwolf at redhat.com>
> *Gesendet:* Thursday, June 25, 2020 3:39:38 PM
> *An:* jdk8u-dev <jdk8u-dev at openjdk.java.net>
> *Cc:* net-dev <net-dev at openjdk.java.net>
> *Betreff:* [8u] RFR(m): 8194298: Add support for per Socket configuration
> of TCP keepalive
>
> Hi,
>
> Please review this OpenJDK 8u backport of JDK-8194298 which adds socket
> configuration options for TCP keepalive. It's one of the Oracle JDK
> parity patches.
>
> As with the OpenJDK 11u change, this includes Linux and Mac only
> changes. This backport is pretty much a rewrite as the JDK 11u codebase
> is rather different in this area.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8194298
> 8u CSR: https://bugs.openjdk.java.net/browse/JDK-8236187
> webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/04/webrev/
>
> Testing:
>  * Build/test on Linux x86_64 and Mac OS x (thanks to Simon Tooke).
>    Build on Windows x86_64 (also thanks to Simon Tooke)
>  * tier1 tests, test/java/nio test/java/net/ test/jdk/net/ on Linux
>    x86_64. No regressions noted.
>
> Thoughts?
>
> Thanks,
> Severin
>
>
>

-- 
Thanks,
Vyom

From vyommani at gmail.com  Fri Jun 26 10:25:06 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 26 Jun 2020 15:55:06 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
Message-ID: <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>

Hi Severin,

Overall code changes looks ok to me, I build & tested at my local REL it
worked fine for me.

Below are few minor comments.

1-> Net.java
    1.1-> I think you don't need to explicitly convert value to integer and
then pass it. You can avoid the local int variable creation as follows.
      ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd, (Integer)value);
   1.2-> In getSocketOption you don't need to explicitly cast it to Integer.
             return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
2-> PlainSocketImpl.java
    1.1 -> In setOption(SocketOption<T> name, T value) you can avoid the
local int variable.
3-> Any specific reason for two set of functions "setTcpKeepAliveTime0
and setTcpKeepAliveTime"
for all three socket options ?

Thanks,
Vyom

On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi,
>
> On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > This would be a great addition.
>
> Thanks.
>
> > I do not understand why it does not support the options available for
> > Windows. Especially given the fact that it actually implements 6
> > native methods to print "Unsupported".
> >
> > But I guess that's less a question to the backport and more to the
> > general implementation.
>
> Yes, indeed. This should be brought up for discussion in JDK head first
> and implemented there before we can consider a backport.
>
> Thanks,
> Severin
>
>
>

-- 
Thanks,
Vyom