From weijun.wang at oracle.com  Wed Jul  1 02:02:08 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 1 Jul 2020 10:02:08 +0800
Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes
In-Reply-To: <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com>
 <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com>
 <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com>
 <E832FEA3-3CE1-4E46-A55B-B3C1B5CC80A2@oracle.com>
 <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
Message-ID: <9D6C8F4C-3FC2-4B56-A506-51DA6E907EAF@oracle.com>

---------------------
src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
@@ -248,7 +248,7 @@ private static X509CRL getCRL(URIName name) throws CertStoreException {
    debug.println("Trying to fetch CRL from DP " + uri);        
    }        

    Event.report("event.crl.check", uri.toString());        
    Event.report(Event.ReporterCategory.CRLCHECK,"event.crl.check", uri.toString());        
 
Please add a whitespace after CRLCHECK.
---------------------
src/java.base/share/classes/sun/security/provider/certpath/OCSP.java
@@ -234,7 +234,7 @@ static OCSPResponse check(List<CertId> certIds, URI responderURI,
    debug.println("connecting to OCSP service at: " + url);        
    }        

    Event.report("event.ocsp.check", url.toString());        
    Event.report(Event.ReporterCategory.CRLCHECK,"event.ocsp.check", url.toString());        
 
White space after CRLCHECK.
--------------------- 
src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
    int perms = JUZFA.getPosixPerms(ze);        
    if (!posixPermsDetected && perms != -1) {        
        posixPermsDetected = true;        
        Event.report(Event.ReporterCategory.POSIXPERMS, "true");        
 
The method signature is "report(category, type, values...)". There is no need to define a type or value here but I feel like more normal to call 'report(POSIXPERMS, "detected")' because the 2nd argument is type instead of value.
---------------------
src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
@@ -1054,7 +1063,7 @@ private void displayMessagesAndResult(boolean isSigning) {
    notYetValidCert || chainNotValidated || hasExpiredCert ||        
    hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) ||        
    (disabledAlg != 0) || aliasNotInStore || notSignedByAlias ||        
    tsaChainNotValidated || permsDetected ||        
 
I'd prefer move the permsDetected check and the if block for it out of this big block, since it's not a fatal warning and just informational. You can move it into "if (hasExpiringCert....".
---------------------
src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
@@ -1805,6 +1820,7 @@ void signJar(String jarName, String alias)
        fos.close();        
    }        

    Event.clearReportListener(Event.ReporterCategory.POSIXPERMS);        
 
Maybe in a final block?
---------------------
test/jdk/sun/security/util/Resources/Usages.java
@@ -75,7 +75,7 @@
    "(?m)rb[ \\n]*\\.getString[ \\n]*\\([ \\n]*\"(.*?)\"\\)");        

    static Pattern EVENT_OCSP_CRL = Pattern.compile(        
            "Event\\.report\\(.*,\"(.*?)\",");        
 
If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well.

Thanks,
Max


> On Jun 30, 2020, at 9:51 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Thanks Lance.
> 
> During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected).
> 
> webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v4/webrev/
> 
> regards,
> Sean.
> 
> On 22/06/2020 17:17, Lance Andersen wrote:
>> HI Sean,
>> 
>> Looks OK based on our exchanges.  Thank you for your time on this one!
>> 
>> Best
>> Lance
>> 
>>> On Jun 22, 2020, at 7:22 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>> 
>>> Thanks Lance.
>>> 
>>> I've updated the patch with some extra offline feedback from yourself and Max.
>>> A new warning is printed with use of the new flag. A warning is also printed when file posix permissions are detected on resources being signed. Test updated for that also.
>>> 
>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/
>>> 
>>> regards,
>>> Sean.
>>> 
>>> On 12/06/2020 17:05, Lance Andersen wrote:
>>>> Hi Sean,
>>>> 
>>>> I think your changes look fine so all good FMPOV.
>>>> 
>>>> Best
>>>> Lance
>>>> 
>>>>> On Jun 12, 2020, at 6:21 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8218021
>>>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/
>>>>> 
>>>>> regards,
>>>>> Sean.
>>>>> 
>>>>> [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html
>>>>> 
>>>> 
>>>> <oracle_sig_logo.gif>
>>>> 
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering 
>>>> 1 Network Drive 
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com
>>>> 
>>>> 
>>>> 
>> 
>> <oracle_sig_logo.gif>
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 


From stuart.marks at oracle.com  Wed Jul  1 02:44:15 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 30 Jun 2020 19:44:15 -0700
Subject: RFR [16/java.xml] 8248348: Regression caused by the update to
 BCEL 6.0
In-Reply-To: <d3c78ebd-334e-2706-61b0-129477c546cd@oracle.com>
References: <09c93e75-8055-fbb9-9cde-195f0f002f1a@oracle.com>
 <d3c78ebd-334e-2706-61b0-129477c546cd@oracle.com>
Message-ID: <ae6092de-fb02-cb81-5504-035605a86bbb@oracle.com>


> An unconventional patch over an unusual hashcode/equals implementation is a bit 
> too controversial. I'd like to propose a new patch that focus on the problem at 
> hand, that is re-setting the opcode causes the item in HashSet to get lost 
> because of the changed hash bucket. This patch therefore simply remove it from 
> the HashSet before the change and then add it back as if it's a new item after 
> setting the opcode. This patch resolves the issue while leaves BCEL 6.0's 
> hashCode/equals alone.
> 
> Here's the new patch:
> http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev02/

Hi Joe,

This makes a good deal more sense than the previous approach! As you note this 
preserves the consistency of equals() and hashCode(), which is an important 
invariant.

It seems a bit roundabout to have to remove something from the HashSet, mutate 
it, and re-add it, but I don't see an alternative. Mutating it while in the 
HashSet is the original cause of problem. Trying to contort things so that 
objects can remain in the HashSet while being mutated is difficult in general, 
and it seems likely to lead to additional problems. Given this, removing and 
re-adding seems the most sensible approach.

It's a bit fragile in that BranchInstruction now has to "know" that the 
InstructionTarget has a HashSet that requires this to be done. However, I don't 
see a way to avoid this without redesigning the relationships of the objects in 
this area -- which seems out of scope for this change.

Just one comment on the test: there are large test data files 
BCELHashCodeTest1.xsl and BCELHashCodeTest2.xsl. What are these? I'm not asking 
for a tutorial, but rather about what function they serve relative to this bug. 
Just a sentence or two about how BCELHashCodeTest2.xsl causes (I think) the 
generated bytecode to exceed the 64Kbyte method size limit. Splitting this into 
multiple methods requires mutating some of the instructions, and then hilarity 
ensued. :-)

I'm also not sure that BCELHashCodeTest1.xsl is necessary if it passes both with 
and without the patch. But if you think it's valuable, then it's ok for it to 
stay in.

Aside from this, I think this change is good to go.

> (had a nice hike today, and asked the beautiful Lake 22 ;-))

I had to look it up. Lake 22 looks very nice! Please give my regards the next 
time you visit.

s'marks

From vipinmv1 at in.ibm.com  Wed Jul  1 04:42:44 2020
From: vipinmv1 at in.ibm.com (Vipin Mv1)
Date: Wed, 1 Jul 2020 04:42:44 +0000
Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with
 Strings
In-Reply-To: <OF44E9534D.C98F5761-ON00258588.00230443-00258588.0023044E@LocalDomain>
References: <OF44E9534D.C98F5761-ON00258588.00230443-00258588.0023044E@LocalDomain>,
 <OF970BE434.A2955C5A-ON00258565.003F3EB3-00258565.003F3EB8@LocalDomain>
Message-ID: <OF14D2225D.8CC159E9-ON00258598.001396E6-00258598.0019E2BC@notes.na.collabserv.com>

Hi,

A gentle reminder to please review this patch.

Thanks & Regards
 Vipin MV					 			
 										 			
			 			
 						

-----Vipin Mv1/India/IBM wrote: -----
To: core-libs-dev at openjdk.java.net
From: Vipin Mv1/India/IBM
Date: 06/15/2020 11:52AM
Subject: Re: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings

Hi,

I have addressed the review comments and the patch has been uploaded here:

http://cr.openjdk.java.net/~vtewari/6470126/webrev/index.html

Please let me know your suggestions.

Thanks & Regards					 			
Vipin MV					 			
 										 			

-----Vipin Mv1/India/IBM wrote: -----
To: core-libs-dev at openjdk.java.net
From: Vipin Mv1/India/IBM
Date: 05/11/2020 05:00PM
Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings

Hi,

Please review the fix for the following issue.

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


diff -r 53568400fec3 src/java.base/share/classes/java/util/jar/Attributes.java
--- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Mar 26 15:26:51 2020 +0000
+++ b/src/java.base/share/classes/java/util/jar/Attributes.java Mon May 11 15:00:01 2020 +0530
@@ -205,7 +205,10 @@
      * @return true if this Map contains the specified attribute name
      */
     public boolean containsKey(Object name) {
-        return map.containsKey(name);
+        if(String.class.isInstance(name))
+            return map.containsKey(Name.of((String)name));
+        else
+            return map.containsKey(name);
     }
 
     /**

Thanks & Regards
Vipin Menon


From huizhe.wang at oracle.com  Wed Jul  1 05:24:37 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 30 Jun 2020 22:24:37 -0700
Subject: RFR [16/java.xml] 8248348: Regression caused by the update to
 BCEL 6.0
In-Reply-To: <ae6092de-fb02-cb81-5504-035605a86bbb@oracle.com>
References: <09c93e75-8055-fbb9-9cde-195f0f002f1a@oracle.com>
 <d3c78ebd-334e-2706-61b0-129477c546cd@oracle.com>
 <ae6092de-fb02-cb81-5504-035605a86bbb@oracle.com>
Message-ID: <c6a1793d-0c76-4eff-d37c-2514fa7bb5d5@oracle.com>



On 6/30/2020 7:44 PM, Stuart Marks wrote:
>
>> An unconventional patch over an unusual hashcode/equals 
>> implementation is a bit too controversial. I'd like to propose a new 
>> patch that focus on the problem at hand, that is re-setting the 
>> opcode causes the item in HashSet to get lost because of the changed 
>> hash bucket. This patch therefore simply remove it from the HashSet 
>> before the change and then add it back as if it's a new item after 
>> setting the opcode. This patch resolves the issue while leaves BCEL 
>> 6.0's hashCode/equals alone.
>>
>> Here's the new patch:
>> http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev02/
>
> Hi Joe,
>
> This makes a good deal more sense than the previous approach! As you 
> note this preserves the consistency of equals() and hashCode(), which 
> is an important invariant.
>
> It seems a bit roundabout to have to remove something from the 
> HashSet, mutate it, and re-add it, but I don't see an alternative. 
> Mutating it while in the HashSet is the original cause of problem. 
> Trying to contort things so that objects can remain in the HashSet 
> while being mutated is difficult in general, and it seems likely to 
> lead to additional problems. Given this, removing and re-adding seems 
> the most sensible approach.

Indeed, mutating while in the HashSet indicates the code design might 
not have considered it could happen.
>
> It's a bit fragile in that BranchInstruction now has to "know" that 
> the InstructionTarget has a HashSet that requires this to be done. 
> However, I don't see a way to avoid this without redesigning the 
> relationships of the objects in this area -- which seems out of scope 
> for this change.

Additional burden for BranchInstruction.? It would have been less 
troublesome if Instructions were not allowed to mutate, that is, 
changing opcode would mean creating new objects. But I think the 
intention is to reduce object creation (that worked for a straight 
forward compilation process).

>
> Just one comment on the test: there are large test data files 
> BCELHashCodeTest1.xsl and BCELHashCodeTest2.xsl. What are these? I'm 
> not asking for a tutorial, but rather about what function they serve 
> relative to this bug. Just a sentence or two about how 
> BCELHashCodeTest2.xsl causes (I think) the generated bytecode to 
> exceed the 64Kbyte method size limit. Splitting this into multiple 
> methods requires mutating some of the instructions, and then hilarity 
> ensued. :-)
>
> I'm also not sure that BCELHashCodeTest1.xsl is necessary if it passes 
> both with and without the patch. But if you think it's valuable, then 
> it's ok for it to stay in.

Will add the comment to the DataProvider and update the webrev.
>
> Aside from this, I think this change is good to go.

Thanks!
>
>> (had a nice hike today, and asked the beautiful Lake 22 ;-))
>
> I had to look it up. Lake 22 looks very nice! Please give my regards 
> the next time you visit.

It is! The trail itself is nice too with a stream running alongside. 
I'll tell Lake 22 you said hello next time ;-)

-Joe

>
> s'marks


From sean.coffey at oracle.com  Thu Jul  2 07:05:40 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 2 Jul 2020 08:05:40 +0100
Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes
In-Reply-To: <9D6C8F4C-3FC2-4B56-A506-51DA6E907EAF@oracle.com>
References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com>
 <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com>
 <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com>
 <E832FEA3-3CE1-4E46-A55B-B3C1B5CC80A2@oracle.com>
 <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
 <9D6C8F4C-3FC2-4B56-A506-51DA6E907EAF@oracle.com>
Message-ID: <b08c143f-9fc4-c6ef-c780-96afb6fd4c16@oracle.com>

Thanks for the review Max. All edits made bar the 
"Event.clearReportListener(Event.ReporterCategory.POSIXPERMS);" 
suggested edit. That's already in a finally block.

latest webrev: 
https://cr.openjdk.java.net/~coffeys/webrev.8218021.v5/webrev/

I plan to push once I have a clean test run.

regards,
Sean.

On 01/07/2020 03:02, Weijun Wang wrote:
> ---------------------
> src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
> @@ -248,7 +248,7 @@ private static X509CRL getCRL(URIName name) throws CertStoreException {
>      debug.println("Trying to fetch CRL from DP " + uri);
>      }
>
>      Event.report("event.crl.check", uri.toString());
>      Event.report(Event.ReporterCategory.CRLCHECK,"event.crl.check", uri.toString());
>   
> Please add a whitespace after CRLCHECK.
> ---------------------
> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java
> @@ -234,7 +234,7 @@ static OCSPResponse check(List<CertId> certIds, URI responderURI,
>      debug.println("connecting to OCSP service at: " + url);
>      }
>
>      Event.report("event.ocsp.check", url.toString());
>      Event.report(Event.ReporterCategory.CRLCHECK,"event.ocsp.check", url.toString());
>   
> White space after CRLCHECK.
> ---------------------
> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>      int perms = JUZFA.getPosixPerms(ze);
>      if (!posixPermsDetected && perms != -1) {
>          posixPermsDetected = true;
>          Event.report(Event.ReporterCategory.POSIXPERMS, "true");
>   
> The method signature is "report(category, type, values...)". There is no need to define a type or value here but I feel like more normal to call 'report(POSIXPERMS, "detected")' because the 2nd argument is type instead of value.
> ---------------------
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
> @@ -1054,7 +1063,7 @@ private void displayMessagesAndResult(boolean isSigning) {
>      notYetValidCert || chainNotValidated || hasExpiredCert ||
>      hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) ||
>      (disabledAlg != 0) || aliasNotInStore || notSignedByAlias ||
>      tsaChainNotValidated || permsDetected ||
>   
> I'd prefer move the permsDetected check and the if block for it out of this big block, since it's not a fatal warning and just informational. You can move it into "if (hasExpiringCert....".
> ---------------------
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
> @@ -1805,6 +1820,7 @@ void signJar(String jarName, String alias)
>          fos.close();
>      }
>
>      Event.clearReportListener(Event.ReporterCategory.POSIXPERMS);
>   
> Maybe in a final block?
> ---------------------
> test/jdk/sun/security/util/Resources/Usages.java
> @@ -75,7 +75,7 @@
>      "(?m)rb[ \\n]*\\.getString[ \\n]*\\([ \\n]*\"(.*?)\"\\)");
>
>      static Pattern EVENT_OCSP_CRL = Pattern.compile(
>              "Event\\.report\\(.*,\"(.*?)\",");
>   
> If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well.
>
> Thanks,
> Max
>
>
>> On Jun 30, 2020, at 9:51 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>
>> Thanks Lance.
>>
>> During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected).
>>
>> webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v4/webrev/
>>
>> regards,
>> Sean.
>>
>> On 22/06/2020 17:17, Lance Andersen wrote:
>>> HI Sean,
>>>
>>> Looks OK based on our exchanges.  Thank you for your time on this one!
>>>
>>> Best
>>> Lance
>>>
>>>> On Jun 22, 2020, at 7:22 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>>>
>>>> Thanks Lance.
>>>>
>>>> I've updated the patch with some extra offline feedback from yourself and Max.
>>>> A new warning is printed with use of the new flag. A warning is also printed when file posix permissions are detected on resources being signed. Test updated for that also.
>>>>
>>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 12/06/2020 17:05, Lance Andersen wrote:
>>>>> Hi Sean,
>>>>>
>>>>> I think your changes look fine so all good FMPOV.
>>>>>
>>>>> Best
>>>>> Lance
>>>>>
>>>>>> On Jun 12, 2020, at 6:21 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8218021
>>>>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>>>> [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html
>>>>>>
>>>>> <oracle_sig_logo.gif>
>>>>>
>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com
>>>>>
>>>>>
>>>>>
>>> <oracle_sig_logo.gif>
>>>
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com
>>>
>>>
>>>

From Alan.Bateman at oracle.com  Thu Jul  2 07:59:41 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Jul 2020 08:59:41 +0100
Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes
In-Reply-To: <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com>
 <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com>
 <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com>
 <E832FEA3-3CE1-4E46-A55B-B3C1B5CC80A2@oracle.com>
 <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
Message-ID: <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com>

On 30/06/2020 14:51, Se?n Coffey wrote:
>
> :
>
> During the CSR review, a suggestion was made to have jarsigner 
> preserve such attributes by default. Warnings about these attributes 
> will also be added during signing and verify operations (if detected).
>
Yes, signing should be additive so the original proposal to drop 
information from the UNIX extra block would be surprising. The 
intersection of those using zip/other tools to create zip files and then 
signing them with jarsigner is probably small but it would still be 
confusing for signing to loose information. Having jarsigner refuse to 
sign these zip files by default, with an option to override, would be a 
reasonable approach. The current proposal to printing a warning seems 
okay too.

I've skimmed through webrev.8218021.v5 which has this warning:

"POSIX file permission attributes detected. Note that these attributes 
are unsigned and not protected by the signature."

I realize you've agreed this with the other Reviewers but I think that 
"Note that these attributes are unsigned ..." is confusing as it could 
be interpreted to mean that they have to be signed by some other means, 
or even that the warning is because they are using unsigned values.

It might be better to tweak the second part to make it a bit clearer, up 
to you but something like "These attributes are ignored when signing and 
are not protected by the signature".

-Alan

From sean.coffey at oracle.com  Thu Jul  2 08:10:53 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 2 Jul 2020 09:10:53 +0100
Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes
In-Reply-To: <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com>
References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com>
 <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com>
 <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com>
 <E832FEA3-3CE1-4E46-A55B-B3C1B5CC80A2@oracle.com>
 <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
 <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com>
Message-ID: <2b363448-8790-75f0-4834-64b9e2e4af01@oracle.com>

Thanks for the review Alan. I'm in contact with Max already about 
possible follow up enhancements in this area. It would be worked via a 
follow on JBS record.

Regarding the error message, I'm fine with your suggestion. We can go 
with this then:
"POSIX file permission attributes detected. These attributes are ignored 
when signing and are not protected by the signature."

regards,
Sean.

On 02/07/2020 08:59, Alan Bateman wrote:
> On 30/06/2020 14:51, Se?n Coffey wrote:
>>
>> :
>>
>> During the CSR review, a suggestion was made to have jarsigner 
>> preserve such attributes by default. Warnings about these attributes 
>> will also be added during signing and verify operations (if detected).
>>
> Yes, signing should be additive so the original proposal to drop 
> information from the UNIX extra block would be surprising. The 
> intersection of those using zip/other tools to create zip files and 
> then signing them with jarsigner is probably small but it would still 
> be confusing for signing to loose information. Having jarsigner refuse 
> to sign these zip files by default, with an option to override, would 
> be a reasonable approach. The current proposal to printing a warning 
> seems okay too.
>
> I've skimmed through webrev.8218021.v5 which has this warning:
>
> "POSIX file permission attributes detected. Note that these attributes 
> are unsigned and not protected by the signature."
>
> I realize you've agreed this with the other Reviewers but I think that 
> "Note that these attributes are unsigned ..." is confusing as it could 
> be interpreted to mean that they have to be signed by some other 
> means, or even that the warning is because they are using unsigned 
> values.
>
> It might be better to tweak the second part to make it a bit clearer, 
> up to you but something like "These attributes are ignored when 
> signing and are not protected by the signature".
>
> -Alan

From rahul.r.yadav at oracle.com  Thu Jul  2 11:35:51 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Thu, 2 Jul 2020 12:35:51 +0100
Subject: RFR 8245302: Upgrade LogRecord to support long thread ids and
 remove its usage of ThreadLocal
In-Reply-To: <8c5e6931-b3fd-8e19-206f-3eedf047e37c@oracle.com>
References: <94B2555B-981F-40EB-AB5F-31E2BE068FF0@oracle.com>
 <BC458419-4077-4413-89E2-1AEA29242EC0@oracle.com>
 <03c38ee2-24c2-cf2d-e428-3f8747888978@oracle.com>
 <5e5bc99f-7d46-df1a-08c1-ee37958a3462@oracle.com>
 <58cda3b5-b75b-6782-01eb-2c935a0e402d@oracle.com>
 <362dc841-a809-95f5-961f-3856f3230b6f@oracle.com>
 <eae2f5d9-3dd3-3136-052e-3aa6b4d6307e@oracle.com>
 <8c5e6931-b3fd-8e19-206f-3eedf047e37c@oracle.com>
Message-ID: <e94588ef-f30d-013e-78ac-fa165bb4e8c8@oracle.com>

Hello,

I have added comments @Serial based on csr feedback for read/writeObject 
methods.

webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/

- rahul

On 25/06/2020 10:22, Rahul Yadav wrote:
> Hello,
>
> Deprecated tag in LogRecord getter and setter for threadID was missing 
> "since" and so i have added it.
>
> webrev : http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/
>
> - rahul
>
> On 22/06/2020 19:38, Daniel Fuchs wrote:
>> Hi Rahul,
>>
>> Looks good to me as well.
>>
>> Reviewed.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 19/06/2020 10:00, Rahul Yadav wrote:
>>> Thank you Alan, updated webrev.
>>>
>>> webrev : 
>>> http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html
>>>
>>> - rahul
>>>
>>> On 19/06/2020 08:43, Alan Bateman wrote:
>>>> On 18/06/2020 23:37, Rahul Yadav wrote:
>>>>> Hi Alan,
>>>>>
>>>>> Thank you for the feedback.I have updated the webrev.
>>>>>
>>>>> webrev : 
>>>>> http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html 
>>>>>
>>>> This looks quite good.
>>>>
>>>> The comment in shortShortID has "any positive long less than 
>>>> Integer.MAX_VALUE" but it's actually <= MAX_VALUE.
>>>>
>>>> I don't think MIN_SEQUENTIAL_THREAD_ID is used so I assume it can 
>>>> be removed.
>>>>
>>>> The @return for setLongThreadID has a description "Log Record" but 
>>>> this should "this LogRecord".
>>>>
>>>> Can you update SerializeLogRecordTest with clear instructions on 
>>>> how to generate the stream? This will help future maintainers that 
>>>> may have to update this test.
>>>>
>>>> -Alan
>>>
>>
>


From LANCE.ANDERSEN at ORACLE.COM  Thu Jul  2 12:12:59 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Thu, 2 Jul 2020 08:12:59 -0400
Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes
In-Reply-To: <2b363448-8790-75f0-4834-64b9e2e4af01@oracle.com>
References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com>
 <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com>
 <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com>
 <E832FEA3-3CE1-4E46-A55B-B3C1B5CC80A2@oracle.com>
 <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com>
 <1fd1604e-812a-c887-3abc-47e9eb531c25@oracle.com>
 <2b363448-8790-75f0-4834-64b9e2e4af01@oracle.com>
Message-ID: <99AEF0BF-8D9D-408A-A569-1206A7C5E927@ORACLE.COM>

Hi Sean,

I think the changes look good including the proposed tweaks to the message suggested by Alan.

Best
Lance

> On Jul 2, 2020, at 4:10 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Thanks for the review Alan. I'm in contact with Max already about possible follow up enhancements in this area. It would be worked via a follow on JBS record.
> 
> Regarding the error message, I'm fine with your suggestion. We can go with this then:
> "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature."
> 
> regards,
> Sean.
> 
> On 02/07/2020 08:59, Alan Bateman wrote:
>> On 30/06/2020 14:51, Se?n Coffey wrote:
>>> 
>>> :
>>> 
>>> During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected).
>>> 
>> Yes, signing should be additive so the original proposal to drop information from the UNIX extra block would be surprising. The intersection of those using zip/other tools to create zip files and then signing them with jarsigner is probably small but it would still be confusing for signing to loose information. Having jarsigner refuse to sign these zip files by default, with an option to override, would be a reasonable approach. The current proposal to printing a warning seems okay too.
>> 
>> I've skimmed through webrev.8218021.v5 which has this warning:
>> 
>> "POSIX file permission attributes detected. Note that these attributes are unsigned and not protected by the signature."
>> 
>> I realize you've agreed this with the other Reviewers but I think that "Note that these attributes are unsigned ..." is confusing as it could be interpreted to mean that they have to be signed by some other means, or even that the warning is because they are using unsigned values.
>> 
>> It might be better to tweak the second part to make it a bit clearer, up to you but something like "These attributes are ignored when signing and are not protected by the signature".
>> 
>> -Alan


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From patrick.concannon at oracle.com  Thu Jul  2 13:30:45 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 2 Jul 2020 14:30:45 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
Message-ID: <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>

Hi,

John: Thanks for your feedback. We've rearranged the ordering of the parameters of the BiConsumer to follow the convention you suggested, and hopefully improve readability going forward. Additional FIs (IntObjConsumer, etc.) have been added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double, Long}Stream.

Remi: Your argument makes sense, and we have updated the BiConsumers generic type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out. We have also removed the caching. 
WRT to the wrappers used in the examples: good examples are tough to nail down. We think the examples in their current form do a good job of demonstrating how the method can be used, but we welcome any alternative suggestions.


The changes discussed can be found in the updated webrev below. 

http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>


Kind regards,

Patrick

> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
> 
> w


From forax at univ-mlv.fr  Thu Jul  2 14:30:55 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 2 Jul 2020 16:30:55 +0200 (CEST)
Subject: =?utf-8?Q?Re:_RFR[8238286]:_'Add_new_flatMap_stream_?=
 =?utf-8?Q?operation_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
Message-ID: <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>

Hi Patrick & Julia,
this version starts to look good.

I just don't understand why the new functional interfaces are not in java.util.function like the other ones ?
(BTW, in the javadoc, the link to the summary overview point to the wrong one, to java.util.stream and not java.util.function).

About the examples, i will try to think about that this evening :)

regards,
R?mi

----- Mail original -----
> De: "Patrick Concannon" <patrick.concannon at oracle.com>
> ?: "Julia Boes" <julia.boes at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 2 Juillet 2020 15:30:45
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing?

> Hi,
> 
> John: Thanks for your feedback. We've rearranged the ordering of the parameters
> of the BiConsumer to follow the convention you suggested, and hopefully improve
> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
> Long}Stream.
> 
> Remi: Your argument makes sense, and we have updated the BiConsumers generic
> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
> We have also removed the caching.
> WRT to the wrappers used in the examples: good examples are tough to nail down.
> We think the examples in their current form do a good job of demonstrating how
> the method can be used, but we welcome any alternative suggestions.
> 
> 
> The changes discussed can be found in the updated webrev below.
> 
> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/
> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>
> 
> 
> Kind regards,
> 
> Patrick
> 
>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
>> 
> > w

From patrick.concannon at oracle.com  Thu Jul  2 14:38:46 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 2 Jul 2020 15:38:46 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <CAE+3fjbVO4nks1u3Gi7KPXAE1kq3ZJjEidkkOXcrdhkfTj4VnA@mail.gmail.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <CAE+3fjbVO4nks1u3Gi7KPXAE1kq3ZJjEidkkOXcrdhkfTj4VnA@mail.gmail.com>
Message-ID: <5B4DFB68-747C-4EAB-A042-C24DF6516FB8@oracle.com>

Hi Tagir,

Thank you for your input. However, we feel that this approach may add more complexity than is needed at this stage. It's a good point, and one that we think is reasonable to consider and evaluate as a possible follow on from this initial proposal.

Kind regards,

Patrick

> On 25 Jun 2020, at 05:04, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> To me, it looks like it's possible to make the better default
> implementation. It could be done even as a separate static method:
> 
> static <T> Stream<T> ofPusher(Consumer<Consumer<? super T>> pusher) {
>  return StreamSupport.stream(new Spliterator<>() {
>    private Spliterator<T> delegate;
> 
>    @Override
>    public boolean tryAdvance(Consumer<? super T> action) {
>      initDelegate();
>      return delegate.tryAdvance(action);
>    }
> 
>    private void initDelegate() {
>      if (delegate == null) {
>        Stream.Builder<T> builder = Stream.builder(); // or use
> SpinedBuffer directly
>        pusher.accept(builder);
>        delegate = builder.build().spliterator();
>      }
>    }
> 
>    @Override
>    public void forEachRemaining(Consumer<? super T> action) {
>      if (delegate != null) {
>        delegate.forEachRemaining(action);
>      } else {
>        pusher.accept(action);
>      }
>    }
> 
>    @Override
>    public Spliterator<T> trySplit() {
>      initDelegate();
>      return delegate.trySplit();
>    }
> 
>    @Override
>    public long estimateSize() {
>      return Long.MAX_VALUE;
>    }
> 
>    @Override
>    public int characteristics() {
>      return 0;
>    }
>  }, false);
> }
> 
> In this case, we are buffering only if short-circuit operation or
> splitting is requested. Otherwise, forEachRemaining will just delegate
> to the pusher.
> Now, the default implementation could be rewritten as
> 
> <T, R> Stream<R> mapMulti(Stream<T> stream, BiConsumer<Consumer<?
> super R>, ? super T> mapper) {
>  Objects.requireNonNull(mapper);
>  return stream.flatMap(e -> ofPusher(sink -> mapper.accept(sink, e)));
> }
> 
> And now, I don't think it's necessary to specialize it at all.
> Probably it's not necessary to introduce mapMulti at all as well, as
> now it's a trivial delegate to ofPusher.
> 
> With best regards,
> Tagir Valeev.
> 
> On Wed, Jun 24, 2020 at 5:58 PM Patrick Concannon
> <patrick.concannon at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing??
>> 
>> This proposal is to add a new flatMap-like operation:
>> 
>> `<R> Stream<R> mapMulti(BiConsumer<Consumer<R>, ? super T> mapper)`
>> 
>> to the java.util.Stream class. This operation is more receptive to the pushing or yielding of values than the current implementation that internally assembles values (if any) into one or more streams. This addition includes the primitive variations of the operation i.e. mapMultiToInt, IntStream mapMulti, etc.
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8238286 <https://bugs.openjdk.java.net/browse/JDK-8238286>
>> csr: https://bugs.openjdk.java.net/browse/JDK-8248166 <https://bugs.openjdk.java.net/browse/JDK-8248166>
>> 
>> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/>
>> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html  <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html>
>> 
>> 
>> Kind regards,
>> Patrick & Julia


From patrick.concannon at oracle.com  Thu Jul  2 14:38:02 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 2 Jul 2020 15:38:02 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <6ea32a67-8292-39c7-df04-58ad15b2fde4@anthonyv.be>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <24F8FA40-3DC5-4156-B208-CCE54DB8CCF5@oracle.com>
 <2F795DFF-36B6-4903-B0AF-120973F29AD8@oracle.com>
 <6ea32a67-8292-39c7-df04-58ad15b2fde4@anthonyv.be>
Message-ID: <3885AE11-2951-47B8-B030-6A0E87C7C73E@oracle.com>

Hi Anthony,

Thanks for your suggestion of using a Stream.Builder instead of a Consumer. However, one of the goals for mapMulti is not to create an additional Stream. Also, I fear that using a builder, but throwing an exception on a call to build, is counter-intuitive and perhaps confusing to the user.

Kind regards,

Patrick

> On 25 Jun 2020, at 18:12, Anthony Vanelverdinghe <dev at anthonyv.be> wrote:
> 
> Hi
> 
> Given the signature of flatMap is:
> <R> Stream<R> flatMap?(Function<? super T, ? extends Stream<? extends R>> mapper)
> 
> I'd like to propose the following signature for the new method:
> <R> Stream<R> builderMap(BiConsumer<? super T, ? super Stream.Builder<R>> mapper)
> 
> This way both methods are named "...Map", and the name "builderMap" follows naturally from the argument's type.
> If the given mapper invokes Stream.Builder::build, an IllegalStateException should be thrown.
> 
> Kind regards,
> Anthony
> 
> On 25/06/2020 02:58, Paul Sandoz wrote:
>> Hi,
>> 
>> We traded CPS style for reusing existing functional interfaces. Originally the signature (my first choice) was as you indicate.
>> 
>> By chance it just so happens that the current signature is the same shape as that for the accumulating argument type of the three arg collect terminal operation:
>> 
>> Stream
>> <R> R collect(Supplier<R> supplier,
>>               BiConsumer<R, ? super T> accumulator,
>>               BiConsumer<R, R> combiner);
>> 
>> IntStream
>> <R> R collect(Supplier<R> supplier,
>>               ObjIntConsumer<R> accumulator,
>>               BiConsumer<R, R> combiner);
>> 
>> Same for the accumulator of a Collector too.
>> 
>> However, I suspect you would argue these terminal accumulation cases are different from the intermediate case, as we are not accumulating but passing or accepting (loosely returning) zero or more elements that replace the input element.
>> 
>> It?s my hope that generic specialization will allow the primitive stream types to fade into the background, along with the primitive functional interfaces. In that respect the addition of three functional interfaces for use on the primitive stream types is not so terrible.
>> 
>> 
>> Regarding the name, you should have seen the first one :-) it was terrible.
>> 
>> Here?s my few brush strokes on the bike shed. I wonder what people think of mapAccept. The specification talks about accepting elements, because that is the operative method name on Consumer. So we can say "T is replaced with the elements accepted by the Consumer<R>", or ? The Consumer<R> accepts the elements that replace T"
>> 
>> Paul.
>> 
>> 
>> 
>>> On Jun 24, 2020, at 1:01 PM, John Rose <john.r.rose at oracle.com> wrote:
>>> 
>>> I like this new API point a lot; it allows flexible, local, temporary
>>> control inversion in the context of one stream transform.
>>> 
>>> What?s the performance model?  It seems like the SpinedBuffer
>>> implementation makes a worst-case assumption about the number
>>> of pending values, that there will be many instead of zero or one.
>>> 
>>> But I guess the pipeline stuff already works in terms of pushes, so
>>> the good news might be that this is really just a drill-down from the
>>> user API into the kinds of operations (push-flavored) that go on
>>> most of the time.
>>> 
>>> OK, so I like the function but I have a beef with its bike shed
>>> color.  First of all, this is a control-inversion (CPS) pattern,
>>> which is very powerful but also notoriously hard to read.
>>> I think that in Java APIs, at least in Stream APIs, code is
>>> easier to read if the logical data flow is from left to right.
>>> 
>>> (This is a language-specific observation.  Apart from varargs,
>>> Java method APIs read favorably when extra control arguments
>>> are added onto the end of the argument list.  Also, the convention
>>> for generic functional interfaces is that the return value type
>>> goes to the right, e.g., R in Function<A,R>.)
>>> 
>>> So the BiConsumer is backwards, because the logical return
>>> should be written, if not as a true return (which would appear
>>> at the end of type parameter lists), at the end of the incoming
>>> parameters (and in the last type parameter).
>>> 
>>> I also think ?multi? is needlessly ?learned? sounding.  A simple
>>> spatial preposition would work well: mapThrough, mapAcross, etc.
>>> I think I prefer mapAcross because the term ?across? can be read
>>> adverbially: ?we are mapping T across to Consumer<R>?.
>>> 
>>> So:
>>> 
>>> mapAcross(BiConsumer<? super T, Consumer<R>> mapper)
>>> mapAcrossToInt(BiConsumer<? super T, IntConsumer> mapper)
>>> mapAcross?(IntObjConsumer<IntConsumer> mapper)
>>> 
>>> This does require additional FI?s like IntObjConsumer, but
>>> I think that is a negligible cost.  Making the control inversion
>>> *readable* is the high order bit here, not minimizing the number
>>> of trivial FIs.
>>> 
>>> (I almost hear David Bowman, in his space suit, saying, ?My API?
>>> It?s full of bikesheds!?  There?s a meme for that.)
>>> 
>>> ? John
>>> 
>>> On Jun 24, 2020, at 3:57 AM, Patrick Concannon <patrick.concannon at oracle.com> wrote:
>>>> Hi,
>>>> 
>>>> Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing??
>>>> 
>>>> This proposal is to add a new flatMap-like operation:
>>>> 
>>>> `<R> Stream<R> mapMulti(BiConsumer<Consumer<R>, ? super T> mapper)`
>>>> 
>>>> to the java.util.Stream class. This operation is more receptive to the pushing or yielding of values than the current implementation that internally assembles values (if any) into one or more streams. This addition includes the primitive variations of the operation i.e. mapMultiToInt, IntStream mapMulti, etc.
>>>> 
>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8238286 <https://bugs.openjdk.java.net/browse/JDK-8238286>
>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8248166 <https://bugs.openjdk.java.net/browse/JDK-8248166>
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/>
>>>> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html  <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html>
>>>> 
>>>> 
>>>> Kind regards,
>>>> Patrick & Julia


From daniel.fuchs at oracle.com  Thu Jul  2 15:14:24 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Jul 2020 16:14:24 +0100
Subject: RFR 8245302: Upgrade LogRecord to support long thread ids and
 remove its usage of ThreadLocal
In-Reply-To: <e94588ef-f30d-013e-78ac-fa165bb4e8c8@oracle.com>
References: <94B2555B-981F-40EB-AB5F-31E2BE068FF0@oracle.com>
 <BC458419-4077-4413-89E2-1AEA29242EC0@oracle.com>
 <03c38ee2-24c2-cf2d-e428-3f8747888978@oracle.com>
 <5e5bc99f-7d46-df1a-08c1-ee37958a3462@oracle.com>
 <58cda3b5-b75b-6782-01eb-2c935a0e402d@oracle.com>
 <362dc841-a809-95f5-961f-3856f3230b6f@oracle.com>
 <eae2f5d9-3dd3-3136-052e-3aa6b4d6307e@oracle.com>
 <8c5e6931-b3fd-8e19-206f-3eedf047e37c@oracle.com>
 <e94588ef-f30d-013e-78ac-fa165bb4e8c8@oracle.com>
Message-ID: <d3c7b4bd-5977-8385-b6aa-d6b93ca69532@oracle.com>

Hi Rahul,

The updates to the readObject API documentation look good to
me. Thanks for adding the missing @Serial annotations!

best regards,

-- daniel

On 02/07/2020 12:35, Rahul Yadav wrote:
> Hello,
> 
> I have added comments @Serial based on csr feedback for read/writeObject 
> methods.
> 
> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/
> 
> - rahul


From Roger.Riggs at oracle.com  Thu Jul  2 16:39:46 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 Jul 2020 12:39:46 -0400
Subject: contributing to JDK-8222187: java.util.Base64.Decoder stream adds
 unexpected null bytes at the end
In-Reply-To: <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
Message-ID: <8f5533a0-fbdc-988f-cd4b-6bc14d373027@oracle.com>

Hi Raffaello,

There is way more code changed here than is needed to fix the bug.
General enhancement should be separated from bug fixes.
It makes it easier to review to see the bug was fixed
and easier to separately review other code to see that there are no 
unexpected changes.

If some of the changes are motivated by expected performance improvements,
there should be JMH tests comparing the before and after.
The change to use byte arrays seems useful, but even using char[]
there is little danger of cache thrashing.

If using the code using xxxExact was correct, don't change it.
Those methods are intrinsified and perform as well or better than using 
long.
Usually, it is better to leave code alone and not risk breaking it.

Special care needs taken when changing a method that is intrinsified.
The optimized version may use fields of the object and stop
working if they are changed.

In the test, the range of buffer sizes tests seems to waste a lot
of cycles on sizes greater than the encoded size of the input.

Regards, Roger


On 6/29/20 1:51 PM, Raffaello Giulietti wrote:
> Hello,
>
> here's a fix and an additional test, both in inline form and as an 
> attachment.
>
> The fix also contains a reimplementation of encodedOutLength() that 
> makes use of long arithmetic rather than relying on addExact(), 
> multiplyExact(), etc.
>
> Further, lookup tables have been declared as byte[], which should help 
> maintaining them in caches for longer because of their smaller sizes.
>
>
> Greetings
> Raffaello
>
> ----
>
> # HG changeset patch
> # User lello
> # Date 1593437938 -7200
> #????? Mon Jun 29 15:38:58 2020 +0200
> # Node ID 58aadb9efae6d5d88479ad8171f2219d41cc761f
> # Parent? 4a91f6b96a506d9d67437338c33b6953a57bfbd9
> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
> the end
> Reviewed-by: TBD
> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>
> diff --git a/src/java.base/share/classes/java/util/Base64.java 
> b/src/java.base/share/classes/java/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java
> +++ b/src/java.base/share/classes/java/util/Base64.java
> @@ -30,7 +30,6 @@
> ?import java.io.IOException;
> ?import java.io.OutputStream;
> ?import java.nio.ByteBuffer;
> -import java.nio.charset.StandardCharsets;
>
> ?import sun.nio.cs.ISO_8859_1;
>
> @@ -133,7 +132,7 @@
> ????? */
> ???? public static Encoder getMimeEncoder(int lineLength, byte[] 
> lineSeparator) {
> ????????? Objects.requireNonNull(lineSeparator);
> -???????? int[] base64 = Decoder.fromBase64;
> +???????? byte[] base64 = Decoder.fromBase64;
> ????????? for (byte b : lineSeparator) {
> ????????????? if (base64[b & 0xff] != -1)
> ????????????????? throw new IllegalArgumentException(
> @@ -216,7 +215,7 @@
> ????????? * index values into their "Base64 Alphabet" equivalents as 
> specified
> ????????? * in "Table 1: The Base64 Alphabet" of RFC 2045 (and RFC 4648).
> ????????? */
> -??????? private static final char[] toBase64 = {
> +??????? private static final byte[] toBase64 = {
> ???????????? 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 
> 'L', 'M',
> ???????????? 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 
> 'Y', 'Z',
> ???????????? 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 
> 'l', 'm',
> @@ -229,7 +228,7 @@
> ????????? * in Table 2 of the RFC 4648, with the '+' and '/' changed 
> to '-' and
> ????????? * '_'. This table is used when BASE64_URL is specified.
> ????????? */
> -??????? private static final char[] toBase64URL = {
> +??????? private static final byte[] toBase64URL = {
> ???????????? 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 
> 'L', 'M',
> ???????????? 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 
> 'Y', 'Z',
> ???????????? 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 
> 'l', 'm',
> @@ -238,7 +237,7 @@
> ???????? };
>
> ???????? private static final int MIMELINEMAX = 76;
> -??????? private static final byte[] CRLF = new byte[] {'\r', '\n'};
> +??????? private static final byte[] CRLF = {'\r', '\n'};
>
> ???????? static final Encoder RFC4648 = new Encoder(false, null, -1, 
> true);
> ???????? static final Encoder RFC4648_URLSAFE = new Encoder(true, 
> null, -1, true);
> @@ -255,27 +254,19 @@
> ????????? *
> ????????? */
> ???????? private final int encodedOutLength(int srclen, boolean 
> throwOOME) {
> -??????????? int len = 0;
> -??????????? try {
> -??????????????? if (doPadding) {
> -??????????????????? len = Math.multiplyExact(4, 
> (Math.addExact(srclen, 2) / 3));
> -??????????????? } else {
> -??????????????????? int n = srclen % 3;
> -??????????????????? len = Math.addExact(Math.multiplyExact(4, (srclen 
> / 3)), (n == 0 ? 0 : n + 1));
> -??????????????? }
> -??????????????? if (linemax > 0) { // line separators
> -??????????????????? len = Math.addExact(len, (len - 1) / linemax * 
> newline.length);
> -??????????????? }
> -??????????? } catch (ArithmeticException ex) {
> -??????????????? if (throwOOME) {
> -??????????????????? throw new OutOfMemoryError("Encoded size is too 
> large");
> -??????????????? } else {
> -??????????????????? // let the caller know that encoded bytes length
> -??????????????????? // is too large
> -??????????????????? len = -1;
> -??????????????? }
> +??????????? long len = doPadding
> +??????????????????? ? (srclen + 2L) / 3 * 4
> +??????????????????? : (srclen + 2L) / 3 + srclen;
> +??????????? if (linemax > 0) {
> +??????????????? len += (len - 1) / linemax * newline.length;
> ???????????? }
> -??????????? return len;
> +??????????? if (len <= Integer.MAX_VALUE) {
> +??????????????? return (int) len;
> +??????????? }
> +??????????? if (throwOOME) {
> +??????????????? throw new OutOfMemoryError("Encoded size is too large");
> +??????????? }
> +??????????? return -1;
> ???????? }
>
> ???????? /**
> @@ -421,24 +412,24 @@
>
> ???????? @HotSpotIntrinsicCandidate
> ???????? private void encodeBlock(byte[] src, int sp, int sl, byte[] 
> dst, int dp, boolean isURL) {
> -??????????? char[] base64 = isURL ? toBase64URL : toBase64;
> +??????????? byte[] base64 = isURL ? toBase64URL : toBase64;
> ???????????? for (int sp0 = sp, dp0 = dp ; sp0 < sl; ) {
> ???????????????? int bits = (src[sp0++] & 0xff) << 16 |
> ??????????????????????????? (src[sp0++] & 0xff) <<? 8 |
> ??????????????????????????? (src[sp0++] & 0xff);
> -??????????????? dst[dp0++] = (byte)base64[(bits >>> 18) & 0x3f];
> -??????????????? dst[dp0++] = (byte)base64[(bits >>> 12) & 0x3f];
> -??????????????? dst[dp0++] = (byte)base64[(bits >>> 6) & 0x3f];
> -??????????????? dst[dp0++] = (byte)base64[bits & 0x3f];
> +??????????????? dst[dp0++] = base64[(bits >>> 18) & 0x3f];
> +??????????????? dst[dp0++] = base64[(bits >>> 12) & 0x3f];
> +??????????????? dst[dp0++] = base64[(bits >>> 6)? & 0x3f];
> +??????????????? dst[dp0++] = base64[bits & 0x3f];
> ???????????? }
> ???????? }
>
> ???????? private int encode0(byte[] src, int off, int end, byte[] dst) {
> -??????????? char[] base64 = isURL ? toBase64URL : toBase64;
> +??????????? byte[] base64 = isURL ? toBase64URL : toBase64;
> ???????????? int sp = off;
> ???????????? int slen = (end - off) / 3 * 3;
> ???????????? int sl = off + slen;
> -??????????? if (linemax > 0 && slen? > linemax / 4 * 3)
> +??????????? if (linemax > 0 && slen > linemax / 4 * 3)
> ???????????????? slen = linemax / 4 * 3;
> ???????????? int dp = 0;
> ???????????? while (sp < sl) {
> @@ -455,17 +446,17 @@
> ???????????? }
> ???????????? if (sp < end) {?????????????? // 1 or 2 leftover bytes
> ???????????????? int b0 = src[sp++] & 0xff;
> -??????????????? dst[dp++] = (byte)base64[b0 >> 2];
> +??????????????? dst[dp++] = base64[b0 >> 2];
> ???????????????? if (sp == end) {
> -??????????????????? dst[dp++] = (byte)base64[(b0 << 4) & 0x3f];
> +??????????????????? dst[dp++] = base64[(b0 << 4) & 0x3f];
> ???????????????????? if (doPadding) {
> ???????????????????????? dst[dp++] = '=';
> ???????????????????????? dst[dp++] = '=';
> ???????????????????? }
> ???????????????? } else {
> ???????????????????? int b1 = src[sp++] & 0xff;
> -??????????????????? dst[dp++] = (byte)base64[(b0 << 4) & 0x3f | (b1 
> >> 4)];
> -??????????????????? dst[dp++] = (byte)base64[(b1 << 2) & 0x3f];
> +??????????????????? dst[dp++] = base64[(b0 << 4) & 0x3f | (b1 >> 4)];
> +??????????????????? dst[dp++] = base64[(b1 << 2) & 0x3f];
> ???????????????????? if (doPadding) {
> ???????????????????????? dst[dp++] = '=';
> ???????????????????? }
> @@ -523,11 +514,12 @@
> ????????? * the array are encoded to -1.
> ????????? *
> ????????? */
> -??????? private static final int[] fromBase64 = new int[256];
> +??????? private static final byte[] fromBase64 = new byte[256];
> +
> ???????? static {
> -??????????? Arrays.fill(fromBase64, -1);
> +??????????? Arrays.fill(fromBase64, (byte) -1);
> ???????????? for (int i = 0; i < Encoder.toBase64.length; i++)
> -??????????????? fromBase64[Encoder.toBase64[i]] = i;
> +??????????????? fromBase64[Encoder.toBase64[i]] = (byte) i;
> ???????????? fromBase64['='] = -2;
> ???????? }
>
> @@ -535,12 +527,12 @@
> ????????? * Lookup table for decoding "URL and Filename safe Base64 
> Alphabet"
> ????????? * as specified in Table2 of the RFC 4648.
> ????????? */
> -??????? private static final int[] fromBase64URL = new int[256];
> +??????? private static final byte[] fromBase64URL = new byte[256];
>
> ???????? static {
> -??????????? Arrays.fill(fromBase64URL, -1);
> +??????????? Arrays.fill(fromBase64URL, (byte) -1);
> ???????????? for (int i = 0; i < Encoder.toBase64URL.length; i++)
> -??????????????? fromBase64URL[Encoder.toBase64URL[i]] = i;
> +??????????????? fromBase64URL[Encoder.toBase64URL[i]] = (byte) i;
> ???????????? fromBase64URL['='] = -2;
> ???????? }
>
> @@ -699,7 +691,7 @@
> ????????? *
> ????????? */
> ???????? private int decodedOutLength(byte[] src, int sp, int sl) {
> -??????????? int[] base64 = isURL ? fromBase64URL : fromBase64;
> +??????????? byte[] base64 = isURL ? fromBase64URL : fromBase64;
> ???????????? int paddings = 0;
> ???????????? int len = sl - sp;
> ???????????? if (len == 0)
> @@ -743,7 +735,7 @@
> ???????? }
>
> ???????? private int decode0(byte[] src, int sp, int sl, byte[] dst) {
> -??????????? int[] base64 = isURL ? fromBase64URL : fromBase64;
> +??????????? byte[] base64 = isURL ? fromBase64URL : fromBase64;
> ???????????? int dp = 0;
> ???????????? int bits = 0;
> ???????????? int shiftto = 18;?????? // pos of first byte of 4-byte atom
> @@ -832,14 +824,14 @@
> ???????? private int b0, b1, b2;
> ???????? private boolean closed = false;
>
> -??????? private final char[] base64;??? // byte->base64 mapping
> +??????? private final byte[] base64;??? // byte->base64 mapping
> ???????? private final byte[] newline;?? // line separator, if needed
> ???????? private final int linemax;
> ???????? private final boolean doPadding;// whether or not to pad
> ???????? private int linepos = 0;
> ???????? private byte[] buf;
>
> -??????? EncOutputStream(OutputStream os, char[] base64,
> +??????? EncOutputStream(OutputStream os, byte[] base64,
> ???????????????????????? byte[] newline, int linemax, boolean 
> doPadding) {
> ???????????? super(os);
> ???????????? this.base64 = base64;
> @@ -863,11 +855,11 @@
> ???????????? }
> ???????? }
>
> -??????? private void writeb4(char b1, char b2, char b3, char b4) 
> throws IOException {
> -??????????? buf[0] = (byte)b1;
> -??????????? buf[1] = (byte)b2;
> -??????????? buf[2] = (byte)b3;
> -??????????? buf[3] = (byte)b4;
> +??????? private void writeb4(byte b1, byte b2, byte b3, byte b4) 
> throws IOException {
> +??????????? buf[0] = b1;
> +??????????? buf[1] = b2;
> +??????????? buf[2] = b3;
> +??????????? buf[3] = b4;
> ???????????? out.write(buf, 0, 4);
> ???????? }
>
> @@ -909,10 +901,10 @@
> ???????????????????? int bits = (b[sp++] & 0xff) << 16 |
> ??????????????????????????????? (b[sp++] & 0xff) <<? 8 |
> ??????????????????????????????? (b[sp++] & 0xff);
> -??????????????????? buf[dp++] = (byte)base64[(bits >>> 18) & 0x3f];
> -??????????????????? buf[dp++] = (byte)base64[(bits >>> 12) & 0x3f];
> -??????????????????? buf[dp++] = (byte)base64[(bits >>> 6)? & 0x3f];
> -??????????????????? buf[dp++] = (byte)base64[bits & 0x3f];
> +??????????????????? buf[dp++] = base64[(bits >>> 18) & 0x3f];
> +??????????????????? buf[dp++] = base64[(bits >>> 12) & 0x3f];
> +??????????????????? buf[dp++] = base64[(bits >>> 6) & 0x3f];
> +??????????????????? buf[dp++] = base64[bits & 0x3f];
> ???????????????? }
> ???????????????? out.write(buf, 0, dp);
> ???????????????? off = sl;
> @@ -960,130 +952,119 @@
> ???? private static class DecInputStream extends InputStream {
>
> ???????? private final InputStream is;
> +??????? private final byte[] base64;??? // mapping from alphabet to 
> values
> ???????? private final boolean isMIME;
> -??????? private final int[] base64;????? // base64 -> byte mapping
> -??????? private int bits = 0;??????????? // 24-bit buffer for decoding
> -??????? private int nextin = 18;???????? // next available "off" in 
> "bits" for input;
> -???????????????????????????????????????? // -> 18, 12, 6, 0
> -??????? private int nextout = -8;??????? // next available "off" in 
> "bits" for output;
> -???????????????????????????????????????? // -> 8, 0, -8 (no byte for 
> output)
> -??????? private boolean eof = false;
> -??????? private boolean closed = false;
> +??????? private int bits;?????????????? // 24 bit buffer for decoding
> +??????? private int wpos;?????????????? // writing bit pos inside bits
> +??????????????????????????????????????? // one of 24 (left, msb), 18, 
> 12, 6, 0
> +??????? private int rpos;?????????????? // reading bit pos inside bits
> +??????????????????????????????????????? // one of 24 (left, msb), 16, 
> 8, 0
> +??????? private boolean eos;
> +??????? private boolean closed;
> +??????? private byte[] onebuf = new byte[1];
>
> -??????? DecInputStream(InputStream is, int[] base64, boolean isMIME) {
> +??????? DecInputStream(InputStream is, byte[] base64, boolean isMIME) {
> ???????????? this.is = is;
> ???????????? this.base64 = base64;
> ???????????? this.isMIME = isMIME;
> ???????? }
>
> -??????? private byte[] sbBuf = new byte[1];
> -
> ???????? @Override
> ???????? public int read() throws IOException {
> -??????????? return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
> +??????????? return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
> +??????? }
> +
> +??????? private int leftovers(byte[] b, int off, int pos, int limit) {
> +??????????? eos = true;
> +??????????? while (rpos - 8 >= wpos && pos != limit) {
> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
> +??????????? }
> +??????????? return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
> ???????? }
>
> -??????? private int eof(byte[] b, int off, int len, int oldOff)
> -??????????? throws IOException
> -??????? {
> -??????????? eof = true;
> -??????????? if (nextin != 18) {
> -??????????????? if (nextin == 12)
> -??????????????????? throw new IOException("Base64 stream has one 
> un-decoded dangling byte.");
> -??????????????? // treat ending xx/xxx without padding character legal.
> -??????????????? // same logic as v == '=' below
> -??????????????? b[off++] = (byte)(bits >> (16));
> -??????????????? if (nextin == 0) {?????????? // only one padding byte
> -??????????????????? if (len == 1) {????????? // no enough output space
> -??????????????????????? bits >>= 8;????????? // shift to lowest byte
> -??????????????????????? nextout = 0;
> -??????????????????? } else {
> -??????????????????????? b[off++] = (byte) (bits >>? 8);
> -??????????????????? }
> -??????????????? }
> +??????? private int eos(byte[] b, int off, int pos, int limit) throws 
> IOException {
> +??????????? // wpos == 18: x???? dangling single x, invalid unit
> +??????????? // accept ending xx or xxx without padding characters
> +??????????? if (wpos == 18) {
> +??????????????? throw new IOException("Base64 stream has one 
> un-decoded dangling byte");
> ???????????? }
> -??????????? return off == oldOff ? -1 : off - oldOff;
> +??????????? rpos = 24;
> +??????????? return leftovers(b, off, pos, limit);
> ???????? }
>
> -??????? private int padding(byte[] b, int off, int len, int oldOff)
> -??????????? throws IOException
> -??????? {
> -??????????? // =???? shiftto==18 unnecessary padding
> -??????????? // x=??? shiftto==12 dangling x, invalid unit
> -??????????? // xx=?? shiftto==6 && missing last '='
> -??????????? // xx=y? or last is not '='
> -??????????? if (nextin == 18 || nextin == 12 ||
> -??????????????? nextin == 6 && is.read() != '=') {
> -??????????????? throw new IOException("Illegal base64 ending 
> sequence:" + nextin);
> +??????? private int padding(byte[] b, int off, int pos, int limit) 
> throws IOException {
> +??????????? // wpos == 24: =??? (unnecessary padding)
> +??????????? // wpos == 18: x=?? (dangling single x, invalid unit)
> +??????????? // wpos == 12 and missing last '=': xx=? (invalid padding)
> +??????????? // wpos == 12 and last is not '=': xx=x (invalid padding)
> +??????????? if (wpos >= 18 || wpos == 12 && is.read() != '=') {
> +??????????????? throw new IOException("Illegal base64 ending sequence");
> ???????????? }
> -??????????? b[off++] = (byte)(bits >> (16));
> -??????????? if (nextin == 0) {?????????? // only one padding byte
> -??????????????? if (len == 1) {????????? // no enough output space
> -??????????????????? bits >>= 8;????????? // shift to lowest byte
> -??????????????????? nextout = 0;
> -??????????????? } else {
> -??????????????????? b[off++] = (byte) (bits >>? 8);
> -??????????????? }
> -??????????? }
> -??????????? eof = true;
> -??????????? return off - oldOff;
> +??????????? rpos = 24;
> +??????????? return leftovers(b, off, pos, limit);
> ???????? }
>
> ???????? @Override
> ???????? public int read(byte[] b, int off, int len) throws IOException {
> -??????????? if (closed)
> +??????????? if (closed) {
> ???????????????? throw new IOException("Stream is closed");
> -??????????? if (eof && nextout < 0)??? // eof and no leftover
> -??????????????? return -1;
> -??????????? if (off < 0 || len < 0 || len > b.length - off)
> -??????????????? throw new IndexOutOfBoundsException();
> -??????????? int oldOff = off;
> -??????????? while (nextout >= 0) {?????? // leftover output byte(s) 
> in bits buf
> -??????????????? if (len == 0)
> -??????????????????? return off - oldOff;
> -??????????????? b[off++] = (byte)(bits >> nextout);
> -??????????????? len--;
> -??????????????? nextout -= 8;
> +??????????? }
> +??????????? Objects.checkFromIndexSize(off, len, b.length);
> +
> +??????????? // limit can overflow to Integer.MIN_VALUE. However, as long
> +??????????? // as comparisons with pos are done as coded, there's no 
> harm.
> +??????????? int pos = off;
> +??????????? int limit = off + len;
> +??????????? if (eos) {
> +??????????????? return leftovers(b, off, pos, limit);
> +??????????? }
> +
> +??????????? // leftovers from previous invocation; here, wpos == 0
> +??????????? while (rpos - 8 >= 0 && pos != limit) {
> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
> ???????????? }
> +??????????? if (pos == limit) {
> +??????????????? return limit - off;
> +??????????? }
> +
> ???????????? bits = 0;
> -??????????? while (len > 0) {
> -??????????????? int v = is.read();
> -??????????????? if (v == -1) {
> -??????????????????? return eof(b, off, len, oldOff);
> +??????????? wpos = 24;
> +??????????? while (pos != limit) {
> +??????????????? int i = is.read();
> +??????????????? if (i < 0) {
> +??????????????????? return eos(b, off, pos, limit);
> ???????????????? }
> -??????????????? if ((v = base64[v]) < 0) {
> -??????????????????? if (v == -2) {?????? // padding byte(s)
> -??????????????????????? return padding(b, off, len, oldOff);
> -??????????????????? }
> +??????????????? int v = base64[i];
> +??????????????? if (v < 0) {
> +??????????????????? // i not in alphabet
> +??????????????????? // v = -2 (i is '=') or v = -1 (i is other, e.g., 
> CR or LF)
> ???????????????????? if (v == -1) {
> -??????????????????????? if (!isMIME)
> -??????????????????????????? throw new IOException("Illegal base64 
> character " +
> -??????????????????????????????? Integer.toString(v, 16));
> -??????????????????????? continue;??????? // skip if for rfc2045
> +??????????????????????? if (isMIME) {
> +??????????????????????????? continue;
> +??????????????????????? }
> +??????????????????????? throw new IOException("Illegal base64 byte 0x" +
> +??????????????????????????????? Integer.toHexString(i));
> ???????????????????? }
> -??????????????????? // neve be here
> +??????????????????? return padding(b, off, pos, limit);
> ???????????????? }
> -??????????????? bits |= (v << nextin);
> -??????????????? if (nextin == 0) {
> -??????????????????? nextin = 18;???????? // clear for next in
> -??????????????????? b[off++] = (byte)(bits >> 16);
> -??????????????????? if (len == 1) {
> -??????????????????????? nextout = 8;??? // 2 bytes left in bits
> -??????????????????????? break;
> +??????????????? bits |= (v << (wpos -= 6));
> +??????????????? if (wpos == 0) {
> +??????????????????? if (limit - pos >= 3) {
> +??????????????????????? // frequently taken fast path, no need to 
> track rpos
> +??????????????????????? b[pos++] = (byte) (bits >> 16);
> +??????????????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????????????? b[pos++] = (byte) bits;
> +??????????????????????? bits = 0;
> +??????????????????????? wpos = 24;
> +??????????????????? } else {
> +??????????????????????? rpos = 24;
> +??????????????????????? while (pos != limit) {
> +??????????????????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
> +??????????????????????? }
> ???????????????????? }
> -??????????????????? b[off++] = (byte)(bits >> 8);
> -??????????????????? if (len == 2) {
> -??????????????????????? nextout = 0;??? // 1 byte left in bits
> -??????????????????????? break;
> -??????????????????? }
> -??????????????????? b[off++] = (byte)bits;
> -??????????????????? len -= 3;
> -??????????????????? bits = 0;
> -??????????????? } else {
> -??????????????????? nextin -= 6;
> ???????????????? }
> ???????????? }
> -??????????? return off - oldOff;
> +??????????? return limit - off;
> ???????? }
>
> ???????? @Override
> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
> b/test/jdk/java/util/Base64/TestBase64.java
> --- a/test/jdk/java/util/Base64/TestBase64.java
> +++ b/test/jdk/java/util/Base64/TestBase64.java
> @@ -144,6 +144,10 @@
> ???????? testDecoderKeepsAbstinence(Base64.getDecoder());
> ???????? testDecoderKeepsAbstinence(Base64.getUrlDecoder());
> ???????? testDecoderKeepsAbstinence(Base64.getMimeDecoder());
> +
> +??????? // tests patch addressing JDK-8222187
> +??????? // https://bugs.openjdk.java.net/browse/JDK-8222187
> +??????? testJDK_8222187();
> ???? }
>
> ???? private static void test(Base64.Encoder enc, Base64.Decoder dec,
> @@ -607,4 +611,27 @@
> ???????????? }
> ???????? }
> ???? }
> +
> +??? private static void testJDK_8222187() throws Throwable {
> +??????? byte[] orig = "12345678".getBytes("US-ASCII");
> +??????? byte[] encoded = Base64.getEncoder().encode(orig);
> +??????? // decode using different buffer sizes
> +??????? for (int bufferSize = 1; bufferSize <= 100; bufferSize++) {
> +??????????? try (
> +??????????????????? InputStream in = Base64.getDecoder().wrap(
> +??????????????????????????? new ByteArrayInputStream(encoded));
> +??????????????????? ByteArrayOutputStream baos = new 
> ByteArrayOutputStream();
> +??????????? ) {
> +??????????????? byte[] buffer = new byte[bufferSize];
> +??????????????? int read;
> +??????????????? while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
> +??????????????????? baos.write(buffer, 0, read);
> +??????????????? }
> +??????????????? // compare result, output info if lengths do not match
> +??????????????? byte[] decoded = baos.toByteArray();
> +??????????????? checkEqual(decoded, orig, "Base64 stream decoding 
> failed!");
> +??????????? }
> +??????? }
> +
> +??? }
> ?}
>
>
>
> On 2020-06-09 09:20, Raffaello Giulietti wrote:
>> Hi Lance,
>>
>> before working on a fix, I just wanted to make sure that I'm not 
>> interfering with existing efforts. Thus, I don't have a fix, yet.
>>
>> I'll be using the example provided in the bug report as a basic test.
>>
>> I'll show up here once the fix is ready.
>>
>>
>> Greetings
>> Raffaello
>>
>>
>>
>> On 2020-06-08 22:34, Lance Andersen wrote:
>>> Hi?Raffaello,
>>>
>>> If you are interested in providing a fix, you are more than welcome 
>>> to do so. ?Please include a test which validates your fix.
>>>
>>> Best
>>> lance
>>>
>>>> On Jun 8, 2020, at 3:45 PM, Raffaello Giulietti 
>>>> <raffaello.giulietti at gmail.com 
>>>> <mailto:raffaello.giulietti at gmail.com>> wrote:
>>>>
>>>> Raffaello
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle?Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>


From patrick.concannon at oracle.com  Thu Jul  2 16:45:13 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 2 Jul 2020 17:45:13 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
Message-ID: <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>


Hi Remi,

Well spotted on the bad link. I?ve updated that now.

http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>

As for the placement of the new FIs, it was decided that once we can use primitive types in generics the need for these interfaces will hopefully fade, and it was deemed better to keep them closer together for this reason. This approach also has the benefit of reducing the exposure / footprint of the general functional interfaces.

Kind regards,

Patrick


> On 2 Jul 2020, at 15:30, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Patrick & Julia,
> this version starts to look good.
> 
> I just don't understand why the new functional interfaces are not in java.util.function like the other ones ?
> (BTW, in the javadoc, the link to the summary overview point to the wrong one, to java.util.stream and not java.util.function).
> 
> About the examples, i will try to think about that this evening :)
> 
> regards,
> R?mi
> 
> ----- Mail original -----
>> De: "Patrick Concannon" <patrick.concannon at oracle.com>
>> ?: "Julia Boes" <julia.boes at oracle.com>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Jeudi 2 Juillet 2020 15:30:45
>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing?
> 
>> Hi,
>> 
>> John: Thanks for your feedback. We've rearranged the ordering of the parameters
>> of the BiConsumer to follow the convention you suggested, and hopefully improve
>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
>> Long}Stream.
>> 
>> Remi: Your argument makes sense, and we have updated the BiConsumers generic
>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
>> We have also removed the caching.
>> WRT to the wrappers used in the examples: good examples are tough to nail down.
>> We think the examples in their current form do a good job of demonstrating how
>> the method can be used, but we welcome any alternative suggestions.
>> 
>> 
>> The changes discussed can be found in the updated webrev below.
>> 
>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/
>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>
>> 
>> 
>> Kind regards,
>> 
>> Patrick
>> 
>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
>>> 
>>> w


From forax at univ-mlv.fr  Thu Jul  2 17:24:44 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 2 Jul 2020 19:24:44 +0200 (CEST)
Subject: =?utf-8?Q?Re:_RFR[8238286]:_'Add_new_flatMap_stream_?=
 =?utf-8?Q?operation_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
Message-ID: <1789420768.717300.1593710684361.JavaMail.zimbra@u-pem.fr>

Brian, I understand that adding new functional interfaces has a cost and when you know that generics over primitive types are around the corner, it starts to be an issue, but the compromise to put them in another place hoping that people will not find them is not very appealing, to say the least. Moreover, i'm pretty sure IDEs will find them anyway, so in the end, we are just creating another inconsistency. 

The cost of adding a new functional interfaces is perhaps too big compared to the need of introducing multiMap (still dislike the name). 
In that case, it's far better to wait and introduce multiMap() later when generics over primitives is added to Java. 

R?mi 

> De: "Patrick Concannon" <patrick.concannon at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Julia Boes" <julia.boes at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 2 Juillet 2020 18:45:13
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
> to pushing?

> Hi Remi,

> Well spotted on the bad link. I?ve updated that now.

> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ |
> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ ]

> As for the placement of the new FIs, it was decided that once we can use
> primitive types in generics the need for these interfaces will hopefully fade,
> and it was deemed better to keep them closer together for this reason. This
> approach also has the benefit of reducing the exposure / footprint of the
> general functional interfaces.

> Kind regards,

> Patrick

>> On 2 Jul 2020, at 15:30, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> Hi Patrick & Julia,
>> this version starts to look good.

>> I just don't understand why the new functional interfaces are not in
>> java.util.function like the other ones ?
>> (BTW, in the javadoc, the link to the summary overview point to the wrong one,
>> to java.util.stream and not java.util.function).

>> About the examples, i will try to think about that this evening :)

>> regards,
>> R?mi

>> ----- Mail original -----

>>> De: "Patrick Concannon" < [ mailto:patrick.concannon at oracle.com |
>>> patrick.concannon at oracle.com ] >
>>> ?: "Julia Boes" < [ mailto:julia.boes at oracle.com | julia.boes at oracle.com ] >
>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>>> core-libs-dev at openjdk.java.net ] >
>>> Envoy?: Jeudi 2 Juillet 2020 15:30:45
>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
>>> to pushing?

>>> Hi,

>>> John: Thanks for your feedback. We've rearranged the ordering of the parameters
>>> of the BiConsumer to follow the convention you suggested, and hopefully improve
>>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
>>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
>>> Long}Stream.

>>> Remi: Your argument makes sense, and we have updated the BiConsumers generic
>>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
>>> We have also removed the caching.
>>> WRT to the wrappers used in the examples: good examples are tough to nail down.
>>> We think the examples in their current form do a good job of demonstrating how
>>> the method can be used, but we welcome any alternative suggestions.

>>> The changes discussed can be found in the updated webrev below.

>>> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ |
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ ]
>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>

>>> Kind regards,

>>> Patrick

>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:

>>>> w

From paul.sandoz at oracle.com  Thu Jul  2 17:46:22 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 2 Jul 2020 10:46:22 -0700
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <1789420768.717300.1593710684361.JavaMail.zimbra@u-pem.fr>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <1789420768.717300.1593710684361.JavaMail.zimbra@u-pem.fr>
Message-ID: <337F3C60-9540-421B-8D6A-A7ECA03229BD@oracle.com>

Hi Remi,

This was my suggestion not Brian?s. I proposed to place these interfaces in the current location, likely to be renamed in accordance with the operation name, when that settles.

The rational is that they will fade away in unison with Int/*/Stream when generic specialization becomes available. The intent is to scope them to the specific purpose, and perhaps discourage their use outside this scope. Of course we cannot stop developers using them, but it should be clearer that it's not recommended.

IMHO your reasoning for delaying is placing the cart before the horse. This method has value now, the functional interfaces far less so (and in the future even less so), and we can reasonably reduce the scope of the API surface, getting the signature we want on Stream.

Paul.

> On Jul 2, 2020, at 10:24 AM, forax at univ-mlv.fr wrote:
> 
> Brian, I understand that adding new functional interfaces has a cost and when you know that generics over primitive types are around the corner, it starts to be an issue, but the compromise to put them in another place hoping that people will not find them is not very appealing, to say the least. Moreover, i'm pretty sure IDEs will find them anyway, so in the end, we are just creating another inconsistency. 
> 
> The cost of adding a new functional interfaces is perhaps too big compared to the need of introducing multiMap (still dislike the name). 
> In that case, it's far better to wait and introduce multiMap() later when generics over primitives is added to Java. 
> 
> R?mi 
> 
>> De: "Patrick Concannon" <patrick.concannon at oracle.com <mailto:patrick.concannon at oracle.com>>
>> ?: "Remi Forax" <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
>> Cc: "Julia Boes" <julia.boes at oracle.com <mailto:julia.boes at oracle.com>>, "core-libs-dev"
>> <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
>> Envoy?: Jeudi 2 Juillet 2020 18:45:13
>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
>> to pushing?
> 
>> Hi Remi,
> 
>> Well spotted on the bad link. I?ve updated that now.
> 
>> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ |
>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ ]
> 
>> As for the placement of the new FIs, it was decided that once we can use
>> primitive types in generics the need for these interfaces will hopefully fade,
>> and it was deemed better to keep them closer together for this reason. This
>> approach also has the benefit of reducing the exposure / footprint of the
>> general functional interfaces.
> 
>> Kind regards,
> 
>> Patrick
> 
>>> On 2 Jul 2020, at 15:30, Remi Forax < [ mailto:forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> |
>>> forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> ] > wrote:
> 
>>> Hi Patrick & Julia,
>>> this version starts to look good.
> 
>>> I just don't understand why the new functional interfaces are not in
>>> java.util.function like the other ones ?
>>> (BTW, in the javadoc, the link to the summary overview point to the wrong one,
>>> to java.util.stream and not java.util.function).
> 
>>> About the examples, i will try to think about that this evening :)
> 
>>> regards,
>>> R?mi
> 
>>> ----- Mail original -----
> 
>>>> De: "Patrick Concannon" < [ mailto:patrick.concannon at oracle.com <mailto:patrick.concannon at oracle.com> |
>>>> patrick.concannon at oracle.com <mailto:patrick.concannon at oracle.com> ] >
>>>> ?: "Julia Boes" < [ mailto:julia.boes at oracle.com <mailto:julia.boes at oracle.com> | julia.boes at oracle.com <mailto:julia.boes at oracle.com> ] >
>>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net> |
>>>> core-libs-dev at openjdk.java.net ] >
>>>> Envoy?: Jeudi 2 Juillet 2020 15:30:45
>>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
>>>> to pushing?
> 
>>>> Hi,
> 
>>>> John: Thanks for your feedback. We've rearranged the ordering of the parameters
>>>> of the BiConsumer to follow the convention you suggested, and hopefully improve
>>>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
>>>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
>>>> Long}Stream.
> 
>>>> Remi: Your argument makes sense, and we have updated the BiConsumers generic
>>>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
>>>> We have also removed the caching.
>>>> WRT to the wrappers used in the examples: good examples are tough to nail down.
>>>> We think the examples in their current form do a good job of demonstrating how
>>>> the method can be used, but we welcome any alternative suggestions.
> 
>>>> The changes discussed can be found in the updated webrev below.
> 
>>>> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> |
>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> ]
>>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>>
> 
>>>> Kind regards,
> 
>>>> Patrick
> 
>>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com <mailto:julia.boes at oracle.com>> wrote:
> 
>>>>> w


From sean.mullan at oracle.com  Thu Jul  2 18:33:57 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 2 Jul 2020 14:33:57 -0400
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>
 <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
Message-ID: <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>

On 6/24/20 2:56 PM, Daniel Fuchs wrote:
> The JNDI/LDAP part looks mostly good. You will need someone
> from the security libs to review the security lib part of the
> changes.

I have previously reviewed it but I would like to give it another once 
over. Max should also review the final version as he is the expert in JGSS.

Given we are around US holidays/vacation, expect some delay.

I suppose this is a bit of a grey area, but given the scope and the 
introduction of new properties and initial support for TLS channel 
binding, it seems more like an Enhancement than a Bug to me. That would 
kind of rule it out for JDK 15, but I suspect that what is more 
important is backporting this to prior releases, and that can be figured 
out later. So, JDK 16 as an initial target seems ok to me.

Thanks,
Sean

From ivan.sipka at oracle.com  Thu Jul  2 19:05:11 2020
From: ivan.sipka at oracle.com (Ivan Sipka)
Date: Thu, 2 Jul 2020 20:05:11 +0100
Subject: request for review JDK-8211290
In-Reply-To: <105EDE3D-E8A4-4798-BDA4-2EDE6803F964@oracle.com>
References: <d4910eee-10b3-4e55-9c4b-0e7daaee8ece@default>
 <105EDE3D-E8A4-4798-BDA4-2EDE6803F964@oracle.com>
Message-ID: <fee3f9c0-4401-ab9b-8fda-cdceb28a45e8@oracle.com>

Hi all,

thank you for the review, I updated the code and run the test.

best regards,

On 30/06/2020 23:15, Lance Andersen wrote:
> Hi Ivan,
>
> Looks fine to me also outside of the one extra line that Roger caught.
>
> Best
> Lance
>
>> On Jun 30, 2020, at 8:38 AM, Ivan Sipka <ivan.sipka at oracle.com 
>> <mailto:ivan.sipka at oracle.com>> wrote:
>>
>> Hi all,
>>
>> kind reminder for RFR for JDK-8211974.
>>
>> thank you,
>>
>> ----- Original Message -----
>> From: ivan.sipka at oracle.com <mailto:ivan.sipka at oracle.com>
>> To: core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>
>> Cc: igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>
>> Sent: Thursday, June 4, 2020 7:40:27 PM GMT +00:00 GMT Britain, 
>> Ireland, Portugal
>> Subject: request for review JDK-8211290
>>
>> Hi all,
>>
>> please review the following changeset: 
>> http://cr.openjdk.java.net/~iignatyev/isipka/8211974/webrev.01/index.html
>> for the JBS issue https://bugs.openjdk.java.net/browse/JDK-8211974
>>
>> which moves the files:
>>
>> open/test/jdk/lib/testlibrary/java/util/jar/Compiler.java
>> open/test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java
>>
>> to files:
>>
>> open/test/lib/jdk/test/lib/util/JarBuilder.java
>> open/test/lib/jdk/test/lib/compiler/Compiler.java
>>
>> and changes the relevant jtreg specification tags in dependent tests:
>>
>> open/test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java
>> open/test/jdk/jdk/nio/zipfs/jarfs/JFSTester.java
>> open/test/jdk/jdk/nio/zipfs/jarfs/MultiReleaseJarTest.java
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java
>> open/test/jdk/java/util/jar/JarFile/JarBacktickManifest.java
>> open/test/jdk/java/net/URL/JarHandlerPkgPrefix/JarHandlerPkgPrefix.java
>>
>> and adds relevant package imports to dependent file:
>>
>> open/test/jdk/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java
>>
>> jtreg command to run all dependent tests from repository root
>>
>> jtreg -verbose:summary -ea -esa -a -conc:9 -jdk:build/linux-x64/jdk/ 
>> open/test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java 
>> open/test/jdk/jdk/nio/zipfs/jarfs/JFSTester.java 
>> open/test/jdk/jdk/nio/zipfs/jarfs/MultiReleaseJarTest.java 
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java 
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java 
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java 
>> open/test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java 
>> open/test/jdk/java/util/jar/JarFile/JarBacktickManifest.java 
>> open/test/jdk/java/net/URL/JarHandlerPkgPrefix/JarHandlerPkgPrefix.java
>>
>> thank you,
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From ivan.sipka at oracle.com  Thu Jul  2 19:34:22 2020
From: ivan.sipka at oracle.com (Ivan Sipka)
Date: Thu, 2 Jul 2020 20:34:22 +0100
Subject: request for review JDK-8242935
Message-ID: <e4181193-dd55-d69e-9360-b31a68efb04c@oracle.com>

Hi all,

please review the following changeset:
http://cr.openjdk.java.net/~iignatyev/isipka/8242935/webrev.00/

for the JBS issue https://bugs.openjdk.java.net/browse/JDK-8242935

which replaces Nashorn scripting engine in a service reload test with services defined via classpath (Pear) and via module (Banana).

thank you,


From forax at univ-mlv.fr  Thu Jul  2 19:36:35 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 2 Jul 2020 21:36:35 +0200 (CEST)
Subject: =?utf-8?Q?Re:_RFR[8238286]:_'Add_new_flatMap_stream_?=
 =?utf-8?Q?operation_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <337F3C60-9540-421B-8D6A-A7ECA03229BD@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <1789420768.717300.1593710684361.JavaMail.zimbra@u-pem.fr>
 <337F3C60-9540-421B-8D6A-A7ECA03229BD@oracle.com>
Message-ID: <1790399176.747231.1593718595556.JavaMail.zimbra@u-pem.fr>

> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Julia Boes"
> <julia.boes at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>,
> "Patrick Concannon" <patrick.concannon at oracle.com>
> Envoy?: Jeudi 2 Juillet 2020 19:46:22
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
> to pushing?

> Hi Remi,

> This was my suggestion not Brian?s. I proposed to place these interfaces in the
> current location, likely to be renamed in accordance with the operation name,
> when that settles.

It's my way to summon him given that he was the spec lead on the Stream API. 

> The rational is that they will fade away in unison with Int/*/Stream when
> generic specialization becomes available. The intent is to scope them to the
> specific purpose, and perhaps discourage their use outside this scope. Of
> course we cannot stop developers using them, but it should be clearer that it's
> not recommended.

> IMHO your reasoning for delaying is placing the cart before the horse. This
> method has value now, the functional interfaces far less so (and in the future
> even less so), and we can reasonably reduce the scope of the API surface,
> getting the signature we want on Stream.

> This method has value now, the functional interfaces far less 

I understand the goal but it's not how Java is designed, a publicly visible method that takes a lambda requires the corresponding functional interface to be public. 
Trying to hide the functional interface just makes the code harder to read/understand, which go against one of the core principle of Java. 

Also do not forget that once you start to make something different for mapMulti than for the rest of the methods of Stream, it makes automatically the Stream API harder to use/understand because the way to use the API not regular anymore. 

> Paul.

R?mi 
you can not get your cart without everybody seeing the horse. 

>> On Jul 2, 2020, at 10:24 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:

>> Brian, I understand that adding new functional interfaces has a cost and when
>> you know that generics over primitive types are around the corner, it starts to
>> be an issue, but the compromise to put them in another place hoping that people
>> will not find them is not very appealing, to say the least. Moreover, i'm
>> pretty sure IDEs will find them anyway, so in the end, we are just creating
>> another inconsistency.

>> The cost of adding a new functional interfaces is perhaps too big compared to
>> the need of introducing multiMap (still dislike the name).
>> In that case, it's far better to wait and introduce multiMap() later when
>> generics over primitives is added to Java.

>> R?mi

>>> De: "Patrick Concannon" < [ mailto:patrick.concannon at oracle.com |
>>> patrick.concannon at oracle.com ] >
>>> ?: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "Julia Boes" < [ mailto:julia.boes at oracle.com | julia.boes at oracle.com ] >,
>>> "core-libs-dev"
>>> < [ mailto:core-libs-dev at openjdk.java.net | core-libs-dev at openjdk.java.net ] >
>>> Envoy?: Jeudi 2 Juillet 2020 18:45:13
>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
>>> to pushing?

>>> Hi Remi,

>>> Well spotted on the bad link. I?ve updated that now.

>>> [ [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ |
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ ] |
>>> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ |
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ ] ]

>>> As for the placement of the new FIs, it was decided that once we can use
>>> primitive types in generics the need for these interfaces will hopefully fade,
>>> and it was deemed better to keep them closer together for this reason. This
>>> approach also has the benefit of reducing the exposure / footprint of the
>>> general functional interfaces.

>>> Kind regards,

>>> Patrick

>>>> On 2 Jul 2020, at 15:30, Remi Forax < [ [ mailto:forax at univ-mlv.fr |
>>>> mailto:forax at univ-mlv.fr ] |
>>>> [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] ] > wrote:

>>>> Hi Patrick & Julia,
>>>> this version starts to look good.

>>>> I just don't understand why the new functional interfaces are not in
>>>> java.util.function like the other ones ?
>>>> (BTW, in the javadoc, the link to the summary overview point to the wrong one,
>>>> to java.util.stream and not java.util.function).

>>>> About the examples, i will try to think about that this evening :)

>>>> regards,
>>>> R?mi

>>>> ----- Mail original -----

>>>>> De: "Patrick Concannon" < [ [ mailto:patrick.concannon at oracle.com |
>>>>> mailto:patrick.concannon at oracle.com ] |
>>>>> [ mailto:patrick.concannon at oracle.com | patrick.concannon at oracle.com ] ] >
>>>>> ?: "Julia Boes" < [ [ mailto:julia.boes at oracle.com |
>>>>> mailto:julia.boes at oracle.com ] | [ mailto:julia.boes at oracle.com |
>>>>> julia.boes at oracle.com ] ] >
>>>>> Cc: "core-libs-dev" < [ [ mailto:core-libs-dev at openjdk.java.net |
>>>>> mailto:core-libs-dev at openjdk.java.net ] |
>>>>> [ mailto:core-libs-dev at openjdk.java.net | core-libs-dev at openjdk.java.net ] ] >
>>>>> Envoy?: Jeudi 2 Juillet 2020 15:30:45
>>>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
>>>>> to pushing?

>>>>> Hi,

>>>>> John: Thanks for your feedback. We've rearranged the ordering of the parameters
>>>>> of the BiConsumer to follow the convention you suggested, and hopefully improve
>>>>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
>>>>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
>>>>> Long}Stream.

>>>>> Remi: Your argument makes sense, and we have updated the BiConsumers generic
>>>>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
>>>>> We have also removed the caching.
>>>>> WRT to the wrappers used in the examples: good examples are tough to nail down.
>>>>> We think the examples in their current form do a good job of demonstrating how
>>>>> the method can be used, but we welcome any alternative suggestions.

>>>>> The changes discussed can be found in the updated webrev below.

>>>>> [ [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ |
>>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ ] |
>>>>> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ |
>>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ ] ]
>>>>> < [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ |
>>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ ] >

>>>>> Kind regards,

>>>>> Patrick

>>>>>> On 26 Jun 2020, at 17:46, Julia Boes < [ mailto:julia.boes at oracle.com |
>>>>>> julia.boes at oracle.com ] > wrote:

>>>>>> w

From andy.herrick at oracle.com  Thu Jul  2 22:53:50 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 2 Jul 2020 18:53:50 -0400
Subject: RFR: 824850: [macos] App created with jpackage on Mac fails with
 error -10810
Message-ID: <6e863819-50e9-f562-05dc-aab5883dd8c8@oracle.com>

Please review jpackage fix for issue [1] at [2].

The class path was no longer set correctly when jars are in a 
sub-directory of the input dir.

/Andy

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

[2] - http://cr.openjdk.java.net/~herrick/8248501/webrev.01/



From paul.sandoz at oracle.com  Fri Jul  3 00:20:55 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 2 Jul 2020 17:20:55 -0700
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <1790399176.747231.1593718595556.JavaMail.zimbra@u-pem.fr>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <1789420768.717300.1593710684361.JavaMail.zimbra@u-pem.fr>
 <337F3C60-9540-421B-8D6A-A7ECA03229BD@oracle.com>
 <1790399176.747231.1593718595556.JavaMail.zimbra@u-pem.fr>
Message-ID: <E51DAFC3-CBAE-428D-B086-2CBE3B5AF58F@oracle.com>

Hiding is a misleading characterization. It?s about reducing the API surface of this feature for reasons previously mentioned. I am reluctant to impose ObjIntConsumer vs. IntObjConsumer on developers.

Paul.


> On Jul 2, 2020, at 12:36 PM, forax at univ-mlv.fr wrote:
> 
> 
> The rational is that they will fade away in unison with Int/*/Stream when generic specialization becomes available. The intent is to scope them to the specific purpose, and perhaps discourage their use outside this scope. Of course we cannot stop developers using them, but it should be clearer that it's not recommended.
> 
> IMHO your reasoning for delaying is placing the cart before the horse. This method has value now, the functional interfaces far less so (and in the future even less so), and we can reasonably reduce the scope of the API surface, getting the signature we want on Stream.
> 
> > This method has value now, the functional interfaces far less
> 
> I understand the goal but it's not how Java is designed, a publicly visible method that takes a lambda requires the corresponding functional interface to be public.
> Trying to hide the functional interface just makes the code harder to read/understand, which go against one of the core principle of Java.
> 
> Also do not forget that once you start to make something different for mapMulti than for the rest of the methods of Stream, it makes automatically the Stream API harder to use/understand because the way to use the API not regular anymore.
> 
> 
> Paul.
> 
> R?mi
> you can not get your cart without everybody seeing the horse.
> 
> 
> On Jul 2, 2020, at 10:24 AM, forax at univ-mlv.fr wrote:
> 
> Brian, I understand that adding new functional interfaces has a cost and when you know that generics over primitive types are around the corner, it starts to be an issue, but the compromise to put them in another place hoping that people will not find them is not very appealing, to say the least. Moreover, i'm pretty sure IDEs will find them anyway, so in the end, we are just creating another inconsistency.
> 
> The cost of adding a new functional interfaces is perhaps too big compared to the need of introducing multiMap (still dislike the name).
> In that case, it's far better to wait and introduce multiMap() later when generics over primitives is added to Java.
> 
> R?mi
> 
> De: "Patrick Concannon" <patrick.concannon at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Julia Boes" <julia.boes at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 2 Juillet 2020 18:45:13
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
> to pushing?
> 
> Hi Remi,
> 
> Well spotted on the bad link. I?ve updated that now.
> 
> [ http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ |
> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ ]
> 
> As for the placement of the new FIs, it was decided that once we can use
> primitive types in generics the need for these interfaces will hopefully fade,
> and it was deemed better to keep them closer together for this reason. This
> approach also has the benefit of reducing the exposure / footprint of the
> general functional interfaces.
> 
> Kind regards,
> 
> Patrick
> 
> On 2 Jul 2020, at 15:30, Remi Forax < [mailto:forax at univ-mlv.fr|
> forax at univ-mlv.fr] > wrote:
> 
> Hi Patrick & Julia,
> this version starts to look good.
> 
> I just don't understand why the new functional interfaces are not in
> java.util.function like the other ones ?
> (BTW, in the javadoc, the link to the summary overview point to the wrong one,
> to java.util.stream and not java.util.function).
> 
> About the examples, i will try to think about that this evening :)
> 
> regards,
> R?mi
> 
> ----- Mail original -----
> 
> De: "Patrick Concannon" < [mailto:patrick.concannon at oracle.com|
> patrick.concannon at oracle.com] >
> ?: "Julia Boes" < [mailto:julia.boes at oracle.com|julia.boes at oracle.com] >
> Cc: "core-libs-dev" < [mailto:core-libs-dev at openjdk.java.net|
> core-libs-dev at openjdk.java.net ] >
> Envoy?: Jeudi 2 Juillet 2020 15:30:45
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
> to pushing?
> 
> Hi,
> 
> John: Thanks for your feedback. We've rearranged the ordering of the parameters
> of the BiConsumer to follow the convention you suggested, and hopefully improve
> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
> Long}Stream.
> 
> Remi: Your argument makes sense, and we have updated the BiConsumers generic
> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
> We have also removed the caching.
> WRT to the wrappers used in the examples: good examples are tough to nail down.
> We think the examples in their current form do a good job of demonstrating how
> the method can be used, but we welcome any alternative suggestions.
> 
> The changes discussed can be found in the updated webrev below.
> 
> [http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/|
> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/]
> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>
> 
> Kind regards,
> 
> Patrick
> 
> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
> 
> w


From alexander.matveev at oracle.com  Fri Jul  3 00:21:29 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 2 Jul 2020 17:21:29 -0700
Subject: RFR: 824850: [macos] App created with jpackage on Mac fails with
 error -10810
In-Reply-To: <6e863819-50e9-f562-05dc-aab5883dd8c8@oracle.com>
References: <6e863819-50e9-f562-05dc-aab5883dd8c8@oracle.com>
Message-ID: <10eb7907-8ce0-b1e2-b49a-6771ee4dce9c@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 7/2/2020 3:53 PM, Andy Herrick wrote:
> Please review jpackage fix for issue [1] at [2].
>
> The class path was no longer set correctly when jars are in a 
> sub-directory of the input dir.
>
> /Andy
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8248501
>
> [2] - http://cr.openjdk.java.net/~herrick/8248501/webrev.01/
>
>


From alexey.semenyuk at oracle.com  Fri Jul  3 00:28:05 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 2 Jul 2020 20:28:05 -0400
Subject: RFR: 824850: [macos] App created with jpackage on Mac fails with
 error -10810
In-Reply-To: <6e863819-50e9-f562-05dc-aab5883dd8c8@oracle.com>
References: <6e863819-50e9-f562-05dc-aab5883dd8c8@oracle.com>
Message-ID: <c97fab29-395c-891a-59b5-4573f57738d7@oracle.com>

Looks good.

- Alexey

On 7/2/2020 6:53 PM, Andy Herrick wrote:
> Please review jpackage fix for issue [1] at [2].
>
> The class path was no longer set correctly when jars are in a 
> sub-directory of the input dir.
>
> /Andy
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8248501
>
> [2] - http://cr.openjdk.java.net/~herrick/8248501/webrev.01/
>
>


From Yang.Zhang at arm.com  Fri Jul  3 02:15:27 2020
From: Yang.Zhang at arm.com (Yang Zhang)
Date: Fri, 3 Jul 2020 02:15:27 +0000
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <BYAPR11MB354348F74149B4E17BFB24E6EF6F0@BYAPR11MB3543.namprd11.prod.outlook.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <BYAPR11MB354348F74149B4E17BFB24E6EF6F0@BYAPR11MB3543.namprd11.prod.outlook.com>
Message-ID: <VI1PR0802MB255858E1565FB8263C42D0CF8E6A0@VI1PR0802MB2558.eurprd08.prod.outlook.com>

Hi Sandhya

Thanks very much for your help.

Regards,
Yang

-----Original Message-----
From: Viswanathan, Sandhya <sandhya.viswanathan at intel.com> 
Sent: Wednesday, July 1, 2020 2:57 AM
To: Yang Zhang <Yang.Zhang at arm.com>; Andrew Haley <aph at redhat.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi Yang,

I have merged vectorIntrinsics with changes from panama/default.

Hope this helps.
Best Regards,
Sandhya

-----Original Message-----
From: Yang Zhang <Yang.Zhang at arm.com>
Sent: Monday, June 29, 2020 12:49 AM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Andrew Haley <aph at redhat.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi Andrew,

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. 

3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't middle-end support.

I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again.



Hi Sandhya,

Could you please help to manual merge panama vectorIntrinsics/vector-unstable to jdk master? So that I can update this patch based on latest jdk master.

Regards
Yang


-----Original Message-----
From: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Sent: Thursday, June 25, 2020 3:04 AM
To: Yang Zhang <Yang.Zhang at arm.com>; Andrew Haley <aph at redhat.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi Andrew/Yang,
 
We couldn?t propose Vector API to target in time for JDK 15 and hoping to do so early in JDK 16 timeframe.
The implementation reviews on other components have made good progress. 
We have so far ok to PPT from (runtime, shared compiler changes, x86 backend).
Java API implementation review is in progress.
I wanted to check with you both if we have a go ahead from aarch64 backed point of view.

Best Regards,
Sandhya

-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of Yang Zhang
Sent: Tuesday, May 26, 2020 7:59 PM
To: Andrew Haley <aph at redhat.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

> But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not?

The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1].

2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved.
May I have a new patch for these? 

3. Panama/Vector API specific  instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't middle-end support.

Regards
Yang

[1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html

-----Original Message-----
From: Andrew Haley <aph at redhat.com>
Sent: Tuesday, May 26, 2020 4:25 PM
To: Yang Zhang <Yang.Zhang at arm.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd <nd at arm.com>
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing 
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement.

But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not?
It'd help if this was possible.

--
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 amaembo at gmail.com  Fri Jul  3 06:59:00 2020
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 3 Jul 2020 13:59:00 +0700
Subject: =?UTF-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_operation_?=
 =?UTF-8?Q?that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <5B4DFB68-747C-4EAB-A042-C24DF6516FB8@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <CAE+3fjbVO4nks1u3Gi7KPXAE1kq3ZJjEidkkOXcrdhkfTj4VnA@mail.gmail.com>
 <5B4DFB68-747C-4EAB-A042-C24DF6516FB8@oracle.com>
Message-ID: <CAE+3fjb-kkkfHKHUFMSuEj+=YXBE+S8Fsv9Ya9FEdzczKYeC0w@mail.gmail.com>

Hello!

Thank you for your feedback. I would disagree that my solution is more
complex. In fact, it's much more simple. It doesn't require any
changes in *Pipeline classes. Also, unlike your proposal, it doesn't
create different behavior for JDK stream implementation and for any
third-party stream implementations. Also, it's more user-friendly.
Your proposal assumes that push-like behavior could be necessary only
in flatMap-like scenarios. But what if somebody wants just to return
the stream to the caller? With your proposal, it could be done in some
hacky way like 'return Stream.of("bogus element").mapMulti((c,
ignored) -> ...)' instead of straightforward 'return ofPusher(c ->
...)'.

By the way, the proposed API allows no possibility to short-circuit
the pusher. So if mapMulti produces many elements and short-circuiting
terminal operation like anyMatch finds the match, it won't stop the
pusher from pushing. Have you considered to use
BiConsumer<Predicate<T>, T>, so Stream API may signal to the pusher
that it's ok to stop pushing? Note that in modern Java versions,
flatMap can actually short-circuit.

With best regards,
Tagir Valeev.

On Thu, Jul 2, 2020 at 9:39 PM Patrick Concannon
<patrick.concannon at oracle.com> wrote:
>
> Hi Tagir,
>
> Thank you for your input. However, we feel that this approach may add more complexity than is needed at this stage. It's a good point, and one that we think is reasonable to consider and evaluate as a possible follow on from this initial proposal.
>
> Kind regards,
>
> Patrick
>
> > On 25 Jun 2020, at 05:04, Tagir Valeev <amaembo at gmail.com> wrote:
> >
> > Hello!
> >
> > To me, it looks like it's possible to make the better default
> > implementation. It could be done even as a separate static method:
> >
> > static <T> Stream<T> ofPusher(Consumer<Consumer<? super T>> pusher) {
> >  return StreamSupport.stream(new Spliterator<>() {
> >    private Spliterator<T> delegate;
> >
> >    @Override
> >    public boolean tryAdvance(Consumer<? super T> action) {
> >      initDelegate();
> >      return delegate.tryAdvance(action);
> >    }
> >
> >    private void initDelegate() {
> >      if (delegate == null) {
> >        Stream.Builder<T> builder = Stream.builder(); // or use
> > SpinedBuffer directly
> >        pusher.accept(builder);
> >        delegate = builder.build().spliterator();
> >      }
> >    }
> >
> >    @Override
> >    public void forEachRemaining(Consumer<? super T> action) {
> >      if (delegate != null) {
> >        delegate.forEachRemaining(action);
> >      } else {
> >        pusher.accept(action);
> >      }
> >    }
> >
> >    @Override
> >    public Spliterator<T> trySplit() {
> >      initDelegate();
> >      return delegate.trySplit();
> >    }
> >
> >    @Override
> >    public long estimateSize() {
> >      return Long.MAX_VALUE;
> >    }
> >
> >    @Override
> >    public int characteristics() {
> >      return 0;
> >    }
> >  }, false);
> > }
> >
> > In this case, we are buffering only if short-circuit operation or
> > splitting is requested. Otherwise, forEachRemaining will just delegate
> > to the pusher.
> > Now, the default implementation could be rewritten as
> >
> > <T, R> Stream<R> mapMulti(Stream<T> stream, BiConsumer<Consumer<?
> > super R>, ? super T> mapper) {
> >  Objects.requireNonNull(mapper);
> >  return stream.flatMap(e -> ofPusher(sink -> mapper.accept(sink, e)));
> > }
> >
> > And now, I don't think it's necessary to specialize it at all.
> > Probably it's not necessary to introduce mapMulti at all as well, as
> > now it's a trivial delegate to ofPusher.
> >
> > With best regards,
> > Tagir Valeev.
> >
> > On Wed, Jun 24, 2020 at 5:58 PM Patrick Concannon
> > <patrick.concannon at oracle.com> wrote:
> >>
> >> Hi,
> >>
> >> Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing??
> >>
> >> This proposal is to add a new flatMap-like operation:
> >>
> >> `<R> Stream<R> mapMulti(BiConsumer<Consumer<R>, ? super T> mapper)`
> >>
> >> to the java.util.Stream class. This operation is more receptive to the pushing or yielding of values than the current implementation that internally assembles values (if any) into one or more streams. This addition includes the primitive variations of the operation i.e. mapMultiToInt, IntStream mapMulti, etc.
> >>
> >> issue: https://bugs.openjdk.java.net/browse/JDK-8238286 <https://bugs.openjdk.java.net/browse/JDK-8238286>
> >> csr: https://bugs.openjdk.java.net/browse/JDK-8248166 <https://bugs.openjdk.java.net/browse/JDK-8248166>
> >>
> >> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/>
> >> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html  <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html>
> >>
> >>
> >> Kind regards,
> >> Patrick & Julia
>

From weijun.wang at oracle.com  Fri Jul  3 08:08:32 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 3 Jul 2020 16:08:32 +0800
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>
 <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
Message-ID: <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>

The GSS and SASL changes look fine to me.

Two small questions:

1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it? Or, do you think we can define the sub-class inside GssKrb5Client and directly check its class name in InitialToken? This is a little ugly so you're free to ignore it.

2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier.

Thanks,
Max

> On Jul 3, 2020, at 2:33 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 6/24/20 2:56 PM, Daniel Fuchs wrote:
>> The JNDI/LDAP part looks mostly good. You will need someone
>> from the security libs to review the security lib part of the
>> changes.
> 
> I have previously reviewed it but I would like to give it another once over. Max should also review the final version as he is the expert in JGSS.
> 
> Given we are around US holidays/vacation, expect some delay.
> 
> I suppose this is a bit of a grey area, but given the scope and the introduction of new properties and initial support for TLS channel binding, it seems more like an Enhancement than a Bug to me. That would kind of rule it out for JDK 15, but I suspect that what is more important is backporting this to prior releases, and that can be figured out later. So, JDK 16 as an initial target seems ok to me.
> 
> Thanks,
> Sean


From julia.boes at oracle.com  Fri Jul  3 09:00:17 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Fri, 3 Jul 2020 10:00:17 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <CAE+3fjb-kkkfHKHUFMSuEj+=YXBE+S8Fsv9Ya9FEdzczKYeC0w@mail.gmail.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <CAE+3fjbVO4nks1u3Gi7KPXAE1kq3ZJjEidkkOXcrdhkfTj4VnA@mail.gmail.com>
 <5B4DFB68-747C-4EAB-A042-C24DF6516FB8@oracle.com>
 <CAE+3fjb-kkkfHKHUFMSuEj+=YXBE+S8Fsv9Ya9FEdzczKYeC0w@mail.gmail.com>
Message-ID: <c8f706bb-2b5b-3cc4-968f-cb01bd49cc4e@oracle.com>

Hi Tagir,
> By the way, the proposed API allows no possibility to short-circuit
> the pusher. So if mapMulti produces many elements and short-circuiting
> terminal operation like anyMatch finds the match, it won't stop the
> pusher from pushing. Have you considered to use
> BiConsumer<Predicate<T>, T>, so Stream API may signal to the pusher
> that it's ok to stop pushing? Note that in modern Java versions,
> flatMap can actually short-circuit.

We did prototype mapMulti with a Predicate and it brought to light some 
limitations that led us to decide against this approach.

1) On the user side, Predicate::test or Predicate::negate would be used 
to check if it's ok to keep pushing. The semantics of these methods 
doesn't really fit the use case (short-circuiting requested true/false) 
and we would probably need to come up with a new method to avoid confusion.

2) Along the lines of 1), but more generally the burden of exposing an 
implementation detail to the user. You are right that flatMap supports 
short-circuiting, but it's hidden in the implementation and the user 
doesn't need to know how it's implemented or how to make it work. For 
mapMulti however, we would need to expose some of it through the use of 
Predicate, and explain to the user how to use it correctly.

3) While the JDK implementation uses Sink, a type of Consumer that 
supports cancellation, the default implementation uses SpinedBuffer, a 
type of Consumer that does not support cancellation. We would need to 
add that functionality.

4) The difficulty of signalling a short-circuit request across the 
stream pipeline, in particular because mapMulti uses flatMap internally, 
which creates something like an inner nested pipeline. While it's 
possible to signal across the main outer pipeline, it's not easy to 
signal between outer and inner pipeline.


Regards,

Julia




From alexey at azul.com  Fri Jul  3 11:32:50 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Fri, 3 Jul 2020 11:32:50 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>
 <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
Message-ID: <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>

Hello All,

Thank you for review.

> 1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it?

As suggested by Max I?ve moved TlsChannelBindingImpl class into sub-package, so module-info.java exports TlsChannelBindingImpl only.

> 
> 2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier.

I think these changes could be useful to exclude situations when application trying to set Channel Binding with GSSContext::setChannelBinding and ?com.sun.jndi.ldap.tls.cbtype? property altogether. I can remove it, if you think it is not necessary.

Also, I've fixed Exception text and parseType(String prop) parameter name as suggested by Michael.
Unfortunately, I can not completely exclude usage of the literal names because of module import issues. Fixed in the TlsChannelBinding class only.

Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v10/

Regards
Alexey


From raffaello.giulietti at gmail.com  Fri Jul  3 12:47:10 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 3 Jul 2020 14:47:10 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
Message-ID: <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>

Hi,

with respect to [1], this version of the patch includes performance 
enhancements for the case of small buffers, in particular for the 
implementation of the no-arg read(), which makes use of a one-byte array.

I also expanded the comments.

As I don't have a webrev repo, I beg the reviewer(s) to publish the 
patch on the own repo, if it makes sense.


Greetings
Raffaello

----

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067538.html

---------------------------------------

# HG changeset patch
# User lello
# Date 1593779777 -7200
#      Fri Jul 03 14:36:17 2020 +0200
# Node ID 72f0e35ada03c4b850dc1bcd47e3296f14c6e531
# Parent  a7c0307232406c7b0c1a4b8c2de111077848203d
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>

diff --git a/src/java.base/share/classes/java/util/Base64.java 
b/src/java.base/share/classes/java/util/Base64.java
--- a/src/java.base/share/classes/java/util/Base64.java
+++ b/src/java.base/share/classes/java/util/Base64.java
@@ -30,7 +30,6 @@
  import java.io.IOException;
  import java.io.OutputStream;
  import java.nio.ByteBuffer;
-import java.nio.charset.StandardCharsets;

  import sun.nio.cs.ISO_8859_1;

@@ -133,7 +132,7 @@
       */
      public static Encoder getMimeEncoder(int lineLength, byte[] 
lineSeparator) {
           Objects.requireNonNull(lineSeparator);
-         int[] base64 = Decoder.fromBase64;
+         byte[] base64 = Decoder.fromBase64;
           for (byte b : lineSeparator) {
               if (base64[b & 0xff] != -1)
                   throw new IllegalArgumentException(
@@ -216,7 +215,7 @@
           * index values into their "Base64 Alphabet" equivalents as 
specified
           * in "Table 1: The Base64 Alphabet" of RFC 2045 (and RFC 4648).
           */
-        private static final char[] toBase64 = {
+        private static final byte[] toBase64 = {
              'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 
'L', 'M',
              'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 
'Y', 'Z',
              'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 
'l', 'm',
@@ -229,7 +228,7 @@
           * in Table 2 of the RFC 4648, with the '+' and '/' changed to 
'-' and
           * '_'. This table is used when BASE64_URL is specified.
           */
-        private static final char[] toBase64URL = {
+        private static final byte[] toBase64URL = {
              'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 
'L', 'M',
              'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 
'Y', 'Z',
              'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 
'l', 'm',
@@ -238,7 +237,7 @@
          };

          private static final int MIMELINEMAX = 76;
-        private static final byte[] CRLF = new byte[] {'\r', '\n'};
+        private static final byte[] CRLF = {'\r', '\n'};

          static final Encoder RFC4648 = new Encoder(false, null, -1, true);
          static final Encoder RFC4648_URLSAFE = new Encoder(true, null, 
-1, true);
@@ -255,27 +254,19 @@
           *
           */
          private final int encodedOutLength(int srclen, boolean 
throwOOME) {
-            int len = 0;
-            try {
-                if (doPadding) {
-                    len = Math.multiplyExact(4, (Math.addExact(srclen, 
2) / 3));
-                } else {
-                    int n = srclen % 3;
-                    len = Math.addExact(Math.multiplyExact(4, (srclen / 
3)), (n == 0 ? 0 : n + 1));
-                }
-                if (linemax > 0) {                             // line 
separators
-                    len = Math.addExact(len, (len - 1) / linemax * 
newline.length);
-                }
-            } catch (ArithmeticException ex) {
-                if (throwOOME) {
-                    throw new OutOfMemoryError("Encoded size is too 
large");
-                } else {
-                    // let the caller know that encoded bytes length
-                    // is too large
-                    len = -1;
-                }
+            long len = doPadding
+                    ? (srclen + 2L) / 3 * 4
+                    : (srclen + 2L) / 3 + srclen;
+            if (linemax > 0) {
+                len += (len - 1) / linemax * newline.length;
              }
-            return len;
+            if (len <= Integer.MAX_VALUE) {
+                return (int) len;
+            }
+            if (throwOOME) {
+                throw new OutOfMemoryError("Encoded size is too large");
+            }
+            return -1;
          }

          /**
@@ -421,24 +412,24 @@

          @HotSpotIntrinsicCandidate
          private void encodeBlock(byte[] src, int sp, int sl, byte[] 
dst, int dp, boolean isURL) {
-            char[] base64 = isURL ? toBase64URL : toBase64;
+            byte[] base64 = isURL ? toBase64URL : toBase64;
              for (int sp0 = sp, dp0 = dp ; sp0 < sl; ) {
                  int bits = (src[sp0++] & 0xff) << 16 |
                             (src[sp0++] & 0xff) <<  8 |
                             (src[sp0++] & 0xff);
-                dst[dp0++] = (byte)base64[(bits >>> 18) & 0x3f];
-                dst[dp0++] = (byte)base64[(bits >>> 12) & 0x3f];
-                dst[dp0++] = (byte)base64[(bits >>> 6)  & 0x3f];
-                dst[dp0++] = (byte)base64[bits & 0x3f];
+                dst[dp0++] = base64[(bits >>> 18) & 0x3f];
+                dst[dp0++] = base64[(bits >>> 12) & 0x3f];
+                dst[dp0++] = base64[(bits >>> 6)  & 0x3f];
+                dst[dp0++] = base64[bits & 0x3f];
              }
          }

          private int encode0(byte[] src, int off, int end, byte[] dst) {
-            char[] base64 = isURL ? toBase64URL : toBase64;
+            byte[] base64 = isURL ? toBase64URL : toBase64;
              int sp = off;
              int slen = (end - off) / 3 * 3;
              int sl = off + slen;
-            if (linemax > 0 && slen  > linemax / 4 * 3)
+            if (linemax > 0 && slen > linemax / 4 * 3)
                  slen = linemax / 4 * 3;
              int dp = 0;
              while (sp < sl) {
@@ -455,17 +446,17 @@
              }
              if (sp < end) {               // 1 or 2 leftover bytes
                  int b0 = src[sp++] & 0xff;
-                dst[dp++] = (byte)base64[b0 >> 2];
+                dst[dp++] = base64[b0 >> 2];
                  if (sp == end) {
-                    dst[dp++] = (byte)base64[(b0 << 4) & 0x3f];
+                    dst[dp++] = base64[(b0 << 4) & 0x3f];
                      if (doPadding) {
                          dst[dp++] = '=';
                          dst[dp++] = '=';
                      }
                  } else {
                      int b1 = src[sp++] & 0xff;
-                    dst[dp++] = (byte)base64[(b0 << 4) & 0x3f | (b1 >> 4)];
-                    dst[dp++] = (byte)base64[(b1 << 2) & 0x3f];
+                    dst[dp++] = base64[(b0 << 4) & 0x3f | (b1 >> 4)];
+                    dst[dp++] = base64[(b1 << 2) & 0x3f];
                      if (doPadding) {
                          dst[dp++] = '=';
                      }
@@ -523,11 +514,12 @@
           * the array are encoded to -1.
           *
           */
-        private static final int[] fromBase64 = new int[256];
+        private static final byte[] fromBase64 = new byte[256];
+
          static {
-            Arrays.fill(fromBase64, -1);
+            Arrays.fill(fromBase64, (byte) -1);
              for (int i = 0; i < Encoder.toBase64.length; i++)
-                fromBase64[Encoder.toBase64[i]] = i;
+                fromBase64[Encoder.toBase64[i]] = (byte) i;
              fromBase64['='] = -2;
          }

@@ -535,12 +527,12 @@
           * Lookup table for decoding "URL and Filename safe Base64 
Alphabet"
           * as specified in Table2 of the RFC 4648.
           */
-        private static final int[] fromBase64URL = new int[256];
+        private static final byte[] fromBase64URL = new byte[256];

          static {
-            Arrays.fill(fromBase64URL, -1);
+            Arrays.fill(fromBase64URL, (byte) -1);
              for (int i = 0; i < Encoder.toBase64URL.length; i++)
-                fromBase64URL[Encoder.toBase64URL[i]] = i;
+                fromBase64URL[Encoder.toBase64URL[i]] = (byte) i;
              fromBase64URL['='] = -2;
          }

@@ -699,7 +691,7 @@
           *
           */
          private int decodedOutLength(byte[] src, int sp, int sl) {
-            int[] base64 = isURL ? fromBase64URL : fromBase64;
+            byte[] base64 = isURL ? fromBase64URL : fromBase64;
              int paddings = 0;
              int len = sl - sp;
              if (len == 0)
@@ -743,7 +735,7 @@
          }

          private int decode0(byte[] src, int sp, int sl, byte[] dst) {
-            int[] base64 = isURL ? fromBase64URL : fromBase64;
+            byte[] base64 = isURL ? fromBase64URL : fromBase64;
              int dp = 0;
              int bits = 0;
              int shiftto = 18;       // pos of first byte of 4-byte atom
@@ -832,14 +824,14 @@
          private int b0, b1, b2;
          private boolean closed = false;

-        private final char[] base64;    // byte->base64 mapping
+        private final byte[] base64;    // byte->base64 mapping
          private final byte[] newline;   // line separator, if needed
          private final int linemax;
          private final boolean doPadding;// whether or not to pad
          private int linepos = 0;
          private byte[] buf;

-        EncOutputStream(OutputStream os, char[] base64,
+        EncOutputStream(OutputStream os, byte[] base64,
                          byte[] newline, int linemax, boolean doPadding) {
              super(os);
              this.base64 = base64;
@@ -863,11 +855,11 @@
              }
          }

-        private void writeb4(char b1, char b2, char b3, char b4) throws 
IOException {
-            buf[0] = (byte)b1;
-            buf[1] = (byte)b2;
-            buf[2] = (byte)b3;
-            buf[3] = (byte)b4;
+        private void writeb4(byte b1, byte b2, byte b3, byte b4) throws 
IOException {
+            buf[0] = b1;
+            buf[1] = b2;
+            buf[2] = b3;
+            buf[3] = b4;
              out.write(buf, 0, 4);
          }

@@ -909,10 +901,10 @@
                      int bits = (b[sp++] & 0xff) << 16 |
                                 (b[sp++] & 0xff) <<  8 |
                                 (b[sp++] & 0xff);
-                    buf[dp++] = (byte)base64[(bits >>> 18) & 0x3f];
-                    buf[dp++] = (byte)base64[(bits >>> 12) & 0x3f];
-                    buf[dp++] = (byte)base64[(bits >>> 6)  & 0x3f];
-                    buf[dp++] = (byte)base64[bits & 0x3f];
+                    buf[dp++] = base64[(bits >>> 18) & 0x3f];
+                    buf[dp++] = base64[(bits >>> 12) & 0x3f];
+                    buf[dp++] = base64[(bits >>> 6)  & 0x3f];
+                    buf[dp++] = base64[bits & 0x3f];
                  }
                  out.write(buf, 0, dp);
                  off = sl;
@@ -960,130 +952,175 @@
      private static class DecInputStream extends InputStream {

          private final InputStream is;
+        private final byte[] base64;    // mapping from alphabet to values
          private final boolean isMIME;
-        private final int[] base64;      // base64 -> byte mapping
-        private int bits = 0;            // 24-bit buffer for decoding
-        private int nextin = 18;         // next available "off" in 
"bits" for input;
-                                         // -> 18, 12, 6, 0
-        private int nextout = -8;        // next available "off" in 
"bits" for output;
-                                         // -> 8, 0, -8 (no byte for 
output)
-        private boolean eof = false;
-        private boolean closed = false;
+        private int bits;               // 24 bit buffer for decoding
+        private int wpos;               // writing bit pos inside bits
+                                        // one of 24 (left, msb), 18, 
12, 6, 0
+        private int rpos;               // reading bit pos inside bits
+                                        // one of 24 (left, msb), 16, 8, 0
+        private boolean eos;
+        private boolean closed;
+        private byte[] onebuf = new byte[1];

-        DecInputStream(InputStream is, int[] base64, boolean isMIME) {
+        DecInputStream(InputStream is, byte[] base64, boolean isMIME) {
              this.is = is;
              this.base64 = base64;
              this.isMIME = isMIME;
          }

-        private byte[] sbBuf = new byte[1];
-
          @Override
          public int read() throws IOException {
-            return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
+            return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
+        }
+
+        private int leftovers(byte[] b, int off, int pos, int limit) {
+            eos = true;
+            /*
+            We use a loop here, as this code is executed only once.
+            Unrolling the loop would probably not contribute much here.
+             */
+            while (rpos - 8 >= wpos && pos != limit) {
+                b[pos++] = (byte) (bits >> (rpos -= 8));
+            }
+            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
          }

-        private int eof(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
-            eof = true;
-            if (nextin != 18) {
-                if (nextin == 12)
-                    throw new IOException("Base64 stream has one 
un-decoded dangling byte.");
-                // treat ending xx/xxx without padding character legal.
-                // same logic as v == '=' below
-                b[off++] = (byte)(bits >> (16));
-                if (nextin == 0) {           // only one padding byte
-                    if (len == 1) {          // no enough output space
-                        bits >>= 8;          // shift to lowest byte
-                        nextout = 0;
-                    } else {
-                        b[off++] = (byte) (bits >>  8);
-                    }
-                }
+        private int eos(byte[] b, int off, int pos, int limit) throws 
IOException {
+            /*
+            wpos == 18: x     dangling single x, invalid unit
+            accept ending xx or xxx without padding characters
+             */
+            if (wpos == 18) {
+                throw new IOException("Base64 stream has one un-decoded 
dangling byte");
              }
-            return off == oldOff ? -1 : off - oldOff;
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
          }

-        private int padding(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
-            // =     shiftto==18 unnecessary padding
-            // x=    shiftto==12 dangling x, invalid unit
-            // xx=   shiftto==6 && missing last '='
-            // xx=y  or last is not '='
-            if (nextin == 18 || nextin == 12 ||
-                nextin == 6 && is.read() != '=') {
-                throw new IOException("Illegal base64 ending sequence:" 
+ nextin);
+        private int padding(byte[] b, int off, int pos, int limit) 
throws IOException {
+            /*
+            wpos == 24: =    (unnecessary padding)
+            wpos == 18: x=   (dangling single x, invalid unit)
+            wpos == 12 and missing last '=': xx=  (invalid padding)
+            wpos == 12 and last is not '=': xx=x (invalid padding)
+             */
+            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
+                throw new IOException("Illegal base64 ending sequence");
              }
-            b[off++] = (byte)(bits >> (16));
-            if (nextin == 0) {           // only one padding byte
-                if (len == 1) {          // no enough output space
-                    bits >>= 8;          // shift to lowest byte
-                    nextout = 0;
-                } else {
-                    b[off++] = (byte) (bits >>  8);
-                }
-            }
-            eof = true;
-            return off - oldOff;
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
          }

          @Override
          public int read(byte[] b, int off, int len) throws IOException {
-            if (closed)
+            if (closed) {
                  throw new IOException("Stream is closed");
-            if (eof && nextout < 0)    // eof and no leftover
-                return -1;
-            if (off < 0 || len < 0 || len > b.length - off)
-                throw new IndexOutOfBoundsException();
-            int oldOff = off;
-            while (nextout >= 0) {       // leftover output byte(s) in 
bits buf
-                if (len == 0)
-                    return off - oldOff;
-                b[off++] = (byte)(bits >> nextout);
-                len--;
-                nextout -= 8;
+            }
+            Objects.checkFromIndexSize(off, len, b.length);
+            if (len == 0) {
+                return 0;
              }
-            bits = 0;
-            while (len > 0) {
-                int v = is.read();
-                if (v == -1) {
-                    return eof(b, off, len, oldOff);
+
+            /*
+            Rather than keeping 2 running vars (e.g., off and len), we only
+            keep one (pos), while definitely fixing the boundaries of 
the range
+            [off, limit).
+
+            Note that limit can overflow to Integer.MIN_VALUE. However, 
as long
+            as comparisons with pos are done as coded, there's no harm.
+
+            In addition, limit - off (= len) is used from here on, so the
+            location for len can be reallocated to other vars (e.g., 
limit).
+             */
+            int pos = off;
+            int limit = off + len;
+            if (eos) {
+                return leftovers(b, off, pos, limit);
+            }
+
+            /*
+            leftovers from previous invocation; here, wpos = 0.
+            There can be at most 2 leftover bytes (rpos <= 16).
+            Further, the buffer b has at least one free place.
+
+            The logic could be coded as a loop, (as in method leftovers())
+            but the explicit "unrolling" makes it possible to generate 
better
+            byte extraction code.
+             */
+            if (rpos == 16) {
+                b[pos++] = (byte) (bits >> 8);
+                rpos = 8;
+                if (pos == limit) {
+                    return limit - off;
                  }
-                if ((v = base64[v]) < 0) {
-                    if (v == -2) {       // padding byte(s)
-                        return padding(b, off, len, oldOff);
-                    }
-                    if (v == -1) {
-                        if (!isMIME)
-                            throw new IOException("Illegal base64 
character " +
-                                Integer.toString(v, 16));
-                        continue;        // skip if for rfc2045
-                    }
-                    // neve be here
-                }
-                bits |= (v << nextin);
-                if (nextin == 0) {
-                    nextin = 18;         // clear for next in
-                    b[off++] = (byte)(bits >> 16);
-                    if (len == 1) {
-                        nextout = 8;    // 2 bytes left in bits
-                        break;
-                    }
-                    b[off++] = (byte)(bits >> 8);
-                    if (len == 2) {
-                        nextout = 0;    // 1 byte left in bits
-                        break;
-                    }
-                    b[off++] = (byte)bits;
-                    len -= 3;
-                    bits = 0;
-                } else {
-                    nextin -= 6;
+            }
+            if (rpos == 8) {
+                b[pos++] = (byte) bits;
+                rpos = 0;
+                if (pos == limit) {
+                    return limit - off;
                  }
              }
-            return off - oldOff;
+
+            bits = 0;
+            wpos = 24;
+            for (;;) {
+                // Here, pos != limit
+                int i = is.read();
+                if (i < 0) {
+                    return eos(b, off, pos, limit);
+                }
+                int v = base64[i];
+                if (v < 0) {
+                    /*
+                    i not in alphabet, thus
+                        v = -2: i is '=', the padding
+                        v = -1: i is something else, e.g., CR or LF
+                     */
+                    if (v == -1) {
+                        if (isMIME) {
+                            continue;
+                        }
+                        throw new IOException("Illegal base64 byte 0x" +
+                                Integer.toHexString(i));
+                    }
+                    return padding(b, off, pos, limit);
+                }
+                bits |= (v << (wpos -= 6));
+                if (wpos != 0) {
+                    continue;
+                }
+                if (limit - pos >= 3) {
+                    // frequently taken fast path, no need to track rpos
+                    b[pos++] = (byte) (bits >> 16);
+                    b[pos++] = (byte) (bits >> 8);
+                    b[pos++] = (byte) bits;
+                    bits = 0;
+                    wpos = 24;
+                    if (pos == limit) {
+                        return limit - off;
+                    }
+                    continue;
+                }
+                /*
+                Here, buffer b has either 1 or 2 free places, that is,
+                limit - pos = 1 or limit - pos = 2.
+
+                As above, this could be coded as a loop. But since the
+                shift lengths are explicit multiples of 8, better code 
can be
+                probably generated.
+                 */
+                b[pos++] = (byte) (bits >> 16);
+                if (pos == limit) {
+                    rpos = 16;
+                    return limit - off;
+                }
+                b[pos++] = (byte) (bits >> 8);
+                // Here, pos = limit, no need for an if.
+                rpos = 8;
+                return limit - off;
+            }
          }

          @Override
diff --git a/test/jdk/java/util/Base64/TestBase64.java 
b/test/jdk/java/util/Base64/TestBase64.java
--- a/test/jdk/java/util/Base64/TestBase64.java
+++ b/test/jdk/java/util/Base64/TestBase64.java
@@ -144,6 +144,10 @@
          testDecoderKeepsAbstinence(Base64.getDecoder());
          testDecoderKeepsAbstinence(Base64.getUrlDecoder());
          testDecoderKeepsAbstinence(Base64.getMimeDecoder());
+
+        // tests patch addressing JDK-8222187
+        // https://bugs.openjdk.java.net/browse/JDK-8222187
+        testJDK_8222187();
      }

      private static void test(Base64.Encoder enc, Base64.Decoder dec,
@@ -607,4 +611,27 @@
              }
          }
      }
+
+    private static void testJDK_8222187() throws Throwable {
+        byte[] orig = "12345678".getBytes("US-ASCII");
+        byte[] encoded = Base64.getEncoder().encode(orig);
+        // decode using different buffer sizes
+        for (int bufferSize = 1; bufferSize <= 100; bufferSize++) {
+            try (
+                    InputStream in = Base64.getDecoder().wrap(
+                            new ByteArrayInputStream(encoded));
+                    ByteArrayOutputStream baos = new 
ByteArrayOutputStream();
+            ) {
+                byte[] buffer = new byte[bufferSize];
+                int read;
+                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
+                    baos.write(buffer, 0, read);
+                }
+                // compare result, output info if lengths do not match
+                byte[] decoded = baos.toByteArray();
+                checkEqual(decoded, orig, "Base64 stream decoding 
failed!");
+            }
+        }
+
+    }
  }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8222187.patch
Type: text/x-patch
Size: 23557 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200703/0fc256d0/JDK-8222187-0001.patch>

From weijun.wang at oracle.com  Fri Jul  3 15:11:11 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 3 Jul 2020 23:11:11 +0800
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>
 <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
Message-ID: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>



> On Jul 3, 2020, at 7:32 PM, Alexey Bakhtin <alexey at azul.com> wrote:
> 
> Hello All,
> 
> Thank you for review.
> 
>> 1. If the change in java.security.jgss/share/classes/module-info.java is unavoidable, can we create a sub-package for this single class so that we only need to export it?
> 
> As suggested by Max I?ve moved TlsChannelBindingImpl class into sub-package, so module-info.java exports TlsChannelBindingImpl only.

Thanks.

> 
>> 
>> 2. Is GSSContextImpl::setChannelBinding really necessary? I don't know if there are people using null to erase a CB set earlier.
> 
> I think these changes could be useful to exclude situations when application trying to set Channel Binding with GSSContext::setChannelBinding and ?com.sun.jndi.ldap.tls.cbtype? property altogether. I can remove it, if you think it is not necessary.

I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it.

There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice.

> 
> Also, I've fixed Exception text and parseType(String prop) parameter name as suggested by Michael.
> Unfortunately, I can not completely exclude usage of the literal names because of module import issues. Fixed in the TlsChannelBinding class only.
> 
> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v10/

Thanks,
Max

> 
> Regards
> Alexey
> 


From alexey at azul.com  Fri Jul  3 15:31:22 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Fri, 3 Jul 2020 15:31:22 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>
 <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
Message-ID: <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>


> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it.
> 
> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice.

OK.
GSSContextImpl class is removed from patch.

Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11

Thank you
Alexey

From raffaello.giulietti at gmail.com  Fri Jul  3 15:48:12 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 3 Jul 2020 17:48:12 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
Message-ID: <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>

Hello,

after Roger's notes, which escaped my attention before, I've withdrawn 
all the changes but for DecInputStream, *except* that I couldn't resist 
to simplify the maths in encodedOutLength(), while still using 
xxxExact() arithmetic.

Sorry for the confusion
Raffaello



> Hi Raffaello,
> 
> There is way more code changed here than is needed to fix the bug.
> General enhancement should be separated from bug fixes.
> It makes it easier to review to see the bug was fixed
> and easier to separately review other code to see that there are no 
> unexpected changes.
> 
> If some of the changes are motivated by expected performance improvements,
> there should be JMH tests comparing the before and after.
> The change to use byte arrays seems useful, but even using char[]
> there is little danger of cache thrashing.
> 
> If using the code using xxxExact was correct, don't change it.
> Those methods are intrinsified and perform as well or better than using 
> long.
> Usually, it is better to leave code alone and not risk breaking it.
> 
> Special care needs taken when changing a method that is intrinsified.
> The optimized version may use fields of the object and stop
> working if they are changed.
> 
> In the test, the range of buffer sizes tests seems to waste a lot
> of cycles on sizes greater than the encoded size of the input.
> 
> Regards, Roger


---------------------

# HG changeset patch
# User lello
# Date 1593790152 -7200
#      Fri Jul 03 17:29:12 2020 +0200
# Node ID 73370832de1d2bf3b450930f5cb2467e10528c69
# Parent  a7c0307232406c7b0c1a4b8c2de111077848203d
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>

diff --git a/src/java.base/share/classes/java/util/Base64.java 
b/src/java.base/share/classes/java/util/Base64.java
--- a/src/java.base/share/classes/java/util/Base64.java
+++ b/src/java.base/share/classes/java/util/Base64.java
@@ -255,14 +255,11 @@
           *
           */
          private final int encodedOutLength(int srclen, boolean 
throwOOME) {
-            int len = 0;
+            int len;
              try {
-                if (doPadding) {
-                    len = Math.multiplyExact(4, (Math.addExact(srclen, 
2) / 3));
-                } else {
-                    int n = srclen % 3;
-                    len = Math.addExact(Math.multiplyExact(4, (srclen / 
3)), (n == 0 ? 0 : n + 1));
-                }
+                len = doPadding
+                        ? Math.multiplyExact(4, (Math.addExact(srclen, 
2) / 3))
+                        : Math.addExact((Math.addExact(srclen, 2) / 3), 
srclen);
                  if (linemax > 0) {                             // line 
separators
                      len = Math.addExact(len, (len - 1) / linemax * 
newline.length);
                  }
@@ -961,14 +958,15 @@

          private final InputStream is;
          private final boolean isMIME;
-        private final int[] base64;      // base64 -> byte mapping
-        private int bits = 0;            // 24-bit buffer for decoding
-        private int nextin = 18;         // next available "off" in 
"bits" for input;
-                                         // -> 18, 12, 6, 0
-        private int nextout = -8;        // next available "off" in 
"bits" for output;
-                                         // -> 8, 0, -8 (no byte for 
output)
-        private boolean eof = false;
-        private boolean closed = false;
+        private final int[] base64;     // mapping from alphabet to values
+        private int bits;               // 24 bit buffer for decoding
+        private int wpos;               // writing bit pos inside bits
+        // one of 24 (left, msb), 18, 12, 6, 0
+        private int rpos;               // reading bit pos inside bits
+        // one of 24 (left, msb), 16, 8, 0
+        private boolean eos;
+        private boolean closed;
+        private byte[] onebuf = new byte[1];

          DecInputStream(InputStream is, int[] base64, boolean isMIME) {
              this.is = is;
@@ -976,114 +974,158 @@
              this.isMIME = isMIME;
          }

-        private byte[] sbBuf = new byte[1];
-
          @Override
          public int read() throws IOException {
-            return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
+            return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
+        }
+
+        private int leftovers(byte[] b, int off, int pos, int limit) {
+            eos = true;
+            /*
+            We use a loop here, as this code is executed only once.
+            Unrolling the loop would probably not contribute much here.
+             */
+            while (rpos - 8 >= wpos && pos != limit) {
+                b[pos++] = (byte) (bits >> (rpos -= 8));
+            }
+            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
          }

-        private int eof(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
-            eof = true;
-            if (nextin != 18) {
-                if (nextin == 12)
-                    throw new IOException("Base64 stream has one 
un-decoded dangling byte.");
-                // treat ending xx/xxx without padding character legal.
-                // same logic as v == '=' below
-                b[off++] = (byte)(bits >> (16));
-                if (nextin == 0) {           // only one padding byte
-                    if (len == 1) {          // no enough output space
-                        bits >>= 8;          // shift to lowest byte
-                        nextout = 0;
-                    } else {
-                        b[off++] = (byte) (bits >>  8);
-                    }
-                }
+        private int eos(byte[] b, int off, int pos, int limit) throws 
IOException {
+            /*
+            wpos == 18: x     dangling single x, invalid unit
+            accept ending xx or xxx without padding characters
+             */
+            if (wpos == 18) {
+                throw new IOException("Base64 stream has one un-decoded 
dangling byte");
              }
-            return off == oldOff ? -1 : off - oldOff;
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
          }

-        private int padding(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
-            // =     shiftto==18 unnecessary padding
-            // x=    shiftto==12 dangling x, invalid unit
-            // xx=   shiftto==6 && missing last '='
-            // xx=y  or last is not '='
-            if (nextin == 18 || nextin == 12 ||
-                nextin == 6 && is.read() != '=') {
-                throw new IOException("Illegal base64 ending sequence:" 
+ nextin);
+        private int padding(byte[] b, int off, int pos, int limit) 
throws IOException {
+            /*
+            wpos == 24: =    (unnecessary padding)
+            wpos == 18: x=   (dangling single x, invalid unit)
+            wpos == 12 and missing last '=': xx=  (invalid padding)
+            wpos == 12 and last is not '=': xx=x (invalid padding)
+             */
+            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
+                throw new IOException("Illegal base64 ending sequence");
              }
-            b[off++] = (byte)(bits >> (16));
-            if (nextin == 0) {           // only one padding byte
-                if (len == 1) {          // no enough output space
-                    bits >>= 8;          // shift to lowest byte
-                    nextout = 0;
-                } else {
-                    b[off++] = (byte) (bits >>  8);
-                }
-            }
-            eof = true;
-            return off - oldOff;
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
          }

          @Override
          public int read(byte[] b, int off, int len) throws IOException {
-            if (closed)
+            if (closed) {
                  throw new IOException("Stream is closed");
-            if (eof && nextout < 0)    // eof and no leftover
-                return -1;
-            if (off < 0 || len < 0 || len > b.length - off)
-                throw new IndexOutOfBoundsException();
-            int oldOff = off;
-            while (nextout >= 0) {       // leftover output byte(s) in 
bits buf
-                if (len == 0)
-                    return off - oldOff;
-                b[off++] = (byte)(bits >> nextout);
-                len--;
-                nextout -= 8;
+            }
+            Objects.checkFromIndexSize(off, len, b.length);
+            if (len == 0) {
+                return 0;
              }
-            bits = 0;
-            while (len > 0) {
-                int v = is.read();
-                if (v == -1) {
-                    return eof(b, off, len, oldOff);
+
+            /*
+            Rather than keeping 2 running vars (e.g., off and len), we only
+            keep one (pos), while definitely fixing the boundaries of 
the range
+            [off, limit).
+
+            Note that limit can overflow to Integer.MIN_VALUE. However, 
as long
+            as comparisons with pos are done as coded, there's no harm.
+
+            In addition, limit - off (= len) is used from here on, so the
+            location for len can be reallocated to other vars (e.g., 
limit).
+             */
+            int pos = off;
+            int limit = off + len;
+            if (eos) {
+                return leftovers(b, off, pos, limit);
+            }
+
+            /*
+            leftovers from previous invocation; here, wpos = 0.
+            There can be at most 2 leftover bytes (rpos <= 16).
+            Further, the buffer b has at least one free place.
+
+            The logic could be coded as a loop, (as in method leftovers())
+            but the explicit "unrolling" makes it possible to generate 
better
+            byte extraction code.
+             */
+            if (rpos == 16) {
+                b[pos++] = (byte) (bits >> 8);
+                rpos = 8;
+                if (pos == limit) {
+                    return limit - off;
                  }
-                if ((v = base64[v]) < 0) {
-                    if (v == -2) {       // padding byte(s)
-                        return padding(b, off, len, oldOff);
-                    }
-                    if (v == -1) {
-                        if (!isMIME)
-                            throw new IOException("Illegal base64 
character " +
-                                Integer.toString(v, 16));
-                        continue;        // skip if for rfc2045
-                    }
-                    // neve be here
-                }
-                bits |= (v << nextin);
-                if (nextin == 0) {
-                    nextin = 18;         // clear for next in
-                    b[off++] = (byte)(bits >> 16);
-                    if (len == 1) {
-                        nextout = 8;    // 2 bytes left in bits
-                        break;
-                    }
-                    b[off++] = (byte)(bits >> 8);
-                    if (len == 2) {
-                        nextout = 0;    // 1 byte left in bits
-                        break;
-                    }
-                    b[off++] = (byte)bits;
-                    len -= 3;
-                    bits = 0;
-                } else {
-                    nextin -= 6;
+            }
+            if (rpos == 8) {
+                b[pos++] = (byte) bits;
+                rpos = 0;
+                if (pos == limit) {
+                    return limit - off;
                  }
              }
-            return off - oldOff;
+
+            bits = 0;
+            wpos = 24;
+            for (;;) {
+                // Here, pos != limit
+                int i = is.read();
+                if (i < 0) {
+                    return eos(b, off, pos, limit);
+                }
+                int v = base64[i];
+                if (v < 0) {
+                    /*
+                    i not in alphabet, thus
+                        v = -2: i is '=', the padding
+                        v = -1: i is something else, e.g., CR or LF
+                     */
+                    if (v == -1) {
+                        if (isMIME) {
+                            continue;
+                        }
+                        throw new IOException("Illegal base64 byte 0x" +
+                                Integer.toHexString(i));
+                    }
+                    return padding(b, off, pos, limit);
+                }
+                bits |= (v << (wpos -= 6));
+                if (wpos != 0) {
+                    continue;
+                }
+                if (limit - pos >= 3) {
+                    // frequently taken fast path, no need to track rpos
+                    b[pos++] = (byte) (bits >> 16);
+                    b[pos++] = (byte) (bits >> 8);
+                    b[pos++] = (byte) bits;
+                    bits = 0;
+                    wpos = 24;
+                    if (pos == limit) {
+                        return limit - off;
+                    }
+                    continue;
+                }
+                /*
+                Here, buffer b has either 1 or 2 free places, that is,
+                limit - pos = 1 or limit - pos = 2.
+
+                As above, this could be coded as a loop. But since the
+                shift lengths are explicit multiples of 8, better code 
can be
+                probably generated.
+                 */
+                b[pos++] = (byte) (bits >> 16);
+                if (pos == limit) {
+                    rpos = 16;
+                    return limit - off;
+                }
+                b[pos++] = (byte) (bits >> 8);
+                // Here, pos = limit, no need for an if.
+                rpos = 8;
+                return limit - off;
+            }
          }

          @Override
diff --git a/test/jdk/java/util/Base64/TestBase64.java 
b/test/jdk/java/util/Base64/TestBase64.java
--- a/test/jdk/java/util/Base64/TestBase64.java
+++ b/test/jdk/java/util/Base64/TestBase64.java
@@ -144,6 +144,10 @@
          testDecoderKeepsAbstinence(Base64.getDecoder());
          testDecoderKeepsAbstinence(Base64.getUrlDecoder());
          testDecoderKeepsAbstinence(Base64.getMimeDecoder());
+
+        // tests patch addressing JDK-8222187
+        // https://bugs.openjdk.java.net/browse/JDK-8222187
+        testJDK_8222187();
      }

      private static void test(Base64.Encoder enc, Base64.Decoder dec,
@@ -607,4 +611,26 @@
              }
          }
      }
+
+    private static void testJDK_8222187() throws Throwable {
+        byte[] orig = "12345678".getBytes("US-ASCII");
+        byte[] encoded = Base64.getEncoder().encode(orig);
+        // decode using different buffer sizes
+        for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
bufferSize++) {
+            try (
+                    InputStream in = Base64.getDecoder().wrap(
+                            new ByteArrayInputStream(encoded));
+                    ByteArrayOutputStream baos = new 
ByteArrayOutputStream();
+            ) {
+                byte[] buffer = new byte[bufferSize];
+                int read;
+                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
+                    baos.write(buffer, 0, read);
+                }
+                // compare result, output info if lengths do not match
+                byte[] decoded = baos.toByteArray();
+                checkEqual(decoded, orig, "Base64 stream decoding 
failed!");
+            }
+        }
+    }
  }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8222187.patch
Type: text/x-patch
Size: 14294 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200703/2bf1ee1d/JDK-8222187-0001.patch>

From dev at anthonyv.be  Sat Jul  4 16:23:50 2020
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Sat, 4 Jul 2020 18:23:50 +0200
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <3885AE11-2951-47B8-B030-6A0E87C7C73E@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <24F8FA40-3DC5-4156-B208-CCE54DB8CCF5@oracle.com>
 <2F795DFF-36B6-4903-B0AF-120973F29AD8@oracle.com>
 <6ea32a67-8292-39c7-df04-58ad15b2fde4@anthonyv.be>
 <3885AE11-2951-47B8-B030-6A0E87C7C73E@oracle.com>
Message-ID: <9703de63-8787-eb20-95cc-33dc911cf39c@anthonyv.be>

On 02/07/2020 16:38, Patrick Concannon wrote:
> Hi Anthony,
Hi Patrick
> Thanks for your suggestion of using a Stream.Builder instead of a Consumer.
Thanks for your response. Since Stream.Builder extends Consumer, I don't 
see it as "instead of": the proposed signature is a strict superset of 
the actual signature. For example, it would accept a BiConsumer<Object, 
Stream.Builder<String>>, whereas the current signature doesn't.
> However, one of the goals for mapMulti is not to create an additional Stream.
Would you mind to elaborate on this? Given that Stream.Builder extends 
Consumer, I don't see why using Stream.Builder would imply having to 
create any more Streams than when using Consumer.
> Also, I fear that using a builder, but throwing an exception on a call to build, is counter-intuitive and perhaps confusing to the user.
Point taken, but I beg to differ: to me this is no different than a 
method `void foo(Consumer<InputStream> bar)` which specifies that the 
given Consumer must not invoke `close` on the InputStream.
Moreover, with the build step being the sole difference with `flatMap`, 
and the elimination of intermediary Streams being a rather obvious 
optimization, I believe most users would find it intuitive not to invoke 
`build` themselves (or they would have read the Javadoc and know not to :)).
Finally, using Stream.Builder makes it intuitive for me what the method 
does, even without considering its name.

Given the above, I still hold that Stream.Builder is a better choice to 
use in the signature. Even more so, I believe there are several things 
that hint at the need for an additional abstraction: your point about 
the potential confusion, the analogy with Collector (as already 
mentioned by Paul w.r.t. the order of the BiConsumer's type arguments), 
and the natural similarity between e.g. BiConsumer<T, Stream.Builder<R>> 
and Function<T, Stream<R>>.

Therefore I'd like to propose the following (complete declarations below):

* introduce a new interface: Transformer<T, I, R> extends Function<T, R>
* adapt Collector to extend it: Collector<T, A, R> extends 
Transformer<Stream<T>, A, R>

So a Transformer is nothing more than a Function which passes via an 
intermediary I to map T to R according to a certain protocol.

Then a method with the following signature could be added to Stream:
<R> Stream<R> flatMap(Transformer<? super T, ? super Stream.Builder<R>, 
? extends Stream<R>> mapper)

Such a Transformer could readily be created from a given BiConsumer (see 
Tranformer::of below).

Since Transformer is a subinterface of Function, there wouldn't be any 
ambiguities w.r.t. overload resolution, so we could just name the new 
method `flatMap` (I assume such ambiguities are the reason why this 
currently isn't the case, since Function and BiConsumer are unrelated?).

Below is a self-contained "demo", containing a simple Demo class, the 
declaration of Transformer, and the adapted declaration of Collector.

Thanks in advance for any feedback.

Kind regards
Anthony



import java.util.ArrayList;
import java.util.List;
import java.util.Set;
import java.util.function.BiConsumer;
import java.util.function.BinaryOperator;
import java.util.function.Function;
import java.util.function.Supplier;
import java.util.stream.Stream;

public class Demo {

 ??? public static void main(String[] args) {
 ??????? BiConsumer<String, Stream.Builder<String>> anagrams = (word, 
builder) -> {
 ??????????? if(word.equals("listen")) {
 ??????????????? builder.accept("silent");
 ??????????????? builder.accept("enlist");
 ??????????? }
 ??????? };
Transformer.of(anagrams::accept).apply("listen").forEachOrdered(System.out::println);
 ??? }

}

interface Transformer<T, I, R> extends Function<T, R> {

 ??? Supplier<? extends I> supplier();

 ??? BiConsumer<? super T, ? super I> transformer();

 ??? Function<? super I, ? extends R> finisher();

 ??? @Override
 ??? default R apply(T t) {
 ??????? var intermediary = supplier().get();
 ??????? transformer().accept(t, intermediary);
 ??????? return finisher().apply(intermediary);
 ??? }

 ??? static <U, V> Transformer<U, Stream.Builder<V>, Stream<V>> 
of(BiConsumer<? super U, ? super Stream.Builder<V>> transformer) {
 ??????? return new Transformer<>() {
 ??????????? @Override
 ??????????? public Supplier<Stream.Builder<V>> supplier() {
 ??????????????? return Stream::builder;
 ??????????? }

 ??????????? @Override
 ??????????? public BiConsumer<U, Stream.Builder<V>> transformer() {
 ??????????????? return transformer::accept;
 ??????????? }

 ??????????? @Override
 ??????????? public Function<Stream.Builder<V>, Stream<V>> finisher() {
 ??????????????? return Stream.Builder::build;
 ??????????? }
 ??????? };
 ??? }

}

interface Collector<T, A, R> extends Transformer<Stream<T>, A, R> {

 ??? @Override
 ??? Supplier<A> supplier();

 ??? BiConsumer<A, T> accumulator();

 ??? BinaryOperator<A> combiner();

 ??? @Override
 ??? Function<A, R> finisher();

 ??? Set<Characteristics> characteristics();

 ??? enum Characteristics {
 ??????? CONCURRENT,
 ??????? UNORDERED,
 ??????? IDENTITY_FINISH
 ??? }

 ??? @Override
 ??? default BiConsumer<Stream<T>, A> transformer() {
 ??????? return (stream, intermediary) -> {
 ??????????? var accumulator = accumulator();
 ??????????? stream.forEachOrdered(t -> accumulator.accept(intermediary, 
t));
 ??????? };
 ??? }

}

>
> Kind regards,
>
> Patrick
>
>> On 25 Jun 2020, at 18:12, Anthony Vanelverdinghe <dev at anthonyv.be> wrote:
>>
>> Hi
>>
>> Given the signature of flatMap is:
>> <R> Stream<R> flatMap?(Function<? super T, ? extends Stream<? extends R>> mapper)
>>
>> I'd like to propose the following signature for the new method:
>> <R> Stream<R> builderMap(BiConsumer<? super T, ? super Stream.Builder<R>> mapper)
>>
>> This way both methods are named "...Map", and the name "builderMap" follows naturally from the argument's type.
>> If the given mapper invokes Stream.Builder::build, an IllegalStateException should be thrown.
>>
>> Kind regards,
>> Anthony
>>
>> On 25/06/2020 02:58, Paul Sandoz wrote:
>>> Hi,
>>>
>>> We traded CPS style for reusing existing functional interfaces. Originally the signature (my first choice) was as you indicate.
>>>
>>> By chance it just so happens that the current signature is the same shape as that for the accumulating argument type of the three arg collect terminal operation:
>>>
>>> Stream
>>> <R> R collect(Supplier<R> supplier,
>>>                BiConsumer<R, ? super T> accumulator,
>>>                BiConsumer<R, R> combiner);
>>>
>>> IntStream
>>> <R> R collect(Supplier<R> supplier,
>>>                ObjIntConsumer<R> accumulator,
>>>                BiConsumer<R, R> combiner);
>>>
>>> Same for the accumulator of a Collector too.
>>>
>>> However, I suspect you would argue these terminal accumulation cases are different from the intermediate case, as we are not accumulating but passing or accepting (loosely returning) zero or more elements that replace the input element.
>>>
>>> It?s my hope that generic specialization will allow the primitive stream types to fade into the background, along with the primitive functional interfaces. In that respect the addition of three functional interfaces for use on the primitive stream types is not so terrible.
>>>
>>>
>>> Regarding the name, you should have seen the first one :-) it was terrible.
>>>
>>> Here?s my few brush strokes on the bike shed. I wonder what people think of mapAccept. The specification talks about accepting elements, because that is the operative method name on Consumer. So we can say "T is replaced with the elements accepted by the Consumer<R>", or ? The Consumer<R> accepts the elements that replace T"
>>>
>>> Paul.
>>>
>>>
>>>
>>>> On Jun 24, 2020, at 1:01 PM, John Rose <john.r.rose at oracle.com> wrote:
>>>>
>>>> I like this new API point a lot; it allows flexible, local, temporary
>>>> control inversion in the context of one stream transform.
>>>>
>>>> What?s the performance model?  It seems like the SpinedBuffer
>>>> implementation makes a worst-case assumption about the number
>>>> of pending values, that there will be many instead of zero or one.
>>>>
>>>> But I guess the pipeline stuff already works in terms of pushes, so
>>>> the good news might be that this is really just a drill-down from the
>>>> user API into the kinds of operations (push-flavored) that go on
>>>> most of the time.
>>>>
>>>> OK, so I like the function but I have a beef with its bike shed
>>>> color.  First of all, this is a control-inversion (CPS) pattern,
>>>> which is very powerful but also notoriously hard to read.
>>>> I think that in Java APIs, at least in Stream APIs, code is
>>>> easier to read if the logical data flow is from left to right.
>>>>
>>>> (This is a language-specific observation.  Apart from varargs,
>>>> Java method APIs read favorably when extra control arguments
>>>> are added onto the end of the argument list.  Also, the convention
>>>> for generic functional interfaces is that the return value type
>>>> goes to the right, e.g., R in Function<A,R>.)
>>>>
>>>> So the BiConsumer is backwards, because the logical return
>>>> should be written, if not as a true return (which would appear
>>>> at the end of type parameter lists), at the end of the incoming
>>>> parameters (and in the last type parameter).
>>>>
>>>> I also think ?multi? is needlessly ?learned? sounding.  A simple
>>>> spatial preposition would work well: mapThrough, mapAcross, etc.
>>>> I think I prefer mapAcross because the term ?across? can be read
>>>> adverbially: ?we are mapping T across to Consumer<R>?.
>>>>
>>>> So:
>>>>
>>>> mapAcross(BiConsumer<? super T, Consumer<R>> mapper)
>>>> mapAcrossToInt(BiConsumer<? super T, IntConsumer> mapper)
>>>> mapAcross?(IntObjConsumer<IntConsumer> mapper)
>>>>
>>>> This does require additional FI?s like IntObjConsumer, but
>>>> I think that is a negligible cost.  Making the control inversion
>>>> *readable* is the high order bit here, not minimizing the number
>>>> of trivial FIs.
>>>>
>>>> (I almost hear David Bowman, in his space suit, saying, ?My API?
>>>> It?s full of bikesheds!?  There?s a meme for that.)
>>>>
>>>> ? John
>>>>
>>>> On Jun 24, 2020, at 3:57 AM, Patrick Concannon <patrick.concannon at oracle.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing??
>>>>>
>>>>> This proposal is to add a new flatMap-like operation:
>>>>>
>>>>> `<R> Stream<R> mapMulti(BiConsumer<Consumer<R>, ? super T> mapper)`
>>>>>
>>>>> to the java.util.Stream class. This operation is more receptive to the pushing or yielding of values than the current implementation that internally assembles values (if any) into one or more streams. This addition includes the primitive variations of the operation i.e. mapMultiToInt, IntStream mapMulti, etc.
>>>>>
>>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8238286 <https://bugs.openjdk.java.net/browse/JDK-8238286>
>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8248166 <https://bugs.openjdk.java.net/browse/JDK-8248166>
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/>
>>>>> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html  <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>> Patrick & Julia

From dev at anthonyv.be  Sat Jul  4 16:43:26 2020
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Sat, 4 Jul 2020 18:43:26 +0200
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <c8f706bb-2b5b-3cc4-968f-cb01bd49cc4e@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <CAE+3fjbVO4nks1u3Gi7KPXAE1kq3ZJjEidkkOXcrdhkfTj4VnA@mail.gmail.com>
 <5B4DFB68-747C-4EAB-A042-C24DF6516FB8@oracle.com>
 <CAE+3fjb-kkkfHKHUFMSuEj+=YXBE+S8Fsv9Ya9FEdzczKYeC0w@mail.gmail.com>
 <c8f706bb-2b5b-3cc4-968f-cb01bd49cc4e@oracle.com>
Message-ID: <47c1e40f-86ac-415d-5c43-674b47d8884d@anthonyv.be>

Hi Julia

Since short-circuiting sounds similar to a Subscriber cancelling its 
Subscription, I believe it might be worthwhile to consider the Flow API.
If the argument would be a `Flow.Processor<T, R>`, then the 
implementation would publish instances of T to it, subscribe to receive 
instances of R, and be able to short-circuit by cancelling its Subscription.

Disclaimer: I haven't actually prototyped this, but it makes sense at 
first thought

Kind regards,
Anthony

On 03/07/2020 11:00, Julia Boes wrote:
> Hi Tagir,
>> By the way, the proposed API allows no possibility to short-circuit
>> the pusher. So if mapMulti produces many elements and short-circuiting
>> terminal operation like anyMatch finds the match, it won't stop the
>> pusher from pushing. Have you considered to use
>> BiConsumer<Predicate<T>, T>, so Stream API may signal to the pusher
>> that it's ok to stop pushing? Note that in modern Java versions,
>> flatMap can actually short-circuit.
>
> We did prototype mapMulti with a Predicate and it brought to light 
> some limitations that led us to decide against this approach.
>
> 1) On the user side, Predicate::test or Predicate::negate would be 
> used to check if it's ok to keep pushing. The semantics of these 
> methods doesn't really fit the use case (short-circuiting requested 
> true/false) and we would probably need to come up with a new method to 
> avoid confusion.
>
> 2) Along the lines of 1), but more generally the burden of exposing an 
> implementation detail to the user. You are right that flatMap supports 
> short-circuiting, but it's hidden in the implementation and the user 
> doesn't need to know how it's implemented or how to make it work. For 
> mapMulti however, we would need to expose some of it through the use 
> of Predicate, and explain to the user how to use it correctly.
>
> 3) While the JDK implementation uses Sink, a type of Consumer that 
> supports cancellation, the default implementation uses SpinedBuffer, a 
> type of Consumer that does not support cancellation. We would need to 
> add that functionality.
>
> 4) The difficulty of signalling a short-circuit request across the 
> stream pipeline, in particular because mapMulti uses flatMap 
> internally, which creates something like an inner nested pipeline. 
> While it's possible to signal across the main outer pipeline, it's not 
> easy to signal between outer and inner pipeline.
>
>
> Regards,
>
> Julia
>
>
>

From peter.levart at gmail.com  Sun Jul  5 08:00:10 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 5 Jul 2020 10:00:10 +0200
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
Message-ID: <c4ac4586-8897-a7e5-c397-e18ff19114bf@gmail.com>

Hi Patrick,


In the test(s), you often use sink::accept:


 ??????? exerciseOps(data, s -> s.mapMulti((e, sink) -> 
IntStream.range(0, e).forEach(sink::accept)));


...where you could simply pass just sink:


 ??????? exerciseOps(data, s -> s.mapMulti((e, sink) -> 
IntStream.range(0, e).forEach(sink)));


Is this intentional and why?


Regards, Peter


On 7/2/20 6:45 PM, Patrick Concannon wrote:
> Hi Remi,
>
> Well spotted on the bad link. I?ve updated that now.
>
> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>
> As for the placement of the new FIs, it was decided that once we can use primitive types in generics the need for these interfaces will hopefully fade, and it was deemed better to keep them closer together for this reason. This approach also has the benefit of reducing the exposure / footprint of the general functional interfaces.
>
> Kind regards,
>
> Patrick
>
>
>> On 2 Jul 2020, at 15:30, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> Hi Patrick & Julia,
>> this version starts to look good.
>>
>> I just don't understand why the new functional interfaces are not in java.util.function like the other ones ?
>> (BTW, in the javadoc, the link to the summary overview point to the wrong one, to java.util.stream and not java.util.function).
>>
>> About the examples, i will try to think about that this evening :)
>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Patrick Concannon" <patrick.concannon at oracle.com>
>>> ?: "Julia Boes" <julia.boes at oracle.com>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Envoy?: Jeudi 2 Juillet 2020 15:30:45
>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing?
>>> Hi,
>>>
>>> John: Thanks for your feedback. We've rearranged the ordering of the parameters
>>> of the BiConsumer to follow the convention you suggested, and hopefully improve
>>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been
>>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double,
>>> Long}Stream.
>>>
>>> Remi: Your argument makes sense, and we have updated the BiConsumers generic
>>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out.
>>> We have also removed the caching.
>>> WRT to the wrappers used in the examples: good examples are tough to nail down.
>>> We think the examples in their current form do a good job of demonstrating how
>>> the method can be used, but we welcome any alternative suggestions.
>>>
>>>
>>> The changes discussed can be found in the updated webrev below.
>>>
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/
>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>
>>>
>>>
>>> Kind regards,
>>>
>>> Patrick
>>>
>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
>>>>
>>>> w

From peter.levart at gmail.com  Sun Jul  5 08:21:48 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 5 Jul 2020 10:21:48 +0200
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <c4ac4586-8897-a7e5-c397-e18ff19114bf@gmail.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <c4ac4586-8897-a7e5-c397-e18ff19114bf@gmail.com>
Message-ID: <68b0eb48-0d37-d625-c75e-bb182d6835c8@gmail.com>

...also note that examples in the Stream javadoc comments, like for example:


385 * <pre>{@code
386 * numbers.mapMulti((Consumer<Integer> c, Number n) -> {
387 * if (n instanceof Integer)
388 * c.accept((Integer) n);
389 * });
390 * }</pre>

...have the arguments (Consumer, element) still wrong. They are swapped 
now as of latest webrev.03:


422 default <R> Stream<R> mapMulti(BiConsumer<? super T, ? super 
Consumer<R>> mapper) {


Regards, Peter


On 7/5/20 10:00 AM, Peter Levart wrote:
> Hi Patrick,
>
>
> In the test(s), you often use sink::accept:
>
>
> ??????? exerciseOps(data, s -> s.mapMulti((e, sink) -> 
> IntStream.range(0, e).forEach(sink::accept)));
>
>
> ...where you could simply pass just sink:
>
>
> ??????? exerciseOps(data, s -> s.mapMulti((e, sink) -> 
> IntStream.range(0, e).forEach(sink)));
>
>
> Is this intentional and why?
>
>
> Regards, Peter
>
>
> On 7/2/20 6:45 PM, Patrick Concannon wrote:
>> Hi Remi,
>>
>> Well spotted on the bad link. I?ve updated that now.
>>
>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ 
>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>>
>> As for the placement of the new FIs, it was decided that once we can 
>> use primitive types in generics the need for these interfaces will 
>> hopefully fade, and it was deemed better to keep them closer together 
>> for this reason. This approach also has the benefit of reducing the 
>> exposure / footprint of the general functional interfaces.
>>
>> Kind regards,
>>
>> Patrick
>>
>>
>>> On 2 Jul 2020, at 15:30, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>> Hi Patrick & Julia,
>>> this version starts to look good.
>>>
>>> I just don't understand why the new functional interfaces are not in 
>>> java.util.function like the other ones ?
>>> (BTW, in the javadoc, the link to the summary overview point to the 
>>> wrong one, to java.util.stream and not java.util.function).
>>>
>>> About the examples, i will try to think about that this evening :)
>>>
>>> regards,
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Patrick Concannon" <patrick.concannon at oracle.com>
>>>> ?: "Julia Boes" <julia.boes at oracle.com>
>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>> Envoy?: Jeudi 2 Juillet 2020 15:30:45
>>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is 
>>>> more amenable to pushing?
>>>> Hi,
>>>>
>>>> John: Thanks for your feedback. We've rearranged the ordering of 
>>>> the parameters
>>>> of the BiConsumer to follow the convention you suggested, and 
>>>> hopefully improve
>>>> readability going forward. Additional FIs (IntObjConsumer, etc.) 
>>>> have been
>>>> added as sub-interfaces to the corresponding Stream classes i.e. 
>>>> {Int, Double,
>>>> Long}Stream.
>>>>
>>>> Remi: Your argument makes sense, and we have updated the 
>>>> BiConsumers generic
>>>> type to `<? super Consumer<R>>` as you suggested. Thanks for 
>>>> pointing this out.
>>>> We have also removed the caching.
>>>> WRT to the wrappers used in the examples: good examples are tough 
>>>> to nail down.
>>>> We think the examples in their current form do a good job of 
>>>> demonstrating how
>>>> the method can be used, but we welcome any alternative suggestions.
>>>>
>>>>
>>>> The changes discussed can be found in the updated webrev below.
>>>>
>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/
>>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Patrick
>>>>
>>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> wrote:
>>>>>
>>>>> w

From peter.levart at gmail.com  Sun Jul  5 08:44:25 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 5 Jul 2020 10:44:25 +0200
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
Message-ID: <03b4d761-cdaf-2c35-89ec-6227d9ecf700@gmail.com>

Hi Patric, Julia,

On 7/2/20 6:45 PM, Patrick Concannon wrote:
> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/  <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>


Then I'd like to discuss cancelation (shortcut Streams). Currently 
mapMulti does not do anything to optimize processing if the downstream 
decides it does not need more elements but just keeps pushing. This is a 
decision I guess to keep the API surface clean and simple. All 
short-cutting ops or even intermediate (like limit) must therefore 
ignore the surplus elements that are emitted by mapMulti and they do so. 
If the intermediate operations up-stream mapMulti are respecting the 
cancelation, this results in at most one invocation of mapMulti function 
producing surplus elements, but if they don't, then multiple invocations 
of mapMulti function is producing surplus elements.

For example:


 ??? someStream

 ??? ??? .mapMulti((e, sink) -> { .... sink.accept(x); ... })

 ??? ??? .filter(x -> ...)

 ??? ??? .mapMulti((x, sink) -> { ... sink.accept(y); ...})

 ??? ??? .limit(10)

 ??? ??? ...


Here the 1st mapMulti emits elements and each of them is filtered and 
then maybe passed to 2nd mapMulti. the 2nd mapMulti could skip calling 
its function if the downstream limit(10) has already passed 10 elements.


WDYT?


Regards, Peter



From Roger.Riggs at oracle.com  Mon Jul  6 18:17:45 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 6 Jul 2020 14:17:45 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
Message-ID: <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>

Hi Raffaello,

I'm still not sure it needed this much of a re-write to fix the bug;
It will take some time to look at the changes.

Regardless, OpenJDK conventions call for following the style of the 
existing code.
Your new comments follow neither the existing convention to use "//..." 
comments
nor the other prevalent comment form using /*... */ which use consistent 
indentation
and "* " on continuation lines.

Regards, Roger


On 7/3/20 11:48 AM, Raffaello Giulietti wrote:
> Hello,
>
> after Roger's notes, which escaped my attention before, I've withdrawn 
> all the changes but for DecInputStream, *except* that I couldn't 
> resist to simplify the maths in encodedOutLength(), while still using 
> xxxExact() arithmetic.
>
> Sorry for the confusion
> Raffaello
>
>
>
>> Hi Raffaello,
>>
>> There is way more code changed here than is needed to fix the bug.
>> General enhancement should be separated from bug fixes.
>> It makes it easier to review to see the bug was fixed
>> and easier to separately review other code to see that there are no 
>> unexpected changes.
>>
>> If some of the changes are motivated by expected performance 
>> improvements,
>> there should be JMH tests comparing the before and after.
>> The change to use byte arrays seems useful, but even using char[]
>> there is little danger of cache thrashing.
>>
>> If using the code using xxxExact was correct, don't change it.
>> Those methods are intrinsified and perform as well or better than 
>> using long.
>> Usually, it is better to leave code alone and not risk breaking it.
>>
>> Special care needs taken when changing a method that is intrinsified.
>> The optimized version may use fields of the object and stop
>> working if they are changed.
>>
>> In the test, the range of buffer sizes tests seems to waste a lot
>> of cycles on sizes greater than the encoded size of the input.
>>
>> Regards, Roger
>
>
> ---------------------
>
> # HG changeset patch
> # User lello
> # Date 1593790152 -7200
> #????? Fri Jul 03 17:29:12 2020 +0200
> # Node ID 73370832de1d2bf3b450930f5cb2467e10528c69
> # Parent? a7c0307232406c7b0c1a4b8c2de111077848203d
> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
> the end
> Reviewed-by: TBD
> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>
> diff --git a/src/java.base/share/classes/java/util/Base64.java 
> b/src/java.base/share/classes/java/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java
> +++ b/src/java.base/share/classes/java/util/Base64.java
> @@ -255,14 +255,11 @@
> ????????? *
> ????????? */
> ???????? private final int encodedOutLength(int srclen, boolean 
> throwOOME) {
> -??????????? int len = 0;
> +??????????? int len;
> ???????????? try {
> -??????????????? if (doPadding) {
> -??????????????????? len = Math.multiplyExact(4, 
> (Math.addExact(srclen, 2) / 3));
> -??????????????? } else {
> -??????????????????? int n = srclen % 3;
> -??????????????????? len = Math.addExact(Math.multiplyExact(4, (srclen 
> / 3)), (n == 0 ? 0 : n + 1));
> -??????????????? }
> +??????????????? len = doPadding
> +??????????????????????? ? Math.multiplyExact(4, 
> (Math.addExact(srclen, 2) / 3))
> +??????????????????????? : Math.addExact((Math.addExact(srclen, 2) / 
> 3), srclen);
> ???????????????? if (linemax > 0) { // line separators
> ???????????????????? len = Math.addExact(len, (len - 1) / linemax * 
> newline.length);
> ???????????????? }
> @@ -961,14 +958,15 @@
>
> ???????? private final InputStream is;
> ???????? private final boolean isMIME;
> -??????? private final int[] base64;????? // base64 -> byte mapping
> -??????? private int bits = 0;??????????? // 24-bit buffer for decoding
> -??????? private int nextin = 18;???????? // next available "off" in 
> "bits" for input;
> -???????????????????????????????????????? // -> 18, 12, 6, 0
> -??????? private int nextout = -8;??????? // next available "off" in 
> "bits" for output;
> -???????????????????????????????????????? // -> 8, 0, -8 (no byte for 
> output)
> -??????? private boolean eof = false;
> -??????? private boolean closed = false;
> +??????? private final int[] base64;???? // mapping from alphabet to 
> values
> +??????? private int bits;?????????????? // 24 bit buffer for decoding
> +??????? private int wpos;?????????????? // writing bit pos inside bits
> +??????? // one of 24 (left, msb), 18, 12, 6, 0
> +??????? private int rpos;?????????????? // reading bit pos inside bits
> +??????? // one of 24 (left, msb), 16, 8, 0
> +??????? private boolean eos;
> +??????? private boolean closed;
> +??????? private byte[] onebuf = new byte[1];
>
> ???????? DecInputStream(InputStream is, int[] base64, boolean isMIME) {
> ???????????? this.is = is;
> @@ -976,114 +974,158 @@
> ???????????? this.isMIME = isMIME;
> ???????? }
>
> -??????? private byte[] sbBuf = new byte[1];
> -
> ???????? @Override
> ???????? public int read() throws IOException {
> -??????????? return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
> +??????????? return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
> +??????? }
> +
> +??????? private int leftovers(byte[] b, int off, int pos, int limit) {
> +??????????? eos = true;
> +??????????? /*
> +??????????? We use a loop here, as this code is executed only once.
> +??????????? Unrolling the loop would probably not contribute much here.
> +???????????? */
> +??????????? while (rpos - 8 >= wpos && pos != limit) {
> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
> +??????????? }
> +??????????? return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
> ???????? }
>
> -??????? private int eof(byte[] b, int off, int len, int oldOff)
> -??????????? throws IOException
> -??????? {
> -??????????? eof = true;
> -??????????? if (nextin != 18) {
> -??????????????? if (nextin == 12)
> -??????????????????? throw new IOException("Base64 stream has one 
> un-decoded dangling byte.");
> -??????????????? // treat ending xx/xxx without padding character legal.
> -??????????????? // same logic as v == '=' below
> -??????????????? b[off++] = (byte)(bits >> (16));
> -??????????????? if (nextin == 0) {?????????? // only one padding byte
> -??????????????????? if (len == 1) {????????? // no enough output space
> -??????????????????????? bits >>= 8;????????? // shift to lowest byte
> -??????????????????????? nextout = 0;
> -??????????????????? } else {
> -??????????????????????? b[off++] = (byte) (bits >>? 8);
> -??????????????????? }
> -??????????????? }
> +??????? private int eos(byte[] b, int off, int pos, int limit) throws 
> IOException {
> +??????????? /*
> +??????????? wpos == 18: x???? dangling single x, invalid unit
> +??????????? accept ending xx or xxx without padding characters
> +???????????? */
> +??????????? if (wpos == 18) {
> +??????????????? throw new IOException("Base64 stream has one 
> un-decoded dangling byte");
> ???????????? }
> -??????????? return off == oldOff ? -1 : off - oldOff;
> +??????????? rpos = 24;
> +??????????? return leftovers(b, off, pos, limit);
> ???????? }
>
> -??????? private int padding(byte[] b, int off, int len, int oldOff)
> -??????????? throws IOException
> -??????? {
> -??????????? // =???? shiftto==18 unnecessary padding
> -??????????? // x=??? shiftto==12 dangling x, invalid unit
> -??????????? // xx=?? shiftto==6 && missing last '='
> -??????????? // xx=y? or last is not '='
> -??????????? if (nextin == 18 || nextin == 12 ||
> -??????????????? nextin == 6 && is.read() != '=') {
> -??????????????? throw new IOException("Illegal base64 ending 
> sequence:" + nextin);
> +??????? private int padding(byte[] b, int off, int pos, int limit) 
> throws IOException {
> +??????????? /*
> +??????????? wpos == 24: =??? (unnecessary padding)
> +??????????? wpos == 18: x=?? (dangling single x, invalid unit)
> +??????????? wpos == 12 and missing last '=': xx=? (invalid padding)
> +??????????? wpos == 12 and last is not '=': xx=x (invalid padding)
> +???????????? */
> +??????????? if (wpos >= 18 || wpos == 12 && is.read() != '=') {
> +??????????????? throw new IOException("Illegal base64 ending sequence");
> ???????????? }
> -??????????? b[off++] = (byte)(bits >> (16));
> -??????????? if (nextin == 0) {?????????? // only one padding byte
> -??????????????? if (len == 1) {????????? // no enough output space
> -??????????????????? bits >>= 8;????????? // shift to lowest byte
> -??????????????????? nextout = 0;
> -??????????????? } else {
> -??????????????????? b[off++] = (byte) (bits >>? 8);
> -??????????????? }
> -??????????? }
> -??????????? eof = true;
> -??????????? return off - oldOff;
> +??????????? rpos = 24;
> +??????????? return leftovers(b, off, pos, limit);
> ???????? }
>
> ???????? @Override
> ???????? public int read(byte[] b, int off, int len) throws IOException {
> -??????????? if (closed)
> +??????????? if (closed) {
> ???????????????? throw new IOException("Stream is closed");
> -??????????? if (eof && nextout < 0)??? // eof and no leftover
> -??????????????? return -1;
> -??????????? if (off < 0 || len < 0 || len > b.length - off)
> -??????????????? throw new IndexOutOfBoundsException();
> -??????????? int oldOff = off;
> -??????????? while (nextout >= 0) {?????? // leftover output byte(s) 
> in bits buf
> -??????????????? if (len == 0)
> -??????????????????? return off - oldOff;
> -??????????????? b[off++] = (byte)(bits >> nextout);
> -??????????????? len--;
> -??????????????? nextout -= 8;
> +??????????? }
> +??????????? Objects.checkFromIndexSize(off, len, b.length);
> +??????????? if (len == 0) {
> +??????????????? return 0;
> ???????????? }
> -??????????? bits = 0;
> -??????????? while (len > 0) {
> -??????????????? int v = is.read();
> -??????????????? if (v == -1) {
> -??????????????????? return eof(b, off, len, oldOff);
> +
> +??????????? /*
> +??????????? Rather than keeping 2 running vars (e.g., off and len), 
> we only
> +??????????? keep one (pos), while definitely fixing the boundaries of 
> the range
> +??????????? [off, limit).
> +
> +??????????? Note that limit can overflow to Integer.MIN_VALUE. 
> However, as long
> +??????????? as comparisons with pos are done as coded, there's no harm.
> +
> +??????????? In addition, limit - off (= len) is used from here on, so 
> the
> +??????????? location for len can be reallocated to other vars (e.g., 
> limit).
> +???????????? */
> +??????????? int pos = off;
> +??????????? int limit = off + len;
> +??????????? if (eos) {
> +??????????????? return leftovers(b, off, pos, limit);
> +??????????? }
> +
> +??????????? /*
> +??????????? leftovers from previous invocation; here, wpos = 0.
> +??????????? There can be at most 2 leftover bytes (rpos <= 16).
> +??????????? Further, the buffer b has at least one free place.
> +
> +??????????? The logic could be coded as a loop, (as in method 
> leftovers())
> +??????????? but the explicit "unrolling" makes it possible to 
> generate better
> +??????????? byte extraction code.
> +???????????? */
> +??????????? if (rpos == 16) {
> +??????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????? rpos = 8;
> +??????????????? if (pos == limit) {
> +??????????????????? return limit - off;
> ???????????????? }
> -??????????????? if ((v = base64[v]) < 0) {
> -??????????????????? if (v == -2) {?????? // padding byte(s)
> -??????????????????????? return padding(b, off, len, oldOff);
> -??????????????????? }
> -??????????????????? if (v == -1) {
> -??????????????????????? if (!isMIME)
> -??????????????????????????? throw new IOException("Illegal base64 
> character " +
> -??????????????????????????????? Integer.toString(v, 16));
> -??????????????????????? continue;??????? // skip if for rfc2045
> -??????????????????? }
> -??????????????????? // neve be here
> -??????????????? }
> -??????????????? bits |= (v << nextin);
> -??????????????? if (nextin == 0) {
> -??????????????????? nextin = 18;???????? // clear for next in
> -??????????????????? b[off++] = (byte)(bits >> 16);
> -??????????????????? if (len == 1) {
> -??????????????????????? nextout = 8;??? // 2 bytes left in bits
> -??????????????????????? break;
> -??????????????????? }
> -??????????????????? b[off++] = (byte)(bits >> 8);
> -??????????????????? if (len == 2) {
> -??????????????????????? nextout = 0;??? // 1 byte left in bits
> -??????????????????????? break;
> -??????????????????? }
> -??????????????????? b[off++] = (byte)bits;
> -??????????????????? len -= 3;
> -??????????????????? bits = 0;
> -??????????????? } else {
> -??????????????????? nextin -= 6;
> +??????????? }
> +??????????? if (rpos == 8) {
> +??????????????? b[pos++] = (byte) bits;
> +??????????????? rpos = 0;
> +??????????????? if (pos == limit) {
> +??????????????????? return limit - off;
> ???????????????? }
> ???????????? }
> -??????????? return off - oldOff;
> + 8222187
> +??????????? bits = 0;
> +??????????? wpos = 24;
> +??????????? for (;;) {
> +??????????????? // Here, pos != limit
> +??????????????? int i = is.read();
> +??????????????? if (i < 0) {
> +??????????????????? return eos(b, off, pos, limit);
> +??????????????? }
> +??????????????? int v = base64[i];
> +??????????????? if (v < 0) {
> +??????????????????? /*
> +??????????????????? i not in alphabet, thus
> +??????????????????????? v = -2: i is '=', the padding
> +??????????????????????? v = -1: i is something else, e.g., CR or LF
> +???????????????????? */
> +??????????????????? if (v == -1) {
> +??????????????????????? if (isMIME) {
> +??????????????????????????? continue;
> +??????????????????????? }
> +??????????????????????? throw new IOException("Illegal base64 byte 0x" +
> +??????????????????????????????? Integer.toHexString(i));
> +??????????????????? }
> +??????????????????? return padding(b, off, pos, limit);
> +??????????????? }
> +??????????????? bits |= (v << (wpos -= 6));
> +??????????????? if (wpos != 0) {
> +??????????????????? continue;
> +??????????????? }
> +??????????????? if (limit - pos >= 3) {
> +??????????????????? // frequently taken fast path, no need to track rpos
> +??????????????????? b[pos++] = (byte) (bits >> 16);
> +??????????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????????? b[pos++] = (byte) bits;
> +??????????????????? bits = 0;
> +??????????????????? wpos = 24;
> +??????????????????? if (pos == limit) {
> +??????????????????????? return limit - off;
> +??????????????????? }
> +??????????????????? continue;
> +??????????????? }
> +??????????????? /*
> +??????????????? Here, buffer b has either 1 or 2 free places, that is,
> +??????????????? limit - pos = 1 or limit - pos = 2.
> +
> +??????????????? As above, this could be coded as a loop. But since the
> +??????????????? shift lengths are explicit multiples of 8, better 
> code can be
> +??????????????? probably generated.
> +???????????????? */
> +??????????????? b[pos++] = (byte) (bits >> 16);
> +??????????????? if (pos == limit) {
> +??????????????????? rpos = 16;
> +??????????????????? return limit - off;
> +??????????????? }
> +??????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????? // Here, pos = limit, no need for an if.
> +??????????????? rpos = 8;
> +??????????????? return limit - off;
> +??????????? }
> ???????? }
>
> ???????? @Override
> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
> b/test/jdk/java/util/Base64/TestBase64.java
> --- a/test/jdk/java/util/Base64/TestBase64.java
> +++ b/test/jdk/java/util/Base64/TestBase64.java
> @@ -144,6 +144,10 @@
> ???????? testDecoderKeepsAbstinence(Base64.getDecoder());
> ???????? testDecoderKeepsAbstinence(Base64.getUrlDecoder());
> ???????? testDecoderKeepsAbstinence(Base64.getMimeDecoder());
> +
> +??????? // tests patch addressing JDK-8222187
> +??????? // https://bugs.openjdk.java.net/browse/JDK-8222187
> +??????? testJDK_8222187();
> ???? }
>
> ???? private static void test(Base64.Encoder enc, Base64.Decoder dec,
> @@ -607,4 +611,26 @@
> ???????????? }
> ???????? }
> ???? }
> +
> +??? private static void testJDK_8222187() throws Throwable {
> +??????? byte[] orig = "12345678".getBytes("US-ASCII");
> +??????? byte[] encoded = Base64.getEncoder().encode(orig);
> +??????? // decode using different buffer sizes
> +??????? for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
> bufferSize++) {
> +??????????? try (
> +??????????????????? InputStream in = Base64.getDecoder().wrap(
> +??????????????????????????? new ByteArrayInputStream(encoded));
> +??????????????????? ByteArrayOutputStream baos = new 
> ByteArrayOutputStream();
> +??????????? ) {
> +??????????????? byte[] buffer = new byte[bufferSize];
> +??????????????? int read;
> +??????????????? while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
> +??????????????????? baos.write(buffer, 0, read);
> +??????????????? }
> +??????????????? // compare result, output info if lengths do not match
> +??????????????? byte[] decoded = baos.toByteArray();
> +??????????????? checkEqual(decoded, orig, "Base64 stream decoding 
> failed!");
> +??????????? }
> +??????? }
> +??? }
> ?}


From sean.mullan at oracle.com  Mon Jul  6 20:11:47 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 6 Jul 2020 16:11:47 -0400
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
Message-ID: <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>

Hi Alexey,

This may have been discussed already, but can you explain why the 
"com.sun.jndi.ldap.connect.timeout" property needs to be set in order to 
use this feature? That property is mostly used in tests to avoid long 
socket timeouts, etc.

Why does that need to be set? What problem are you trying to solve?

--Sean


On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
> 
>> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it.
>>
>> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice.
> 
> OK.
> GSSContextImpl class is removed from patch.
> 
> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
> 
> Thank you
> Alexey
> 

From raffaello.giulietti at gmail.com  Mon Jul  6 20:48:28 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 6 Jul 2020 22:48:28 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
Message-ID: <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>

Hi Roger,

the structure of the original design is preserved, the details change 
with the intent of having code that is easier to reason about.

The main loop has many exit points in the original code, as well as in 
the new code. For this reason, I prefer not to express it as a while or 
as a counted for loop. That's why it has the for (;;) form, which 
promptly warns that more exit points at unusual positions should be 
expected.

The "Illegal base64 character" IOException in the original code is 
wrong, probably due to oversight. That's why the new code has two vars, 
namely i and v, to convey more meaningful diagnostic.

The new code keeps track of only one running variable pos instead of the 
original two vars off and len, wit?out using more live variables for 
this purpose. Less mutating vars help keeping the code simpler. The 
method has only one mutating var.

With the use of writing and reading bit positions fields wpos and rpos, 
checking when a byte in field bits is ready means testing rpos - 8 >= wpos.

I can add more comments, e.g., in the form of Dijkstra/Hoare-style loop 
invariants, if this helps improving confidence. Or I can add 
constant-guarded assertions to the proposed code instead of just 
comments. Or both.



There's nothing I can find in the coding convention [1] about block 
comments that states that continuation lines must start with the 
asterisk *, although the examples do so. While I find these asterisks 
quite distracting, it would be a trivial matter to add them in the next 
review iteration.

The end-of-line comments either comply with the rules in [1] or, in the 
description of the fields, have been inadvertently "inherited" as 
multiple lines from the original code. I will of course correct them 
there in the next review iteration.


Greetings
Raffaello

----

[1] 
https://www.oracle.com/java/technologies/javase/codeconventions-comments.html


On 2020-07-06 20:17, Roger Riggs wrote:
> Hi Raffaello,
> 
> I'm still not sure it needed this much of a re-write to fix the bug;
> It will take some time to look at the changes.
> 
> Regardless, OpenJDK conventions call for following the style of the 
> existing code.
> Your new comments follow neither the existing convention to use "//..." 
> comments
> nor the other prevalent comment form using /*... */ which use consistent 
> indentation
> and "* " on continuation lines.
> 
> Regards, Roger
> 
> 
> On 7/3/20 11:48 AM, Raffaello Giulietti wrote:
>> Hello,
>>
>> after Roger's notes, which escaped my attention before, I've withdrawn 
>> all the changes but for DecInputStream, *except* that I couldn't 
>> resist to simplify the maths in encodedOutLength(), while still using 
>> xxxExact() arithmetic.
>>
>> Sorry for the confusion
>> Raffaello
>>
>>
>>
>>> Hi Raffaello,
>>>
>>> There is way more code changed here than is needed to fix the bug.
>>> General enhancement should be separated from bug fixes.
>>> It makes it easier to review to see the bug was fixed
>>> and easier to separately review other code to see that there are no 
>>> unexpected changes.
>>>
>>> If some of the changes are motivated by expected performance 
>>> improvements,
>>> there should be JMH tests comparing the before and after.
>>> The change to use byte arrays seems useful, but even using char[]
>>> there is little danger of cache thrashing.
>>>
>>> If using the code using xxxExact was correct, don't change it.
>>> Those methods are intrinsified and perform as well or better than 
>>> using long.
>>> Usually, it is better to leave code alone and not risk breaking it.
>>>
>>> Special care needs taken when changing a method that is intrinsified.
>>> The optimized version may use fields of the object and stop
>>> working if they are changed.
>>>
>>> In the test, the range of buffer sizes tests seems to waste a lot
>>> of cycles on sizes greater than the encoded size of the input.
>>>
>>> Regards, Roger
>>
>>
>> ---------------------
>>
>> # HG changeset patch
>> # User lello
>> # Date 1593790152 -7200
>> #????? Fri Jul 03 17:29:12 2020 +0200
>> # Node ID 73370832de1d2bf3b450930f5cb2467e10528c69
>> # Parent? a7c0307232406c7b0c1a4b8c2de111077848203d
>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
>> the end
>> Reviewed-by: TBD
>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>>
>> diff --git a/src/java.base/share/classes/java/util/Base64.java 
>> b/src/java.base/share/classes/java/util/Base64.java
>> --- a/src/java.base/share/classes/java/util/Base64.java
>> +++ b/src/java.base/share/classes/java/util/Base64.java
>> @@ -255,14 +255,11 @@
>> ????????? *
>> ????????? */
>> ???????? private final int encodedOutLength(int srclen, boolean 
>> throwOOME) {
>> -??????????? int len = 0;
>> +??????????? int len;
>> ???????????? try {
>> -??????????????? if (doPadding) {
>> -??????????????????? len = Math.multiplyExact(4, 
>> (Math.addExact(srclen, 2) / 3));
>> -??????????????? } else {
>> -??????????????????? int n = srclen % 3;
>> -??????????????????? len = Math.addExact(Math.multiplyExact(4, (srclen 
>> / 3)), (n == 0 ? 0 : n + 1));
>> -??????????????? }
>> +??????????????? len = doPadding
>> +??????????????????????? ? Math.multiplyExact(4, 
>> (Math.addExact(srclen, 2) / 3))
>> +??????????????????????? : Math.addExact((Math.addExact(srclen, 2) / 
>> 3), srclen);
>> ???????????????? if (linemax > 0) { // line separators
>> ???????????????????? len = Math.addExact(len, (len - 1) / linemax * 
>> newline.length);
>> ???????????????? }
>> @@ -961,14 +958,15 @@
>>
>> ???????? private final InputStream is;
>> ???????? private final boolean isMIME;
>> -??????? private final int[] base64;????? // base64 -> byte mapping
>> -??????? private int bits = 0;??????????? // 24-bit buffer for decoding
>> -??????? private int nextin = 18;???????? // next available "off" in 
>> "bits" for input;
>> -???????????????????????????????????????? // -> 18, 12, 6, 0
>> -??????? private int nextout = -8;??????? // next available "off" in 
>> "bits" for output;
>> -???????????????????????????????????????? // -> 8, 0, -8 (no byte for 
>> output)
>> -??????? private boolean eof = false;
>> -??????? private boolean closed = false;
>> +??????? private final int[] base64;???? // mapping from alphabet to 
>> values
>> +??????? private int bits;?????????????? // 24 bit buffer for decoding
>> +??????? private int wpos;?????????????? // writing bit pos inside bits
>> +??????? // one of 24 (left, msb), 18, 12, 6, 0
>> +??????? private int rpos;?????????????? // reading bit pos inside bits
>> +??????? // one of 24 (left, msb), 16, 8, 0
>> +??????? private boolean eos;
>> +??????? private boolean closed;
>> +??????? private byte[] onebuf = new byte[1];
>>
>> ???????? DecInputStream(InputStream is, int[] base64, boolean isMIME) {
>> ???????????? this.is = is;
>> @@ -976,114 +974,158 @@
>> ???????????? this.isMIME = isMIME;
>> ???????? }
>>
>> -??????? private byte[] sbBuf = new byte[1];
>> -
>> ???????? @Override
>> ???????? public int read() throws IOException {
>> -??????????? return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>> +??????????? return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
>> +??????? }
>> +
>> +??????? private int leftovers(byte[] b, int off, int pos, int limit) {
>> +??????????? eos = true;
>> +??????????? /*
>> +??????????? We use a loop here, as this code is executed only once.
>> +??????????? Unrolling the loop would probably not contribute much here.
>> +???????????? */
>> +??????????? while (rpos - 8 >= wpos && pos != limit) {
>> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
>> +??????????? }
>> +??????????? return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
>> ???????? }
>>
>> -??????? private int eof(byte[] b, int off, int len, int oldOff)
>> -??????????? throws IOException
>> -??????? {
>> -??????????? eof = true;
>> -??????????? if (nextin != 18) {
>> -??????????????? if (nextin == 12)
>> -??????????????????? throw new IOException("Base64 stream has one 
>> un-decoded dangling byte.");
>> -??????????????? // treat ending xx/xxx without padding character legal.
>> -??????????????? // same logic as v == '=' below
>> -??????????????? b[off++] = (byte)(bits >> (16));
>> -??????????????? if (nextin == 0) {?????????? // only one padding byte
>> -??????????????????? if (len == 1) {????????? // no enough output space
>> -??????????????????????? bits >>= 8;????????? // shift to lowest byte
>> -??????????????????????? nextout = 0;
>> -??????????????????? } else {
>> -??????????????????????? b[off++] = (byte) (bits >>? 8);
>> -??????????????????? }
>> -??????????????? }
>> +??????? private int eos(byte[] b, int off, int pos, int limit) throws 
>> IOException {
>> +??????????? /*
>> +??????????? wpos == 18: x???? dangling single x, invalid unit
>> +??????????? accept ending xx or xxx without padding characters
>> +???????????? */
>> +??????????? if (wpos == 18) {
>> +??????????????? throw new IOException("Base64 stream has one 
>> un-decoded dangling byte");
>> ???????????? }
>> -??????????? return off == oldOff ? -1 : off - oldOff;
>> +??????????? rpos = 24;
>> +??????????? return leftovers(b, off, pos, limit);
>> ???????? }
>>
>> -??????? private int padding(byte[] b, int off, int len, int oldOff)
>> -??????????? throws IOException
>> -??????? {
>> -??????????? // =???? shiftto==18 unnecessary padding
>> -??????????? // x=??? shiftto==12 dangling x, invalid unit
>> -??????????? // xx=?? shiftto==6 && missing last '='
>> -??????????? // xx=y? or last is not '='
>> -??????????? if (nextin == 18 || nextin == 12 ||
>> -??????????????? nextin == 6 && is.read() != '=') {
>> -??????????????? throw new IOException("Illegal base64 ending 
>> sequence:" + nextin);
>> +??????? private int padding(byte[] b, int off, int pos, int limit) 
>> throws IOException {
>> +??????????? /*
>> +??????????? wpos == 24: =??? (unnecessary padding)
>> +??????????? wpos == 18: x=?? (dangling single x, invalid unit)
>> +??????????? wpos == 12 and missing last '=': xx=? (invalid padding)
>> +??????????? wpos == 12 and last is not '=': xx=x (invalid padding)
>> +???????????? */
>> +??????????? if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>> +??????????????? throw new IOException("Illegal base64 ending sequence");
>> ???????????? }
>> -??????????? b[off++] = (byte)(bits >> (16));
>> -??????????? if (nextin == 0) {?????????? // only one padding byte
>> -??????????????? if (len == 1) {????????? // no enough output space
>> -??????????????????? bits >>= 8;????????? // shift to lowest byte
>> -??????????????????? nextout = 0;
>> -??????????????? } else {
>> -??????????????????? b[off++] = (byte) (bits >>? 8);
>> -??????????????? }
>> -??????????? }
>> -??????????? eof = true;
>> -??????????? return off - oldOff;
>> +??????????? rpos = 24;
>> +??????????? return leftovers(b, off, pos, limit);
>> ???????? }
>>
>> ???????? @Override
>> ???????? public int read(byte[] b, int off, int len) throws IOException {
>> -??????????? if (closed)
>> +??????????? if (closed) {
>> ???????????????? throw new IOException("Stream is closed");
>> -??????????? if (eof && nextout < 0)??? // eof and no leftover
>> -??????????????? return -1;
>> -??????????? if (off < 0 || len < 0 || len > b.length - off)
>> -??????????????? throw new IndexOutOfBoundsException();
>> -??????????? int oldOff = off;
>> -??????????? while (nextout >= 0) {?????? // leftover output byte(s) 
>> in bits buf
>> -??????????????? if (len == 0)
>> -??????????????????? return off - oldOff;
>> -??????????????? b[off++] = (byte)(bits >> nextout);
>> -??????????????? len--;
>> -??????????????? nextout -= 8;
>> +??????????? }
>> +??????????? Objects.checkFromIndexSize(off, len, b.length);
>> +??????????? if (len == 0) {
>> +??????????????? return 0;
>> ???????????? }
>> -??????????? bits = 0;
>> -??????????? while (len > 0) {
>> -??????????????? int v = is.read();
>> -??????????????? if (v == -1) {
>> -??????????????????? return eof(b, off, len, oldOff);
>> +
>> +??????????? /*
>> +??????????? Rather than keeping 2 running vars (e.g., off and len), 
>> we only
>> +??????????? keep one (pos), while definitely fixing the boundaries of 
>> the range
>> +??????????? [off, limit).
>> +
>> +??????????? Note that limit can overflow to Integer.MIN_VALUE. 
>> However, as long
>> +??????????? as comparisons with pos are done as coded, there's no harm.
>> +
>> +??????????? In addition, limit - off (= len) is used from here on, so 
>> the
>> +??????????? location for len can be reallocated to other vars (e.g., 
>> limit).
>> +???????????? */
>> +??????????? int pos = off;
>> +??????????? int limit = off + len;
>> +??????????? if (eos) {
>> +??????????????? return leftovers(b, off, pos, limit);
>> +??????????? }
>> +
>> +??????????? /*
>> +??????????? leftovers from previous invocation; here, wpos = 0.
>> +??????????? There can be at most 2 leftover bytes (rpos <= 16).
>> +??????????? Further, the buffer b has at least one free place.
>> +
>> +??????????? The logic could be coded as a loop, (as in method 
>> leftovers())
>> +??????????? but the explicit "unrolling" makes it possible to 
>> generate better
>> +??????????? byte extraction code.
>> +???????????? */
>> +??????????? if (rpos == 16) {
>> +??????????????? b[pos++] = (byte) (bits >> 8);
>> +??????????????? rpos = 8;
>> +??????????????? if (pos == limit) {
>> +??????????????????? return limit - off;
>> ???????????????? }
>> -??????????????? if ((v = base64[v]) < 0) {
>> -??????????????????? if (v == -2) {?????? // padding byte(s)
>> -??????????????????????? return padding(b, off, len, oldOff);
>> -??????????????????? }
>> -??????????????????? if (v == -1) {
>> -??????????????????????? if (!isMIME)
>> -??????????????????????????? throw new IOException("Illegal base64 
>> character " +
>> -??????????????????????????????? Integer.toString(v, 16));
>> -??????????????????????? continue;??????? // skip if for rfc2045
>> -??????????????????? }
>> -??????????????????? // neve be here
>> -??????????????? }
>> -??????????????? bits |= (v << nextin);
>> -??????????????? if (nextin == 0) {
>> -??????????????????? nextin = 18;???????? // clear for next in
>> -??????????????????? b[off++] = (byte)(bits >> 16);
>> -??????????????????? if (len == 1) {
>> -??????????????????????? nextout = 8;??? // 2 bytes left in bits
>> -??????????????????????? break;
>> -??????????????????? }
>> -??????????????????? b[off++] = (byte)(bits >> 8);
>> -??????????????????? if (len == 2) {
>> -??????????????????????? nextout = 0;??? // 1 byte left in bits
>> -??????????????????????? break;
>> -??????????????????? }
>> -??????????????????? b[off++] = (byte)bits;
>> -??????????????????? len -= 3;
>> -??????????????????? bits = 0;
>> -??????????????? } else {
>> -??????????????????? nextin -= 6;
>> +??????????? }
>> +??????????? if (rpos == 8) {
>> +??????????????? b[pos++] = (byte) bits;
>> +??????????????? rpos = 0;
>> +??????????????? if (pos == limit) {
>> +??????????????????? return limit - off;
>> ???????????????? }
>> ???????????? }
>> -??????????? return off - oldOff;
>> + 8222187
>> +??????????? bits = 0;
>> +??????????? wpos = 24;
>> +??????????? for (;;) {
>> +??????????????? // Here, pos != limit
>> +??????????????? int i = is.read();
>> +??????????????? if (i < 0) {
>> +??????????????????? return eos(b, off, pos, limit);
>> +??????????????? }
>> +??????????????? int v = base64[i];
>> +??????????????? if (v < 0) {
>> +??????????????????? /*
>> +??????????????????? i not in alphabet, thus
>> +??????????????????????? v = -2: i is '=', the padding
>> +??????????????????????? v = -1: i is something else, e.g., CR or LF
>> +???????????????????? */
>> +??????????????????? if (v == -1) {
>> +??????????????????????? if (isMIME) {
>> +??????????????????????????? continue;
>> +??????????????????????? }
>> +??????????????????????? throw new IOException("Illegal base64 byte 0x" +
>> +??????????????????????????????? Integer.toHexString(i));
>> +??????????????????? }
>> +??????????????????? return padding(b, off, pos, limit);
>> +??????????????? }
>> +??????????????? bits |= (v << (wpos -= 6));
>> +??????????????? if (wpos != 0) {
>> +??????????????????? continue;
>> +??????????????? }
>> +??????????????? if (limit - pos >= 3) {
>> +??????????????????? // frequently taken fast path, no need to track rpos
>> +??????????????????? b[pos++] = (byte) (bits >> 16);
>> +??????????????????? b[pos++] = (byte) (bits >> 8);
>> +??????????????????? b[pos++] = (byte) bits;
>> +??????????????????? bits = 0;
>> +??????????????????? wpos = 24;
>> +??????????????????? if (pos == limit) {
>> +??????????????????????? return limit - off;
>> +??????????????????? }
>> +??????????????????? continue;
>> +??????????????? }
>> +??????????????? /*
>> +??????????????? Here, buffer b has either 1 or 2 free places, that is,
>> +??????????????? limit - pos = 1 or limit - pos = 2.
>> +
>> +??????????????? As above, this could be coded as a loop. But since the
>> +??????????????? shift lengths are explicit multiples of 8, better 
>> code can be
>> +??????????????? probably generated.
>> +???????????????? */
>> +??????????????? b[pos++] = (byte) (bits >> 16);
>> +??????????????? if (pos == limit) {
>> +??????????????????? rpos = 16;
>> +??????????????????? return limit - off;
>> +??????????????? }
>> +??????????????? b[pos++] = (byte) (bits >> 8);
>> +??????????????? // Here, pos = limit, no need for an if.
>> +??????????????? rpos = 8;
>> +??????????????? return limit - off;
>> +??????????? }
>> ???????? }
>>
>> ???????? @Override
>> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
>> b/test/jdk/java/util/Base64/TestBase64.java
>> --- a/test/jdk/java/util/Base64/TestBase64.java
>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>> @@ -144,6 +144,10 @@
>> ???????? testDecoderKeepsAbstinence(Base64.getDecoder());
>> ???????? testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>> ???????? testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>> +
>> +??????? // tests patch addressing JDK-8222187
>> +??????? // https://bugs.openjdk.java.net/browse/JDK-8222187
>> +??????? testJDK_8222187();
>> ???? }
>>
>> ???? private static void test(Base64.Encoder enc, Base64.Decoder dec,
>> @@ -607,4 +611,26 @@
>> ???????????? }
>> ???????? }
>> ???? }
>> +
>> +??? private static void testJDK_8222187() throws Throwable {
>> +??????? byte[] orig = "12345678".getBytes("US-ASCII");
>> +??????? byte[] encoded = Base64.getEncoder().encode(orig);
>> +??????? // decode using different buffer sizes
>> +??????? for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
>> bufferSize++) {
>> +??????????? try (
>> +??????????????????? InputStream in = Base64.getDecoder().wrap(
>> +??????????????????????????? new ByteArrayInputStream(encoded));
>> +??????????????????? ByteArrayOutputStream baos = new 
>> ByteArrayOutputStream();
>> +??????????? ) {
>> +??????????????? byte[] buffer = new byte[bufferSize];
>> +??????????????? int read;
>> +??????????????? while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>> +??????????????????? baos.write(buffer, 0, read);
>> +??????????????? }
>> +??????????????? // compare result, output info if lengths do not match
>> +??????????????? byte[] decoded = baos.toByteArray();
>> +??????????????? checkEqual(decoded, orig, "Base64 stream decoding 
>> failed!");
>> +??????????? }
>> +??????? }
>> +??? }
>> ?}
> 

From Nikola.Grcevski at microsoft.com  Mon Jul  6 21:59:56 2020
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Mon, 6 Jul 2020 21:59:56 +0000
Subject: RFR: JDK-8232092: (fs) Files::isWritable returns false on a writeable
 root directory (win)
Message-ID: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>

Hello core-libs-dev,

I was asked to help look into JDK-8232092 by Christian Stein (the bug reporter), and since I don't have an OpenJDK account yet I'm sharing my findings on the issue here. I looked into two separate issues that might cause FileSystemProvider.checkAccess to return an incorrect result as reported. 

The first issue seems related to substituted directories with volumes, or virtual drives on Windows. The problem happens if the Windows GetVolumePathNameW API is called with a virtual drive letter in the path, causing the API to return ERROR_INVALID_PARAMETER or error code 87. The code in WindowsFileStore::create makes a call to WindowsLinkSupport::getFinalPath, however the getFinalPath method will avoid expanding the virtual drive path, by calling GetFinalPathNameByHandle, because the path isn't a symbolic link. The existing code in WindowsFileStore::create currently checks for the ErrorLevel of ERROR_DIR_NOT_ROOT, and it properly calls the path expansion API, however it doesn't check for ERROR_INVALID_PARAMETER which might happen if a path with virtual drive letter is used.

We can follow the steps below to reproduce the issue:
- Have a writeable directory on Windows, e.g. C:\Temp
- Run "subst T: C:\Temp" on the command line to create the virtual drive T for C:\Temp
- Check with "cacls T:" and "cacls C:\Temp" that you have the exact same access control permissions
- Run "FileSystems.getDefault().provider().checkAccess(Path.of("T:\\"), java.nio.file.AccessMode.WRITE)" in jshell and you'll see an Exception java.nio.file.FileSystemException: T:\: The parameter is incorrect. Running the same command on C:\\Temp will return without an exception.

I've attached at the bottom of this email a simple patch that address the virtual drive issue. There might be a better way to fix this issue so any feedback is appreciated.

The second issue reported is using a virtual drive with the ImDisk utility to create a Virtual RAM Disk on Windows (Z: drive in the bug report). As mentioned in the bug report the failure is slightly different, in this case GetFinalPathNameByHandleW is called and the API returns ERROR_INVALID_FUNCTION. This error is caused by the third-party utility design/implementation. With ImDisk virtual disks, applications that rely on Windows Volume Mount Manager APIs, like GetFinalPathNameByHandleW, will fail because ImDisk does not interact with Windows Volume Mount Manager at all, it effectively bypasses it. Essentially, GetFinalPathNameByHandle and few other APIs will never work properly with ImDisk virtual drives.

Cheers,
Nikola Grcevski
Microsoft

diff --git a/src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java b/src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java
index acbb2c15f2a..9b4b4117b24 100644
--- a/src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java
+++ b/src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java
@@ -79,10 +79,12 @@ class WindowsFileStore
             // volume that the link is on so we need to call it with the
             // final target
             String target = WindowsLinkSupport.getFinalPath(file, true);
+                        
             try {
                 return createFromPath(target);
             } catch (WindowsException e) {
-                if (e.lastError() != ERROR_DIR_NOT_ROOT)
+                if (e.lastError() != ERROR_DIR_NOT_ROOT && 
+                    e.lastError() != ERROR_INVALID_PARAMETER)
                     throw e;
                 target = WindowsLinkSupport.getFinalPath(file);
                 if (target == null)

From aleksej.efimov at oracle.com  Mon Jul  6 22:06:52 2020
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 6 Jul 2020 23:06:52 +0100
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <F7EEE69D-E446-4FF1-A49A-F7A962164582@oracle.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
Message-ID: <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>

Hi Sean,

Alexey answered the same question for me:

> I mean ?com.sun.jndi.ldap.connect.timeout? property.
> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds:
> Connection.java
>>> if (connectTimeout > 0) {
>>>      int socketTimeout = sslSocket.getSoTimeout();
>>>      sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value
>>>      sslSocket.startHandshake();
>>>      sslSocket.setSoTimeout(socketTimeout);
>>> }
> Without this property handshake is started later asynchronously.
> As result
>>>     certs = ssock.getSession().getPeerCertificates();
> in the LdapClient.java could return SSLPeerUnverifiedException().
> This exception will be wrapped to NamingException and thrown to application.
>
> This is not usually happens but I saw it on the slow connection

The full context of LDAP Connection code that initiates the SSL 
handshake could be viewed here:
https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345

-- Aleksei

On 06/07/2020 21:11, Sean Mullan wrote:
> Hi Alexey,
>
> This may have been discussed already, but can you explain why the 
> "com.sun.jndi.ldap.connect.timeout" property needs to be set in order 
> to use this feature? That property is mostly used in tests to avoid 
> long socket timeouts, etc.
>
> Why does that need to be set? What problem are you trying to solve?
>
> --Sean
>
>
> On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
>>
>>> I would suggest removing it. At least for the SASL GSS-API mech, it 
>>> seems the GSSContext object will not be leaked and no one has a 
>>> chance to call setChannelBinding again on it.
>>>
>>> There is no spec saying setChannelBinding() can only be called once, 
>>> so I'd rather we don't enforce that, although you might say there is 
>>> no need to call it twice.
>>
>> OK.
>> GSSContextImpl class is removed from patch.
>>
>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
>>
>> Thank you
>> Alexey
>>


From sean.mullan at oracle.com  Mon Jul  6 23:30:28 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 6 Jul 2020 19:30:28 -0400
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
Message-ID: <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>

Thanks for that extra info.

I think it would be much cleaner to avoid having to set that property 
and instead start the handshake synchronously if the 
"com.sun.jndi.ldap.tls.cbtype" property is set. This way only one 
property needs to be set and you don't need to guess what an acceptable 
value is for the timeout property, which could also cause the connection 
to be interrupted before the TLS handshake is complete if you use too 
small of a value.

Or better yet, there may be another way to do this with JSSE where you 
wait for the TLS connection to complete. I'll ask my team and get back 
to you.

--Sean


On 7/6/20 6:06 PM, Aleks Efimov wrote:
> Hi Sean,
> 
> Alexey answered the same question for me:
> 
>> I mean ?com.sun.jndi.ldap.connect.timeout? property.
>> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds:
>> Connection.java
>>>> if (connectTimeout > 0) {
>>>>      int socketTimeout = sslSocket.getSoTimeout();
>>>>      sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value
>>>>      sslSocket.startHandshake();
>>>>      sslSocket.setSoTimeout(socketTimeout);
>>>> }
>> Without this property handshake is started later asynchronously.
>> As result
>>>>     certs = ssock.getSession().getPeerCertificates();
>> in the LdapClient.java could return SSLPeerUnverifiedException().
>> This exception will be wrapped to NamingException and thrown to application.
>>
>> This is not usually happens but I saw it on the slow connection
> 
> The full context of LDAP Connection code that initiates the SSL 
> handshake could be viewed here:
> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345
> 
> -- Aleksei
> 
> On 06/07/2020 21:11, Sean Mullan wrote:
>> Hi Alexey,
>>
>> This may have been discussed already, but can you explain why the 
>> "com.sun.jndi.ldap.connect.timeout" property needs to be set in order 
>> to use this feature? That property is mostly used in tests to avoid 
>> long socket timeouts, etc.
>>
>> Why does that need to be set? What problem are you trying to solve?
>>
>> --Sean
>>
>>
>> On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
>>>
>>>> I would suggest removing it. At least for the SASL GSS-API mech, it 
>>>> seems the GSSContext object will not be leaked and no one has a 
>>>> chance to call setChannelBinding again on it.
>>>>
>>>> There is no spec saying setChannelBinding() can only be called once, 
>>>> so I'd rather we don't enforce that, although you might say there is 
>>>> no need to call it twice.
>>>
>>> OK.
>>> GSSContextImpl class is removed from patch.
>>>
>>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
>>>
>>> Thank you
>>> Alexey
>>>
> 

From alexander.matveev at oracle.com  Mon Jul  6 23:35:15 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Mon, 6 Jul 2020 16:35:15 -0700
Subject: RFR: 8223955: Eliminate or reduce mixing of old File API and new
 Path/Files APIs
Message-ID: <077890ea-6a64-8313-5b86-9e1e02fcb5b2@oracle.com>

Please review the jpackage fix for bug [1] at [2].

Substituted old File APIs with Path/Files APIs when it was possible and 
makes sense.

[1] https://bugs.openjdk.java.net/browse/JDK-8223955
[2] http://cr.openjdk.java.net/~almatvee/8223955/webrev.00/

Thanks,
Alexander

From huizhe.wang at oracle.com  Mon Jul  6 23:37:56 2020
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Mon, 6 Jul 2020 16:37:56 -0700
Subject: RFR [15/java.xml] 8248884: Regression caused by the update to BCEL 6.0
Message-ID: <7e1d5f39-e63a-bbf7-2188-7866e28dd8f5@oracle.com>

Please refer to the previous review for 8248348. This patch should have 
been pushed into 15 in the first place. I hope a merge with 16 repo 
won't cause any trouble/conflict.


JBS: https://bugs.openjdk.java.net/browse/JDK-8248884

webrev: http://cr.openjdk.java.net/~joehw/jdk15/8248884/webrev/


Thanks,

Joe



From brian.burkhalter at oracle.com  Mon Jul  6 23:54:31 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 6 Jul 2020 16:54:31 -0700
Subject: RFR: JDK-8232092: (fs) Files::isWritable returns false on a
 writeable root directory (win)
In-Reply-To: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
References: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
Message-ID: <3472705B-C732-4474-B44D-731165634110@oracle.com>

Hello Nikola,

I added to the issue [1] a link [2] to the archive of your message.

I should note that the discussion should ideally be conducted on nio-dev [3] as the topic pertains to that subcomponent.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8232092
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067594.html
[3] https://mail.openjdk.java.net/mailman/listinfo/nio-dev

> On Jul 6, 2020, at 2:59 PM, Nikola Grcevski <Nikola.Grcevski at microsoft.com> wrote:
> 
> I was asked to help look into JDK-8232092 by Christian Stein (the bug reporter), and since I don't have an OpenJDK account yet I'm sharing my findings on the issue here. I looked into two separate issues that might cause FileSystemProvider.checkAccess to return an incorrect result as reported. 


From stuart.marks at oracle.com  Mon Jul  6 23:55:39 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 6 Jul 2020 16:55:39 -0700
Subject: RFR [15/java.xml] 8248884: Regression caused by the update to
 BCEL 6.0
In-Reply-To: <7e1d5f39-e63a-bbf7-2188-7866e28dd8f5@oracle.com>
References: <7e1d5f39-e63a-bbf7-2188-7866e28dd8f5@oracle.com>
Message-ID: <f03e5541-af12-da85-9f3a-9d2dc9d4b465@oracle.com>



On 7/6/20 4:37 PM, huizhe.wang at oracle.com wrote:
> Please refer to the previous review for 8248348. This patch should have been 
> pushed into 15 in the first place. I hope a merge with 16 repo won't cause any 
> trouble/conflict.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8248884
> 
> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8248884/webrev/

OK, looks good. Remember to push the backport changeset using the main bug ID, 
which in this case is JDK-8248348.

Also, we usually rely on the hgupdater to create the backport record 
automatically. You've already created backport record JDK-8248884, so just leave 
it there in case the hgupdater reuses it. However, if for some reason hgupdater 
decides to create a *new* backport, then close this one out as Not An Issue or 
something.

Thanks,

s'marks

From huizhe.wang at oracle.com  Tue Jul  7 00:20:21 2020
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Mon, 6 Jul 2020 17:20:21 -0700
Subject: RFR [15/java.xml] 8248884: Regression caused by the update to
 BCEL 6.0
In-Reply-To: <f03e5541-af12-da85-9f3a-9d2dc9d4b465@oracle.com>
References: <7e1d5f39-e63a-bbf7-2188-7866e28dd8f5@oracle.com>
 <f03e5541-af12-da85-9f3a-9d2dc9d4b465@oracle.com>
Message-ID: <ae197598-952e-02d2-d8af-c4a253d0e479@oracle.com>


On 7/6/20 4:55 PM, Stuart Marks wrote:
>
>
> On 7/6/20 4:37 PM, huizhe.wang at oracle.com wrote:
>> Please refer to the previous review for 8248348. This patch should 
>> have been pushed into 15 in the first place. I hope a merge with 16 
>> repo won't cause any trouble/conflict.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8248884
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk15/8248884/webrev/
>
> OK, looks good. Remember to push the backport changeset using the main 
> bug ID, which in this case is JDK-8248348.
>
> Also, we usually rely on the hgupdater to create the backport record 
> automatically. You've already created backport record JDK-8248884, so 
> just leave it there in case the hgupdater reuses it. However, if for 
> some reason hgupdater decides to create a *new* backport, then close 
> this one out as Not An Issue or something.


Thanks! Glad you reminded me to use the main bug ID, or it might have 
caused more trouble :-)? Looks like hgupdater was smart enough to detect 
the existing 15 backport id, phew.


Best,

Joe


>
> Thanks,
>
> s'marks

From alexander.matveev at oracle.com  Tue Jul  7 00:27:21 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Mon, 6 Jul 2020 17:27:21 -0700 (PDT)
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests verbose
 output
Message-ID: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>

Please review the jpackage fix for bug [1] at [2].

Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].

[1] https://bugs.openjdk.java.net/browse/JDK-8248261
[2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/

Thanks,
Alexander

From kim.barrett at oracle.com  Tue Jul  7 01:10:54 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 6 Jul 2020 21:10:54 -0400
Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language
 Features in HotSpot
In-Reply-To: <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
References: <B98C962A-7864-446B-98ED-69068C7F00D1@oracle.com>
 <5EDE9A75.6020504@oracle.com>
 <A8A5757E-15BC-4104-83DB-6084DFF5CC81@oracle.com>
 <EFE531CD-86C7-4155-BBC9-F4B45179B9A8@oracle.com> <5EE5AB71.20505@oracle.com>
 <DA8424D0-F428-405E-891A-EAB43650F96D@oracle.com>
 <B49ADE47-FA0E-4E48-A9AB-2E9F79ED9DA7@oracle.com>
 <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
Message-ID: <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>

I just noticed that doc/building.{md,html} describes minimum toolchain versions,
so also needs to be updated.  Here?s the update, matching what?s now in the JEP:

full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/

I also deleted a discussion of a problem one might run into when building with
Visual Studio 2010, since that version is no longer relevant.


From andy.herrick at oracle.com  Tue Jul  7 13:18:34 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 7 Jul 2020 09:18:34 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
Message-ID: <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>

All looks good, except maybe Log.error().

I think Log.error() should have the same output whether verbose or not, 
adding timestamp to the message only if verbose does not look right.

Problem is that Log.error() is used for two fundamentally different 
purposes:

1.) by Main and Arguments to display the final error message when 
jpackage is failing.

2.) by everyone else to display a serious warning message when jpackage 
is continuing (sometimes failing further on, and sometimes not).

I wouldn't mind adding timestamps only when verbose in case (2), but I 
don't think that's appropriate for case (1).

/ANdy

On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>
> Thanks,
> Alexander

From erik.joelsson at oracle.com  Tue Jul  7 13:59:01 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 7 Jul 2020 06:59:01 -0700
Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language
 Features in HotSpot
In-Reply-To: <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>
References: <B98C962A-7864-446B-98ED-69068C7F00D1@oracle.com>
 <5EDE9A75.6020504@oracle.com>
 <A8A5757E-15BC-4104-83DB-6084DFF5CC81@oracle.com>
 <EFE531CD-86C7-4155-BBC9-F4B45179B9A8@oracle.com> <5EE5AB71.20505@oracle.com>
 <DA8424D0-F428-405E-891A-EAB43650F96D@oracle.com>
 <B49ADE47-FA0E-4E48-A9AB-2E9F79ED9DA7@oracle.com>
 <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
 <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>
Message-ID: <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com>

Doc changes look good.

/Erik

On 2020-07-06 18:10, Kim Barrett wrote:
> I just noticed that doc/building.{md,html} describes minimum toolchain versions,
> so also needs to be updated.  Here?s the update, matching what?s now in the JEP:
>
> full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
> incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/
>
> I also deleted a discussion of a problem one might run into when building with
> Visual Studio 2010, since that version is no longer relevant.
>

From sundararajan.athijegannathan at oracle.com  Tue Jul  7 14:04:00 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 7 Jul 2020 19:34:00 +0530
Subject: request for review JDK-8242935
Message-ID: <572d3045-5e8b-3efa-d4bb-589acdc5e684@oracle.com>

This is in response to 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067571.html

Hi,

Your fix looks good to me.

Thanks

-Sundar


From kim.barrett at oracle.com  Tue Jul  7 14:38:48 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 7 Jul 2020 10:38:48 -0400
Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language
 Features in HotSpot
In-Reply-To: <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com>
References: <B98C962A-7864-446B-98ED-69068C7F00D1@oracle.com>
 <5EDE9A75.6020504@oracle.com>
 <A8A5757E-15BC-4104-83DB-6084DFF5CC81@oracle.com>
 <EFE531CD-86C7-4155-BBC9-F4B45179B9A8@oracle.com> <5EE5AB71.20505@oracle.com>
 <DA8424D0-F428-405E-891A-EAB43650F96D@oracle.com>
 <B49ADE47-FA0E-4E48-A9AB-2E9F79ED9DA7@oracle.com>
 <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
 <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>
 <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com>
Message-ID: <0680F1AA-351F-405C-A73D-CDA217D66CFF@oracle.com>

> On Jul 7, 2020, at 9:59 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Doc changes look good.
> 
> /Erik
> 
> On 2020-07-06 18:10, Kim Barrett wrote:
>> I just noticed that doc/building.{md,html} describes minimum toolchain versions,
>> so also needs to be updated.  Here?s the update, matching what?s now in the JEP:
>> 
>> full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
>> incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/
>> 
>> I also deleted a discussion of a problem one might run into when building with
>> Visual Studio 2010, since that version is no longer relevant.

Thanks.


From alexey at azul.com  Tue Jul  7 16:29:06 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 7 Jul 2020 16:29:06 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <B7EB9D0F-1F97-41C5-8318-487D85A036F7@azul.com>
 <F0EB3445-7F11-4BCA-AD2F-CFE47851F941@oracle.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
Message-ID: <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>

Hello Sean,

Thank you for review.
You are right, we can eliminate requirements for connection timeout property. I?ve added handshakeComletedListener to the LDAP over SSl. In this case we?ll have no possible performance impact caused by synchronous handshake.
Also, it allows to exclude changes in the LdapCtx class.

Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/

Regards
Alexey

> On 7 Jul 2020, at 02:30, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Thanks for that extra info.
> 
> I think it would be much cleaner to avoid having to set that property and instead start the handshake synchronously if the "com.sun.jndi.ldap.tls.cbtype" property is set. This way only one property needs to be set and you don't need to guess what an acceptable value is for the timeout property, which could also cause the connection to be interrupted before the TLS handshake is complete if you use too small of a value.
> 
> Or better yet, there may be another way to do this with JSSE where you wait for the TLS connection to complete. I'll ask my team and get back to you.
> 
> --Sean
> 
> 
> On 7/6/20 6:06 PM, Aleks Efimov wrote:
>> Hi Sean,
>> Alexey answered the same question for me:
>>> I mean ?com.sun.jndi.ldap.connect.timeout? property.
>>> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds:
>>> Connection.java
>>>>> if (connectTimeout > 0) {
>>>>>     int socketTimeout = sslSocket.getSoTimeout();
>>>>>     sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value
>>>>>     sslSocket.startHandshake();
>>>>>     sslSocket.setSoTimeout(socketTimeout);
>>>>> }
>>> Without this property handshake is started later asynchronously.
>>> As result
>>>>>    certs = ssock.getSession().getPeerCertificates();
>>> in the LdapClient.java could return SSLPeerUnverifiedException().
>>> This exception will be wrapped to NamingException and thrown to application.
>>> 
>>> This is not usually happens but I saw it on the slow connection
>> The full context of LDAP Connection code that initiates the SSL handshake could be viewed here:
>> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345
>> -- Aleksei
>> On 06/07/2020 21:11, Sean Mullan wrote:
>>> Hi Alexey,
>>> 
>>> This may have been discussed already, but can you explain why the "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to use this feature? That property is mostly used in tests to avoid long socket timeouts, etc.
>>> 
>>> Why does that need to be set? What problem are you trying to solve?
>>> 
>>> --Sean
>>> 
>>> 
>>> On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
>>>> 
>>>>> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it.
>>>>> 
>>>>> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice.
>>>> 
>>>> OK.
>>>> GSSContextImpl class is removed from patch.
>>>> 
>>>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
>>>> 
>>>> Thank you
>>>> Alexey
>>>> 


From andy.herrick at oracle.com  Tue Jul  7 16:45:11 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 7 Jul 2020 12:45:11 -0400
Subject: RFR: 8223955: Eliminate or reduce mixing of old File API and new
 Path/Files APIs
In-Reply-To: <077890ea-6a64-8313-5b86-9e1e02fcb5b2@oracle.com>
References: <077890ea-6a64-8313-5b86-9e1e02fcb5b2@oracle.com>
Message-ID: <87b2cca4-3dd8-287e-7dc1-8eb264e22a37@oracle.com>

looks good.

/Andy

On 7/6/2020 7:35 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> Substituted old File APIs with Path/Files APIs when it was possible 
> and makes sense.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223955
> [2] http://cr.openjdk.java.net/~almatvee/8223955/webrev.00/
>
> Thanks,
> Alexander

From daniel.fuchs at oracle.com  Tue Jul  7 17:57:18 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 Jul 2020 18:57:18 +0100
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
Message-ID: <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>

Hi,

I will not comment on the changes to libfdlibm/k_standard.c

Concerning NetworkInterface.c I believe the proposed changes are
incorrect - and I do not see the issue with the current code.

 > +    if (sizeof(if2.ifr_name) < sizeof(name)) {
 > +        return -1;
 > +    }

If I'm not mistaken `sizeof(name)` where name is a const char*
will always be 8 (on 64 bits architecture) - so this is probably
not doing what you want.

Also you don't want to trust that `name` is null terminated.
Calling strncpy in that case is much safer than calling strcpy
even if guarded by strlen.
I'm not sure what the compiler is warning you about here.

I'd suggest to experiment changing:

 >       memset((char *)&if2, 0, sizeof(if2));
 > -     strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
   +     strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
   +     if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

and see if that makes the warning go away.

best regards,

-- daniel


On 24/06/2020 08:48, Koichi Sakata wrote:
> Hi all,
> 
> (I've sent a similar e-mail before to this ML, but I extract the part 
> only related to core-libs-dev ML from the previous one.)
> 
> I tried to build OpenJDK fastdebug with GCC 10.1 on Ubuntu 18.04, but I 
> saw some compiler warnings as follows:
> 
> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/: In 
> function '__j__kernel_standard':
> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/k_standard.c:743:19: 
> error: 'exc.retval' may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
>  ? 743 |???????? return exc.retval;
>  ????? |??????????????? ~~~^~~~~~~
> 
> In file included from /usr/include/string.h:494,
>  ???????????????? from 
> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:30: 
> 
> In function 'strncpy',
>  ??? inlined from 'getFlags' at 
> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:1362:5, 
> 
>  ??? inlined from 'addif' at 
> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:974:13: 
> 
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
> '__builtin_strncpy' output may be truncated copying 15 bytes from a 
> string of length 15 [-Werror=stringop-truncation]
>  ? 106 |?? return __builtin___strncpy_chk (__dest, __src, __len, __bos 
> (__dest));
>  ????? | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I can resolve them with the following patch. I believe it fixes those 
> potential bugs, so I'd like to contribute it.
> (Our company has signed OCA.)
> 
> Thanks,
> Koichi
> 
> ===== PATCH =====
> diff -r 20d92fe3ac52 src/java.base/share/native/libfdlibm/k_standard.c
> --- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Jun 16 
> 03:16:41 2020 +0000
> +++ b/src/java.base/share/native/libfdlibm/k_standard.c Thu Jun 18 
> 07:08:50 2020 +0900
> @@ -739,6 +739,10 @@
>  ???????????????????????? errno = EDOM;
>  ???????????????? }
>  ???????????????? break;
> +??????????? default:
> +??????????????? exc.retval = zero;
> +??????????????? errno = EINVAL;
> +??????????????? break;
>  ???????? }
>  ???????? return exc.retval;
>  ?}
> diff -r 20d92fe3ac52 src/java.base/unix/native/libnet/NetworkInterface.c
> --- a/src/java.base/unix/native/libnet/NetworkInterface.c?????? Tue Jun 
> 16 03:16:41 2020 +0000
> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c?????? Thu Jun 
> 18 07:08:50 2020 +0900
> @@ -1296,7 +1296,10 @@
>  ?static int getIndex(int sock, const char *name) {
>  ???? struct ifreq if2;
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
> +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
> +??????? return -1;
> +??? }
> +??? strcpy(if2.ifr_name, name);
> 
>  ???? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>  ???????? return -1;
> @@ -1359,7 +1362,10 @@
>  ?static int getFlags(int sock, const char *ifname, int *flags) {
>  ???? struct ifreq if2;
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
> +??? if (sizeof(if2.ifr_name) < sizeof(ifname)) {
> +??????? return -1;
> +??? }
> +??? strcpy(if2.ifr_name, ifname);
> 
>  ???? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>  ???????? return -1;


From paul.sandoz at oracle.com  Tue Jul  7 18:09:01 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Jul 2020 11:09:01 -0700
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <03b4d761-cdaf-2c35-89ec-6227d9ecf700@gmail.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <03b4d761-cdaf-2c35-89ec-6227d9ecf700@gmail.com>
Message-ID: <699535E9-E8CA-4BF6-8FC6-72E78968A303@oracle.com>

Hi Peter,

You guessed correctly about the motivation from the API perspective.

I would like to stress that short-circuiting optimizations are an implementation detail that are only partially applied. Surfacing the notion of cooperative cancellation for one operation has quite a cost, and will likely increase the expectation that it applies in all scenarios.

My sense is your example is likely more of on the edge than common. I believe it's simple to implement but would prefer to hold off and focus the current implementation and integrate, then we could reconsider afterwards if need be.

Paul.

> On Jul 5, 2020, at 1:44 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Patric, Julia,
> 
> On 7/2/20 6:45 PM, Patrick Concannon wrote:
>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/  <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
> 
> 
> Then I'd like to discuss cancelation (shortcut Streams). Currently mapMulti does not do anything to optimize processing if the downstream decides it does not need more elements but just keeps pushing. This is a decision I guess to keep the API surface clean and simple. All short-cutting ops or even intermediate (like limit) must therefore ignore the surplus elements that are emitted by mapMulti and they do so. If the intermediate operations up-stream mapMulti are respecting the cancelation, this results in at most one invocation of mapMulti function producing surplus elements, but if they don't, then multiple invocations of mapMulti function is producing surplus elements.
> 
> For example:
> 
> 
>     someStream
> 
>         .mapMulti((e, sink) -> { .... sink.accept(x); ... })
> 
>         .filter(x -> ...)
> 
>         .mapMulti((x, sink) -> { ... sink.accept(y); ...})
> 
>         .limit(10)
> 
>         ...
> 
> 
> Here the 1st mapMulti emits elements and each of them is filtered and then maybe passed to 2nd mapMulti. the 2nd mapMulti could skip calling its function if the downstream limit(10) has already passed 10 elements.
> 
> 
> WDYT?
> 
> 
> Regards, Peter
> 
> 


From alexey.semenyuk at oracle.com  Tue Jul  7 18:16:06 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 7 Jul 2020 14:16:06 -0400
Subject: RFR: 8223955: Eliminate or reduce mixing of old File API and new
 Path/Files APIs
In-Reply-To: <87b2cca4-3dd8-287e-7dc1-8eb264e22a37@oracle.com>
References: <077890ea-6a64-8313-5b86-9e1e02fcb5b2@oracle.com>
 <87b2cca4-3dd8-287e-7dc1-8eb264e22a37@oracle.com>
Message-ID: <ec21966f-88f8-5b97-46de-1a46ba637af9@oracle.com>

Looks good!

- Alexey

On 7/7/2020 12:45 PM, Andy Herrick wrote:
> looks good.
>
> /Andy
>
> On 7/6/2020 7:35 PM, alexander.matveev at oracle.com wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> Substituted old File APIs with Path/Files APIs when it was possible 
>> and makes sense.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223955
>> [2] http://cr.openjdk.java.net/~almatvee/8223955/webrev.00/
>>
>> Thanks,
>> Alexander


From forax at univ-mlv.fr  Tue Jul  7 18:20:06 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 7 Jul 2020 20:20:06 +0200 (CEST)
Subject: =?utf-8?Q?Re:_RFR[8238286]:_'Add_new_flatMap_stream_?=
 =?utf-8?Q?operation_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <699535E9-E8CA-4BF6-8FC6-72E78968A303@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <03b4d761-cdaf-2c35-89ec-6227d9ecf700@gmail.com>
 <699535E9-E8CA-4BF6-8FC6-72E78968A303@oracle.com>
Message-ID: <1499464604.1548460.1594146006214.JavaMail.zimbra@u-pem.fr>

At the same time,
mapMulti and flatMap are two sides of the same coins,
flatMap uses a pull API while mapMulti uses a push API.

so having mapMulti and flatMap doing cancellation differently is inconsistent.

Consistency is a good way to avoid to expect that all operations do short-circuiting optimizations.

R?mi 

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> ?: "Peter Levart" <peter.levart at gmail.com>
> Cc: "Patrick Concannon" <patrick.concannon at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>, "Julia Boes"
> <julia.boes at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 7 Juillet 2020 20:09:01
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing?

> Hi Peter,
> 
> You guessed correctly about the motivation from the API perspective.
> 
> I would like to stress that short-circuiting optimizations are an implementation
> detail that are only partially applied. Surfacing the notion of cooperative
> cancellation for one operation has quite a cost, and will likely increase the
> expectation that it applies in all scenarios.
> 
> My sense is your example is likely more of on the edge than common. I believe
> it's simple to implement but would prefer to hold off and focus the current
> implementation and integrate, then we could reconsider afterwards if need be.
> 
> Paul.
> 
>> On Jul 5, 2020, at 1:44 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>> Hi Patric, Julia,
>> 
>> On 7/2/20 6:45 PM, Patrick Concannon wrote:
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/
>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>> 
>> 
>> Then I'd like to discuss cancelation (shortcut Streams). Currently mapMulti does
>> not do anything to optimize processing if the downstream decides it does not
>> need more elements but just keeps pushing. This is a decision I guess to keep
>> the API surface clean and simple. All short-cutting ops or even intermediate
>> (like limit) must therefore ignore the surplus elements that are emitted by
>> mapMulti and they do so. If the intermediate operations up-stream mapMulti are
>> respecting the cancelation, this results in at most one invocation of mapMulti
>> function producing surplus elements, but if they don't, then multiple
>> invocations of mapMulti function is producing surplus elements.
>> 
>> For example:
>> 
>> 
>>     someStream
>> 
>>         .mapMulti((e, sink) -> { .... sink.accept(x); ... })
>> 
>>         .filter(x -> ...)
>> 
>>         .mapMulti((x, sink) -> { ... sink.accept(y); ...})
>> 
>>         .limit(10)
>> 
>>         ...
>> 
>> 
>> Here the 1st mapMulti emits elements and each of them is filtered and then maybe
>> passed to 2nd mapMulti. the 2nd mapMulti could skip calling its function if the
>> downstream limit(10) has already passed 10 elements.
>> 
>> 
>> WDYT?
>> 
>> 
>> Regards, Peter
>> 

From paul.sandoz at oracle.com  Tue Jul  7 19:04:09 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Jul 2020 12:04:09 -0700
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <1499464604.1548460.1594146006214.JavaMail.zimbra@u-pem.fr>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <03b4d761-cdaf-2c35-89ec-6227d9ecf700@gmail.com>
 <699535E9-E8CA-4BF6-8FC6-72E78968A303@oracle.com>
 <1499464604.1548460.1594146006214.JavaMail.zimbra@u-pem.fr>
Message-ID: <BB3C0B52-66BD-407B-A619-60A265EB7621@oracle.com>

Hi Remi,

I stress again that the short-circuiting optimizations are an implementation detail that are partially applied. The behavior is not specified. It's already inconsistent. 

We might be able to improve on certain cases, as in Peter?s example, and apply an optimization consistently for flatMap and mapMulti. But I would prefer we focus on what we have now and consider that later if need be.

Paul.

> On Jul 7, 2020, at 11:20 AM, forax at univ-mlv.fr wrote:
> 
> At the same time,
> mapMulti and flatMap are two sides of the same coins,
> flatMap uses a pull API while mapMulti uses a push API.
> 
> so having mapMulti and flatMap doing cancellation differently is inconsistent.
> 
> Consistency is a good way to avoid to expect that all operations do short-circuiting optimizations.
> 
> R?mi 
> 
> ----- Mail original -----
>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>> ?: "Peter Levart" <peter.levart at gmail.com>
>> Cc: "Patrick Concannon" <patrick.concannon at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>, "Julia Boes"
>> <julia.boes at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Mardi 7 Juillet 2020 20:09:01
>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing?
> 
>> Hi Peter,
>> 
>> You guessed correctly about the motivation from the API perspective.
>> 
>> I would like to stress that short-circuiting optimizations are an implementation
>> detail that are only partially applied. Surfacing the notion of cooperative
>> cancellation for one operation has quite a cost, and will likely increase the
>> expectation that it applies in all scenarios.
>> 
>> My sense is your example is likely more of on the edge than common. I believe
>> it's simple to implement but would prefer to hold off and focus the current
>> implementation and integrate, then we could reconsider afterwards if need be.
>> 
>> Paul.
>> 
>>> On Jul 5, 2020, at 1:44 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>> 
>>> Hi Patric, Julia,
>>> 
>>> On 7/2/20 6:45 PM, Patrick Concannon wrote:
>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/
>>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>>> 
>>> 
>>> Then I'd like to discuss cancelation (shortcut Streams). Currently mapMulti does
>>> not do anything to optimize processing if the downstream decides it does not
>>> need more elements but just keeps pushing. This is a decision I guess to keep
>>> the API surface clean and simple. All short-cutting ops or even intermediate
>>> (like limit) must therefore ignore the surplus elements that are emitted by
>>> mapMulti and they do so. If the intermediate operations up-stream mapMulti are
>>> respecting the cancelation, this results in at most one invocation of mapMulti
>>> function producing surplus elements, but if they don't, then multiple
>>> invocations of mapMulti function is producing surplus elements.
>>> 
>>> For example:
>>> 
>>> 
>>>    someStream
>>> 
>>>        .mapMulti((e, sink) -> { .... sink.accept(x); ... })
>>> 
>>>        .filter(x -> ...)
>>> 
>>>        .mapMulti((x, sink) -> { ... sink.accept(y); ...})
>>> 
>>>        .limit(10)
>>> 
>>>        ...
>>> 
>>> 
>>> Here the 1st mapMulti emits elements and each of them is filtered and then maybe
>>> passed to 2nd mapMulti. the 2nd mapMulti could skip calling its function if the
>>> downstream limit(10) has already passed 10 elements.
>>> 
>>> 
>>> WDYT?
>>> 
>>> 
>>> Regards, Peter
>>> 


From patrick.concannon at oracle.com  Tue Jul  7 20:46:32 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Tue, 7 Jul 2020 21:46:32 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <9703de63-8787-eb20-95cc-33dc911cf39c@anthonyv.be>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <24F8FA40-3DC5-4156-B208-CCE54DB8CCF5@oracle.com>
 <2F795DFF-36B6-4903-B0AF-120973F29AD8@oracle.com>
 <6ea32a67-8292-39c7-df04-58ad15b2fde4@anthonyv.be>
 <3885AE11-2951-47B8-B030-6A0E87C7C73E@oracle.com>
 <9703de63-8787-eb20-95cc-33dc911cf39c@anthonyv.be>
Message-ID: <7B86062C-3A24-40E7-B906-A39E8FCFB09A@oracle.com>

Hi Anthony, 

It's a good point.

You're correct in saying that `Stream.Builder` is a superset of `Consumer`, however `Stream.Builder`'s usual usage is in the creation of new streams. To use it in this context brings with it the connotation that we are going to create a new stream, something we don't want to suggest. In its current state, we push directly downstream and don't create an intermediate stream (like in `flatMap`, for example). 

With regards to the build operation, I have to disagree. The build method is central to the `Stream.Builder`'s use case. In your example, I think it's obvious that close shouldn't be called unless you wish the Stream to be closed. However, in the case with build the opposite is true: it's not obvious that a call to build shouldn't be made when you want to finish building your stream.

Both operations are similar, but `Consumer` doesn't bring this baggage with it and therefore seems more fitting.

Kind regards,
Patrick

> On 4 Jul 2020, at 17:23, Anthony Vanelverdinghe <dev at anthonyv.be> wrote:
> 
> On 02/07/2020 16:38, Patrick Concannon wrote:
>> Hi Anthony,
> Hi Patrick
>> Thanks for your suggestion of using a Stream.Builder instead of a Consumer.
> Thanks for your response. Since Stream.Builder extends Consumer, I don't see it as "instead of": the proposed signature is a strict superset of the actual signature. For example, it would accept a BiConsumer<Object, Stream.Builder<String>>, whereas the current signature doesn't.
>> However, one of the goals for mapMulti is not to create an additional Stream.
> Would you mind to elaborate on this? Given that Stream.Builder extends Consumer, I don't see why using Stream.Builder would imply having to create any more Streams than when using Consumer.
>> Also, I fear that using a builder, but throwing an exception on a call to build, is counter-intuitive and perhaps confusing to the user.
> Point taken, but I beg to differ: to me this is no different than a method `void foo(Consumer<InputStream> bar)` which specifies that the given Consumer must not invoke `close` on the InputStream.
> Moreover, with the build step being the sole difference with `flatMap`, and the elimination of intermediary Streams being a rather obvious optimization, I believe most users would find it intuitive not to invoke `build` themselves (or they would have read the Javadoc and know not to :)).
> Finally, using Stream.Builder makes it intuitive for me what the method does, even without considering its name.
> 
> Given the above, I still hold that Stream.Builder is a better choice to use in the signature. Even more so, I believe there are several things that hint at the need for an additional abstraction: your point about the potential confusion, the analogy with Collector (as already mentioned by Paul w.r.t. the order of the BiConsumer's type arguments), and the natural similarity between e.g. BiConsumer<T, Stream.Builder<R>> and Function<T, Stream<R>>.
> 
> Therefore I'd like to propose the following (complete declarations below):
> 
> * introduce a new interface: Transformer<T, I, R> extends Function<T, R>
> * adapt Collector to extend it: Collector<T, A, R> extends Transformer<Stream<T>, A, R>
> 
> So a Transformer is nothing more than a Function which passes via an intermediary I to map T to R according to a certain protocol.
> 
> Then a method with the following signature could be added to Stream:
> <R> Stream<R> flatMap(Transformer<? super T, ? super Stream.Builder<R>, ? extends Stream<R>> mapper)
> 
> Such a Transformer could readily be created from a given BiConsumer (see Tranformer::of below).
> 
> Since Transformer is a subinterface of Function, there wouldn't be any ambiguities w.r.t. overload resolution, so we could just name the new method `flatMap` (I assume such ambiguities are the reason why this currently isn't the case, since Function and BiConsumer are unrelated?).
> 
> Below is a self-contained "demo", containing a simple Demo class, the declaration of Transformer, and the adapted declaration of Collector.
> 
> Thanks in advance for any feedback.
> 
> Kind regards
> Anthony
> 
> 
> 
> import java.util.ArrayList;
> import java.util.List;
> import java.util.Set;
> import java.util.function.BiConsumer;
> import java.util.function.BinaryOperator;
> import java.util.function.Function;
> import java.util.function.Supplier;
> import java.util.stream.Stream;
> 
> public class Demo {
> 
>     public static void main(String[] args) {
>         BiConsumer<String, Stream.Builder<String>> anagrams = (word, builder) -> {
>             if(word.equals("listen")) {
>                 builder.accept("silent");
>                 builder.accept("enlist");
>             }
>         };
>         Transformer.of(anagrams::accept).apply("listen").forEachOrdered(System.out::println);
>     }
> 
> }
> 
> interface Transformer<T, I, R> extends Function<T, R> {
> 
>     Supplier<? extends I> supplier();
> 
>     BiConsumer<? super T, ? super I> transformer();
> 
>     Function<? super I, ? extends R> finisher();
> 
>     @Override
>     default R apply(T t) {
>         var intermediary = supplier().get();
>         transformer().accept(t, intermediary);
>         return finisher().apply(intermediary);
>     }
> 
>     static <U, V> Transformer<U, Stream.Builder<V>, Stream<V>> of(BiConsumer<? super U, ? super Stream.Builder<V>> transformer) {
>         return new Transformer<>() {
>             @Override
>             public Supplier<Stream.Builder<V>> supplier() {
>                 return Stream::builder;
>             }
> 
>             @Override
>             public BiConsumer<U, Stream.Builder<V>> transformer() {
>                 return transformer::accept;
>             }
> 
>             @Override
>             public Function<Stream.Builder<V>, Stream<V>> finisher() {
>                 return Stream.Builder::build;
>             }
>         };
>     }
> 
> }
> 
> interface Collector<T, A, R> extends Transformer<Stream<T>, A, R> {
> 
>     @Override
>     Supplier<A> supplier();
> 
>     BiConsumer<A, T> accumulator();
> 
>     BinaryOperator<A> combiner();
> 
>     @Override
>     Function<A, R> finisher();
> 
>     Set<Characteristics> characteristics();
> 
>     enum Characteristics {
>         CONCURRENT,
>         UNORDERED,
>         IDENTITY_FINISH
>     }
> 
>     @Override
>     default BiConsumer<Stream<T>, A> transformer() {
>         return (stream, intermediary) -> {
>             var accumulator = accumulator();
>             stream.forEachOrdered(t -> accumulator.accept(intermediary, t));
>         };
>     }
> 
> }
> 
>> 
>> Kind regards,
>> 
>> Patrick
>> 
>>> On 25 Jun 2020, at 18:12, Anthony Vanelverdinghe <dev at anthonyv.be> <mailto:dev at anthonyv.be> wrote:
>>> 
>>> Hi
>>> 
>>> Given the signature of flatMap is:
>>> <R> Stream<R> flatMap?(Function<? super T, ? extends Stream<? extends R>> mapper)
>>> 
>>> I'd like to propose the following signature for the new method:
>>> <R> Stream<R> builderMap(BiConsumer<? super T, ? super Stream.Builder<R>> mapper)
>>> 
>>> This way both methods are named "...Map", and the name "builderMap" follows naturally from the argument's type.
>>> If the given mapper invokes Stream.Builder::build, an IllegalStateException should be thrown.
>>> 
>>> Kind regards,
>>> Anthony
>>> 
>>> On 25/06/2020 02:58, Paul Sandoz wrote:
>>>> Hi,
>>>> 
>>>> We traded CPS style for reusing existing functional interfaces. Originally the signature (my first choice) was as you indicate.
>>>> 
>>>> By chance it just so happens that the current signature is the same shape as that for the accumulating argument type of the three arg collect terminal operation:
>>>> 
>>>> Stream
>>>> <R> R collect(Supplier<R> supplier,
>>>>               BiConsumer<R, ? super T> accumulator,
>>>>               BiConsumer<R, R> combiner);
>>>> 
>>>> IntStream
>>>> <R> R collect(Supplier<R> supplier,
>>>>               ObjIntConsumer<R> accumulator,
>>>>               BiConsumer<R, R> combiner);
>>>> 
>>>> Same for the accumulator of a Collector too.
>>>> 
>>>> However, I suspect you would argue these terminal accumulation cases are different from the intermediate case, as we are not accumulating but passing or accepting (loosely returning) zero or more elements that replace the input element.
>>>> 
>>>> It?s my hope that generic specialization will allow the primitive stream types to fade into the background, along with the primitive functional interfaces. In that respect the addition of three functional interfaces for use on the primitive stream types is not so terrible.
>>>> 
>>>> 
>>>> Regarding the name, you should have seen the first one :-) it was terrible.
>>>> 
>>>> Here?s my few brush strokes on the bike shed. I wonder what people think of mapAccept. The specification talks about accepting elements, because that is the operative method name on Consumer. So we can say "T is replaced with the elements accepted by the Consumer<R>", or ? The Consumer<R> accepts the elements that replace T"
>>>> 
>>>> Paul.
>>>> 
>>>> 
>>>> 
>>>>> On Jun 24, 2020, at 1:01 PM, John Rose <john.r.rose at oracle.com> <mailto:john.r.rose at oracle.com> wrote:
>>>>> 
>>>>> I like this new API point a lot; it allows flexible, local, temporary
>>>>> control inversion in the context of one stream transform.
>>>>> 
>>>>> What?s the performance model?  It seems like the SpinedBuffer
>>>>> implementation makes a worst-case assumption about the number
>>>>> of pending values, that there will be many instead of zero or one.
>>>>> 
>>>>> But I guess the pipeline stuff already works in terms of pushes, so
>>>>> the good news might be that this is really just a drill-down from the
>>>>> user API into the kinds of operations (push-flavored) that go on
>>>>> most of the time.
>>>>> 
>>>>> OK, so I like the function but I have a beef with its bike shed
>>>>> color.  First of all, this is a control-inversion (CPS) pattern,
>>>>> which is very powerful but also notoriously hard to read.
>>>>> I think that in Java APIs, at least in Stream APIs, code is
>>>>> easier to read if the logical data flow is from left to right.
>>>>> 
>>>>> (This is a language-specific observation.  Apart from varargs,
>>>>> Java method APIs read favorably when extra control arguments
>>>>> are added onto the end of the argument list.  Also, the convention
>>>>> for generic functional interfaces is that the return value type
>>>>> goes to the right, e.g., R in Function<A,R>.)
>>>>> 
>>>>> So the BiConsumer is backwards, because the logical return
>>>>> should be written, if not as a true return (which would appear
>>>>> at the end of type parameter lists), at the end of the incoming
>>>>> parameters (and in the last type parameter).
>>>>> 
>>>>> I also think ?multi? is needlessly ?learned? sounding.  A simple
>>>>> spatial preposition would work well: mapThrough, mapAcross, etc.
>>>>> I think I prefer mapAcross because the term ?across? can be read
>>>>> adverbially: ?we are mapping T across to Consumer<R>?.
>>>>> 
>>>>> So:
>>>>> 
>>>>> mapAcross(BiConsumer<? super T, Consumer<R>> mapper)
>>>>> mapAcrossToInt(BiConsumer<? super T, IntConsumer> mapper)
>>>>> mapAcross?(IntObjConsumer<IntConsumer> mapper)
>>>>> 
>>>>> This does require additional FI?s like IntObjConsumer, but
>>>>> I think that is a negligible cost.  Making the control inversion
>>>>> *readable* is the high order bit here, not minimizing the number
>>>>> of trivial FIs.
>>>>> 
>>>>> (I almost hear David Bowman, in his space suit, saying, ?My API?
>>>>> It?s full of bikesheds!?  There?s a meme for that.)
>>>>> 
>>>>> ? John
>>>>> 
>>>>> On Jun 24, 2020, at 3:57 AM, Patrick Concannon <patrick.concannon at oracle.com> <mailto:patrick.concannon at oracle.com> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing??
>>>>>> 
>>>>>> This proposal is to add a new flatMap-like operation:
>>>>>> 
>>>>>> `<R> Stream<R> mapMulti(BiConsumer<Consumer<R>, ? super T> mapper)`
>>>>>> 
>>>>>> to the java.util.Stream class. This operation is more receptive to the pushing or yielding of values than the current implementation that internally assembles values (if any) into one or more streams. This addition includes the primitive variations of the operation i.e. mapMultiToInt, IntStream mapMulti, etc.
>>>>>> 
>>>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8238286 <https://bugs.openjdk.java.net/browse/JDK-8238286> <https://bugs.openjdk.java.net/browse/JDK-8238286> <https://bugs.openjdk.java.net/browse/JDK-8238286>
>>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8248166 <https://bugs.openjdk.java.net/browse/JDK-8248166> <https://bugs.openjdk.java.net/browse/JDK-8248166> <https://bugs.openjdk.java.net/browse/JDK-8248166>
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/>
>>>>>> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html>  <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html> <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview-summary.html>
>>>>>> 
>>>>>> 
>>>>>> Kind regards,
>>>>>> Patrick & Julia


From forax at univ-mlv.fr  Tue Jul  7 22:17:22 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 8 Jul 2020 00:17:22 +0200 (CEST)
Subject: =?utf-8?Q?Re:_RFR[8238286]:_'Add_new_flatMap_stream_?=
 =?utf-8?Q?operation_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <BB3C0B52-66BD-407B-A619-60A265EB7621@oracle.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <03b4d761-cdaf-2c35-89ec-6227d9ecf700@gmail.com>
 <699535E9-E8CA-4BF6-8FC6-72E78968A303@oracle.com>
 <1499464604.1548460.1594146006214.JavaMail.zimbra@u-pem.fr>
 <BB3C0B52-66BD-407B-A619-60A265EB7621@oracle.com>
Message-ID: <2131096494.1616442.1594160242320.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Peter Levart" <peter.levart at gmail.com>, "Patrick Concannon" <patrick.concannon at oracle.com>, "Julia Boes"
> <julia.boes at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 7 Juillet 2020 21:04:09
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing?

> Hi Remi,
> 
> I stress again that the short-circuiting optimizations are an implementation
> detail that are partially applied. The behavior is not specified. It's already
> inconsistent.
> 
> We might be able to improve on certain cases, as in Peter?s example, and apply
> an optimization consistently for flatMap and mapMulti. But I would prefer we
> focus on what we have now and consider that later if need be.

I don't think an incremental evolution works here,
because apart from people trying to understand streams, you have also a whole ecosystem on top of the stream API like by example IDEs that can refactor, provide visual debugging, etc of streams.

> 
> Paul.

R?mi

> 
>> On Jul 7, 2020, at 11:20 AM, forax at univ-mlv.fr wrote:
>> 
>> At the same time,
>> mapMulti and flatMap are two sides of the same coins,
>> flatMap uses a pull API while mapMulti uses a push API.
>> 
>> so having mapMulti and flatMap doing cancellation differently is inconsistent.
>> 
>> Consistency is a good way to avoid to expect that all operations do
>> short-circuiting optimizations.
>> 
>> R?mi
>> 
>> ----- Mail original -----
>>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>>> ?: "Peter Levart" <peter.levart at gmail.com>
>>> Cc: "Patrick Concannon" <patrick.concannon at oracle.com>, "Remi Forax"
>>> <forax at univ-mlv.fr>, "Julia Boes"
>>> <julia.boes at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Envoy?: Mardi 7 Juillet 2020 20:09:01
>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable
>>> to pushing?
>> 
>>> Hi Peter,
>>> 
>>> You guessed correctly about the motivation from the API perspective.
>>> 
>>> I would like to stress that short-circuiting optimizations are an implementation
>>> detail that are only partially applied. Surfacing the notion of cooperative
>>> cancellation for one operation has quite a cost, and will likely increase the
>>> expectation that it applies in all scenarios.
>>> 
>>> My sense is your example is likely more of on the edge than common. I believe
>>> it's simple to implement but would prefer to hold off and focus the current
>>> implementation and integrate, then we could reconsider afterwards if need be.
>>> 
>>> Paul.
>>> 
>>>> On Jul 5, 2020, at 1:44 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>>> 
>>>> Hi Patric, Julia,
>>>> 
>>>> On 7/2/20 6:45 PM, Patrick Concannon wrote:
>>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/
>>>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>>>> 
>>>> 
>>>> Then I'd like to discuss cancelation (shortcut Streams). Currently mapMulti does
>>>> not do anything to optimize processing if the downstream decides it does not
>>>> need more elements but just keeps pushing. This is a decision I guess to keep
>>>> the API surface clean and simple. All short-cutting ops or even intermediate
>>>> (like limit) must therefore ignore the surplus elements that are emitted by
>>>> mapMulti and they do so. If the intermediate operations up-stream mapMulti are
>>>> respecting the cancelation, this results in at most one invocation of mapMulti
>>>> function producing surplus elements, but if they don't, then multiple
>>>> invocations of mapMulti function is producing surplus elements.
>>>> 
>>>> For example:
>>>> 
>>>> 
>>>>    someStream
>>>> 
>>>>        .mapMulti((e, sink) -> { .... sink.accept(x); ... })
>>>> 
>>>>        .filter(x -> ...)
>>>> 
>>>>        .mapMulti((x, sink) -> { ... sink.accept(y); ...})
>>>> 
>>>>        .limit(10)
>>>> 
>>>>        ...
>>>> 
>>>> 
>>>> Here the 1st mapMulti emits elements and each of them is filtered and then maybe
>>>> passed to 2nd mapMulti. the 2nd mapMulti could skip calling its function if the
>>>> downstream limit(10) has already passed 10 elements.
>>>> 
>>>> 
>>>> WDYT?
>>>> 
>>>> 
>>>> Regards, Peter

From alexander.matveev at oracle.com  Tue Jul  7 22:51:39 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Tue, 7 Jul 2020 15:51:39 -0700
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
Message-ID: <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>

Hi Andy,

Timestamps for error message without verbose output are meaningless in 
my opinion. This is why I did not add them. Also, in some cases output 
does not look right. For example when timestamp is added to error 
message always:
jpackage --someoption
WARNING: Using incubator modules: jdk.incubator.jpackage
[15:49:23.798] Error: Invalid Option: [--someoption]

In example above I do not see any point to have timestamp.

Thanks,
Alexander

On 7/7/20 6:18 AM, Andy Herrick wrote:
> All looks good, except maybe Log.error().
>
> I think Log.error() should have the same output whether verbose or 
> not, adding timestamp to the message only if verbose does not look right.
>
> Problem is that Log.error() is used for two fundamentally different 
> purposes:
>
> 1.) by Main and Arguments to display the final error message when 
> jpackage is failing.
>
> 2.) by everyone else to display a serious warning message when 
> jpackage is continuing (sometimes failing further on, and sometimes not).
>
> I wouldn't mind adding timestamps only when verbose in case (2), but I 
> don't think that's appropriate for case (1).
>
> /ANdy
>
> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>
>> Thanks,
>> Alexander


From naoto.sato at oracle.com  Tue Jul  7 22:55:32 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 7 Jul 2020 15:55:32 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid date-only
Message-ID: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8248695/webrev.00/

There were two causes that resulted in throwing exceptions. One was that 
the Host adapter for Windows always produced Date and Time combined 
patterns, so formatting a LocalDate ended up with unsupported temporal 
field for HourOfDay (reported in the bug), and the other cause was the 
pattern for am/pm was "aa", which was not valid as a DateTimeFormatter 
pattern.

Besides these issues, localized DayOfWeek/AM_PM names have not been 
correctly implemented in the host adapter. Now those names are correctly 
returned from Windows.

Naoto

From andy.herrick at oracle.com  Tue Jul  7 23:20:43 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 7 Jul 2020 19:20:43 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
Message-ID: <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>

I agree - but I would rather then that Log.error() never show timestamp.

It would be better still if we could differentiate fatal error messages 
from warning messages - right now we are using Log.error for both.

/Andy


On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
> Hi Andy,
>
> Timestamps for error message without verbose output are meaningless in 
> my opinion. This is why I did not add them. Also, in some cases output 
> does not look right. For example when timestamp is added to error 
> message always:
> jpackage --someoption
> WARNING: Using incubator modules: jdk.incubator.jpackage
> [15:49:23.798] Error: Invalid Option: [--someoption]
>
> In example above I do not see any point to have timestamp.
>
> Thanks,
> Alexander
>
> On 7/7/20 6:18 AM, Andy Herrick wrote:
>> All looks good, except maybe Log.error().
>>
>> I think Log.error() should have the same output whether verbose or 
>> not, adding timestamp to the message only if verbose does not look 
>> right.
>>
>> Problem is that Log.error() is used for two fundamentally different 
>> purposes:
>>
>> 1.) by Main and Arguments to display the final error message when 
>> jpackage is failing.
>>
>> 2.) by everyone else to display a serious warning message when 
>> jpackage is continuing (sometimes failing further on, and sometimes 
>> not).
>>
>> I wouldn't mind adding timestamps only when verbose in case (2), but 
>> I don't think that's appropriate for case (1).
>>
>> /ANdy
>>
>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>
>>> Thanks,
>>> Alexander
>

From alexey.semenyuk at oracle.com  Tue Jul  7 23:23:03 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 7 Jul 2020 19:23:03 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
Message-ID: <5fa3430c-d11f-6777-88f4-7e6e07516a60@oracle.com>

Alexander,

We probably need a clean separation of logging from error reporting as 
Andy pointed out in his comment. I don't think having timestamps only in 
verbose output is a good idea.
Besides at some point we might will use java.util.logging.Logger instead 
of jdk.incubator.jpackage.internal.Log and having this clean separation 
would make this transition easier.

- Alexey

On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
> Hi Andy,
>
> Timestamps for error message without verbose output are meaningless in 
> my opinion. This is why I did not add them. Also, in some cases output 
> does not look right. For example when timestamp is added to error 
> message always:
> jpackage --someoption
> WARNING: Using incubator modules: jdk.incubator.jpackage
> [15:49:23.798] Error: Invalid Option: [--someoption]
>
> In example above I do not see any point to have timestamp.
>
> Thanks,
> Alexander
>
> On 7/7/20 6:18 AM, Andy Herrick wrote:
>> All looks good, except maybe Log.error().
>>
>> I think Log.error() should have the same output whether verbose or 
>> not, adding timestamp to the message only if verbose does not look 
>> right.
>>
>> Problem is that Log.error() is used for two fundamentally different 
>> purposes:
>>
>> 1.) by Main and Arguments to display the final error message when 
>> jpackage is failing.
>>
>> 2.) by everyone else to display a serious warning message when 
>> jpackage is continuing (sometimes failing further on, and sometimes 
>> not).
>>
>> I wouldn't mind adding timestamps only when verbose in case (2), but 
>> I don't think that's appropriate for case (1).
>>
>> /ANdy
>>
>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>
>>> Thanks,
>>> Alexander
>


From felix.yang at huawei.com  Wed Jul  8 03:34:47 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Wed, 8 Jul 2020 03:34:47 +0000
Subject: RFR(S): 8248910: NPE when freeing the memory for a slice from a buffer
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE7E64F16@dggeml527-mbx.china.huawei.com>

Hi,

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

    The overall procedure is described by the newly add test.
    For a slice from a ByteBuffer, it does not have a cleaner, which leads to the NPE.
    Here, I thinks we should not try to free the memory of a slice.
    Proposed fix adds a null check for cleaner in Util.free before invoking its clean() method.
    Another possible way would be catching slice in Util. releaseTemporaryDirectBuffer and exclude it.
    
    Tier1-3 tested on x86_64-linux-gnu.  Newly add test fail without the fix and pass otherwise.
    Comments?

Thanks,
Felix

From Yang.Zhang at arm.com  Wed Jul  8 07:05:09 2020
From: Yang.Zhang at arm.com (Yang Zhang)
Date: Wed, 8 Jul 2020 07:05:09 +0000
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
Message-ID: <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
   aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
   in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/

Thanks,
Yang


-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

On 29/06/2020 08:48, Yang Zhang wrote:
> 1. Instructions that can be matched with NEON instructions directly.
> MulVB, SqrtVF and AbsV have been merged into jdk master already.
> 
> 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly.
> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. 
> 
> 3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
> These instructions cannot be moved into jdk master first because there isn't middle-end support.
> 
> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again.

Thank you *very* much for your hard work. Appreciated!

--
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 sean.mullan at oracle.com  Wed Jul  8 12:25:08 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Jul 2020 08:25:08 -0400
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
Message-ID: <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>

On 7/7/20 12:29 PM, Alexey Bakhtin wrote:
> Hello Sean,
> 
> Thank you for review.
> You are right, we can eliminate requirements for connection timeout property. I?ve added handshakeComletedListener to the LDAP over SSl. In this case we?ll have no possible performance impact caused by synchronous handshake.

Great! And one less property to set too.

> Also, it allows to exclude changes in the LdapCtx class.
> 
> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/

You will also need to update the CSR to remove the connection timeout 
property.

Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in 
the java.naming module-info file as was done for other properties in 
Daniel's recent RFR, once he has pushed it [1].

* src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java

It looks like there is a possibility of deadlock if 
getTlsServerCertificate() is called before handshakeCompleted(). In that 
case the lock could be obtained first and the thread would end up 
holding the lock and waiting forever.

Here are a few other mostly minor comments on the code:

* 
src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java

   61          * Channel binding on the base of TLS Finished message

I think you mean to say "basis", not "base". Same comment on line 65.

   87                 throw new NamingException( "Channel binding type " +

Remove extra space before "Channel.

  114      * Construct tls-server-point-point Channel Binding data

Typo: "point-point" -> "end-point".

* 
src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java


  380         // LDAP TLS Channel Binding requires 
CHANNEL_BINDING_AF_UNSPEC address type
  381         // for unspecified initiator and acceptor addresses
  382         // CHANNEL_BINDING_AF_NULL_ADDR value should be used for 
unspecified address
  383         // in all other cases

This would read better if there were periods at the end of each sentence 
on lines 381 and 383. The same comment applies to the comment block on 
lines 207-210 in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c

--Sean

[1] https://mail.openjdk.java.net/pipermail/net-dev/2020-July/014148.html
> 
> Regards
> Alexey
> 
>> On 7 Jul 2020, at 02:30, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> Thanks for that extra info.
>>
>> I think it would be much cleaner to avoid having to set that property and instead start the handshake synchronously if the "com.sun.jndi.ldap.tls.cbtype" property is set. This way only one property needs to be set and you don't need to guess what an acceptable value is for the timeout property, which could also cause the connection to be interrupted before the TLS handshake is complete if you use too small of a value.
>>
>> Or better yet, there may be another way to do this with JSSE where you wait for the TLS connection to complete. I'll ask my team and get back to you.
>>
>> --Sean
>>
>>
>> On 7/6/20 6:06 PM, Aleks Efimov wrote:
>>> Hi Sean,
>>> Alexey answered the same question for me:
>>>> I mean ?com.sun.jndi.ldap.connect.timeout? property.
>>>> The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds:
>>>> Connection.java
>>>>>> if (connectTimeout > 0) {
>>>>>>      int socketTimeout = sslSocket.getSoTimeout();
>>>>>>      sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value
>>>>>>      sslSocket.startHandshake();
>>>>>>      sslSocket.setSoTimeout(socketTimeout);
>>>>>> }
>>>> Without this property handshake is started later asynchronously.
>>>> As result
>>>>>>     certs = ssock.getSession().getPeerCertificates();
>>>> in the LdapClient.java could return SSLPeerUnverifiedException().
>>>> This exception will be wrapped to NamingException and thrown to application.
>>>>
>>>> This is not usually happens but I saw it on the slow connection
>>> The full context of LDAP Connection code that initiates the SSL handshake could be viewed here:
>>> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345
>>> -- Aleksei
>>> On 06/07/2020 21:11, Sean Mullan wrote:
>>>> Hi Alexey,
>>>>
>>>> This may have been discussed already, but can you explain why the "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to use this feature? That property is mostly used in tests to avoid long socket timeouts, etc.
>>>>
>>>> Why does that need to be set? What problem are you trying to solve?
>>>>
>>>> --Sean
>>>>
>>>>
>>>> On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
>>>>>
>>>>>> I would suggest removing it. At least for the SASL GSS-API mech, it seems the GSSContext object will not be leaked and no one has a chance to call setChannelBinding again on it.
>>>>>>
>>>>>> There is no spec saying setChannelBinding() can only be called once, so I'd rather we don't enforce that, although you might say there is no need to call it twice.
>>>>>
>>>>> OK.
>>>>> GSSContextImpl class is removed from patch.
>>>>>
>>>>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
>>>>>
>>>>> Thank you
>>>>> Alexey
>>>>>
> 

From andy.herrick at oracle.com  Wed Jul  8 13:59:46 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 8 Jul 2020 09:59:46 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
 <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>
Message-ID: <312cfde4-afc4-83b9-9e51-85b0a9f5b47f@oracle.com>

After further discussion, I approve this change as is.

The main fatal error in Arguments.processArguments() only calls 
Log.error if not verbose , so guarding it from having a timestamp when 
verbose is not an issue.

/Andy

On 7/7/2020 7:20 PM, Andy Herrick wrote:
> I agree - but I would rather then that Log.error() never show timestamp.
>
> It would be better still if we could differentiate fatal error 
> messages from warning messages - right now we are using Log.error for 
> both.
>
> /Andy
>
>
> On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
>> Hi Andy,
>>
>> Timestamps for error message without verbose output are meaningless 
>> in my opinion. This is why I did not add them. Also, in some cases 
>> output does not look right. For example when timestamp is added to 
>> error message always:
>> jpackage --someoption
>> WARNING: Using incubator modules: jdk.incubator.jpackage
>> [15:49:23.798] Error: Invalid Option: [--someoption]
>>
>> In example above I do not see any point to have timestamp.
>>
>> Thanks,
>> Alexander
>>
>> On 7/7/20 6:18 AM, Andy Herrick wrote:
>>> All looks good, except maybe Log.error().
>>>
>>> I think Log.error() should have the same output whether verbose or 
>>> not, adding timestamp to the message only if verbose does not look 
>>> right.
>>>
>>> Problem is that Log.error() is used for two fundamentally different 
>>> purposes:
>>>
>>> 1.) by Main and Arguments to display the final error message when 
>>> jpackage is failing.
>>>
>>> 2.) by everyone else to display a serious warning message when 
>>> jpackage is continuing (sometimes failing further on, and sometimes 
>>> not).
>>>
>>> I wouldn't mind adding timestamps only when verbose in case (2), but 
>>> I don't think that's appropriate for case (1).
>>>
>>> /ANdy
>>>
>>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>>
>>>> Thanks,
>>>> Alexander
>>

From andy.herrick at oracle.com  Wed Jul  8 14:34:30 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 8 Jul 2020 10:34:30 -0400
Subject: RFR: JDK-8247779 Remove deprecated --bind-services option from
 jpackage
Message-ID: <c3447ae9-cdea-9a09-d16c-ffde41cf8404@oracle.com>

Please review change at [1] to issue [2] removing the "--bind-services" 
option from jpackage.

/Andy


[1] http://cr.openjdk.java.net/~herrick/8248864/webrev.01/

[2] https://bugs.openjdk.java.net/browse/JDK-8247779


From daniel.fuchs at oracle.com  Wed Jul  8 14:41:22 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Jul 2020 15:41:22 +0100
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
Message-ID: <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>

Thanks Sean, Alexey,

On 08/07/2020 13:25, Sean Mullan wrote:
>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/
> 
> You will also need to update the CSR to remove the connection timeout 
> property.
> 
> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in 
> the java.naming module-info file as was done for other properties in 
> Daniel's recent RFR, once he has pushed it [1].

I have pushed the fix:
https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779

Alexey, you should now be able to document your new 
"com.sun.jndi.ldap.tls.cbtype"
property in that @implNote as well, and update your CSR
consequently.

> 
> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
> 
> It looks like there is a possibility of deadlock if 
> getTlsServerCertificate() is called before handshakeCompleted(). In that 
> case the lock could be obtained first and the thread would end up 
> holding the lock and waiting forever.

I also have a concern with the use of wait/notify in that code.
I would suggest prototyping using a CompletableFuture instead
(or can new certificates be exchanged later on the same
  connection?)

CompletableFuture would allow you to relay and propagate any
exception raised in the callback handler as well, and would
avoid running into deadlocks.

best regards,

-- daniel


From bob.vandette at oracle.com  Wed Jul  8 15:19:42 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 8 Jul 2020 11:19:42 -0400
Subject: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles
Message-ID: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>

Please review this RFE for JDK 16 that reduces a class dependency in the MethodHandles.Lookup class.

The ensureInitialized method from MethodHandles.Lookup creates a transient MemberName object only
to be used to throw an exception. This exception can be created in a more efficient manner without
using this class reducing the number of classes required. This reduction in dependencies is beneficial
to the GraalVM native-image tool and will be useful for future Leyden native image implementations. 

RFE:

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

WEBREV:

http://cr.openjdk.java.net/~bobv/8249080/webrev.01/

Bob.


From mandy.chung at oracle.com  Wed Jul  8 16:08:59 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Jul 2020 09:08:59 -0700
Subject: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles
In-Reply-To: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>
References: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>
Message-ID: <d1d67739-d2b0-50ed-223b-b4d884871b95@oracle.com>



On 7/8/20 8:19 AM, Bob Vandette wrote:
> Please review this RFE for JDK 16 that reduces a class dependency in the MethodHandles.Lookup class.
>
> The ensureInitialized method from MethodHandles.Lookup creates a transient MemberName object only
> to be used to throw an exception. This exception can be created in a more efficient manner without
> using this class reducing the number of classes required. This reduction in dependencies is beneficial
> to the GraalVM native-image tool and will be useful for future Leyden native image implementations.

I agree that Lookup::ensureInitialized should not depend MemberName.? 
This refactoring seems a reasonable approach.

> RFE:
>
> https://bugs.openjdk.java.net/browse/JDK-8249080
>
> WEBREV:
>
> http://cr.openjdk.java.net/~bobv/8249080/webrev.01/
>
3537???????? /**
3538????????? * Perform necessary <a 
href="MethodHandles.Lookup.html#secmgr">access checks</a>
3539????????? * for findClass or accessClass.
3540????????? */

This should also mention `ensureInitialized`.

3578???????????? if (m == null) {
3579???????????? // Step 2b:
3580???????????????? if (!fullPowerLookup) {
3581 smgr.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
3582???????????????? }
3583???????????????? return;
3584???????????? }

This is no longer needed.? Instead, this method should require a 
non-null MemberName argument.

Mandy

From alexey.semenyuk at oracle.com  Wed Jul  8 16:18:14 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 8 Jul 2020 12:18:14 -0400
Subject: RFR: JDK-8247779 Remove deprecated --bind-services option from
 jpackage
In-Reply-To: <c3447ae9-cdea-9a09-d16c-ffde41cf8404@oracle.com>
References: <c3447ae9-cdea-9a09-d16c-ffde41cf8404@oracle.com>
Message-ID: <752d2a2c-9e0e-df69-66cd-bf23df4a7ac1@oracle.com>

Looks good.

- Alexey

On 7/8/2020 10:34 AM, Andy Herrick wrote:
> Please review change at [1] to issue [2] removing the 
> "--bind-services" option from jpackage.
>
> /Andy
>
>
> [1] http://cr.openjdk.java.net/~herrick/8248864/webrev.01/
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8247779
>


From alexey.semenyuk at oracle.com  Wed Jul  8 16:34:07 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 8 Jul 2020 12:34:07 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <312cfde4-afc4-83b9-9e51-85b0a9f5b47f@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
 <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>
 <312cfde4-afc4-83b9-9e51-85b0a9f5b47f@oracle.com>
Message-ID: <8964d112-015c-e376-3900-b01b8406bcd0@oracle.com>

I still think it would be good to create dedicated method for final 
error reporting in Main and Arguments classes without timestamps.

- Alexey

On 7/8/2020 9:59 AM, Andy Herrick wrote:
> After further discussion, I approve this change as is.
>
> The main fatal error in Arguments.processArguments() only calls 
> Log.error if not verbose , so guarding it from having a timestamp when 
> verbose is not an issue.
>
> /Andy
>
> On 7/7/2020 7:20 PM, Andy Herrick wrote:
>> I agree - but I would rather then that Log.error() never show timestamp.
>>
>> It would be better still if we could differentiate fatal error 
>> messages from warning messages - right now we are using Log.error for 
>> both.
>>
>> /Andy
>>
>>
>> On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
>>> Hi Andy,
>>>
>>> Timestamps for error message without verbose output are meaningless 
>>> in my opinion. This is why I did not add them. Also, in some cases 
>>> output does not look right. For example when timestamp is added to 
>>> error message always:
>>> jpackage --someoption
>>> WARNING: Using incubator modules: jdk.incubator.jpackage
>>> [15:49:23.798] Error: Invalid Option: [--someoption]
>>>
>>> In example above I do not see any point to have timestamp.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 7/7/20 6:18 AM, Andy Herrick wrote:
>>>> All looks good, except maybe Log.error().
>>>>
>>>> I think Log.error() should have the same output whether verbose or 
>>>> not, adding timestamp to the message only if verbose does not look 
>>>> right.
>>>>
>>>> Problem is that Log.error() is used for two fundamentally different 
>>>> purposes:
>>>>
>>>> 1.) by Main and Arguments to display the final error message when 
>>>> jpackage is failing.
>>>>
>>>> 2.) by everyone else to display a serious warning message when 
>>>> jpackage is continuing (sometimes failing further on, and sometimes 
>>>> not).
>>>>
>>>> I wouldn't mind adding timestamps only when verbose in case (2), 
>>>> but I don't think that's appropriate for case (1).
>>>>
>>>> /ANdy
>>>>
>>>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>>>> Please review the jpackage fix for bug [1] at [2].
>>>>>
>>>>> Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>


From bob.vandette at oracle.com  Wed Jul  8 16:40:59 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 8 Jul 2020 12:40:59 -0400
Subject: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles
In-Reply-To: <d1d67739-d2b0-50ed-223b-b4d884871b95@oracle.com>
References: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>
 <d1d67739-d2b0-50ed-223b-b4d884871b95@oracle.com>
Message-ID: <F53BD4A8-4FB7-4DB5-B65D-9D94CC7763BC@oracle.com>



> On Jul 8, 2020, at 12:08 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 7/8/20 8:19 AM, Bob Vandette wrote:
>> Please review this RFE for JDK 16 that reduces a class dependency in the MethodHandles.Lookup class.
>> 
>> The ensureInitialized method from MethodHandles.Lookup creates a transient MemberName object only
>> to be used to throw an exception. This exception can be created in a more efficient manner without
>> using this class reducing the number of classes required. This reduction in dependencies is beneficial
>> to the GraalVM native-image tool and will be useful for future Leyden native image implementations. 
>> 
> 
> I agree that Lookup::ensureInitialized should not depend MemberName.  This refactoring seems a reasonable approach.
> 
>> RFE:
>> 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8249080
>> 
>> 
>> WEBREV:
>> 
>> 
>> http://cr.openjdk.java.net/~bobv/8249080/webrev.01/
>> 
>> 
>> 
> 3537         /**
> 3538          * Perform necessary <a href="MethodHandles.Lookup.html#secmgr">access checks</a>
> 3539          * for findClass or accessClass.
> 3540          */
> 
> This should also mention `ensureInitialized`.  

Ok.

> 
> 3578             if (m == null) {
> 3579             // Step 2b:
> 3580                 if (!fullPowerLookup) {
> 3581                     smgr.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
> 3582                 }
> 3583                 return;
> 3584             }
> 
> This is no longer needed.  Instead, this method should require a non-null MemberName argument.

I was going to remove the null check but was concerned that there might be other cases where the argument 
might be null.

Should I add an assert or just let the NPE happen?

Bob.


> 
> Mandy


From Roger.Riggs at oracle.com  Wed Jul  8 16:45:26 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2020 12:45:26 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
Message-ID: <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>

Hi Rafaello,

Since you have expanded the scope of the fix, you will need to update 
the bug to
include the other changes you are making.? Or create a new issue for the 
additional work.

Personal preference in style has very little place when maintaining 
existing code.
The style should match the existing code.

There is little correspondence between the existing code and the new 
code that
it make is more difficult to determine that they are equivalent.

The messages in the exceptions should not be changed without a 
compelling reason.
1014: It would be more informative to include the rogue character in the 
message than to drop it.
As is, it gives some indication what's wrong about the end.

Grautituous changes such as changing the condition in 979 are unnecessary.

The change from using "eof" to "eos" is unconventional for IO streams 
and unnecessary.

The note about allowing limit to overflow to MIN_VALUE is informative 
but it would
be better to avoid it and keep a future maintainer from falling into the 
trap.

Regards, Roger

On 7/6/20 4:48 PM, Raffaello Giulietti wrote:
> Hi Roger,
>
> the structure of the original design is preserved, the details change 
> with the intent of having code that is easier to reason about.
>
> The main loop has many exit points in the original code, as well as in 
> the new code. For this reason, I prefer not to express it as a while 
> or as a counted for loop. That's why it has the for (;;) form, which 
> promptly warns that more exit points at unusual positions should be 
> expected.
>
> The "Illegal base64 character" IOException in the original code is 
> wrong, probably due to oversight. That's why the new code has two 
> vars, namely i and v, to convey more meaningful diagnostic.
>
> The new code keeps track of only one running variable pos instead of 
> the original two vars off and len, wit?out using more live variables 
> for this purpose. Less mutating vars help keeping the code simpler. 
> The method has only one mutating var.
>
> With the use of writing and reading bit positions fields wpos and 
> rpos, checking when a byte in field bits is ready means testing rpos - 
> 8 >= wpos.
>
> I can add more comments, e.g., in the form of Dijkstra/Hoare-style 
> loop invariants, if this helps improving confidence. Or I can add 
> constant-guarded assertions to the proposed code instead of just 
> comments. Or both.
>
>
>
> There's nothing I can find in the coding convention [1] about block 
> comments that states that continuation lines must start with the 
> asterisk *, although the examples do so. While I find these asterisks 
> quite distracting, it would be a trivial matter to add them in the 
> next review iteration.
>
> The end-of-line comments either comply with the rules in [1] or, in 
> the description of the fields, have been inadvertently "inherited" as 
> multiple lines from the original code. I will of course correct them 
> there in the next review iteration.
>
>
> Greetings
> Raffaello
>
> ----
>
> [1] 
> https://www.oracle.com/java/technologies/javase/codeconventions-comments.html
>
>
> On 2020-07-06 20:17, Roger Riggs wrote:
>> Hi Raffaello,
>>
>> I'm still not sure it needed this much of a re-write to fix the bug;
>> It will take some time to look at the changes.
>>
>> Regardless, OpenJDK conventions call for following the style of the 
>> existing code.
>> Your new comments follow neither the existing convention to use 
>> "//..." comments
>> nor the other prevalent comment form using /*... */ which use 
>> consistent indentation
>> and "* " on continuation lines.
>>
>> Regards, Roger
>>
>>
>> On 7/3/20 11:48 AM, Raffaello Giulietti wrote:
>>> Hello,
>>>
>>> after Roger's notes, which escaped my attention before, I've 
>>> withdrawn all the changes but for DecInputStream, *except* that I 
>>> couldn't resist to simplify the maths in encodedOutLength(), while 
>>> still using xxxExact() arithmetic.
>>>
>>> Sorry for the confusion
>>> Raffaello
>>>
>>>
>>>
>>>> Hi Raffaello,
>>>>
>>>> There is way more code changed here than is needed to fix the bug.
>>>> General enhancement should be separated from bug fixes.
>>>> It makes it easier to review to see the bug was fixed
>>>> and easier to separately review other code to see that there are no 
>>>> unexpected changes.
>>>>
>>>> If some of the changes are motivated by expected performance 
>>>> improvements,
>>>> there should be JMH tests comparing the before and after.
>>>> The change to use byte arrays seems useful, but even using char[]
>>>> there is little danger of cache thrashing.
>>>>
>>>> If using the code using xxxExact was correct, don't change it.
>>>> Those methods are intrinsified and perform as well or better than 
>>>> using long.
>>>> Usually, it is better to leave code alone and not risk breaking it.
>>>>
>>>> Special care needs taken when changing a method that is intrinsified.
>>>> The optimized version may use fields of the object and stop
>>>> working if they are changed.
>>>>
>>>> In the test, the range of buffer sizes tests seems to waste a lot
>>>> of cycles on sizes greater than the encoded size of the input.
>>>>
>>>> Regards, Roger
>>>
>>>
>>> ---------------------
>>>
>>> # HG changeset patch
>>> # User lello
>>> # Date 1593790152 -7200
>>> #????? Fri Jul 03 17:29:12 2020 +0200
>>> # Node ID 73370832de1d2bf3b450930f5cb2467e10528c69
>>> # Parent? a7c0307232406c7b0c1a4b8c2de111077848203d
>>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes 
>>> at the end
>>> Reviewed-by: TBD
>>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>>>
>>> diff --git a/src/java.base/share/classes/java/util/Base64.java 
>>> b/src/java.base/share/classes/java/util/Base64.java
>>> --- a/src/java.base/share/classes/java/util/Base64.java
>>> +++ b/src/java.base/share/classes/java/util/Base64.java
>>> @@ -255,14 +255,11 @@
>>> ????????? *
>>> ????????? */
>>> ???????? private final int encodedOutLength(int srclen, boolean 
>>> throwOOME) {
>>> -??????????? int len = 0;
>>> +??????????? int len;
>>> ???????????? try {
>>> -??????????????? if (doPadding) {
>>> -??????????????????? len = Math.multiplyExact(4, 
>>> (Math.addExact(srclen, 2) / 3));
>>> -??????????????? } else {
>>> -??????????????????? int n = srclen % 3;
>>> -??????????????????? len = Math.addExact(Math.multiplyExact(4, 
>>> (srclen / 3)), (n == 0 ? 0 : n + 1));
>>> -??????????????? }
>>> +??????????????? len = doPadding
>>> +??????????????????????? ? Math.multiplyExact(4, 
>>> (Math.addExact(srclen, 2) / 3))
>>> +??????????????????????? : Math.addExact((Math.addExact(srclen, 2) / 
>>> 3), srclen);
>>> ???????????????? if (linemax > 0) { // line separators
>>> ???????????????????? len = Math.addExact(len, (len - 1) / linemax * 
>>> newline.length);
>>> ???????????????? }
>>> @@ -961,14 +958,15 @@
>>>
>>> ???????? private final InputStream is;
>>> ???????? private final boolean isMIME;
>>> -??????? private final int[] base64;????? // base64 -> byte mapping
>>> -??????? private int bits = 0;??????????? // 24-bit buffer for decoding
>>> -??????? private int nextin = 18;???????? // next available "off" in 
>>> "bits" for input;
>>> -???????????????????????????????????????? // -> 18, 12, 6, 0
>>> -??????? private int nextout = -8;??????? // next available "off" in 
>>> "bits" for output;
>>> -???????????????????????????????????????? // -> 8, 0, -8 (no byte 
>>> for output)
>>> -??????? private boolean eof = false;
>>> -??????? private boolean closed = false;
>>> +??????? private final int[] base64;???? // mapping from alphabet to 
>>> values
>>> +??????? private int bits;?????????????? // 24 bit buffer for decoding
>>> +??????? private int wpos;?????????????? // writing bit pos inside bits
>>> +??????? // one of 24 (left, msb), 18, 12, 6, 0
>>> +??????? private int rpos;?????????????? // reading bit pos inside bits
>>> +??????? // one of 24 (left, msb), 16, 8, 0
>>> +??????? private boolean eos;
>>> +??????? private boolean closed;
>>> +??????? private byte[] onebuf = new byte[1];
>>>
>>> ???????? DecInputStream(InputStream is, int[] base64, boolean isMIME) {
>>> ???????????? this.is = is;
>>> @@ -976,114 +974,158 @@
>>> ???????????? this.isMIME = isMIME;
>>> ???????? }
>>>
>>> -??????? private byte[] sbBuf = new byte[1];
>>> -
>>> ???????? @Override
>>> ???????? public int read() throws IOException {
>>> -??????????? return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>>> +??????????? return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
>>> +??????? }
>>> +
>>> +??????? private int leftovers(byte[] b, int off, int pos, int limit) {
>>> +??????????? eos = true;
>>> +??????????? /*
>>> +??????????? We use a loop here, as this code is executed only once.
>>> +??????????? Unrolling the loop would probably not contribute much 
>>> here.
>>> +???????????? */
>>> +??????????? while (rpos - 8 >= wpos && pos != limit) {
>>> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
>>> +??????????? }
>>> +??????????? return pos - off != 0 || rpos - 8 >= wpos ? pos - off : 
>>> -1;
>>> ???????? }
>>>
>>> -??????? private int eof(byte[] b, int off, int len, int oldOff)
>>> -??????????? throws IOException
>>> -??????? {
>>> -??????????? eof = true;
>>> -??????????? if (nextin != 18) {
>>> -??????????????? if (nextin == 12)
>>> -??????????????????? throw new IOException("Base64 stream has one 
>>> un-decoded dangling byte.");
>>> -??????????????? // treat ending xx/xxx without padding character 
>>> legal.
>>> -??????????????? // same logic as v == '=' below
>>> -??????????????? b[off++] = (byte)(bits >> (16));
>>> -??????????????? if (nextin == 0) {?????????? // only one padding byte
>>> -??????????????????? if (len == 1) {????????? // no enough output space
>>> -??????????????????????? bits >>= 8;????????? // shift to lowest byte
>>> -??????????????????????? nextout = 0;
>>> -??????????????????? } else {
>>> -??????????????????????? b[off++] = (byte) (bits >>? 8);
>>> -??????????????????? }
>>> -??????????????? }
>>> +??????? private int eos(byte[] b, int off, int pos, int limit) 
>>> throws IOException {
>>> +??????????? /*
>>> +??????????? wpos == 18: x???? dangling single x, invalid unit
>>> +??????????? accept ending xx or xxx without padding characters
>>> +???????????? */
>>> +??????????? if (wpos == 18) {
>>> +??????????????? throw new IOException("Base64 stream has one 
>>> un-decoded dangling byte");
>>> ???????????? }
>>> -??????????? return off == oldOff ? -1 : off - oldOff;
>>> +??????????? rpos = 24;
>>> +??????????? return leftovers(b, off, pos, limit);
>>> ???????? }
>>>
>>> -??????? private int padding(byte[] b, int off, int len, int oldOff)
>>> -??????????? throws IOException
>>> -??????? {
>>> -??????????? // =???? shiftto==18 unnecessary padding
>>> -??????????? // x=??? shiftto==12 dangling x, invalid unit
>>> -??????????? // xx=?? shiftto==6 && missing last '='
>>> -??????????? // xx=y? or last is not '='
>>> -??????????? if (nextin == 18 || nextin == 12 ||
>>> -??????????????? nextin == 6 && is.read() != '=') {
>>> -??????????????? throw new IOException("Illegal base64 ending 
>>> sequence:" + nextin);
>>> +??????? private int padding(byte[] b, int off, int pos, int limit) 
>>> throws IOException {
>>> +??????????? /*
>>> +??????????? wpos == 24: =??? (unnecessary padding)
>>> +??????????? wpos == 18: x=?? (dangling single x, invalid unit)
>>> +??????????? wpos == 12 and missing last '=': xx=? (invalid padding)
>>> +??????????? wpos == 12 and last is not '=': xx=x (invalid padding)
>>> +???????????? */
>>> +??????????? if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>>> +??????????????? throw new IOException("Illegal base64 ending 
>>> sequence");
>>> ???????????? }
>>> -??????????? b[off++] = (byte)(bits >> (16));
>>> -??????????? if (nextin == 0) {?????????? // only one padding byte
>>> -??????????????? if (len == 1) {????????? // no enough output space
>>> -??????????????????? bits >>= 8;????????? // shift to lowest byte
>>> -??????????????????? nextout = 0;
>>> -??????????????? } else {
>>> -??????????????????? b[off++] = (byte) (bits >>? 8);
>>> -??????????????? }
>>> -??????????? }
>>> -??????????? eof = true;
>>> -??????????? return off - oldOff;
>>> +??????????? rpos = 24;
>>> +??????????? return leftovers(b, off, pos, limit);
>>> ???????? }
>>>
>>> ???????? @Override
>>> ???????? public int read(byte[] b, int off, int len) throws 
>>> IOException {
>>> -??????????? if (closed)
>>> +??????????? if (closed) {
>>> ???????????????? throw new IOException("Stream is closed");
>>> -??????????? if (eof && nextout < 0)??? // eof and no leftover
>>> -??????????????? return -1;
>>> -??????????? if (off < 0 || len < 0 || len > b.length - off)
>>> -??????????????? throw new IndexOutOfBoundsException();
>>> -??????????? int oldOff = off;
>>> -??????????? while (nextout >= 0) {?????? // leftover output byte(s) 
>>> in bits buf
>>> -??????????????? if (len == 0)
>>> -??????????????????? return off - oldOff;
>>> -??????????????? b[off++] = (byte)(bits >> nextout);
>>> -??????????????? len--;
>>> -??????????????? nextout -= 8;
>>> +??????????? }
>>> +??????????? Objects.checkFromIndexSize(off, len, b.length);
>>> +??????????? if (len == 0) {
>>> +??????????????? return 0;
>>> ???????????? }
>>> -??????????? bits = 0;
>>> -??????????? while (len > 0) {
>>> -??????????????? int v = is.read();
>>> -??????????????? if (v == -1) {
>>> -??????????????????? return eof(b, off, len, oldOff);
>>> +
>>> +??????????? /*
>>> +??????????? Rather than keeping 2 running vars (e.g., off and len), 
>>> we only
>>> +??????????? keep one (pos), while definitely fixing the boundaries 
>>> of the range
>>> +??????????? [off, limit).
>>> +
>>> +??????????? Note that limit can overflow to Integer.MIN_VALUE. 
>>> However, as long
>>> +??????????? as comparisons with pos are done as coded, there's no 
>>> harm.
>>> +
>>> +??????????? In addition, limit - off (= len) is used from here on, 
>>> so the
>>> +??????????? location for len can be reallocated to other vars 
>>> (e.g., limit).
>>> +???????????? */
>>> +??????????? int pos = off;
>>> +??????????? int limit = off + len;
>>> +??????????? if (eos) {
>>> +??????????????? return leftovers(b, off, pos, limit);
>>> +??????????? }
>>> +
>>> +??????????? /*
>>> +??????????? leftovers from previous invocation; here, wpos = 0.
>>> +??????????? There can be at most 2 leftover bytes (rpos <= 16).
>>> +??????????? Further, the buffer b has at least one free place.
>>> +
>>> +??????????? The logic could be coded as a loop, (as in method 
>>> leftovers())
>>> +??????????? but the explicit "unrolling" makes it possible to 
>>> generate better
>>> +??????????? byte extraction code.
>>> +???????????? */
>>> +??????????? if (rpos == 16) {
>>> +??????????????? b[pos++] = (byte) (bits >> 8);
>>> +??????????????? rpos = 8;
>>> +??????????????? if (pos == limit) {
>>> +??????????????????? return limit - off;
>>> ???????????????? }
>>> -??????????????? if ((v = base64[v]) < 0) {
>>> -??????????????????? if (v == -2) {?????? // padding byte(s)
>>> -??????????????????????? return padding(b, off, len, oldOff);
>>> -??????????????????? }
>>> -??????????????????? if (v == -1) {
>>> -??????????????????????? if (!isMIME)
>>> -??????????????????????????? throw new IOException("Illegal base64 
>>> character " +
>>> -??????????????????????????????? Integer.toString(v, 16));
>>> -??????????????????????? continue;??????? // skip if for rfc2045
>>> -??????????????????? }
>>> -??????????????????? // neve be here
>>> -??????????????? }
>>> -??????????????? bits |= (v << nextin);
>>> -??????????????? if (nextin == 0) {
>>> -??????????????????? nextin = 18;???????? // clear for next in
>>> -??????????????????? b[off++] = (byte)(bits >> 16);
>>> -??????????????????? if (len == 1) {
>>> -??????????????????????? nextout = 8;??? // 2 bytes left in bits
>>> -??????????????????????? break;
>>> -??????????????????? }
>>> -??????????????????? b[off++] = (byte)(bits >> 8);
>>> -??????????????????? if (len == 2) {
>>> -??????????????????????? nextout = 0;??? // 1 byte left in bits
>>> -??????????????????????? break;
>>> -??????????????????? }
>>> -??????????????????? b[off++] = (byte)bits;
>>> -??????????????????? len -= 3;
>>> -??????????????????? bits = 0;
>>> -??????????????? } else {
>>> -??????????????????? nextin -= 6;
>>> +??????????? }
>>> +??????????? if (rpos == 8) {
>>> +??????????????? b[pos++] = (byte) bits;
>>> +??????????????? rpos = 0;
>>> +??????????????? if (pos == limit) {
>>> +??????????????????? return limit - off;
>>> ???????????????? }
>>> ???????????? }
>>> -??????????? return off - oldOff;
>>> + 8222187
>>> +??????????? bits = 0;
>>> +??????????? wpos = 24;
>>> +??????????? for (;;) {
>>> +??????????????? // Here, pos != limit
>>> +??????????????? int i = is.read();
>>> +??????????????? if (i < 0) {
>>> +??????????????????? return eos(b, off, pos, limit);
>>> +??????????????? }
>>> +??????????????? int v = base64[i];
>>> +??????????????? if (v < 0) {
>>> +??????????????????? /*
>>> +??????????????????? i not in alphabet, thus
>>> +??????????????????????? v = -2: i is '=', the padding
>>> +??????????????????????? v = -1: i is something else, e.g., CR or LF
>>> +???????????????????? */
>>> +??????????????????? if (v == -1) {
>>> +??????????????????????? if (isMIME) {
>>> +??????????????????????????? continue;
>>> +??????????????????????? }
>>> +??????????????????????? throw new IOException("Illegal base64 byte 
>>> 0x" +
>>> +??????????????????????????????? Integer.toHexString(i));
>>> +??????????????????? }
>>> +??????????????????? return padding(b, off, pos, limit);
>>> +??????????????? }
>>> +??????????????? bits |= (v << (wpos -= 6));
>>> +??????????????? if (wpos != 0) {
>>> +??????????????????? continue;
>>> +??????????????? }
>>> +??????????????? if (limit - pos >= 3) {
>>> +??????????????????? // frequently taken fast path, no need to track 
>>> rpos
>>> +??????????????????? b[pos++] = (byte) (bits >> 16);
>>> +??????????????????? b[pos++] = (byte) (bits >> 8);
>>> +??????????????????? b[pos++] = (byte) bits;
>>> +??????????????????? bits = 0;
>>> +??????????????????? wpos = 24;
>>> +??????????????????? if (pos == limit) {
>>> +??????????????????????? return limit - off;
>>> +??????????????????? }
>>> +??????????????????? continue;
>>> +??????????????? }
>>> +??????????????? /*
>>> +??????????????? Here, buffer b has either 1 or 2 free places, that is,
>>> +??????????????? limit - pos = 1 or limit - pos = 2.
>>> +
>>> +??????????????? As above, this could be coded as a loop. But since the
>>> +??????????????? shift lengths are explicit multiples of 8, better 
>>> code can be
>>> +??????????????? probably generated.
>>> +???????????????? */
>>> +??????????????? b[pos++] = (byte) (bits >> 16);
>>> +??????????????? if (pos == limit) {
>>> +??????????????????? rpos = 16;
>>> +??????????????????? return limit - off;
>>> +??????????????? }
>>> +??????????????? b[pos++] = (byte) (bits >> 8);
>>> +??????????????? // Here, pos = limit, no need for an if.
>>> +??????????????? rpos = 8;
>>> +??????????????? return limit - off;
>>> +??????????? }
>>> ???????? }
>>>
>>> ???????? @Override
>>> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
>>> b/test/jdk/java/util/Base64/TestBase64.java
>>> --- a/test/jdk/java/util/Base64/TestBase64.java
>>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>>> @@ -144,6 +144,10 @@
>>> ???????? testDecoderKeepsAbstinence(Base64.getDecoder());
>>> ???????? testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>>> ???????? testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>>> +
>>> +??????? // tests patch addressing JDK-8222187
>>> +??????? // https://bugs.openjdk.java.net/browse/JDK-8222187
>>> +??????? testJDK_8222187();
>>> ???? }
>>>
>>> ???? private static void test(Base64.Encoder enc, Base64.Decoder dec,
>>> @@ -607,4 +611,26 @@
>>> ???????????? }
>>> ???????? }
>>> ???? }
>>> +
>>> +??? private static void testJDK_8222187() throws Throwable {
>>> +??????? byte[] orig = "12345678".getBytes("US-ASCII");
>>> +??????? byte[] encoded = Base64.getEncoder().encode(orig);
>>> +??????? // decode using different buffer sizes
>>> +??????? for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
>>> bufferSize++) {
>>> +??????????? try (
>>> +??????????????????? InputStream in = Base64.getDecoder().wrap(
>>> +??????????????????????????? new ByteArrayInputStream(encoded));
>>> +??????????????????? ByteArrayOutputStream baos = new 
>>> ByteArrayOutputStream();
>>> +??????????? ) {
>>> +??????????????? byte[] buffer = new byte[bufferSize];
>>> +??????????????? int read;
>>> +??????????????? while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>>> +??????????????????? baos.write(buffer, 0, read);
>>> +??????????????? }
>>> +??????????????? // compare result, output info if lengths do not match
>>> +??????????????? byte[] decoded = baos.toByteArray();
>>> +??????????????? checkEqual(decoded, orig, "Base64 stream decoding 
>>> failed!");
>>> +??????????? }
>>> +??????? }
>>> +??? }
>>> ?}
>>


From mandy.chung at oracle.com  Wed Jul  8 17:01:03 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Jul 2020 10:01:03 -0700
Subject: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles
In-Reply-To: <F53BD4A8-4FB7-4DB5-B65D-9D94CC7763BC@oracle.com>
References: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>
 <d1d67739-d2b0-50ed-223b-b4d884871b95@oracle.com>
 <F53BD4A8-4FB7-4DB5-B65D-9D94CC7763BC@oracle.com>
Message-ID: <a3007fa8-6fa6-074d-41f1-053dc714d7ff@oracle.com>



On 7/8/20 9:40 AM, Bob Vandette wrote:
> Should I add an assert or just let the NPE happen?

What about? Objects.requireNonNull(m);

Mandy

From li.jiang at oracle.com  Wed Jul  8 17:58:43 2020
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Thu, 9 Jul 2020 01:58:43 +0800
Subject: RFR: 8249086: JDK 15 L10n resource file update - msg drop 10
Message-ID: <908f05e3-c319-20dc-e65e-8d93182b6710@oracle.com>

Hi,

Pls review the l10n resource files update for JDK 15 msg drop 10.

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

Webrev:
http://cr.openjdk.java.net/~ljiang/8249086/read/

Thanks,
Leo

From bob.vandette at oracle.com  Wed Jul  8 18:21:51 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 8 Jul 2020 14:21:51 -0400
Subject: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles
In-Reply-To: <a3007fa8-6fa6-074d-41f1-053dc714d7ff@oracle.com>
References: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>
 <d1d67739-d2b0-50ed-223b-b4d884871b95@oracle.com>
 <F53BD4A8-4FB7-4DB5-B65D-9D94CC7763BC@oracle.com>
 <a3007fa8-6fa6-074d-41f1-053dc714d7ff@oracle.com>
Message-ID: <0ADDFBD6-34A0-4EC9-9695-871DFDEE847B@oracle.com>



> On Jul 8, 2020, at 1:01 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 7/8/20 9:40 AM, Bob Vandette wrote:
>> Should I add an assert or just let the NPE happen?
> 
> What about  Objects.requireNonNull(m);

Thanks.

Here?s the updated webrev:

   https://cr.openjdk.java.net/~bobv/8249080/webrev.02/

Bob

> 
> Mandy


From mandy.chung at oracle.com  Wed Jul  8 18:39:12 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Jul 2020 11:39:12 -0700
Subject: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles
In-Reply-To: <0ADDFBD6-34A0-4EC9-9695-871DFDEE847B@oracle.com>
References: <8755BBD2-EBB7-4D7B-9960-3E65F2188C05@oracle.com>
 <d1d67739-d2b0-50ed-223b-b4d884871b95@oracle.com>
 <F53BD4A8-4FB7-4DB5-B65D-9D94CC7763BC@oracle.com>
 <a3007fa8-6fa6-074d-41f1-053dc714d7ff@oracle.com>
 <0ADDFBD6-34A0-4EC9-9695-871DFDEE847B@oracle.com>
Message-ID: <7743a07f-fdb7-b0ca-328a-ab32c0261204@oracle.com>



On 7/8/20 11:21 AM, Bob Vandette wrote:
>
>> On Jul 8, 2020, at 1:01 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>>
>>
>> On 7/8/20 9:40 AM, Bob Vandette wrote:
>>> Should I add an assert or just let the NPE happen?
>> What about  Objects.requireNonNull(m);
> Thanks.
>
> Here?s the updated webrev:
>
>     https://cr.openjdk.java.net/~bobv/8249080/webrev.02/
>
>

line 3580-8383 step 2b should be removed completely.

checkSecurityManager(Class<?> refc, MemberName m) performs step 1, 2a 
and 3 [1]? whereas checkSecurityManager(Class<?> refc) performs step 1 
and 2b only.

It'd be helpful to make it clear in the comment the steps that it performs.

Nit: line 3566: probably better to add Objects.requireNonNull(refc) to 
avoid misinterpreting that refc can be null.

thanks
Mandy
[1] 
https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#secmgr

From raffaello.giulietti at gmail.com  Wed Jul  8 19:50:19 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 8 Jul 2020 21:50:19 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
Message-ID: <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>

Hello Roger,

I would of course retract the changes in encodedOutLength() because, as 
you observe, it is out of scope w.r.t. the bug. I would also retract the 
other minor changes you mention and clean up the appearance of the 
comments to adhere to community shared practices.

Thus, if you think that doing these changes can facilitate my 
contribution to get through the review process, I would be happy to 
prepare another patch.

On the other hand, I see no incentive in dropping the bulk of the new 
working implementation to try to fix the current one. I would not feel 
as confident as I am with the proposed code.

For the sake of completeness and love of experiment, I privately added 
many cherry-picking and kind of self-documenting assertions and tested 
tons of normal and edge cases without troubles.


Greetings
Raffaello



On 2020-07-08 18:45, Roger Riggs wrote:
> Hi Rafaello,
> 
> Since you have expanded the scope of the fix, you will need to update 
> the bug to
> include the other changes you are making.? Or create a new issue for the 
> additional work.
>  > Personal preference in style has very little place when maintaining
> existing code.
> The style should match the existing code.
> 
> There is little correspondence between the existing code and the new 
> code that
> it make is more difficult to determine that they are equivalent.
> 
> The messages in the exceptions should not be changed without a 
> compelling reason.
> 1014: It would be more informative to include the rogue character in the 
> message than to drop it.
> As is, it gives some indication what's wrong about the end.
> 
> Grautituous changes such as changing the condition in 979 are unnecessary.
> 
> The change from using "eof" to "eos" is unconventional for IO streams 
> and unnecessary.
> 
> The note about allowing limit to overflow to MIN_VALUE is informative 
> but it would
> be better to avoid it and keep a future maintainer from falling into the 
> trap.
> 
> Regards, Roger
> 
> On 7/6/20 4:48 PM, Raffaello Giulietti wrote:
>> Hi Roger,
>>
>> the structure of the original design is preserved, the details change 
>> with the intent of having code that is easier to reason about.
>>
>> The main loop has many exit points in the original code, as well as in 
>> the new code. For this reason, I prefer not to express it as a while 
>> or as a counted for loop. That's why it has the for (;;) form, which 
>> promptly warns that more exit points at unusual positions should be 
>> expected.
>>
>> The "Illegal base64 character" IOException in the original code is 
>> wrong, probably due to oversight. That's why the new code has two 
>> vars, namely i and v, to convey more meaningful diagnostic.
>>
>> The new code keeps track of only one running variable pos instead of 
>> the original two vars off and len, wit?out using more live variables 
>> for this purpose. Less mutating vars help keeping the code simpler. 
>> The method has only one mutating var.
>>
>> With the use of writing and reading bit positions fields wpos and 
>> rpos, checking when a byte in field bits is ready means testing rpos - 
>> 8 >= wpos.
>>
>> I can add more comments, e.g., in the form of Dijkstra/Hoare-style 
>> loop invariants, if this helps improving confidence. Or I can add 
>> constant-guarded assertions to the proposed code instead of just 
>> comments. Or both.
>>
>>
>>
>> There's nothing I can find in the coding convention [1] about block 
>> comments that states that continuation lines must start with the 
>> asterisk *, although the examples do so. While I find these asterisks 
>> quite distracting, it would be a trivial matter to add them in the 
>> next review iteration.
>>
>> The end-of-line comments either comply with the rules in [1] or, in 
>> the description of the fields, have been inadvertently "inherited" as 
>> multiple lines from the original code. I will of course correct them 
>> there in the next review iteration.
>>
>>
>> Greetings
>> Raffaello
>>
>> ----
>>
>> [1] 
>> https://www.oracle.com/java/technologies/javase/codeconventions-comments.html 
>>
>>
>>
>> On 2020-07-06 20:17, Roger Riggs wrote:
>>> Hi Raffaello,
>>>
>>> I'm still not sure it needed this much of a re-write to fix the bug;
>>> It will take some time to look at the changes.
>>>
>>> Regardless, OpenJDK conventions call for following the style of the 
>>> existing code.
>>> Your new comments follow neither the existing convention to use 
>>> "//..." comments
>>> nor the other prevalent comment form using /*... */ which use 
>>> consistent indentation
>>> and "* " on continuation lines.
>>>
>>> Regards, Roger
>>>
>>>
>>> On 7/3/20 11:48 AM, Raffaello Giulietti wrote:
>>>> Hello,
>>>>
>>>> after Roger's notes, which escaped my attention before, I've 
>>>> withdrawn all the changes but for DecInputStream, *except* that I 
>>>> couldn't resist to simplify the maths in encodedOutLength(), while 
>>>> still using xxxExact() arithmetic.
>>>>
>>>> Sorry for the confusion
>>>> Raffaello
>>>>
>>>>
>>>>
>>>>> Hi Raffaello,
>>>>>
>>>>> There is way more code changed here than is needed to fix the bug.
>>>>> General enhancement should be separated from bug fixes.
>>>>> It makes it easier to review to see the bug was fixed
>>>>> and easier to separately review other code to see that there are no 
>>>>> unexpected changes.
>>>>>
>>>>> If some of the changes are motivated by expected performance 
>>>>> improvements,
>>>>> there should be JMH tests comparing the before and after.
>>>>> The change to use byte arrays seems useful, but even using char[]
>>>>> there is little danger of cache thrashing.
>>>>>
>>>>> If using the code using xxxExact was correct, don't change it.
>>>>> Those methods are intrinsified and perform as well or better than 
>>>>> using long.
>>>>> Usually, it is better to leave code alone and not risk breaking it.
>>>>>
>>>>> Special care needs taken when changing a method that is intrinsified.
>>>>> The optimized version may use fields of the object and stop
>>>>> working if they are changed.
>>>>>
>>>>> In the test, the range of buffer sizes tests seems to waste a lot
>>>>> of cycles on sizes greater than the encoded size of the input.
>>>>>
>>>>> Regards, Roger
>>>>
>>>>
>>>> ---------------------
>>>>
>>>> # HG changeset patch
>>>> # User lello
>>>> # Date 1593790152 -7200
>>>> #????? Fri Jul 03 17:29:12 2020 +0200
>>>> # Node ID 73370832de1d2bf3b450930f5cb2467e10528c69
>>>> # Parent? a7c0307232406c7b0c1a4b8c2de111077848203d
>>>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes 
>>>> at the end
>>>> Reviewed-by: TBD
>>>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>>>>
>>>> diff --git a/src/java.base/share/classes/java/util/Base64.java 
>>>> b/src/java.base/share/classes/java/util/Base64.java
>>>> --- a/src/java.base/share/classes/java/util/Base64.java
>>>> +++ b/src/java.base/share/classes/java/util/Base64.java
>>>> @@ -255,14 +255,11 @@
>>>> ????????? *
>>>> ????????? */
>>>> ???????? private final int encodedOutLength(int srclen, boolean 
>>>> throwOOME) {
>>>> -??????????? int len = 0;
>>>> +??????????? int len;
>>>> ???????????? try {
>>>> -??????????????? if (doPadding) {
>>>> -??????????????????? len = Math.multiplyExact(4, 
>>>> (Math.addExact(srclen, 2) / 3));
>>>> -??????????????? } else {
>>>> -??????????????????? int n = srclen % 3;
>>>> -??????????????????? len = Math.addExact(Math.multiplyExact(4, 
>>>> (srclen / 3)), (n == 0 ? 0 : n + 1));
>>>> -??????????????? }
>>>> +??????????????? len = doPadding
>>>> +??????????????????????? ? Math.multiplyExact(4, 
>>>> (Math.addExact(srclen, 2) / 3))
>>>> +??????????????????????? : Math.addExact((Math.addExact(srclen, 2) / 
>>>> 3), srclen);
>>>> ???????????????? if (linemax > 0) { // line separators
>>>> ???????????????????? len = Math.addExact(len, (len - 1) / linemax * 
>>>> newline.length);
>>>> ???????????????? }
>>>> @@ -961,14 +958,15 @@
>>>>
>>>> ???????? private final InputStream is;
>>>> ???????? private final boolean isMIME;
>>>> -??????? private final int[] base64;????? // base64 -> byte mapping
>>>> -??????? private int bits = 0;??????????? // 24-bit buffer for decoding
>>>> -??????? private int nextin = 18;???????? // next available "off" in 
>>>> "bits" for input;
>>>> -???????????????????????????????????????? // -> 18, 12, 6, 0
>>>> -??????? private int nextout = -8;??????? // next available "off" in 
>>>> "bits" for output;
>>>> -???????????????????????????????????????? // -> 8, 0, -8 (no byte 
>>>> for output)
>>>> -??????? private boolean eof = false;
>>>> -??????? private boolean closed = false;
>>>> +??????? private final int[] base64;???? // mapping from alphabet to 
>>>> values
>>>> +??????? private int bits;?????????????? // 24 bit buffer for decoding
>>>> +??????? private int wpos;?????????????? // writing bit pos inside bits
>>>> +??????? // one of 24 (left, msb), 18, 12, 6, 0
>>>> +??????? private int rpos;?????????????? // reading bit pos inside bits
>>>> +??????? // one of 24 (left, msb), 16, 8, 0
>>>> +??????? private boolean eos;
>>>> +??????? private boolean closed;
>>>> +??????? private byte[] onebuf = new byte[1];
>>>>
>>>> ???????? DecInputStream(InputStream is, int[] base64, boolean isMIME) {
>>>> ???????????? this.is = is;
>>>> @@ -976,114 +974,158 @@
>>>> ???????????? this.isMIME = isMIME;
>>>> ???????? }
>>>>
>>>> -??????? private byte[] sbBuf = new byte[1];
>>>> -
>>>> ???????? @Override
>>>> ???????? public int read() throws IOException {
>>>> -??????????? return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>>>> +??????????? return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
>>>> +??????? }
>>>> +
>>>> +??????? private int leftovers(byte[] b, int off, int pos, int limit) {
>>>> +??????????? eos = true;
>>>> +??????????? /*
>>>> +??????????? We use a loop here, as this code is executed only once.
>>>> +??????????? Unrolling the loop would probably not contribute much 
>>>> here.
>>>> +???????????? */
>>>> +??????????? while (rpos - 8 >= wpos && pos != limit) {
>>>> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
>>>> +??????????? }
>>>> +??????????? return pos - off != 0 || rpos - 8 >= wpos ? pos - off : 
>>>> -1;
>>>> ???????? }
>>>>
>>>> -??????? private int eof(byte[] b, int off, int len, int oldOff)
>>>> -??????????? throws IOException
>>>> -??????? {
>>>> -??????????? eof = true;
>>>> -??????????? if (nextin != 18) {
>>>> -??????????????? if (nextin == 12)
>>>> -??????????????????? throw new IOException("Base64 stream has one 
>>>> un-decoded dangling byte.");
>>>> -??????????????? // treat ending xx/xxx without padding character 
>>>> legal.
>>>> -??????????????? // same logic as v == '=' below
>>>> -??????????????? b[off++] = (byte)(bits >> (16));
>>>> -??????????????? if (nextin == 0) {?????????? // only one padding byte
>>>> -??????????????????? if (len == 1) {????????? // no enough output space
>>>> -??????????????????????? bits >>= 8;????????? // shift to lowest byte
>>>> -??????????????????????? nextout = 0;
>>>> -??????????????????? } else {
>>>> -??????????????????????? b[off++] = (byte) (bits >>? 8);
>>>> -??????????????????? }
>>>> -??????????????? }
>>>> +??????? private int eos(byte[] b, int off, int pos, int limit) 
>>>> throws IOException {
>>>> +??????????? /*
>>>> +??????????? wpos == 18: x???? dangling single x, invalid unit
>>>> +??????????? accept ending xx or xxx without padding characters
>>>> +???????????? */
>>>> +??????????? if (wpos == 18) {
>>>> +??????????????? throw new IOException("Base64 stream has one 
>>>> un-decoded dangling byte");
>>>> ???????????? }
>>>> -??????????? return off == oldOff ? -1 : off - oldOff;
>>>> +??????????? rpos = 24;
>>>> +??????????? return leftovers(b, off, pos, limit);
>>>> ???????? }
>>>>
>>>> -??????? private int padding(byte[] b, int off, int len, int oldOff)
>>>> -??????????? throws IOException
>>>> -??????? {
>>>> -??????????? // =???? shiftto==18 unnecessary padding
>>>> -??????????? // x=??? shiftto==12 dangling x, invalid unit
>>>> -??????????? // xx=?? shiftto==6 && missing last '='
>>>> -??????????? // xx=y? or last is not '='
>>>> -??????????? if (nextin == 18 || nextin == 12 ||
>>>> -??????????????? nextin == 6 && is.read() != '=') {
>>>> -??????????????? throw new IOException("Illegal base64 ending 
>>>> sequence:" + nextin);
>>>> +??????? private int padding(byte[] b, int off, int pos, int limit) 
>>>> throws IOException {
>>>> +??????????? /*
>>>> +??????????? wpos == 24: =??? (unnecessary padding)
>>>> +??????????? wpos == 18: x=?? (dangling single x, invalid unit)
>>>> +??????????? wpos == 12 and missing last '=': xx=? (invalid padding)
>>>> +??????????? wpos == 12 and last is not '=': xx=x (invalid padding)
>>>> +???????????? */
>>>> +??????????? if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>>>> +??????????????? throw new IOException("Illegal base64 ending 
>>>> sequence");
>>>> ???????????? }
>>>> -??????????? b[off++] = (byte)(bits >> (16));
>>>> -??????????? if (nextin == 0) {?????????? // only one padding byte
>>>> -??????????????? if (len == 1) {????????? // no enough output space
>>>> -??????????????????? bits >>= 8;????????? // shift to lowest byte
>>>> -??????????????????? nextout = 0;
>>>> -??????????????? } else {
>>>> -??????????????????? b[off++] = (byte) (bits >>? 8);
>>>> -??????????????? }
>>>> -??????????? }
>>>> -??????????? eof = true;
>>>> -??????????? return off - oldOff;
>>>> +??????????? rpos = 24;
>>>> +??????????? return leftovers(b, off, pos, limit);
>>>> ???????? }
>>>>
>>>> ???????? @Override
>>>> ???????? public int read(byte[] b, int off, int len) throws 
>>>> IOException {
>>>> -??????????? if (closed)
>>>> +??????????? if (closed) {
>>>> ???????????????? throw new IOException("Stream is closed");
>>>> -??????????? if (eof && nextout < 0)??? // eof and no leftover
>>>> -??????????????? return -1;
>>>> -??????????? if (off < 0 || len < 0 || len > b.length - off)
>>>> -??????????????? throw new IndexOutOfBoundsException();
>>>> -??????????? int oldOff = off;
>>>> -??????????? while (nextout >= 0) {?????? // leftover output byte(s) 
>>>> in bits buf
>>>> -??????????????? if (len == 0)
>>>> -??????????????????? return off - oldOff;
>>>> -??????????????? b[off++] = (byte)(bits >> nextout);
>>>> -??????????????? len--;
>>>> -??????????????? nextout -= 8;
>>>> +??????????? }
>>>> +??????????? Objects.checkFromIndexSize(off, len, b.length);
>>>> +??????????? if (len == 0) {
>>>> +??????????????? return 0;
>>>> ???????????? }
>>>> -??????????? bits = 0;
>>>> -??????????? while (len > 0) {
>>>> -??????????????? int v = is.read();
>>>> -??????????????? if (v == -1) {
>>>> -??????????????????? return eof(b, off, len, oldOff);
>>>> +
>>>> +??????????? /*
>>>> +??????????? Rather than keeping 2 running vars (e.g., off and len), 
>>>> we only
>>>> +??????????? keep one (pos), while definitely fixing the boundaries 
>>>> of the range
>>>> +??????????? [off, limit).
>>>> +
>>>> +??????????? Note that limit can overflow to Integer.MIN_VALUE. 
>>>> However, as long
>>>> +??????????? as comparisons with pos are done as coded, there's no 
>>>> harm.
>>>> +
>>>> +??????????? In addition, limit - off (= len) is used from here on, 
>>>> so the
>>>> +??????????? location for len can be reallocated to other vars 
>>>> (e.g., limit).
>>>> +???????????? */
>>>> +??????????? int pos = off;
>>>> +??????????? int limit = off + len;
>>>> +??????????? if (eos) {
>>>> +??????????????? return leftovers(b, off, pos, limit);
>>>> +??????????? }
>>>> +
>>>> +??????????? /*
>>>> +??????????? leftovers from previous invocation; here, wpos = 0.
>>>> +??????????? There can be at most 2 leftover bytes (rpos <= 16).
>>>> +??????????? Further, the buffer b has at least one free place.
>>>> +
>>>> +??????????? The logic could be coded as a loop, (as in method 
>>>> leftovers())
>>>> +??????????? but the explicit "unrolling" makes it possible to 
>>>> generate better
>>>> +??????????? byte extraction code.
>>>> +???????????? */
>>>> +??????????? if (rpos == 16) {
>>>> +??????????????? b[pos++] = (byte) (bits >> 8);
>>>> +??????????????? rpos = 8;
>>>> +??????????????? if (pos == limit) {
>>>> +??????????????????? return limit - off;
>>>> ???????????????? }
>>>> -??????????????? if ((v = base64[v]) < 0) {
>>>> -??????????????????? if (v == -2) {?????? // padding byte(s)
>>>> -??????????????????????? return padding(b, off, len, oldOff);
>>>> -??????????????????? }
>>>> -??????????????????? if (v == -1) {
>>>> -??????????????????????? if (!isMIME)
>>>> -??????????????????????????? throw new IOException("Illegal base64 
>>>> character " +
>>>> -??????????????????????????????? Integer.toString(v, 16));
>>>> -??????????????????????? continue;??????? // skip if for rfc2045
>>>> -??????????????????? }
>>>> -??????????????????? // neve be here
>>>> -??????????????? }
>>>> -??????????????? bits |= (v << nextin);
>>>> -??????????????? if (nextin == 0) {
>>>> -??????????????????? nextin = 18;???????? // clear for next in
>>>> -??????????????????? b[off++] = (byte)(bits >> 16);
>>>> -??????????????????? if (len == 1) {
>>>> -??????????????????????? nextout = 8;??? // 2 bytes left in bits
>>>> -??????????????????????? break;
>>>> -??????????????????? }
>>>> -??????????????????? b[off++] = (byte)(bits >> 8);
>>>> -??????????????????? if (len == 2) {
>>>> -??????????????????????? nextout = 0;??? // 1 byte left in bits
>>>> -??????????????????????? break;
>>>> -??????????????????? }
>>>> -??????????????????? b[off++] = (byte)bits;
>>>> -??????????????????? len -= 3;
>>>> -??????????????????? bits = 0;
>>>> -??????????????? } else {
>>>> -??????????????????? nextin -= 6;
>>>> +??????????? }
>>>> +??????????? if (rpos == 8) {
>>>> +??????????????? b[pos++] = (byte) bits;
>>>> +??????????????? rpos = 0;
>>>> +??????????????? if (pos == limit) {
>>>> +??????????????????? return limit - off;
>>>> ???????????????? }
>>>> ???????????? }
>>>> -??????????? return off - oldOff;
>>>> + 8222187
>>>> +??????????? bits = 0;
>>>> +??????????? wpos = 24;
>>>> +??????????? for (;;) {
>>>> +??????????????? // Here, pos != limit
>>>> +??????????????? int i = is.read();
>>>> +??????????????? if (i < 0) {
>>>> +??????????????????? return eos(b, off, pos, limit);
>>>> +??????????????? }
>>>> +??????????????? int v = base64[i];
>>>> +??????????????? if (v < 0) {
>>>> +??????????????????? /*
>>>> +??????????????????? i not in alphabet, thus
>>>> +??????????????????????? v = -2: i is '=', the padding
>>>> +??????????????????????? v = -1: i is something else, e.g., CR or LF
>>>> +???????????????????? */
>>>> +??????????????????? if (v == -1) {
>>>> +??????????????????????? if (isMIME) {
>>>> +??????????????????????????? continue;
>>>> +??????????????????????? }
>>>> +??????????????????????? throw new IOException("Illegal base64 byte 
>>>> 0x" +
>>>> +??????????????????????????????? Integer.toHexString(i));
>>>> +??????????????????? }
>>>> +??????????????????? return padding(b, off, pos, limit);
>>>> +??????????????? }
>>>> +??????????????? bits |= (v << (wpos -= 6));
>>>> +??????????????? if (wpos != 0) {
>>>> +??????????????????? continue;
>>>> +??????????????? }
>>>> +??????????????? if (limit - pos >= 3) {
>>>> +??????????????????? // frequently taken fast path, no need to track 
>>>> rpos
>>>> +??????????????????? b[pos++] = (byte) (bits >> 16);
>>>> +??????????????????? b[pos++] = (byte) (bits >> 8);
>>>> +??????????????????? b[pos++] = (byte) bits;
>>>> +??????????????????? bits = 0;
>>>> +??????????????????? wpos = 24;
>>>> +??????????????????? if (pos == limit) {
>>>> +??????????????????????? return limit - off;
>>>> +??????????????????? }
>>>> +??????????????????? continue;
>>>> +??????????????? }
>>>> +??????????????? /*
>>>> +??????????????? Here, buffer b has either 1 or 2 free places, that is,
>>>> +??????????????? limit - pos = 1 or limit - pos = 2.
>>>> +
>>>> +??????????????? As above, this could be coded as a loop. But since the
>>>> +??????????????? shift lengths are explicit multiples of 8, better 
>>>> code can be
>>>> +??????????????? probably generated.
>>>> +???????????????? */
>>>> +??????????????? b[pos++] = (byte) (bits >> 16);
>>>> +??????????????? if (pos == limit) {
>>>> +??????????????????? rpos = 16;
>>>> +??????????????????? return limit - off;
>>>> +??????????????? }
>>>> +??????????????? b[pos++] = (byte) (bits >> 8);
>>>> +??????????????? // Here, pos = limit, no need for an if.
>>>> +??????????????? rpos = 8;
>>>> +??????????????? return limit - off;
>>>> +??????????? }
>>>> ???????? }
>>>>
>>>> ???????? @Override
>>>> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
>>>> b/test/jdk/java/util/Base64/TestBase64.java
>>>> --- a/test/jdk/java/util/Base64/TestBase64.java
>>>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>>>> @@ -144,6 +144,10 @@
>>>> ???????? testDecoderKeepsAbstinence(Base64.getDecoder());
>>>> ???????? testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>>>> ???????? testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>>>> +
>>>> +??????? // tests patch addressing JDK-8222187
>>>> +??????? // https://bugs.openjdk.java.net/browse/JDK-8222187
>>>> +??????? testJDK_8222187();
>>>> ???? }
>>>>
>>>> ???? private static void test(Base64.Encoder enc, Base64.Decoder dec,
>>>> @@ -607,4 +611,26 @@
>>>> ???????????? }
>>>> ???????? }
>>>> ???? }
>>>> +
>>>> +??? private static void testJDK_8222187() throws Throwable {
>>>> +??????? byte[] orig = "12345678".getBytes("US-ASCII");
>>>> +??????? byte[] encoded = Base64.getEncoder().encode(orig);
>>>> +??????? // decode using different buffer sizes
>>>> +??????? for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
>>>> bufferSize++) {
>>>> +??????????? try (
>>>> +??????????????????? InputStream in = Base64.getDecoder().wrap(
>>>> +??????????????????????????? new ByteArrayInputStream(encoded));
>>>> +??????????????????? ByteArrayOutputStream baos = new 
>>>> ByteArrayOutputStream();
>>>> +??????????? ) {
>>>> +??????????????? byte[] buffer = new byte[bufferSize];
>>>> +??????????????? int read;
>>>> +??????????????? while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>>>> +??????????????????? baos.write(buffer, 0, read);
>>>> +??????????????? }
>>>> +??????????????? // compare result, output info if lengths do not match
>>>> +??????????????? byte[] decoded = baos.toByteArray();
>>>> +??????????????? checkEqual(decoded, orig, "Base64 stream decoding 
>>>> failed!");
>>>> +??????????? }
>>>> +??????? }
>>>> +??? }
>>>> ?}
>>>
> 

From naoto.sato at oracle.com  Wed Jul  8 19:53:18 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 8 Jul 2020 12:53:18 -0700
Subject: RFR: 8249086: JDK 15 L10n resource file update - msg drop 10
In-Reply-To: <908f05e3-c319-20dc-e65e-8d93182b6710@oracle.com>
References: <908f05e3-c319-20dc-e65e-8d93182b6710@oracle.com>
Message-ID: <6d8ce9ab-be80-9ba9-6654-d5769e0e8c93@oracle.com>

Hi Leo,

Looks good to me.

Naoto

On 7/8/20 10:58 AM, li.jiang at oracle.com wrote:
> Hi,
> 
> Pls review the l10n resource files update for JDK 15 msg drop 10.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8249086
> 
> Webrev:
> http://cr.openjdk.java.net/~ljiang/8249086/read/
> 
> Thanks,
> Leo

From Roger.Riggs at oracle.com  Wed Jul  8 20:51:29 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2020 16:51:29 -0400
Subject: RFR 15: 8217475: Unexpected StackOverflowError in "process reaper"
 thread
Message-ID: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>

Please reveiw a change to increase the size of the Process Reaper stack 
for debug builds.
This intermittent issue can be traced to the stack shadow page size 
being larger
in debug builds than in release builds. The problem has only been 
spotted in debug builds.

diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
--- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
+++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
@@ -85,12 +85,16 @@
              doPrivileged((PrivilegedAction<Executor>) () -> {
  
                  ThreadGroup tg = Thread.currentThread().getThreadGroup();
                  while (tg.getParent() != null) tg = tg.getParent();
                  ThreadGroup systemThreadGroup = tg;
+
+                // For a debug build, the stack shadow zone is larger;
+                // Increase the total stack size to avoid potential stack overflow.
+                int debugDelta = "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
                  final long stackSize = Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
-                        ? 0 : REAPER_DEFAULT_STACKSIZE;
+                        ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
  
                  ThreadFactory threadFactory = grimReaper -> {
                      Thread t = new Thread(systemThreadGroup, grimReaper,
                              "process reaper", stackSize, false);
                      t.setDaemon(true);

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/

Issue:
 ?? https://bugs.openjdk.java.net/browse/JDK-8217475

Thanks, Roger


From lance.andersen at oracle.com  Wed Jul  8 20:57:44 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 8 Jul 2020 16:57:44 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
Message-ID: <FB12A02B-A269-4D42-8A7A-D1B887EBBFBA@oracle.com>

Hi Raffaello,

Thank you for your taking up this issue.  When working on a fix such as this, it is best to keep the changes narrowly focused to the issue at hand and not attempt to address additional issues within the same fix (though this can be tempting). 

To move forward, I would suggest for your revised patch, to just address the issue described in the bug report.  At the same time create a new issue(s) to address proposed readability issues and/or additional areas of improvement.

Best
Lance

> On Jul 8, 2020, at 3:50 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
> 
> Hello Roger,
> 
> I would of course retract the changes in encodedOutLength() because, as you observe, it is out of scope w.r.t. the bug. I would also retract the other minor changes you mention and clean up the appearance of the comments to adhere to community shared practices.
> 
> Thus, if you think that doing these changes can facilitate my contribution to get through the review process, I would be happy to prepare another patch.
> 
> On the other hand, I see no incentive in dropping the bulk of the new working implementation to try to fix the current one. I would not feel as confident as I am with the proposed code.
> 
> For the sake of completeness and love of experiment, I privately added many cherry-picking and kind of self-documenting assertions and tested tons of normal and edge cases without troubles.
> 
> 
> Greetings
> Raffaello
> 
> 
> 
> On 2020-07-08 18:45, Roger Riggs wrote:
>> Hi Rafaello,
>> Since you have expanded the scope of the fix, you will need to update the bug to
>> include the other changes you are making.  Or create a new issue for the additional work.
>> > Personal preference in style has very little place when maintaining
>> existing code.
>> The style should match the existing code.
>> There is little correspondence between the existing code and the new code that
>> it make is more difficult to determine that they are equivalent.
>> The messages in the exceptions should not be changed without a compelling reason.
>> 1014: It would be more informative to include the rogue character in the message than to drop it.
>> As is, it gives some indication what's wrong about the end.
>> Grautituous changes such as changing the condition in 979 are unnecessary.
>> The change from using "eof" to "eos" is unconventional for IO streams and unnecessary.
>> The note about allowing limit to overflow to MIN_VALUE is informative but it would
>> be better to avoid it and keep a future maintainer from falling into the trap.
>> Regards, Roger
>> On 7/6/20 4:48 PM, Raffaello Giulietti wrote:
>>> Hi Roger,
>>> 
>>> the structure of the original design is preserved, the details change with the intent of having code that is easier to reason about.
>>> 
>>> The main loop has many exit points in the original code, as well as in the new code. For this reason, I prefer not to express it as a while or as a counted for loop. That's why it has the for (;;) form, which promptly warns that more exit points at unusual positions should be expected.
>>> 
>>> The "Illegal base64 character" IOException in the original code is wrong, probably due to oversight. That's why the new code has two vars, namely i and v, to convey more meaningful diagnostic.
>>> 
>>> The new code keeps track of only one running variable pos instead of the original two vars off and len, wit?out using more live variables for this purpose. Less mutating vars help keeping the code simpler. The method has only one mutating var.
>>> 
>>> With the use of writing and reading bit positions fields wpos and rpos, checking when a byte in field bits is ready means testing rpos - 8 >= wpos.
>>> 
>>> I can add more comments, e.g., in the form of Dijkstra/Hoare-style loop invariants, if this helps improving confidence. Or I can add constant-guarded assertions to the proposed code instead of just comments. Or both.
>>> 
>>> 
>>> 
>>> There's nothing I can find in the coding convention [1] about block comments that states that continuation lines must start with the asterisk *, although the examples do so. While I find these asterisks quite distracting, it would be a trivial matter to add them in the next review iteration.
>>> 
>>> The end-of-line comments either comply with the rules in [1] or, in the description of the fields, have been inadvertently "inherited" as multiple lines from the original code. I will of course correct them there in the next review iteration.
>>> 
>>> 
>>> Greetings
>>> Raffaello
>>> 
>>> ----
>>> 
>>> [1] https://www.oracle.com/java/technologies/javase/codeconventions-comments.html 
>>> 
>>> 
>>> On 2020-07-06 20:17, Roger Riggs wrote:
>>>> Hi Raffaello,
>>>> 
>>>> I'm still not sure it needed this much of a re-write to fix the bug;
>>>> It will take some time to look at the changes.
>>>> 
>>>> Regardless, OpenJDK conventions call for following the style of the existing code.
>>>> Your new comments follow neither the existing convention to use "//..." comments
>>>> nor the other prevalent comment form using /*... */ which use consistent indentation
>>>> and "* " on continuation lines.
>>>> 
>>>> Regards, Roger
>>>> 
>>>> 
>>>> On 7/3/20 11:48 AM, Raffaello Giulietti wrote:
>>>>> Hello,
>>>>> 
>>>>> after Roger's notes, which escaped my attention before, I've withdrawn all the changes but for DecInputStream, *except* that I couldn't resist to simplify the maths in encodedOutLength(), while still using xxxExact() arithmetic.
>>>>> 
>>>>> Sorry for the confusion
>>>>> Raffaello
>>>>> 
>>>>> 
>>>>> 
>>>>>> Hi Raffaello,
>>>>>> 
>>>>>> There is way more code changed here than is needed to fix the bug.
>>>>>> General enhancement should be separated from bug fixes.
>>>>>> It makes it easier to review to see the bug was fixed
>>>>>> and easier to separately review other code to see that there are no unexpected changes.
>>>>>> 
>>>>>> If some of the changes are motivated by expected performance improvements,
>>>>>> there should be JMH tests comparing the before and after.
>>>>>> The change to use byte arrays seems useful, but even using char[]
>>>>>> there is little danger of cache thrashing.
>>>>>> 
>>>>>> If using the code using xxxExact was correct, don't change it.
>>>>>> Those methods are intrinsified and perform as well or better than using long.
>>>>>> Usually, it is better to leave code alone and not risk breaking it.
>>>>>> 
>>>>>> Special care needs taken when changing a method that is intrinsified.
>>>>>> The optimized version may use fields of the object and stop
>>>>>> working if they are changed.
>>>>>> 
>>>>>> In the test, the range of buffer sizes tests seems to waste a lot
>>>>>> of cycles on sizes greater than the encoded size of the input.
>>>>>> 
>>>>>> Regards, Roger
>>>>> 
>>>>> 
>>>>> ---------------------
>>>>> 
>>>>> # HG changeset patch
>>>>> # User lello
>>>>> # Date 1593790152 -7200
>>>>> #      Fri Jul 03 17:29:12 2020 +0200
>>>>> # Node ID 73370832de1d2bf3b450930f5cb2467e10528c69
>>>>> # Parent  a7c0307232406c7b0c1a4b8c2de111077848203d
>>>>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end
>>>>> Reviewed-by: TBD
>>>>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>>>>> 
>>>>> diff --git a/src/java.base/share/classes/java/util/Base64.java b/src/java.base/share/classes/java/util/Base64.java
>>>>> --- a/src/java.base/share/classes/java/util/Base64.java
>>>>> +++ b/src/java.base/share/classes/java/util/Base64.java
>>>>> @@ -255,14 +255,11 @@
>>>>>           *
>>>>>           */
>>>>>          private final int encodedOutLength(int srclen, boolean throwOOME) {
>>>>> -            int len = 0;
>>>>> +            int len;
>>>>>              try {
>>>>> -                if (doPadding) {
>>>>> -                    len = Math.multiplyExact(4, (Math.addExact(srclen, 2) / 3));
>>>>> -                } else {
>>>>> -                    int n = srclen % 3;
>>>>> -                    len = Math.addExact(Math.multiplyExact(4, (srclen / 3)), (n == 0 ? 0 : n + 1));
>>>>> -                }
>>>>> +                len = doPadding
>>>>> +                        ? Math.multiplyExact(4, (Math.addExact(srclen, 2) / 3))
>>>>> +                        : Math.addExact((Math.addExact(srclen, 2) / 3), srclen);
>>>>>                  if (linemax > 0) { // line separators
>>>>>                      len = Math.addExact(len, (len - 1) / linemax * newline.length);
>>>>>                  }
>>>>> @@ -961,14 +958,15 @@
>>>>> 
>>>>>          private final InputStream is;
>>>>>          private final boolean isMIME;
>>>>> -        private final int[] base64;      // base64 -> byte mapping
>>>>> -        private int bits = 0;            // 24-bit buffer for decoding
>>>>> -        private int nextin = 18;         // next available "off" in "bits" for input;
>>>>> -                                         // -> 18, 12, 6, 0
>>>>> -        private int nextout = -8;        // next available "off" in "bits" for output;
>>>>> -                                         // -> 8, 0, -8 (no byte for output)
>>>>> -        private boolean eof = false;
>>>>> -        private boolean closed = false;
>>>>> +        private final int[] base64;     // mapping from alphabet to values
>>>>> +        private int bits;               // 24 bit buffer for decoding
>>>>> +        private int wpos;               // writing bit pos inside bits
>>>>> +        // one of 24 (left, msb), 18, 12, 6, 0
>>>>> +        private int rpos;               // reading bit pos inside bits
>>>>> +        // one of 24 (left, msb), 16, 8, 0
>>>>> +        private boolean eos;
>>>>> +        private boolean closed;
>>>>> +        private byte[] onebuf = new byte[1];
>>>>> 
>>>>>          DecInputStream(InputStream is, int[] base64, boolean isMIME) {
>>>>>              this.is = is;
>>>>> @@ -976,114 +974,158 @@
>>>>>              this.isMIME = isMIME;
>>>>>          }
>>>>> 
>>>>> -        private byte[] sbBuf = new byte[1];
>>>>> -
>>>>>          @Override
>>>>>          public int read() throws IOException {
>>>>> -            return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>>>>> +            return read(onebuf, 0, 1) >= 0 ? onebuf[0] & 0xff : -1;
>>>>> +        }
>>>>> +
>>>>> +        private int leftovers(byte[] b, int off, int pos, int limit) {
>>>>> +            eos = true;
>>>>> +            /*
>>>>> +            We use a loop here, as this code is executed only once.
>>>>> +            Unrolling the loop would probably not contribute much here.
>>>>> +             */
>>>>> +            while (rpos - 8 >= wpos && pos != limit) {
>>>>> +                b[pos++] = (byte) (bits >> (rpos -= 8));
>>>>> +            }
>>>>> +            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
>>>>>          }
>>>>> 
>>>>> -        private int eof(byte[] b, int off, int len, int oldOff)
>>>>> -            throws IOException
>>>>> -        {
>>>>> -            eof = true;
>>>>> -            if (nextin != 18) {
>>>>> -                if (nextin == 12)
>>>>> -                    throw new IOException("Base64 stream has one un-decoded dangling byte.");
>>>>> -                // treat ending xx/xxx without padding character legal.
>>>>> -                // same logic as v == '=' below
>>>>> -                b[off++] = (byte)(bits >> (16));
>>>>> -                if (nextin == 0) {           // only one padding byte
>>>>> -                    if (len == 1) {          // no enough output space
>>>>> -                        bits >>= 8;          // shift to lowest byte
>>>>> -                        nextout = 0;
>>>>> -                    } else {
>>>>> -                        b[off++] = (byte) (bits >>  8);
>>>>> -                    }
>>>>> -                }
>>>>> +        private int eos(byte[] b, int off, int pos, int limit) throws IOException {
>>>>> +            /*
>>>>> +            wpos == 18: x     dangling single x, invalid unit
>>>>> +            accept ending xx or xxx without padding characters
>>>>> +             */
>>>>> +            if (wpos == 18) {
>>>>> +                throw new IOException("Base64 stream has one un-decoded dangling byte");
>>>>>              }
>>>>> -            return off == oldOff ? -1 : off - oldOff;
>>>>> +            rpos = 24;
>>>>> +            return leftovers(b, off, pos, limit);
>>>>>          }
>>>>> 
>>>>> -        private int padding(byte[] b, int off, int len, int oldOff)
>>>>> -            throws IOException
>>>>> -        {
>>>>> -            // =     shiftto==18 unnecessary padding
>>>>> -            // x=    shiftto==12 dangling x, invalid unit
>>>>> -            // xx=   shiftto==6 && missing last '='
>>>>> -            // xx=y  or last is not '='
>>>>> -            if (nextin == 18 || nextin == 12 ||
>>>>> -                nextin == 6 && is.read() != '=') {
>>>>> -                throw new IOException("Illegal base64 ending sequence:" + nextin);
>>>>> +        private int padding(byte[] b, int off, int pos, int limit) throws IOException {
>>>>> +            /*
>>>>> +            wpos == 24: =    (unnecessary padding)
>>>>> +            wpos == 18: x=   (dangling single x, invalid unit)
>>>>> +            wpos == 12 and missing last '=': xx=  (invalid padding)
>>>>> +            wpos == 12 and last is not '=': xx=x (invalid padding)
>>>>> +             */
>>>>> +            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>>>>> +                throw new IOException("Illegal base64 ending sequence");
>>>>>              }
>>>>> -            b[off++] = (byte)(bits >> (16));
>>>>> -            if (nextin == 0) {           // only one padding byte
>>>>> -                if (len == 1) {          // no enough output space
>>>>> -                    bits >>= 8;          // shift to lowest byte
>>>>> -                    nextout = 0;
>>>>> -                } else {
>>>>> -                    b[off++] = (byte) (bits >>  8);
>>>>> -                }
>>>>> -            }
>>>>> -            eof = true;
>>>>> -            return off - oldOff;
>>>>> +            rpos = 24;
>>>>> +            return leftovers(b, off, pos, limit);
>>>>>          }
>>>>> 
>>>>>          @Override
>>>>>          public int read(byte[] b, int off, int len) throws IOException {
>>>>> -            if (closed)
>>>>> +            if (closed) {
>>>>>                  throw new IOException("Stream is closed");
>>>>> -            if (eof && nextout < 0)    // eof and no leftover
>>>>> -                return -1;
>>>>> -            if (off < 0 || len < 0 || len > b.length - off)
>>>>> -                throw new IndexOutOfBoundsException();
>>>>> -            int oldOff = off;
>>>>> -            while (nextout >= 0) {       // leftover output byte(s) in bits buf
>>>>> -                if (len == 0)
>>>>> -                    return off - oldOff;
>>>>> -                b[off++] = (byte)(bits >> nextout);
>>>>> -                len--;
>>>>> -                nextout -= 8;
>>>>> +            }
>>>>> +            Objects.checkFromIndexSize(off, len, b.length);
>>>>> +            if (len == 0) {
>>>>> +                return 0;
>>>>>              }
>>>>> -            bits = 0;
>>>>> -            while (len > 0) {
>>>>> -                int v = is.read();
>>>>> -                if (v == -1) {
>>>>> -                    return eof(b, off, len, oldOff);
>>>>> +
>>>>> +            /*
>>>>> +            Rather than keeping 2 running vars (e.g., off and len), we only
>>>>> +            keep one (pos), while definitely fixing the boundaries of the range
>>>>> +            [off, limit).
>>>>> +
>>>>> +            Note that limit can overflow to Integer.MIN_VALUE. However, as long
>>>>> +            as comparisons with pos are done as coded, there's no harm.
>>>>> +
>>>>> +            In addition, limit - off (= len) is used from here on, so the
>>>>> +            location for len can be reallocated to other vars (e.g., limit).
>>>>> +             */
>>>>> +            int pos = off;
>>>>> +            int limit = off + len;
>>>>> +            if (eos) {
>>>>> +                return leftovers(b, off, pos, limit);
>>>>> +            }
>>>>> +
>>>>> +            /*
>>>>> +            leftovers from previous invocation; here, wpos = 0.
>>>>> +            There can be at most 2 leftover bytes (rpos <= 16).
>>>>> +            Further, the buffer b has at least one free place.
>>>>> +
>>>>> +            The logic could be coded as a loop, (as in method leftovers())
>>>>> +            but the explicit "unrolling" makes it possible to generate better
>>>>> +            byte extraction code.
>>>>> +             */
>>>>> +            if (rpos == 16) {
>>>>> +                b[pos++] = (byte) (bits >> 8);
>>>>> +                rpos = 8;
>>>>> +                if (pos == limit) {
>>>>> +                    return limit - off;
>>>>>                  }
>>>>> -                if ((v = base64[v]) < 0) {
>>>>> -                    if (v == -2) {       // padding byte(s)
>>>>> -                        return padding(b, off, len, oldOff);
>>>>> -                    }
>>>>> -                    if (v == -1) {
>>>>> -                        if (!isMIME)
>>>>> -                            throw new IOException("Illegal base64 character " +
>>>>> -                                Integer.toString(v, 16));
>>>>> -                        continue;        // skip if for rfc2045
>>>>> -                    }
>>>>> -                    // neve be here
>>>>> -                }
>>>>> -                bits |= (v << nextin);
>>>>> -                if (nextin == 0) {
>>>>> -                    nextin = 18;         // clear for next in
>>>>> -                    b[off++] = (byte)(bits >> 16);
>>>>> -                    if (len == 1) {
>>>>> -                        nextout = 8;    // 2 bytes left in bits
>>>>> -                        break;
>>>>> -                    }
>>>>> -                    b[off++] = (byte)(bits >> 8);
>>>>> -                    if (len == 2) {
>>>>> -                        nextout = 0;    // 1 byte left in bits
>>>>> -                        break;
>>>>> -                    }
>>>>> -                    b[off++] = (byte)bits;
>>>>> -                    len -= 3;
>>>>> -                    bits = 0;
>>>>> -                } else {
>>>>> -                    nextin -= 6;
>>>>> +            }
>>>>> +            if (rpos == 8) {
>>>>> +                b[pos++] = (byte) bits;
>>>>> +                rpos = 0;
>>>>> +                if (pos == limit) {
>>>>> +                    return limit - off;
>>>>>                  }
>>>>>              }
>>>>> -            return off - oldOff;
>>>>> + 8222187
>>>>> +            bits = 0;
>>>>> +            wpos = 24;
>>>>> +            for (;;) {
>>>>> +                // Here, pos != limit
>>>>> +                int i = is.read();
>>>>> +                if (i < 0) {
>>>>> +                    return eos(b, off, pos, limit);
>>>>> +                }
>>>>> +                int v = base64[i];
>>>>> +                if (v < 0) {
>>>>> +                    /*
>>>>> +                    i not in alphabet, thus
>>>>> +                        v = -2: i is '=', the padding
>>>>> +                        v = -1: i is something else, e.g., CR or LF
>>>>> +                     */
>>>>> +                    if (v == -1) {
>>>>> +                        if (isMIME) {
>>>>> +                            continue;
>>>>> +                        }
>>>>> +                        throw new IOException("Illegal base64 byte 0x" +
>>>>> +                                Integer.toHexString(i));
>>>>> +                    }
>>>>> +                    return padding(b, off, pos, limit);
>>>>> +                }
>>>>> +                bits |= (v << (wpos -= 6));
>>>>> +                if (wpos != 0) {
>>>>> +                    continue;
>>>>> +                }
>>>>> +                if (limit - pos >= 3) {
>>>>> +                    // frequently taken fast path, no need to track rpos
>>>>> +                    b[pos++] = (byte) (bits >> 16);
>>>>> +                    b[pos++] = (byte) (bits >> 8);
>>>>> +                    b[pos++] = (byte) bits;
>>>>> +                    bits = 0;
>>>>> +                    wpos = 24;
>>>>> +                    if (pos == limit) {
>>>>> +                        return limit - off;
>>>>> +                    }
>>>>> +                    continue;
>>>>> +                }
>>>>> +                /*
>>>>> +                Here, buffer b has either 1 or 2 free places, that is,
>>>>> +                limit - pos = 1 or limit - pos = 2.
>>>>> +
>>>>> +                As above, this could be coded as a loop. But since the
>>>>> +                shift lengths are explicit multiples of 8, better code can be
>>>>> +                probably generated.
>>>>> +                 */
>>>>> +                b[pos++] = (byte) (bits >> 16);
>>>>> +                if (pos == limit) {
>>>>> +                    rpos = 16;
>>>>> +                    return limit - off;
>>>>> +                }
>>>>> +                b[pos++] = (byte) (bits >> 8);
>>>>> +                // Here, pos = limit, no need for an if.
>>>>> +                rpos = 8;
>>>>> +                return limit - off;
>>>>> +            }
>>>>>          }
>>>>> 
>>>>>          @Override
>>>>> diff --git a/test/jdk/java/util/Base64/TestBase64.java b/test/jdk/java/util/Base64/TestBase64.java
>>>>> --- a/test/jdk/java/util/Base64/TestBase64.java
>>>>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>>>>> @@ -144,6 +144,10 @@
>>>>>          testDecoderKeepsAbstinence(Base64.getDecoder());
>>>>>          testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>>>>>          testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>>>>> +
>>>>> +        // tests patch addressing JDK-8222187
>>>>> +        // https://bugs.openjdk.java.net/browse/JDK-8222187
>>>>> +        testJDK_8222187();
>>>>>      }
>>>>> 
>>>>>      private static void test(Base64.Encoder enc, Base64.Decoder dec,
>>>>> @@ -607,4 +611,26 @@
>>>>>              }
>>>>>          }
>>>>>      }
>>>>> +
>>>>> +    private static void testJDK_8222187() throws Throwable {
>>>>> +        byte[] orig = "12345678".getBytes("US-ASCII");
>>>>> +        byte[] encoded = Base64.getEncoder().encode(orig);
>>>>> +        // decode using different buffer sizes
>>>>> +        for (int bufferSize = 1; bufferSize <= encoded.length + 1; bufferSize++) {
>>>>> +            try (
>>>>> +                    InputStream in = Base64.getDecoder().wrap(
>>>>> +                            new ByteArrayInputStream(encoded));
>>>>> +                    ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>>>> +            ) {
>>>>> +                byte[] buffer = new byte[bufferSize];
>>>>> +                int read;
>>>>> +                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>>>>> +                    baos.write(buffer, 0, read);
>>>>> +                }
>>>>> +                // compare result, output info if lengths do not match
>>>>> +                byte[] decoded = baos.toByteArray();
>>>>> +                checkEqual(decoded, orig, "Base64 stream decoding failed!");
>>>>> +            }
>>>>> +        }
>>>>> +    }
>>>>>  }
>>>> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From daniel.daugherty at oracle.com  Wed Jul  8 21:22:32 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 8 Jul 2020 17:22:32 -0400
Subject: RFR(T): 8249097: test/lib/jdk/test/lib/util/JarBuilder.java has a bad
 copyright
Message-ID: <468998e0-e37f-4be5-d841-d62dc7b2591f@oracle.com>

Greetings,

A trivial fix to make the validate-header Tier1 task happy.

Here's the context diff:

$ hg diff -r qparent
diff -r c5202ed40b86 test/lib/jdk/test/lib/util/JarBuilder.java
--- a/test/lib/jdk/test/lib/util/JarBuilder.java??? Wed Jul 08 20:35:36 
2020 +0100
+++ b/test/lib/jdk/test/lib/util/JarBuilder.java??? Wed Jul 08 17:20:01 
2020 -0400
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2015, 2020 Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2015, 2020, 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


Thanks, in advance, for any comments, questions, or suggestions.

Dan


From igor.ignatyev at oracle.com  Wed Jul  8 21:23:37 2020
From: igor.ignatyev at oracle.com (igor.ignatyev at oracle.com)
Date: Wed, 8 Jul 2020 14:23:37 -0700
Subject: RFR(T): 8249097: test/lib/jdk/test/lib/util/JarBuilder.java has a
 bad copyright
In-Reply-To: <468998e0-e37f-4be5-d841-d62dc7b2591f@oracle.com>
References: <468998e0-e37f-4be5-d841-d62dc7b2591f@oracle.com>
Message-ID: <2D84F8BE-3DB0-4999-A8FE-E5A91475332B@oracle.com>

LGTM, thanks for fixing, and sorry for introducing that. 

? Igor

> On Jul 8, 2020, at 2:22 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
> ?Greetings,
> 
> A trivial fix to make the validate-header Tier1 task happy.
> 
> Here's the context diff:
> 
> $ hg diff -r qparent
> diff -r c5202ed40b86 test/lib/jdk/test/lib/util/JarBuilder.java
> --- a/test/lib/jdk/test/lib/util/JarBuilder.java    Wed Jul 08 20:35:36 2020 +0100
> +++ b/test/lib/jdk/test/lib/util/JarBuilder.java    Wed Jul 08 17:20:01 2020 -0400
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2015, 2020 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2020, 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
> 
> 
> Thanks, in advance, for any comments, questions, or suggestions.
> 
> Dan
> 


From daniel.daugherty at oracle.com  Wed Jul  8 21:24:40 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 8 Jul 2020 17:24:40 -0400
Subject: RFR(T): 8249097: test/lib/jdk/test/lib/util/JarBuilder.java has a
 bad copyright
In-Reply-To: <2D84F8BE-3DB0-4999-A8FE-E5A91475332B@oracle.com>
References: <468998e0-e37f-4be5-d841-d62dc7b2591f@oracle.com>
 <2D84F8BE-3DB0-4999-A8FE-E5A91475332B@oracle.com>
Message-ID: <7b395b80-ce53-60ac-d52c-68a8e282cd24@oracle.com>

Thanks for the fast review.

I was surprised that jcheck -r tip didn't flag that, but... :-)

Dan


On 7/8/20 5:23 PM, igor.ignatyev at oracle.com wrote:
> LGTM, thanks for fixing, and sorry for introducing that.
>
> ? Igor
>
>> On Jul 8, 2020, at 2:22 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> ?Greetings,
>>
>> A trivial fix to make the validate-header Tier1 task happy.
>>
>> Here's the context diff:
>>
>> $ hg diff -r qparent
>> diff -r c5202ed40b86 test/lib/jdk/test/lib/util/JarBuilder.java
>> --- a/test/lib/jdk/test/lib/util/JarBuilder.java    Wed Jul 08 20:35:36 2020 +0100
>> +++ b/test/lib/jdk/test/lib/util/JarBuilder.java    Wed Jul 08 17:20:01 2020 -0400
>> @@ -1,5 +1,5 @@
>>   /*
>> - * Copyright (c) 2015, 2020 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2015, 2020, 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
>>
>>
>> Thanks, in advance, for any comments, questions, or suggestions.
>>
>> Dan
>>


From alexander.matveev at oracle.com  Wed Jul  8 22:12:07 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Wed, 8 Jul 2020 15:12:07 -0700
Subject: RFR: JDK-8247779 Remove deprecated --bind-services option from
 jpackage
In-Reply-To: <752d2a2c-9e0e-df69-66cd-bf23df4a7ac1@oracle.com>
References: <c3447ae9-cdea-9a09-d16c-ffde41cf8404@oracle.com>
 <752d2a2c-9e0e-df69-66cd-bf23df4a7ac1@oracle.com>
Message-ID: <0ec19c5a-6040-990b-476c-82a608b30333@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 7/8/20 9:18 AM, Alexey Semenyuk wrote:
> Looks good.
>
> - Alexey
>
> On 7/8/2020 10:34 AM, Andy Herrick wrote:
>> Please review change at [1] to issue [2] removing the 
>> "--bind-services" option from jpackage.
>>
>> /Andy
>>
>>
>> [1] http://cr.openjdk.java.net/~herrick/8248864/webrev.01/
>>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8247779
>>
>


From martinrb at google.com  Wed Jul  8 22:17:27 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Jul 2020 15:17:27 -0700
Subject: RFR 15: 8217475: Unexpected StackOverflowError in "process
 reaper" thread
In-Reply-To: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
References: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
Message-ID: <CA+kOe08CQmUv-zDtat49m4X5UONYxxbDU22zsOroKQRT7Q_Ukw@mail.gmail.com>

Approved.

As author of the small stack size for the reaper thread, I'm sorry
it's caused so much trouble.
But as always, the proper solution is to fix the java runtime so that
fixed allocations like this are unnecessary.

hard: stack size should not include native overhead like shadow pages.
Switching to a debug build should not cause SOE.

harder: banish SOE in pure java code entirely by loomishly moving
continuations to a larger stack.


On Wed, Jul 8, 2020 at 1:54 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
> Please reveiw a change to increase the size of the Process Reaper stack
> for debug builds.
> This intermittent issue can be traced to the stack shadow page size
> being larger
> in debug builds than in release builds. The problem has only been
> spotted in debug builds.
>
> diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> @@ -85,12 +85,16 @@
>               doPrivileged((PrivilegedAction<Executor>) () -> {
>
>                   ThreadGroup tg = Thread.currentThread().getThreadGroup();
>                   while (tg.getParent() != null) tg = tg.getParent();
>                   ThreadGroup systemThreadGroup = tg;
> +
> +                // For a debug build, the stack shadow zone is larger;
> +                // Increase the total stack size to avoid potential stack overflow.
> +                int debugDelta = "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
>                   final long stackSize = Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
> -                        ? 0 : REAPER_DEFAULT_STACKSIZE;
> +                        ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
>
>                   ThreadFactory threadFactory = grimReaper -> {
>                       Thread t = new Thread(systemThreadGroup, grimReaper,
>                               "process reaper", stackSize, false);
>                       t.setDaemon(true);
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/
>
> Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8217475
>
> Thanks, Roger
>

From Roger.Riggs at oracle.com  Wed Jul  8 22:25:03 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2020 18:25:03 -0400
Subject: RFR 15: 8217475: Unexpected StackOverflowError in "process
 reaper" thread
In-Reply-To: <CA+kOe08CQmUv-zDtat49m4X5UONYxxbDU22zsOroKQRT7Q_Ukw@mail.gmail.com>
References: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
 <CA+kOe08CQmUv-zDtat49m4X5UONYxxbDU22zsOroKQRT7Q_Ukw@mail.gmail.com>
Message-ID: <ea808395-24dd-d78f-43a7-40bf1270ef78@oracle.com>

Hi Martin,

Yep, there are number of other ways stack could have been handled.
Another one might be to not "commit" all the stack memory until it is 
needed.
So it takes up address space, but not memory; still not a perfect way.

I haven't looked to see if the 64k network stack buffer that is reserved
can be done another way; but that's a different idea.

In continued testing, I had another SOE with the 8k stack proposed.
I need to do another round with 16k.

Thanks, Roger


On 7/8/20 6:17 PM, Martin Buchholz wrote:
> Approved.
>
> As author of the small stack size for the reaper thread, I'm sorry
> it's caused so much trouble.
> But as always, the proper solution is to fix the java runtime so that
> fixed allocations like this are unnecessary.
>
> hard: stack size should not include native overhead like shadow pages.
> Switching to a debug build should not cause SOE.
>
> harder: banish SOE in pure java code entirely by loomishly moving
> continuations to a larger stack.
>
>
> On Wed, Jul 8, 2020 at 1:54 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Please reveiw a change to increase the size of the Process Reaper stack
>> for debug builds.
>> This intermittent issue can be traced to the stack shadow page size
>> being larger
>> in debug builds than in release builds. The problem has only been
>> spotted in debug builds.
>>
>> diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>> @@ -85,12 +85,16 @@
>>                doPrivileged((PrivilegedAction<Executor>) () -> {
>>
>>                    ThreadGroup tg = Thread.currentThread().getThreadGroup();
>>                    while (tg.getParent() != null) tg = tg.getParent();
>>                    ThreadGroup systemThreadGroup = tg;
>> +
>> +                // For a debug build, the stack shadow zone is larger;
>> +                // Increase the total stack size to avoid potential stack overflow.
>> +                int debugDelta = "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
>>                    final long stackSize = Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
>> -                        ? 0 : REAPER_DEFAULT_STACKSIZE;
>> +                        ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
>>
>>                    ThreadFactory threadFactory = grimReaper -> {
>>                        Thread t = new Thread(systemThreadGroup, grimReaper,
>>                                "process reaper", stackSize, false);
>>                        t.setDaemon(true);
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/
>>
>> Issue:
>>      https://bugs.openjdk.java.net/browse/JDK-8217475
>>
>> Thanks, Roger
>>


From alexey.semenyuk at oracle.com  Thu Jul  9 01:37:35 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 8 Jul 2020 21:37:35 -0400
Subject: RFR: JDK-8247229: jpackage tests failed due to "semop(1): encountered
 an error: Invalid argument"
In-Reply-To: <01ebf9e4-9049-b33d-e395-798706828b74@oracle.com>
References: <01ebf9e4-9049-b33d-e395-798706828b74@oracle.com>
Message-ID: <fc52e413-13db-b152-dec9-223958b76f57@oracle.com>

Please review fix [2] for jpackage bug [1].

Sometimes jpackage fails building .deb package due to failure of 
`fakeroot` command with the same error message printed in stderr: 
`semop(1): encountered an error: Invalid argument`.
The suggested fix is to rerun `fakeroot` command if it fails and the 
known error message is pritnted to stederr.

- Alexey

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

[2]?http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.00


From alexander.matveev at oracle.com  Thu Jul  9 04:02:03 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Wed, 8 Jul 2020 21:02:03 -0700
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <8964d112-015c-e376-3900-b01b8406bcd0@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
 <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>
 <312cfde4-afc4-83b9-9e51-85b0a9f5b47f@oracle.com>
 <8964d112-015c-e376-3900-b01b8406bcd0@oracle.com>
Message-ID: <e55fabfc-7b86-7d66-aaa9-7fe6e97a8e25@oracle.com>

Hi Alexey,

http://cr.openjdk.java.net/~almatvee/8248261/webrev.01/

- Added fatalError() to log fatal errors without timestamp.
- Added missing timestamp to Log.verbose(Throwable t).

Thanks,
Alexander

On 7/8/20 9:34 AM, Alexey Semenyuk wrote:
> I still think it would be good to create dedicated method for final 
> error reporting in Main and Arguments classes without timestamps.
>
> - Alexey
>
> On 7/8/2020 9:59 AM, Andy Herrick wrote:
>> After further discussion, I approve this change as is.
>>
>> The main fatal error in Arguments.processArguments() only calls 
>> Log.error if not verbose , so guarding it from having a timestamp 
>> when verbose is not an issue.
>>
>> /Andy
>>
>> On 7/7/2020 7:20 PM, Andy Herrick wrote:
>>> I agree - but I would rather then that Log.error() never show 
>>> timestamp.
>>>
>>> It would be better still if we could differentiate fatal error 
>>> messages from warning messages - right now we are using Log.error 
>>> for both.
>>>
>>> /Andy
>>>
>>>
>>> On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
>>>> Hi Andy,
>>>>
>>>> Timestamps for error message without verbose output are meaningless 
>>>> in my opinion. This is why I did not add them. Also, in some cases 
>>>> output does not look right. For example when timestamp is added to 
>>>> error message always:
>>>> jpackage --someoption
>>>> WARNING: Using incubator modules: jdk.incubator.jpackage
>>>> [15:49:23.798] Error: Invalid Option: [--someoption]
>>>>
>>>> In example above I do not see any point to have timestamp.
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 7/7/20 6:18 AM, Andy Herrick wrote:
>>>>> All looks good, except maybe Log.error().
>>>>>
>>>>> I think Log.error() should have the same output whether verbose or 
>>>>> not, adding timestamp to the message only if verbose does not look 
>>>>> right.
>>>>>
>>>>> Problem is that Log.error() is used for two fundamentally 
>>>>> different purposes:
>>>>>
>>>>> 1.) by Main and Arguments to display the final error message when 
>>>>> jpackage is failing.
>>>>>
>>>>> 2.) by everyone else to display a serious warning message when 
>>>>> jpackage is continuing (sometimes failing further on, and 
>>>>> sometimes not).
>>>>>
>>>>> I wouldn't mind adding timestamps only when verbose in case (2), 
>>>>> but I don't think that's appropriate for case (1).
>>>>>
>>>>> /ANdy
>>>>>
>>>>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>>>>> Please review the jpackage fix for bug [1] at [2].
>>>>>>
>>>>>> Added timestamp to verbose and test output in form of 
>>>>>> [HH:mm:ss.SSS].
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>>>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>
>


From alexander.matveev at oracle.com  Thu Jul  9 04:21:10 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Wed, 8 Jul 2020 21:21:10 -0700
Subject: RFR: JDK-8247229: jpackage tests failed due to "semop(1):
 encountered an error: Invalid argument"
In-Reply-To: <fc52e413-13db-b152-dec9-223958b76f57@oracle.com>
References: <01ebf9e4-9049-b33d-e395-798706828b74@oracle.com>
 <fc52e413-13db-b152-dec9-223958b76f57@oracle.com>
Message-ID: <bc834a38-c332-8c1d-60a4-1cbec08d1804@oracle.com>

Hi Alexey,

Looks good. Only suggestion is to move CmdlineExecutor to Executor class 
and make it configurable for error message and probably attempts and 
timeout in case if we need such functionality in other places.

Thanks,
Alexander

On 7/8/20 6:37 PM, Alexey Semenyuk wrote:
> Please review fix [2] for jpackage bug [1].
>
> Sometimes jpackage fails building .deb package due to failure of 
> `fakeroot` command with the same error message printed in stderr: 
> `semop(1): encountered an error: Invalid argument`.
> The suggested fix is to rerun `fakeroot` command if it fails and the 
> known error message is pritnted to stederr.
>
> - Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8247229
>
> [2]?http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.00
>


From sakatakui at oss.nttdata.com  Thu Jul  9 07:48:36 2020
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Thu, 9 Jul 2020 16:48:36 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
Message-ID: <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>

Hi Daniel,

Thank you for your response.

 >  > +    if (sizeof(if2.ifr_name) < sizeof(name)) {
 >  > +        return -1;
 >  > +    }
 >
 > If I'm not mistaken `sizeof(name)` where name is a const char*
 > will always be 8 (on 64 bits architecture) - so this is probably
 > not doing what you want.

I'm sorry. That is my mistake.

 > Also you don't want to trust that `name` is null terminated.
 > Calling strncpy in that case is much safer than calling strcpy
 > even if guarded by strlen.
 > I'm not sure what the compiler is warning you about here.
 >
 > I'd suggest to experiment changing:
 >
 >  >       memset((char *)&if2, 0, sizeof(if2));
 >  > -     strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
 >    +     strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
 >    +     if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

I've written the code same as your suggestion. Certainly that can 
resolve the warnings. But I think it could cut off the name in the 
middle when length of the name longer than the if2.ifr_name length. I 
would say I might as well return the error code under the circumstances. 
  So I added the if statement. The code that reflect my intention 
correctly is as follows.


diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
b/src/java.base/unix/native/libnet/NetworkInterface.c
--- a/src/java.base/unix/native/libnet/NetworkInterface.c
+++ b/src/java.base/unix/native/libnet/NetworkInterface.c
@@ -1295,8 +1295,13 @@
   */
  static int getIndex(int sock, const char *name) {
      struct ifreq if2;
+
+    if (sizeof(if2.ifr_name) < strlen(name) + 1) {
+        return -1;
+    }
+
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
+    strcpy(if2.ifr_name, name);

      if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
          return -1;
@@ -1358,8 +1363,13 @@

  static int getFlags(int sock, const char *ifname, int *flags) {
      struct ifreq if2;
+
+    if (sizeof(if2.ifr_name) < strlen(ifname) + 1) {
+        return -1;
+    }
+
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
+    strcpy(if2.ifr_name, ifname);

      if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
          return -1;


Thanks,
Koichi

On 2020/07/08 2:57, Daniel Fuchs wrote:
> Hi,
> 
> I will not comment on the changes to libfdlibm/k_standard.c
> 
> Concerning NetworkInterface.c I believe the proposed changes are
> incorrect - and I do not see the issue with the current code.
> 
>  > +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>  > +??????? return -1;
>  > +??? }
> 
> If I'm not mistaken `sizeof(name)` where name is a const char*
> will always be 8 (on 64 bits architecture) - so this is probably
> not doing what you want.
> 
> Also you don't want to trust that `name` is null terminated.
> Calling strncpy in that case is much safer than calling strcpy
> even if guarded by strlen.
> I'm not sure what the compiler is warning you about here.
> 
> I'd suggest to experiment changing:
> 
>  >?????? memset((char *)&if2, 0, sizeof(if2));
>  > -???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>  ? +???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>  ? +???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
> and see if that makes the warning go away.
> 
> best regards,
> 
> -- daniel
> 
> 
> On 24/06/2020 08:48, Koichi Sakata wrote:
>> Hi all,
>>
>> (I've sent a similar e-mail before to this ML, but I extract the part 
>> only related to core-libs-dev ML from the previous one.)
>>
>> I tried to build OpenJDK fastdebug with GCC 10.1 on Ubuntu 18.04, but 
>> I saw some compiler warnings as follows:
>>
>> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/: In 
>> function '__j__kernel_standard':
>> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/k_standard.c:743:19: 
>> error: 'exc.retval' may be used uninitialized in this function 
>> [-Werror=maybe-uninitialized]
>> ?? 743 |???????? return exc.retval;
>> ?????? |??????????????? ~~~^~~~~~~
>>
>> In file included from /usr/include/string.h:494,
>> ????????????????? from 
>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:30: 
>>
>> In function 'strncpy',
>> ???? inlined from 'getFlags' at 
>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:1362:5, 
>>
>> ???? inlined from 'addif' at 
>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:974:13: 
>>
>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
>> '__builtin_strncpy' output may be truncated copying 15 bytes from a 
>> string of length 15 [-Werror=stringop-truncation]
>> ?? 106 |?? return __builtin___strncpy_chk (__dest, __src, __len, __bos 
>> (__dest));
>> ?????? | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> I can resolve them with the following patch. I believe it fixes those 
>> potential bugs, so I'd like to contribute it.
>> (Our company has signed OCA.)
>>
>> Thanks,
>> Koichi
>>
>> ===== PATCH =====
>> diff -r 20d92fe3ac52 src/java.base/share/native/libfdlibm/k_standard.c
>> --- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Jun 16 
>> 03:16:41 2020 +0000
>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c Thu Jun 18 
>> 07:08:50 2020 +0900
>> @@ -739,6 +739,10 @@
>> ????????????????????????? errno = EDOM;
>> ????????????????? }
>> ????????????????? break;
>> +??????????? default:
>> +??????????????? exc.retval = zero;
>> +??????????????? errno = EINVAL;
>> +??????????????? break;
>> ????????? }
>> ????????? return exc.retval;
>> ??}
>> diff -r 20d92fe3ac52 src/java.base/unix/native/libnet/NetworkInterface.c
>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c?????? Tue 
>> Jun 16 03:16:41 2020 +0000
>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c?????? Thu 
>> Jun 18 07:08:50 2020 +0900
>> @@ -1296,7 +1296,10 @@
>> ??static int getIndex(int sock, const char *name) {
>> ????? struct ifreq if2;
>> ????? memset((char *)&if2, 0, sizeof(if2));
>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>> +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>> +??????? return -1;
>> +??? }
>> +??? strcpy(if2.ifr_name, name);
>>
>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>> ????????? return -1;
>> @@ -1359,7 +1362,10 @@
>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>> ????? struct ifreq if2;
>> ????? memset((char *)&if2, 0, sizeof(if2));
>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>> +??? if (sizeof(if2.ifr_name) < sizeof(ifname)) {
>> +??????? return -1;
>> +??? }
>> +??? strcpy(if2.ifr_name, ifname);
>>
>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>> ????????? return -1;
> 

From david.holmes at oracle.com  Thu Jul  9 08:54:15 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2020 18:54:15 +1000
Subject: RFR 15: 8217475: Unexpected StackOverflowError in "process
 reaper" thread
In-Reply-To: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
References: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
Message-ID: <f067b157-3c98-13cf-c1c7-8b4e18e5b537@oracle.com>

Hi Roger,

Looks good to me.

Thanks,
David

On 9/07/2020 6:51 am, Roger Riggs wrote:
> Please reveiw a change to increase the size of the Process Reaper stack 
> for debug builds.
> This intermittent issue can be traced to the stack shadow page size 
> being larger
> in debug builds than in release builds. The problem has only been 
> spotted in debug builds.
> 
> diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java 
> b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
> @@ -85,12 +85,16 @@
>  ???????????? doPrivileged((PrivilegedAction<Executor>) () -> {
> 
>  ???????????????? ThreadGroup tg = Thread.currentThread().getThreadGroup();
>  ???????????????? while (tg.getParent() != null) tg = tg.getParent();
>  ???????????????? ThreadGroup systemThreadGroup = tg;
> +
> +??????????????? // For a debug build, the stack shadow zone is larger;
> +??????????????? // Increase the total stack size to avoid potential 
> stack overflow.
> +??????????????? int debugDelta = 
> "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
>  ???????????????? final long stackSize = 
> Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
> -??????????????????????? ? 0 : REAPER_DEFAULT_STACKSIZE;
> +??????????????????????? ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
> 
>  ???????????????? ThreadFactory threadFactory = grimReaper -> {
>  ???????????????????? Thread t = new Thread(systemThreadGroup, grimReaper,
>  ???????????????????????????? "process reaper", stackSize, false);
>  ???????????????????? t.setDaemon(true);
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/
> 
> Issue:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8217475
> 
> Thanks, Roger
> 

From david.holmes at oracle.com  Thu Jul  9 09:10:41 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2020 19:10:41 +1000
Subject: RFR(T): 8249097: test/lib/jdk/test/lib/util/JarBuilder.java has a
 bad copyright
In-Reply-To: <7b395b80-ce53-60ac-d52c-68a8e282cd24@oracle.com>
References: <468998e0-e37f-4be5-d841-d62dc7b2591f@oracle.com>
 <2D84F8BE-3DB0-4999-A8FE-E5A91475332B@oracle.com>
 <7b395b80-ce53-60ac-d52c-68a8e282cd24@oracle.com>
Message-ID: <bc5f37dd-f7ba-bddf-b442-3b60e19becc2@oracle.com>

On 9/07/2020 7:24 am, Daniel D. Daugherty wrote:
> Thanks for the fast review.
> 
> I was surprised that jcheck -r tip didn't flag that, but... :-)

jcheck doesn't check copyright lines or file headers.

Cheers,
David

> Dan
> 
> 
> On 7/8/20 5:23 PM, igor.ignatyev at oracle.com wrote:
>> LGTM, thanks for fixing, and sorry for introducing that.
>>
>> ? Igor
>>
>>> On Jul 8, 2020, at 2:22 PM, Daniel D. Daugherty 
>>> <daniel.daugherty at oracle.com> wrote:
>>>
>>> ?Greetings,
>>>
>>> A trivial fix to make the validate-header Tier1 task happy.
>>>
>>> Here's the context diff:
>>>
>>> $ hg diff -r qparent
>>> diff -r c5202ed40b86 test/lib/jdk/test/lib/util/JarBuilder.java
>>> --- a/test/lib/jdk/test/lib/util/JarBuilder.java??? Wed Jul 08 
>>> 20:35:36 2020 +0100
>>> +++ b/test/lib/jdk/test/lib/util/JarBuilder.java??? Wed Jul 08 
>>> 17:20:01 2020 -0400
>>> @@ -1,5 +1,5 @@
>>> ? /*
>>> - * Copyright (c) 2015, 2020 Oracle and/or its affiliates. All rights 
>>> reserved.
>>> + * Copyright (c) 2015, 2020, 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
>>>
>>>
>>> Thanks, in advance, for any comments, questions, or suggestions.
>>>
>>> Dan
>>>
> 

From daniel.fuchs at oracle.com  Thu Jul  9 09:16:46 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Jul 2020 10:16:46 +0100
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
Message-ID: <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>

Hi Koichi,

If you don't mind I'd prefer to keep the simple approach
that will fix the warning without changing the behavior
of the function.

         memset((char *)&if2, 0, sizeof(if2));
   -     strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
   +     strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
   +     if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

or at the very least use `strnlen` instead of `strlen`:

   if (sizeof(if2.ifr_name) < strnlen(name, sizeof(if2.ifr_name)) + 1) {
       return -1;
   }

that would be acceptable too.

best regards,

-- daniel

On 09/07/2020 08:48, Koichi Sakata wrote:
> Hi Daniel,
> 
> Thank you for your response.
> 
>  >? > +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>  >? > +??????? return -1;
>  >? > +??? }
>  >
>  > If I'm not mistaken `sizeof(name)` where name is a const char*
>  > will always be 8 (on 64 bits architecture) - so this is probably
>  > not doing what you want.
> 
> I'm sorry. That is my mistake.
> 
>  > Also you don't want to trust that `name` is null terminated.
>  > Calling strncpy in that case is much safer than calling strcpy
>  > even if guarded by strlen.
>  > I'm not sure what the compiler is warning you about here.
>  >
>  > I'd suggest to experiment changing:
>  >
>  >? >?????? memset((char *)&if2, 0, sizeof(if2));
>  >? > -???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>  >??? +???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>  >??? +???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
> I've written the code same as your suggestion. Certainly that can 
> resolve the warnings. But I think it could cut off the name in the 
> middle when length of the name longer than the if2.ifr_name length. I 
> would say I might as well return the error code under the circumstances. 
>  ?So I added the if statement. The code that reflect my intention 
> correctly is as follows.
> 
> 
> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
> b/src/java.base/unix/native/libnet/NetworkInterface.c
> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
> @@ -1295,8 +1295,13 @@
>  ? */
>  ?static int getIndex(int sock, const char *name) {
>  ???? struct ifreq if2;
> +
> +??? if (sizeof(if2.ifr_name) < strlen(name) + 1) {
> +??????? return -1;
> +??? }
> +
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
> +??? strcpy(if2.ifr_name, name);
> 
>  ???? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>  ???????? return -1;
> @@ -1358,8 +1363,13 @@
> 
>  ?static int getFlags(int sock, const char *ifname, int *flags) {
>  ???? struct ifreq if2;
> +
> +??? if (sizeof(if2.ifr_name) < strlen(ifname) + 1) {
> +??????? return -1;
> +??? }
> +
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
> +??? strcpy(if2.ifr_name, ifname);
> 
>  ???? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>  ???????? return -1;
> 
> 
> Thanks,
> Koichi
> 
> On 2020/07/08 2:57, Daniel Fuchs wrote:
>> Hi,
>>
>> I will not comment on the changes to libfdlibm/k_standard.c
>>
>> Concerning NetworkInterface.c I believe the proposed changes are
>> incorrect - and I do not see the issue with the current code.
>>
>> ?> +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>> ?> +??????? return -1;
>> ?> +??? }
>>
>> If I'm not mistaken `sizeof(name)` where name is a const char*
>> will always be 8 (on 64 bits architecture) - so this is probably
>> not doing what you want.
>>
>> Also you don't want to trust that `name` is null terminated.
>> Calling strncpy in that case is much safer than calling strcpy
>> even if guarded by strlen.
>> I'm not sure what the compiler is warning you about here.
>>
>> I'd suggest to experiment changing:
>>
>> ?>?????? memset((char *)&if2, 0, sizeof(if2));
>> ?> -???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>> ?? +???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>> ?? +???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>
>> and see if that makes the warning go away.
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 24/06/2020 08:48, Koichi Sakata wrote:
>>> Hi all,
>>>
>>> (I've sent a similar e-mail before to this ML, but I extract the part 
>>> only related to core-libs-dev ML from the previous one.)
>>>
>>> I tried to build OpenJDK fastdebug with GCC 10.1 on Ubuntu 18.04, but 
>>> I saw some compiler warnings as follows:
>>>
>>> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/: In 
>>> function '__j__kernel_standard':
>>> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/k_standard.c:743:19: 
>>> error: 'exc.retval' may be used uninitialized in this function 
>>> [-Werror=maybe-uninitialized]
>>> ?? 743 |???????? return exc.retval;
>>> ?????? |??????????????? ~~~^~~~~~~
>>>
>>> In file included from /usr/include/string.h:494,
>>> ????????????????? from 
>>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:30: 
>>>
>>> In function 'strncpy',
>>> ???? inlined from 'getFlags' at 
>>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:1362:5, 
>>>
>>> ???? inlined from 'addif' at 
>>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:974:13: 
>>>
>>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
>>> '__builtin_strncpy' output may be truncated copying 15 bytes from a 
>>> string of length 15 [-Werror=stringop-truncation]
>>> ?? 106 |?? return __builtin___strncpy_chk (__dest, __src, __len, 
>>> __bos (__dest));
>>> ?????? | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> I can resolve them with the following patch. I believe it fixes those 
>>> potential bugs, so I'd like to contribute it.
>>> (Our company has signed OCA.)
>>>
>>> Thanks,
>>> Koichi
>>>
>>> ===== PATCH =====
>>> diff -r 20d92fe3ac52 src/java.base/share/native/libfdlibm/k_standard.c
>>> --- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Jun 16 
>>> 03:16:41 2020 +0000
>>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c Thu Jun 18 
>>> 07:08:50 2020 +0900
>>> @@ -739,6 +739,10 @@
>>> ????????????????????????? errno = EDOM;
>>> ????????????????? }
>>> ????????????????? break;
>>> +??????????? default:
>>> +??????????????? exc.retval = zero;
>>> +??????????????? errno = EINVAL;
>>> +??????????????? break;
>>> ????????? }
>>> ????????? return exc.retval;
>>> ??}
>>> diff -r 20d92fe3ac52 src/java.base/unix/native/libnet/NetworkInterface.c
>>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c?????? Tue 
>>> Jun 16 03:16:41 2020 +0000
>>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c?????? Thu 
>>> Jun 18 07:08:50 2020 +0900
>>> @@ -1296,7 +1296,10 @@
>>> ??static int getIndex(int sock, const char *name) {
>>> ????? struct ifreq if2;
>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>>> +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>>> +??????? return -1;
>>> +??? }
>>> +??? strcpy(if2.ifr_name, name);
>>>
>>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>>> ????????? return -1;
>>> @@ -1359,7 +1362,10 @@
>>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>>> ????? struct ifreq if2;
>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>>> +??? if (sizeof(if2.ifr_name) < sizeof(ifname)) {
>>> +??????? return -1;
>>> +??? }
>>> +??? strcpy(if2.ifr_name, ifname);
>>>
>>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>>> ????????? return -1;
>>


From Roger.Riggs at oracle.com  Thu Jul  9 14:09:38 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 9 Jul 2020 10:09:38 -0400
Subject: RFR 15: 8217475: Unexpected StackOverflowError in "process
 reaper" thread
In-Reply-To: <f067b157-3c98-13cf-c1c7-8b4e18e5b537@oracle.com>
References: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
 <f067b157-3c98-13cf-c1c7-8b4e18e5b537@oracle.com>
Message-ID: <49d68029-7b16-2f60-8822-2dc34d346226@oracle.com>

Hi,

I raised the debugDelta to 16k and so far (12hrs) have not seen any 
failures.
I'll push later today with 16k unless I hear any concerns.

Webrev: 
http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475-1/

Thanks, Roger


On 7/9/20 4:54 AM, David Holmes wrote:
> Hi Roger,
>
> Looks good to me.
>
> Thanks,
> David
>
> On 9/07/2020 6:51 am, Roger Riggs wrote:
>> Please review a change to increase the size of the Process Reaper 
>> stack for debug builds.
>> This intermittent issue can be traced to the stack shadow page size 
>> being larger
>> in debug builds than in release builds. The problem has only been 
>> spotted in debug builds.
>>
>> diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java 
>> b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>> @@ -85,12 +85,16 @@
>> ????????????? doPrivileged((PrivilegedAction<Executor>) () -> {
>>
>> ????????????????? ThreadGroup tg = 
>> Thread.currentThread().getThreadGroup();
>> ????????????????? while (tg.getParent() != null) tg = tg.getParent();
>> ????????????????? ThreadGroup systemThreadGroup = tg;
>> +
>> +??????????????? // For a debug build, the stack shadow zone is larger;
>> +??????????????? // Increase the total stack size to avoid potential 
>> stack overflow.
>> +??????????????? int debugDelta = 
>> "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
>> ????????????????? final long stackSize = 
>> Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
>> -??????????????????????? ? 0 : REAPER_DEFAULT_STACKSIZE;
>> +??????????????????????? ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
>>
>> ????????????????? ThreadFactory threadFactory = grimReaper -> {
>> ????????????????????? Thread t = new Thread(systemThreadGroup, 
>> grimReaper,
>> ????????????????????????????? "process reaper", stackSize, false);
>> ????????????????????? t.setDaemon(true);
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/
>>
>> Issue:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8217475
>>
>> Thanks, Roger
>>


From li.jiang at oracle.com  Thu Jul  9 17:12:38 2020
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Fri, 10 Jul 2020 01:12:38 +0800
Subject: RFR: 8249086: JDK 15 L10n resource file update - msg drop 10
In-Reply-To: <6d8ce9ab-be80-9ba9-6654-d5769e0e8c93@oracle.com>
References: <908f05e3-c319-20dc-e65e-8d93182b6710@oracle.com>
 <6d8ce9ab-be80-9ba9-6654-d5769e0e8c93@oracle.com>
Message-ID: <59f48e9d-a01e-8596-381d-b6ff1f026a6b@oracle.com>

Thank you Naoto! The patch was pushed into jdk/jdk15.

Thanks,
Leo

On 7/9/20 3:53 AM, naoto.sato at oracle.com wrote:
> Hi Leo,
> 
> Looks good to me.
> 
> Naoto
> 
> On 7/8/20 10:58 AM, li.jiang at oracle.com wrote:
>> Hi,
>>
>> Pls review the l10n resource files update for JDK 15 msg drop 10.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8249086
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ljiang/8249086/read/
>>
>> Thanks,
>> Leo

From alexey at azul.com  Thu Jul  9 19:34:14 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 9 Jul 2020 19:34:14 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com>
 <c1ea5c0e-a647-b08a-c88b-159069cc70c2@oracle.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
Message-ID: <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>

Hello Sean, Daniel,

Thank you for review
I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file
and updated synchronisation using CompletableFuture.
Also, I have added new test cases : successful and unsuccessful TLS handshake,
synchronous and asynchronous TLS handshake.

New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13

Connection property is removed from CSR :
https://bugs.openjdk.java.net/browse/JDK-8247311

Regards
Alexey

> On 8 Jul 2020, at 17:41, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Thanks Sean, Alexey,
> 
> On 08/07/2020 13:25, Sean Mullan wrote:
>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/
>> You will also need to update the CSR to remove the connection timeout property.
>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1].
> 
> I have pushed the fix:
> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779
> 
> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype"
> property in that @implNote as well, and update your CSR
> consequently.
> 
>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever.
> 
> I also have a concern with the use of wait/notify in that code.
> I would suggest prototyping using a CompletableFuture instead
> (or can new certificates be exchanged later on the same
> connection?)
> 
> CompletableFuture would allow you to relay and propagate any
> exception raised in the callback handler as well, and would
> avoid running into deadlocks.
> 
> best regards,
> 
> -- daniel


From alexey.semenyuk at oracle.com  Thu Jul  9 19:49:32 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 9 Jul 2020 15:49:32 -0400
Subject: RFR: JDK-8247229: jpackage tests failed due to "semop(1):
 encountered an error: Invalid argument"
In-Reply-To: <bc834a38-c332-8c1d-60a4-1cbec08d1804@oracle.com>
References: <01ebf9e4-9049-b33d-e395-798706828b74@oracle.com>
 <fc52e413-13db-b152-dec9-223958b76f57@oracle.com>
 <bc834a38-c332-8c1d-60a4-1cbec08d1804@oracle.com>
Message-ID: <62aa3fe0-f3cc-7c7c-8d79-cf647d9ca576@oracle.com>

Hi Alexander,

Agreed with your suggestion. Updated review available at [1].

- Alexey

[1] http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.01/webrev.01/

On 7/9/2020 12:21 AM, alexander.matveev at oracle.com wrote:
> Hi Alexey,
>
> Looks good. Only suggestion is to move CmdlineExecutor to Executor 
> class and make it configurable for error message and probably attempts 
> and timeout in case if we need such functionality in other places.
>
> Thanks,
> Alexander
>
> On 7/8/20 6:37 PM, Alexey Semenyuk wrote:
>> Please review fix [2] for jpackage bug [1].
>>
>> Sometimes jpackage fails building .deb package due to failure of 
>> `fakeroot` command with the same error message printed in stderr: 
>> `semop(1): encountered an error: Invalid argument`.
>> The suggested fix is to rerun `fakeroot` command if it fails and the 
>> known error message is pritnted to stederr.
>>
>> - Alexey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8247229
>>
>> [2]?http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.00
>>
>


From andy.herrick at oracle.com  Thu Jul  9 20:25:36 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 9 Jul 2020 16:25:36 -0400
Subject: RFR: JDK-8247229: jpackage tests failed due to "semop(1):
 encountered an error: Invalid argument"
In-Reply-To: <62aa3fe0-f3cc-7c7c-8d79-cf647d9ca576@oracle.com>
References: <01ebf9e4-9049-b33d-e395-798706828b74@oracle.com>
 <fc52e413-13db-b152-dec9-223958b76f57@oracle.com>
 <bc834a38-c332-8c1d-60a4-1cbec08d1804@oracle.com>
 <62aa3fe0-f3cc-7c7c-8d79-cf647d9ca576@oracle.com>
Message-ID: <15daba04-6a16-6dcc-5fd2-88619508ea98@oracle.com>

looks good.

/Andy

On 7/9/2020 3:49 PM, Alexey Semenyuk wrote:
> Hi Alexander,
>
> Agreed with your suggestion. Updated review available at [1].
>
> - Alexey
>
> [1] http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.01/webrev.01/
>
> On 7/9/2020 12:21 AM, alexander.matveev at oracle.com wrote:
>> Hi Alexey,
>>
>> Looks good. Only suggestion is to move CmdlineExecutor to Executor 
>> class and make it configurable for error message and probably 
>> attempts and timeout in case if we need such functionality in other 
>> places.
>>
>> Thanks,
>> Alexander
>>
>> On 7/8/20 6:37 PM, Alexey Semenyuk wrote:
>>> Please review fix [2] for jpackage bug [1].
>>>
>>> Sometimes jpackage fails building .deb package due to failure of 
>>> `fakeroot` command with the same error message printed in stderr: 
>>> `semop(1): encountered an error: Invalid argument`.
>>> The suggested fix is to rerun `fakeroot` command if it fails and the 
>>> known error message is pritnted to stederr.
>>>
>>> - Alexey
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247229
>>>
>>> [2]?http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.00
>>>
>>
>

From lance.andersen at oracle.com  Thu Jul  9 20:57:06 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 9 Jul 2020 16:57:06 -0400
Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with
 Strings
In-Reply-To: <OF14D2225D.8CC159E9-ON00258598.001396E6-00258598.0019E2BC@notes.na.collabserv.com>
References: <OF44E9534D.C98F5761-ON00258588.00230443-00258588.0023044E@LocalDomain>
 <OF970BE434.A2955C5A-ON00258565.003F3EB3-00258565.003F3EB8@LocalDomain>
 <OF14D2225D.8CC159E9-ON00258598.001396E6-00258598.0019E2BC@notes.na.collabserv.com>
Message-ID: <B95309F0-A5C3-421D-9605-89EC4BECFE8C@oracle.com>

Hi Vipin,

Apologies for the delay.


After looking at the bug, which is over 14 years old, the SCCS history of Attributes.java, I am reluctant to suggest we move forward with your proposed change. 

 The  key for an Attributes map entry should be an Attributes.Name object (see Attributes::put). Unfortunately your proposed fix introduces a behavioral change and could possibly break existing applications.  


A  behavioral change to existing  public methods would require approval via a CSR and would require more compressive testing.   I took a quick scan of the JCK tests and of the JTReg tests and I believe your change would cause some of the existing tests to fail.

From my perspective, it would be better to clarify the Attributes javadoc to make it clearer that an Attributes.Name object is required   (which I believe has not changed since the Attributes class was added to Java SE).



Best
Lance



> On Jul 1, 2020, at 12:42 AM, Vipin Mv1 <vipinmv1 at in.ibm.com> wrote:
> 
> Hi,
> 
> A gentle reminder to please review this patch.
> 
> Thanks & Regards
> Vipin MV					 			
> 										 			
> 			 			
> 						
> 
> -----Vipin Mv1/India/IBM wrote: -----
> To: core-libs-dev at openjdk.java.net
> From: Vipin Mv1/India/IBM
> Date: 06/15/2020 11:52AM
> Subject: Re: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings
> 
> Hi,
> 
> I have addressed the review comments and the patch has been uploaded here:
> 
> http://cr.openjdk.java.net/~vtewari/6470126/webrev/index.html
> 
> Please let me know your suggestions.
> 
> Thanks & Regards					 			
> Vipin MV					 			
> 										 			
> 
> -----Vipin Mv1/India/IBM wrote: -----
> To: core-libs-dev at openjdk.java.net
> From: Vipin Mv1/India/IBM
> Date: 05/11/2020 05:00PM
> Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings
> 
> Hi,
> 
> Please review the fix for the following issue.
> 
> https://bugs.openjdk.java.net/browse/JDK-6470126
> 
> 
> diff -r 53568400fec3 src/java.base/share/classes/java/util/jar/Attributes.java
> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Mar 26 15:26:51 2020 +0000
> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Mon May 11 15:00:01 2020 +0530
> @@ -205,7 +205,10 @@
>      * @return true if this Map contains the specified attribute name
>      */
>     public boolean containsKey(Object name) {
> -        return map.containsKey(name);
> +        if(String.class.isInstance(name))
> +            return map.containsKey(Name.of((String)name));
> +        else
> +            return map.containsKey(name);
>     }
> 
>     /**
> 
> Thanks & Regards
> Vipin Menon
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From huizhe.wang at oracle.com  Thu Jul  9 22:23:50 2020
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Thu, 9 Jul 2020 15:23:50 -0700
Subject: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang
 private fields should be removed
Message-ID: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>

Hi,

Please review a patch to remove an illegal access to java.lang by the 
SafeThread. Note that InnocuousThread meets all the needs for SafeThread 
except that it also revokes permissions that the xml parser requires. 
This patch uses the new constructor added to Thread in JDK 9 that do not 
inherit inheritable thread-local initial values.


JBS: https://bugs.openjdk.java.net/browse/JDK-8248486

webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/


Thanks,

Joe


From alexander.matveev at oracle.com  Thu Jul  9 22:27:37 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Thu, 9 Jul 2020 15:27:37 -0700
Subject: RFR: JDK-8247229: jpackage tests failed due to "semop(1):
 encountered an error: Invalid argument"
In-Reply-To: <62aa3fe0-f3cc-7c7c-8d79-cf647d9ca576@oracle.com>
References: <01ebf9e4-9049-b33d-e395-798706828b74@oracle.com>
 <fc52e413-13db-b152-dec9-223958b76f57@oracle.com>
 <bc834a38-c332-8c1d-60a4-1cbec08d1804@oracle.com>
 <62aa3fe0-f3cc-7c7c-8d79-cf647d9ca576@oracle.com>
Message-ID: <d5c16494-0b72-60b3-b7b1-faa2ca79b278@oracle.com>

Hi Alexey,

Looks good.

Thanks,
Alexander

On 7/9/20 12:49 PM, Alexey Semenyuk wrote:
> Hi Alexander,
>
> Agreed with your suggestion. Updated review available at [1].
>
> - Alexey
>
> [1] http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.01/webrev.01/
>
> On 7/9/2020 12:21 AM, alexander.matveev at oracle.com wrote:
>> Hi Alexey,
>>
>> Looks good. Only suggestion is to move CmdlineExecutor to Executor 
>> class and make it configurable for error message and probably 
>> attempts and timeout in case if we need such functionality in other 
>> places.
>>
>> Thanks,
>> Alexander
>>
>> On 7/8/20 6:37 PM, Alexey Semenyuk wrote:
>>> Please review fix [2] for jpackage bug [1].
>>>
>>> Sometimes jpackage fails building .deb package due to failure of 
>>> `fakeroot` command with the same error message printed in stderr: 
>>> `semop(1): encountered an error: Invalid argument`.
>>> The suggested fix is to rerun `fakeroot` command if it fails and the 
>>> known error message is pritnted to stederr.
>>>
>>> - Alexey
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247229
>>>
>>> [2]?http://cr.openjdk.java.net/~asemenyuk/8247229/webrev.00
>>>
>>
>


From patrick.concannon at oracle.com  Fri Jul 10 14:33:57 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Fri, 10 Jul 2020 15:33:57 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8238286=5D=3A_=27Add_new_flatMap_stream_ope?=
 =?utf-8?Q?ration_that_is_more_amenable_to_pushing=E2=80=99?=
In-Reply-To: <68b0eb48-0d37-d625-c75e-bb182d6835c8@gmail.com>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <366194096.16591.1593041533516.JavaMail.zimbra@u-pem.fr>
 <b136531a-a4e7-2ba9-0bd1-6b24b2d955d8@oracle.com>
 <C11192DE-6818-42BA-8AC0-AA82E4552622@oracle.com>
 <823330165.575313.1593700255407.JavaMail.zimbra@u-pem.fr>
 <BB05BC9A-8AEE-4155-A4CE-A03A81B122FC@oracle.com>
 <c4ac4586-8897-a7e5-c397-e18ff19114bf@gmail.com>
 <68b0eb48-0d37-d625-c75e-bb182d6835c8@gmail.com>
Message-ID: <213479FD-4A9B-4162-9180-31FBA1D067FB@oracle.com>

Hi Peter,

Thanks for your feedback, and for pointing out these mistakes.

I?ve rectified this now, and you can find the latest changes in the new webrev and specdiff below.

webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.04/
specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.01/


Kind regards,
Patrick

> On 5 Jul 2020, at 09:21, Peter Levart <peter.levart at gmail.com> wrote:
> 
> ...also note that examples in the Stream javadoc comments, like for example:
> 
> 
> 
>  385      * <pre>{@code
>  386      *     numbers.mapMulti((Consumer<Integer> c, Number n) -> {
>  387      *         if (n instanceof Integer)
>  388      *             c.accept((Integer) n);
>  389      *     });
>  390      * }</pre>
> 
> 
> 
> ...have the arguments (Consumer, element) still wrong. They are swapped now as of latest webrev.03:
> 
> 
> 
>  422     default <R> Stream<R> mapMulti(BiConsumer<? super T, ? super Consumer<R>> mapper) {
> 
> 
> Regards, Peter
> 
> 
> 
> On 7/5/20 10:00 AM, Peter Levart wrote:
>> Hi Patrick, 
>> 
>> 
>> In the test(s), you often use sink::accept: 
>> 
>> 
>>         exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).forEach(sink::accept))); 
>> 
>> 
>> ...where you could simply pass just sink: 
>> 
>> 
>>         exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).forEach(sink))); 
>> 
>> 
>> Is this intentional and why? 
>> 
>> 
>> Regards, Peter 
>> 
>> 
>> On 7/2/20 6:45 PM, Patrick Concannon wrote: 
>>> Hi Remi, 
>>> 
>>> Well spotted on the bad link. I?ve updated that now. 
>>> 
>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/>
>>> 
>>> As for the placement of the new FIs, it was decided that once we can use primitive types in generics the need for these interfaces will hopefully fade, and it was deemed better to keep them closer together for this reason. This approach also has the benefit of reducing the exposure / footprint of the general functional interfaces. 
>>> 
>>> Kind regards, 
>>> 
>>> Patrick 
>>> 
>>> 
>>>> On 2 Jul 2020, at 15:30, Remi Forax <forax at univ-mlv.fr> <mailto:forax at univ-mlv.fr> wrote: 
>>>> 
>>>> Hi Patrick & Julia, 
>>>> this version starts to look good. 
>>>> 
>>>> I just don't understand why the new functional interfaces are not in java.util.function like the other ones ? 
>>>> (BTW, in the javadoc, the link to the summary overview point to the wrong one, to java.util.stream and not java.util.function). 
>>>> 
>>>> About the examples, i will try to think about that this evening :) 
>>>> 
>>>> regards, 
>>>> R?mi 
>>>> 
>>>> ----- Mail original ----- 
>>>>> De: "Patrick Concannon" <patrick.concannon at oracle.com> <mailto:patrick.concannon at oracle.com> 
>>>>> ?: "Julia Boes" <julia.boes at oracle.com> <mailto:julia.boes at oracle.com> 
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> <mailto:core-libs-dev at openjdk.java.net> 
>>>>> Envoy?: Jeudi 2 Juillet 2020 15:30:45 
>>>>> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing? 
>>>>> Hi, 
>>>>> 
>>>>> John: Thanks for your feedback. We've rearranged the ordering of the parameters 
>>>>> of the BiConsumer to follow the convention you suggested, and hopefully improve 
>>>>> readability going forward. Additional FIs (IntObjConsumer, etc.) have been 
>>>>> added as sub-interfaces to the corresponding Stream classes i.e. {Int, Double, 
>>>>> Long}Stream. 
>>>>> 
>>>>> Remi: Your argument makes sense, and we have updated the BiConsumers generic 
>>>>> type to `<? super Consumer<R>>` as you suggested. Thanks for pointing this out. 
>>>>> We have also removed the caching. 
>>>>> WRT to the wrappers used in the examples: good examples are tough to nail down. 
>>>>> We think the examples in their current form do a good job of demonstrating how 
>>>>> the method can be used, but we welcome any alternative suggestions. 
>>>>> 
>>>>> 
>>>>> The changes discussed can be found in the updated webrev below. 
>>>>> 
>>>>> http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> 
>>>>> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.02/> 
>>>>> 
>>>>> 
>>>>> Kind regards, 
>>>>> 
>>>>> Patrick 
>>>>> 
>>>>>> On 26 Jun 2020, at 17:46, Julia Boes <julia.boes at oracle.com> <mailto:julia.boes at oracle.com> wrote: 
>>>>>> 
>>>>>> w 


From chris.hegarty at oracle.com  Fri Jul 10 16:38:15 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 10 Jul 2020 17:38:15 +0100
Subject: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang
 private fields should be removed
In-Reply-To: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
Message-ID: <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>



> On 9 Jul 2020, at 23:23, huizhe.wang at oracle.com wrote:
> 
> ...
> 
> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/
> 
Looks good. Reviewed.

-Chris.

From aleksej.efimov at oracle.com  Fri Jul 10 16:40:32 2020
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Fri, 10 Jul 2020 17:40:32 +0100
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
Message-ID: <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>

Hi Alexey,

Thank you for removing the dependency on the timeout property and adding 
tests for TLS handshake cases.

Please, find the comments about the latest webrev below:

Not quite sure why the CF is completed at two places. Probably that?s 
OK, but it would be good to know the reason :)

The ExecutionException could be unpacked instead of using it directly - 
and its cause used instead.

'getTlsServerCertificate' should return null if 'isTlsConnection()' is 
false - rather than waiting forever.

java.naming/share/classes/module-info.java: could we try to improve the 
formatting of the possible values for the new system property - maybe 
format them as a list.

Connection.java:995 - you could use diamond operator here

Formatting: Connection.java:1027 'catch ('

Could we use the test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java from 
the test library to implement dummy LDAPS server, I believe it could 
help to increase the test verbosity and reduce its code size.

LdapCBPropertiesTest.java:122 - could use no param Hastable constructor

I've also run your latest patch through our CI system and it showed no 
failures with your latest changes.

-Aleksei

On 09/07/2020 20:34, Alexey Bakhtin wrote:
> Hello Sean, Daniel,
>
> Thank you for review
> I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file
> and updated synchronisation using CompletableFuture.
> Also, I have added new test cases : successful and unsuccessful TLS handshake,
> synchronous and asynchronous TLS handshake.
>
> New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13
>
> Connection property is removed from CSR :
> https://bugs.openjdk.java.net/browse/JDK-8247311
>
> Regards
> Alexey
>
>> On 8 Jul 2020, at 17:41, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Thanks Sean, Alexey,
>>
>> On 08/07/2020 13:25, Sean Mullan wrote:
>>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/
>>> You will also need to update the CSR to remove the connection timeout property.
>>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1].
>> I have pushed the fix:
>> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779
>>
>> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype"
>> property in that @implNote as well, and update your CSR
>> consequently.
>>
>>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
>>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever.
>> I also have a concern with the use of wait/notify in that code.
>> I would suggest prototyping using a CompletableFuture instead
>> (or can new certificates be exchanged later on the same
>> connection?)
>>
>> CompletableFuture would allow you to relay and propagate any
>> exception raised in the callback handler as well, and would
>> avoid running into deadlocks.
>>
>> best regards,
>>
>> -- daniel


From mandy.chung at oracle.com  Fri Jul 10 16:59:36 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Jul 2020 09:59:36 -0700
Subject: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang
 private fields should be removed
In-Reply-To: <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
Message-ID: <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>

Hi Joe,

The change looks good.?? You can consider using AtomicInteger for the 
thread number.? Looks like this is the only use of jdk.internal.misc 
from java.xml.?? You can remove the qualified exports from java.base to 
java.xml.

$ ./bin/jdeps -verbose:class -p jdk.internal.misc modules/java.xml
java.xml
:
java.xml -> java.base
 ?? com.sun.org.apache.xml.internal.utils.SafeThread?? -> 
jdk.internal.misc.Unsafe?????????????????????????? java.base (qualified)

Mandy

On 7/10/20 9:38 AM, Chris Hegarty wrote:
>
>> On 9 Jul 2020, at 23:23, huizhe.wang at oracle.com wrote:
>>
>> ...
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/
>>
> Looks good. Reviewed.
>
> -Chris.


From dmitry.chuyko at bell-sw.com  Fri Jul 10 18:11:36 2020
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Fri, 10 Jul 2020 21:11:36 +0300
Subject: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative
 numbers
Message-ID: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>

Hello,

Please review a small change in Math.signum(double d) and 
Math.signum(float f) that improves performance for positive and negative 
numbers.

Current version first checks if the number is NaN or zero, and for all 
other numbers it extracts sign bit and constructs fp result. That makes 
all regular numbers case ~1.2-1.5x slower than two special number cases.

Improved version checks for regular number cases first, and does not use 
bit extraction. For positive and negative double numbers improvement is 
~1.31-1.47x, for floats it is 1.06-1.46x. Micro-benchmark results are 
provided for tiered C2 on x86_64 and aarch64. For NaN and zero we see 
~1.00-1.26x slowdown in same conditions.

Please find benchmarks and results in the webrev.

rfe: https://bugs.openjdk.java.net/browse/JDK-8249198

webrev: http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/

results: http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/results.txt

testing: JCK tests, jtreg tests on different platforms.

-Dmitry


From joe.darcy at oracle.com  Fri Jul 10 19:06:41 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 10 Jul 2020 12:06:41 -0700
Subject: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative
 numbers
In-Reply-To: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>
References: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>
Message-ID: <cdbe7c3f-2ab2-332f-1d0c-dfb0bb505c28@oracle.com>

Hello,

The comment

+??????? // NaN is here by JLS 15.20.1

is not correct; either NaN or (signed) zero is present at that point in 
the code.

-Joe

On 7/10/2020 11:11 AM, Dmitry Chuyko wrote:
> Hello,
>
> Please review a small change in Math.signum(double d) and 
> Math.signum(float f) that improves performance for positive and 
> negative numbers.
>
> Current version first checks if the number is NaN or zero, and for all 
> other numbers it extracts sign bit and constructs fp result. That 
> makes all regular numbers case ~1.2-1.5x slower than two special 
> number cases.
>
> Improved version checks for regular number cases first, and does not 
> use bit extraction. For positive and negative double numbers 
> improvement is ~1.31-1.47x, for floats it is 1.06-1.46x. 
> Micro-benchmark results are provided for tiered C2 on x86_64 and 
> aarch64. For NaN and zero we see ~1.00-1.26x slowdown in same conditions.
>
> Please find benchmarks and results in the webrev.
>
> rfe: https://bugs.openjdk.java.net/browse/JDK-8249198
>
> webrev: http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/
>
> results: 
> http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/results.txt
>
> testing: JCK tests, jtreg tests on different platforms.
>
> -Dmitry
>

From dmitry.chuyko at bell-sw.com  Fri Jul 10 19:29:04 2020
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Fri, 10 Jul 2020 22:29:04 +0300
Subject: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative
 numbers
In-Reply-To: <cdbe7c3f-2ab2-332f-1d0c-dfb0bb505c28@oracle.com>
References: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>
 <cdbe7c3f-2ab2-332f-1d0c-dfb0bb505c28@oracle.com>
Message-ID: <5d490a22-28ec-54c5-17cc-b4d6fc2ec5e8@bell-sw.com>

Joe, thanks for taking a look on that.

Would something like "Here d is either (signed) zero or NaN (JLS 
15.20.1)" make more sense?

-Dmitry

On 7/10/20 10:06 PM, Joe Darcy wrote:
> Hello,
>
> The comment
>
> +??????? // NaN is here by JLS 15.20.1
>
> is not correct; either NaN or (signed) zero is present at that point 
> in the code.
>
> -Joe
>
> On 7/10/2020 11:11 AM, Dmitry Chuyko wrote:
>> Hello,
>>
>> Please review a small change in Math.signum(double d) and 
>> Math.signum(float f) that improves performance for positive and 
>> negative numbers.
>>
>> Current version first checks if the number is NaN or zero, and for 
>> all other numbers it extracts sign bit and constructs fp result. That 
>> makes all regular numbers case ~1.2-1.5x slower than two special 
>> number cases.
>>
>> Improved version checks for regular number cases first, and does not 
>> use bit extraction. For positive and negative double numbers 
>> improvement is ~1.31-1.47x, for floats it is 1.06-1.46x. 
>> Micro-benchmark results are provided for tiered C2 on x86_64 and 
>> aarch64. For NaN and zero we see ~1.00-1.26x slowdown in same 
>> conditions.
>>
>> Please find benchmarks and results in the webrev.
>>
>> rfe: https://bugs.openjdk.java.net/browse/JDK-8249198
>>
>> webrev: http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/
>>
>> results: 
>> http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/results.txt
>>
>> testing: JCK tests, jtreg tests on different platforms.
>>
>> -Dmitry
>>

From joe.darcy at oracle.com  Fri Jul 10 20:28:30 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 10 Jul 2020 13:28:30 -0700
Subject: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative
 numbers
In-Reply-To: <5d490a22-28ec-54c5-17cc-b4d6fc2ec5e8@bell-sw.com>
References: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>
 <cdbe7c3f-2ab2-332f-1d0c-dfb0bb505c28@oracle.com>
 <5d490a22-28ec-54c5-17cc-b4d6fc2ec5e8@bell-sw.com>
Message-ID: <b20ab38e-119c-43a4-558d-15cb59727312@oracle.com>

Hi Dmitry,

On 7/10/2020 12:29 PM, Dmitry Chuyko wrote:
> Joe, thanks for taking a look on that.
>
> Would something like "Here d is either (signed) zero or NaN (JLS 
> 15.20.1)" make more sense?

That would be a correct statement. However, rather than referring to the 
JLS in this case, I suggesting stating the relevant information 
directly, something like:

return d; // Signed zeros and NaN are neither greater than zero nor less 
than zero.

Looking over the existing regression tests, I believe they are 
sufficient for the new implementation.

I'll leave it to others to review the benchmarks.

Thanks,

-Joe


>
> -Dmitry
>
> On 7/10/20 10:06 PM, Joe Darcy wrote:
>> Hello,
>>
>> The comment
>>
>> +??????? // NaN is here by JLS 15.20.1
>>
>> is not correct; either NaN or (signed) zero is present at that point 
>> in the code.
>>
>> -Joe
>>
>> On 7/10/2020 11:11 AM, Dmitry Chuyko wrote:
>>> Hello,
>>>
>>> Please review a small change in Math.signum(double d) and 
>>> Math.signum(float f) that improves performance for positive and 
>>> negative numbers.
>>>
>>> Current version first checks if the number is NaN or zero, and for 
>>> all other numbers it extracts sign bit and constructs fp result. 
>>> That makes all regular numbers case ~1.2-1.5x slower than two 
>>> special number cases.
>>>
>>> Improved version checks for regular number cases first, and does not 
>>> use bit extraction. For positive and negative double numbers 
>>> improvement is ~1.31-1.47x, for floats it is 1.06-1.46x. 
>>> Micro-benchmark results are provided for tiered C2 on x86_64 and 
>>> aarch64. For NaN and zero we see ~1.00-1.26x slowdown in same 
>>> conditions.
>>>
>>> Please find benchmarks and results in the webrev.
>>>
>>> rfe: https://bugs.openjdk.java.net/browse/JDK-8249198
>>>
>>> webrev: http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/
>>>
>>> results: 
>>> http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/results.txt
>>>
>>> testing: JCK tests, jtreg tests on different platforms.
>>>
>>> -Dmitry
>>>

From alexey at azul.com  Fri Jul 10 20:37:26 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Fri, 10 Jul 2020 20:37:26 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com>
 <A85B0F6A-6B80-4DD0-9AD3-2E1BE9150579@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
 <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
Message-ID: <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>

Hello Aleksei,

Thank you for review.
Please see my comments below.

Updated webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/

Regards
Alexey

> On 10 Jul 2020, at 19:40, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> Hi Alexey,
> 
> Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases.
> 
> Please, find the comments about the latest webrev below:
> 
> Not quite sure why the CF is completed at two places. Probably that?s OK, but it would be good to know the reason :)

HandshakeCompletedListener is called in case of successful handshake only.
In case of async handshake failed we close the connection and complete CF exceptionally to release CF.get()

> 
> The ExecutionException could be unpacked instead of using it directly - and its cause used instead.

Thank you. Fixed in Connection.java and LdapCBPropertiesTest.java
> 
> 'getTlsServerCertificate' should return null if 'isTlsConnection()' is false - rather than waiting forever.

We call isTlsConnection() in the LdapSasl before getTlsServerCertificate().
But your are right, we can double check it to prevent possible deadlock in the future, if code changed.
Fixed in Connection.java

> 
> java.naming/share/classes/module-info.java: could we try to improve the formatting of the possible values for the new system property - maybe format them as a list.
Done
> 
> Connection.java:995 - you could use diamond operator here
Updated
> 
> Formatting: Connection.java:1027 'catch (?
Updated
> 
> Could we use the test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java from the test library to implement dummy LDAPS server, I believe it could help to increase the test verbosity and reduce its code size.
Thank you for suggestion. Updated to use BaseLdapServer in the test

> 
> LdapCBPropertiesTest.java:122 - could use no param Hastable constructor
Fixed
> 
> I've also run your latest patch through our CI system and it showed no failures with your latest changes.
> 
> -Aleksei
> 
> On 09/07/2020 20:34, Alexey Bakhtin wrote:
>> Hello Sean, Daniel,
>> 
>> Thank you for review
>> I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file
>> and updated synchronisation using CompletableFuture.
>> Also, I have added new test cases : successful and unsuccessful TLS handshake,
>> synchronous and asynchronous TLS handshake.
>> 
>> New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13
>> 
>> Connection property is removed from CSR :
>> https://bugs.openjdk.java.net/browse/JDK-8247311
>> 
>> Regards
>> Alexey
>> 
>>> On 8 Jul 2020, at 17:41, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Thanks Sean, Alexey,
>>> 
>>> On 08/07/2020 13:25, Sean Mullan wrote:
>>>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/
>>>> You will also need to update the CSR to remove the connection timeout property.
>>>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1].
>>> I have pushed the fix:
>>> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779
>>> 
>>> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype"
>>> property in that @implNote as well, and update your CSR
>>> consequently.
>>> 
>>>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
>>>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever.
>>> I also have a concern with the use of wait/notify in that code.
>>> I would suggest prototyping using a CompletableFuture instead
>>> (or can new certificates be exchanged later on the same
>>> connection?)
>>> 
>>> CompletableFuture would allow you to relay and propagate any
>>> exception raised in the callback handler as well, and would
>>> avoid running into deadlocks.
>>> 
>>> best regards,
>>> 
>>> -- daniel


From brian.burkhalter at oracle.com  Fri Jul 10 20:56:41 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 10 Jul 2020 13:56:41 -0700
Subject: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative
 numbers
In-Reply-To: <b20ab38e-119c-43a4-558d-15cb59727312@oracle.com>
References: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>
 <cdbe7c3f-2ab2-332f-1d0c-dfb0bb505c28@oracle.com>
 <5d490a22-28ec-54c5-17cc-b4d6fc2ec5e8@bell-sw.com>
 <b20ab38e-119c-43a4-558d-15cb59727312@oracle.com>
Message-ID: <08BAB668-84AB-4744-B1E2-0038AA6AF050@oracle.com>

Hi Dmitry,

Regarding the benchmarks [1], I was curious as to why you chose to use the reduce() method, which inside it loops over invocations of signum(), given the considerations discussed in the sample JMHSample_11_Loops.java [2]? Is that in order to force inlining? I have not used the @CompilerControl annotation.

Thanks,

Brian

[1] http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/test/micro/org/openjdk/bench/java/lang/DoubleSignum.java.html
http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/test/micro/org/openjdk/bench/java/lang/FloatSignum.java.html
[2] https://hg.openjdk.java.net/code-tools/jmh/file/4a420afe8a9e/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_11_Loops.java

> On Jul 10, 2020, at 1:28 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> I'll leave it to others to review the benchmarks.


From huizhe.wang at oracle.com  Fri Jul 10 21:25:09 2020
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Fri, 10 Jul 2020 14:25:09 -0700
Subject: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang
 private fields should be removed
In-Reply-To: <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
Message-ID: <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>

Thanks Chris, Roger, and Mandy.? I've updated the webrev using 
AtomicInteger and removing java.base export.

Here's the updated webrev:

http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/

-Joe


On 7/10/20 9:59 AM, Mandy Chung wrote:
> Hi Joe,
>
> The change looks good.?? You can consider using AtomicInteger for the 
> thread number.? Looks like this is the only use of jdk.internal.misc 
> from java.xml.?? You can remove the qualified exports from java.base 
> to java.xml.
>
> $ ./bin/jdeps -verbose:class -p jdk.internal.misc modules/java.xml
> java.xml
> :
> java.xml -> java.base
> ?? com.sun.org.apache.xml.internal.utils.SafeThread?? -> 
> jdk.internal.misc.Unsafe?????????????????????????? java.base (qualified)
>
> Mandy
>
> On 7/10/20 9:38 AM, Chris Hegarty wrote:
>>
>>> On 9 Jul 2020, at 23:23, huizhe.wang at oracle.com wrote:
>>>
>>> ...
>>>
>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/
>>>
>> Looks good. Reviewed.
>>
>> -Chris.
>

From mandy.chung at oracle.com  Fri Jul 10 22:02:57 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Jul 2020 15:02:57 -0700
Subject: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang
 private fields should be removed
In-Reply-To: <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
 <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
Message-ID: <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>



On 7/10/20 2:25 PM, huizhe.wang at oracle.com wrote:
> Thanks Chris, Roger, and Mandy.? I've updated the webrev using 
> AtomicInteger and removing java.base export.
>
> Here's the updated webrev:
>
> http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/

Looks good.

Mandy

From andy.herrick at oracle.com  Fri Jul 10 22:29:25 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 10 Jul 2020 18:29:25 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <e55fabfc-7b86-7d66-aaa9-7fe6e97a8e25@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
 <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>
 <312cfde4-afc4-83b9-9e51-85b0a9f5b47f@oracle.com>
 <8964d112-015c-e376-3900-b01b8406bcd0@oracle.com>
 <e55fabfc-7b86-7d66-aaa9-7fe6e97a8e25@oracle.com>
Message-ID: <34a37821-07b5-9c59-a558-126bef1e3b92@oracle.com>

looks good.

/Andy

On 7/9/2020 12:02 AM, alexander.matveev at oracle.com wrote:
> Hi Alexey,
>
> http://cr.openjdk.java.net/~almatvee/8248261/webrev.01/
>
> - Added fatalError() to log fatal errors without timestamp.
> - Added missing timestamp to Log.verbose(Throwable t).
>
> Thanks,
> Alexander
>
> On 7/8/20 9:34 AM, Alexey Semenyuk wrote:
>> I still think it would be good to create dedicated method for final 
>> error reporting in Main and Arguments classes without timestamps.
>>
>> - Alexey
>>
>> On 7/8/2020 9:59 AM, Andy Herrick wrote:
>>> After further discussion, I approve this change as is.
>>>
>>> The main fatal error in Arguments.processArguments() only calls 
>>> Log.error if not verbose , so guarding it from having a timestamp 
>>> when verbose is not an issue.
>>>
>>> /Andy
>>>
>>> On 7/7/2020 7:20 PM, Andy Herrick wrote:
>>>> I agree - but I would rather then that Log.error() never show 
>>>> timestamp.
>>>>
>>>> It would be better still if we could differentiate fatal error 
>>>> messages from warning messages - right now we are using Log.error 
>>>> for both.
>>>>
>>>> /Andy
>>>>
>>>>
>>>> On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
>>>>> Hi Andy,
>>>>>
>>>>> Timestamps for error message without verbose output are 
>>>>> meaningless in my opinion. This is why I did not add them. Also, 
>>>>> in some cases output does not look right. For example when 
>>>>> timestamp is added to error message always:
>>>>> jpackage --someoption
>>>>> WARNING: Using incubator modules: jdk.incubator.jpackage
>>>>> [15:49:23.798] Error: Invalid Option: [--someoption]
>>>>>
>>>>> In example above I do not see any point to have timestamp.
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>>>
>>>>> On 7/7/20 6:18 AM, Andy Herrick wrote:
>>>>>> All looks good, except maybe Log.error().
>>>>>>
>>>>>> I think Log.error() should have the same output whether verbose 
>>>>>> or not, adding timestamp to the message only if verbose does not 
>>>>>> look right.
>>>>>>
>>>>>> Problem is that Log.error() is used for two fundamentally 
>>>>>> different purposes:
>>>>>>
>>>>>> 1.) by Main and Arguments to display the final error message when 
>>>>>> jpackage is failing.
>>>>>>
>>>>>> 2.) by everyone else to display a serious warning message when 
>>>>>> jpackage is continuing (sometimes failing further on, and 
>>>>>> sometimes not).
>>>>>>
>>>>>> I wouldn't mind adding timestamps only when verbose in case (2), 
>>>>>> but I don't think that's appropriate for case (1).
>>>>>>
>>>>>> /ANdy
>>>>>>
>>>>>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>>>>>> Please review the jpackage fix for bug [1] at [2].
>>>>>>>
>>>>>>> Added timestamp to verbose and test output in form of 
>>>>>>> [HH:mm:ss.SSS].
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>>>>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander
>>>>>
>>
>

From david.holmes at oracle.com  Sat Jul 11 13:28:01 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Jul 2020 23:28:01 +1000
Subject: RFR 15: 8217475: Unexpected StackOverflowError in "process
 reaper" thread
In-Reply-To: <49d68029-7b16-2f60-8822-2dc34d346226@oracle.com>
References: <f0ca0ce7-0687-f291-64d5-6f982b3c99da@oracle.com>
 <f067b157-3c98-13cf-c1c7-8b4e18e5b537@oracle.com>
 <49d68029-7b16-2f60-8822-2dc34d346226@oracle.com>
Message-ID: <cf10c811-5f58-0658-9155-df317603a1ab@oracle.com>



On 10/07/2020 12:09 am, Roger Riggs wrote:
> Hi,
> 
> I raised the debugDelta to 16k and so far (12hrs) have not seen any 
> failures.
> I'll push later today with 16k unless I hear any concerns.
> 
> Webrev: 
> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475-1/

Unfortunately failures are still happening after the push.

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

David
-----

> Thanks, Roger
> 
> 
> On 7/9/20 4:54 AM, David Holmes wrote:
>> Hi Roger,
>>
>> Looks good to me.
>>
>> Thanks,
>> David
>>
>> On 9/07/2020 6:51 am, Roger Riggs wrote:
>>> Please review a change to increase the size of the Process Reaper 
>>> stack for debug builds.
>>> This intermittent issue can be traced to the stack shadow page size 
>>> being larger
>>> in debug builds than in release builds. The problem has only been 
>>> spotted in debug builds.
>>>
>>> diff a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java 
>>> b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>>> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>>> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java
>>> @@ -85,12 +85,16 @@
>>> ????????????? doPrivileged((PrivilegedAction<Executor>) () -> {
>>>
>>> ????????????????? ThreadGroup tg = 
>>> Thread.currentThread().getThreadGroup();
>>> ????????????????? while (tg.getParent() != null) tg = tg.getParent();
>>> ????????????????? ThreadGroup systemThreadGroup = tg;
>>> +
>>> +??????????????? // For a debug build, the stack shadow zone is larger;
>>> +??????????????? // Increase the total stack size to avoid potential 
>>> stack overflow.
>>> +??????????????? int debugDelta = 
>>> "release".equals(System.getProperty("jdk.debug")) ? 0 : 8192;
>>> ????????????????? final long stackSize = 
>>> Boolean.getBoolean("jdk.lang.processReaperUseDefaultStackSize")
>>> -??????????????????????? ? 0 : REAPER_DEFAULT_STACKSIZE;
>>> +??????????????????????? ? 0 : REAPER_DEFAULT_STACKSIZE + debugDelta;
>>>
>>> ????????????????? ThreadFactory threadFactory = grimReaper -> {
>>> ????????????????????? Thread t = new Thread(systemThreadGroup, 
>>> grimReaper,
>>> ????????????????????????????? "process reaper", stackSize, false);
>>> ????????????????????? t.setDaemon(true);
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-process-stackoverflow-8217475/
>>>
>>> Issue:
>>> ??? https://bugs.openjdk.java.net/browse/JDK-8217475
>>>
>>> Thanks, Roger
>>>
> 

From dmitry.chuyko at bell-sw.com  Sun Jul 12 11:44:33 2020
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Sun, 12 Jul 2020 14:44:33 +0300
Subject: RFR(S): 8249198: Faster Math.signum(fp) for positive and negative
 numbers
In-Reply-To: <08BAB668-84AB-4744-B1E2-0038AA6AF050@oracle.com>
References: <834fccdc-3cc7-3b5a-d000-62592fbd8a10@bell-sw.com>
 <cdbe7c3f-2ab2-332f-1d0c-dfb0bb505c28@oracle.com>
 <5d490a22-28ec-54c5-17cc-b4d6fc2ec5e8@bell-sw.com>
 <b20ab38e-119c-43a4-558d-15cb59727312@oracle.com>
 <08BAB668-84AB-4744-B1E2-0038AA6AF050@oracle.com>
Message-ID: <ef29dc98-66da-43e0-af0f-e6a473a64636@bell-sw.com>

Hello,

After much more thorough analysis of benchmarks on different platforms I 
tend to cancel this patch proposal.

As Brian rightly remarked [3], the benchmark has peculiar explicit 
iteration over the data. This is more like 2nd anti-pattern in safe 
looping JMH sample [4]. This actually came out of larger experiment in 
Lucene geo-search. But canonical case like [5] is also important.

For micro-benchmarks with any kind of safe looping, there can be a 
degradation up to 7x. It is caused by spilling/re-materialization of 
registers that hold constants when they are alive around the call (good 
case benefits when they are moved out of loops).

The possible other way to improve singnum should probably be platform 
specific.

Joe and Brian, thanks again for taking a look.

[3] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067671.html

[4] 
https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_34_SafeLooping.java

[5] http://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java

On 7/10/20 11:56 PM, Brian Burkhalter wrote:
> Hi Dmitry,
>
> Regarding the benchmarks [1], I was curious as to why you chose to use 
> the reduce() method, which inside it loops over invocations of 
> signum(), given the considerations discussed in the sample 
> JMHSample_11_Loops.java [2]? Is that in order to force inlining? I 
> have not used the @CompilerControl annotation.
>
> Thanks,
>
> Brian
>
> [1] 
> http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/test/micro/org/openjdk/bench/java/lang/DoubleSignum.java.html
> http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/test/micro/org/openjdk/bench/java/lang/FloatSignum.java.html
> [2] 
> https://hg.openjdk.java.net/code-tools/jmh/file/4a420afe8a9e/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_11_Loops.java 
>
>
>> On Jul 10, 2020, at 1:28 PM, Joe Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> I'll leave it to others to review the benchmarks.
>

From huizhe.wang at oracle.com  Sun Jul 12 22:21:32 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Sun, 12 Jul 2020 15:21:32 -0700
Subject: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread illegal
 access to java.lang private fields should be removed
In-Reply-To: <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
 <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
 <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>
Message-ID: <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>

Hi all,

Alan updated the bug to indicate it fails since JDK 9. Given we still 
have a couple days for JDK 15, I've rebased the patch to the jdk15 repo 
and would like to check in the patch into JDK 15 instead (and let it be 
sync-ed to 16). Here's the webrev for JDK 15:

http://cr.openjdk.java.net/~joehw/jdk15/8248486/webrev/

No change to the SafeThread. The change to module-info.java was made by 
deleting java.xml from its JDK15 version. Please review.

Thanks,
Joe

On 7/10/2020 3:02 PM, Mandy Chung wrote:
>
>
> On 7/10/20 2:25 PM, huizhe.wang at oracle.com wrote:
>> Thanks Chris, Roger, and Mandy.? I've updated the webrev using 
>> AtomicInteger and removing java.base export.
>>
>> Here's the updated webrev:
>>
>> http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/
>
> Looks good.
>
> Mandy


From Alan.Bateman at oracle.com  Mon Jul 13 06:11:09 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Jul 2020 07:11:09 +0100
Subject: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread
 illegal access to java.lang private fields should be removed
In-Reply-To: <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
 <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
 <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>
 <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>
Message-ID: <fb4d5e85-5c3e-9888-0db8-9dbe50776b47@oracle.com>

On 12/07/2020 23:21, Joe Wang wrote:
> Hi all,
>
> Alan updated the bug to indicate it fails since JDK 9. Given we still 
> have a couple days for JDK 15, I've rebased the patch to the jdk15 
> repo and would like to check in the patch into JDK 15 instead (and let 
> it be sync-ed to 16). Here's the webrev for JDK 15:
>
> http://cr.openjdk.java.net/~joehw/jdk15/8248486/webrev/
>
> No change to the SafeThread. The change to module-info.java was made 
> by deleting java.xml from its JDK15 version. Please review.
I was curious how we didn't spot this in JDK 9 but it's using Unsafe to 
get an offset to these fields so that explains it. Good to get this 
technical debt fixed as there is no guarantee that the hack will work in 
the future. I don't think there is any urgency for JDK 15 though, fixing 
it in the main line for JDK 16 is fine.

-Alan

From sakatakui at oss.nttdata.com  Mon Jul 13 07:03:07 2020
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Mon, 13 Jul 2020 16:03:07 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
Message-ID: <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>

Hi Daniel,

On 2020/07/09 18:16, Daniel Fuchs wrote:
 > Hi Koichi,
 >
 > If you don't mind I'd prefer to keep the simple approach
 > that will fix the warning without changing the behavior
 > of the function.

I understand that. I respect your idea.
I fixed the patch as follows.

By the way, k_standard.c still remains. Is there a way to proceed with it?

Thanks,
Koichi

===== PATCH =====
diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
b/src/java.base/unix/native/libnet/NetworkInterface.c
--- a/src/java.base/unix/native/libnet/NetworkInterface.c
+++ b/src/java.base/unix/native/libnet/NetworkInterface.c
@@ -1296,7 +1296,8 @@
  static int getIndex(int sock, const char *name) {
      struct ifreq if2;
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
+    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
+    if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

      if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
          return -1;
@@ -1359,7 +1360,8 @@
  static int getFlags(int sock, const char *ifname, int *flags) {
      struct ifreq if2;
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
+    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
+    if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

      if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
          return -1;
diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
b/src/java.base/share/native/libfdlibm/k_standard.c
--- a/src/java.base/share/native/libfdlibm/k_standard.c
+++ b/src/java.base/share/native/libfdlibm/k_standard.c
@@ -739,6 +739,10 @@
                          errno = EDOM;
                  }
                  break;
+            default:
+                exc.retval = zero;
+                errno = EINVAL;
+                break;
          }
          return exc.retval;
  }


> 
>  ??????? memset((char *)&if2, 0, sizeof(if2));
>  ? -???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>  ? +???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>  ? +???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
> or at the very least use `strnlen` instead of `strlen`:
> 
>  ? if (sizeof(if2.ifr_name) < strnlen(name, sizeof(if2.ifr_name)) + 1) {
>  ????? return -1;
>  ? }
> 
> that would be acceptable too.
> 
> best regards,
> 
> -- daniel
> 
> On 09/07/2020 08:48, Koichi Sakata wrote:
>> Hi Daniel,
>>
>> Thank you for your response.
>>
>> ?>? > +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>> ?>? > +??????? return -1;
>> ?>? > +??? }
>> ?>
>> ?> If I'm not mistaken `sizeof(name)` where name is a const char*
>> ?> will always be 8 (on 64 bits architecture) - so this is probably
>> ?> not doing what you want.
>>
>> I'm sorry. That is my mistake.
>>
>> ?> Also you don't want to trust that `name` is null terminated.
>> ?> Calling strncpy in that case is much safer than calling strcpy
>> ?> even if guarded by strlen.
>> ?> I'm not sure what the compiler is warning you about here.
>> ?>
>> ?> I'd suggest to experiment changing:
>> ?>
>> ?>? >?????? memset((char *)&if2, 0, sizeof(if2));
>> ?>? > -???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>> ?>??? +???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>> ?>??? +???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>
>> I've written the code same as your suggestion. Certainly that can 
>> resolve the warnings. But I think it could cut off the name in the 
>> middle when length of the name longer than the if2.ifr_name length. I 
>> would say I might as well return the error code under the 
>> circumstances. ??So I added the if statement. The code that reflect my 
>> intention correctly is as follows.
>>
>>
>> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
>> b/src/java.base/unix/native/libnet/NetworkInterface.c
>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
>> @@ -1295,8 +1295,13 @@
>> ?? */
>> ??static int getIndex(int sock, const char *name) {
>> ????? struct ifreq if2;
>> +
>> +??? if (sizeof(if2.ifr_name) < strlen(name) + 1) {
>> +??????? return -1;
>> +??? }
>> +
>> ????? memset((char *)&if2, 0, sizeof(if2));
>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>> +??? strcpy(if2.ifr_name, name);
>>
>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>> ????????? return -1;
>> @@ -1358,8 +1363,13 @@
>>
>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>> ????? struct ifreq if2;
>> +
>> +??? if (sizeof(if2.ifr_name) < strlen(ifname) + 1) {
>> +??????? return -1;
>> +??? }
>> +
>> ????? memset((char *)&if2, 0, sizeof(if2));
>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>> +??? strcpy(if2.ifr_name, ifname);
>>
>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>> ????????? return -1;
>>
>>
>> Thanks,
>> Koichi
>>
>> On 2020/07/08 2:57, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> I will not comment on the changes to libfdlibm/k_standard.c
>>>
>>> Concerning NetworkInterface.c I believe the proposed changes are
>>> incorrect - and I do not see the issue with the current code.
>>>
>>> ?> +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>>> ?> +??????? return -1;
>>> ?> +??? }
>>>
>>> If I'm not mistaken `sizeof(name)` where name is a const char*
>>> will always be 8 (on 64 bits architecture) - so this is probably
>>> not doing what you want.
>>>
>>> Also you don't want to trust that `name` is null terminated.
>>> Calling strncpy in that case is much safer than calling strcpy
>>> even if guarded by strlen.
>>> I'm not sure what the compiler is warning you about here.
>>>
>>> I'd suggest to experiment changing:
>>>
>>> ?>?????? memset((char *)&if2, 0, sizeof(if2));
>>> ?> -???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>>> ?? +???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>>> ?? +???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>
>>> and see if that makes the warning go away.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>> On 24/06/2020 08:48, Koichi Sakata wrote:
>>>> Hi all,
>>>>
>>>> (I've sent a similar e-mail before to this ML, but I extract the 
>>>> part only related to core-libs-dev ML from the previous one.)
>>>>
>>>> I tried to build OpenJDK fastdebug with GCC 10.1 on Ubuntu 18.04, 
>>>> but I saw some compiler warnings as follows:
>>>>
>>>> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/: In 
>>>> function '__j__kernel_standard':
>>>> /home/jyukutyo/code/jdk/src/java.base/share/native/libfdlibm/k_standard.c:743:19: 
>>>> error: 'exc.retval' may be used uninitialized in this function 
>>>> [-Werror=maybe-uninitialized]
>>>> ?? 743 |???????? return exc.retval;
>>>> ?????? |??????????????? ~~~^~~~~~~
>>>>
>>>> In file included from /usr/include/string.h:494,
>>>> ????????????????? from 
>>>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:30: 
>>>>
>>>> In function 'strncpy',
>>>> ???? inlined from 'getFlags' at 
>>>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:1362:5, 
>>>>
>>>> ???? inlined from 'addif' at 
>>>> /home/jyukutyo/code/jdk/src/java.base/unix/native/libnet/NetworkInterface.c:974:13: 
>>>>
>>>> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: 
>>>> '__builtin_strncpy' output may be truncated copying 15 bytes from a 
>>>> string of length 15 [-Werror=stringop-truncation]
>>>> ?? 106 |?? return __builtin___strncpy_chk (__dest, __src, __len, 
>>>> __bos (__dest));
>>>> ?????? | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> I can resolve them with the following patch. I believe it fixes 
>>>> those potential bugs, so I'd like to contribute it.
>>>> (Our company has signed OCA.)
>>>>
>>>> Thanks,
>>>> Koichi
>>>>
>>>> ===== PATCH =====
>>>> diff -r 20d92fe3ac52 src/java.base/share/native/libfdlibm/k_standard.c
>>>> --- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Jun 16 
>>>> 03:16:41 2020 +0000
>>>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c Thu Jun 18 
>>>> 07:08:50 2020 +0900
>>>> @@ -739,6 +739,10 @@
>>>> ????????????????????????? errno = EDOM;
>>>> ????????????????? }
>>>> ????????????????? break;
>>>> +??????????? default:
>>>> +??????????????? exc.retval = zero;
>>>> +??????????????? errno = EINVAL;
>>>> +??????????????? break;
>>>> ????????? }
>>>> ????????? return exc.retval;
>>>> ??}
>>>> diff -r 20d92fe3ac52 
>>>> src/java.base/unix/native/libnet/NetworkInterface.c
>>>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c?????? Tue 
>>>> Jun 16 03:16:41 2020 +0000
>>>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c?????? Thu 
>>>> Jun 18 07:08:50 2020 +0900
>>>> @@ -1296,7 +1296,10 @@
>>>> ??static int getIndex(int sock, const char *name) {
>>>> ????? struct ifreq if2;
>>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>>>> +??? if (sizeof(if2.ifr_name) < sizeof(name)) {
>>>> +??????? return -1;
>>>> +??? }
>>>> +??? strcpy(if2.ifr_name, name);
>>>>
>>>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>>>> ????????? return -1;
>>>> @@ -1359,7 +1362,10 @@
>>>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>>>> ????? struct ifreq if2;
>>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>>>> +??? if (sizeof(if2.ifr_name) < sizeof(ifname)) {
>>>> +??????? return -1;
>>>> +??? }
>>>> +??? strcpy(if2.ifr_name, ifname);
>>>>
>>>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>>>> ????????? return -1;
>>>
> 

From naoto.sato at oracle.com  Mon Jul 13 12:54:22 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 13 Jul 2020 05:54:22 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid
 date-only
In-Reply-To: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
References: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
Message-ID: <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>

Ping.

On 7/7/20 3:55 PM, naoto.sato at oracle.com wrote:
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8248695
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
> 
> There were two causes that resulted in throwing exceptions. One was that 
> the Host adapter for Windows always produced Date and Time combined 
> patterns, so formatting a LocalDate ended up with unsupported temporal 
> field for HourOfDay (reported in the bug), and the other cause was the 
> pattern for am/pm was "aa", which was not valid as a DateTimeFormatter 
> pattern.
> 
> Besides these issues, localized DayOfWeek/AM_PM names have not been 
> correctly implemented in the host adapter. Now those names are correctly 
> returned from Windows.
> 
> Naoto

From vipinmv1 at in.ibm.com  Mon Jul 13 13:43:06 2020
From: vipinmv1 at in.ibm.com (Vipin Mv1)
Date: Mon, 13 Jul 2020 13:43:06 +0000
Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with
 Strings
In-Reply-To: <B95309F0-A5C3-421D-9605-89EC4BECFE8C@oracle.com>
References: <B95309F0-A5C3-421D-9605-89EC4BECFE8C@oracle.com>,
 <OF44E9534D.C98F5761-ON00258588.00230443-00258588.0023044E@LocalDomain>
 <OF970BE434.A2955C5A-ON00258565.003F3EB3-00258565.003F3EB8@LocalDomain>
 <OF14D2225D.8CC159E9-ON00258598.001396E6-00258598.0019E2BC@notes.na.collabserv.com>
Message-ID: <OF7790917B.AEF3DAEA-ON002585A4.004B5BA2-002585A4.004B5BA9@notes.na.collabserv.com>

Hi Lance

Thanks for the detailed review. I will go ahead and look into the required documentation changes.
		
Thanks & Regards				 			
Vipin MV					 			
 										 							 			
 						

-----Lance Andersen <lance.andersen at oracle.com> wrote: -----
To: Vipin Mv1 <vipinmv1 at in.ibm.com>
From: Lance Andersen <lance.andersen at oracle.com>
Date: 07/10/2020 02:27AM
Cc: core-libs-dev at openjdk.java.net
Subject: [EXTERNAL] Re: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings

Hi Vipin,

Apologies for the delay.


After looking at the bug, which is over 14 years old, the SCCS history of Attributes.java, I am reluctant to suggest we move forward with your proposed change. 

 The  key for an Attributes map entry should be an Attributes.Name object (see Attributes::put). Unfortunately your proposed fix introduces a behavioral change and could possibly break existing applications.  


A  behavioral change to existing  public methods would require approval via a CSR and would require more compressive testing.   I took a quick scan of the JCK tests and of the JTReg tests and I believe your change would cause some of the existing tests to fail.

>From my perspective, it would be better to clarify the Attributes javadoc to make it clearer that an Attributes.Name object is required   (which I believe has not changed since the Attributes class was added to Java SE).



Best
Lance



On Jul 1, 2020, at 12:42 AM, Vipin Mv1 <vipinmv1 at in.ibm.com> wrote:
Hi,

A gentle reminder to please review this patch.

Thanks & Regards
 Vipin MV                                                                 
                                                                                                          
                                                 
                                                 

-----Vipin Mv1/India/IBM wrote: -----
To: core-libs-dev at openjdk.java.net
From: Vipin Mv1/India/IBM
Date: 06/15/2020 11:52AM
Subject: Re: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings

Hi,

I have addressed the review comments and the patch has been uploaded here:

http://cr.openjdk.java.net/~vtewari/6470126/webrev/index.html

Please let me know your suggestions.

Thanks & Regards                                                                 
Vipin MV                                                                 
                                                                                                          

-----Vipin Mv1/India/IBM wrote: -----
To: core-libs-dev at openjdk.java.net
From: Vipin Mv1/India/IBM
Date: 05/11/2020 05:00PM
Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings

Hi,

Please review the fix for the following issue.

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


diff -r 53568400fec3 src/java.base/share/classes/java/util/jar/Attributes.java
--- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Mar 26 15:26:51 2020 +0000
+++ b/src/java.base/share/classes/java/util/jar/Attributes.java Mon May 11 15:00:01 2020 +0530
@@ -205,7 +205,10 @@
      * @return true if this Map contains the specified attribute name
      */
     public boolean containsKey(Object name) {
-        return map.containsKey(name);
+        if(String.class.isInstance(name))
+            return map.containsKey(Name.of((String)name));
+        else
+            return map.containsKey(name);
     }

     /**

Thanks & Regards
Vipin Menon


 

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


  
 


From huizhe.wang at oracle.com  Mon Jul 13 16:05:17 2020
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Mon, 13 Jul 2020 09:05:17 -0700
Subject: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread
 illegal access to java.lang private fields should be removed
In-Reply-To: <fb4d5e85-5c3e-9888-0db8-9dbe50776b47@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
 <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
 <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>
 <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>
 <fb4d5e85-5c3e-9888-0db8-9dbe50776b47@oracle.com>
Message-ID: <ae256496-4d15-1dbf-8c66-741ebfa91ae0@oracle.com>



On 7/12/20 11:11 PM, Alan Bateman wrote:
> On 12/07/2020 23:21, Joe Wang wrote:
>> Hi all,
>>
>> Alan updated the bug to indicate it fails since JDK 9. Given we still 
>> have a couple days for JDK 15, I've rebased the patch to the jdk15 
>> repo and would like to check in the patch into JDK 15 instead (and 
>> let it be sync-ed to 16). Here's the webrev for JDK 15:
>>
>> http://cr.openjdk.java.net/~joehw/jdk15/8248486/webrev/
>>
>> No change to the SafeThread. The change to module-info.java was made 
>> by deleting java.xml from its JDK15 version. Please review.
> I was curious how we didn't spot this in JDK 9 but it's using Unsafe 
> to get an offset to these fields so that explains it. Good to get this 
> technical debt fixed as there is no guarantee that the hack will work 
> in the future. I don't think there is any urgency for JDK 15 though, 
> fixing it in the main line for JDK 16 is fine.

Ok, I thought it'd save a potential backport given it happened since JDK 
9. But you're right about no urgency, I'll fix it in the main line (16).

-Joe

>
> -Alan


From Alan.Bateman at oracle.com  Mon Jul 13 17:04:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Jul 2020 18:04:46 +0100
Subject: request for review JDK-8242935
In-Reply-To: <e4181193-dd55-d69e-9360-b31a68efb04c@oracle.com>
References: <e4181193-dd55-d69e-9360-b31a68efb04c@oracle.com>
Message-ID: <c43be3a8-9a9e-6e04-ab4b-141d78834459@oracle.com>

On 02/07/2020 20:34, Ivan Sipka wrote:
> Hi all,
>
> please review the following changeset:
> http://cr.openjdk.java.net/~iignatyev/isipka/8242935/webrev.00/
>
> for the JBS issue https://bugs.openjdk.java.net/browse/JDK-8242935
>
> which replaces Nashorn scripting engine in a service reload test with 
> services defined via classpath (Pear) and via module (Banana).
Looks good.

-Alan.

From mandy.chung at oracle.com  Mon Jul 13 17:13:58 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 13 Jul 2020 10:13:58 -0700
Subject: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread
 illegal access to java.lang private fields should be removed
In-Reply-To: <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
 <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
 <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>
 <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>
Message-ID: <23624894-1f0b-8b0c-4d49-73d26584e961@oracle.com>

Looks okay.? Same as Alan's comment,? I don't see there is any urgency 
to fix this in 15.?? Fixing it in 16 is fine.

Mandy

On 7/12/20 3:21 PM, Joe Wang wrote:
> Hi all,
>
> Alan updated the bug to indicate it fails since JDK 9. Given we still 
> have a couple days for JDK 15, I've rebased the patch to the jdk15 
> repo and would like to check in the patch into JDK 15 instead (and let 
> it be sync-ed to 16). Here's the webrev for JDK 15:
>
> http://cr.openjdk.java.net/~joehw/jdk15/8248486/webrev/
>
> No change to the SafeThread. The change to module-info.java was made 
> by deleting java.xml from its JDK15 version. Please review.
>
> Thanks,
> Joe
>
> On 7/10/2020 3:02 PM, Mandy Chung wrote:
>>
>>
>> On 7/10/20 2:25 PM, huizhe.wang at oracle.com wrote:
>>> Thanks Chris, Roger, and Mandy.? I've updated the webrev using 
>>> AtomicInteger and removing java.base export.
>>>
>>> Here's the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/
>>
>> Looks good.
>>
>> Mandy
>


From alexey.semenyuk at oracle.com  Mon Jul 13 17:17:52 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 13 Jul 2020 13:17:52 -0400
Subject: RFR: 8248261: Add timestamps to jpackage and jpackage tests
 verbose output
In-Reply-To: <34a37821-07b5-9c59-a558-126bef1e3b92@oracle.com>
References: <e7b9c84a-c0b3-5018-f306-3d99e430b253@oracle.com>
 <fa6ea4cf-17d5-3094-844f-ddd44a316fed@oracle.com>
 <30a66436-0cf9-e17b-d318-954a5c1075cc@oracle.com>
 <e33e0fbe-b100-263c-7dc9-4c8476e81b9f@oracle.com>
 <312cfde4-afc4-83b9-9e51-85b0a9f5b47f@oracle.com>
 <8964d112-015c-e376-3900-b01b8406bcd0@oracle.com>
 <e55fabfc-7b86-7d66-aaa9-7fe6e97a8e25@oracle.com>
 <34a37821-07b5-9c59-a558-126bef1e3b92@oracle.com>
Message-ID: <71687af0-081a-4de8-b275-0dcbfc566bde@oracle.com>

+1

- Alexey

On 7/10/2020 6:29 PM, Andy Herrick wrote:
> looks good.
>
> /Andy
>
> On 7/9/2020 12:02 AM, alexander.matveev at oracle.com wrote:
>> Hi Alexey,
>>
>> http://cr.openjdk.java.net/~almatvee/8248261/webrev.01/
>>
>> - Added fatalError() to log fatal errors without timestamp.
>> - Added missing timestamp to Log.verbose(Throwable t).
>>
>> Thanks,
>> Alexander
>>
>> On 7/8/20 9:34 AM, Alexey Semenyuk wrote:
>>> I still think it would be good to create dedicated method for final 
>>> error reporting in Main and Arguments classes without timestamps.
>>>
>>> - Alexey
>>>
>>> On 7/8/2020 9:59 AM, Andy Herrick wrote:
>>>> After further discussion, I approve this change as is.
>>>>
>>>> The main fatal error in Arguments.processArguments() only calls 
>>>> Log.error if not verbose , so guarding it from having a timestamp 
>>>> when verbose is not an issue.
>>>>
>>>> /Andy
>>>>
>>>> On 7/7/2020 7:20 PM, Andy Herrick wrote:
>>>>> I agree - but I would rather then that Log.error() never show 
>>>>> timestamp.
>>>>>
>>>>> It would be better still if we could differentiate fatal error 
>>>>> messages from warning messages - right now we are using Log.error 
>>>>> for both.
>>>>>
>>>>> /Andy
>>>>>
>>>>>
>>>>> On 7/7/2020 6:51 PM, alexander.matveev at oracle.com wrote:
>>>>>> Hi Andy,
>>>>>>
>>>>>> Timestamps for error message without verbose output are 
>>>>>> meaningless in my opinion. This is why I did not add them. Also, 
>>>>>> in some cases output does not look right. For example when 
>>>>>> timestamp is added to error message always:
>>>>>> jpackage --someoption
>>>>>> WARNING: Using incubator modules: jdk.incubator.jpackage
>>>>>> [15:49:23.798] Error: Invalid Option: [--someoption]
>>>>>>
>>>>>> In example above I do not see any point to have timestamp.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>> On 7/7/20 6:18 AM, Andy Herrick wrote:
>>>>>>> All looks good, except maybe Log.error().
>>>>>>>
>>>>>>> I think Log.error() should have the same output whether verbose 
>>>>>>> or not, adding timestamp to the message only if verbose does not 
>>>>>>> look right.
>>>>>>>
>>>>>>> Problem is that Log.error() is used for two fundamentally 
>>>>>>> different purposes:
>>>>>>>
>>>>>>> 1.) by Main and Arguments to display the final error message 
>>>>>>> when jpackage is failing.
>>>>>>>
>>>>>>> 2.) by everyone else to display a serious warning message when 
>>>>>>> jpackage is continuing (sometimes failing further on, and 
>>>>>>> sometimes not).
>>>>>>>
>>>>>>> I wouldn't mind adding timestamps only when verbose in case (2), 
>>>>>>> but I don't think that's appropriate for case (1).
>>>>>>>
>>>>>>> /ANdy
>>>>>>>
>>>>>>> On 7/6/2020 8:27 PM, alexander.matveev at oracle.com wrote:
>>>>>>>> Please review the jpackage fix for bug [1] at [2].
>>>>>>>>
>>>>>>>> Added timestamp to verbose and test output in form of 
>>>>>>>> [HH:mm:ss.SSS].
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248261
>>>>>>>> [2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexander
>>>>>>
>>>
>>


From chris.hegarty at oracle.com  Mon Jul 13 18:01:58 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 Jul 2020 19:01:58 +0100
Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, 
 implementation, and tests
In-Reply-To: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com>
References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com>
Message-ID: <5C553417-8DED-41A7-AEE5-5366BAA66EAA@oracle.com>


> On 1 Apr 2020, at 23:46, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target:
> 
>  https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html <https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html>
> 
> This email expands the review of the API to the Java implementation and Java tests:
> 
>  http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/>
> 
>  http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/>

Overall the code seems very well structured, very repetitive (similar to any of these implementations that are generated from templates). From what I know of the concepts, the approach seems sound and clearly deliberate (with performance in mind).

The API surfaces seems large at first glance (and it is), but once the reader gets the concepts clear in their head I think it kinda works well (albeit obviously low-level).

I?m happy to see the use of asserts in several places the code. I know that they are not always enabled, but they are at least in our testing.

There are a bunch of FIXMEs in AbstractMask which look like they could be (easily?) resolved, but maybe they need perf analysis before doing that?

Silly repetitive typo in the X-Vector.java template spills into several javadocs, so I cannot resist:
     * This is not a full-service named operation like
     * {@link #add(Vector) add}.  A masked ****version of****
     * version of this operation is not directly available
     * but may be obtained via the masked version of
     * {@code lanewise}.

-Chris.

From huizhe.wang at oracle.com  Mon Jul 13 18:23:31 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 13 Jul 2020 11:23:31 -0700
Subject: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread
 illegal access to java.lang private fields should be removed
In-Reply-To: <23624894-1f0b-8b0c-4d49-73d26584e961@oracle.com>
References: <e4376039-091b-e43b-64d4-143b98c459f4@oracle.com>
 <2F1B7A0B-E887-4BE3-98D3-E9E2D38BEF9C@oracle.com>
 <daf2c474-f43c-ebf7-7a41-8645b1ec5c2f@oracle.com>
 <3e2cba60-f57e-4315-bf83-03f895ee01d9@oracle.com>
 <fb160f18-7ffa-f5b8-38d1-1bd7a4fc22c8@oracle.com>
 <152d6b75-6270-00e8-3ff0-6cb429b5467b@oracle.com>
 <23624894-1f0b-8b0c-4d49-73d26584e961@oracle.com>
Message-ID: <a73cce13-003a-149a-7669-3701efe0e3c2@oracle.com>

Thanks Mandy. Pushed to the mainline/16 repo.

-Joe

On 7/13/20 10:13 AM, Mandy Chung wrote:
> Looks okay.? Same as Alan's comment,? I don't see there is any urgency 
> to fix this in 15.?? Fixing it in 16 is fine.
>
> Mandy
>
> On 7/12/20 3:21 PM, Joe Wang wrote:
>> Hi all,
>>
>> Alan updated the bug to indicate it fails since JDK 9. Given we still 
>> have a couple days for JDK 15, I've rebased the patch to the jdk15 
>> repo and would like to check in the patch into JDK 15 instead (and 
>> let it be sync-ed to 16). Here's the webrev for JDK 15:
>>
>> http://cr.openjdk.java.net/~joehw/jdk15/8248486/webrev/
>>
>> No change to the SafeThread. The change to module-info.java was made 
>> by deleting java.xml from its JDK15 version. Please review.
>>
>> Thanks,
>> Joe
>>
>> On 7/10/2020 3:02 PM, Mandy Chung wrote:
>>>
>>>
>>> On 7/10/20 2:25 PM, huizhe.wang at oracle.com wrote:
>>>> Thanks Chris, Roger, and Mandy.? I've updated the webrev using 
>>>> AtomicInteger and removing java.base export.
>>>>
>>>> Here's the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/
>>>
>>> Looks good.
>>>
>>> Mandy
>>
>


From andy.herrick at oracle.com  Mon Jul 13 20:26:52 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 13 Jul 2020 16:26:52 -0400
Subject: RFR: JDK-8248687: JPackage test extension misspelled "extention"
Message-ID: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>

please review trivial jpackage fix to issue [1] at [2]

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

[2] http://cr.openjdk.java.net/~herrick/8248687/webrev.01/

/Andy


From alexander.matveev at oracle.com  Mon Jul 13 20:39:17 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Mon, 13 Jul 2020 13:39:17 -0700
Subject: [15] RFR: 8249256: [macos] Add EmptyFolderPackageTest test to problem
 list
Message-ID: <ba2c288b-ac28-695c-b5c0-7d14fc6f67e9@oracle.com>

Please review the jpackage fix for bug [1] at [2].

EmptyFolderPackageTest.java added to ProblemList.

[1] https://bugs.openjdk.java.net/browse/JDK-8249256
[2] http://cr.openjdk.java.net/~almatvee/8249256/webrev.00/

Thanks,
Alexander

From andy.herrick at oracle.com  Mon Jul 13 21:03:57 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 13 Jul 2020 17:03:57 -0400
Subject: [15] RFR: 8249256: [macos] Add EmptyFolderPackageTest test to
 problem list
In-Reply-To: <ba2c288b-ac28-695c-b5c0-7d14fc6f67e9@oracle.com>
References: <ba2c288b-ac28-695c-b5c0-7d14fc6f67e9@oracle.com>
Message-ID: <f72cf37c-aecf-a0b2-bed5-6cb8dc96e6cb@oracle.com>

looks good.

/Andy

On 7/13/2020 4:39 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> EmptyFolderPackageTest.java added to ProblemList.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8249256
> [2] http://cr.openjdk.java.net/~almatvee/8249256/webrev.00/
>
> Thanks,
> Alexander

From alexander.matveev at oracle.com  Mon Jul 13 21:21:10 2020
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 13 Jul 2020 14:21:10 -0700
Subject: RFR: JDK-8248687: JPackage test extension misspelled "extention"
In-Reply-To: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>
References: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>
Message-ID: <22c73eee-1033-116d-380f-c4bdafc99216@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 7/13/2020 1:26 PM, Andy Herrick wrote:
> please review trivial jpackage fix to issue [1] at [2]
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8248687
>
> [2] http://cr.openjdk.java.net/~herrick/8248687/webrev.01/
>
> /Andy
>


From paul.sandoz at oracle.com  Mon Jul 13 21:59:17 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Jul 2020 14:59:17 -0700
Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, 
 implementation, and tests
In-Reply-To: <5C553417-8DED-41A7-AEE5-5366BAA66EAA@oracle.com>
References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com>
 <5C553417-8DED-41A7-AEE5-5366BAA66EAA@oracle.com>
Message-ID: <64735010-6681-4C24-845E-7398CB4CBA73@oracle.com>

Hi Chris,

Thank you for jumping in at the deep end and reviewing.

I fixed the typos and sent a review of a patch on the panama-dev list [1], to be pushed in the panama repo and rolled back in to patches at some point, likely with other updates to expand testing to cover more API points.

Operations on masks and mask accepting vector operations require more work, as you rightly observed!
Both are not trivial and will need deeper intrinsic work after incubation. A particular challenge is the three different kinds of architecture, x64 AVX2 and aarch64 NEON, x64 AVX512, and aarch64 SVE.  These architectures affect how a mask is represented in hardware registers and how masked operations are translated to hardware instructions.

Paul.

[1] https://mail.openjdk.java.net/pipermail/panama-dev/2020-July/009860.html <https://mail.openjdk.java.net/pipermail/panama-dev/2020-July/009860.html>

> On Jul 13, 2020, at 11:01 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> 
>> On 1 Apr 2020, at 23:46, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> Hi,
>> 
>> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target:
>> 
>>  https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html <https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html> <https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html <https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html>>
>> 
>> This email expands the review of the API to the Java implementation and Java tests:
>> 
>>  http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/> <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/>>
>> 
>>  http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/> <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/>>
> 
> Overall the code seems very well structured, very repetitive (similar to any of these implementations that are generated from templates). From what I know of the concepts, the approach seems sound and clearly deliberate (with performance in mind).
> 
> The API surfaces seems large at first glance (and it is), but once the reader gets the concepts clear in their head I think it kinda works well (albeit obviously low-level).
> 
> I?m happy to see the use of asserts in several places the code. I know that they are not always enabled, but they are at least in our testing.
> 
> There are a bunch of FIXMEs in AbstractMask which look like they could be (easily?) resolved, but maybe they need perf analysis before doing that?
> 
> Silly repetitive typo in the X-Vector.java template spills into several javadocs, so I cannot resist:
>      * This is not a full-service named operation like
>      * {@link #add(Vector) add}.  A masked ****version of****
>      * version of this operation is not directly available
>      * but may be obtained via the masked version of
>      * {@code lanewise}.
> 
> -Chris.


From huizhe.wang at oracle.com  Mon Jul 13 22:55:42 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 13 Jul 2020 15:55:42 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid
 date-only
In-Reply-To: <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>
References: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
 <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>
Message-ID: <1bb42b4b-d2e5-36a7-45c7-37aedbb0e751@oracle.com>

Hi Naoto,

Would it make sense to provide an additional test using the public APIs 
similar to the one provided in the bug report? I'm sure yours is correct 
and covers more cases than the original, but it would be nice to have an 
actual use case and use the public APIs. The report showed it was failed 
somewhere down the stream than when it is run against the current build, 
which produces IAE "Too many pattern letters: a" instead of what's reported.

HostLocaleProviderAdapter_md:849 - 865: may be compacted into one if 
statement, (bCal && getCalendarInfoWrapper(...) || 
getLocaleInfoWrapper(...)).

Regards,
Joe

On 7/13/2020 5:54 AM, naoto.sato at oracle.com wrote:
> Ping.
>
> On 7/7/20 3:55 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8248695
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
>>
>> There were two causes that resulted in throwing exceptions. One was 
>> that the Host adapter for Windows always produced Date and Time 
>> combined patterns, so formatting a LocalDate ended up with 
>> unsupported temporal field for HourOfDay (reported in the bug), and 
>> the other cause was the pattern for am/pm was "aa", which was not 
>> valid as a DateTimeFormatter pattern.
>>
>> Besides these issues, localized DayOfWeek/AM_PM names have not been 
>> correctly implemented in the host adapter. Now those names are 
>> correctly returned from Windows.
>>
>> Naoto


From alexander.matveev at oracle.com  Tue Jul 14 00:35:44 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Mon, 13 Jul 2020 17:35:44 -0700
Subject: RFR: 8249264: Build validate-headers task fails after JDK-8248261
Message-ID: <0ce7226a-c035-8ab8-4871-c6814132c83b@oracle.com>

Please review the jpackage fix for bug [1] at [2].

Added missing ",".

[1] https://bugs.openjdk.java.net/browse/JDK-8249264
[2] http://cr.openjdk.java.net/~almatvee/8249264/webrev.00/

Thanks,
Alexander

From igor.ignatyev at oracle.com  Tue Jul 14 00:41:30 2020
From: igor.ignatyev at oracle.com (igor.ignatyev at oracle.com)
Date: Mon, 13 Jul 2020 17:41:30 -0700
Subject: RFR: 8249264: Build validate-headers task fails after JDK-8248261
In-Reply-To: <0ce7226a-c035-8ab8-4871-c6814132c83b@oracle.com>
References: <0ce7226a-c035-8ab8-4871-c6814132c83b@oracle.com>
Message-ID: <FDC5C0CD-0FB9-4F87-A9A4-7A42C4C70891@oracle.com>

LGTM

? Igor

> On Jul 13, 2020, at 5:35 PM, alexander.matveev at oracle.com wrote:
> 
> ?Please review the jpackage fix for bug [1] at [2].
> 
> Added missing ",".
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8249264
> [2] http://cr.openjdk.java.net/~almatvee/8249264/webrev.00/
> 
> Thanks,
> Alexander


From andy.herrick at oracle.com  Tue Jul 14 00:41:48 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 13 Jul 2020 20:41:48 -0400
Subject: RFR: 8249264: Build validate-headers task fails after JDK-8248261
In-Reply-To: <0ce7226a-c035-8ab8-4871-c6814132c83b@oracle.com>
References: <0ce7226a-c035-8ab8-4871-c6814132c83b@oracle.com>
Message-ID: <c2e98f7a-d511-c909-71f2-662702d078c7@oracle.com>

looks good

/Andy

On 7/13/2020 8:35 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> Added missing ",".
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8249264
> [2] http://cr.openjdk.java.net/~almatvee/8249264/webrev.00/
>
> Thanks,
> Alexander

From naoto.sato at oracle.com  Tue Jul 14 02:01:06 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 13 Jul 2020 19:01:06 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid
 date-only
In-Reply-To: <1bb42b4b-d2e5-36a7-45c7-37aedbb0e751@oracle.com>
References: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
 <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>
 <1bb42b4b-d2e5-36a7-45c7-37aedbb0e751@oracle.com>
Message-ID: <b7f85c00-6b9e-f797-f800-7ebffd205ff3@oracle.com>

Hi Joe,

Thank you for your review.

On 7/13/20 3:55 PM, Joe Wang wrote:
> Hi Naoto,
> 
> Would it make sense to provide an additional test using the public APIs 
> similar to the one provided in the bug report? I'm sure yours is correct 
> and covers more cases than the original, but it would be nice to have an 
> actual use case and use the public APIs. The report showed it was failed 
> somewhere down the stream than when it is run against the current build, 
> which produces IAE "Too many pattern letters: a" instead of what's 
> reported.

I am not quite sure I got your suggestion, but the test case uses the 
same API as in the bug report (LocaleProviders.java, line 421-428) that 
are supposed to catch two cases, i.e., 
ofLocalizedDate()/ofLocalizedTime() tests catch "unsupported temporal 
field" exception, such as HourOfDay, and ofLocalizedDateTime() catches 
"Too many pattern letters: aa" which you saw in (possibly) en_US locale. 
To make it clearer, I added some comments to it.

> 
> HostLocaleProviderAdapter_md:849 - 865: may be compacted into one if 
> statement, (bCal && getCalendarInfoWrapper(...) || 
> getLocaleInfoWrapper(...)).

Quite right. Modified.

The updated webrev is located at:

https://cr.openjdk.java.net/~naoto/8248695/webrev.01/

Naoto

> 
> Regards,
> Joe
> 
> On 7/13/2020 5:54 AM, naoto.sato at oracle.com wrote:
>> Ping.
>>
>> On 7/7/20 3:55 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8248695
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
>>>
>>> There were two causes that resulted in throwing exceptions. One was 
>>> that the Host adapter for Windows always produced Date and Time 
>>> combined patterns, so formatting a LocalDate ended up with 
>>> unsupported temporal field for HourOfDay (reported in the bug), and 
>>> the other cause was the pattern for am/pm was "aa", which was not 
>>> valid as a DateTimeFormatter pattern.
>>>
>>> Besides these issues, localized DayOfWeek/AM_PM names have not been 
>>> correctly implemented in the host adapter. Now those names are 
>>> correctly returned from Windows.
>>>
>>> Naoto
> 

From huizhe.wang at oracle.com  Tue Jul 14 02:28:11 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 13 Jul 2020 19:28:11 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid
 date-only
In-Reply-To: <b7f85c00-6b9e-f797-f800-7ebffd205ff3@oracle.com>
References: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
 <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>
 <1bb42b4b-d2e5-36a7-45c7-37aedbb0e751@oracle.com>
 <b7f85c00-6b9e-f797-f800-7ebffd205ff3@oracle.com>
Message-ID: <2fabb235-aff1-eb5f-c919-2637a70ee5dd@oracle.com>



On 7/13/2020 7:01 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thank you for your review.
>
> On 7/13/20 3:55 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> Would it make sense to provide an additional test using the public 
>> APIs similar to the one provided in the bug report? I'm sure yours is 
>> correct and covers more cases than the original, but it would be nice 
>> to have an actual use case and use the public APIs. The report showed 
>> it was failed somewhere down the stream than when it is run against 
>> the current build, which produces IAE "Too many pattern letters: a" 
>> instead of what's reported.
>
> I am not quite sure I got your suggestion, but the test case uses the 
> same API as in the bug report (LocaleProviders.java, line 421-428) 
> that are supposed to catch two cases, i.e., 
> ofLocalizedDate()/ofLocalizedTime() tests catch "unsupported temporal 
> field" exception, such as HourOfDay, and ofLocalizedDateTime() catches 
> "Too many pattern letters: aa" which you saw in (possibly) en_US 
> locale. To make it clearer, I added some comments to it.

Yes, the test covered the cases. What I was suggesting was an additional 
test that uses only public APIs similar to that in the bug report, that 
is what users would do and how they may encounter this issue, e.g.
 ??? System.setProperty("java.locale.providers", "HOST");
 ??? DateTimeFormatter formatter = 
DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL);

It's unlikely for an user application to refer to a private 
package/class like sun.util.locale.provider.LocaleProviderAdapter.

I understand it's been that way for these test. But to me, a real world 
use case is always nice to have. Your call whether you want to add it or 
not. There's no missing coverage.

>
>>
>> HostLocaleProviderAdapter_md:849 - 865: may be compacted into one if 
>> statement, (bCal && getCalendarInfoWrapper(...) || 
>> getLocaleInfoWrapper(...)).
>
> Quite right. Modified.
>
> The updated webrev is located at:
>
> https://cr.openjdk.java.net/~naoto/8248695/webrev.01/

Looks good to me.

Best,
Joe

>
> Naoto
>
>>
>> Regards,
>> Joe
>>
>> On 7/13/2020 5:54 AM, naoto.sato at oracle.com wrote:
>>> Ping.
>>>
>>> On 7/7/20 3:55 PM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8248695
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
>>>>
>>>> There were two causes that resulted in throwing exceptions. One was 
>>>> that the Host adapter for Windows always produced Date and Time 
>>>> combined patterns, so formatting a LocalDate ended up with 
>>>> unsupported temporal field for HourOfDay (reported in the bug), and 
>>>> the other cause was the pattern for am/pm was "aa", which was not 
>>>> valid as a DateTimeFormatter pattern.
>>>>
>>>> Besides these issues, localized DayOfWeek/AM_PM names have not been 
>>>> correctly implemented in the host adapter. Now those names are 
>>>> correctly returned from Windows.
>>>>
>>>> Naoto
>>


From naoto.sato at oracle.com  Tue Jul 14 04:04:15 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 13 Jul 2020 21:04:15 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid
 date-only
In-Reply-To: <2fabb235-aff1-eb5f-c919-2637a70ee5dd@oracle.com>
References: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
 <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>
 <1bb42b4b-d2e5-36a7-45c7-37aedbb0e751@oracle.com>
 <b7f85c00-6b9e-f797-f800-7ebffd205ff3@oracle.com>
 <2fabb235-aff1-eb5f-c919-2637a70ee5dd@oracle.com>
Message-ID: <cfeb9fb3-fff5-39e0-4d22-51a72625fdb0@oracle.com>

Hi Joe,

On 7/13/20 7:28 PM, Joe Wang wrote:
> 
> 
> On 7/13/2020 7:01 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Thank you for your review.
>>
>> On 7/13/20 3:55 PM, Joe Wang wrote:
>>> Hi Naoto,
>>>
>>> Would it make sense to provide an additional test using the public 
>>> APIs similar to the one provided in the bug report? I'm sure yours is 
>>> correct and covers more cases than the original, but it would be nice 
>>> to have an actual use case and use the public APIs. The report showed 
>>> it was failed somewhere down the stream than when it is run against 
>>> the current build, which produces IAE "Too many pattern letters: a" 
>>> instead of what's reported.
>>
>> I am not quite sure I got your suggestion, but the test case uses the 
>> same API as in the bug report (LocaleProviders.java, line 421-428) 
>> that are supposed to catch two cases, i.e., 
>> ofLocalizedDate()/ofLocalizedTime() tests catch "unsupported temporal 
>> field" exception, such as HourOfDay, and ofLocalizedDateTime() catches 
>> "Too many pattern letters: aa" which you saw in (possibly) en_US 
>> locale. To make it clearer, I added some comments to it.
> 
> Yes, the test covered the cases. What I was suggesting was an additional 
> test that uses only public APIs similar to that in the bug report, that 
> is what users would do and how they may encounter this issue, e.g.
>  ??? System.setProperty("java.locale.providers", "HOST");
>  ??? DateTimeFormatter formatter = 
> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL);
> 
> It's unlikely for an user application to refer to a private 
> package/class like sun.util.locale.provider.LocaleProviderAdapter.
> 
> I understand it's been that way for these test. But to me, a real world 
> use case is always nice to have. Your call whether you want to add it or 
> not. There's no missing coverage.

Now I got what you are talking about. The way the bug report is doing is 
in fact discouraged, as once it is read at the startup, it won't be read 
again with later setProperty() call. Apps are supposed to specify the 
property as -D launcher parameter. (And the test case is doing it, at 
line 184 of LocaleProvidersRun.java) Internal interface is used only to 
tell whether HOST provider is actually used or not, so apps should not 
depend on it.

> 
>>
>>>
>>> HostLocaleProviderAdapter_md:849 - 865: may be compacted into one if 
>>> statement, (bCal && getCalendarInfoWrapper(...) || 
>>> getLocaleInfoWrapper(...)).
>>
>> Quite right. Modified.
>>
>> The updated webrev is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8248695/webrev.01/
> 
> Looks good to me.

Thanks!

Naoto

> 
> Best,
> Joe
> 
>>
>> Naoto
>>
>>>
>>> Regards,
>>> Joe
>>>
>>> On 7/13/2020 5:54 AM, naoto.sato at oracle.com wrote:
>>>> Ping.
>>>>
>>>> On 7/7/20 3:55 PM, naoto.sato at oracle.com wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix to the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248695
>>>>>
>>>>> The proposed changeset is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
>>>>>
>>>>> There were two causes that resulted in throwing exceptions. One was 
>>>>> that the Host adapter for Windows always produced Date and Time 
>>>>> combined patterns, so formatting a LocalDate ended up with 
>>>>> unsupported temporal field for HourOfDay (reported in the bug), and 
>>>>> the other cause was the pattern for am/pm was "aa", which was not 
>>>>> valid as a DateTimeFormatter pattern.
>>>>>
>>>>> Besides these issues, localized DayOfWeek/AM_PM names have not been 
>>>>> correctly implemented in the host adapter. Now those names are 
>>>>> correctly returned from Windows.
>>>>>
>>>>> Naoto
>>>
> 

From huizhe.wang at oracle.com  Tue Jul 14 05:20:31 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 13 Jul 2020 22:20:31 -0700
Subject: RFR: 8248695: HostLocaleProviderAdapterImpl provides invalid
 date-only
In-Reply-To: <cfeb9fb3-fff5-39e0-4d22-51a72625fdb0@oracle.com>
References: <04830fb4-9a7b-aded-099a-d635f5754857@oracle.com>
 <e6d7cf88-ba2a-4c26-60fd-a2f366fcaec8@oracle.com>
 <1bb42b4b-d2e5-36a7-45c7-37aedbb0e751@oracle.com>
 <b7f85c00-6b9e-f797-f800-7ebffd205ff3@oracle.com>
 <2fabb235-aff1-eb5f-c919-2637a70ee5dd@oracle.com>
 <cfeb9fb3-fff5-39e0-4d22-51a72625fdb0@oracle.com>
Message-ID: <b4e770bc-00ef-3d07-08b0-3e6fbc2edbb7@oracle.com>



On 7/13/2020 9:04 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> On 7/13/20 7:28 PM, Joe Wang wrote:
>>
>>
>> On 7/13/2020 7:01 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for your review.
>>>
>>> On 7/13/20 3:55 PM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> Would it make sense to provide an additional test using the public 
>>>> APIs similar to the one provided in the bug report? I'm sure yours 
>>>> is correct and covers more cases than the original, but it would be 
>>>> nice to have an actual use case and use the public APIs. The report 
>>>> showed it was failed somewhere down the stream than when it is run 
>>>> against the current build, which produces IAE "Too many pattern 
>>>> letters: a" instead of what's reported.
>>>
>>> I am not quite sure I got your suggestion, but the test case uses 
>>> the same API as in the bug report (LocaleProviders.java, line 
>>> 421-428) that are supposed to catch two cases, i.e., 
>>> ofLocalizedDate()/ofLocalizedTime() tests catch "unsupported 
>>> temporal field" exception, such as HourOfDay, and 
>>> ofLocalizedDateTime() catches "Too many pattern letters: aa" which 
>>> you saw in (possibly) en_US locale. To make it clearer, I added some 
>>> comments to it.
>>
>> Yes, the test covered the cases. What I was suggesting was an 
>> additional test that uses only public APIs similar to that in the bug 
>> report, that is what users would do and how they may encounter this 
>> issue, e.g.
>> ???? System.setProperty("java.locale.providers", "HOST");
>> ???? DateTimeFormatter formatter = 
>> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL);
>>
>> It's unlikely for an user application to refer to a private 
>> package/class like sun.util.locale.provider.LocaleProviderAdapter.
>>
>> I understand it's been that way for these test. But to me, a real 
>> world use case is always nice to have. Your call whether you want to 
>> add it or not. There's no missing coverage.
>
> Now I got what you are talking about. The way the bug report is doing 
> is in fact discouraged, as once it is read at the startup, it won't be 
> read again with later setProperty() call. Apps are supposed to specify 
> the property as -D launcher parameter. (And the test case is doing it, 
> at line 184 of LocaleProvidersRun.java) Internal interface is used 
> only to tell whether HOST provider is actually used or not, so apps 
> should not depend on it.

I see. Thanks for the clarification. Also, nice comments to the test, 
helpful for understanding the details if ever it's read again.

Best,
Joe

>
>>
>>>
>>>>
>>>> HostLocaleProviderAdapter_md:849 - 865: may be compacted into one 
>>>> if statement, (bCal && getCalendarInfoWrapper(...) || 
>>>> getLocaleInfoWrapper(...)).
>>>
>>> Quite right. Modified.
>>>
>>> The updated webrev is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8248695/webrev.01/
>>
>> Looks good to me.
>
> Thanks!
>
> Naoto
>
>>
>> Best,
>> Joe
>>
>>>
>>> Naoto
>>>
>>>>
>>>> Regards,
>>>> Joe
>>>>
>>>> On 7/13/2020 5:54 AM, naoto.sato at oracle.com wrote:
>>>>> Ping.
>>>>>
>>>>> On 7/7/20 3:55 PM, naoto.sato at oracle.com wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8248695
>>>>>>
>>>>>> The proposed changeset is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
>>>>>>
>>>>>> There were two causes that resulted in throwing exceptions. One 
>>>>>> was that the Host adapter for Windows always produced Date and 
>>>>>> Time combined patterns, so formatting a LocalDate ended up with 
>>>>>> unsupported temporal field for HourOfDay (reported in the bug), 
>>>>>> and the other cause was the pattern for am/pm was "aa", which was 
>>>>>> not valid as a DateTimeFormatter pattern.
>>>>>>
>>>>>> Besides these issues, localized DayOfWeek/AM_PM names have not 
>>>>>> been correctly implemented in the host adapter. Now those names 
>>>>>> are correctly returned from Windows.
>>>>>>
>>>>>> Naoto
>>>>
>>


From julia.boes at oracle.com  Tue Jul 14 08:19:02 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 14 Jul 2020 09:19:02 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8238286=5d=3a_=27Add_new_flatMap_stream_opera?=
 =?UTF-8?Q?tion_that_is_more_amenable_to_pushing=e2=80=99?=
In-Reply-To: <47c1e40f-86ac-415d-5c43-674b47d8884d@anthonyv.be>
References: <928E8074-D519-4419-8879-4628979BB67F@oracle.com>
 <CAE+3fjbVO4nks1u3Gi7KPXAE1kq3ZJjEidkkOXcrdhkfTj4VnA@mail.gmail.com>
 <5B4DFB68-747C-4EAB-A042-C24DF6516FB8@oracle.com>
 <CAE+3fjb-kkkfHKHUFMSuEj+=YXBE+S8Fsv9Ya9FEdzczKYeC0w@mail.gmail.com>
 <c8f706bb-2b5b-3cc4-968f-cb01bd49cc4e@oracle.com>
 <47c1e40f-86ac-415d-5c43-674b47d8884d@anthonyv.be>
Message-ID: <fc445a90-f2f8-83f9-0c08-38ead9c5c464@oracle.com>

Hi Anthony,
>
> Since short-circuiting sounds similar to a Subscriber cancelling its 
> Subscription, I believe it might be worthwhile to consider the Flow API.
> If the argument would be a `Flow.Processor<T, R>`, then the 
> implementation would publish instances of T to it, subscribe to 
> receive instances of R, and be able to short-circuit by cancelling its 
> Subscription.
>
> Disclaimer: I haven't actually prototyped this, but it makes sense at 
> first thought
>
Thanks for the suggestion. I refer to Paul's comments about why we don't 
consider short-circuiting at the moment but might do so at a later point.

Cheers,

Julia


From daniel.fuchs at oracle.com  Tue Jul 14 15:28:30 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Jul 2020 16:28:30 +0100
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
 <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
 <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
Message-ID: <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com>

Hi Alexey,

On 10/07/2020 21:37, Alexey Bakhtin wrote:
> Updated webrev:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/

In what the JNDI part is concerned this looks good to me now.

nit: 
java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java:
  138         }catch(NoSuchAlgorithmException | 
CertificateEncodingException e) {

missing spaces around `catch`; No need for a new webrev.

Please make sure to update the CSR, and in particular update
the specification section with the diffs from

src/java.naming/share/classes/module-info.java

Also I am not sure the links that are currently in the
specification section are at their place. They may be better
placed in the Solution section (the solution is to implement
the client part of the channel binding as described by these
documents in the default JNDI/LDAP/GSS provider).

Since we don't really have any end-to-end regression test
(what we have is mostly a smoke test) - it would be good if
you could describe in more details what you did to test your
fix against a real server in a JBS comment in JDK-8245527 - so
that someone (future or current maintainers) could reproduce
this testing to verify that nothing is broken by future evolutions.
In particular - if anything specific needs to be
installed/configured on the test machine (LDAP server? Which?
Is that all?)


best regards,

-- daniel

From lance.andersen at oracle.com  Tue Jul 14 15:41:16 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Jul 2020 11:41:16 -0400
Subject: RFR 824767: Incorrect class name displayed in DriverManager  trace
 output
Message-ID: <DA9B2DCC-B311-4827-BF02-4A2DEA2A8FC0@oracle.com>

Hi all,

Please review this trivial fix for https://bugs.openjdk.java.net/browse/JDK-8247677 <https://bugs.openjdk.java.net/browse/JDK-8247677>,  which addresses a couple of typos where the driver class name was not included in the trace output from DriverManager.

???????
$ hg diff
diff -r e92a076bc6a5 src/java.sql/share/classes/java/sql/DriverManager.java
--- a/src/java.sql/share/classes/java/sql/DriverManager.java    Fri Jun 26 13:37:43 2020 -0400
+++ b/src/java.sql/share/classes/java/sql/DriverManager.java    Tue Jul 14 10:15:42 2020 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2020, 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
@@ -449,7 +449,7 @@
             if (isDriverAllowed(aDriver.driver, callerClass)) {
                 result.add(aDriver.driver);
             } else {
-                println("    skipping: " + aDriver.getClass().getName());
+                println("    skipping: " + aDriver.driver.getClass().getName());
             }
         }
         return result;
@@ -687,7 +687,7 @@
                 }
 
             } else {
-                println("    skipping: " + aDriver.getClass().getName());
+                println("    skipping: " + aDriver.driver.getClass().getName());
             }
 
         }

??????????

Best,
Lance
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From raffaello.giulietti at gmail.com  Tue Jul 14 15:47:46 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Tue, 14 Jul 2020 17:47:46 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
Message-ID: <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>

Hi Roger,

here's the latest version of the patch.

I did:
* Withdraw the simplification in encodedOutLength(), as it is indeed out 
of scope for this bug fix.
* Restore field names in DecInputStream except for nextin (now wpos) and 
nextout (now rpos) because they have slightly different semantics. 
That's just for clarity. I would have nothing against reusing the old 
names for the proposed purpose.
* Switch back to the original no-arg read() implementation.
* Adjust comment continuation lines.
* Preserve the proposed logic of read(byte[], int, int) and the 
supporting methods.

Others needed changes are:
* Correct the copyright years: that's something better left to Oracle.
* Remove the apparently useless import at L33. I could build and run 
without it.


Greetings
Raffaello

----

# HG changeset patch
# User lello
# Date 1594741356 -7200
#      Tue Jul 14 17:42:36 2020 +0200
# Node ID 2bebe2aced4c3fa3b42b3c6ee445f9b7b0d20b5d
# Parent  a5649ebf94193770ca763391dd63807059d333b4
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>

diff --git a/src/java.base/share/classes/java/util/Base64.java 
b/src/java.base/share/classes/java/util/Base64.java
--- a/src/java.base/share/classes/java/util/Base64.java
+++ b/src/java.base/share/classes/java/util/Base64.java
@@ -961,12 +961,15 @@

          private final InputStream is;
          private final boolean isMIME;
-        private final int[] base64;      // base64 -> byte mapping
-        private int bits = 0;            // 24-bit buffer for decoding
-        private int nextin = 18;         // next available "off" in 
"bits" for input;
-                                         // -> 18, 12, 6, 0
-        private int nextout = -8;        // next available "off" in 
"bits" for output;
-                                         // -> 8, 0, -8 (no byte for 
output)
+        private final int[] base64;     // base64 -> byte mapping
+        private int bits = 0;           // 24-bit buffer for decoding
+
+        /* writing bit pos inside bits; one of 24 (left, msb), 18, 12, 
6, 0 */
+        private int wpos = 0;
+
+        /* reading bit pos inside bits: one of 24 (left, msb), 16, 8, 0 */
+        private int rpos = 0;
+
          private boolean eof = false;
          private boolean closed = false;

@@ -983,107 +986,156 @@
              return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
          }

-        private int eof(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
+        private int leftovers(byte[] b, int off, int pos, int limit) {
              eof = true;
-            if (nextin != 18) {
-                if (nextin == 12)
-                    throw new IOException("Base64 stream has one 
un-decoded dangling byte.");
-                // treat ending xx/xxx without padding character legal.
-                // same logic as v == '=' below
-                b[off++] = (byte)(bits >> (16));
-                if (nextin == 0) {           // only one padding byte
-                    if (len == 1) {          // no enough output space
-                        bits >>= 8;          // shift to lowest byte
-                        nextout = 0;
-                    } else {
-                        b[off++] = (byte) (bits >>  8);
-                    }
-                }
+
+            /*
+             * We use a loop here, as this method is executed only a 
few times.
+             * Unrolling the loop would probably not contribute much here.
+             */
+            while (rpos - 8 >= wpos & pos != limit) {
+                b[pos++] = (byte) (bits >> (rpos -= 8));
              }
-            return off == oldOff ? -1 : off - oldOff;
+            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
          }

-        private int padding(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
-            // =     shiftto==18 unnecessary padding
-            // x=    shiftto==12 dangling x, invalid unit
-            // xx=   shiftto==6 && missing last '='
-            // xx=y  or last is not '='
-            if (nextin == 18 || nextin == 12 ||
-                nextin == 6 && is.read() != '=') {
-                throw new IOException("Illegal base64 ending sequence:" 
+ nextin);
+        private int eof(byte[] b, int off, int pos, int limit) throws 
IOException {
+            /*
+             * pos != limit
+             *
+             * wpos == 18: x     dangling single x, invalid unit
+             * accept ending xx or xxx without padding characters
+             */
+            if (wpos == 18) {
+                throw new IOException("Base64 stream has one un-decoded 
dangling byte.");
              }
-            b[off++] = (byte)(bits >> (16));
-            if (nextin == 0) {           // only one padding byte
-                if (len == 1) {          // no enough output space
-                    bits >>= 8;          // shift to lowest byte
-                    nextout = 0;
-                } else {
-                    b[off++] = (byte) (bits >>  8);
-                }
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
+        }
+
+        private int padding(byte[] b, int off, int pos, int limit) 
throws IOException {
+            /*
+             * pos != limit
+             *
+             * wpos == 24: =    (unnecessary padding)
+             * wpos == 18: x=   (dangling single x, invalid unit)
+             * wpos == 12 and missing last '=': xx=  (invalid padding)
+             * wpos == 12 and last is not '=': xx=x (invalid padding)
+             */
+            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
+                throw new IOException("Illegal base64 ending sequence:" 
+ wpos);
              }
-            eof = true;
-            return off - oldOff;
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
          }

          @Override
          public int read(byte[] b, int off, int len) throws IOException {
-            if (closed)
+            if (closed) {
                  throw new IOException("Stream is closed");
-            if (eof && nextout < 0)    // eof and no leftover
-                return -1;
-            if (off < 0 || len < 0 || len > b.length - off)
-                throw new IndexOutOfBoundsException();
-            int oldOff = off;
-            while (nextout >= 0) {       // leftover output byte(s) in 
bits buf
-                if (len == 0)
-                    return off - oldOff;
-                b[off++] = (byte)(bits >> nextout);
-                len--;
-                nextout -= 8;
+            }
+            Objects.checkFromIndexSize(off, len, b.length);
+            if (len == 0) {
+                return 0;
              }
-            bits = 0;
-            while (len > 0) {
-                int v = is.read();
-                if (v == -1) {
-                    return eof(b, off, len, oldOff);
+
+            /*
+             * Rather than keeping 2 running vars (e.g., off and len),
+             * we only keep one (pos), while definitely fixing the 
boundaries
+             * of the range [off, limit).
+             * More specifically, each use of pos as an index in b, it 
meets
+             *      pos - off >= 0 & limit - pos > 0
+             *
+             * Note that limit can overflow to Integer.MIN_VALUE. However,
+             * as long as comparisons with pos are as coded, there's no 
harm.
+             *
+             * In addition, limit - off (= len) is used from here on, 
so the
+             * space for len can be reallocated to other vars (e.g., 
limit).
+             */
+            int pos = off;
+            int limit = off + len;
+            if (eof) {
+                return leftovers(b, off, pos, limit);
+            }
+
+            /*
+             * Leftovers from previous invocation; here, wpos = 0.
+             * There can be at most 2 leftover bytes (rpos <= 16).
+             * Further, b has at least one free place.
+             *
+             * The logic could be coded as a loop, (as in method 
leftovers())
+             * but the explicit "unrolling" makes it possible to generate
+             * better byte extraction code.
+             */
+            if (rpos == 16) {
+                b[pos++] = (byte) (bits >> 8);
+                rpos = 8;
+                if (pos == limit) {
+                    return limit - off;
                  }
-                if ((v = base64[v]) < 0) {
-                    if (v == -2) {       // padding byte(s)
-                        return padding(b, off, len, oldOff);
-                    }
-                    if (v == -1) {
-                        if (!isMIME)
-                            throw new IOException("Illegal base64 
character " +
-                                Integer.toString(v, 16));
-                        continue;        // skip if for rfc2045
-                    }
-                    // neve be here
-                }
-                bits |= (v << nextin);
-                if (nextin == 0) {
-                    nextin = 18;         // clear for next in
-                    b[off++] = (byte)(bits >> 16);
-                    if (len == 1) {
-                        nextout = 8;    // 2 bytes left in bits
-                        break;
-                    }
-                    b[off++] = (byte)(bits >> 8);
-                    if (len == 2) {
-                        nextout = 0;    // 1 byte left in bits
-                        break;
-                    }
-                    b[off++] = (byte)bits;
-                    len -= 3;
-                    bits = 0;
-                } else {
-                    nextin -= 6;
+            }
+            if (rpos == 8) {
+                b[pos++] = (byte) bits;
+                rpos = 0;
+                if (pos == limit) {
+                    return limit - off;
                  }
              }
-            return off - oldOff;
+
+            bits = 0;
+            wpos = 24;
+            for (;;) {
+                /* pos != limit & rpos == 0 */
+                int i = is.read();
+                if (i < 0) {
+                    return eof(b, off, pos, limit);
+                }
+                int v = base64[i];
+                if (v < 0) {
+
+                    /*
+                     * i not in alphabet, thus
+                     *      v == -2: i is '=', the padding
+                     *      v == -1: i is something else, typically CR 
or LF
+                     */
+                    if (v == -1) {
+                        if (isMIME) {
+                            continue;
+                        }
+                        throw new IOException("Illegal base64 character 
0x" +
+                                Integer.toHexString(i));
+                    }
+                    return padding(b, off, pos, limit);
+                }
+                bits |= (v << (wpos -= 6));
+                if (wpos != 0) {
+                    continue;
+                }
+                if (limit - pos >= 3) {
+
+                    /* frequently taken fast path, no need to track rpos */
+                    b[pos++] = (byte) (bits >> 16);
+                    b[pos++] = (byte) (bits >> 8);
+                    b[pos++] = (byte) bits;
+                    bits = 0;
+                    wpos = 24;
+                    if (pos == limit) {
+                        return limit - off;
+                    }
+                    continue;
+                }
+
+                /* b has either 1 or 2 free places */
+                b[pos++] = (byte) (bits >> 16);
+                if (pos == limit) {
+                    rpos = 16;
+                    return limit - off;
+                }
+                b[pos++] = (byte) (bits >> 8);
+                /* pos == limit, no need for an if */
+                rpos = 8;
+                return limit - off;
+            }
          }

          @Override
diff --git a/test/jdk/java/util/Base64/TestBase64.java 
b/test/jdk/java/util/Base64/TestBase64.java
--- a/test/jdk/java/util/Base64/TestBase64.java
+++ b/test/jdk/java/util/Base64/TestBase64.java
@@ -144,6 +144,10 @@
          testDecoderKeepsAbstinence(Base64.getDecoder());
          testDecoderKeepsAbstinence(Base64.getUrlDecoder());
          testDecoderKeepsAbstinence(Base64.getMimeDecoder());
+
+        // tests patch addressing JDK-8222187
+        // https://bugs.openjdk.java.net/browse/JDK-8222187
+        testJDK_8222187();
      }

      private static void test(Base64.Encoder enc, Base64.Decoder dec,
@@ -607,4 +611,26 @@
              }
          }
      }
+
+    private static void testJDK_8222187() throws Throwable {
+        byte[] orig = "12345678".getBytes("US-ASCII");
+        byte[] encoded = Base64.getEncoder().encode(orig);
+        // decode using different buffer sizes, up to a longer one than 
needed
+        for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
bufferSize++) {
+            try (
+                    InputStream in = Base64.getDecoder().wrap(
+                            new ByteArrayInputStream(encoded));
+                    ByteArrayOutputStream baos = new 
ByteArrayOutputStream();
+            ) {
+                byte[] buffer = new byte[bufferSize];
+                int read;
+                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
+                    baos.write(buffer, 0, read);
+                }
+                // compare result, output info if lengths do not match
+                byte[] decoded = baos.toByteArray();
+                checkEqual(decoded, orig, "Base64 stream decoding 
failed!");
+            }
+        }
+    }
  }

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8222187.patch
Type: text/x-patch
Size: 13012 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200714/e052a3e4/JDK-8222187-0001.patch>

From james.laskey at oracle.com  Tue Jul 14 17:01:09 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 14 Jul 2020 14:01:09 -0300
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed
 due to OOM (JDK 15)
Message-ID: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>

The test was failing on a newly added mac mini. I've reduced the memory stress by introducing a shared maximum sized string. I don't recommend reducing the 4G memory requirement -- multiple new large objects are constructed in the tests hoping to create an OOM.

JBS: https://bugs.openjdk.java.net/browse/JDK-8249258 <https://bugs.openjdk.java.net/browse/JDK-8249258>
webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01>






From huizhe.wang at oracle.com  Tue Jul 14 17:10:39 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jul 2020 10:10:39 -0700
Subject: RFR 824767: Incorrect class name displayed in DriverManager trace
 output
In-Reply-To: <DA9B2DCC-B311-4827-BF02-4A2DEA2A8FC0@oracle.com>
References: <DA9B2DCC-B311-4827-BF02-4A2DEA2A8FC0@oracle.com>
Message-ID: <c5112583-3ed9-278f-6f8e-bdd51959dabb@oracle.com>

+1

Joe

On 7/14/20 8:41 AM, Lance Andersen wrote:
> Hi all,
>
> Please review this trivial fix for https://bugs.openjdk.java.net/browse/JDK-8247677 <https://bugs.openjdk.java.net/browse/JDK-8247677>,  which addresses a couple of typos where the driver class name was not included in the trace output from DriverManager.
>
> ???????
> $ hg diff
> diff -r e92a076bc6a5 src/java.sql/share/classes/java/sql/DriverManager.java
> --- a/src/java.sql/share/classes/java/sql/DriverManager.java    Fri Jun 26 13:37:43 2020 -0400
> +++ b/src/java.sql/share/classes/java/sql/DriverManager.java    Tue Jul 14 10:15:42 2020 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2020, 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
> @@ -449,7 +449,7 @@
>               if (isDriverAllowed(aDriver.driver, callerClass)) {
>                   result.add(aDriver.driver);
>               } else {
> -                println("    skipping: " + aDriver.getClass().getName());
> +                println("    skipping: " + aDriver.driver.getClass().getName());
>               }
>           }
>           return result;
> @@ -687,7 +687,7 @@
>                   }
>   
>               } else {
> -                println("    skipping: " + aDriver.getClass().getName());
> +                println("    skipping: " + aDriver.driver.getClass().getName());
>               }
>   
>           }
>
> ??????????
>
> Best,
> Lance
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From james.laskey at oracle.com  Tue Jul 14 18:09:26 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 14 Jul 2020 15:09:26 -0300
Subject: Fwd: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
Message-ID: <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>

Adding Daniel 

> Begin forwarded message:
> 
> From: Jim Laskey <james.laskey at oracle.com>
> Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)
> Date: July 14, 2020 at 2:01:09 PM ADT
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> 
> The test was failing on a newly added mac mini. I've reduced the memory stress by introducing a shared maximum sized string. I don't recommend reducing the 4G memory requirement -- multiple new large objects are constructed in the tests hoping to create an OOM.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258 <https://bugs.openjdk.java.net/browse/JDK-8249258>
> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01>
> 
> 
> 
> 
> 


From daniel.daugherty at oracle.com  Tue Jul 14 18:23:42 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 14 Jul 2020 14:23:42 -0400
Subject: Fwd: RFR: JDK-8249258
 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)
In-Reply-To: <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
Message-ID: <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>

On 7/14/20 2:09 PM, Jim Laskey wrote:
> Adding Daniel
>
>> Begin forwarded message:
>>
>> *From: *Jim Laskey <james.laskey at oracle.com 
>> <mailto:james.laskey at oracle.com>>
>> *Subject: **RFR: JDK-8249258 
>> java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)*
>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>>
>>
>> The test was failing on a newly added mac mini. I've reduced the 
>> memory stress by introducing a shared maximum sized string. I don't 
>> recommend reducing the 4G memory requirement -- multiple new large 
>> objects are constructed in the tests hoping to create an OOM.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01

test/jdk/java/util/StringJoiner/StringJoinerTest.java
 ??? No comments on the changes.

This should make it less likely to cause an OOM in an unexpected place.
Thanks for fixing this so quickly.

Thumbs up. Don't know if your team updates copyrights as you
touch files, but if you do, then this one needs it...

Dan


>>
>>
>>
>>
>>
>


From daniel.fuchs at oracle.com  Tue Jul 14 18:36:25 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Jul 2020 19:36:25 +0100
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
Message-ID: <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>

Hi Koichi,

On 13/07/2020 08:03, Koichi Sakata wrote:
 > I understand that. I respect your idea.
 > I fixed the patch as follows.
The changes to NetworkInterface.c look good to me.

 >
 > By the way, k_standard.c still remains. Is there a way to proceed 
with it?

You'll need to find a reviewer that understands what that
method is supposed to do in that case, that's not me ;-)

best regards,

-- daniel

> Thanks, > Koichi
> 
> ===== PATCH =====
> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
> b/src/java.base/unix/native/libnet/NetworkInterface.c
> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
> @@ -1296,7 +1296,8 @@
>  ?static int getIndex(int sock, const char *name) {
>  ???? struct ifreq if2;
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
> +??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
>  ???? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>  ???????? return -1;
> @@ -1359,7 +1360,8 @@
>  ?static int getFlags(int sock, const char *ifname, int *flags) {
>  ???? struct ifreq if2;
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
> +??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
>  ???? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>  ???????? return -1;
> diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
> b/src/java.base/share/native/libfdlibm/k_standard.c
> --- a/src/java.base/share/native/libfdlibm/k_standard.c
> +++ b/src/java.base/share/native/libfdlibm/k_standard.c
> @@ -739,6 +739,10 @@
>  ???????????????????????? errno = EDOM;
>  ???????????????? }
>  ???????????????? break;
> +??????????? default:
> +??????????????? exc.retval = zero;
> +??????????????? errno = EINVAL;
> +??????????????? break;
>  ???????? }
>  ???????? return exc.retval;
>  ?}
> 
> 


From Roger.Riggs at oracle.com  Tue Jul 14 19:35:21 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 14 Jul 2020 15:35:21 -0400
Subject: Fwd: RFR: JDK-8249258
 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)
In-Reply-To: <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
Message-ID: <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>

Looks good.

Though it does seem like the VM should have been able to reclaim enough 
memory between tests
to not need to throw OOME.

Thanks, Roger


On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
> On 7/14/20 2:09 PM, Jim Laskey wrote:
>> Adding Daniel
>>
>>> Begin forwarded message:
>>>
>>> *From: *Jim Laskey <james.laskey at oracle.com 
>>> <mailto:james.laskey at oracle.com>>
>>> *Subject: **RFR: JDK-8249258 
>>> java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 
>>> 15)*
>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net 
>>> <mailto:core-libs-dev at openjdk.java.net>>
>>>
>>> The test was failing on a newly added mac mini. I've reduced the 
>>> memory stress by introducing a shared maximum sized string. I don't 
>>> recommend reducing the 4G memory requirement -- multiple new large 
>>> objects are constructed in the tests hoping to create an OOM.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>
> test/jdk/java/util/StringJoiner/StringJoinerTest.java
> ??? No comments on the changes.
>
> This should make it less likely to cause an OOM in an unexpected place.
> Thanks for fixing this so quickly.
>
> Thumbs up. Don't know if your team updates copyrights as you
> touch files, but if you do, then this one needs it...
>
> Dan
>
>
>>>
>>>
>>>
>>>
>>>
>>
>


From alexey.semenyuk at oracle.com  Tue Jul 14 23:12:00 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 14 Jul 2020 19:12:00 -0400
Subject: RFR: JDK-8248687: JPackage test extension misspelled "extention"
In-Reply-To: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>
References: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>
Message-ID: <6bcc1f22-5f3c-fd5c-72f7-1c02599be552@oracle.com>

Looks good.

- Alexey

On 7/13/2020 4:26 PM, Andy Herrick wrote:
> please review trivial jpackage fix to issue [1] at [2]
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8248687
>
> [2] http://cr.openjdk.java.net/~herrick/8248687/webrev.01/
>
> /Andy
>


From philip.race at oracle.com  Tue Jul 14 23:16:46 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 14 Jul 2020 16:16:46 -0700
Subject: RFR: JDK-8248687: JPackage test extension misspelled "extention"
In-Reply-To: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>
References: <589155d0-fd3f-e951-305a-8592cd10fae6@oracle.com>
Message-ID: <5F0E3CDE.1010707@oracle.com>

+1

-phil

On 7/13/20, 1:26 PM, Andy Herrick wrote:
> please review trivial jpackage fix to issue [1] at [2]
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8248687
>
> [2] http://cr.openjdk.java.net/~herrick/8248687/webrev.01/
>
> /Andy
>

From david.holmes at oracle.com  Tue Jul 14 23:36:26 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Jul 2020 09:36:26 +1000
Subject: Fwd: RFR: JDK-8249258
 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)
In-Reply-To: <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
Message-ID: <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>

On 15/07/2020 5:35 am, Roger Riggs wrote:
> Looks good.
> 
> Though it does seem like the VM should have been able to reclaim enough 
> memory between tests to not need to throw OOME.

I'd have to agree with that - something seems strange here.

The first OOME in OOM1 is not actually Java heap exhaustion, but 
"Requested array size exceeds VM limit", so it could in theory consume 
sufficient Java heap that the "repeat" in OOM2 actually exhausts the 
heap. But that isn't what we see - the unexpected OOME is in OOM3. 
Before OOM2 runs out of memory the GC should have reclaimed everything 
from OOM1. Similarly before OOM3 runs out of memory the GC should have 
reclaimed everything from OOM2 - which should make it impossible for the 
same "repeat" call to hit an OOME in OOM3. Unless the test is being run 
concurrrently in the same VM as other tests?

Cheers,
David

> 
> Thanks, Roger
> 
> 
> On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
>> On 7/14/20 2:09 PM, Jim Laskey wrote:
>>> Adding Daniel
>>>
>>>> Begin forwarded message:
>>>>
>>>> *From: *Jim Laskey <james.laskey at oracle.com 
>>>> <mailto:james.laskey at oracle.com>>
>>>> *Subject: **RFR: JDK-8249258 
>>>> java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 
>>>> 15)*
>>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net 
>>>> <mailto:core-libs-dev at openjdk.java.net>>
>>>>
>>>> The test was failing on a newly added mac mini. I've reduced the 
>>>> memory stress by introducing a shared maximum sized string. I don't 
>>>> recommend reducing the 4G memory requirement -- multiple new large 
>>>> objects are constructed in the tests hoping to create an OOM.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>>
>> test/jdk/java/util/StringJoiner/StringJoinerTest.java
>> ??? No comments on the changes.
>>
>> This should make it less likely to cause an OOM in an unexpected place.
>> Thanks for fixing this so quickly.
>>
>> Thumbs up. Don't know if your team updates copyrights as you
>> touch files, but if you do, then this one needs it...
>>
>> Dan
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
> 

From aleksej.efimov at oracle.com  Wed Jul 15 09:41:23 2020
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 15 Jul 2020 10:41:23 +0100
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
 <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
 <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
Message-ID: <5fa647e7-4ced-31ce-1dc5-97ac0886c329@oracle.com>

Hi Alexey,

Thanks for addressing comments and answering questions. The JNDI changes 
in latest webrev looks good to me.
CI is also happy with the latest changes.

Best,
Aleksei

On 10/07/2020 21:37, Alexey Bakhtin wrote:
> Hello Aleksei,
>
> Thank you for review.
> Please see my comments below.
>
> Updated webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/
>
> Regards
> Alexey
>
>> On 10 Jul 2020, at 19:40, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
>>
>> Hi Alexey,
>>
>> Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases.
>>
>> Please, find the comments about the latest webrev below:
>>
>> Not quite sure why the CF is completed at two places. Probably that?s OK, but it would be good to know the reason :)
> HandshakeCompletedListener is called in case of successful handshake only.
> In case of async handshake failed we close the connection and complete CF exceptionally to release CF.get()
>
>> The ExecutionException could be unpacked instead of using it directly - and its cause used instead.
> Thank you. Fixed in Connection.java and LdapCBPropertiesTest.java
>> 'getTlsServerCertificate' should return null if 'isTlsConnection()' is false - rather than waiting forever.
> We call isTlsConnection() in the LdapSasl before getTlsServerCertificate().
> But your are right, we can double check it to prevent possible deadlock in the future, if code changed.
> Fixed in Connection.java
>
>> java.naming/share/classes/module-info.java: could we try to improve the formatting of the possible values for the new system property - maybe format them as a list.
> Done
>> Connection.java:995 - you could use diamond operator here
> Updated
>> Formatting: Connection.java:1027 'catch (?
> Updated
>> Could we use the test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java from the test library to implement dummy LDAPS server, I believe it could help to increase the test verbosity and reduce its code size.
> Thank you for suggestion. Updated to use BaseLdapServer in the test
>
>> LdapCBPropertiesTest.java:122 - could use no param Hastable constructor
> Fixed
>> I've also run your latest patch through our CI system and it showed no failures with your latest changes.
>>
>> -Aleksei
>>
>> On 09/07/2020 20:34, Alexey Bakhtin wrote:
>>> Hello Sean, Daniel,
>>>
>>> Thank you for review
>>> I?ve added ?com.sun.jndi.ldap.tls.cbtype? property into the module-info file
>>> and updated synchronisation using CompletableFuture.
>>> Also, I have added new test cases : successful and unsuccessful TLS handshake,
>>> synchronous and asynchronous TLS handshake.
>>>
>>> New webrev at : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v13
>>>
>>> Connection property is removed from CSR :
>>> https://bugs.openjdk.java.net/browse/JDK-8247311
>>>
>>> Regards
>>> Alexey
>>>
>>>> On 8 Jul 2020, at 17:41, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>>>
>>>> Thanks Sean, Alexey,
>>>>
>>>> On 08/07/2020 13:25, Sean Mullan wrote:
>>>>>> Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v12/
>>>>> You will also need to update the CSR to remove the connection timeout property.
>>>>> Also, you should document the "com.sun.jndi.ldap.tls.cbtype" property in the java.naming module-info file as was done for other properties in Daniel's recent RFR, once he has pushed it [1].
>>>> I have pushed the fix:
>>>> https://hg.openjdk.java.net/jdk/jdk/rev/ed375ae6c779
>>>>
>>>> Alexey, you should now be able to document your new "com.sun.jndi.ldap.tls.cbtype"
>>>> property in that @implNote as well, and update your CSR
>>>> consequently.
>>>>
>>>>> * src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
>>>>> It looks like there is a possibility of deadlock if getTlsServerCertificate() is called before handshakeCompleted(). In that case the lock could be obtained first and the thread would end up holding the lock and waiting forever.
>>>> I also have a concern with the use of wait/notify in that code.
>>>> I would suggest prototyping using a CompletableFuture instead
>>>> (or can new certificates be exchanged later on the same
>>>> connection?)
>>>>
>>>> CompletableFuture would allow you to relay and propagate any
>>>> exception raised in the callback handler as well, and would
>>>> avoid running into deadlocks.
>>>>
>>>> best regards,
>>>>
>>>> -- daniel


From sgehwolf at redhat.com  Wed Jul 15 09:47:25 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 15 Jul 2020 11:47:25 +0200
Subject: [PING?] RFR(s): 8247863: Unreachable code in
 OperatingSystemImpl.getTotalSwapSpaceSize()
In-Reply-To: <d526dcb167109fa23b510dcd87cb6cb365ba7c4b.camel@redhat.com>
References: <d526dcb167109fa23b510dcd87cb6cb365ba7c4b.camel@redhat.com>
Message-ID: <40bd7c49d36c5775d86b9d2ff5740b50cf4359e9.camel@redhat.com>

Anyone?

On Mon, 2020-06-29 at 17:53 +0200, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this dead-code removal? During review of
> JDK-8244500 it was discovered that with the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return
> 0 when relevant cgroup files are missing. E.g. on a system where the
> kernel doesn't support swap limit capabilities. Therefore this code
> introduced with JDK-8236617 can no longer be reached and should get
> removed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8247863
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247863/01/webrev/
> 
> Testing: Matthias tested this on the affected system and it did pass
> for him. Docker tests on cgroup v1 and cgroup v2.
> 
> Thanks,
> Severin


From alexey at azul.com  Wed Jul 15 11:18:45 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Wed, 15 Jul 2020 11:18:45 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
 <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
 <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
 <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com>
Message-ID: <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com>

Hello Daniel,

I?ve updated CSR as you suggested and added kerberos ldap setup commands for the client host in the JDK-8245527

Regards
Alexey

> On 14 Jul 2020, at 18:28, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Alexey,
> 
> On 10/07/2020 21:37, Alexey Bakhtin wrote:
>> Updated webrev:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/
> 
> In what the JNDI part is concerned this looks good to me now.
> 
> nit: java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java:
> 138         }catch(NoSuchAlgorithmException | CertificateEncodingException e) {
> 
> missing spaces around `catch`; No need for a new webrev.
> 
> Please make sure to update the CSR, and in particular update
> the specification section with the diffs from
> 
> src/java.naming/share/classes/module-info.java
> 
> Also I am not sure the links that are currently in the
> specification section are at their place. They may be better
> placed in the Solution section (the solution is to implement
> the client part of the channel binding as described by these
> documents in the default JNDI/LDAP/GSS provider).
> 
> Since we don't really have any end-to-end regression test
> (what we have is mostly a smoke test) - it would be good if
> you could describe in more details what you did to test your
> fix against a real server in a JBS comment in JDK-8245527 - so
> that someone (future or current maintainers) could reproduce
> this testing to verify that nothing is broken by future evolutions.
> In particular - if anything specific needs to be
> installed/configured on the test machine (LDAP server? Which?
> Is that all?)
> 
> 
> best regards,
> 
> -- daniel


From james.laskey at oracle.com  Wed Jul 15 11:55:46 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 15 Jul 2020 08:55:46 -0300
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
Message-ID: <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>

Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on the side per se and are subject to the platforms VM whims.

> On Jul 14, 2020, at 8:36 PM, David Holmes <David.Holmes at oracle.com> wrote:
> 
> On 15/07/2020 5:35 am, Roger Riggs wrote:
>> Looks good.
>> Though it does seem like the VM should have been able to reclaim enough memory between tests to not need to throw OOME.
> 
> I'd have to agree with that - something seems strange here.
> 
> The first OOME in OOM1 is not actually Java heap exhaustion, but "Requested array size exceeds VM limit", so it could in theory consume sufficient Java heap that the "repeat" in OOM2 actually exhausts the heap. But that isn't what we see - the unexpected OOME is in OOM3. Before OOM2 runs out of memory the GC should have reclaimed everything from OOM1. Similarly before OOM3 runs out of memory the GC should have reclaimed everything from OOM2 - which should make it impossible for the same "repeat" call to hit an OOME in OOM3. Unless the test is being run concurrrently in the same VM as other tests?
> 
> Cheers,
> David
> 
>> Thanks, Roger
>> On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
>>> On 7/14/20 2:09 PM, Jim Laskey wrote:
>>>> Adding Daniel
>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> *From: *Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>>
>>>>> *Subject: **RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)*
>>>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
>>>>> 
>>>>> The test was failing on a newly added mac mini. I've reduced the memory stress by introducing a shared maximum sized string. I don't recommend reducing the 4G memory requirement -- multiple new large objects are constructed in the tests hoping to create an OOM.
>>>>> 
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>>> 
>>> test/jdk/java/util/StringJoiner/StringJoinerTest.java
>>>     No comments on the changes.
>>> 
>>> This should make it less likely to cause an OOM in an unexpected place.
>>> Thanks for fixing this so quickly.
>>> 
>>> Thumbs up. Don't know if your team updates copyrights as you
>>> touch files, but if you do, then this one needs it...
>>> 
>>> Dan
>>> 
>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 


From james.laskey at oracle.com  Wed Jul 15 12:18:41 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 15 Jul 2020 09:18:41 -0300
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
 <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
Message-ID: <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>

Thomas explained: That large objects are never moved (outstanding issue) So, it's possible to fragment the -Xmx4g such that a 2G object can't be allocated,

> On Jul 15, 2020, at 8:55 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on the side per se and are subject to the platforms VM whims.
> 
>> On Jul 14, 2020, at 8:36 PM, David Holmes <David.Holmes at oracle.com> wrote:
>> 
>> On 15/07/2020 5:35 am, Roger Riggs wrote:
>>> Looks good.
>>> Though it does seem like the VM should have been able to reclaim enough memory between tests to not need to throw OOME.
>> 
>> I'd have to agree with that - something seems strange here.
>> 
>> The first OOME in OOM1 is not actually Java heap exhaustion, but "Requested array size exceeds VM limit", so it could in theory consume sufficient Java heap that the "repeat" in OOM2 actually exhausts the heap. But that isn't what we see - the unexpected OOME is in OOM3. Before OOM2 runs out of memory the GC should have reclaimed everything from OOM1. Similarly before OOM3 runs out of memory the GC should have reclaimed everything from OOM2 - which should make it impossible for the same "repeat" call to hit an OOME in OOM3. Unless the test is being run concurrrently in the same VM as other tests?
>> 
>> Cheers,
>> David
>> 
>>> Thanks, Roger
>>> On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
>>>> On 7/14/20 2:09 PM, Jim Laskey wrote:
>>>>> Adding Daniel
>>>>> 
>>>>>> Begin forwarded message:
>>>>>> 
>>>>>> *From: *Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>>
>>>>>> *Subject: **RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)*
>>>>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>>>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
>>>>>> 
>>>>>> The test was failing on a newly added mac mini. I've reduced the memory stress by introducing a shared maximum sized string. I don't recommend reducing the 4G memory requirement -- multiple new large objects are constructed in the tests hoping to create an OOM.
>>>>>> 
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>>>> 
>>>> test/jdk/java/util/StringJoiner/StringJoinerTest.java
>>>>    No comments on the changes.
>>>> 
>>>> This should make it less likely to cause an OOM in an unexpected place.
>>>> Thanks for fixing this so quickly.
>>>> 
>>>> Thumbs up. Don't know if your team updates copyrights as you
>>>> touch files, but if you do, then this one needs it...
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
> 


From david.holmes at oracle.com  Wed Jul 15 13:25:29 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Jul 2020 23:25:29 +1000
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
 <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
 <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>
Message-ID: <f92da228-af7e-dfce-6874-ee92990d6d29@oracle.com>

On 15/07/2020 10:18 pm, Jim Laskey wrote:
> Thomas explained: That large objects are never moved (outstanding issue) So, it's possible to fragment the -Xmx4g such that a 2G object can't be allocated,

Naively one would expect that whatever memory was consumed by

String maxString = "*".repeat(MAX_ARRAY_LENGTH);

in OOM2, would be fully freed and available for use by the same 
statememt in OOM3. But without knowing the exact allocation patterns ...

Cheers,
David
-----

>> On Jul 15, 2020, at 8:55 AM, Jim Laskey <james.laskey at oracle.com> wrote:
>>
>> Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on the side per se and are subject to the platforms VM whims.
>>
>>> On Jul 14, 2020, at 8:36 PM, David Holmes <David.Holmes at oracle.com> wrote:
>>>
>>> On 15/07/2020 5:35 am, Roger Riggs wrote:
>>>> Looks good.
>>>> Though it does seem like the VM should have been able to reclaim enough memory between tests to not need to throw OOME.
>>>
>>> I'd have to agree with that - something seems strange here.
>>>
>>> The first OOME in OOM1 is not actually Java heap exhaustion, but "Requested array size exceeds VM limit", so it could in theory consume sufficient Java heap that the "repeat" in OOM2 actually exhausts the heap. But that isn't what we see - the unexpected OOME is in OOM3. Before OOM2 runs out of memory the GC should have reclaimed everything from OOM1. Similarly before OOM3 runs out of memory the GC should have reclaimed everything from OOM2 - which should make it impossible for the same "repeat" call to hit an OOME in OOM3. Unless the test is being run concurrrently in the same VM as other tests?
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks, Roger
>>>> On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
>>>>> On 7/14/20 2:09 PM, Jim Laskey wrote:
>>>>>> Adding Daniel
>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>> *From: *Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>>
>>>>>>> *Subject: **RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)*
>>>>>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>>>>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
>>>>>>>
>>>>>>> The test was failing on a newly added mac mini. I've reduced the memory stress by introducing a shared maximum sized string. I don't recommend reducing the 4G memory requirement -- multiple new large objects are constructed in the tests hoping to create an OOM.
>>>>>>>
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>>>>>
>>>>> test/jdk/java/util/StringJoiner/StringJoinerTest.java
>>>>>     No comments on the changes.
>>>>>
>>>>> This should make it less likely to cause an OOM in an unexpected place.
>>>>> Thanks for fixing this so quickly.
>>>>>
>>>>> Thumbs up. Don't know if your team updates copyrights as you
>>>>> touch files, but if you do, then this one needs it...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
> 

From james.laskey at oracle.com  Wed Jul 15 13:35:08 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 15 Jul 2020 10:35:08 -0300
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <f92da228-af7e-dfce-6874-ee92990d6d29@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
 <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
 <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>
 <f92da228-af7e-dfce-6874-ee92990d6d29@oracle.com>
Message-ID: <5EEFB235-9BE3-4CE3-A4DA-408626F8F3ED@oracle.com>

Try this:

- You have a 4G heap.
- You allocate some stuff, say 1 byte.
- You allocate a 2G object - so there is only 2G - 1, left. Not enough space for another 2G object.
- But you do allocate 1 byte.
- You have 1 byte, 2G and 1 byte.
- You free the original 2G object.
- But something allocates 1 byte in it's old space.
- Now there is no range that that can accommodate a 2G object. OOM.


> On Jul 15, 2020, at 10:25 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 15/07/2020 10:18 pm, Jim Laskey wrote:
>> Thomas explained: That large objects are never moved (outstanding issue) So, it's possible to fragment the -Xmx4g such that a 2G object can't be allocated,
> 
> Naively one would expect that whatever memory was consumed by
> 
> String maxString = "*".repeat(MAX_ARRAY_LENGTH);
> 
> in OOM2, would be fully freed and available for use by the same statememt in OOM3. But without knowing the exact allocation patterns ...
> 
> Cheers,
> David
> -----
> 
>>> On Jul 15, 2020, at 8:55 AM, Jim Laskey <james.laskey at oracle.com> wrote:
>>> 
>>> Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on the side per se and are subject to the platforms VM whims.
>>> 
>>>> On Jul 14, 2020, at 8:36 PM, David Holmes <David.Holmes at oracle.com> wrote:
>>>> 
>>>> On 15/07/2020 5:35 am, Roger Riggs wrote:
>>>>> Looks good.
>>>>> Though it does seem like the VM should have been able to reclaim enough memory between tests to not need to throw OOME.
>>>> 
>>>> I'd have to agree with that - something seems strange here.
>>>> 
>>>> The first OOME in OOM1 is not actually Java heap exhaustion, but "Requested array size exceeds VM limit", so it could in theory consume sufficient Java heap that the "repeat" in OOM2 actually exhausts the heap. But that isn't what we see - the unexpected OOME is in OOM3. Before OOM2 runs out of memory the GC should have reclaimed everything from OOM1. Similarly before OOM3 runs out of memory the GC should have reclaimed everything from OOM2 - which should make it impossible for the same "repeat" call to hit an OOME in OOM3. Unless the test is being run concurrrently in the same VM as other tests?
>>>> 
>>>> Cheers,
>>>> David
>>>> 
>>>>> Thanks, Roger
>>>>> On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
>>>>>> On 7/14/20 2:09 PM, Jim Laskey wrote:
>>>>>>> Adding Daniel
>>>>>>> 
>>>>>>>> Begin forwarded message:
>>>>>>>> 
>>>>>>>> *From: *Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>>
>>>>>>>> *Subject: **RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)*
>>>>>>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>>>>>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
>>>>>>>> 
>>>>>>>> The test was failing on a newly added mac mini. I've reduced the memory stress by introducing a shared maximum sized string. I don't recommend reducing the 4G memory requirement -- multiple new large objects are constructed in the tests hoping to create an OOM.
>>>>>>>> 
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>>>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>>>>>> 
>>>>>> test/jdk/java/util/StringJoiner/StringJoinerTest.java
>>>>>>    No comments on the changes.
>>>>>> 
>>>>>> This should make it less likely to cause an OOM in an unexpected place.
>>>>>> Thanks for fixing this so quickly.
>>>>>> 
>>>>>> Thumbs up. Don't know if your team updates copyrights as you
>>>>>> touch files, but if you do, then this one needs it...
>>>>>> 
>>>>>> Dan
>>>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>> 


From matthias.baesken at sap.com  Wed Jul 15 15:22:18 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 15 Jul 2020 15:22:18 +0000
Subject: [PING?] RFR(s): 8247863: Unreachable code in
 OperatingSystemImpl.getTotalSwapSpaceSize()
In-Reply-To: <40bd7c49d36c5775d86b9d2ff5740b50cf4359e9.camel@redhat.com>
References: <d526dcb167109fa23b510dcd87cb6cb365ba7c4b.camel@redhat.com>
 <40bd7c49d36c5775d86b9d2ff5740b50cf4359e9.camel@redhat.com>
Message-ID: <AM0PR02MB5412A7A9AD7CA2987E913F09937E0@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hello Severin ,  

> the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return   0

Wouldn?t it be possible that the  coding  of  getMemoryAndSwapLimit   returns a negative value  (might not happen on a "healthy" system but you never know) :

jdk/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java

444    public long getMemoryAndSwapLimit() {
445        long retval = getLongValue(memory, "memory.memsw.limit_in_bytes");
446        if (retval > CgroupV1SubsystemController.UNLIMITED_MIN) {
447            if (memory.isHierarchical()) {
448                // memory.memsw.limit_in_bytes returned unlimited, attempt
449                // hierarchical memory limit
450                String match = "hierarchical_memsw_limit";
451                retval = CgroupV1SubsystemController.getLongValueMatchingLine(memory,
452                                                            "memory.stat",
453                                                            match);
454            }
455        }
456        return CgroupV1SubsystemController.longValOrUnlimited(retval);
457    }


jdk/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java

278    public long getMemoryAndSwapLimit() {
279        String strVal = CgroupSubsystemController.getStringValue(unified, "memory.swap.max");
280        return limitFromString(strVal);
281    }

So  the check you want to clean up does no harm, and might handle "strange" cases - why not keep it?



Best regards, Matthias


-----Original Message-----
From: Severin Gehwolf <sgehwolf at redhat.com> 
Sent: Mittwoch, 15. Juli 2020 11:47
To: core-libs-dev <core-libs-dev at openjdk.java.net>; serviceability-dev <serviceability-dev at openjdk.java.net>
Cc: Baesken, Matthias <matthias.baesken at sap.com>; Bob Vandette <bob.vandette at oracle.com>
Subject: Re: [PING?] RFR(s): 8247863: Unreachable code in OperatingSystemImpl.getTotalSwapSpaceSize()

Anyone?

On Mon, 2020-06-29 at 17:53 +0200, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this dead-code removal? During review of
> JDK-8244500 it was discovered that with the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return
> 0 when relevant cgroup files are missing. E.g. on a system where the
> kernel doesn't support swap limit capabilities. Therefore this code
> introduced with JDK-8236617 can no longer be reached and should get
> removed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8247863
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247863/01/webrev/
> 
> Testing: Matthias tested this on the affected system and it did pass
> for him. Docker tests on cgroup v1 and cgroup v2.
> 
> Thanks,
> Severin


From thomas.schatzl at oracle.com  Wed Jul 15 15:26:32 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 15 Jul 2020 17:26:32 +0200
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <5EEFB235-9BE3-4CE3-A4DA-408626F8F3ED@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
 <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
 <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>
 <f92da228-af7e-dfce-6874-ee92990d6d29@oracle.com>
 <5EEFB235-9BE3-4CE3-A4DA-408626F8F3ED@oracle.com>
Message-ID: <adda8eb5-f8f0-b475-9445-7216a7b74668@oracle.com>

Hi,

On 15.07.20 15:35, Jim Laskey wrote:
> Try this:
> 
> - You have a 4G heap.
> - You allocate some stuff, say 1 byte.
> - You allocate a 2G object - so there is only 2G - 1, left. Not enough space for another 2G object.
> - But you do allocate 1 byte.
> - You have 1 byte, 2G and 1 byte.
> - You free the original 2G object.
> - But something allocates 1 byte in it's old space.
> - Now there is no range that that can accommodate a 2G object. OOM.

   just for clarification: it's a bit more elaborate than that to get 
into this situation as G1 will try a full collection that will compact 
these 1 byte "stuff" into a contiguous range of memory.

G1 at this time will never move "large" (>= heap region size / 2; at 4g 
heap region size is 2M iirc) objects though. I.e. with a suitably placed 
single "large" object in that 4g heap (like covering the middle center 
regions of the heap, i.e. regions #1023 and #1024) you can make 
allocation of that 2g object impossible.

Thanks,
   Thomas

From naoto.sato at oracle.com  Wed Jul 15 16:00:45 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jul 2020 09:00:45 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
Message-ID: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>

Hello,

Please review the fix to the following issues:

https://bugs.openjdk.java.net/browse/JDK-8248655
https://bugs.openjdk.java.net/browse/JDK-8248434

The proposed changeset and its CSR are located at:

https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8248664

A bug was filed against SimpleDateFormat (8248434) where 
case-insensitive date format/parse failed in some of the new locales in 
JDK15. The root cause was that case-insensitive String.regionMatches() 
method did not work with supplementary characters. The problem is that 
the method's spec does not expect case mappings of supplementary 
characters, possibly because it was overlooked in the first place, JSR 
204 - "Unicode Supplementary Character support". Similar behavior is 
observed in other two case-insensitive methods, i.e., 
compareToIgnoreCase() and equalsIgnoreCase().

The fix is straightforward to compare strings by code point basis, 
instead of code unit (16bit "char") basis. Technically this change will 
introduce a backward incompatibility, but I believe it is an 
incompatibility to wrong behavior, not true to the meaning of those 
methods' expectations.

Naoto

From thomas.schatzl at oracle.com  Wed Jul 15 16:21:34 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 15 Jul 2020 18:21:34 +0200
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <adda8eb5-f8f0-b475-9445-7216a7b74668@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
 <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
 <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>
 <f92da228-af7e-dfce-6874-ee92990d6d29@oracle.com>
 <5EEFB235-9BE3-4CE3-A4DA-408626F8F3ED@oracle.com>
 <adda8eb5-f8f0-b475-9445-7216a7b74668@oracle.com>
Message-ID: <f7a77827-1c34-47fa-4886-b2d730c7c3a7@oracle.com>

Hi,

   I looked a bit at the allocations themselves, but first answering 
questions.

On 15.07.20 15:25, David Holmes wrote:
 > On 15/07/2020 10:18 pm, Jim Laskey wrote:
 >> Thomas explained: That large objects are never moved (outstanding
 >> issue) So, it's possible to fragment the -Xmx4g such that a 2G object
 >> can't be allocated,
 >
 > Naively one would expect that whatever memory was consumed by
 >
 > String maxString = "*".repeat(MAX_ARRAY_LENGTH);
 >
 > in OOM2, would be fully freed and available for use by the same
 > statememt in OOM3. But without knowing the exact allocation patterns

This is true.

Augmenting OOM3 code with allocations/gcs:

Heap has 2.05g (1030 regions)
Allocation 1 for 1025 regions, 2g

   - concurrent mark start pause because of humongous allocation 
attempt; heap has 2.05g
   - not enough free space, so do a young collection, elevate to full 
collection -> heap shrunk to 2M
   - allocation goes through

1)      String maxString = "*".repeat(MAX_ARRAY_LENGTH);
         try {

Allocation 2 for 2048 regions(!), 4g
   - concurrent start pause because of humongous allocation attempt
   - not enough free space, so do a young collection, elevate to full 
collection -> heap stays at 2.05g -> OOME

2)          new StringJoiner(maxString, "", maxString).toString();
             fail("Should have thrown OutOfMemoryError");

Two observations:
- I ask myselves how that test could have ever failed (i.e. not throw an 
OOME). A 4g allocation on a 4g heap can in practice never succeed. This 
is very suspicious.

- It is also interesting why Allocation 2 internally has been truncated 
to a 2048 region allocation. It should be 2049 (4g + 16 bytes header?). 
Checking at lower layers, memory management get a request for 4294967296 
bytes which is exactly 2^32... this is too small for that object. 
Something is truncating that string. Printing it gives a length of 
2147483639 chars (i.e. 2^32-1-9). I assume that is correct to silently 
truncate the result string?

Thanks,
   Thomas

From james.laskey at oracle.com  Wed Jul 15 16:26:27 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 15 Jul 2020 13:26:27 -0300
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
Message-ID: <DE466261-31B9-4D15-8918-2D02F4079634@oracle.com>

I think I'm good with this. +1

Asides:

 325             int cp1 = (int)getChar(value, k1);
 326             int cp2 = (int)getChar(other, k2);

I would be tempted to short cut by exiting when not equal, but I think we agreed we need to allow for upper/lowers on different planes.
 
In the UTF-16 code I was trying to think of how your could exhaust the first string and not the second, and still have their lengths the same. I think I have convinced myself that it's not possible as long as surrogates always map upper/lowers to surrogates (two chars each.)

Cheers,

-- Jim





> On Jul 15, 2020, at 1:00 PM, naoto.sato at oracle.com wrote:
> 
> Hello,
> 
> Please review the fix to the following issues:
> 
> https://bugs.openjdk.java.net/browse/JDK-8248655
> https://bugs.openjdk.java.net/browse/JDK-8248434
> 
> The proposed changeset and its CSR are located at:
> 
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8248664
> 
> A bug was filed against SimpleDateFormat (8248434) where case-insensitive date format/parse failed in some of the new locales in JDK15. The root cause was that case-insensitive String.regionMatches() method did not work with supplementary characters. The problem is that the method's spec does not expect case mappings of supplementary characters, possibly because it was overlooked in the first place, JSR 204 - "Unicode Supplementary Character support". Similar behavior is observed in other two case-insensitive methods, i.e., compareToIgnoreCase() and equalsIgnoreCase().
> 
> The fix is straightforward to compare strings by code point basis, instead of code unit (16bit "char") basis. Technically this change will introduce a backward incompatibility, but I believe it is an incompatibility to wrong behavior, not true to the meaning of those methods' expectations.
> 
> Naoto


From naoto.sato at oracle.com  Wed Jul 15 16:39:26 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jul 2020 09:39:26 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <DE466261-31B9-4D15-8918-2D02F4079634@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <DE466261-31B9-4D15-8918-2D02F4079634@oracle.com>
Message-ID: <2cfcaf44-322b-eb9c-597f-2a5745230e5b@oracle.com>

Thank you, Jim, for the quick review!

On 7/15/20 9:26 AM, Jim Laskey wrote:
> I think I'm good with this. +1
> 
> Asides:
> 
>   325             int cp1 = (int)getChar(value, k1);
>   326             int cp2 = (int)getChar(other, k2);
> 
> I would be tempted to short cut by exiting when not equal, but I think we agreed we need to allow for upper/lowers on different planes.
>   
> In the UTF-16 code I was trying to think of how your could exhaust the first string and not the second, and still have their lengths the same. I think I have convinced myself that it's not possible as long as surrogates always map upper/lowers to surrogates (two chars each.)

Right. All code points as of JDK15/6 is in the same plane, thus the 
lengths won't change. I was trying to create a test case for that 
hypothetical situation, but gave up because each character case map is 
embedded in Unicode Character Database, which cannot be modified.

Naoto

> 
> Cheers,
> 
> -- Jim
> 
> 
> 
> 
> 
>> On Jul 15, 2020, at 1:00 PM, naoto.sato at oracle.com wrote:
>>
>> Hello,
>>
>> Please review the fix to the following issues:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8248655
>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>
>> The proposed changeset and its CSR are located at:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>
>> A bug was filed against SimpleDateFormat (8248434) where case-insensitive date format/parse failed in some of the new locales in JDK15. The root cause was that case-insensitive String.regionMatches() method did not work with supplementary characters. The problem is that the method's spec does not expect case mappings of supplementary characters, possibly because it was overlooked in the first place, JSR 204 - "Unicode Supplementary Character support". Similar behavior is observed in other two case-insensitive methods, i.e., compareToIgnoreCase() and equalsIgnoreCase().
>>
>> The fix is straightforward to compare strings by code point basis, instead of code unit (16bit "char") basis. Technically this change will introduce a backward incompatibility, but I believe it is an incompatibility to wrong behavior, not true to the meaning of those methods' expectations.
>>
>> Naoto
> 

From james.laskey at oracle.com  Wed Jul 15 17:19:33 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 15 Jul 2020 14:19:33 -0300
Subject: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java
 failed due to OOM (JDK 15)
In-Reply-To: <f7a77827-1c34-47fa-4886-b2d730c7c3a7@oracle.com>
References: <68BA5E06-7344-4D4B-B7B5-B38E4309BACB@oracle.com>
 <D1CCEFD5-CD59-40DD-8E4A-AF92D9DD263E@oracle.com>
 <155fe78f-b13a-a02b-c999-56c8988f41e7@oracle.com>
 <893f08fa-2e89-b600-b0d0-f9e49466342b@oracle.com>
 <ea7cf334-e92b-017d-bc8a-dc73c18baea0@oracle.com>
 <7174C847-ADE5-4EA3-93BC-49330AAD50C2@oracle.com>
 <F2A8E429-1101-49E6-AD46-6B47E7CE1247@oracle.com>
 <f92da228-af7e-dfce-6874-ee92990d6d29@oracle.com>
 <5EEFB235-9BE3-4CE3-A4DA-408626F8F3ED@oracle.com>
 <adda8eb5-f8f0-b475-9445-7216a7b74668@oracle.com>
 <f7a77827-1c34-47fa-4886-b2d730c7c3a7@oracle.com>
Message-ID: <393D32A5-D2E5-4543-A827-315299A382DC@oracle.com>

In StringJoiner::toString

	final int addLen = prefix.length() + suffix.length();

Looks suspicious. There is no check for overflow here. Looking at the constructor it should have raised a OOM much earlier. Will investigate and file a bug.

Thanks.

-- Jim


> On Jul 15, 2020, at 1:21 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
>  I looked a bit at the allocations themselves, but first answering questions.
> 
> On 15.07.20 15:25, David Holmes wrote:
> > On 15/07/2020 10:18 pm, Jim Laskey wrote:
> >> Thomas explained: That large objects are never moved (outstanding
> >> issue) So, it's possible to fragment the -Xmx4g such that a 2G object
> >> can't be allocated,
> >
> > Naively one would expect that whatever memory was consumed by
> >
> > String maxString = "*".repeat(MAX_ARRAY_LENGTH);
> >
> > in OOM2, would be fully freed and available for use by the same
> > statememt in OOM3. But without knowing the exact allocation patterns
> 
> This is true.
> 
> Augmenting OOM3 code with allocations/gcs:
> 
> Heap has 2.05g (1030 regions)
> Allocation 1 for 1025 regions, 2g
> 
>  - concurrent mark start pause because of humongous allocation attempt; heap has 2.05g
>  - not enough free space, so do a young collection, elevate to full collection -> heap shrunk to 2M
>  - allocation goes through
> 
> 1)      String maxString = "*".repeat(MAX_ARRAY_LENGTH);
>        try {
> 
> Allocation 2 for 2048 regions(!), 4g
>  - concurrent start pause because of humongous allocation attempt
>  - not enough free space, so do a young collection, elevate to full collection -> heap stays at 2.05g -> OOME
> 
> 2)          new StringJoiner(maxString, "", maxString).toString();
>            fail("Should have thrown OutOfMemoryError");
> 
> Two observations:
> - I ask myselves how that test could have ever failed (i.e. not throw an OOME). A 4g allocation on a 4g heap can in practice never succeed. This is very suspicious.
> 
> - It is also interesting why Allocation 2 internally has been truncated to a 2048 region allocation. It should be 2049 (4g + 16 bytes header?). Checking at lower layers, memory management get a request for 4294967296 bytes which is exactly 2^32... this is too small for that object. Something is truncating that string. Printing it gives a length of 2147483639 chars (i.e. 2^32-1-9). I assume that is correct to silently truncate the result string?
> 
> Thanks,
>  Thomas


From rkennke at redhat.com  Wed Jul 15 17:20:21 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Wed, 15 Jul 2020 19:20:21 +0200
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
Message-ID: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>

DirectBufferAllocTest is unreliable when running with
+ExplicitGCInvokesConcurrent, because allocating DBB spreads
System.gc() calls all over concurrent GC cycles. It becomes more
reliable when running with -ExplicitGCInvokesConcurrent. (Shenandoah
defaults to +ExplicitGCInvokesConcurrent, other GCs don't as far as I
know.)

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

Ok?

Thanks,
Roman


From Roger.Riggs at oracle.com  Wed Jul 15 17:56:21 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Jul 2020 13:56:21 -0400
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
Message-ID: <bec64d48-5604-f9c0-d933-4a264390b3ea@oracle.com>

Hi Naoto,

Given the extra tests in the body of the loop, I think its worth finding 
or creating
a JMH test for this and checking the performance.

With performance in mind, I would try to fall back to the UC/LC 
conversions only
when the bytes don't match.? See java.util.Arrays.mismatch(byte[], byte[]).

It might even be worth finding the mismatch in the byte arrays before even
starting to look at the characters.

There's also an option to assemble 4 bytes at a time and compare the int's.
If they are equal you are ahead of the game.? If not, back off to comparing
the characters and checking for surrogates.? The backoff code will be a bit
messier though.

Also, compareToCI and regionMatchesCI could share the implementation of 
the inner loop.

If k1 and k2 ever get out of sync, isn't that failed assertion, so why 
have two indexes.

The loop will have fewer checks against the length of it processes len-1 
chars
and then have a check if there is a final char to be checked.
it can always know there is another char and can blindly get it.

Regards, Roger


On 7/15/20 12:00 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issues:
>
> https://bugs.openjdk.java.net/browse/JDK-8248655
> https://bugs.openjdk.java.net/browse/JDK-8248434
>
> The proposed changeset and its CSR are located at:
>
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8248664
>
> A bug was filed against SimpleDateFormat (8248434) where 
> case-insensitive date format/parse failed in some of the new locales 
> in JDK15. The root cause was that case-insensitive 
> String.regionMatches() method did not work with supplementary 
> characters. The problem is that the method's spec does not expect case 
> mappings of supplementary characters, possibly because it was 
> overlooked in the first place, JSR 204 - "Unicode Supplementary 
> Character support". Similar behavior is observed in other two 
> case-insensitive methods, i.e., compareToIgnoreCase() and 
> equalsIgnoreCase().
>
> The fix is straightforward to compare strings by code point basis, 
> instead of code unit (16bit "char") basis. Technically this change 
> will introduce a backward incompatibility, but I believe it is an 
> incompatibility to wrong behavior, not true to the meaning of those 
> methods' expectations.
>
> Naoto


From huizhe.wang at oracle.com  Wed Jul 15 17:57:17 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 15 Jul 2020 10:57:17 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
Message-ID: <4899dc65-c851-f6f6-94ee-bd4743e71997@oracle.com>

Hi Naoto,

In StringUTF16.java, if one is isHighSurrogate and the other not, you 
may quickly return without going through the rest of the process, 
probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal 
anyways. But it could skip a couple of 
toCodePoint/toUpperCase/toLowerCase calls.

-Joe

On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issues:
>
> https://bugs.openjdk.java.net/browse/JDK-8248655
> https://bugs.openjdk.java.net/browse/JDK-8248434
>
> The proposed changeset and its CSR are located at:
>
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8248664
>
> A bug was filed against SimpleDateFormat (8248434) where 
> case-insensitive date format/parse failed in some of the new locales 
> in JDK15. The root cause was that case-insensitive 
> String.regionMatches() method did not work with supplementary 
> characters. The problem is that the method's spec does not expect case 
> mappings of supplementary characters, possibly because it was 
> overlooked in the first place, JSR 204 - "Unicode Supplementary 
> Character support". Similar behavior is observed in other two 
> case-insensitive methods, i.e., compareToIgnoreCase() and 
> equalsIgnoreCase().
>
> The fix is straightforward to compare strings by code point basis, 
> instead of code unit (16bit "char") basis. Technically this change 
> will introduce a backward incompatibility, but I believe it is an 
> incompatibility to wrong behavior, not true to the meaning of those 
> methods' expectations.
>
> Naoto


From naoto.sato at oracle.com  Wed Jul 15 18:27:28 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jul 2020 11:27:28 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <bec64d48-5604-f9c0-d933-4a264390b3ea@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <bec64d48-5604-f9c0-d933-4a264390b3ea@oracle.com>
Message-ID: <023c14dd-d925-0149-b341-c3db9bdb6e29@oracle.com>

Hi Roger,

Thank you for your review and suggestions.

On 7/15/20 10:56 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> Given the extra tests in the body of the loop, I think its worth finding 
> or creating
> a JMH test for this and checking the performance.

Good point.

> 
> With performance in mind, I would try to fall back to the UC/LC 
> conversions only
> when the bytes don't match.? See java.util.Arrays.mismatch(byte[], byte[]).
> 
> It might even be worth finding the mismatch in the byte arrays before even
> starting to look at the characters.

Agree.

> 
> There's also an option to assemble 4 bytes at a time and compare the int's.
> If they are equal you are ahead of the game.? If not, back off to comparing
> the characters and checking for surrogates.? The backoff code will be a bit
> messier though.

Sure int comparison would be faster, I am not quite sure that would be 
worth compared to more complicated recovery code though.

> 
> Also, compareToCI and regionMatchesCI could share the implementation of 
> the inner loop.

Yes.

> 
> If k1 and k2 ever get out of sync, isn't that failed assertion, so why 
> have two indexes.

This is for preventing possible case maps where one in BMP and the other 
in supplementary, thus the indices could be different.

> 
> The loop will have fewer checks against the length of it processes len-1 
> chars
> and then have a check if there is a final char to be checked.
> it can always know there is another char and can blindly get it.

Maybe, but could be complicated if the last char is a low surrogate.

Anyway, I will come up with a JMH test case and revise the webrev.

Naoto

> 
> Regards, Roger
> 
> 
> On 7/15/20 12:00 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issues:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8248655
>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>
>> The proposed changeset and its CSR are located at:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>
>> A bug was filed against SimpleDateFormat (8248434) where 
>> case-insensitive date format/parse failed in some of the new locales 
>> in JDK15. The root cause was that case-insensitive 
>> String.regionMatches() method did not work with supplementary 
>> characters. The problem is that the method's spec does not expect case 
>> mappings of supplementary characters, possibly because it was 
>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>> Character support". Similar behavior is observed in other two 
>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>> equalsIgnoreCase().
>>
>> The fix is straightforward to compare strings by code point basis, 
>> instead of code unit (16bit "char") basis. Technically this change 
>> will introduce a backward incompatibility, but I believe it is an 
>> incompatibility to wrong behavior, not true to the meaning of those 
>> methods' expectations.
>>
>> Naoto
> 

From naoto.sato at oracle.com  Wed Jul 15 18:32:40 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jul 2020 11:32:40 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <4899dc65-c851-f6f6-94ee-bd4743e71997@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <4899dc65-c851-f6f6-94ee-bd4743e71997@oracle.com>
Message-ID: <9730d3e2-93bf-bf12-748f-9e2851743d80@oracle.com>

Hi Joe,

Thank you for your review.

On 7/15/20 10:57 AM, Joe Wang wrote:
> Hi Naoto,
> 
> In StringUTF16.java, if one is isHighSurrogate and the other not, you 
> may quickly return without going through the rest of the process, 
> probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal 
> anyways. But it could skip a couple of 
> toCodePoint/toUpperCase/toLowerCase calls.

Yes, that is correct as of now, which is based on the assumption that 
case mappings do not cross BMP and supplementary planes boundary. I 
could not find any description where that's given or not. So I just took 
it to be safe.

Naoto

> 
> -Joe
> 
> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issues:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8248655
>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>
>> The proposed changeset and its CSR are located at:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>
>> A bug was filed against SimpleDateFormat (8248434) where 
>> case-insensitive date format/parse failed in some of the new locales 
>> in JDK15. The root cause was that case-insensitive 
>> String.regionMatches() method did not work with supplementary 
>> characters. The problem is that the method's spec does not expect case 
>> mappings of supplementary characters, possibly because it was 
>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>> Character support". Similar behavior is observed in other two 
>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>> equalsIgnoreCase().
>>
>> The fix is straightforward to compare strings by code point basis, 
>> instead of code unit (16bit "char") basis. Technically this change 
>> will introduce a backward incompatibility, but I believe it is an 
>> incompatibility to wrong behavior, not true to the meaning of those 
>> methods' expectations.
>>
>> Naoto
> 

From andy.herrick at oracle.com  Wed Jul 15 18:37:23 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 15 Jul 2020 14:37:23 -0400
Subject: RFR: JDK-8249289: Exception thrown when --temp points to non-existant
 directory
Message-ID: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>

Please review the jpackage fix for issue [1] at [2].

This fixes the regression in JDK16 which caused exception when an empty 
directory was used int the --temp jpackage option, and added to the 
existing test.

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

[2[ - http://cr.openjdk.java.net/~herrick/8249289/webrev.02/

/Andy


From Alan.Bateman at oracle.com  Wed Jul 15 18:43:57 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Jul 2020 19:43:57 +0100
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
In-Reply-To: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
References: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
Message-ID: <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>

On 15/07/2020 18:20, rkennke at redhat.com wrote:
> DirectBufferAllocTest is unreliable when running with
> +ExplicitGCInvokesConcurrent, because allocating DBB spreads
> System.gc() calls all over concurrent GC cycles. It becomes more
> reliable when running with -ExplicitGCInvokesConcurrent. (Shenandoah
> defaults to +ExplicitGCInvokesConcurrent, other GCs don't as far as I
> know.)
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8249543
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8249543/webrev.00/
>
> Ok?
>
I guess this is okay but if -ExplicitGCInvokesConcurrent is the default 
then doesn't it break RMI DGC?? Are you sure this is the only test that 
fails?

-Alan

From james.laskey at oracle.com  Wed Jul 15 18:46:22 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 15 Jul 2020 15:46:22 -0300
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <9730d3e2-93bf-bf12-748f-9e2851743d80@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <4899dc65-c851-f6f6-94ee-bd4743e71997@oracle.com>
 <9730d3e2-93bf-bf12-748f-9e2851743d80@oracle.com>
Message-ID: <B2250C55-54A9-401C-8784-9D6D9B7406C4@oracle.com>

Joe: This is a defensive approach that I believe has minimal cost.

    public static boolean isHighSurrogate(char ch) {
        // Help VM constant-fold; MAX_HIGH_SURROGATE + 1 == MIN_LOW_SURROGATE
        return ch >= MIN_HIGH_SURROGATE && ch < (MAX_HIGH_SURROGATE + 1);
    }


> On Jul 15, 2020, at 3:32 PM, naoto.sato at oracle.com wrote:
> 
> Hi Joe,
> 
> Thank you for your review.
> 
> On 7/15/20 10:57 AM, Joe Wang wrote:
>> Hi Naoto,
>> In StringUTF16.java, if one is isHighSurrogate and the other not, you may quickly return without going through the rest of the process, probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal anyways. But it could skip a couple of toCodePoint/toUpperCase/toLowerCase calls.
> 
> Yes, that is correct as of now, which is based on the assumption that case mappings do not cross BMP and supplementary planes boundary. I could not find any description where that's given or not. So I just took it to be safe.
> 
> Naoto
> 
>> -Joe
>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>> Hello,
>>> 
>>> Please review the fix to the following issues:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>> 
>>> The proposed changeset and its CSR are located at:
>>> 
>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>> 
>>> A bug was filed against SimpleDateFormat (8248434) where case-insensitive date format/parse failed in some of the new locales in JDK15. The root cause was that case-insensitive String.regionMatches() method did not work with supplementary characters. The problem is that the method's spec does not expect case mappings of supplementary characters, possibly because it was overlooked in the first place, JSR 204 - "Unicode Supplementary Character support". Similar behavior is observed in other two case-insensitive methods, i.e., compareToIgnoreCase() and equalsIgnoreCase().
>>> 
>>> The fix is straightforward to compare strings by code point basis, instead of code unit (16bit "char") basis. Technically this change will introduce a backward incompatibility, but I believe it is an incompatibility to wrong behavior, not true to the meaning of those methods' expectations.
>>> 
>>> Naoto


From huizhe.wang at oracle.com  Wed Jul 15 19:32:36 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 15 Jul 2020 12:32:36 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <B2250C55-54A9-401C-8784-9D6D9B7406C4@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <4899dc65-c851-f6f6-94ee-bd4743e71997@oracle.com>
 <9730d3e2-93bf-bf12-748f-9e2851743d80@oracle.com>
 <B2250C55-54A9-401C-8784-9D6D9B7406C4@oracle.com>
Message-ID: <adb4256c-194e-4344-c9d8-ede08fe2db18@oracle.com>

Jim: I was referring to the rest of the process (the calls to 
toCodePoint/toUpperCase/toLowerCase), not isHighSurrogate itself. But 
Roger has a more comprehensive review on performance, and Naoto is 
planning on preparing a JMH test.

-Joe

On 7/15/2020 11:46 AM, Jim Laskey wrote:
> Joe: This is a defensive approach that I believe has minimal cost.
>
>      public static boolean isHighSurrogate(char ch) {
>          // Help VM constant-fold; MAX_HIGH_SURROGATE + 1 == MIN_LOW_SURROGATE
>          return ch >= MIN_HIGH_SURROGATE && ch < (MAX_HIGH_SURROGATE + 1);
>      }
>
>
>> On Jul 15, 2020, at 3:32 PM, naoto.sato at oracle.com wrote:
>>
>> Hi Joe,
>>
>> Thank you for your review.
>>
>> On 7/15/20 10:57 AM, Joe Wang wrote:
>>> Hi Naoto,
>>> In StringUTF16.java, if one is isHighSurrogate and the other not, you may quickly return without going through the rest of the process, probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal anyways. But it could skip a couple of toCodePoint/toUpperCase/toLowerCase calls.
>> Yes, that is correct as of now, which is based on the assumption that case mappings do not cross BMP and supplementary planes boundary. I could not find any description where that's given or not. So I just took it to be safe.
>>
>> Naoto
>>
>>> -Joe
>>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issues:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>
>>>> The proposed changeset and its CSR are located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>
>>>> A bug was filed against SimpleDateFormat (8248434) where case-insensitive date format/parse failed in some of the new locales in JDK15. The root cause was that case-insensitive String.regionMatches() method did not work with supplementary characters. The problem is that the method's spec does not expect case mappings of supplementary characters, possibly because it was overlooked in the first place, JSR 204 - "Unicode Supplementary Character support". Similar behavior is observed in other two case-insensitive methods, i.e., compareToIgnoreCase() and equalsIgnoreCase().
>>>>
>>>> The fix is straightforward to compare strings by code point basis, instead of code unit (16bit "char") basis. Technically this change will introduce a backward incompatibility, but I believe it is an incompatibility to wrong behavior, not true to the meaning of those methods' expectations.
>>>>
>>>> Naoto


From james.laskey at oracle.com  Wed Jul 15 19:42:34 2020
From: james.laskey at oracle.com (James Laskey)
Date: Wed, 15 Jul 2020 16:42:34 -0300
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <adb4256c-194e-4344-c9d8-ede08fe2db18@oracle.com>
References: <adb4256c-194e-4344-c9d8-ede08fe2db18@oracle.com>
Message-ID: <80793091-B7ED-4C6E-A10B-E0096453ECA1@oracle.com>

??

??

> On Jul 15, 2020, at 4:32 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> ?Jim: I was referring to the rest of the process (the calls to toCodePoint/toUpperCase/toLowerCase), not isHighSurrogate itself. But Roger has a more comprehensive review on performance, and Naoto is planning on preparing a JMH test.
> 
> -Joe
> 
>> On 7/15/2020 11:46 AM, Jim Laskey wrote:
>> Joe: This is a defensive approach that I believe has minimal cost.
>> 
>>     public static boolean isHighSurrogate(char ch) {
>>         // Help VM constant-fold; MAX_HIGH_SURROGATE + 1 == MIN_LOW_SURROGATE
>>         return ch >= MIN_HIGH_SURROGATE && ch < (MAX_HIGH_SURROGATE + 1);
>>     }
>> 
>> 
>>>> On Jul 15, 2020, at 3:32 PM, naoto.sato at oracle.com wrote:
>>> 
>>> Hi Joe,
>>> 
>>> Thank you for your review.
>>> 
>>> On 7/15/20 10:57 AM, Joe Wang wrote:
>>>> Hi Naoto,
>>>> In StringUTF16.java, if one is isHighSurrogate and the other not, you may quickly return without going through the rest of the process, probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal anyways. But it could skip a couple of toCodePoint/toUpperCase/toLowerCase calls.
>>> Yes, that is correct as of now, which is based on the assumption that case mappings do not cross BMP and supplementary planes boundary. I could not find any description where that's given or not. So I just took it to be safe.
>>> 
>>> Naoto
>>> 
>>>> -Joe
>>>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>>>> Hello,
>>>>> 
>>>>> Please review the fix to the following issues:
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>> 
>>>>> The proposed changeset and its CSR are located at:
>>>>> 
>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>> 
>>>>> A bug was filed against SimpleDateFormat (8248434) where case-insensitive date format/parse failed in some of the new locales in JDK15. The root cause was that case-insensitive String.regionMatches() method did not work with supplementary characters. The problem is that the method's spec does not expect case mappings of supplementary characters, possibly because it was overlooked in the first place, JSR 204 - "Unicode Supplementary Character support". Similar behavior is observed in other two case-insensitive methods, i.e., compareToIgnoreCase() and equalsIgnoreCase().
>>>>> 
>>>>> The fix is straightforward to compare strings by code point basis, instead of code unit (16bit "char") basis. Technically this change will introduce a backward incompatibility, but I believe it is an incompatibility to wrong behavior, not true to the meaning of those methods' expectations.
>>>>> 
>>>>> Naoto
> 


From rkennke at redhat.com  Wed Jul 15 19:47:21 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 15 Jul 2020 21:47:21 +0200
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
In-Reply-To: <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>
References: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
 <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>
Message-ID: <8c6d42af3f36953d8b680c7c07c112e7ff75574b.camel@redhat.com>

Hi Alan,

> On 15/07/2020 18:20, rkennke at redhat.com wrote:
> > DirectBufferAllocTest is unreliable when running with
> > +ExplicitGCInvokesConcurrent, because allocating DBB spreads
> > System.gc() calls all over concurrent GC cycles. It becomes more
> > reliable when running with -ExplicitGCInvokesConcurrent.
> > (Shenandoah
> > defaults to +ExplicitGCInvokesConcurrent, other GCs don't as far as
> > I
> > know.)
> > 
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8249543
> > Webrev:
> > http://cr.openjdk.java.net/~rkennke/JDK-8249543/webrev.00/
> > 
> > Ok?
> > 
> I guess this is okay but if -ExplicitGCInvokesConcurrent is the
> default 
> then doesn't it break RMI DGC?

Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the
default for all GCs but Shenandoah, and has been that way forever. Do
you mean +ExplicitGCInvokesConcurrent?)

Here's some context from our perspective:

Normally, when System.gc() is called, it invokes a STW garbage
collection. For most GCs that has been that way forever. This is what
-ExplicitGCInvokesConcurrent implies. In Shenandoah, we opted to do
+ExplicitGCInvokesConcurrent instead. This means that when System.gc()
is called, a *concurrent* collection cycle is started, and the calling
thread will wait for that to complete (and other threads will keep on
running - unless they also call System.gc() ).

It breaks this test because all test threads are hammering the GC with
System.gc(), the first one will trigger the start of a concurrent GC,
and the other ones will line up while concurrent GC is running. This is
normally ok. However, the test (or even DirectByteBuffer allocation
routine in Bits.java) is also over-assuming that when System.gc()
returns (and Cleaner thread did its thing), it could now allocate
native memory. However, when lots of test threads are competing for
this, the last one could already been outrun by the first ones that are
rescheduled already. The additional concurrency introduced by
concurrent GC, plus a bunch of wrinkles in our implementation (e.g. the
cleaner can run concurrently with ongoing GC, and not after the GC as
it would do with STW GC) makes this test spuriously fail with
Shenandoah. Forcing it to -ExplicitGCInvokesConcurrent makes it more
reliable. But as far as I can tell, the test is intrinsically
unreliable, but I'm also not sure how it could be made better (or the
DBB allocator even).


>   Are you sure this is the only test that 
> fails?

So far, yes. Can you point me to specific tests that you would expect
to fail?

Roman



From Roger.Riggs at oracle.com  Wed Jul 15 20:21:08 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Jul 2020 16:21:08 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
 <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
Message-ID: <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>

Hi Raffaello,

Base64.java:
2: Please update 2nd copyright year to 2020

leftovers():
996: "&" the shortcutting && is more typical in a condition.
997: the -= is buried in an expression and a reader might miss it.


1053:? "can be reallocated to other vars":? not a useful comment, 
reflecting on only one possible implementation that is out of the 
control of the developer.
I'd almost rather see 'len' than 'limit - off'; it might be informative 
to the reader if 'limit' was declared final. (1056:)

TestBase54.java:

2: Update 2nd copyright year to 2020

27:? Please add the bug number to the @bug line.

Style-wise, I would remove the blank lines at the beginning of blocks.? 
(1095, 1115)

Thanks, Roger


On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
> Hi Roger,
>
> here's the latest version of the patch.
>
> I did:
> * Withdraw the simplification in encodedOutLength(), as it is indeed 
> out of scope for this bug fix.
> * Restore field names in DecInputStream except for nextin (now wpos) 
> and nextout (now rpos) because they have slightly different semantics. 
> That's just for clarity. I would have nothing against reusing the old 
> names for the proposed purpose.
> * Switch back to the original no-arg read() implementation.
> * Adjust comment continuation lines.
> * Preserve the proposed logic of read(byte[], int, int) and the 
> supporting methods.
>
> Others needed changes are:
> * Correct the copyright years: that's something better left to Oracle.
> * Remove the apparently useless import at L33. I could build and run 
> without it.
>
>
> Greetings
> Raffaello
>
> ----
>
> # HG changeset patch
> # User lello
> # Date 1594741356 -7200
> #????? Tue Jul 14 17:42:36 2020 +0200
> # Node ID 2bebe2aced4c3fa3b42b3c6ee445f9b7b0d20b5d
> # Parent? a5649ebf94193770ca763391dd63807059d333b4
> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
> the end
> Reviewed-by: TBD
> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>
> diff --git a/src/java.base/share/classes/java/util/Base64.java 
> b/src/java.base/share/classes/java/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java
> +++ b/src/java.base/share/classes/java/util/Base64.java
> @@ -961,12 +961,15 @@
>
> ???????? private final InputStream is;
> ???????? private final boolean isMIME;
> -??????? private final int[] base64;????? // base64 -> byte mapping
> -??????? private int bits = 0;??????????? // 24-bit buffer for decoding
> -??????? private int nextin = 18;???????? // next available "off" in 
> "bits" for input;
> -???????????????????????????????????????? // -> 18, 12, 6, 0
> -??????? private int nextout = -8;??????? // next available "off" in 
> "bits" for output;
> -???????????????????????????????????????? // -> 8, 0, -8 (no byte for 
> output)
> +??????? private final int[] base64;???? // base64 -> byte mapping
> +??????? private int bits = 0;?????????? // 24-bit buffer for decoding
> +
> +??????? /* writing bit pos inside bits; one of 24 (left, msb), 18, 
> 12, 6, 0 */
> +??????? private int wpos = 0;
> +
> +??????? /* reading bit pos inside bits: one of 24 (left, msb), 16, 8, 
> 0 */
> +??????? private int rpos = 0;
> +
> ???????? private boolean eof = false;
> ???????? private boolean closed = false;
>
> @@ -983,107 +986,156 @@
> ???????????? return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
> ???????? }
>
> -??????? private int eof(byte[] b, int off, int len, int oldOff)
> -??????????? throws IOException
> -??????? {
> +??????? private int leftovers(byte[] b, int off, int pos, int limit) {
> ???????????? eof = true;
> -??????????? if (nextin != 18) {
> -??????????????? if (nextin == 12)
> -??????????????????? throw new IOException("Base64 stream has one 
> un-decoded dangling byte.");
> -??????????????? // treat ending xx/xxx without padding character legal.
> -??????????????? // same logic as v == '=' below
> -??????????????? b[off++] = (byte)(bits >> (16));
> -??????????????? if (nextin == 0) {?????????? // only one padding byte
> -??????????????????? if (len == 1) {????????? // no enough output space
> -??????????????????????? bits >>= 8;????????? // shift to lowest byte
> -??????????????????????? nextout = 0;
> -??????????????????? } else {
> -??????????????????????? b[off++] = (byte) (bits >>? 8);
> -??????????????????? }
> -??????????????? }
> +
> +??????????? /*
> +???????????? * We use a loop here, as this method is executed only a 
> few times.
> +???????????? * Unrolling the loop would probably not contribute much 
> here.
> +???????????? */
> +??????????? while (rpos - 8 >= wpos & pos != limit) {
> +??????????????? b[pos++] = (byte) (bits >> (rpos -= 8));
> ???????????? }
> -??????????? return off == oldOff ? -1 : off - oldOff;
> +??????????? return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
> ???????? }
>
> -??????? private int padding(byte[] b, int off, int len, int oldOff)
> -??????????? throws IOException
> -??????? {
> -??????????? // =???? shiftto==18 unnecessary padding
> -??????????? // x=??? shiftto==12 dangling x, invalid unit
> -??????????? // xx=?? shiftto==6 && missing last '='
> -??????????? // xx=y? or last is not '='
> -??????????? if (nextin == 18 || nextin == 12 ||
> -??????????????? nextin == 6 && is.read() != '=') {
> -??????????????? throw new IOException("Illegal base64 ending 
> sequence:" + nextin);
> +??????? private int eof(byte[] b, int off, int pos, int limit) throws 
> IOException {
> +??????????? /*
> +???????????? * pos != limit
> +???????????? *
> +???????????? * wpos == 18: x???? dangling single x, invalid unit
> +???????????? * accept ending xx or xxx without padding characters
> +???????????? */
> +??????????? if (wpos == 18) {
> +??????????????? throw new IOException("Base64 stream has one 
> un-decoded dangling byte.");
> ???????????? }
> -??????????? b[off++] = (byte)(bits >> (16));
> -??????????? if (nextin == 0) {?????????? // only one padding byte
> -??????????????? if (len == 1) {????????? // no enough output space
> -??????????????????? bits >>= 8;????????? // shift to lowest byte
> -??????????????????? nextout = 0;
> -??????????????? } else {
> -??????????????????? b[off++] = (byte) (bits >>? 8);
> -??????????????? }
> +??????????? rpos = 24;
> +??????????? return leftovers(b, off, pos, limit);
> +??????? }
> +
> +??????? private int padding(byte[] b, int off, int pos, int limit) 
> throws IOException {
> +??????????? /*
> +???????????? * pos != limit
> +???????????? *
> +???????????? * wpos == 24: =??? (unnecessary padding)
> +???????????? * wpos == 18: x=?? (dangling single x, invalid unit)
> +???????????? * wpos == 12 and missing last '=': xx=? (invalid padding)
> +???????????? * wpos == 12 and last is not '=': xx=x (invalid padding)
> +???????????? */
> +??????????? if (wpos >= 18 || wpos == 12 && is.read() != '=') {
> +??????????????? throw new IOException("Illegal base64 ending 
> sequence:" + wpos);
> ???????????? }
> -??????????? eof = true;
> -??????????? return off - oldOff;
> +??????????? rpos = 24;
> +??????????? return leftovers(b, off, pos, limit);
> ???????? }
>
> ???????? @Override
> ???????? public int read(byte[] b, int off, int len) throws IOException {
> -??????????? if (closed)
> +??????????? if (closed) {
> ???????????????? throw new IOException("Stream is closed");
> -??????????? if (eof && nextout < 0)??? // eof and no leftover
> -??????????????? return -1;
> -??????????? if (off < 0 || len < 0 || len > b.length - off)
> -??????????????? throw new IndexOutOfBoundsException();
> -??????????? int oldOff = off;
> -??????????? while (nextout >= 0) {?????? // leftover output byte(s) 
> in bits buf
> -??????????????? if (len == 0)
> -??????????????????? return off - oldOff;
> -??????????????? b[off++] = (byte)(bits >> nextout);
> -??????????????? len--;
> -??????????????? nextout -= 8;
> +??????????? }
> +??????????? Objects.checkFromIndexSize(off, len, b.length);
> +??????????? if (len == 0) {
> +??????????????? return 0;
> ???????????? }
> -??????????? bits = 0;
> -??????????? while (len > 0) {
> -??????????????? int v = is.read();
> -??????????????? if (v == -1) {
> -??????????????????? return eof(b, off, len, oldOff);
> +
> +??????????? /*
> +???????????? * Rather than keeping 2 running vars (e.g., off and len),
> +???????????? * we only keep one (pos), while definitely fixing the 
> boundaries
> +???????????? * of the range [off, limit).
> +???????????? * More specifically, each use of pos as an index in b, 
> it meets
> +???????????? *????? pos - off >= 0 & limit - pos > 0
> +???????????? *
> +???????????? * Note that limit can overflow to Integer.MIN_VALUE. 
> However,
> +???????????? * as long as comparisons with pos are as coded, there's 
> no harm.
> +???????????? *
> +???????????? * In addition, limit - off (= len) is used from here on, 
> so the
> +???????????? * space for len can be reallocated to other vars (e.g., 
> limit).
> +???????????? */
> +??????????? int pos = off;
> +??????????? int limit = off + len;
> +??????????? if (eof) {
> +??????????????? return leftovers(b, off, pos, limit);
> +??????????? }
> +
> +??????????? /*
> +???????????? * Leftovers from previous invocation; here, wpos = 0.
> +???????????? * There can be at most 2 leftover bytes (rpos <= 16).
> +???????????? * Further, b has at least one free place.
> +???????????? *
> +???????????? * The logic could be coded as a loop, (as in method 
> leftovers())
> +???????????? * but the explicit "unrolling" makes it possible to 
> generate
> +???????????? * better byte extraction code.
> +???????????? */
> +??????????? if (rpos == 16) {
> +??????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????? rpos = 8;
> +??????????????? if (pos == limit) {
> +??????????????????? return limit - off;
> ???????????????? }
> -??????????????? if ((v = base64[v]) < 0) {
> -??????????????????? if (v == -2) {?????? // padding byte(s)
> -??????????????????????? return padding(b, off, len, oldOff);
> -??????????????????? }
> -??????????????????? if (v == -1) {
> -??????????????????????? if (!isMIME)
> -??????????????????????????? throw new IOException("Illegal base64 
> character " +
> -??????????????????????????????? Integer.toString(v, 16));
> -??????????????????????? continue;??????? // skip if for rfc2045
> -??????????????????? }
> -??????????????????? // neve be here
> -??????????????? }
> -??????????????? bits |= (v << nextin);
> -??????????????? if (nextin == 0) {
> -??????????????????? nextin = 18;???????? // clear for next in
> -??????????????????? b[off++] = (byte)(bits >> 16);
> -??????????????????? if (len == 1) {
> -??????????????????????? nextout = 8;??? // 2 bytes left in bits
> -??????????????????????? break;
> -??????????????????? }
> -??????????????????? b[off++] = (byte)(bits >> 8);
> -??????????????????? if (len == 2) {
> -??????????????????????? nextout = 0;??? // 1 byte left in bits
> -??????????????????????? break;
> -??????????????????? }
> -??????????????????? b[off++] = (byte)bits;
> -??????????????????? len -= 3;
> -??????????????????? bits = 0;
> -??????????????? } else {
> -??????????????????? nextin -= 6;
> +??????????? }
> +??????????? if (rpos == 8) {
> +??????????????? b[pos++] = (byte) bits;
> +??????????????? rpos = 0;
> +??????????????? if (pos == limit) {
> +??????????????????? return limit - off;
> ???????????????? }
> ???????????? }
> -??????????? return off - oldOff;
> +
> +??????????? bits = 0;
> +??????????? wpos = 24;
> +??????????? for (;;) {
> +??????????????? /* pos != limit & rpos == 0 */
> +??????????????? int i = is.read();
> +??????????????? if (i < 0) {
> +??????????????????? return eof(b, off, pos, limit);
> +??????????????? }
> +??????????????? int v = base64[i];
> +??????????????? if (v < 0) {
> +
> +??????????????????? /*
> +???????????????????? * i not in alphabet, thus
> +???????????????????? *????? v == -2: i is '=', the padding
> +???????????????????? *????? v == -1: i is something else, typically 
> CR or LF
> +???????????????????? */
> +??????????????????? if (v == -1) {
> +??????????????????????? if (isMIME) {
> +??????????????????????????? continue;
> +??????????????????????? }
> +??????????????????????? throw new IOException("Illegal base64 
> character 0x" +
> +??????????????????????????????? Integer.toHexString(i));
> +??????????????????? }
> +??????????????????? return padding(b, off, pos, limit);
> +??????????????? }
> +??????????????? bits |= (v << (wpos -= 6));
> +??????????????? if (wpos != 0) {
> +??????????????????? continue;
> +??????????????? }
> +??????????????? if (limit - pos >= 3) {
> +
> +??????????????????? /* frequently taken fast path, no need to track 
> rpos */
> +??????????????????? b[pos++] = (byte) (bits >> 16);
> +??????????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????????? b[pos++] = (byte) bits;
> +??????????????????? bits = 0;
> +??????????????????? wpos = 24;
> +??????????????????? if (pos == limit) {
> +??????????????????????? return limit - off;
> +??????????????????? }
> +??????????????????? continue;
> +??????????????? }
> +
> +??????????????? /* b has either 1 or 2 free places */
> +??????????????? b[pos++] = (byte) (bits >> 16);
> +??????????????? if (pos == limit) {
> +??????????????????? rpos = 16;
> +??????????????????? return limit - off;
> +??????????????? }
> +??????????????? b[pos++] = (byte) (bits >> 8);
> +??????????????? /* pos == limit, no need for an if */
> +??????????????? rpos = 8;
> +??????????????? return limit - off;
> +??????????? }
> ???????? }
>
> ???????? @Override
> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
> b/test/jdk/java/util/Base64/TestBase64.java
> --- a/test/jdk/java/util/Base64/TestBase64.java
> +++ b/test/jdk/java/util/Base64/TestBase64.java
> @@ -144,6 +144,10 @@
> ???????? testDecoderKeepsAbstinence(Base64.getDecoder());
> ???????? testDecoderKeepsAbstinence(Base64.getUrlDecoder());
> ???????? testDecoderKeepsAbstinence(Base64.getMimeDecoder());
> +
> +??????? // tests patch addressing JDK-8222187
> +??????? // https://bugs.openjdk.java.net/browse/JDK-8222187
> +??????? testJDK_8222187();
> ???? }
>
> ???? private static void test(Base64.Encoder enc, Base64.Decoder dec,
> @@ -607,4 +611,26 @@
> ???????????? }
> ???????? }
> ???? }
> +
> +??? private static void testJDK_8222187() throws Throwable {
> +??????? byte[] orig = "12345678".getBytes("US-ASCII");
> +??????? byte[] encoded = Base64.getEncoder().encode(orig);
> +??????? // decode using different buffer sizes, up to a longer one 
> than needed
> +??????? for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
> bufferSize++) {
> +??????????? try (
> +??????????????????? InputStream in = Base64.getDecoder().wrap(
> +??????????????????????????? new ByteArrayInputStream(encoded));
> +??????????????????? ByteArrayOutputStream baos = new 
> ByteArrayOutputStream();
> +??????????? ) {
> +??????????????? byte[] buffer = new byte[bufferSize];
> +??????????????? int read;
> +??????????????? while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
> +??????????????????? baos.write(buffer, 0, read);
> +??????????????? }
> +??????????????? // compare result, output info if lengths do not match
> +??????????????? byte[] decoded = baos.toByteArray();
> +??????????????? checkEqual(decoded, orig, "Base64 stream decoding 
> failed!");
> +??????????? }
> +??????? }
> +??? }
> ?}
>


From raffaello.giulietti at gmail.com  Wed Jul 15 21:44:23 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 15 Jul 2020 23:44:23 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
 <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
 <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>
Message-ID: <9d351d78-88c1-9e6d-28a0-9aa6c552c251@gmail.com>

Hi Roger,

On 2020-07-15 22:21, Roger Riggs wrote:
> Hi Raffaello,
> 
> Base64.java:
> 2: Please update 2nd copyright year to 2020
> 

I was unsure what to do here, thanks for guidance.
I also removed the seemingly useless import at former L33.



> leftovers():
> 996: "&" the shortcutting && is more typical in a condition.
> 997: the -= is buried in an expression and a reader might miss it.
> 

Corrected, as well as the analogous -= usage for wpos now at L1106-7


> 
> 1053:? "can be reallocated to other vars":? not a useful comment, 
> reflecting on only one possible implementation that is out of the 
> control of the developer.
> I'd almost rather see 'len' than 'limit - off'; it might be informative 
> to the reader if 'limit' was declared final. (1056:)
> 

Done, as well as declaring i and v final in the loop.



> TestBase54.java:
> 
> 2: Update 2nd copyright year to 2020
> 
> 27:? Please add the bug number to the @bug line.
> 
> Style-wise, I would remove the blank lines at the beginning of blocks. 
> (1095, 1115)
> 

Done.


> Thanks, Roger
> 
> 
> On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
>> Hi Roger,
>>
>> here's the latest version of the patch.
>>
>> I did:
>> * Withdraw the simplification in encodedOutLength(), as it is indeed 
>> out of scope for this bug fix.
>> * Restore field names in DecInputStream except for nextin (now wpos) 
>> and nextout (now rpos) because they have slightly different semantics. 
>> That's just for clarity. I would have nothing against reusing the old 
>> names for the proposed purpose.
>> * Switch back to the original no-arg read() implementation.
>> * Adjust comment continuation lines.
>> * Preserve the proposed logic of read(byte[], int, int) and the 
>> supporting methods.
>>
>> Others needed changes are:
>> * Correct the copyright years: that's something better left to Oracle.
>> * Remove the apparently useless import at L33. I could build and run 
>> without it.
>>
>>
>> Greetings
>> Raffaello
>>


----

# HG changeset patch
# User lello
# Date 1594848775 -7200
#      Wed Jul 15 23:32:55 2020 +0200
# Node ID f7407f35e83ab508f0e6deab4f776bb1a1c85e68
# Parent  a5649ebf94193770ca763391dd63807059d333b4
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at 
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>

diff --git a/src/java.base/share/classes/java/util/Base64.java 
b/src/java.base/share/classes/java/util/Base64.java
--- a/src/java.base/share/classes/java/util/Base64.java
+++ b/src/java.base/share/classes/java/util/Base64.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2012, 2020, 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
@@ -30,7 +30,6 @@
  import java.io.IOException;
  import java.io.OutputStream;
  import java.nio.ByteBuffer;
-import java.nio.charset.StandardCharsets;

  import sun.nio.cs.ISO_8859_1;

@@ -961,12 +960,15 @@

          private final InputStream is;
          private final boolean isMIME;
-        private final int[] base64;      // base64 -> byte mapping
-        private int bits = 0;            // 24-bit buffer for decoding
-        private int nextin = 18;         // next available "off" in 
"bits" for input;
-                                         // -> 18, 12, 6, 0
-        private int nextout = -8;        // next available "off" in 
"bits" for output;
-                                         // -> 8, 0, -8 (no byte for 
output)
+        private final int[] base64;     // base64 -> byte mapping
+        private int bits = 0;           // 24-bit buffer for decoding
+
+        /* writing bit pos inside bits; one of 24 (left, msb), 18, 12, 
6, 0 */
+        private int wpos = 0;
+
+        /* reading bit pos inside bits: one of 24 (left, msb), 16, 8, 0 */
+        private int rpos = 0;
+
          private boolean eof = false;
          private boolean closed = false;

@@ -983,107 +985,153 @@
              return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
          }

-        private int eof(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
+        private int leftovers(byte[] b, int off, int pos, int limit) {
              eof = true;
-            if (nextin != 18) {
-                if (nextin == 12)
-                    throw new IOException("Base64 stream has one 
un-decoded dangling byte.");
-                // treat ending xx/xxx without padding character legal.
-                // same logic as v == '=' below
-                b[off++] = (byte)(bits >> (16));
-                if (nextin == 0) {           // only one padding byte
-                    if (len == 1) {          // no enough output space
-                        bits >>= 8;          // shift to lowest byte
-                        nextout = 0;
-                    } else {
-                        b[off++] = (byte) (bits >>  8);
-                    }
-                }
+
+            /*
+             * We use a loop here, as this method is executed only a 
few times.
+             * Unrolling the loop would probably not contribute much here.
+             */
+            while (rpos - 8 >= wpos && pos != limit) {
+                rpos -= 8;
+                b[pos++] = (byte) (bits >> rpos);
              }
-            return off == oldOff ? -1 : off - oldOff;
+            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
          }

-        private int padding(byte[] b, int off, int len, int oldOff)
-            throws IOException
-        {
-            // =     shiftto==18 unnecessary padding
-            // x=    shiftto==12 dangling x, invalid unit
-            // xx=   shiftto==6 && missing last '='
-            // xx=y  or last is not '='
-            if (nextin == 18 || nextin == 12 ||
-                nextin == 6 && is.read() != '=') {
-                throw new IOException("Illegal base64 ending sequence:" 
+ nextin);
+        private int eof(byte[] b, int off, int pos, int limit) throws 
IOException {
+            /*
+             * pos != limit
+             *
+             * wpos == 18: x     dangling single x, invalid unit
+             * accept ending xx or xxx without padding characters
+             */
+            if (wpos == 18) {
+                throw new IOException("Base64 stream has one un-decoded 
dangling byte.");
              }
-            b[off++] = (byte)(bits >> (16));
-            if (nextin == 0) {           // only one padding byte
-                if (len == 1) {          // no enough output space
-                    bits >>= 8;          // shift to lowest byte
-                    nextout = 0;
-                } else {
-                    b[off++] = (byte) (bits >>  8);
-                }
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
+        }
+
+        private int padding(byte[] b, int off, int pos, int limit) 
throws IOException {
+            /*
+             * pos != limit
+             *
+             * wpos == 24: =    (unnecessary padding)
+             * wpos == 18: x=   (dangling single x, invalid unit)
+             * wpos == 12 and missing last '=': xx=  (invalid padding)
+             * wpos == 12 and last is not '=': xx=x (invalid padding)
+             */
+            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
+                throw new IOException("Illegal base64 ending sequence:" 
+ wpos);
              }
-            eof = true;
-            return off - oldOff;
+            rpos = 24;
+            return leftovers(b, off, pos, limit);
          }

          @Override
          public int read(byte[] b, int off, int len) throws IOException {
-            if (closed)
+            if (closed) {
                  throw new IOException("Stream is closed");
-            if (eof && nextout < 0)    // eof and no leftover
-                return -1;
-            if (off < 0 || len < 0 || len > b.length - off)
-                throw new IndexOutOfBoundsException();
-            int oldOff = off;
-            while (nextout >= 0) {       // leftover output byte(s) in 
bits buf
-                if (len == 0)
-                    return off - oldOff;
-                b[off++] = (byte)(bits >> nextout);
-                len--;
-                nextout -= 8;
+            }
+            Objects.checkFromIndexSize(off, len, b.length);
+            if (len == 0) {
+                return 0;
              }
-            bits = 0;
-            while (len > 0) {
-                int v = is.read();
-                if (v == -1) {
-                    return eof(b, off, len, oldOff);
+
+            /*
+             * Rather than keeping 2 running vars (e.g., off and len),
+             * we only keep one (pos), while definitely fixing the 
boundaries
+             * of the range [off, limit).
+             * More specifically, each use of pos as an index in b meets
+             *      pos - off >= 0 & limit - pos > 0
+             *
+             * Note that limit can overflow to Integer.MIN_VALUE. However,
+             * as long as comparisons with pos are as coded, there's no 
harm.
+             */
+            int pos = off;
+            final int limit = off + len;
+            if (eof) {
+                return leftovers(b, off, pos, limit);
+            }
+
+            /*
+             * Leftovers from previous invocation; here, wpos = 0.
+             * There can be at most 2 leftover bytes (rpos <= 16).
+             * Further, b has at least one free place.
+             *
+             * The logic could be coded as a loop, (as in method 
leftovers())
+             * but the explicit "unrolling" makes it possible to generate
+             * better byte extraction code.
+             */
+            if (rpos == 16) {
+                b[pos++] = (byte) (bits >> 8);
+                rpos = 8;
+                if (pos == limit) {
+                    return len;
                  }
-                if ((v = base64[v]) < 0) {
-                    if (v == -2) {       // padding byte(s)
-                        return padding(b, off, len, oldOff);
-                    }
-                    if (v == -1) {
-                        if (!isMIME)
-                            throw new IOException("Illegal base64 
character " +
-                                Integer.toString(v, 16));
-                        continue;        // skip if for rfc2045
-                    }
-                    // neve be here
-                }
-                bits |= (v << nextin);
-                if (nextin == 0) {
-                    nextin = 18;         // clear for next in
-                    b[off++] = (byte)(bits >> 16);
-                    if (len == 1) {
-                        nextout = 8;    // 2 bytes left in bits
-                        break;
-                    }
-                    b[off++] = (byte)(bits >> 8);
-                    if (len == 2) {
-                        nextout = 0;    // 1 byte left in bits
-                        break;
-                    }
-                    b[off++] = (byte)bits;
-                    len -= 3;
-                    bits = 0;
-                } else {
-                    nextin -= 6;
+            }
+            if (rpos == 8) {
+                b[pos++] = (byte) bits;
+                rpos = 0;
+                if (pos == limit) {
+                    return len;
                  }
              }
-            return off - oldOff;
+
+            bits = 0;
+            wpos = 24;
+            for (;;) {
+                /* pos != limit & rpos == 0 */
+                final int i = is.read();
+                if (i < 0) {
+                    return eof(b, off, pos, limit);
+                }
+                final int v = base64[i];
+                if (v < 0) {
+                    /*
+                     * i not in alphabet, thus
+                     *      v == -2: i is '=', the padding
+                     *      v == -1: i is something else, typically CR 
or LF
+                     */
+                    if (v == -1) {
+                        if (isMIME) {
+                            continue;
+                        }
+                        throw new IOException("Illegal base64 character 
0x" +
+                                Integer.toHexString(i));
+                    }
+                    return padding(b, off, pos, limit);
+                }
+                wpos -= 6;
+                bits |= v << wpos;
+                if (wpos != 0) {
+                    continue;
+                }
+                if (limit - pos >= 3) {
+                    /* frequently taken fast path, no need to track rpos */
+                    b[pos++] = (byte) (bits >> 16);
+                    b[pos++] = (byte) (bits >> 8);
+                    b[pos++] = (byte) bits;
+                    bits = 0;
+                    wpos = 24;
+                    if (pos == limit) {
+                        return len;
+                    }
+                    continue;
+                }
+
+                /* b has either 1 or 2 free places */
+                b[pos++] = (byte) (bits >> 16);
+                if (pos == limit) {
+                    rpos = 16;
+                    return len;
+                }
+                b[pos++] = (byte) (bits >> 8);
+                /* pos == limit, no need for an if */
+                rpos = 8;
+                return len;
+            }
          }

          @Override
diff --git a/test/jdk/java/util/Base64/TestBase64.java 
b/test/jdk/java/util/Base64/TestBase64.java
--- a/test/jdk/java/util/Base64/TestBase64.java
+++ b/test/jdk/java/util/Base64/TestBase64.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2012, 2020, 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
@@ -24,7 +24,7 @@
  /**
   * @test
   * @bug 4235519 8004212 8005394 8007298 8006295 8006315 8006530 
8007379 8008925
- *      8014217 8025003 8026330 8028397 8129544 8165243 8176379
+ *      8014217 8025003 8026330 8028397 8129544 8165243 8176379 8222187
   * @summary tests java.util.Base64
   * @library /test/lib
   * @build jdk.test.lib.RandomFactory
@@ -144,6 +144,10 @@
          testDecoderKeepsAbstinence(Base64.getDecoder());
          testDecoderKeepsAbstinence(Base64.getUrlDecoder());
          testDecoderKeepsAbstinence(Base64.getMimeDecoder());
+
+        // tests patch addressing JDK-8222187
+        // https://bugs.openjdk.java.net/browse/JDK-8222187
+        testJDK_8222187();
      }

      private static void test(Base64.Encoder enc, Base64.Decoder dec,
@@ -607,4 +611,26 @@
              }
          }
      }
+
+    private static void testJDK_8222187() throws Throwable {
+        byte[] orig = "12345678".getBytes("US-ASCII");
+        byte[] encoded = Base64.getEncoder().encode(orig);
+        // decode using different buffer sizes, up to a longer one than 
needed
+        for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
bufferSize++) {
+            try (
+                    InputStream in = Base64.getDecoder().wrap(
+                            new ByteArrayInputStream(encoded));
+                    ByteArrayOutputStream baos = new 
ByteArrayOutputStream();
+            ) {
+                byte[] buffer = new byte[bufferSize];
+                int read;
+                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
+                    baos.write(buffer, 0, read);
+                }
+                // compare result, output info if lengths do not match
+                byte[] decoded = baos.toByteArray();
+                checkEqual(decoded, orig, "Base64 stream decoding 
failed!");
+            }
+        }
+    }
  }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8222187.patch
Type: text/x-patch
Size: 14034 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200715/e09ab6c1/JDK-8222187-0001.patch>

From alexey.semenyuk at oracle.com  Wed Jul 15 22:09:16 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 15 Jul 2020 18:09:16 -0400
Subject: RFR: JDK-8249289: Exception thrown when --temp points to
 non-existant directory
In-Reply-To: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>
References: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>
Message-ID: <82d83c64-7c11-73ab-fc2e-1911c690bbc9@oracle.com>

Andy,

Stream.close() call is missing on the result of Files.list() call.
I'd also replace Files.list(root) with Files.walk(root, 1) call to 
eliminate diving in directory tree.

- Alexey

On 7/15/2020 2:37 PM, Andy Herrick wrote:
> Please review the jpackage fix for issue [1] at [2].
>
> This fixes the regression in JDK16 which caused exception when an 
> empty directory was used int the --temp jpackage option, and added to 
> the existing test.
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8249289
>
> [2[ - http://cr.openjdk.java.net/~herrick/8249289/webrev.02/
>
> /Andy
>


From alexander.matveev at oracle.com  Wed Jul 15 22:41:41 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Wed, 15 Jul 2020 15:41:41 -0700
Subject: RFR: JDK-8249289: Exception thrown when --temp points to
 non-existant directory
In-Reply-To: <82d83c64-7c11-73ab-fc2e-1911c690bbc9@oracle.com>
References: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>
 <82d83c64-7c11-73ab-fc2e-1911c690bbc9@oracle.com>
Message-ID: <faf2a177-b134-1bfd-54a1-b92fb29b77a5@oracle.com>

Hi Andy,

Can you double check two other places where File.list() was introduced 
with JDK-8223955 for similar issues?
One in MacPkgBundler.java and second in DeployParams.java.

Thanks,
Alexander

On 7/15/20 3:09 PM, Alexey Semenyuk wrote:
> Andy,
>
> Stream.close() call is missing on the result of Files.list() call.
> I'd also replace Files.list(root) with Files.walk(root, 1) call to 
> eliminate diving in directory tree.
>
> - Alexey
>
> On 7/15/2020 2:37 PM, Andy Herrick wrote:
>> Please review the jpackage fix for issue [1] at [2].
>>
>> This fixes the regression in JDK16 which caused exception when an 
>> empty directory was used int the --temp jpackage option, and added to 
>> the existing test.
>>
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8249289
>>
>> [2[ - http://cr.openjdk.java.net/~herrick/8249289/webrev.02/
>>
>> /Andy
>>
>


From alexander.matveev at oracle.com  Wed Jul 15 23:29:45 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Wed, 15 Jul 2020 16:29:45 -0700
Subject: RFR: 8245311: [macos] misc package tests failed due to "execution
 error: Finder got an error: AppleEvent timed out."
Message-ID: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>

Please review the jpackage fix for bug [1] at [2].

- "hdiutil detach" resource busy error is fixed in same way as 
JDK-8242786 by repeating detach several times.
- pkgbuild timeout will be covered with JDK-8249395.

[1] https://bugs.openjdk.java.net/browse/JDK-8245311
[2] http://cr.openjdk.java.net/~almatvee/8245311/webrev.00/

Thanks,
Alexander

From Alan.Bateman at oracle.com  Thu Jul 16 07:09:10 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Jul 2020 08:09:10 +0100
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
In-Reply-To: <8c6d42af3f36953d8b680c7c07c112e7ff75574b.camel@redhat.com>
References: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
 <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>
 <8c6d42af3f36953d8b680c7c07c112e7ff75574b.camel@redhat.com>
Message-ID: <95f93bec-6dde-d532-ca49-2739be463dd5@oracle.com>

On 15/07/2020 20:47, Roman Kennke wrote:
> :
> Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the
> default for all GCs but Shenandoah, and has been that way forever. Do
> you mean +ExplicitGCInvokesConcurrent?)
>
Just surprised that more tests aren't impacted. RMI DGC wouldn't work 
with a STW collector if explicit GC were disabled. I haven't heard of 
deployment using it with a concurrent GC but maybe it's okay. I'm just 
surprised that the RMI tests in the jdk repo are robust enough to pass, 
I would have guessed they might need attention (the test group is 
jdk_rmi but it sounds like you might be running those already).

-Alan

From rkennke at redhat.com  Thu Jul 16 09:19:21 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 16 Jul 2020 11:19:21 +0200
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
In-Reply-To: <95f93bec-6dde-d532-ca49-2739be463dd5@oracle.com>
References: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
 <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>
 <8c6d42af3f36953d8b680c7c07c112e7ff75574b.camel@redhat.com>
 <95f93bec-6dde-d532-ca49-2739be463dd5@oracle.com>
Message-ID: <ea84e5a12c8ed01627d1edb245524a8e8cb50530.camel@redhat.com>

On Thu, 2020-07-16 at 08:09 +0100, Alan Bateman wrote:
> On 15/07/2020 20:47, Roman Kennke wrote:
> > :
> > Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the
> > default for all GCs but Shenandoah, and has been that way forever.
> > Do
> > you mean +ExplicitGCInvokesConcurrent?)
> > 
> Just surprised that more tests aren't impacted. RMI DGC wouldn't
> work 
> with a STW collector if explicit GC were disabled.

Yeah, but +ExplicitGCInvokesConcurrent doesn't disable System.gc(), it
only turns it into a concurrent cycle with the calling thread waiting
for it to comlete. That is semantically very close to what STW
System.gc() does.

DirectBufferAllocTest is only problematic because it is not reliable as
it is, and the added concurrency makes it worse, as far as I can tell.

>  I haven't heard of 
> deployment using it with a concurrent GC but maybe it's okay. I'm
> just 
> surprised that the RMI tests in the jdk repo are robust enough to
> pass, 
> I would have guessed they might need attention (the test group is 
> jdk_rmi but it sounds like you might be running those already).

I've just run it again with my setup and it all passes.

You ok with the patch?

Thanks,
Roman



From matthias.baesken at sap.com  Thu Jul 16 10:53:40 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 16 Jul 2020 10:53:40 +0000
Subject: addon to 8230613: Better ASCII conversions  ?
Message-ID: <AM0PR02MB5412F1A80A87A22472748AC9937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hello, recent change

https://hg.openjdk.java.net/jdk/jdk/rev/9e70cd55ae08

8230613: Better ASCII conversions

Adjusted one place  in  file Punycode.java   to throw  the declared ParseException in

    public static StringBuffer encode(StringBuffer src, boolean[] caseFlags) throws ParseException{  ...  }

I think we should  better adjust  the  remaining  throw   in  the same method  as well to a ParseException .  See  small patch below.
Should I open a JBS  issue  for this ?

Thanks, Matthias



diff -r 0150b301ac5a src/java.base/share/classes/jdk/internal/icu/impl/Punycode.java
--- a/src/java.base/share/classes/jdk/internal/icu/impl/Punycode.java   Wed Jul 15 21:24:39 2020 -0700
+++ b/src/java.base/share/classes/jdk/internal/icu/impl/Punycode.java   Thu Jul 16 12:49:07 2020 +0200
@@ -252,7 +252,7 @@
              * <n,i> state to <m,0>, but guard against overflow:
              */
             if(m-n>(0x7fffffff-MAX_CP_COUNT-delta)/(handledCPCount+1)) {
-                throw new RuntimeException("Internal program error");
+                throw new ParseException("Internal program error, potential overflow", -1);
             }
             delta+=(m-n)*(handledCPCount+1);
             n=m;

From Alan.Bateman at oracle.com  Thu Jul 16 10:57:34 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Jul 2020 11:57:34 +0100
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
In-Reply-To: <ea84e5a12c8ed01627d1edb245524a8e8cb50530.camel@redhat.com>
References: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
 <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>
 <8c6d42af3f36953d8b680c7c07c112e7ff75574b.camel@redhat.com>
 <95f93bec-6dde-d532-ca49-2739be463dd5@oracle.com>
 <ea84e5a12c8ed01627d1edb245524a8e8cb50530.camel@redhat.com>
Message-ID: <3b6fb18f-9ac5-e982-8c19-1c55da5ea560@oracle.com>

On 16/07/2020 10:19, Roman Kennke wrote:
> :
> I've just run it again with my setup and it all passes.
>
> You ok with the patch?
>
Yes, I think it's okay to push.

-Alan

From Alan.Bateman at oracle.com  Thu Jul 16 11:55:54 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Jul 2020 12:55:54 +0100
Subject: addon to 8230613: Better ASCII conversions ?
In-Reply-To: <AM0PR02MB5412F1A80A87A22472748AC9937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB5412F1A80A87A22472748AC9937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <c90b0c0b-2509-4862-ae7e-40eecd850283@oracle.com>

On 16/07/2020 11:53, Baesken, Matthias wrote:
> Hello, recent change
>
> https://hg.openjdk.java.net/jdk/jdk/rev/9e70cd55ae08
>
> 8230613: Better ASCII conversions
>
> Adjusted one place  in  file Punycode.java   to throw  the declared ParseException in
>
>      public static StringBuffer encode(StringBuffer src, boolean[] caseFlags) throws ParseException{  ...  }
>
> I think we should  better adjust  the  remaining  throw   in  the same method  as well to a ParseException .  See  small patch below.
> Should I open a JBS  issue  for this ?
>
I wonder if it is possible to create a test case that uses IDN.toASCII 
and trickles this case in Punnycode. In passing, it might be that the 
IAE specified by toASCII needs clarification for the additional cases 
where it will reject input.

-Alan.

From matthias.baesken at sap.com  Thu Jul 16 12:19:34 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 16 Jul 2020 12:19:34 +0000
Subject: addon to 8230613: Better ASCII conversions ?
In-Reply-To: <c90b0c0b-2509-4862-ae7e-40eecd850283@oracle.com>
References: <AM0PR02MB5412F1A80A87A22472748AC9937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <c90b0c0b-2509-4862-ae7e-40eecd850283@oracle.com>
Message-ID: <AM0PR02MB5412678D4754EABACAC4B150937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>


Hi Alan, I do not have such a test case .
Is there one for the  change 8230613 ?

The only call to Punycode.encode in IDN.java  is  below and the coding intends to catch java.text.ParseException  from  Punycode.encode
and then throws an IllegalArgumentException . I see nothing  regarding  RuntimeException  in IDN .


jdk/src/java.base/share/classes/java/net/IDN.java


260    private static String toASCIIInternal(String label, int flag)
          .....
312            if (!isAllASCII(dest.toString())) {
313                // step 5
314                // verify the sequence does not begin with ACE prefix
315                if(!startsWithACEPrefix(dest)){
316
317                    // step 6
318                    // encode the sequence with punycode
319                    try {
320                        dest = Punycode.encode(dest, null);
321                    } catch (java.text.ParseException e) {
322                        throw new IllegalArgumentException(e);
323                    }
324
325                    dest = toASCIILower(dest);
326
327                    // step 7
328                    // prepend the ACE prefix
329                    dest.insert(0, ACE_PREFIX);
330                } else {
331                    throw new IllegalArgumentException("The input starts with the ACE Prefix");
332                }

Best regards, Matthias


>> Hello, recent change
>>
>> https://hg.openjdk.java.net/jdk/jdk/rev/9e70cd55ae08
>>
>> 8230613: Better ASCII conversions
>>
>> Adjusted one place  in  file Punycode.java   to throw  the declared ParseException in
>>
>>      public static StringBuffer encode(StringBuffer src, boolean[] caseFlags) throws ParseException{  ...  }
>>
>> I think we should  better adjust  the  remaining  throw   in  the same method  as well to a ParseException .  See  small patch below.
>> Should I open a JBS  issue  for this ?
>>
>I wonder if it is possible to create a test case that uses IDN.toASCII 
>and trickles this case in Punnycode. In passing, it might be that the 
>IAE specified by toASCII needs clarification for the additional cases 
>where it will reject input.


From roger.riggs at oracle.com  Thu Jul 16 12:42:13 2020
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 16 Jul 2020 08:42:13 -0400
Subject: RFR: 8249543: Force DirectBufferAllocTest to run with
 -ExplicitGCInvokesConcurrent
In-Reply-To: <95f93bec-6dde-d532-ca49-2739be463dd5@oracle.com>
References: <751a1935bfcbc92d3c29acaeb8846a85a0ce1664.camel@redhat.com>
 <82bb8596-0f7b-6266-45d3-80f042ed4db0@oracle.com>
 <8c6d42af3f36953d8b680c7c07c112e7ff75574b.camel@redhat.com>
 <95f93bec-6dde-d532-ca49-2739be463dd5@oracle.com>
Message-ID: <addea518-75b4-86d5-a354-833d1a2b505c@oracle.com>

Hi,

RMI DGC relies only on WeakReferences so unless that is disabled, RMI 
should not see any difference.
The tests do provoke GC to run, so if it doesn't eventually clear weak 
refs (within a timeout) that would fail.

Thanks, Roger

On 7/16/20 3:09 AM, Alan Bateman wrote:
> On 15/07/2020 20:47, Roman Kennke wrote:
>> :
>> Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the
>> default for all GCs but Shenandoah, and has been that way forever. Do
>> you mean +ExplicitGCInvokesConcurrent?)
>>
> Just surprised that more tests aren't impacted. RMI DGC wouldn't work 
> with a STW collector if explicit GC were disabled. I haven't heard of 
> deployment using it with a concurrent GC but maybe it's okay. I'm just 
> surprised that the RMI tests in the jdk repo are robust enough to 
> pass, I would have guessed they might need attention (the test group 
> is jdk_rmi but it sounds like you might be running those already).
>
> -Alan


From alexander.scherbatiy at bell-sw.com  Thu Jul 16 13:34:44 2020
From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy)
Date: Thu, 16 Jul 2020 16:34:44 +0300
Subject: RFR: 8249612 Remove unused ISNANF and ISNAND from jdk_util_md.h
Message-ID: <bd15f336-5941-c930-259a-20b7256758cf@bell-sw.com>

Hello,

Could you review a simple clean up of jdk_util_md.h files:
 ? Bug: https://bugs.openjdk.java.net/browse/JDK-8249612
 ? Fix: http://cr.openjdk.java.net/~alexsch/8249612/webrev.00

JDK-8001334 [1] defines ISNANF and ISNAND in jdk_util_md.h.
JDK-8199424 [2] removes ISNANF and ISNAND usage.
ISNANF and ISNAND are not used any more in JDK code.
The proposed fix removes ISNANF and ISNAND definition from jdk_util_md.h.

[1] https://hg.openjdk.java.net/jdk/jdk/rev/e269be167fae
[2] https://hg.openjdk.java.net/jdk/jdk/rev/da8673f61e94

Thanks,
Alexander.


From Alan.Bateman at oracle.com  Thu Jul 16 13:43:53 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Jul 2020 14:43:53 +0100
Subject: addon to 8230613: Better ASCII conversions ?
In-Reply-To: <AM0PR02MB5412678D4754EABACAC4B150937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB5412F1A80A87A22472748AC9937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <c90b0c0b-2509-4862-ae7e-40eecd850283@oracle.com>
 <AM0PR02MB5412678D4754EABACAC4B150937F0@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <edb89813-8b4b-01dd-8eb9-9a242cd261f0@oracle.com>

On 16/07/2020 13:19, Baesken, Matthias wrote:
> Hi Alan, I do not have such a test case .
> Is there one for the  change 8230613 ?
>
> The only call to Punycode.encode in IDN.java  is  below and the coding intends to catch java.text.ParseException  from  Punycode.encode
> and then throws an IllegalArgumentException . I see nothing  regarding  RuntimeException  in IDN .
>
Tests for changes in security updates are not included in the jdk repo.

IDN.toASCII only specifies IAE so it would be useful to find input that 
tickles other (non-resource) exceptions. Aleksei tells me that he 
couldn't find input that would cause this so this is why it was not 
changed at the time.

-Alan

From mikael.vidstedt at oracle.com  Thu Jul 16 15:50:56 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 16 Jul 2020 08:50:56 -0700
Subject: RFR: 8249612 Remove unused ISNANF and ISNAND from jdk_util_md.h
In-Reply-To: <bd15f336-5941-c930-259a-20b7256758cf@bell-sw.com>
References: <bd15f336-5941-c930-259a-20b7256758cf@bell-sw.com>
Message-ID: <23782D1B-0EFB-4B00-A5B2-651B6D30FF19@oracle.com>


Nice find! :)

Cheers,
Mikael

> On Jul 16, 2020, at 6:34 AM, Alexander Scherbatiy <alexander.scherbatiy at bell-sw.com> wrote:
> 
> Hello,
> 
> Could you review a simple clean up of jdk_util_md.h files:
>   Bug: https://bugs.openjdk.java.net/browse/JDK-8249612
>   Fix: http://cr.openjdk.java.net/~alexsch/8249612/webrev.00
> 
> JDK-8001334 [1] defines ISNANF and ISNAND in jdk_util_md.h.
> JDK-8199424 [2] removes ISNANF and ISNAND usage.
> ISNANF and ISNAND are not used any more in JDK code.
> The proposed fix removes ISNANF and ISNAND definition from jdk_util_md.h.
> 
> [1] https://hg.openjdk.java.net/jdk/jdk/rev/e269be167fae
> [2] https://hg.openjdk.java.net/jdk/jdk/rev/da8673f61e94
> 
> Thanks,
> Alexander.
> 


From andy.herrick at oracle.com  Thu Jul 16 18:44:15 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 16 Jul 2020 14:44:15 -0400
Subject: RFR: JDK-8249289: Exception thrown when --temp points to
 non-existant directory
In-Reply-To: <faf2a177-b134-1bfd-54a1-b92fb29b77a5@oracle.com>
References: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>
 <82d83c64-7c11-73ab-fc2e-1911c690bbc9@oracle.com>
 <faf2a177-b134-1bfd-54a1-b92fb29b77a5@oracle.com>
Message-ID: <332059dc-fb75-bdd5-5fb9-e82d29cb3bd0@oracle.com>

yes - revised as suggested - please re review.

/Andy

On 7/15/2020 6:41 PM, alexander.matveev at oracle.com wrote:
> Hi Andy,
>
> Can you double check two other places where File.list() was introduced 
> with JDK-8223955 for similar issues?
> One in MacPkgBundler.java and second in DeployParams.java.
>
> Thanks,
> Alexander
>
> On 7/15/20 3:09 PM, Alexey Semenyuk wrote:
>> Andy,
>>
>> Stream.close() call is missing on the result of Files.list() call.
>> I'd also replace Files.list(root) with Files.walk(root, 1) call to 
>> eliminate diving in directory tree.
>>
>> - Alexey
>>
>> On 7/15/2020 2:37 PM, Andy Herrick wrote:
>>> Please review the jpackage fix for issue [1] at [2].
>>>
>>> This fixes the regression in JDK16 which caused exception when an 
>>> empty directory was used int the --temp jpackage option, and added 
>>> to the existing test.
>>>
>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8249289
>>>
>>> [2[ - http://cr.openjdk.java.net/~herrick/8249289/webrev.02/
>>>
>>> /Andy
>>>
>>
>

From andy.herrick at oracle.com  Thu Jul 16 21:23:51 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 16 Jul 2020 17:23:51 -0400
Subject: RFR: JDK-8247734: [macos] jpackage fails to retrieve signing
 certificate when there are multiple
Message-ID: <f734cb47-ed9b-fc3c-c481-a72b660e9f75@oracle.com>

Please review fix for jpackage bug [1] at [2].

The behavior is to allow (after a warning message) case where user has 
multiple certificates matching the given mac-signing-key-user-name, and 
to allow the full certificate name to be used if it is given as user 
name (providing it matches expected certificate names)

/Andy

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

[2] - http://cr.openjdk.java.net/~herrick/8247734/webrev.01/index.html


From alexander.matveev at oracle.com  Thu Jul 16 21:38:20 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Thu, 16 Jul 2020 14:38:20 -0700
Subject: RFR: JDK-8249289: Exception thrown when --temp points to
 non-existant directory
In-Reply-To: <332059dc-fb75-bdd5-5fb9-e82d29cb3bd0@oracle.com>
References: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>
 <82d83c64-7c11-73ab-fc2e-1911c690bbc9@oracle.com>
 <faf2a177-b134-1bfd-54a1-b92fb29b77a5@oracle.com>
 <332059dc-fb75-bdd5-5fb9-e82d29cb3bd0@oracle.com>
Message-ID: <54071f18-cdc4-a5f7-4042-cdd926142000@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 7/16/20 11:44 AM, Andy Herrick wrote:
> yes - revised as suggested - please re review.
>
> /Andy
>
> On 7/15/2020 6:41 PM, alexander.matveev at oracle.com wrote:
>> Hi Andy,
>>
>> Can you double check two other places where File.list() was 
>> introduced with JDK-8223955 for similar issues?
>> One in MacPkgBundler.java and second in DeployParams.java.
>>
>> Thanks,
>> Alexander
>>
>> On 7/15/20 3:09 PM, Alexey Semenyuk wrote:
>>> Andy,
>>>
>>> Stream.close() call is missing on the result of Files.list() call.
>>> I'd also replace Files.list(root) with Files.walk(root, 1) call to 
>>> eliminate diving in directory tree.
>>>
>>> - Alexey
>>>
>>> On 7/15/2020 2:37 PM, Andy Herrick wrote:
>>>> Please review the jpackage fix for issue [1] at [2].
>>>>
>>>> This fixes the regression in JDK16 which caused exception when an 
>>>> empty directory was used int the --temp jpackage option, and added 
>>>> to the existing test.
>>>>
>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8249289
>>>>
>>>> [2[ - http://cr.openjdk.java.net/~herrick/8249289/webrev.02/
>>>>
>>>> /Andy
>>>>
>>>
>>


From alexander.matveev at oracle.com  Thu Jul 16 21:47:27 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Thu, 16 Jul 2020 14:47:27 -0700
Subject: RFR: JDK-8247734: [macos] jpackage fails to retrieve signing
 certificate when there are multiple
In-Reply-To: <f734cb47-ed9b-fc3c-c481-a72b660e9f75@oracle.com>
References: <f734cb47-ed9b-fc3c-c481-a72b660e9f75@oracle.com>
Message-ID: <91c2f2a5-cfff-e22a-3003-7eac84c2fa6b@oracle.com>

Hi Andy,

Looks good.

Thanks,
Alexander

On 7/16/20 2:23 PM, Andy Herrick wrote:
> Please review fix for jpackage bug [1] at [2].
>
> The behavior is to allow (after a warning message) case where user has 
> multiple certificates matching the given mac-signing-key-user-name, 
> and to allow the full certificate name to be used if it is given as 
> user name (providing it matches expected certificate names)
>
> /Andy
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8247734
>
> [2] - http://cr.openjdk.java.net/~herrick/8247734/webrev.01/index.html
>


From alexey.semenyuk at oracle.com  Thu Jul 16 22:38:49 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 16 Jul 2020 18:38:49 -0400
Subject: RFR: JDK-8249289: Exception thrown when --temp points to
 non-existant directory
In-Reply-To: <332059dc-fb75-bdd5-5fb9-e82d29cb3bd0@oracle.com>
References: <22a605f8-4642-89b6-4833-0f6849c8c2f9@oracle.com>
 <82d83c64-7c11-73ab-fc2e-1911c690bbc9@oracle.com>
 <faf2a177-b134-1bfd-54a1-b92fb29b77a5@oracle.com>
 <332059dc-fb75-bdd5-5fb9-e82d29cb3bd0@oracle.com>
Message-ID: <0ec8e3e7-8e19-47de-1909-a898bf1c9c4f@oracle.com>

Diffs at [1] look good!

- Alexey

[1] http://cr.openjdk.java.net/~herrick/8249289/webrev.03/

On 7/16/2020 2:44 PM, Andy Herrick wrote:
> yes - revised as suggested - please re review.
>
> /Andy
>
> On 7/15/2020 6:41 PM, alexander.matveev at oracle.com wrote:
>> Hi Andy,
>>
>> Can you double check two other places where File.list() was 
>> introduced with JDK-8223955 for similar issues?
>> One in MacPkgBundler.java and second in DeployParams.java.
>>
>> Thanks,
>> Alexander
>>
>> On 7/15/20 3:09 PM, Alexey Semenyuk wrote:
>>> Andy,
>>>
>>> Stream.close() call is missing on the result of Files.list() call.
>>> I'd also replace Files.list(root) with Files.walk(root, 1) call to 
>>> eliminate diving in directory tree.
>>>
>>> - Alexey
>>>
>>> On 7/15/2020 2:37 PM, Andy Herrick wrote:
>>>> Please review the jpackage fix for issue [1] at [2].
>>>>
>>>> This fixes the regression in JDK16 which caused exception when an 
>>>> empty directory was used int the --temp jpackage option, and added 
>>>> to the existing test.
>>>>
>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8249289
>>>>
>>>> [2[ - http://cr.openjdk.java.net/~herrick/8249289/webrev.02/
>>>>
>>>> /Andy
>>>>
>>>
>>


From alexey.semenyuk at oracle.com  Thu Jul 16 22:41:01 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 16 Jul 2020 18:41:01 -0400
Subject: RFR: JDK-8247734: [macos] jpackage fails to retrieve signing
 certificate when there are multiple
In-Reply-To: <f734cb47-ed9b-fc3c-c481-a72b660e9f75@oracle.com>
References: <f734cb47-ed9b-fc3c-c481-a72b660e9f75@oracle.com>
Message-ID: <3496ee35-f82e-7f54-952b-04cdbf48f06d@oracle.com>

Looks good.

- Alexey

On 7/16/2020 5:23 PM, Andy Herrick wrote:
> Please review fix for jpackage bug [1] at [2].
>
> The behavior is to allow (after a warning message) case where user has 
> multiple certificates matching the given mac-signing-key-user-name, 
> and to allow the full certificate name to be used if it is given as 
> user name (providing it matches expected certificate names)
>
> /Andy
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8247734
>
> [2] - http://cr.openjdk.java.net/~herrick/8247734/webrev.01/index.html
>


From joe.darcy at oracle.com  Fri Jul 17 02:43:18 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 16 Jul 2020 19:43:18 -0700
Subject: RFR: 8249612 Remove unused ISNANF and ISNAND from jdk_util_md.h
In-Reply-To: <23782D1B-0EFB-4B00-A5B2-651B6D30FF19@oracle.com>
References: <bd15f336-5941-c930-259a-20b7256758cf@bell-sw.com>
 <23782D1B-0EFB-4B00-A5B2-651B6D30FF19@oracle.com>
Message-ID: <bd6e33ba-b907-8528-8b80-0fb9281a0e9f@oracle.com>

Looks fine (when needed, there are equivalents of those in the Java math 
library); thanks,

-Joe

On 7/16/2020 8:50 AM, Mikael Vidstedt wrote:
> Nice find! :)
>
> Cheers,
> Mikael
>
>> On Jul 16, 2020, at 6:34 AM, Alexander Scherbatiy <alexander.scherbatiy at bell-sw.com> wrote:
>>
>> Hello,
>>
>> Could you review a simple clean up of jdk_util_md.h files:
>>    Bug: https://bugs.openjdk.java.net/browse/JDK-8249612
>>    Fix: http://cr.openjdk.java.net/~alexsch/8249612/webrev.00
>>
>> JDK-8001334 [1] defines ISNANF and ISNAND in jdk_util_md.h.
>> JDK-8199424 [2] removes ISNANF and ISNAND usage.
>> ISNANF and ISNAND are not used any more in JDK code.
>> The proposed fix removes ISNANF and ISNAND definition from jdk_util_md.h.
>>
>> [1] https://hg.openjdk.java.net/jdk/jdk/rev/e269be167fae
>> [2] https://hg.openjdk.java.net/jdk/jdk/rev/da8673f61e94
>>
>> Thanks,
>> Alexander.
>>

From sakatakui at oss.nttdata.com  Fri Jul 17 11:26:08 2020
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Fri, 17 Jul 2020 20:26:08 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
Message-ID: <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>

Hi Daniel,

 > The changes to NetworkInterface.c look good to me.

Thank you.

 > You'll need to find a reviewer that understands what that
 > method is supposed to do in that case, that's not me ;-)

I understand. This ML is suitable for finding a reviewer, isn't it?
Or, there is another way. We can avoid the error by the accepting 
maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.

diff --git a/make/modules/java.base/lib/CoreLibraries.gmk 
b/make/modules/java.base/lib/CoreLibraries.gmk
--- a/make/modules/java.base/lib/CoreLibraries.gmk
+++ b/make/modules/java.base/lib/CoreLibraries.gmk
@@ -48,7 +48,7 @@
      CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \
      CFLAGS_windows_debug := -DLOGGING, \
      CFLAGS_aix := -qfloat=nomaf, \
-    DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
array-bounds, \
+    DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
array-bounds maybe-uninitialized, \
      DISABLED_WARNINGS_clang := sign-compare, \
      DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
      ARFLAGS := $(ARFLAGS), \

Thanks,
Koichi

On 2020/07/15 3:36, Daniel Fuchs wrote:
> Hi Koichi,
> 
> On 13/07/2020 08:03, Koichi Sakata wrote:
>  > I understand that. I respect your idea.
>  > I fixed the patch as follows.
> The changes to NetworkInterface.c look good to me.
> 
>  >
>  > By the way, k_standard.c still remains. Is there a way to proceed 
> with it?
> 
> You'll need to find a reviewer that understands what that
> method is supposed to do in that case, that's not me ;-)
> 
> best regards,
> 
> -- daniel
> 
>> Thanks, > Koichi
>>
>> ===== PATCH =====
>> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
>> b/src/java.base/unix/native/libnet/NetworkInterface.c
>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
>> @@ -1296,7 +1296,8 @@
>> ??static int getIndex(int sock, const char *name) {
>> ????? struct ifreq if2;
>> ????? memset((char *)&if2, 0, sizeof(if2));
>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>> +??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>
>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>> ????????? return -1;
>> @@ -1359,7 +1360,8 @@
>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>> ????? struct ifreq if2;
>> ????? memset((char *)&if2, 0, sizeof(if2));
>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>> +??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>
>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>> ????????? return -1;
>> diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
>> b/src/java.base/share/native/libfdlibm/k_standard.c
>> --- a/src/java.base/share/native/libfdlibm/k_standard.c
>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c
>> @@ -739,6 +739,10 @@
>> ????????????????????????? errno = EDOM;
>> ????????????????? }
>> ????????????????? break;
>> +??????????? default:
>> +??????????????? exc.retval = zero;
>> +??????????????? errno = EINVAL;
>> +??????????????? break;
>> ????????? }
>> ????????? return exc.retval;
>> ??}
>>
>>
> 

From suenaga at oss.nttdata.com  Fri Jul 17 13:48:06 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Fri, 17 Jul 2020 22:48:06 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
Message-ID: <17cd90dd-2af5-2179-0d7e-4360f175a6de@oss.nttdata.com>

Hi Koichi,

On 2020/07/17 20:26, Koichi Sakata wrote:
> Hi Daniel,
> 
>  > The changes to NetworkInterface.c look good to me.
> 
> Thank you.
> 
>  > You'll need to find a reviewer that understands what that
>  > method is supposed to do in that case, that's not me ;-)
> 
> I understand. This ML is suitable for finding a reviewer, isn't it?
> Or, there is another way. We can avoid the error by the accepting maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.
> 
> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk b/make/modules/java.base/lib/CoreLibraries.gmk
> --- a/make/modules/java.base/lib/CoreLibraries.gmk
> +++ b/make/modules/java.base/lib/CoreLibraries.gmk
> @@ -48,7 +48,7 @@
>  ???? CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \
>  ???? CFLAGS_windows_debug := -DLOGGING, \
>  ???? CFLAGS_aix := -qfloat=nomaf, \
> -??? DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-bounds, \
> +??? DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-bounds maybe-uninitialized, \
>  ???? DISABLED_WARNINGS_clang := sign-compare, \
>  ???? DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>  ???? ARFLAGS := $(ARFLAGS), \

This change affects all of C sources in core-libs.
So I think it is better affect to k_standard.c only as below:

```
diff --git a/make/modules/java.base/lib/CoreLibraries.gmk b/make/modules/java.base/lib/CoreLibraries.gmk
--- a/make/modules/java.base/lib/CoreLibraries.gmk
+++ b/make/modules/java.base/lib/CoreLibraries.gmk
@@ -39,6 +39,10 @@
  LIBFDLIBM_SRC := $(TOPDIR)/src/java.base/share/native/libfdlibm
  LIBFDLIBM_CFLAGS := -I$(LIBFDLIBM_SRC) $(FDLIBM_CFLAGS)

+ifeq ($(call isTargetOs, linux), true)
+  BUILD_LIBFDLIBM_k_standard.c_CFLAGS += -Wno-maybe-uninitialized
+endif
+
  $(eval $(call SetupNativeCompilation, BUILD_LIBFDLIBM, \
      NAME := fdlibm, \
      TYPE := STATIC_LIBRARY, \
```

You can pass compiler option to specified file.


Thanks,

Yasumasa


> Thanks,
> Koichi
> 
> On 2020/07/15 3:36, Daniel Fuchs wrote:
>> Hi Koichi,
>>
>> On 13/07/2020 08:03, Koichi Sakata wrote:
>> ?> I understand that. I respect your idea.
>> ?> I fixed the patch as follows.
>> The changes to NetworkInterface.c look good to me.
>>
>> ?>
>> ?> By the way, k_standard.c still remains. Is there a way to proceed with it?
>>
>> You'll need to find a reviewer that understands what that
>> method is supposed to do in that case, that's not me ;-)
>>
>> best regards,
>>
>> -- daniel
>>
>>> Thanks, > Koichi
>>>
>>> ===== PATCH =====
>>> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c b/src/java.base/unix/native/libnet/NetworkInterface.c
>>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
>>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
>>> @@ -1296,7 +1296,8 @@
>>> ??static int getIndex(int sock, const char *name) {
>>> ????? struct ifreq if2;
>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>>> +??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>
>>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>>> ????????? return -1;
>>> @@ -1359,7 +1360,8 @@
>>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>>> ????? struct ifreq if2;
>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>>> +??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
>>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>
>>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>>> ????????? return -1;
>>> diff --git a/src/java.base/share/native/libfdlibm/k_standard.c b/src/java.base/share/native/libfdlibm/k_standard.c
>>> --- a/src/java.base/share/native/libfdlibm/k_standard.c
>>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c
>>> @@ -739,6 +739,10 @@
>>> ????????????????????????? errno = EDOM;
>>> ????????????????? }
>>> ????????????????? break;
>>> +??????????? default:
>>> +??????????????? exc.retval = zero;
>>> +??????????????? errno = EINVAL;
>>> +??????????????? break;
>>> ????????? }
>>> ????????? return exc.retval;
>>> ??}
>>>
>>>
>>

From david.holmes at oracle.com  Fri Jul 17 14:05:32 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 18 Jul 2020 00:05:32 +1000
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <17cd90dd-2af5-2179-0d7e-4360f175a6de@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <17cd90dd-2af5-2179-0d7e-4360f175a6de@oss.nttdata.com>
Message-ID: <2a3982e7-e9a5-d376-1143-dab80e68679a@oracle.com>

If you are going to change makefiles you need to get review on 
build-dev at openjdk.java.net :)

David

On 17/07/2020 11:48 pm, Yasumasa Suenaga wrote:
> Hi Koichi,
> 
> On 2020/07/17 20:26, Koichi Sakata wrote:
>> Hi Daniel,
>>
>> ?> The changes to NetworkInterface.c look good to me.
>>
>> Thank you.
>>
>> ?> You'll need to find a reviewer that understands what that
>> ?> method is supposed to do in that case, that's not me ;-)
>>
>> I understand. This ML is suitable for finding a reviewer, isn't it?
>> Or, there is another way. We can avoid the error by the accepting 
>> maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.
>>
>> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk 
>> b/make/modules/java.base/lib/CoreLibraries.gmk
>> --- a/make/modules/java.base/lib/CoreLibraries.gmk
>> +++ b/make/modules/java.base/lib/CoreLibraries.gmk
>> @@ -48,7 +48,7 @@
>> ????? CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \
>> ????? CFLAGS_windows_debug := -DLOGGING, \
>> ????? CFLAGS_aix := -qfloat=nomaf, \
>> -??? DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
>> array-bounds, \
>> +??? DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
>> array-bounds maybe-uninitialized, \
>> ????? DISABLED_WARNINGS_clang := sign-compare, \
>> ????? DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>> ????? ARFLAGS := $(ARFLAGS), \
> 
> This change affects all of C sources in core-libs.
> So I think it is better affect to k_standard.c only as below:
> 
> ```
> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk 
> b/make/modules/java.base/lib/CoreLibraries.gmk
> --- a/make/modules/java.base/lib/CoreLibraries.gmk
> +++ b/make/modules/java.base/lib/CoreLibraries.gmk
> @@ -39,6 +39,10 @@
>  ?LIBFDLIBM_SRC := $(TOPDIR)/src/java.base/share/native/libfdlibm
>  ?LIBFDLIBM_CFLAGS := -I$(LIBFDLIBM_SRC) $(FDLIBM_CFLAGS)
> 
> +ifeq ($(call isTargetOs, linux), true)
> +? BUILD_LIBFDLIBM_k_standard.c_CFLAGS += -Wno-maybe-uninitialized
> +endif
> +
>  ?$(eval $(call SetupNativeCompilation, BUILD_LIBFDLIBM, \
>  ???? NAME := fdlibm, \
>  ???? TYPE := STATIC_LIBRARY, \
> ```
> 
> You can pass compiler option to specified file.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
>> Thanks,
>> Koichi
>>
>> On 2020/07/15 3:36, Daniel Fuchs wrote:
>>> Hi Koichi,
>>>
>>> On 13/07/2020 08:03, Koichi Sakata wrote:
>>> ?> I understand that. I respect your idea.
>>> ?> I fixed the patch as follows.
>>> The changes to NetworkInterface.c look good to me.
>>>
>>> ?>
>>> ?> By the way, k_standard.c still remains. Is there a way to proceed 
>>> with it?
>>>
>>> You'll need to find a reviewer that understands what that
>>> method is supposed to do in that case, that's not me ;-)
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>> Thanks, > Koichi
>>>>
>>>> ===== PATCH =====
>>>> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
>>>> b/src/java.base/unix/native/libnet/NetworkInterface.c
>>>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
>>>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
>>>> @@ -1296,7 +1296,8 @@
>>>> ??static int getIndex(int sock, const char *name) {
>>>> ????? struct ifreq if2;
>>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>>>> +??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>>>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>>
>>>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>>>> ????????? return -1;
>>>> @@ -1359,7 +1360,8 @@
>>>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>>>> ????? struct ifreq if2;
>>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>>>> +??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
>>>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>>
>>>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>>>> ????????? return -1;
>>>> diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
>>>> b/src/java.base/share/native/libfdlibm/k_standard.c
>>>> --- a/src/java.base/share/native/libfdlibm/k_standard.c
>>>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c
>>>> @@ -739,6 +739,10 @@
>>>> ????????????????????????? errno = EDOM;
>>>> ????????????????? }
>>>> ????????????????? break;
>>>> +??????????? default:
>>>> +??????????????? exc.retval = zero;
>>>> +??????????????? errno = EINVAL;
>>>> +??????????????? break;
>>>> ????????? }
>>>> ????????? return exc.retval;
>>>> ??}
>>>>
>>>>
>>>

From andy.herrick at oracle.com  Fri Jul 17 17:03:09 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 17 Jul 2020 13:03:09 -0400
Subject: RFR: 8245311: [macos] misc package tests failed due to "execution
 error: Finder got an error: AppleEvent timed out."
In-Reply-To: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>
References: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>
Message-ID: <6cfe91cc-b74c-3c1e-184a-8e30d8740b48@oracle.com>

Looks OK - I approve.

/Andy

On 7/15/2020 7:29 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - "hdiutil detach" resource busy error is fixed in same way as 
> JDK-8242786 by repeating detach several times.
> - pkgbuild timeout will be covered with JDK-8249395.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8245311
> [2] http://cr.openjdk.java.net/~almatvee/8245311/webrev.00/
>
> Thanks,
> Alexander

From sandhya.viswanathan at intel.com  Fri Jul 17 18:32:04 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Fri, 17 Jul 2020 18:32:04 +0000
Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator):
 Hotspot and x86 backend changes
Message-ID: <BYAPR11MB3543026ABF92A463562E5DE5EF7C0@BYAPR11MB3543.namprd11.prod.outlook.com>

Hi Vladimir and Coleen,

We are getting ready to propose to target Vector API to JDK 16. 
Please find below the updated hotspot and x86 backend changes:

Shared Hotspot:
   Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.01/
   Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.00-webrev.01/

X86:
   Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.01/
   Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00-webrev.01/

Older webrev links for your reference:
Shared Hotspot: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/
X86b backend: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/
To get incremental webrev, I had to do some adjustments to these to be able to apply it to the jdk tip.

Please let us know your feedback and if we have ok from you to propose to target to JDK 16. 

Best Regards,
Sandhya

-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
Sent: Friday, May 01, 2020 6:05 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev <hotspot-dev at openjdk.java.net>
Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes

On 5/1/20 5:55 PM, Viswanathan, Sandhya wrote:
> Hi Vladimir,
> 
> Thanks a lot for the feedback.
> 
> We used an old existing separate branch to share the code for review and to track changes.
> We didn?t know how to change the name of the branch from vector-unstable to vector-stable.

Good to know that it does not mean that code is "unstable" ;)

Katya filed today new bug [1]. Please look.

Regards,
Vladimir

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

> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Friday, May 01, 2020 5:32 PM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes
> 
> Changes seems fine. Nice work.
> 
> Why it is called "vector-unstable branch"?
> 
> Thanks,
> Vladimir K
> 
> On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote:
>> Hi,
>>
>>
>> Following up on review requests of API [0], Java implementation [1] and
>>
>> General Hotspot changes[3] for Vector API, here's a request for review
>>
>> of x86 backend changes required for supporting the API:
>>
>>
>>
>> JEP: https://openjdk.java.net/jeps/338
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347
>>
>> Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/
>>
>>
>>
>> Complete implementation resides in vector-unstable branch of
>>
>> panama/dev repository [3].
>>
>> Looking forward to your feedback.
>>
>> Best Regards,
>> Sandhya
>>
>>
>> [0]  https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html
>>
>>
>>
>> [1]  https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html
>>
>>
>>
>> [2]  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html
>>
>>
>>
>> [3]  https://openjdk.java.net/projects/panama/
>>
>>          $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable
>>
>>
>>
>>
>>

From joe.darcy at oracle.com  Fri Jul 17 22:03:24 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 17 Jul 2020 15:03:24 -0700
Subject: JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more
 places in java.base
Message-ID: <3cbb3c7b-49e8-2b56-71a9-49955e3d102a@oracle.com>

Hello,

Following-up on? JDK-8237805 and some recent observations from Mikael 
V., there are more locations in the base module where in-line @jls and 
@jvms tags are appropriate to use. Please review their addition:

 ??? http://cr.openjdk.java.net/~darcy/8249687.0/

I checked that the sections were correct for the current JLS and JVMS, 
which led to a change of referenced section in AssertionError.

Thanks,

-Joe


From brian.burkhalter at oracle.com  Fri Jul 17 22:30:09 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 17 Jul 2020 15:30:09 -0700
Subject: JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more
 places in java.base
In-Reply-To: <3cbb3c7b-49e8-2b56-71a9-49955e3d102a@oracle.com>
References: <3cbb3c7b-49e8-2b56-71a9-49955e3d102a@oracle.com>
Message-ID: <41846EB8-BFBB-4E5A-9DC7-E75E9B0AD19C@oracle.com>

Hi Joe,

+1

Brian

> On Jul 17, 2020, at 3:03 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Following-up on  JDK-8237805 and some recent observations from Mikael V., there are more locations in the base module where in-line @jls and @jvms tags are appropriate to use. Please review their addition:
> 
>     http://cr.openjdk.java.net/~darcy/8249687.0/ <http://cr.openjdk.java.net/~darcy/8249687.0/>
> 
> I checked that the sections were correct for the current JLS and JVMS, which led to a change of referenced section in AssertionError.


From joe.darcy at oracle.com  Fri Jul 17 23:04:08 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 17 Jul 2020 16:04:08 -0700
Subject: JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more
 places in java.base
In-Reply-To: <41846EB8-BFBB-4E5A-9DC7-E75E9B0AD19C@oracle.com>
References: <3cbb3c7b-49e8-2b56-71a9-49955e3d102a@oracle.com>
 <41846EB8-BFBB-4E5A-9DC7-E75E9B0AD19C@oracle.com>
Message-ID: <fbd58d9b-0960-66f2-7ced-5180d88b67ab@oracle.com>

A few more cases found with scripted assistance from Mikael; updated webrev:

 ???? http://cr.openjdk.java.net/~darcy/8249687.1

Patches for new files below.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/lang/StackTraceElement.java 
2020-07-17 15:54:09.036893982 -0700
+++ new/src/java.base/share/classes/java/lang/StackTraceElement.java 
2020-07-17 15:54:08.316893982 -0700
@@ -153,8 +153,8 @@
 ????? * Returns the name of the source file containing the execution point
 ????? * represented by this stack trace element.? Generally, this 
corresponds
 ????? * to the {@code SourceFile} attribute of the relevant {@code class}
-???? * file (as per <i>The Java Virtual Machine Specification</i>, Section
-???? * 4.7.7).? In some systems, the name may refer to some source code 
unit
+???? * file (as per <cite>The Java Virtual Machine 
Specification</cite>, Section
+???? * {@jvms 4.7.7}).? In some systems, the name may refer to some 
source code unit
 ????? * other than a file, such as an entry in source repository.
 ????? *
 ????? * @return the name of the file containing the execution point
@@ -169,8 +169,8 @@
 ????? * Returns the line number of the source line containing the execution
 ????? * point represented by this stack trace element.? Generally, this is
 ????? * derived from the {@code LineNumberTable} attribute of the relevant
-???? * {@code class} file (as per <i>The Java Virtual Machine
-???? * Specification</i>, Section 4.7.8).
+???? * {@code class} file (as per <cite>The Java Virtual Machine
+???? * Specification</cite>, Section {@jvms 4.7.8}).
 ????? *
 ????? * @return the line number of the source line containing the execution
 ????? *???????? point represented by this stack trace element, or a 
negative
@@ -242,8 +242,8 @@
 ????? * represented by this stack trace element.? If the execution point is
 ????? * contained in an instance or class initializer, this method will 
return
 ????? * the appropriate <i>special method name</i>, {@code <init>} or
-???? * {@code <clinit>}, as per Section 3.9 of <i>The Java Virtual
-???? * Machine Specification</i>.
+???? * {@code <clinit>}, as per Section {@jvms 3.9} of <cite>The Java 
Virtual
+???? * Machine Specification</cite>.
 ????? *
 ????? * @return the name of the method containing the execution point
 ????? *???????? represented by this stack trace element.


--- old/src/java.base/share/classes/java/lang/String.java 2020-07-17 
15:54:10.200893982 -0700
+++ new/src/java.base/share/classes/java/lang/String.java 2020-07-17 
15:54:09.576893982 -0700
@@ -3533,12 +3533,11 @@
 ????? * if and only if {@code s.equals(t)} is {@code true}.
 ????? * <p>
 ????? * All literal strings and string-valued constant expressions are
-???? * interned. String literals are defined in section 3.10.5 of the
+???? * interned. String literals are defined in section {@jls 3.10.5} 
of the
 ????? * <cite>The Java Language Specification</cite>.
 ????? *
 ????? * @return? a string that has the same contents as this string, but is
 ????? *????????? guaranteed to be from a pool of unique strings.
-???? * @jls 3.10.5 String Literals
 ????? */
 ???? public native String intern();

--- old/src/java.base/share/classes/java/lang/ref/Reference.java 
2020-07-17 15:54:11.504893982 -0700
+++ new/src/java.base/share/classes/java/lang/ref/Reference.java 
2020-07-17 15:54:10.792893982 -0700
@@ -418,7 +418,7 @@
 ????? * {@code synchronized} blocks or methods, or using other 
synchronization
 ????? * facilities are not possible or do not provide the desired 
control.? This
 ????? * method is applicable only when reclamation may have visible 
effects,
-???? * which is possible for objects with finalizers (See Section 12.6
+???? * which is possible for objects with finalizers (See Section {@jls 
12.6}
 ????? * of <cite>The Java Language Specification</cite>) that
 ????? * are implemented in ways that rely on ordering control for
 ????? * correctness.

--- old/src/java.base/share/classes/java/lang/reflect/Constructor.java 
2020-07-17 15:54:12.664893982 -0700
+++ new/src/java.base/share/classes/java/lang/reflect/Constructor.java 
2020-07-17 15:54:12.064893982 -0700
@@ -436,7 +436,7 @@
 ????? *
 ????? * <p>If the constructor's declaring class is an inner class in a
 ????? * non-static context, the first argument to the constructor needs
-???? * to be the enclosing instance; see section 15.9.3 of
+???? * to be the enclosing instance; see section {@jls 15.9.3} of
 ????? * <cite>The Java Language Specification</cite>.
 ????? *
 ????? * <p>If the required access and argument checks succeed and the

--- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 
2020-07-17 15:54:13.864893982 -0700
+++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 
2020-07-17 15:54:13.192893982 -0700
@@ -32,7 +32,7 @@
 ? * constants to decode class and member access modifiers.? The sets of
 ? * modifiers are represented as integers with distinct bit positions
 ? * representing different modifiers.? The values for the constants
- * representing the modifiers are taken from the tables in sections 
4.1, 4.4, 4.5, and 4.7 of
+ * representing the modifiers are taken from the tables in sections 
{@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and {@jvms 4.7} of
 ? * <cite>The Java Virtual Machine Specification</cite>.
 ? *
 ? * @see Class#getModifiers()

--- 
old/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java 
2020-07-17 15:54:15.108893982 -0700
+++ 
new/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java 
2020-07-17 15:54:14.428893982 -0700
@@ -392,7 +392,7 @@
 ???? /**
 ????? * Return the number of abstract "words", or consecutive local 
variable
 ????? * indexes, required to contain a value of the given type. See JVMS
-???? * section 3.6.1.
+???? * section {@jvms 3.6.1}.
 ????? * <p>
 ????? * Note that the original version of the JVMS contained a 
definition of
 ????? * this abstract notion of a "word" in section 3.4, but that 
definition

--- old/src/java.base/share/classes/java/util/Properties.java 2020-07-17 
15:54:16.376893982 -0700
+++ new/src/java.base/share/classes/java/util/Properties.java 2020-07-17 
15:54:15.776893982 -0700
@@ -94,7 +94,7 @@
 ? * methods work the same way as the load(Reader)/store(Writer, String) 
pair, except
 ? * the input/output stream is encoded in ISO 8859-1 character encoding.
 ? * Characters that cannot be directly represented in this encoding can 
be written using
- * Unicode escapes as defined in section 3.3 of
+ * Unicode escapes as defined in section {@jls 3.3} of
 ? * <cite>The Java Language Specification</cite>;
 ? * only a single 'u' character is allowed in an escape
 ? * sequence.
@@ -336,7 +336,7 @@
 ????? * <a id="unicodeescapes"></a>
 ????? * Characters in keys and elements can be represented in escape
 ????? * sequences similar to those used for character and string literals
-???? * (see sections 3.3 and 3.10.6 of
+???? * (see sections {@jls 3.3} and {@jls 3.10.6} of
 ????? * <cite>The Java Language Specification</cite>).
 ????? *
 ????? * The differences from the character escape sequences and Unicode
@@ -390,7 +390,7 @@
 ????? * the ISO 8859-1 character encoding; that is each byte is one Latin1
 ????? * character. Characters not in Latin1, and certain special 
characters,
 ????? * are represented in keys and elements using Unicode escapes as 
defined in
-???? * section 3.3 of
+???? * section {@jls 3.3} of
 ????? * <cite>The Java Language Specification</cite>.
 ????? * <p>
 ????? * The specified stream remains open after this method returns.

On 7/17/2020 3:30 PM, Brian Burkhalter wrote:
> Hi Joe,
>
> +1
>
> Brian
>
>> On Jul 17, 2020, at 3:03 PM, Joe Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Following-up on? JDK-8237805 and some recent observations from Mikael 
>> V., there are more locations in the base module where in-line @jls 
>> and @jvms tags are appropriate to use. Please review their addition:
>>
>> http://cr.openjdk.java.net/~darcy/8249687.0/
>>
>> I checked that the sections were correct for the current JLS and 
>> JVMS, which led to a change of referenced section in AssertionError.
>

From alexey.semenyuk at oracle.com  Fri Jul 17 23:26:49 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 17 Jul 2020 19:26:49 -0400
Subject: RFR: 8245311: [macos] misc package tests failed due to "execution
 error: Finder got an error: AppleEvent timed out."
In-Reply-To: <6cfe91cc-b74c-3c1e-184a-8e30d8740b48@oracle.com>
References: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>
 <6cfe91cc-b74c-3c1e-184a-8e30d8740b48@oracle.com>
Message-ID: <6e17d63b-e839-19cf-1ac4-bb175831768e@oracle.com>

Alexander,

The change in RetryExecutor.java results in Executor instance created 
only once and not every time command line should be executed.

I'd suggest to have
---
void execute(String cmdline[]) throws IOException {
 ??? executeLoop(() -> Executor.of(cmdline));
}

private void executeLoop(Supplier<Executor> execSupplier) throws 
IOException {
 ???? ...
 ???? Executor exec = execSupplier.get();
}
---

instead.

- Alexey

On 7/17/2020 1:03 PM, Andy Herrick wrote:
> Looks OK - I approve.
>
> /Andy
>
> On 7/15/2020 7:29 PM, alexander.matveev at oracle.com wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> - "hdiutil detach" resource busy error is fixed in same way as 
>> JDK-8242786 by repeating detach several times.
>> - pkgbuild timeout will be covered with JDK-8249395.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8245311
>> [2] http://cr.openjdk.java.net/~almatvee/8245311/webrev.00/
>>
>> Thanks,
>> Alexander


From naoto.sato at oracle.com  Fri Jul 17 23:36:00 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 17 Jul 2020 16:36:00 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
Message-ID: <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>

Hi,

Based on the suggestions, I modified the fix as follows:

https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/

Changes from the initial revision are:

- Shared the implementation between compareToCI() and regionMatchesCI()
- Enabled immediate short cut if two code points match.
- Created a simple JMH benchmark. Here is the scores before and after 
the change:

before:
Benchmark                                Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.lower          avgt   25  53.764 ? 2.811  ns/op
StringCompareToIgnoreCase.supLower       avgt   25  24.211 ? 1.135  ns/op
StringCompareToIgnoreCase.supUpperLower  avgt   25  30.595 ? 1.344  ns/op
StringCompareToIgnoreCase.upperLower     avgt   25  18.859 ? 1.499  ns/op

after:
Benchmark                                Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.lower          avgt   25  58.354 ? 4.603  ns/op
StringCompareToIgnoreCase.supLower       avgt   25  57.975 ? 5.672  ns/op
StringCompareToIgnoreCase.supUpperLower  avgt   25  23.912 ? 0.965  ns/op
StringCompareToIgnoreCase.upperLower     avgt   25  17.744 ? 0.272  ns/op

Here, "sup" means all supplementary characters, BMP otherwise. "lower" 
means each character requires upper->lower casemap. "upperLower" means 
all characters are the same, except the last character which requires 
casemap.

I think the result is reasonable, considering surrogates check are now 
mandatory. I have tried Roger's suggestion to use Arrays.mismatch() but 
it did not seem to benefit here. In fact, the performance degraded 
partly because I implemented the short cut, and possibly for the 
overhead of extra checks.

Naoto

On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
> Hello,
> 
> Please review the fix to the following issues:
> 
> https://bugs.openjdk.java.net/browse/JDK-8248655
> https://bugs.openjdk.java.net/browse/JDK-8248434
> 
> The proposed changeset and its CSR are located at:
> 
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8248664
> 
> A bug was filed against SimpleDateFormat (8248434) where 
> case-insensitive date format/parse failed in some of the new locales in 
> JDK15. The root cause was that case-insensitive String.regionMatches() 
> method did not work with supplementary characters. The problem is that 
> the method's spec does not expect case mappings of supplementary 
> characters, possibly because it was overlooked in the first place, JSR 
> 204 - "Unicode Supplementary Character support". Similar behavior is 
> observed in other two case-insensitive methods, i.e., 
> compareToIgnoreCase() and equalsIgnoreCase().
> 
> The fix is straightforward to compare strings by code point basis, 
> instead of code unit (16bit "char") basis. Technically this change will 
> introduce a backward incompatibility, but I believe it is an 
> incompatibility to wrong behavior, not true to the meaning of those 
> methods' expectations.
> 
> Naoto

From mandy.chung at oracle.com  Fri Jul 17 23:56:08 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 17 Jul 2020 16:56:08 -0700
Subject: JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more
 places in java.base
In-Reply-To: <fbd58d9b-0960-66f2-7ced-5180d88b67ab@oracle.com>
References: <3cbb3c7b-49e8-2b56-71a9-49955e3d102a@oracle.com>
 <41846EB8-BFBB-4E5A-9DC7-E75E9B0AD19C@oracle.com>
 <fbd58d9b-0960-66f2-7ced-5180d88b67ab@oracle.com>
Message-ID: <a7c19462-b74a-f634-57fc-d595dbef5376@oracle.com>

+1
Mandy

On 7/17/20 4:04 PM, Joe Darcy wrote:
> A few more cases found with scripted assistance from Mikael; updated 
> webrev:
>
> ???? http://cr.openjdk.java.net/~darcy/8249687.1
>
> Patches for new files below.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/lang/StackTraceElement.java 
> 2020-07-17 15:54:09.036893982 -0700
> +++ new/src/java.base/share/classes/java/lang/StackTraceElement.java 
> 2020-07-17 15:54:08.316893982 -0700
> @@ -153,8 +153,8 @@
> ????? * Returns the name of the source file containing the execution 
> point
> ????? * represented by this stack trace element.? Generally, this 
> corresponds
> ????? * to the {@code SourceFile} attribute of the relevant {@code class}
> -???? * file (as per <i>The Java Virtual Machine Specification</i>, 
> Section
> -???? * 4.7.7).? In some systems, the name may refer to some source 
> code unit
> +???? * file (as per <cite>The Java Virtual Machine 
> Specification</cite>, Section
> +???? * {@jvms 4.7.7}).? In some systems, the name may refer to some 
> source code unit
> ????? * other than a file, such as an entry in source repository.
> ????? *
> ????? * @return the name of the file containing the execution point
> @@ -169,8 +169,8 @@
> ????? * Returns the line number of the source line containing the 
> execution
> ????? * point represented by this stack trace element.? Generally, 
> this is
> ????? * derived from the {@code LineNumberTable} attribute of the 
> relevant
> -???? * {@code class} file (as per <i>The Java Virtual Machine
> -???? * Specification</i>, Section 4.7.8).
> +???? * {@code class} file (as per <cite>The Java Virtual Machine
> +???? * Specification</cite>, Section {@jvms 4.7.8}).
> ????? *
> ????? * @return the line number of the source line containing the 
> execution
> ????? *???????? point represented by this stack trace element, or a 
> negative
> @@ -242,8 +242,8 @@
> ????? * represented by this stack trace element.? If the execution 
> point is
> ????? * contained in an instance or class initializer, this method 
> will return
> ????? * the appropriate <i>special method name</i>, {@code <init>} or
> -???? * {@code <clinit>}, as per Section 3.9 of <i>The Java Virtual
> -???? * Machine Specification</i>.
> +???? * {@code <clinit>}, as per Section {@jvms 3.9} of <cite>The Java 
> Virtual
> +???? * Machine Specification</cite>.
> ????? *
> ????? * @return the name of the method containing the execution point
> ????? *???????? represented by this stack trace element.
>
>
> --- old/src/java.base/share/classes/java/lang/String.java 2020-07-17 
> 15:54:10.200893982 -0700
> +++ new/src/java.base/share/classes/java/lang/String.java 2020-07-17 
> 15:54:09.576893982 -0700
> @@ -3533,12 +3533,11 @@
> ????? * if and only if {@code s.equals(t)} is {@code true}.
> ????? * <p>
> ????? * All literal strings and string-valued constant expressions are
> -???? * interned. String literals are defined in section 3.10.5 of the
> +???? * interned. String literals are defined in section {@jls 3.10.5} 
> of the
> ????? * <cite>The Java Language Specification</cite>.
> ????? *
> ????? * @return? a string that has the same contents as this string, 
> but is
> ????? *????????? guaranteed to be from a pool of unique strings.
> -???? * @jls 3.10.5 String Literals
> ????? */
> ???? public native String intern();
>
> --- old/src/java.base/share/classes/java/lang/ref/Reference.java 
> 2020-07-17 15:54:11.504893982 -0700
> +++ new/src/java.base/share/classes/java/lang/ref/Reference.java 
> 2020-07-17 15:54:10.792893982 -0700
> @@ -418,7 +418,7 @@
> ????? * {@code synchronized} blocks or methods, or using other 
> synchronization
> ????? * facilities are not possible or do not provide the desired 
> control.? This
> ????? * method is applicable only when reclamation may have visible 
> effects,
> -???? * which is possible for objects with finalizers (See Section 12.6
> +???? * which is possible for objects with finalizers (See Section 
> {@jls 12.6}
> ????? * of <cite>The Java Language Specification</cite>) that
> ????? * are implemented in ways that rely on ordering control for
> ????? * correctness.
>
> --- old/src/java.base/share/classes/java/lang/reflect/Constructor.java 
> 2020-07-17 15:54:12.664893982 -0700
> +++ new/src/java.base/share/classes/java/lang/reflect/Constructor.java 
> 2020-07-17 15:54:12.064893982 -0700
> @@ -436,7 +436,7 @@
> ????? *
> ????? * <p>If the constructor's declaring class is an inner class in a
> ????? * non-static context, the first argument to the constructor needs
> -???? * to be the enclosing instance; see section 15.9.3 of
> +???? * to be the enclosing instance; see section {@jls 15.9.3} of
> ????? * <cite>The Java Language Specification</cite>.
> ????? *
> ????? * <p>If the required access and argument checks succeed and the
>
> --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 
> 2020-07-17 15:54:13.864893982 -0700
> +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 
> 2020-07-17 15:54:13.192893982 -0700
> @@ -32,7 +32,7 @@
> ? * constants to decode class and member access modifiers.? The sets of
> ? * modifiers are represented as integers with distinct bit positions
> ? * representing different modifiers.? The values for the constants
> - * representing the modifiers are taken from the tables in sections 
> 4.1, 4.4, 4.5, and 4.7 of
> + * representing the modifiers are taken from the tables in sections 
> {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and {@jvms 4.7} of
> ? * <cite>The Java Virtual Machine Specification</cite>.
> ? *
> ? * @see Class#getModifiers()
>
> --- 
> old/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java 
> 2020-07-17 15:54:15.108893982 -0700
> +++ 
> new/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java 
> 2020-07-17 15:54:14.428893982 -0700
> @@ -392,7 +392,7 @@
> ???? /**
> ????? * Return the number of abstract "words", or consecutive local 
> variable
> ????? * indexes, required to contain a value of the given type. See JVMS
> -???? * section 3.6.1.
> +???? * section {@jvms 3.6.1}.
> ????? * <p>
> ????? * Note that the original version of the JVMS contained a 
> definition of
> ????? * this abstract notion of a "word" in section 3.4, but that 
> definition
>
> --- old/src/java.base/share/classes/java/util/Properties.java 
> 2020-07-17 15:54:16.376893982 -0700
> +++ new/src/java.base/share/classes/java/util/Properties.java 
> 2020-07-17 15:54:15.776893982 -0700
> @@ -94,7 +94,7 @@
> ? * methods work the same way as the load(Reader)/store(Writer, 
> String) pair, except
> ? * the input/output stream is encoded in ISO 8859-1 character encoding.
> ? * Characters that cannot be directly represented in this encoding 
> can be written using
> - * Unicode escapes as defined in section 3.3 of
> + * Unicode escapes as defined in section {@jls 3.3} of
> ? * <cite>The Java Language Specification</cite>;
> ? * only a single 'u' character is allowed in an escape
> ? * sequence.
> @@ -336,7 +336,7 @@
> ????? * <a id="unicodeescapes"></a>
> ????? * Characters in keys and elements can be represented in escape
> ????? * sequences similar to those used for character and string literals
> -???? * (see sections 3.3 and 3.10.6 of
> +???? * (see sections {@jls 3.3} and {@jls 3.10.6} of
> ????? * <cite>The Java Language Specification</cite>).
> ????? *
> ????? * The differences from the character escape sequences and Unicode
> @@ -390,7 +390,7 @@
> ????? * the ISO 8859-1 character encoding; that is each byte is one 
> Latin1
> ????? * character. Characters not in Latin1, and certain special 
> characters,
> ????? * are represented in keys and elements using Unicode escapes as 
> defined in
> -???? * section 3.3 of
> +???? * section {@jls 3.3} of
> ????? * <cite>The Java Language Specification</cite>.
> ????? * <p>
> ????? * The specified stream remains open after this method returns.
>
> On 7/17/2020 3:30 PM, Brian Burkhalter wrote:
>> Hi Joe,
>>
>> +1
>>
>> Brian
>>
>>> On Jul 17, 2020, at 3:03 PM, Joe Darcy <joe.darcy at oracle.com 
>>> <mailto:joe.darcy at oracle.com>> wrote:
>>>
>>> Following-up on? JDK-8237805 and some recent observations from 
>>> Mikael V., there are more locations in the base module where in-line 
>>> @jls and @jvms tags are appropriate to use. Please review their 
>>> addition:
>>>
>>> http://cr.openjdk.java.net/~darcy/8249687.0/
>>>
>>> I checked that the sections were correct for the current JLS and 
>>> JVMS, which led to a change of referenced section in AssertionError.
>>


From brian.burkhalter at oracle.com  Sat Jul 18 00:56:04 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 17 Jul 2020 17:56:04 -0700
Subject: JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more
 places in java.base
In-Reply-To: <a7c19462-b74a-f634-57fc-d595dbef5376@oracle.com>
References: <3cbb3c7b-49e8-2b56-71a9-49955e3d102a@oracle.com>
 <41846EB8-BFBB-4E5A-9DC7-E75E9B0AD19C@oracle.com>
 <fbd58d9b-0960-66f2-7ced-5180d88b67ab@oracle.com>
 <a7c19462-b74a-f634-57fc-d595dbef5376@oracle.com>
Message-ID: <80A98567-6AF1-4970-B892-9A366D8C1B3E@oracle.com>

+1

Brian

> On Jul 17, 2020, at 4:56 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> +1
> Mandy
> 
> On 7/17/20 4:04 PM, Joe Darcy wrote:
>> A few more cases found with scripted assistance from Mikael; updated webrev: 
>> 
>>      http://cr.openjdk.java.net/~darcy/8249687.1 <http://cr.openjdk.java.net/~darcy/8249687.1> 
>> 
>> Patches for new files below. 


From alexander.matveev at oracle.com  Sat Jul 18 02:35:45 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Fri, 17 Jul 2020 19:35:45 -0700
Subject: RFR: 8245311: [macos] misc package tests failed due to "execution
 error: Finder got an error: AppleEvent timed out."
In-Reply-To: <6e17d63b-e839-19cf-1ac4-bb175831768e@oracle.com>
References: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>
 <6cfe91cc-b74c-3c1e-184a-8e30d8740b48@oracle.com>
 <6e17d63b-e839-19cf-1ac4-bb175831768e@oracle.com>
Message-ID: <0e84d08e-fe9c-57fc-8178-dd96dcbb1c69@oracle.com>

Hi Alexey,

Fixed as per your suggestion:
http://cr.openjdk.java.net/~almatvee/8245311/webrev.01/

Thanks,
Alexander

On 7/17/20 4:26 PM, Alexey Semenyuk wrote:
> Alexander,
>
> The change in RetryExecutor.java results in Executor instance created 
> only once and not every time command line should be executed.
>
> I'd suggest to have
> ---
> void execute(String cmdline[]) throws IOException {
> ??? executeLoop(() -> Executor.of(cmdline));
> }
>
> private void executeLoop(Supplier<Executor> execSupplier) throws 
> IOException {
> ???? ...
> ???? Executor exec = execSupplier.get();
> }
> ---
>
> instead.
>
> - Alexey
>
> On 7/17/2020 1:03 PM, Andy Herrick wrote:
>> Looks OK - I approve.
>>
>> /Andy
>>
>> On 7/15/2020 7:29 PM, alexander.matveev at oracle.com wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> - "hdiutil detach" resource busy error is fixed in same way as 
>>> JDK-8242786 by repeating detach several times.
>>> - pkgbuild timeout will be covered with JDK-8249395.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8245311
>>> [2] http://cr.openjdk.java.net/~almatvee/8245311/webrev.00/
>>>
>>> Thanks,
>>> Alexander
>


From igor.ignatyev at oracle.com  Sat Jul 18 03:54:12 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 17 Jul 2020 20:54:12 -0700
Subject: [15] RFR(T) :  8249697 : java/lang/invoke/RicochetTest.java should
 use @requires instead of @ignore
Message-ID: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
> 7 lines changed: 4 ins; 0 del; 3 mod;


Hi all,

could you please review this small and trivial patch for java/lang/invoke/RicochetTest.java test?
from JBS:
> a run of java/lang/invoke/RicochetTest.java w/ MAX_ARITY=255 was removed from all configurations by JDK-7049122, yet the problem manifests itself only w/ Xcomp. as now we have @requires to filter out tests from certain configurations, the test can be updated to run MAX_ARITY=255 in all configs but Xcomp.

the patch splits the test into two subtests, each one w/ one @run, and use @requires to exclude one w/ MAX_ARITY=255 from execution if Xcomp flag is used.

JBS: https://bugs.openjdk.java.net/browse/JDK-8249697
webrev: http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
testing: java/lang/invoke/RicochetTest.java on {linux,windows,macos}-x64 w/ and w/o -Xcomp; Xcomp runs, as expected, had only 1 test run

Thanks,
-- Igor

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

From igor.ignatyev at oracle.com  Sat Jul 18 03:57:43 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 17 Jul 2020 20:57:43 -0700
Subject: [15] RFR(T) : 8249698 :
 java/lang/invoke/LFCaching/LFGarbageCollectedTest.java should be
 ProblemList-ed and not @ignored
Message-ID: <61EBB792-FAF4-4DFD-A674-4BE7153F20AA@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00
> 3 lines changed: 1 ins; 1 del; 1 mod;


Hi all,

could you please review this trivial patch which removes @ignore from LFGarbageCollectedTest and adds it into problem-list instead?

from  8249698:
> java/lang/invoke/LFCaching/LFGarbageCollectedTest.java is excluded from execution due to JDK-8078602. although the test might indeed fail due to JDK-8078602, it still can be useful and isn't harmful to run, therefore this test should be put in ProblemList.txt and @ignore is to be removed.
from main issue(8249618):
> although ProblemList and @ignore achieve the same end result (test exclusion), their server different goals and have slightly different meanings, simplified @ignore should be used to exclude useless or harmful tests, and ProblemList in all other cases (see yet-not-integrated `ProblemListing or `@ignore`-ing a Test` section of dev guide, PR -- https://github.com/openjdk/guide/pull/21 for more details). 
> 
> due to different reasons, this hasn't been always followed and some currently @ignore-d tests should rather be ProblemList-ed, and some of ProblemList-ed should be @ignore-d, this issue is to clean up the current state in a hope that this will reduce further confusion. 


webrev: http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00
JBS: https://bugs.openjdk.java.net/browse/JDK-8249698

Thanks,
-- Igor

8078602: https://bugs.openjdk.java.net/browse/JDK-8078602
8249618: https://bugs.openjdk.java.net/browse/JDK-8249618

From igor.ignatyev at oracle.com  Sun Jul 19 04:28:58 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sat, 18 Jul 2020 21:28:58 -0700
Subject: [15] RFR(S) : 8249700 : java/io/File/GetXSpace.java should be added
 to exclude list, and not @ignore-d
Message-ID: <F1EBBFAD-9410-4A67-AD40-C138B884E2D4@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8249700/webrev.01/
> 9 lines changed: 1 ins; 1 del; 7 mod

Hi all,

could you please review this small patch which removes @ignore from java/io/File/GetXSpace.java and instead adds an entry to ProblemList.txt?

from JBS:
> java/io/File/GetXSpace.java is currently @ignore due to JDK-6492634 and JDK-6501010, as running this test isn't harmful and can still be useful to find other bugs, the test should be added to ProblemList.txt and @ignore tag should be removed.
> given JDK-6492634 is solaris-specific, and solaris port has been removed from jdk15, the test will be problem-listed only due to JDK-6501010 and only on windows.
from main issue(8249618):
> although ProblemList and @ignore achieve the same end result (test exclusion), their server different goals and have slightly different meanings, simplified @ignore should be used to exclude useless or harmful tests, and ProblemList in all other cases (see yet-not-integrated `ProblemListing or `@ignore`-ing a Test` section of dev guide, PR -- https://github.com/openjdk/guide/pull/21 for more details). 
> 
> due to different reasons, this hasn't been always followed and some currently @ignore-d tests should rather be ProblemList-ed, and some of ProblemList-ed should be @ignore-d, this issue is to clean up the current state in a hope that this will reduce further confusion. 

the patch also includes minimal changes to make the test runnable on macosx, which reveled that the test might fail on macos. 8249703 has been filed for that issue and the appropriate changes are done in ProblemList.txt.

webrev: http://cr.openjdk.java.net/~iignatyev//8249700/webrev.01/
JBS: https://bugs.openjdk.java.net/browse/JDK-8249700
testing:  java/io/File/GetXSpace.java on linux-x64 100 times, 100% passed; macos-x64 100 times, 71% passed

PS the test is still failing on windows albeit due to the reason other than in 6501010; it seems that the test should be just updated to recognize cygwin's `df` output. I'm currently working on the fix and will send it out for review shortly. 

Thanks,
-- Igor

JDK-6492634: https://bugs.openjdk.java.net/browse/JDK-8249700
JDK-6501010: https://bugs.openjdk.java.net/browse/JDK-6501010
JDK-6492634: https://bugs.openjdk.java.net/browse/JDK-6492634
JDK-8249703: https://bugs.openjdk.java.net/browse/JDK-8249703

From mandy.chung at oracle.com  Sun Jul 19 04:32:32 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 18 Jul 2020 21:32:32 -0700
Subject: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should
 use @requires instead of @ignore
In-Reply-To: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>
References: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>
Message-ID: <60806519-8e57-d126-8a2e-800053b4ee9a@oracle.com>



On 7/17/20 8:54 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
>

I suggest to change this:
 ? 32? * @comment The following test creates an unreasonable number of 
adapters in -Xcomp mode (7049122)

To:

 ?? @bug 8249697
 ?? @summary verify very high number of adapters in -Xcomp mode

Otherwise, looks fine.

Mandy
> Hi all,
>
> could you please review this small and trivial patch for java/lang/invoke/RicochetTest.java test?
> from JBS:
>> a run of java/lang/invoke/RicochetTest.java w/ MAX_ARITY=255 was removed from all configurations by JDK-7049122, yet the problem manifests itself only w/ Xcomp. as now we have @requires to filter out tests from certain configurations, the test can be updated to run MAX_ARITY=255 in all configs but Xcomp.
> the patch splits the test into two subtests, each one w/ one @run, and use @requires to exclude one w/ MAX_ARITY=255 from execution if Xcomp flag is used.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249697
> webrev: http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
> testing: java/lang/invoke/RicochetTest.java on {linux,windows,macos}-x64 w/ and w/o -Xcomp; Xcomp runs, as expected, had only 1 test run
>
> Thanks,
> -- Igor
>
> JDK-7049122 : https://bugs.openjdk.java.net/browse/JDK-7049122


From mandy.chung at oracle.com  Sun Jul 19 04:33:21 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 18 Jul 2020 21:33:21 -0700
Subject: [15] RFR(T) : 8249698 :
 java/lang/invoke/LFCaching/LFGarbageCollectedTest.java should be
 ProblemList-ed and not @ignored
In-Reply-To: <61EBB792-FAF4-4DFD-A674-4BE7153F20AA@oracle.com>
References: <61EBB792-FAF4-4DFD-A674-4BE7153F20AA@oracle.com>
Message-ID: <ee1085d5-af99-09f9-02ca-0fa7a79c3f33@oracle.com>

+1

Mandy

On 7/17/20 8:57 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00
>> 3 lines changed: 1 ins; 1 del; 1 mod;
>
> Hi all,
>
> could you please review this trivial patch which removes @ignore from LFGarbageCollectedTest and adds it into problem-list instead?
>
> from  8249698:
>> java/lang/invoke/LFCaching/LFGarbageCollectedTest.java is excluded from execution due to JDK-8078602. although the test might indeed fail due to JDK-8078602, it still can be useful and isn't harmful to run, therefore this test should be put in ProblemList.txt and @ignore is to be removed.
> from main issue(8249618):
>> although ProblemList and @ignore achieve the same end result (test exclusion), their server different goals and have slightly different meanings, simplified @ignore should be used to exclude useless or harmful tests, and ProblemList in all other cases (see yet-not-integrated `ProblemListing or `@ignore`-ing a Test` section of dev guide, PR -- https://github.com/openjdk/guide/pull/21 for more details).
>>
>> due to different reasons, this hasn't been always followed and some currently @ignore-d tests should rather be ProblemList-ed, and some of ProblemList-ed should be @ignore-d, this issue is to clean up the current state in a hope that this will reduce further confusion.
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249698
>
> Thanks,
> -- Igor
>
> 8078602: https://bugs.openjdk.java.net/browse/JDK-8078602
> 8249618: https://bugs.openjdk.java.net/browse/JDK-8249618


From liyu.italy at gmail.com  Sun Jul 19 10:48:48 2020
From: liyu.italy at gmail.com (Lisa Li)
Date: Sun, 19 Jul 2020 18:48:48 +0800
Subject: [PATCH] 8245694 : java.util.Properties.entrySet() does not
 override java.lang.Object methods
In-Reply-To: <CAFZshwoYZZ47bMKrPmupovFhFdPs+rpN_rBEhZi=C6o7g5T8Bw@mail.gmail.com>
References: <CAFZshwqsMObUVhPSP8kOWkQSp_T+DRAbWx_ab_Jayw2EJA9TmA@mail.gmail.com>
 <9487a1c9-d0bc-3632-156d-5927e5801dc8@icemanx.nl>
 <20109712-d505-1b17-3e6b-ae388d554400@oracle.com>
 <767a4dae-55f0-ca11-dbdf-57c7a22205d3@oracle.com>
 <CAFZshwq89R66TtPLN2niLa2YcFs6DBGRhqW4iDKq2N1XGJTr0g@mail.gmail.com>
 <CAFZshwra0r_zBVdPOyAT2u5yQCcOAVo49f+MayEx3reu9s+iQw@mail.gmail.com>
 <7b01289c-d7c9-47ab-f9f6-e2cf3a00f2da@oracle.com>
 <37bea22e-115f-5187-0f21-e04536691efc@oracle.com>
 <CAFZshwr3yXQ2sTOckmdDheMMnE4pkBCccv_7boPqeJtPAt3ypw@mail.gmail.com>
 <CAFZshwr-efvZDosDQfvfLvuCVRKi+GYPShCJnZ+F=9UJKj9ihw@mail.gmail.com>
 <de327d49-b5cb-92ed-7425-5fa6c2ac8e20@oracle.com>
 <CAFZshwomQyV3JJ9J8_KEMOoQQh5UF0dkw-DU1DB9H0DbvrUmJg@mail.gmail.com>
 <140eb4ab-ff9b-eb20-2d37-e6bb5f9506b4@oracle.com>
 <CAFZshwoYZZ47bMKrPmupovFhFdPs+rpN_rBEhZi=C6o7g5T8Bw@mail.gmail.com>
Message-ID: <CAFZshwoCuxG31jWifWyx=yVO9TbdFefPK_wwkEvZbQM1E1jV+w@mail.gmail.com>

Hi Julia?

Apologies for the delay. Please review the updated fix for JDK-8245694
<https://bugs.openjdk.java.net/browse/JDK-8245694>.  Also, my name is on
the contributor list as: Yu Li - OpenJDK - yuli.


*BUG DESCRIPTION*:

JDK-8245694 <https://bugs.openjdk.java.net/browse/JDK-8245694> :
java.util.Properties.entrySet()
does not override java.lang.Object methods since java 9.


*PATCH*:

# HG changeset patch
# User yuli
# Date 1595152648 -28800
#      Sun Jul 19 17:57:28 2020 +0800
# Node ID 4f359fdb3df3407cf8b31cb9ad153a99c52165c8
# Parent  72bf0aca309e326f35cdc85cbdeb3076e4d4e74d
8245694: java.util.Properties.entrySet() does not override Object methods
Summary: Add missing override methods
Contributed-by: Yu Li <liyu.italy at gmail.com>

diff -r 72bf0aca309e -r 4f359fdb3df3
src/java.base/share/classes/java/util/Properties.java
--- a/src/java.base/share/classes/java/util/Properties.java Fri Jul 17
17:27:31 2020 -0700
+++ b/src/java.base/share/classes/java/util/Properties.java Sun Jul 19
17:57:28 2020 +0800
@@ -1405,6 +1405,21 @@
         }

         @Override
+        public boolean equals(Object o) {
+            return o == this || entrySet.equals(o);
+        }
+
+        @Override
+        public int hashCode() {
+            return entrySet.hashCode();
+        }
+
+        @Override
+        public String toString() {
+            return entrySet.toString();
+        }
+
+        @Override
         public boolean removeAll(Collection<?> c) {
             return entrySet.removeAll(c);
         }
diff -r 72bf0aca309e -r 4f359fdb3df3
test/jdk/java/util/Properties/PropertiesEntrySetTest.java
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java Sun Jul 19
17:57:28 2020 +0800
@@ -0,0 +1,201 @@
+/*
+ * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+/*
+ * @test
+ * @bug        8245694
+ * @summary    tests the entrySet() method of Properties class
+ * @author     Yu Li
+ * @run testng PropertiesEntrySetTest
+ */
+
+import org.testng.annotations.Test;
+
+import java.util.Properties;
+
+import static org.testng.Assert.assertEquals;
+import static org.testng.Assert.assertFalse;
+import static org.testng.Assert.assertThrows;
+import static org.testng.Assert.assertTrue;
+
+public class PropertiesEntrySetTest {
+
+    @Test
+    public void testEquals() {
+        Properties a = new Properties();
+        var aEntrySet = a.entrySet();
+        assertFalse(aEntrySet.equals(null));
+        assertTrue(aEntrySet.equals(aEntrySet));
+
+        Properties b = new Properties();
+        var bEntrySet = b.entrySet();
+        assertTrue(bEntrySet.equals(aEntrySet));
+        assertTrue(bEntrySet.hashCode() == aEntrySet.hashCode());
+
+        a.setProperty("p1", "1");
+        assertFalse(bEntrySet.equals(aEntrySet));
+        assertFalse(bEntrySet.hashCode() == aEntrySet.hashCode());
+
+        b.setProperty("p1", "1");
+        assertTrue(aEntrySet.equals(bEntrySet));
+        assertTrue(bEntrySet.hashCode() == aEntrySet.hashCode());
+
+        Properties c = new Properties();
+        c.setProperty("p1", "2");
+        var cEntrySet = c.entrySet();
+        assertFalse(cEntrySet.equals(bEntrySet));
+        assertFalse(bEntrySet.hashCode() == cEntrySet.hashCode());
+        assertFalse(cEntrySet.equals(aEntrySet));
+        assertFalse(aEntrySet.hashCode() == cEntrySet.hashCode());
+
+        a.setProperty("p2", "2");
+        Properties d = new Properties();
+        d.setProperty("p2", "2");
+        d.setProperty("p1", "1");
+        var dEntrySet = d.entrySet();
+        assertTrue(dEntrySet.equals(aEntrySet));
+        assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
+
+        a.remove("p1");
+        assertFalse(aEntrySet.equals(dEntrySet));
+        assertFalse(aEntrySet.hashCode() == dEntrySet.hashCode());
+
+        d.remove("p1", "1");
+        assertTrue(dEntrySet.equals(aEntrySet));
+        assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
+
+        a.clear();
+        assertFalse(aEntrySet.equals(dEntrySet));
+        assertFalse(aEntrySet.hashCode() == dEntrySet.hashCode());
+        assertTrue(aEntrySet.isEmpty());
+
+        d.clear();
+        assertTrue(dEntrySet.equals(aEntrySet));
+        assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
+        assertTrue(dEntrySet.isEmpty());
+    }
+
+    @Test
+    public void testToString() {
+        Properties a = new Properties();
+        var aEntrySet = a.entrySet();
+        assertEquals(aEntrySet.toString(), "[]");
+
+        a.setProperty("p1", "1");
+        assertEquals(aEntrySet.toString(), "[p1=1]");
+
+        a.setProperty("p2", "2");
+        assertEquals(aEntrySet.size(), 2);
+        assertTrue(aEntrySet.toString().trim().startsWith("["));
+        assertTrue(aEntrySet.toString().contains("p1=1"));
+        assertTrue(aEntrySet.toString().contains("p2=2"));
+        assertTrue(aEntrySet.toString().trim().endsWith("]"));
+
+        Properties b = new Properties();
+        b.setProperty("p2", "2");
+        b.setProperty("p1", "1");
+        var bEntrySet = b.entrySet();
+        assertEquals(bEntrySet.size(), 2);
+        assertTrue(bEntrySet.toString().trim().startsWith("["));
+        assertTrue(bEntrySet.toString().contains("p1=1"));
+        assertTrue(bEntrySet.toString().contains("p2=2"));
+        assertTrue(bEntrySet.toString().trim().endsWith("]"));
+
+        b.setProperty("p0", "0");
+        assertEquals(bEntrySet.size(), 3);
+        assertTrue(bEntrySet.toString().contains("p0=0"));
+
+        b.remove("p1");
+        assertEquals(bEntrySet.size(), 2);
+        assertFalse(bEntrySet.toString().contains("p1=1"));
+        assertTrue(bEntrySet.toString().trim().startsWith("["));
+        assertTrue(bEntrySet.toString().contains("p0=0"));
+        assertTrue(bEntrySet.toString().contains("p2=2"));
+        assertTrue(bEntrySet.toString().trim().endsWith("]"));
+
+        b.remove("p0", "0");
+        assertEquals(bEntrySet.size(), 1);
+        assertFalse(bEntrySet.toString().contains("p0=0"));
+        assertTrue(bEntrySet.toString().trim().startsWith("["));
+        assertTrue(bEntrySet.toString().contains("p2=2"));
+        assertTrue(bEntrySet.toString().trim().endsWith("]"));
+
+        b.clear();
+        assertTrue(bEntrySet.isEmpty());
+        assertTrue(bEntrySet.toString().equals("[]"));
+    }
+
+    @Test
+    public void testEntrySetWithoutException() {
+        Properties a = new Properties();
+        a.setProperty("p1", "1");
+        a.setProperty("p2", "2");
+        var aEntrySet = a.entrySet();
+        assertEquals(aEntrySet.size(), 2);
+
+        var i = aEntrySet.iterator();
+        var e1 = i.next();
+        i.remove();
+        assertFalse(aEntrySet.contains(e1));
+        assertEquals(aEntrySet.size(), 1);
+
+        var e2 = i.next();
+        aEntrySet.remove(e2);
+        assertFalse(aEntrySet.contains(e2));
+        assertTrue(aEntrySet.isEmpty());
+
+        a.setProperty("p1", "1");
+        a.setProperty("p3", "3");
+        Properties b = new Properties();
+        b.setProperty("p2", "2");
+        b.setProperty("p1", "1");
+        var bEntrySet = b.entrySet();
+
+        assertFalse(bEntrySet.containsAll(aEntrySet));
+        assertEquals(bEntrySet.size(), 2);
+
+        assertTrue(bEntrySet.removeAll(aEntrySet));
+        assertEquals(bEntrySet.size(), 1);
+
+        assertTrue(bEntrySet.retainAll(aEntrySet));
+        assertTrue(bEntrySet.isEmpty());
+        assertEquals(aEntrySet.size(), 2);
+
+        aEntrySet.clear();
+        assertTrue(aEntrySet.isEmpty());
+    }
+
+    @Test
+    public void testEntrySetExceptionWhenAdd() {
+        Properties a = new Properties();
+        a.setProperty("p1", "1");
+        var aEntrySet = a.entrySet();
+
+        Properties b = new Properties();
+        b.setProperty("p2", "2");
+        var bEntrySet = b.entrySet();
+
+        assertThrows(UnsupportedOperationException.class, () ->
aEntrySet.addAll(bEntrySet));
+        assertThrows(UnsupportedOperationException.class, () ->
aEntrySet.add(bEntrySet.iterator().next()));
+    }
+}
\ No newline at end of file

Best regards,
Yu L.


On Tue, Jun 23, 2020 at 12:32 AM Lisa Li <liyu.italy at gmail.com> wrote:

> Great, thanks Julia!
>
> Best regards,
>  Yu L.
>
> On Mon, Jun 22, 2020 at 9:56 PM Julia Boes <julia.boes at oracle.com> wrote:
>
>> Hi Yu,
>>
>> Just to confirm, for
>> src/java.base/share/classes/java/util/Properties.java the copyright should
>> be updated as :
>>
>> + * Copyright (c) 1995, 2020, Oracle and/or its affiliates. All rights
>>
>> Because 1995 was the year when the file was added, while 2020 when this
>> change is made. Correct me if I'm wrong.
>>
>> That's right!
>>
>> Cheers,
>>
>> Julia
>>
>>
>>

From Alan.Bateman at oracle.com  Sun Jul 19 15:18:21 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 19 Jul 2020 16:18:21 +0100
Subject: [15] RFR(S) : 8249700 : java/io/File/GetXSpace.java should be
 added to exclude list, and not @ignore-d
In-Reply-To: <F1EBBFAD-9410-4A67-AD40-C138B884E2D4@oracle.com>
References: <F1EBBFAD-9410-4A67-AD40-C138B884E2D4@oracle.com>
Message-ID: <6bb9995e-61e4-365a-997e-0b5f8fa7d55c@oracle.com>

On 19/07/2020 05:28, Igor Ignatyev wrote:
> :
> the patch also includes minimal changes to make the test runnable on macosx, which reveled that the test might fail on macos. 8249703 has been filed for that issue and the appropriate changes are done in ProblemList.txt.
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8249700/webrev.01/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249700
> testing:  java/io/File/GetXSpace.java on linux-x64 100 times, 100% passed; macos-x64 100 times, 71% passed
>
> PS the test is still failing on windows albeit due to the reason other than in 6501010; it seems that the test should be just updated to recognize cygwin's `df` output. I'm currently working on the fix and will send it out for review shortly.
>
This looks okay to me.

-Alan

From naoto.sato at oracle.com  Sun Jul 19 18:05:11 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Sun, 19 Jul 2020 11:05:11 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
Message-ID: <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>

Hi Mark,

Thank you for your comments.

On 7/17/20 8:03 PM, Mark Davis ? wrote:
> One option is to have a fast path that uses char functions, up to the 
> point where you hit a high surrogate, then drop into the slower 
> codepoint path. That saves time for the high-runner cases.
> 
> On the other hand, if the times are good enough, you might not need the 
> complication.

The implementation is dealing with bare byte arrays. Only methods that 
it uses from Character class are toLowerCase(int) and toUpperCase(int) 
(sans surrogate check, which is needed at each iteration anyways), and 
their "char" equivalents are merely casting (char) to the int result. So 
it might not be so beneficial to differentiate char and int paths.

Having said that, I found that there was an unnecessary surrogate check 
(always checks high *and* low surrogate on each iteration), so I revised 
the fix (added line 380-383 in StringUTF16.java):

http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/

Naoto

> 
> Mark
> //////
> 
> 
> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>> wrote:
> 
>     Hi,
> 
>     Based on the suggestions, I modified the fix as follows:
> 
>     https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
> 
>     Changes from the initial revision are:
> 
>     - Shared the implementation between compareToCI() and regionMatchesCI()
>     - Enabled immediate short cut if two code points match.
>     - Created a simple JMH benchmark. Here is the scores before and after
>     the change:
> 
>     before:
>     Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score? ?Error 
>     Units
>     StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 53.764 ? 2.811 
>     ns/op
>     StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 24.211 ? 1.135 
>     ns/op
>     StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 30.595 ? 1.344 
>     ns/op
>     StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 18.859 ? 1.499 
>     ns/op
> 
>     after:
>     Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score? ?Error 
>     Units
>     StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 58.354 ? 4.603 
>     ns/op
>     StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 57.975 ? 5.672 
>     ns/op
>     StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 23.912 ? 0.965 
>     ns/op
>     StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 17.744 ? 0.272 
>     ns/op
> 
>     Here, "sup" means all supplementary characters, BMP otherwise. "lower"
>     means each character requires upper->lower casemap. "upperLower" means
>     all characters are the same, except the last character which requires
>     casemap.
> 
>     I think the result is reasonable, considering surrogates check are now
>     mandatory. I have tried Roger's suggestion to use Arrays.mismatch() but
>     it did not seem to benefit here. In fact, the performance degraded
>     partly because I implemented the short cut, and possibly for the
>     overhead of extra checks.
> 
>     Naoto
> 
>     On 7/15/20 9:00 AM, naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com> wrote:
>      > Hello,
>      >
>      > Please review the fix to the following issues:
>      >
>      > https://bugs.openjdk.java.net/browse/JDK-8248655
>      > https://bugs.openjdk.java.net/browse/JDK-8248434
>      >
>      > The proposed changeset and its CSR are located at:
>      >
>      > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>      > https://bugs.openjdk.java.net/browse/JDK-8248664
>      >
>      > A bug was filed against SimpleDateFormat (8248434) where
>      > case-insensitive date format/parse failed in some of the new
>     locales in
>      > JDK15. The root cause was that case-insensitive
>     String.regionMatches()
>      > method did not work with supplementary characters. The problem is
>     that
>      > the method's spec does not expect case mappings of supplementary
>      > characters, possibly because it was overlooked in the first
>     place, JSR
>      > 204 - "Unicode Supplementary Character support". Similar behavior is
>      > observed in other two case-insensitive methods, i.e.,
>      > compareToIgnoreCase() and equalsIgnoreCase().
>      >
>      > The fix is straightforward to compare strings by code point basis,
>      > instead of code unit (16bit "char") basis. Technically this
>     change will
>      > introduce a backward incompatibility, but I believe it is an
>      > incompatibility to wrong behavior, not true to the meaning of those
>      > methods' expectations.
>      >
>      > Naoto
> 

From lance.andersen at oracle.com  Sun Jul 19 18:31:58 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 19 Jul 2020 14:31:58 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <9d351d78-88c1-9e6d-28a0-9aa6c552c251@gmail.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
 <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
 <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>
 <9d351d78-88c1-9e6d-28a0-9aa6c552c251@gmail.com>
Message-ID: <4202609E-F2B7-4C81-B325-B470BD79EA67@oracle.com>

Hi Raffaello,

I think the changes look reasonable.

I have created a webrev, http://cr.openjdk.java.net/~lancea/8222187/webrev.00/ <http://cr.openjdk.java.net/~lancea/8222187/webrev.00/>, for others to review as it is a bit easier than the patch.

I have also run the JCK tests in this area as well as mach5 tiers1-3 (which I believe Roger has also)

Best
Lance

> On Jul 15, 2020, at 5:44 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
> 
> Hi Roger,
> 
> On 2020-07-15 22:21, Roger Riggs wrote:
>> Hi Raffaello,
>> Base64.java:
>> 2: Please update 2nd copyright year to 2020
> 
> I was unsure what to do here, thanks for guidance.
> I also removed the seemingly useless import at former L33.
> 
> 
> 
>> leftovers():
>> 996: "&" the shortcutting && is more typical in a condition.
>> 997: the -= is buried in an expression and a reader might miss it.
> 
> Corrected, as well as the analogous -= usage for wpos now at L1106-7
> 
> 
>> 1053:  "can be reallocated to other vars":  not a useful comment, reflecting on only one possible implementation that is out of the control of the developer.
>> I'd almost rather see 'len' than 'limit - off'; it might be informative to the reader if 'limit' was declared final. (1056:)
> 
> Done, as well as declaring i and v final in the loop.
> 
> 
> 
>> TestBase54.java:
>> 2: Update 2nd copyright year to 2020
>> 27:  Please add the bug number to the @bug line.
>> Style-wise, I would remove the blank lines at the beginning of blocks. (1095, 1115)
> 
> Done.
> 
> 
>> Thanks, Roger
>> On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
>>> Hi Roger,
>>> 
>>> here's the latest version of the patch.
>>> 
>>> I did:
>>> * Withdraw the simplification in encodedOutLength(), as it is indeed out of scope for this bug fix.
>>> * Restore field names in DecInputStream except for nextin (now wpos) and nextout (now rpos) because they have slightly different semantics. That's just for clarity. I would have nothing against reusing the old names for the proposed purpose.
>>> * Switch back to the original no-arg read() implementation.
>>> * Adjust comment continuation lines.
>>> * Preserve the proposed logic of read(byte[], int, int) and the supporting methods.
>>> 
>>> Others needed changes are:
>>> * Correct the copyright years: that's something better left to Oracle.
>>> * Remove the apparently useless import at L33. I could build and run without it.
>>> 
>>> 
>>> Greetings
>>> Raffaello
>>> 
> 
> 
> ----
> 
> # HG changeset patch
> # User lello
> # Date 1594848775 -7200
> #      Wed Jul 15 23:32:55 2020 +0200
> # Node ID f7407f35e83ab508f0e6deab4f776bb1a1c85e68
> # Parent  a5649ebf94193770ca763391dd63807059d333b4
> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end
> Reviewed-by: TBD
> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com <mailto:raffaello.giulietti at gmail.com>>
> 
> diff --git a/src/java.base/share/classes/java/util/Base64.java b/src/java.base/share/classes/java/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java
> +++ b/src/java.base/share/classes/java/util/Base64.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2020, 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
> @@ -30,7 +30,6 @@
> import java.io.IOException;
> import java.io.OutputStream;
> import java.nio.ByteBuffer;
> -import java.nio.charset.StandardCharsets;
> 
> import sun.nio.cs.ISO_8859_1;
> 
> @@ -961,12 +960,15 @@
> 
>         private final InputStream is;
>         private final boolean isMIME;
> -        private final int[] base64;      // base64 -> byte mapping
> -        private int bits = 0;            // 24-bit buffer for decoding
> -        private int nextin = 18;         // next available "off" in "bits" for input;
> -                                         // -> 18, 12, 6, 0
> -        private int nextout = -8;        // next available "off" in "bits" for output;
> -                                         // -> 8, 0, -8 (no byte for output)
> +        private final int[] base64;     // base64 -> byte mapping
> +        private int bits = 0;           // 24-bit buffer for decoding
> +
> +        /* writing bit pos inside bits; one of 24 (left, msb), 18, 12, 6, 0 */
> +        private int wpos = 0;
> +
> +        /* reading bit pos inside bits: one of 24 (left, msb), 16, 8, 0 */
> +        private int rpos = 0;
> +
>         private boolean eof = false;
>         private boolean closed = false;
> 
> @@ -983,107 +985,153 @@
>             return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>         }
> 
> -        private int eof(byte[] b, int off, int len, int oldOff)
> -            throws IOException
> -        {
> +        private int leftovers(byte[] b, int off, int pos, int limit) {
>             eof = true;
> -            if (nextin != 18) {
> -                if (nextin == 12)
> -                    throw new IOException("Base64 stream has one un-decoded dangling byte.");
> -                // treat ending xx/xxx without padding character legal.
> -                // same logic as v == '=' below
> -                b[off++] = (byte)(bits >> (16));
> -                if (nextin == 0) {           // only one padding byte
> -                    if (len == 1) {          // no enough output space
> -                        bits >>= 8;          // shift to lowest byte
> -                        nextout = 0;
> -                    } else {
> -                        b[off++] = (byte) (bits >>  8);
> -                    }
> -                }
> +
> +            /*
> +             * We use a loop here, as this method is executed only a few times.
> +             * Unrolling the loop would probably not contribute much here.
> +             */
> +            while (rpos - 8 >= wpos && pos != limit) {
> +                rpos -= 8;
> +                b[pos++] = (byte) (bits >> rpos);
>             }
> -            return off == oldOff ? -1 : off - oldOff;
> +            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
>         }
> 
> -        private int padding(byte[] b, int off, int len, int oldOff)
> -            throws IOException
> -        {
> -            // =     shiftto==18 unnecessary padding
> -            // x=    shiftto==12 dangling x, invalid unit
> -            // xx=   shiftto==6 && missing last '='
> -            // xx=y  or last is not '='
> -            if (nextin == 18 || nextin == 12 ||
> -                nextin == 6 && is.read() != '=') {
> -                throw new IOException("Illegal base64 ending sequence:" + nextin);
> +        private int eof(byte[] b, int off, int pos, int limit) throws IOException {
> +            /*
> +             * pos != limit
> +             *
> +             * wpos == 18: x     dangling single x, invalid unit
> +             * accept ending xx or xxx without padding characters
> +             */
> +            if (wpos == 18) {
> +                throw new IOException("Base64 stream has one un-decoded dangling byte.");
>             }
> -            b[off++] = (byte)(bits >> (16));
> -            if (nextin == 0) {           // only one padding byte
> -                if (len == 1) {          // no enough output space
> -                    bits >>= 8;          // shift to lowest byte
> -                    nextout = 0;
> -                } else {
> -                    b[off++] = (byte) (bits >>  8);
> -                }
> +            rpos = 24;
> +            return leftovers(b, off, pos, limit);
> +        }
> +
> +        private int padding(byte[] b, int off, int pos, int limit) throws IOException {
> +            /*
> +             * pos != limit
> +             *
> +             * wpos == 24: =    (unnecessary padding)
> +             * wpos == 18: x=   (dangling single x, invalid unit)
> +             * wpos == 12 and missing last '=': xx=  (invalid padding)
> +             * wpos == 12 and last is not '=': xx=x (invalid padding)
> +             */
> +            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
> +                throw new IOException("Illegal base64 ending sequence:" + wpos);
>             }
> -            eof = true;
> -            return off - oldOff;
> +            rpos = 24;
> +            return leftovers(b, off, pos, limit);
>         }
> 
>         @Override
>         public int read(byte[] b, int off, int len) throws IOException {
> -            if (closed)
> +            if (closed) {
>                 throw new IOException("Stream is closed");
> -            if (eof && nextout < 0)    // eof and no leftover
> -                return -1;
> -            if (off < 0 || len < 0 || len > b.length - off)
> -                throw new IndexOutOfBoundsException();
> -            int oldOff = off;
> -            while (nextout >= 0) {       // leftover output byte(s) in bits buf
> -                if (len == 0)
> -                    return off - oldOff;
> -                b[off++] = (byte)(bits >> nextout);
> -                len--;
> -                nextout -= 8;
> +            }
> +            Objects.checkFromIndexSize(off, len, b.length);
> +            if (len == 0) {
> +                return 0;
>             }
> -            bits = 0;
> -            while (len > 0) {
> -                int v = is.read();
> -                if (v == -1) {
> -                    return eof(b, off, len, oldOff);
> +
> +            /*
> +             * Rather than keeping 2 running vars (e.g., off and len),
> +             * we only keep one (pos), while definitely fixing the boundaries
> +             * of the range [off, limit).
> +             * More specifically, each use of pos as an index in b meets
> +             *      pos - off >= 0 & limit - pos > 0
> +             *
> +             * Note that limit can overflow to Integer.MIN_VALUE. However,
> +             * as long as comparisons with pos are as coded, there's no harm.
> +             */
> +            int pos = off;
> +            final int limit = off + len;
> +            if (eof) {
> +                return leftovers(b, off, pos, limit);
> +            }
> +
> +            /*
> +             * Leftovers from previous invocation; here, wpos = 0.
> +             * There can be at most 2 leftover bytes (rpos <= 16).
> +             * Further, b has at least one free place.
> +             *
> +             * The logic could be coded as a loop, (as in method leftovers())
> +             * but the explicit "unrolling" makes it possible to generate
> +             * better byte extraction code.
> +             */
> +            if (rpos == 16) {
> +                b[pos++] = (byte) (bits >> 8);
> +                rpos = 8;
> +                if (pos == limit) {
> +                    return len;
>                 }
> -                if ((v = base64[v]) < 0) {
> -                    if (v == -2) {       // padding byte(s)
> -                        return padding(b, off, len, oldOff);
> -                    }
> -                    if (v == -1) {
> -                        if (!isMIME)
> -                            throw new IOException("Illegal base64 character " +
> -                                Integer.toString(v, 16));
> -                        continue;        // skip if for rfc2045
> -                    }
> -                    // neve be here
> -                }
> -                bits |= (v << nextin);
> -                if (nextin == 0) {
> -                    nextin = 18;         // clear for next in
> -                    b[off++] = (byte)(bits >> 16);
> -                    if (len == 1) {
> -                        nextout = 8;    // 2 bytes left in bits
> -                        break;
> -                    }
> -                    b[off++] = (byte)(bits >> 8);
> -                    if (len == 2) {
> -                        nextout = 0;    // 1 byte left in bits
> -                        break;
> -                    }
> -                    b[off++] = (byte)bits;
> -                    len -= 3;
> -                    bits = 0;
> -                } else {
> -                    nextin -= 6;
> +            }
> +            if (rpos == 8) {
> +                b[pos++] = (byte) bits;
> +                rpos = 0;
> +                if (pos == limit) {
> +                    return len;
>                 }
>             }
> -            return off - oldOff;
> +
> +            bits = 0;
> +            wpos = 24;
> +            for (;;) {
> +                /* pos != limit & rpos == 0 */
> +                final int i = is.read();
> +                if (i < 0) {
> +                    return eof(b, off, pos, limit);
> +                }
> +                final int v = base64[i];
> +                if (v < 0) {
> +                    /*
> +                     * i not in alphabet, thus
> +                     *      v == -2: i is '=', the padding
> +                     *      v == -1: i is something else, typically CR or LF
> +                     */
> +                    if (v == -1) {
> +                        if (isMIME) {
> +                            continue;
> +                        }
> +                        throw new IOException("Illegal base64 character 0x" +
> +                                Integer.toHexString(i));
> +                    }
> +                    return padding(b, off, pos, limit);
> +                }
> +                wpos -= 6;
> +                bits |= v << wpos;
> +                if (wpos != 0) {
> +                    continue;
> +                }
> +                if (limit - pos >= 3) {
> +                    /* frequently taken fast path, no need to track rpos */
> +                    b[pos++] = (byte) (bits >> 16);
> +                    b[pos++] = (byte) (bits >> 8);
> +                    b[pos++] = (byte) bits;
> +                    bits = 0;
> +                    wpos = 24;
> +                    if (pos == limit) {
> +                        return len;
> +                    }
> +                    continue;
> +                }
> +
> +                /* b has either 1 or 2 free places */
> +                b[pos++] = (byte) (bits >> 16);
> +                if (pos == limit) {
> +                    rpos = 16;
> +                    return len;
> +                }
> +                b[pos++] = (byte) (bits >> 8);
> +                /* pos == limit, no need for an if */
> +                rpos = 8;
> +                return len;
> +            }
>         }
> 
>         @Override
> diff --git a/test/jdk/java/util/Base64/TestBase64.java b/test/jdk/java/util/Base64/TestBase64.java
> --- a/test/jdk/java/util/Base64/TestBase64.java
> +++ b/test/jdk/java/util/Base64/TestBase64.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2020, 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
> @@ -24,7 +24,7 @@
> /**
>  * @test
>  * @bug 4235519 8004212 8005394 8007298 8006295 8006315 8006530 8007379 8008925
> - *      8014217 8025003 8026330 8028397 8129544 8165243 8176379
> + *      8014217 8025003 8026330 8028397 8129544 8165243 8176379 8222187
>  * @summary tests java.util.Base64
>  * @library /test/lib
>  * @build jdk.test.lib.RandomFactory
> @@ -144,6 +144,10 @@
>         testDecoderKeepsAbstinence(Base64.getDecoder());
>         testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>         testDecoderKeepsAbstinence(Base64.getMimeDecoder());
> +
> +        // tests patch addressing JDK-8222187
> +        // https://bugs.openjdk.java.net/browse/JDK-8222187
> +        testJDK_8222187();
>     }
> 
>     private static void test(Base64.Encoder enc, Base64.Decoder dec,
> @@ -607,4 +611,26 @@
>             }
>         }
>     }
> +
> +    private static void testJDK_8222187() throws Throwable {
> +        byte[] orig = "12345678".getBytes("US-ASCII");
> +        byte[] encoded = Base64.getEncoder().encode(orig);
> +        // decode using different buffer sizes, up to a longer one than needed
> +        for (int bufferSize = 1; bufferSize <= encoded.length + 1; bufferSize++) {
> +            try (
> +                    InputStream in = Base64.getDecoder().wrap(
> +                            new ByteArrayInputStream(encoded));
> +                    ByteArrayOutputStream baos = new ByteArrayOutputStream();
> +            ) {
> +                byte[] buffer = new byte[bufferSize];
> +                int read;
> +                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
> +                    baos.write(buffer, 0, read);
> +                }
> +                // compare result, output info if lengths do not match
> +                byte[] decoded = baos.toByteArray();
> +                checkEqual(decoded, orig, "Base64 stream decoding failed!");
> +            }
> +        }
> +    }
> }
> <JDK-8222187.patch>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From sergei.tsypanov at yandex.ru  Mon Jul 20 07:39:37 2020
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 20 Jul 2020 09:39:37 +0200
Subject: [PATCH] trivial improvement of String.replace(CharSequence cs1,
 CharSequence cs2) for the case cs1 is empty
Message-ID: <870111595192314@mail.yandex.ru>

Hello,

I'd like to contribute this simple patch that improves performance of
 String.replace(CharSequence cs1, CharSequence cs2) for the case cs1 is empty.

The idea is to get rid of StringBuilder in favour of byte[] / char[].

To measure improvement I've used benchmark [1] that demonstrates improvement as of both memory and time consumption
for the case when I have String s = "aaaa" and I need to surround each char 'a' with 'b'. For this I call

String str = s.replace("", "b");

See the results for original JDK and patched one:

before
                                                        (latin)  (length)   Mode  Cnt      Score     Error   Units
insertBetweenEachChar                                      true         5  thrpt   50  16992.105 ? 528.388  ops/ms
insertBetweenEachChar                                      true        10  thrpt   50   9119.878 ? 421.776  ops/ms
insertBetweenEachChar                                      true        50  thrpt   50   2270.251 ?  45.815  ops/ms
insertBetweenEachChar                                     false         5  thrpt   50  11468.241 ? 623.440  ops/ms
insertBetweenEachChar                                     false        10  thrpt   50   7150.812 ? 299.363  ops/ms
insertBetweenEachChar                                     false        50  thrpt   50   1613.470 ?  66.941  ops/ms

insertBetweenEachChar:?gc.alloc.rate.norm                  true         5  thrpt   50     88.010 ?   0.001    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                  true        10  thrpt   50    104.015 ?   0.001    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                  true        50  thrpt   50    264.046 ?   0.002    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                 false         5  thrpt   50    177.618 ?   5.880    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                 false        10  thrpt   50    251.229 ?   4.801    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                 false        50  thrpt   50    736.091 ?   0.005    B/op

after

insertBetweenEachChar                                      true         5  thrpt   50  19249.086 ? 325.786  ops/ms
insertBetweenEachChar                                      true        10  thrpt   50  12962.483 ?  61.992  ops/ms
insertBetweenEachChar                                      true        50  thrpt   50   3232.475 ?  16.864  ops/ms
insertBetweenEachChar                                     false         5  thrpt   50  26083.880 ? 218.046  ops/ms
insertBetweenEachChar                                     false        10  thrpt   50  18305.650 ? 180.684  ops/ms
insertBetweenEachChar                                     false        50  thrpt   50   5712.175 ?  37.051  ops/ms

insertBetweenEachChar:?gc.alloc.rate.norm                  true         5  thrpt   50     88.010 ?   0.001    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                  true        10  thrpt   50    104.012 ?   0.001    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                  true        50  thrpt   50    264.038 ?   0.002    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                 false         5  thrpt   50    136.012 ?   0.001    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                 false        10  thrpt   50    192.017 ?   0.001    B/op
insertBetweenEachChar:?gc.alloc.rate.norm                 false        50  thrpt   50    592.053 ?   0.001    B/op

Full output can be found in [2].

Patch is attached.

With best regards,
Sergey Tsypanov

[1] https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/string/InsertCharBenchmark.java
[2] https://github.com/stsypanov/strings/blob/master/results/InsertCharBenchmark.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string.patch
Type: text/x-diff
Size: 1625 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200720/bc8d8f27/string.patch>

From johnlinp at gmail.com  Mon Jul 20 08:48:43 2020
From: johnlinp at gmail.com (=?UTF-8?B?5p6X6Ieq5Z2H?=)
Date: Mon, 20 Jul 2020 16:48:43 +0800
Subject: [PATCH] 8247402: Rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <CAKO26MuMGjiSy+nz9EHqBDRmxZoojLCsADqnDgEFm_GnEkvTjw@mail.gmail.com>
References: <CAKO26MsUt-9DBefiqU36jOJ+JzTiKnoFmMh+pfxY-iQRFwGO-Q@mail.gmail.com>
 <CA+kOe08_O88KxYHTVqdqQkt6tC-Joi44y7sStVbCs0UgfDdPkA@mail.gmail.com>
 <CAKO26MtSgrBNhosYUpva=hRChUUEbsEntUJo=dczNfAMXo5ERQ@mail.gmail.com>
 <CA+kOe0-Mu7ZV+D4H_Ybno-rAbUAavxqn9TZGRZ0B27U6zKBS1w@mail.gmail.com>
 <CAKO26MuXziE035eEWBPo-MLYamsUdTFmdi414_FPL9_558eQvQ@mail.gmail.com>
 <CA+kOe0_W-vVNxmev0HTRDc9sPFFaz6M07bUNJp=1wqn9=ASVnA@mail.gmail.com>
 <CAKO26Mvv+9TdTV1cutRJEKhtrMvq65+BMtqDtujKcvcH8iQVeg@mail.gmail.com>
 <CAKO26MuMGjiSy+nz9EHqBDRmxZoojLCsADqnDgEFm_GnEkvTjw@mail.gmail.com>
Message-ID: <CAKO26Mtuc-ECTqtsFX-E+LW=waYbs+VyuLxgqfa8mwNbsPsvwg@mail.gmail.com>

Hi Martin,

It's been over a month since your last email. Do you have any update?

Best,
John Lin

??? <johnlinp at gmail.com> ? 2020?6?20? ?? ??9:00???
>
> Hi Martin,
>
> Any update on this? Thanks!
>
> Best,
> John Lin
>
> ??? <johnlinp at gmail.com> ? 2020?6?13? ?? ??11:08???
> >
> > Hi Martin,
> >
> > I see your point. Thank you for demostrating this for me.
> >
> > Here's my updated patch:
> >
> > # HG changeset patch
> > # User John Lin <johnlinp at gmail.com>
> > # Date 1591923561 -28800
> > #      Fri Jun 12 08:59:21 2020 +0800
> > # Node ID e01d9d020506a88d3d585bd3264594a26450c659
> > # Parent  49a68abdb0ba68351db0f140ddac793b1c391bd5
> > 8247402: Rewrite the implementation requirements for Map::compute()
> >
> > diff --git a/src/java.base/share/classes/java/util/Map.java
> > b/src/java.base/share/classes/java/util/Map.java
> > --- a/src/java.base/share/classes/java/util/Map.java
> > +++ b/src/java.base/share/classes/java/util/Map.java
> > @@ -1113,17 +1113,12 @@ public interface Map<K, V> {
> >       * <pre> {@code
> >       * V oldValue = map.get(key);
> >       * V newValue = remappingFunction.apply(key, oldValue);
> > -     * if (oldValue != null) {
> > -     *    if (newValue != null)
> > -     *       map.put(key, newValue);
> > -     *    else
> > -     *       map.remove(key);
> > +     * if (newValue != null) {
> > +     *     map.put(key, newValue);
> >       * } else {
> > -     *    if (newValue != null)
> > -     *       map.put(key, newValue);
> > -     *    else
> > -     *       return null;
> > +     *     map.remove(key);
> >       * }
> > +     * return newValue;
> >       * }</pre>
> >       *
> >       * <p>The default implementation makes no guarantees about detecting if the
> >
> > By the way, I saw everyone in this mailing list is using webrev.
> > However, the tutorial https://openjdk.java.net/guide/codeReview.html
> > says that only the users with push access to the OpenJDK Mercurial
> > server can use webrev. Can I apply for push access to the OpenJDK
> > Mercurial server too?
> >
> > Best,
> > John Lin
> >
> > Martin Buchholz <martinrb at google.com> ? 2020?6?13? ?? ??12:36???
> > >
> > > If I rub that program, I get:
> > >
> > > HashMap false
> > > HashMap1 false
> > > HashMap2 true
> > >
> > > which suggests that HashMap2's implementation is wrong.

From julia.boes at oracle.com  Mon Jul 20 12:17:59 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Mon, 20 Jul 2020 13:17:59 +0100
Subject: [PATCH] 8245694 : java.util.Properties.entrySet() does not
 override java.lang.Object methods
In-Reply-To: <CAFZshwoCuxG31jWifWyx=yVO9TbdFefPK_wwkEvZbQM1E1jV+w@mail.gmail.com>
References: <CAFZshwqsMObUVhPSP8kOWkQSp_T+DRAbWx_ab_Jayw2EJA9TmA@mail.gmail.com>
 <9487a1c9-d0bc-3632-156d-5927e5801dc8@icemanx.nl>
 <20109712-d505-1b17-3e6b-ae388d554400@oracle.com>
 <767a4dae-55f0-ca11-dbdf-57c7a22205d3@oracle.com>
 <CAFZshwq89R66TtPLN2niLa2YcFs6DBGRhqW4iDKq2N1XGJTr0g@mail.gmail.com>
 <CAFZshwra0r_zBVdPOyAT2u5yQCcOAVo49f+MayEx3reu9s+iQw@mail.gmail.com>
 <7b01289c-d7c9-47ab-f9f6-e2cf3a00f2da@oracle.com>
 <37bea22e-115f-5187-0f21-e04536691efc@oracle.com>
 <CAFZshwr3yXQ2sTOckmdDheMMnE4pkBCccv_7boPqeJtPAt3ypw@mail.gmail.com>
 <CAFZshwr-efvZDosDQfvfLvuCVRKi+GYPShCJnZ+F=9UJKj9ihw@mail.gmail.com>
 <de327d49-b5cb-92ed-7425-5fa6c2ac8e20@oracle.com>
 <CAFZshwomQyV3JJ9J8_KEMOoQQh5UF0dkw-DU1DB9H0DbvrUmJg@mail.gmail.com>
 <140eb4ab-ff9b-eb20-2d37-e6bb5f9506b4@oracle.com>
 <CAFZshwoYZZ47bMKrPmupovFhFdPs+rpN_rBEhZi=C6o7g5T8Bw@mail.gmail.com>
 <CAFZshwoCuxG31jWifWyx=yVO9TbdFefPK_wwkEvZbQM1E1jV+w@mail.gmail.com>
Message-ID: <36380c40-edfa-5a27-4b91-93f081ea495e@oracle.com>

Hi Lisa,

I added a newline at the end of the test and ran the relevant test set, 
which came back all clear.

The change is pushed now.

Thanks,

Julia

On 19/07/2020 11:48, Lisa Li wrote:
> Hi Julia?
>
> Apologies?for the delay. Please review the updated fix for JDK-8245694 
> <https://bugs.openjdk.java.net/browse/JDK-8245694>.? Also, my name is 
> on the contributor list as: Yu Li - OpenJDK - yuli.
>
>
> *BUG DESCRIPTION*:
>
> JDK-8245694 <https://bugs.openjdk.java.net/browse/JDK-8245694>?: 
> java.util.Properties.entrySet() does not override java.lang.Object 
> methods since java 9.
>
>
> *PATCH*:
>
> # HG changeset patch
> # User yuli
> # Date 1595152648 -28800
> # ? ? ?Sun Jul 19 17:57:28 2020 +0800
> # Node ID 4f359fdb3df3407cf8b31cb9ad153a99c52165c8
> # Parent ?72bf0aca309e326f35cdc85cbdeb3076e4d4e74d
> 8245694: java.util.Properties.entrySet() does not override Object methods
> Summary: Add missing override methods
> Contributed-by: Yu Li <liyu.italy at gmail.com <mailto:liyu.italy at gmail.com>>
>
> diff -r 72bf0aca309e -r 4f359fdb3df3 
> src/java.base/share/classes/java/util/Properties.java
> --- a/src/java.base/share/classes/java/util/Properties.java Fri Jul 17 
> 17:27:31 2020 -0700
> +++ b/src/java.base/share/classes/java/util/Properties.java Sun Jul 19 
> 17:57:28 2020 +0800
> @@ -1405,6 +1405,21 @@
> ? ? ? ? ?}
>
> ? ? ? ? ?@Override
> + ? ? ? ?public boolean equals(Object o) {
> + ? ? ? ? ? ?return o == this || entrySet.equals(o);
> + ? ? ? ?}
> +
> + ? ? ? ?@Override
> + ? ? ? ?public int hashCode() {
> + ? ? ? ? ? ?return entrySet.hashCode();
> + ? ? ? ?}
> +
> + ? ? ? ?@Override
> + ? ? ? ?public String toString() {
> + ? ? ? ? ? ?return entrySet.toString();
> + ? ? ? ?}
> +
> + ? ? ? ?@Override
> ? ? ? ? ?public boolean removeAll(Collection<?> c) {
> ? ? ? ? ? ? ?return entrySet.removeAll(c);
> ? ? ? ? ?}
> diff -r 72bf0aca309e -r 4f359fdb3df3 
> test/jdk/java/util/Properties/PropertiesEntrySetTest.java
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java Sun 
> Jul 19 17:57:28 2020 +0800
> @@ -0,0 +1,201 @@
> +/*
> + * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.? See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file 
> that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License 
> version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 
> 94065 USA
> + * or visit www.oracle.com <http://www.oracle.com> if you need 
> additional information or have any
> + * questions.
> + */
> +
> +/*
> + * @test
> + * @bug ? ? ? ?8245694
> + * @summary ? ?tests the entrySet() method of Properties class
> + * @author ? ? Yu Li
> + * @run testng PropertiesEntrySetTest
> + */
> +
> +import org.testng.annotations.Test;
> +
> +import java.util.Properties;
> +
> +import static org.testng.Assert.assertEquals;
> +import static org.testng.Assert.assertFalse;
> +import static org.testng.Assert.assertThrows;
> +import static org.testng.Assert.assertTrue;
> +
> +public class PropertiesEntrySetTest {
> +
> + ? ?@Test
> + ? ?public void testEquals() {
> + ? ? ? ?Properties a = new Properties();
> + ? ? ? ?var aEntrySet = a.entrySet();
> + ? ? ? ?assertFalse(aEntrySet.equals(null));
> + ? ? ? ?assertTrue(aEntrySet.equals(aEntrySet));
> +
> + ? ? ? ?Properties b = new Properties();
> + ? ? ? ?var bEntrySet = b.entrySet();
> + ? ? ? ?assertTrue(bEntrySet.equals(aEntrySet));
> + ? ? ? ?assertTrue(bEntrySet.hashCode() == aEntrySet.hashCode());
> +
> + ? ? ? ?a.setProperty("p1", "1");
> + ? ? ? ?assertFalse(bEntrySet.equals(aEntrySet));
> + ? ? ? ?assertFalse(bEntrySet.hashCode() == aEntrySet.hashCode());
> +
> + ? ? ? ?b.setProperty("p1", "1");
> + ? ? ? ?assertTrue(aEntrySet.equals(bEntrySet));
> + ? ? ? ?assertTrue(bEntrySet.hashCode() == aEntrySet.hashCode());
> +
> + ? ? ? ?Properties c = new Properties();
> + ? ? ? ?c.setProperty("p1", "2");
> + ? ? ? ?var cEntrySet = c.entrySet();
> + ? ? ? ?assertFalse(cEntrySet.equals(bEntrySet));
> + ? ? ? ?assertFalse(bEntrySet.hashCode() == cEntrySet.hashCode());
> + ? ? ? ?assertFalse(cEntrySet.equals(aEntrySet));
> + ? ? ? ?assertFalse(aEntrySet.hashCode() == cEntrySet.hashCode());
> +
> + ? ? ? ?a.setProperty("p2", "2");
> + ? ? ? ?Properties d = new Properties();
> + ? ? ? ?d.setProperty("p2", "2");
> + ? ? ? ?d.setProperty("p1", "1");
> + ? ? ? ?var dEntrySet = d.entrySet();
> + ? ? ? ?assertTrue(dEntrySet.equals(aEntrySet));
> + ? ? ? ?assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
> +
> + ? ? ? ?a.remove("p1");
> + ? ? ? ?assertFalse(aEntrySet.equals(dEntrySet));
> + ? ? ? ?assertFalse(aEntrySet.hashCode() == dEntrySet.hashCode());
> +
> + ? ? ? ?d.remove("p1", "1");
> + ? ? ? ?assertTrue(dEntrySet.equals(aEntrySet));
> + ? ? ? ?assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
> +
> + ? ? ? ?a.clear();
> + ? ? ? ?assertFalse(aEntrySet.equals(dEntrySet));
> + ? ? ? ?assertFalse(aEntrySet.hashCode() == dEntrySet.hashCode());
> + ? ? ? ?assertTrue(aEntrySet.isEmpty());
> +
> + ? ? ? ?d.clear();
> + ? ? ? ?assertTrue(dEntrySet.equals(aEntrySet));
> + ? ? ? ?assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
> + ? ? ? ?assertTrue(dEntrySet.isEmpty());
> + ? ?}
> +
> + ? ?@Test
> + ? ?public void testToString() {
> + ? ? ? ?Properties a = new Properties();
> + ? ? ? ?var aEntrySet = a.entrySet();
> + ? ? ? ?assertEquals(aEntrySet.toString(), "[]");
> +
> + ? ? ? ?a.setProperty("p1", "1");
> + ? ? ? ?assertEquals(aEntrySet.toString(), "[p1=1]");
> +
> + ? ? ? ?a.setProperty("p2", "2");
> + ? ? ? ?assertEquals(aEntrySet.size(), 2);
> + ?assertTrue(aEntrySet.toString().trim().startsWith("["));
> + ? ? ? ?assertTrue(aEntrySet.toString().contains("p1=1"));
> + ? ? ? ?assertTrue(aEntrySet.toString().contains("p2=2"));
> + ?assertTrue(aEntrySet.toString().trim().endsWith("]"));
> +
> + ? ? ? ?Properties b = new Properties();
> + ? ? ? ?b.setProperty("p2", "2");
> + ? ? ? ?b.setProperty("p1", "1");
> + ? ? ? ?var bEntrySet = b.entrySet();
> + ? ? ? ?assertEquals(bEntrySet.size(), 2);
> + ?assertTrue(bEntrySet.toString().trim().startsWith("["));
> + ? ? ? ?assertTrue(bEntrySet.toString().contains("p1=1"));
> + ? ? ? ?assertTrue(bEntrySet.toString().contains("p2=2"));
> + ?assertTrue(bEntrySet.toString().trim().endsWith("]"));
> +
> + ? ? ? ?b.setProperty("p0", "0");
> + ? ? ? ?assertEquals(bEntrySet.size(), 3);
> + ? ? ? ?assertTrue(bEntrySet.toString().contains("p0=0"));
> +
> + ? ? ? ?b.remove("p1");
> + ? ? ? ?assertEquals(bEntrySet.size(), 2);
> + ? ? ? ?assertFalse(bEntrySet.toString().contains("p1=1"));
> + ?assertTrue(bEntrySet.toString().trim().startsWith("["));
> + ? ? ? ?assertTrue(bEntrySet.toString().contains("p0=0"));
> + ? ? ? ?assertTrue(bEntrySet.toString().contains("p2=2"));
> + ?assertTrue(bEntrySet.toString().trim().endsWith("]"));
> +
> + ? ? ? ?b.remove("p0", "0");
> + ? ? ? ?assertEquals(bEntrySet.size(), 1);
> + ? ? ? ?assertFalse(bEntrySet.toString().contains("p0=0"));
> + ?assertTrue(bEntrySet.toString().trim().startsWith("["));
> + ? ? ? ?assertTrue(bEntrySet.toString().contains("p2=2"));
> + ?assertTrue(bEntrySet.toString().trim().endsWith("]"));
> +
> + ? ? ? ?b.clear();
> + ? ? ? ?assertTrue(bEntrySet.isEmpty());
> + ? ? ? ?assertTrue(bEntrySet.toString().equals("[]"));
> + ? ?}
> +
> + ? ?@Test
> + ? ?public void testEntrySetWithoutException() {
> + ? ? ? ?Properties a = new Properties();
> + ? ? ? ?a.setProperty("p1", "1");
> + ? ? ? ?a.setProperty("p2", "2");
> + ? ? ? ?var aEntrySet = a.entrySet();
> + ? ? ? ?assertEquals(aEntrySet.size(), 2);
> +
> + ? ? ? ?var i = aEntrySet.iterator();
> + ? ? ? ?var e1 = i.next();
> + ? ? ? ?i.remove();
> + ? ? ? ?assertFalse(aEntrySet.contains(e1));
> + ? ? ? ?assertEquals(aEntrySet.size(), 1);
> +
> + ? ? ? ?var e2 = i.next();
> + ? ? ? ?aEntrySet.remove(e2);
> + ? ? ? ?assertFalse(aEntrySet.contains(e2));
> + ? ? ? ?assertTrue(aEntrySet.isEmpty());
> +
> + ? ? ? ?a.setProperty("p1", "1");
> + ? ? ? ?a.setProperty("p3", "3");
> + ? ? ? ?Properties b = new Properties();
> + ? ? ? ?b.setProperty("p2", "2");
> + ? ? ? ?b.setProperty("p1", "1");
> + ? ? ? ?var bEntrySet = b.entrySet();
> +
> + ? ? ? ?assertFalse(bEntrySet.containsAll(aEntrySet));
> + ? ? ? ?assertEquals(bEntrySet.size(), 2);
> +
> + ? ? ? ?assertTrue(bEntrySet.removeAll(aEntrySet));
> + ? ? ? ?assertEquals(bEntrySet.size(), 1);
> +
> + ? ? ? ?assertTrue(bEntrySet.retainAll(aEntrySet));
> + ? ? ? ?assertTrue(bEntrySet.isEmpty());
> + ? ? ? ?assertEquals(aEntrySet.size(), 2);
> +
> + ? ? ? ?aEntrySet.clear();
> + ? ? ? ?assertTrue(aEntrySet.isEmpty());
> + ? ?}
> +
> + ? ?@Test
> + ? ?public void testEntrySetExceptionWhenAdd() {
> + ? ? ? ?Properties a = new Properties();
> + ? ? ? ?a.setProperty("p1", "1");
> + ? ? ? ?var aEntrySet = a.entrySet();
> +
> + ? ? ? ?Properties b = new Properties();
> + ? ? ? ?b.setProperty("p2", "2");
> + ? ? ? ?var bEntrySet = b.entrySet();
> +
> + ? ? ? ?assertThrows(UnsupportedOperationException.class, () -> 
> aEntrySet.addAll(bEntrySet));
> + ? ? ? ?assertThrows(UnsupportedOperationException.class, () -> 
> aEntrySet.add(bEntrySet.iterator().next()));
> + ? ?}
> +}
> \ No newline at end of file
>
> Best regards,
> Yu L.
>
>
> On Tue, Jun 23, 2020 at 12:32 AM Lisa Li <liyu.italy at gmail.com 
> <mailto:liyu.italy at gmail.com>> wrote:
>
>     Great, thanks Julia!
>
>     Best regards,
>     ?Yu L.
>
>     On Mon, Jun 22, 2020 at 9:56 PM Julia Boes <julia.boes at oracle.com
>     <mailto:julia.boes at oracle.com>> wrote:
>
>         Hi Yu,
>
>>         Just to confirm, for
>>         src/java.base/share/classes/java/util/Properties.java the
>>         copyright should be updated as :
>>
>>         + * Copyright (c) 1995, 2020, Oracle and/or its affiliates.
>>         All rights
>>
>>         Because 1995 was the year when the?file was added, while 2020
>>         when this change is made. Correct me if I'm wrong.
>
>         That's right!
>
>         Cheers,
>
>         Julia
>
>

From liyu.italy at gmail.com  Mon Jul 20 15:24:36 2020
From: liyu.italy at gmail.com (Lisa Li)
Date: Mon, 20 Jul 2020 23:24:36 +0800
Subject: [PATCH] 8245694 : java.util.Properties.entrySet() does not
 override java.lang.Object methods
In-Reply-To: <36380c40-edfa-5a27-4b91-93f081ea495e@oracle.com>
References: <CAFZshwqsMObUVhPSP8kOWkQSp_T+DRAbWx_ab_Jayw2EJA9TmA@mail.gmail.com>
 <9487a1c9-d0bc-3632-156d-5927e5801dc8@icemanx.nl>
 <20109712-d505-1b17-3e6b-ae388d554400@oracle.com>
 <767a4dae-55f0-ca11-dbdf-57c7a22205d3@oracle.com>
 <CAFZshwq89R66TtPLN2niLa2YcFs6DBGRhqW4iDKq2N1XGJTr0g@mail.gmail.com>
 <CAFZshwra0r_zBVdPOyAT2u5yQCcOAVo49f+MayEx3reu9s+iQw@mail.gmail.com>
 <7b01289c-d7c9-47ab-f9f6-e2cf3a00f2da@oracle.com>
 <37bea22e-115f-5187-0f21-e04536691efc@oracle.com>
 <CAFZshwr3yXQ2sTOckmdDheMMnE4pkBCccv_7boPqeJtPAt3ypw@mail.gmail.com>
 <CAFZshwr-efvZDosDQfvfLvuCVRKi+GYPShCJnZ+F=9UJKj9ihw@mail.gmail.com>
 <de327d49-b5cb-92ed-7425-5fa6c2ac8e20@oracle.com>
 <CAFZshwomQyV3JJ9J8_KEMOoQQh5UF0dkw-DU1DB9H0DbvrUmJg@mail.gmail.com>
 <140eb4ab-ff9b-eb20-2d37-e6bb5f9506b4@oracle.com>
 <CAFZshwoYZZ47bMKrPmupovFhFdPs+rpN_rBEhZi=C6o7g5T8Bw@mail.gmail.com>
 <CAFZshwoCuxG31jWifWyx=yVO9TbdFefPK_wwkEvZbQM1E1jV+w@mail.gmail.com>
 <36380c40-edfa-5a27-4b91-93f081ea495e@oracle.com>
Message-ID: <CAFZshwq_RrkFxrOLU5KrmBdU08tr-anegyMpnQYosJgByBB0ug@mail.gmail.com>

Hi Julia, Brent, Jason and Rob,

Thanks a lot for all your help guys! It's been a wonderful experience for
me. First patch for OpenJDK, checked!

Cheers,
Yu L.

On Mon, Jul 20, 2020 at 8:18 PM Julia Boes <julia.boes at oracle.com> wrote:

> Hi Lisa,
>
> I added a newline at the end of the test and ran the relevant test set,
> which came back all clear.
>
> The change is pushed now.
>
> Thanks,
>
> Julia
>
> On 19/07/2020 11:48, Lisa Li wrote:
> > Hi Julia?
> >
> > Apologies for the delay. Please review the updated fix for JDK-8245694
> > <https://bugs.openjdk.java.net/browse/JDK-8245694>.  Also, my name is
> > on the contributor list as: Yu Li - OpenJDK - yuli.
> >
> >
> > *BUG DESCRIPTION*:
> >
> > JDK-8245694 <https://bugs.openjdk.java.net/browse/JDK-8245694> :
> > java.util.Properties.entrySet() does not override java.lang.Object
> > methods since java 9.
> >
> >
> > *PATCH*:
> >
> > # HG changeset patch
> > # User yuli
> > # Date 1595152648 -28800
> > #      Sun Jul 19 17:57:28 2020 +0800
> > # Node ID 4f359fdb3df3407cf8b31cb9ad153a99c52165c8
> > # Parent  72bf0aca309e326f35cdc85cbdeb3076e4d4e74d
> > 8245694: java.util.Properties.entrySet() does not override Object methods
> > Summary: Add missing override methods
> > Contributed-by: Yu Li <liyu.italy at gmail.com <mailto:liyu.italy at gmail.com
> >>
> >
> > diff -r 72bf0aca309e -r 4f359fdb3df3
> > src/java.base/share/classes/java/util/Properties.java
> > --- a/src/java.base/share/classes/java/util/Properties.java Fri Jul 17
> > 17:27:31 2020 -0700
> > +++ b/src/java.base/share/classes/java/util/Properties.java Sun Jul 19
> > 17:57:28 2020 +0800
> > @@ -1405,6 +1405,21 @@
> >          }
> >
> >          @Override
> > +        public boolean equals(Object o) {
> > +            return o == this || entrySet.equals(o);
> > +        }
> > +
> > +        @Override
> > +        public int hashCode() {
> > +            return entrySet.hashCode();
> > +        }
> > +
> > +        @Override
> > +        public String toString() {
> > +            return entrySet.toString();
> > +        }
> > +
> > +        @Override
> >          public boolean removeAll(Collection<?> c) {
> >              return entrySet.removeAll(c);
> >          }
> > diff -r 72bf0aca309e -r 4f359fdb3df3
> > test/jdk/java/util/Properties/PropertiesEntrySetTest.java
> > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> > +++ b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java Sun
> > Jul 19 17:57:28 2020 +0800
> > @@ -0,0 +1,201 @@
> > +/*
> > + * Copyright (c) 2020, Oracle and/or its affiliates. All rights
> reserved.
> > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> > + *
> > + * This code is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 only, as
> > + * published by the Free Software Foundation.
> > + *
> > + * This code is distributed in the hope that it will be useful, but
> > WITHOUT
> > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> > + * version 2 for more details (a copy is included in the LICENSE file
> > that
> > + * accompanied this code).
> > + *
> > + * You should have received a copy of the GNU General Public License
> > version
> > + * 2 along with this work; if not, write to the Free Software
> Foundation,
> > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> > + *
> > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
> > 94065 USA
> > + * or visit www.oracle.com <http://www.oracle.com> if you need
> > additional information or have any
> > + * questions.
> > + */
> > +
> > +/*
> > + * @test
> > + * @bug        8245694
> > + * @summary    tests the entrySet() method of Properties class
> > + * @author     Yu Li
> > + * @run testng PropertiesEntrySetTest
> > + */
> > +
> > +import org.testng.annotations.Test;
> > +
> > +import java.util.Properties;
> > +
> > +import static org.testng.Assert.assertEquals;
> > +import static org.testng.Assert.assertFalse;
> > +import static org.testng.Assert.assertThrows;
> > +import static org.testng.Assert.assertTrue;
> > +
> > +public class PropertiesEntrySetTest {
> > +
> > +    @Test
> > +    public void testEquals() {
> > +        Properties a = new Properties();
> > +        var aEntrySet = a.entrySet();
> > +        assertFalse(aEntrySet.equals(null));
> > +        assertTrue(aEntrySet.equals(aEntrySet));
> > +
> > +        Properties b = new Properties();
> > +        var bEntrySet = b.entrySet();
> > +        assertTrue(bEntrySet.equals(aEntrySet));
> > +        assertTrue(bEntrySet.hashCode() == aEntrySet.hashCode());
> > +
> > +        a.setProperty("p1", "1");
> > +        assertFalse(bEntrySet.equals(aEntrySet));
> > +        assertFalse(bEntrySet.hashCode() == aEntrySet.hashCode());
> > +
> > +        b.setProperty("p1", "1");
> > +        assertTrue(aEntrySet.equals(bEntrySet));
> > +        assertTrue(bEntrySet.hashCode() == aEntrySet.hashCode());
> > +
> > +        Properties c = new Properties();
> > +        c.setProperty("p1", "2");
> > +        var cEntrySet = c.entrySet();
> > +        assertFalse(cEntrySet.equals(bEntrySet));
> > +        assertFalse(bEntrySet.hashCode() == cEntrySet.hashCode());
> > +        assertFalse(cEntrySet.equals(aEntrySet));
> > +        assertFalse(aEntrySet.hashCode() == cEntrySet.hashCode());
> > +
> > +        a.setProperty("p2", "2");
> > +        Properties d = new Properties();
> > +        d.setProperty("p2", "2");
> > +        d.setProperty("p1", "1");
> > +        var dEntrySet = d.entrySet();
> > +        assertTrue(dEntrySet.equals(aEntrySet));
> > +        assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
> > +
> > +        a.remove("p1");
> > +        assertFalse(aEntrySet.equals(dEntrySet));
> > +        assertFalse(aEntrySet.hashCode() == dEntrySet.hashCode());
> > +
> > +        d.remove("p1", "1");
> > +        assertTrue(dEntrySet.equals(aEntrySet));
> > +        assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
> > +
> > +        a.clear();
> > +        assertFalse(aEntrySet.equals(dEntrySet));
> > +        assertFalse(aEntrySet.hashCode() == dEntrySet.hashCode());
> > +        assertTrue(aEntrySet.isEmpty());
> > +
> > +        d.clear();
> > +        assertTrue(dEntrySet.equals(aEntrySet));
> > +        assertTrue(aEntrySet.hashCode() == dEntrySet.hashCode());
> > +        assertTrue(dEntrySet.isEmpty());
> > +    }
> > +
> > +    @Test
> > +    public void testToString() {
> > +        Properties a = new Properties();
> > +        var aEntrySet = a.entrySet();
> > +        assertEquals(aEntrySet.toString(), "[]");
> > +
> > +        a.setProperty("p1", "1");
> > +        assertEquals(aEntrySet.toString(), "[p1=1]");
> > +
> > +        a.setProperty("p2", "2");
> > +        assertEquals(aEntrySet.size(), 2);
> > +  assertTrue(aEntrySet.toString().trim().startsWith("["));
> > +        assertTrue(aEntrySet.toString().contains("p1=1"));
> > +        assertTrue(aEntrySet.toString().contains("p2=2"));
> > +  assertTrue(aEntrySet.toString().trim().endsWith("]"));
> > +
> > +        Properties b = new Properties();
> > +        b.setProperty("p2", "2");
> > +        b.setProperty("p1", "1");
> > +        var bEntrySet = b.entrySet();
> > +        assertEquals(bEntrySet.size(), 2);
> > +  assertTrue(bEntrySet.toString().trim().startsWith("["));
> > +        assertTrue(bEntrySet.toString().contains("p1=1"));
> > +        assertTrue(bEntrySet.toString().contains("p2=2"));
> > +  assertTrue(bEntrySet.toString().trim().endsWith("]"));
> > +
> > +        b.setProperty("p0", "0");
> > +        assertEquals(bEntrySet.size(), 3);
> > +        assertTrue(bEntrySet.toString().contains("p0=0"));
> > +
> > +        b.remove("p1");
> > +        assertEquals(bEntrySet.size(), 2);
> > +        assertFalse(bEntrySet.toString().contains("p1=1"));
> > +  assertTrue(bEntrySet.toString().trim().startsWith("["));
> > +        assertTrue(bEntrySet.toString().contains("p0=0"));
> > +        assertTrue(bEntrySet.toString().contains("p2=2"));
> > +  assertTrue(bEntrySet.toString().trim().endsWith("]"));
> > +
> > +        b.remove("p0", "0");
> > +        assertEquals(bEntrySet.size(), 1);
> > +        assertFalse(bEntrySet.toString().contains("p0=0"));
> > +  assertTrue(bEntrySet.toString().trim().startsWith("["));
> > +        assertTrue(bEntrySet.toString().contains("p2=2"));
> > +  assertTrue(bEntrySet.toString().trim().endsWith("]"));
> > +
> > +        b.clear();
> > +        assertTrue(bEntrySet.isEmpty());
> > +        assertTrue(bEntrySet.toString().equals("[]"));
> > +    }
> > +
> > +    @Test
> > +    public void testEntrySetWithoutException() {
> > +        Properties a = new Properties();
> > +        a.setProperty("p1", "1");
> > +        a.setProperty("p2", "2");
> > +        var aEntrySet = a.entrySet();
> > +        assertEquals(aEntrySet.size(), 2);
> > +
> > +        var i = aEntrySet.iterator();
> > +        var e1 = i.next();
> > +        i.remove();
> > +        assertFalse(aEntrySet.contains(e1));
> > +        assertEquals(aEntrySet.size(), 1);
> > +
> > +        var e2 = i.next();
> > +        aEntrySet.remove(e2);
> > +        assertFalse(aEntrySet.contains(e2));
> > +        assertTrue(aEntrySet.isEmpty());
> > +
> > +        a.setProperty("p1", "1");
> > +        a.setProperty("p3", "3");
> > +        Properties b = new Properties();
> > +        b.setProperty("p2", "2");
> > +        b.setProperty("p1", "1");
> > +        var bEntrySet = b.entrySet();
> > +
> > +        assertFalse(bEntrySet.containsAll(aEntrySet));
> > +        assertEquals(bEntrySet.size(), 2);
> > +
> > +        assertTrue(bEntrySet.removeAll(aEntrySet));
> > +        assertEquals(bEntrySet.size(), 1);
> > +
> > +        assertTrue(bEntrySet.retainAll(aEntrySet));
> > +        assertTrue(bEntrySet.isEmpty());
> > +        assertEquals(aEntrySet.size(), 2);
> > +
> > +        aEntrySet.clear();
> > +        assertTrue(aEntrySet.isEmpty());
> > +    }
> > +
> > +    @Test
> > +    public void testEntrySetExceptionWhenAdd() {
> > +        Properties a = new Properties();
> > +        a.setProperty("p1", "1");
> > +        var aEntrySet = a.entrySet();
> > +
> > +        Properties b = new Properties();
> > +        b.setProperty("p2", "2");
> > +        var bEntrySet = b.entrySet();
> > +
> > +        assertThrows(UnsupportedOperationException.class, () ->
> > aEntrySet.addAll(bEntrySet));
> > +        assertThrows(UnsupportedOperationException.class, () ->
> > aEntrySet.add(bEntrySet.iterator().next()));
> > +    }
> > +}
> > \ No newline at end of file
> >
> > Best regards,
> > Yu L.
> >
> >
> > On Tue, Jun 23, 2020 at 12:32 AM Lisa Li <liyu.italy at gmail.com
> > <mailto:liyu.italy at gmail.com>> wrote:
> >
> >     Great, thanks Julia!
> >
> >     Best regards,
> >      Yu L.
> >
> >     On Mon, Jun 22, 2020 at 9:56 PM Julia Boes <julia.boes at oracle.com
> >     <mailto:julia.boes at oracle.com>> wrote:
> >
> >         Hi Yu,
> >
> >>         Just to confirm, for
> >>         src/java.base/share/classes/java/util/Properties.java the
> >>         copyright should be updated as :
> >>
> >>         + * Copyright (c) 1995, 2020, Oracle and/or its affiliates.
> >>         All rights
> >>
> >>         Because 1995 was the year when the file was added, while 2020
> >>         when this change is made. Correct me if I'm wrong.
> >
> >         That's right!
> >
> >         Cheers,
> >
> >         Julia
> >
> >
>

From igor.ignatyev at oracle.com  Mon Jul 20 16:13:29 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Jul 2020 09:13:29 -0700
Subject: [15] RFR(S) : 8249700 : java/io/File/GetXSpace.java should be
 added to exclude list, and not @ignore-d
In-Reply-To: <6bb9995e-61e4-365a-997e-0b5f8fa7d55c@oracle.com>
References: <F1EBBFAD-9410-4A67-AD40-C138B884E2D4@oracle.com>
 <6bb9995e-61e4-365a-997e-0b5f8fa7d55c@oracle.com>
Message-ID: <1F0F42C7-8814-419B-894D-F94EF9159720@oracle.com>

Hi Alan,

thanks for the review, pushed to jdk15.

-- Igor

> On Jul 19, 2020, at 8:18 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 19/07/2020 05:28, Igor Ignatyev wrote:
>> :
>> the patch also includes minimal changes to make the test runnable on macosx, which reveled that the test might fail on macos. 8249703 has been filed for that issue and the appropriate changes are done in ProblemList.txt.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8249700/webrev.01/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249700
>> testing:  java/io/File/GetXSpace.java on linux-x64 100 times, 100% passed; macos-x64 100 times, 71% passed
>> 
>> PS the test is still failing on windows albeit due to the reason other than in 6501010; it seems that the test should be just updated to recognize cygwin's `df` output. I'm currently working on the fix and will send it out for review shortly.
>> 
> This looks okay to me.
> 
> -Alan


From igor.ignatyev at oracle.com  Mon Jul 20 16:13:35 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Jul 2020 09:13:35 -0700
Subject: [15] RFR(T) : 8249698 :
 java/lang/invoke/LFCaching/LFGarbageCollectedTest.java should be
 ProblemList-ed and not @ignored
In-Reply-To: <ee1085d5-af99-09f9-02ca-0fa7a79c3f33@oracle.com>
References: <61EBB792-FAF4-4DFD-A674-4BE7153F20AA@oracle.com>
 <ee1085d5-af99-09f9-02ca-0fa7a79c3f33@oracle.com>
Message-ID: <74D1782A-4AA1-44CB-98DC-BD038B263F3A@oracle.com>

Mandy, Vladimir,

thanks for your reviews, pushed to jdk15.

-- Igor

> On Jul 18, 2020, at 9:33 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> +1
> 
> Mandy
> 
> On 7/17/20 8:57 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00 <http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00>
>>> 3 lines changed: 1 ins; 1 del; 1 mod;
>> 
>> Hi all,
>> 
>> could you please review this trivial patch which removes @ignore from LFGarbageCollectedTest and adds it into problem-list instead?
>> 
>> from  8249698:
>>> java/lang/invoke/LFCaching/LFGarbageCollectedTest.java is excluded from execution due to JDK-8078602. although the test might indeed fail due to JDK-8078602, it still can be useful and isn't harmful to run, therefore this test should be put in ProblemList.txt and @ignore is to be removed.
>> from main issue(8249618):
>>> although ProblemList and @ignore achieve the same end result (test exclusion), their server different goals and have slightly different meanings, simplified @ignore should be used to exclude useless or harmful tests, and ProblemList in all other cases (see yet-not-integrated `ProblemListing or `@ignore`-ing a Test` section of dev guide, PR -- https://github.com/openjdk/guide/pull/21 <https://github.com/openjdk/guide/pull/21> for more details). 
>>> 
>>> due to different reasons, this hasn't been always followed and some currently @ignore-d tests should rather be ProblemList-ed, and some of ProblemList-ed should be @ignore-d, this issue is to clean up the current state in a hope that this will reduce further confusion. 
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00 <http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249698 <https://bugs.openjdk.java.net/browse/JDK-8249698>
>> 
>> Thanks,
>> -- Igor
>> 
>> 8078602: https://bugs.openjdk.java.net/browse/JDK-8078602 <https://bugs.openjdk.java.net/browse/JDK-8078602>
>> 8249618: https://bugs.openjdk.java.net/browse/JDK-8249618 <https://bugs.openjdk.java.net/browse/JDK-8249618>


From brian.burkhalter at oracle.com  Mon Jul 20 17:04:56 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 20 Jul 2020 10:04:56 -0700
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <7B4443ED-626F-4273-8604-336CA2E868ED@oracle.com>
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
 <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>
 <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com>
 <d91c0ac0-b8c3-2247-5d57-2f19d9c1b3f5@oracle.com>
 <D578799E-E601-4BF7-A090-4DB68630833C@oracle.com>
 <B554E700-65CD-4B2E-900C-06FA44D5AB4E@oracle.com>
 <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com>
 <575CE79A-D60C-4550-B74D-EDA1FAFBAF2F@oracle.com>
 <05887BD3-F7F1-4DA6-86EA-82929BC26874@oracle.com>
 <7B4443ED-626F-4273-8604-336CA2E868ED@oracle.com>
Message-ID: <89621E36-1F35-47FF-81AD-50BB86FF901F@oracle.com>

The CSR [2] has been approved so unless there are further comments I?ll push this change [1] this week.

Thanks,

Brian

> On Mar 19, 2020, at 7:43 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Another webrev [1] which is adjusted from the previous one per the comments on the CSR [2] is available for review. The only change is to the class-level specification:
> 
> --- a/src/java.base/share/classes/java/io/LineNumberReader.java
> +++ b/src/java.base/share/classes/java/io/LineNumberReader.java
> @@ -41,7 +41,8 @@
>   *
>   * <p> A line is considered to be <a id="lt">terminated</a> by any one of a
>   * line feed ('\n'), a carriage return ('\r'), or a carriage return followed
> - * immediately by a linefeed.
> + * immediately by a linefeed, or any of the previous terminators followed by
> + * end of stream, or end of stream not preceded by another terminator.
>   *
> 
> Thanks,
> 
> Brian
> 
>> On Mar 13, 2020, at 10:28 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>> 
>> An updated webrev is at [1] and a CSR has been filed [2].

[1] http://cr.openjdk.java.net/~bpb/8235792/webrev.02/
[2] https://bugs.openjdk.java.net/browse/JDK-8241020


From brian.burkhalter at oracle.com  Mon Jul 20 17:06:13 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 20 Jul 2020 10:06:13 -0700
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <89621E36-1F35-47FF-81AD-50BB86FF901F@oracle.com>
References: <5C2BE0DF-C35D-4FF3-82E1-CB179809D349@oracle.com>
 <6e5eb999-cbae-1446-bd81-c470cb3f13c1@oracle.com>
 <14E6EF7F-C01F-4407-B865-32089266DC28@oracle.com>
 <d91c0ac0-b8c3-2247-5d57-2f19d9c1b3f5@oracle.com>
 <D578799E-E601-4BF7-A090-4DB68630833C@oracle.com>
 <B554E700-65CD-4B2E-900C-06FA44D5AB4E@oracle.com>
 <665e81fc-5136-2cf6-748b-6c6f448cfc16@oracle.com>
 <575CE79A-D60C-4550-B74D-EDA1FAFBAF2F@oracle.com>
 <05887BD3-F7F1-4DA6-86EA-82929BC26874@oracle.com>
 <7B4443ED-626F-4273-8604-336CA2E868ED@oracle.com>
 <89621E36-1F35-47FF-81AD-50BB86FF901F@oracle.com>
Message-ID: <EF12D244-95BC-48C9-9C18-97C6FDB2B0B3@oracle.com>

Push to JDK 16 that is.

> On Jul 20, 2020, at 10:04 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> The CSR [2] has been approved so unless there are further comments I?ll push this change [1] this week.
> 
> Thanks,
> 
> Brian
> 
>> On Mar 19, 2020, at 7:43 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>> 
>> Another webrev [1] which is adjusted from the previous one per the comments on the CSR [2] is available for review. The only change is to the class-level specification:
>> 
>> --- a/src/java.base/share/classes/java/io/LineNumberReader.java
>> +++ b/src/java.base/share/classes/java/io/LineNumberReader.java
>> @@ -41,7 +41,8 @@
>>  *
>>  * <p> A line is considered to be <a id="lt">terminated</a> by any one of a
>>  * line feed ('\n'), a carriage return ('\r'), or a carriage return followed
>> - * immediately by a linefeed.
>> + * immediately by a linefeed, or any of the previous terminators followed by
>> + * end of stream, or end of stream not preceded by another terminator.
>>  *
>> 
>> Thanks,
>> 
>> Brian
>> 
>>> On Mar 13, 2020, at 10:28 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>>> 
>>> An updated webrev is at [1] and a CSR has been filed [2].
> 
> [1] http://cr.openjdk.java.net/~bpb/8235792/webrev.02/
> [2] https://bugs.openjdk.java.net/browse/JDK-8241020
> 


From igor.ignatyev at oracle.com  Mon Jul 20 17:13:34 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Jul 2020 10:13:34 -0700
Subject: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should
 use @requires instead of @ignore
In-Reply-To: <60806519-8e57-d126-8a2e-800053b4ee9a@oracle.com>
References: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>
 <60806519-8e57-d126-8a2e-800053b4ee9a@oracle.com>
Message-ID: <956AE2D8-1D95-4357-9DBD-9A9D5ABF9CD1@oracle.com>

Hi Mandy,

that's actually the opposite, the 2nd subtest is run only in modes other than Xcomp, as w/ Xcomp the test creates lots of adapters and used to lead to JVM failure as described in 7049122. I tried to reproduce this failure, but in vain,..  after a bit more historical digging, I realized that the underlying problem was 7009641, which has been fixed in hs25/jdk8. so I've changed the fix for 8249697 to simply return run w/ '-DRicochetTest.MAX_ARITY=255': http://cr.openjdk.java.net/~iignatyev//8249697/webrev.02

I've verified that the test passes w/ Xcomp and 
 - -XX:+TieredCompilation (c1 + c2);
 - -XX:-TieredCompilation (c2-only);
 - -XX:+NeverActAsServerClassMachine (emulated-client, c1-only)

the test was run 100 times on {linux,windows,macos}-x64 w/ 0 failures.
 
Thanks,
-- Igor

> On Jul 18, 2020, at 9:32 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 7/17/20 8:54 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/>
>> 
> 
> I suggest to change this:
>   32  * @comment The following test creates an unreasonable number of adapters in -Xcomp mode (7049122)
> 
> To:
> 
>    @bug 8249697
>    @summary verify very high number of adapters in -Xcomp mode
> 
> Otherwise, looks fine.
> 
> Mandy
>> Hi all,
>> 
>> could you please review this small and trivial patch for java/lang/invoke/RicochetTest.java test?
>> from JBS:
>>> a run of java/lang/invoke/RicochetTest.java w/ MAX_ARITY=255 was removed from all configurations by JDK-7049122, yet the problem manifests itself only w/ Xcomp. as now we have @requires to filter out tests from certain configurations, the test can be updated to run MAX_ARITY=255 in all configs but Xcomp.
>> the patch splits the test into two subtests, each one w/ one @run, and use @requires to exclude one w/ MAX_ARITY=255 from execution if Xcomp flag is used.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249697 <https://bugs.openjdk.java.net/browse/JDK-8249697>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/>
>> testing: java/lang/invoke/RicochetTest.java on {linux,windows,macos}-x64 w/ and w/o -Xcomp; Xcomp runs, as expected, had only 1 test run
>> 
>> Thanks,
>> -- Igor
>> 
>> JDK-7049122 : https://bugs.openjdk.java.net/browse/JDK-7049122 <https://bugs.openjdk.java.net/browse/JDK-7049122>


From andy.herrick at oracle.com  Mon Jul 20 18:02:22 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 20 Jul 2020 14:02:22 -0400
Subject: Standardizing JEP 343 with draft of new JEP - JDK-8247768: Packaging
 Tool (Standard)
Message-ID: <8e28c857-d991-be84-18c0-f69ab7d2b55e@oracle.com>

The jpackage tool described in JEP 343 
(https://bugs.openjdk.java.net/browse/JDK-8200758) 
<https://bugs.openjdk.java.net/browse/JDK-8200758>.

This was delivered as an incubating tool in JDK 14, and again in JDK 15 
to allow more time for feedback.

At this time we have received and incorporated such feedback, would like 
to standardize this tool.

To that end we intend to submit: JDK-8247768: Packaging Tool (Standard) 
(https://bugs.openjdk.java.net/browse/JDK-8247768).

Please review and send feedback to core-libs-dev at openjdk.java.net.

/Andy


From huizhe.wang at oracle.com  Mon Jul 20 18:20:36 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 20 Jul 2020 11:20:36 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
Message-ID: <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>

Hi Naoto,

StringUTF16: line 384 - 388 seem unnecessary since you'd only get there 
if 389:isHighSurrogate is not true. But more importantly, StringUTF16 
has existing method "codePointAt" you may want to consider instead of 
adding a new method.

Comparing to the base benchmark:
StringCompareToIgnoreCase.lower????????? 8.5%
StringCompareToIgnoreCase.supLower????? 139%
StringCompareToIgnoreCase.supUpperLower? -21.8%
StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%


"lower" was 8.5% slower, if such test exists in the specJVM, it would be 
considered a regression. I would suggest you run the specJVM. I agree 
with you on surrogate check being a requirement, thus supLower being 
139% slower is ok since it won't otherwise be correct anyways. But after 
introducing additional operations supUpperLower and upperLower ran 
faster? That may indicate irregularity in the tests. Maybe we should 
consider running tests with short, long and very long sample strings to 
see if we can reduce the noise level and also see how it fares for a 
longer string. I assume the machine you're running the test on was isolated.

Regards,
Joe

On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
> Hi Mark,
>
> Thank you for your comments.
>
> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>> One option is to have a fast path that uses char functions, up to the 
>> point where you hit a high surrogate, then drop into the slower 
>> codepoint path. That saves time for the high-runner cases.
>>
>> On the other hand, if the times are good enough, you might not need 
>> the complication.
>
> The implementation is dealing with bare byte arrays. Only methods that 
> it uses from Character class are toLowerCase(int) and toUpperCase(int) 
> (sans surrogate check, which is needed at each iteration anyways), and 
> their "char" equivalents are merely casting (char) to the int result. 
> So it might not be so beneficial to differentiate char and int paths.
>
> Having said that, I found that there was an unnecessary surrogate 
> check (always checks high *and* low surrogate on each iteration), so I 
> revised the fix (added line 380-383 in StringUTF16.java):
>
> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>
> Naoto
>
>>
>> Mark
>> //////
>>
>>
>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com>> wrote:
>>
>> ??? Hi,
>>
>> ??? Based on the suggestions, I modified the fix as follows:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>
>> ??? Changes from the initial revision are:
>>
>> ??? - Shared the implementation between compareToCI() and 
>> regionMatchesCI()
>> ??? - Enabled immediate short cut if two code points match.
>> ??? - Created a simple JMH benchmark. Here is the scores before and 
>> after
>> ??? the change:
>>
>> ??? before:
>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score ?Error 
>> ??? Units
>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 53.764 ? 
>> 2.811 ??? ns/op
>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 24.211 ? 
>> 1.135 ??? ns/op
>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 30.595 ? 
>> 1.344 ??? ns/op
>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 18.859 ? 
>> 1.499 ??? ns/op
>>
>> ??? after:
>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score ?Error 
>> ??? Units
>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 58.354 ? 
>> 4.603 ??? ns/op
>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 57.975 ? 
>> 5.672 ??? ns/op
>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 23.912 ? 
>> 0.965 ??? ns/op
>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 17.744 ? 
>> 0.272 ??? ns/op
>>
>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>> "lower"
>> ??? means each character requires upper->lower casemap. "upperLower" 
>> means
>> ??? all characters are the same, except the last character which 
>> requires
>> ??? casemap.
>>
>> ??? I think the result is reasonable, considering surrogates check 
>> are now
>> ??? mandatory. I have tried Roger's suggestion to use 
>> Arrays.mismatch() but
>> ??? it did not seem to benefit here. In fact, the performance degraded
>> ??? partly because I implemented the short cut, and possibly for the
>> ??? overhead of extra checks.
>>
>> ??? Naoto
>>
>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>> ??? <mailto:naoto.sato at oracle.com> wrote:
>> ???? > Hello,
>> ???? >
>> ???? > Please review the fix to the following issues:
>> ???? >
>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>> ???? >
>> ???? > The proposed changeset and its CSR are located at:
>> ???? >
>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>> ???? >
>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>> ???? > case-insensitive date format/parse failed in some of the new
>> ??? locales in
>> ???? > JDK15. The root cause was that case-insensitive
>> ??? String.regionMatches()
>> ???? > method did not work with supplementary characters. The problem is
>> ??? that
>> ???? > the method's spec does not expect case mappings of supplementary
>> ???? > characters, possibly because it was overlooked in the first
>> ??? place, JSR
>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>> behavior is
>> ???? > observed in other two case-insensitive methods, i.e.,
>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>> ???? >
>> ???? > The fix is straightforward to compare strings by code point 
>> basis,
>> ???? > instead of code unit (16bit "char") basis. Technically this
>> ??? change will
>> ???? > introduce a backward incompatibility, but I believe it is an
>> ???? > incompatibility to wrong behavior, not true to the meaning of 
>> those
>> ???? > methods' expectations.
>> ???? >
>> ???? > Naoto
>>


From igor.ignatyev at oracle.com  Mon Jul 20 18:28:15 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Jul 2020 11:28:15 -0700
Subject: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on
 Windows
Message-ID: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>

http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00
> 98 lines changed: 18 ins; 31 del; 49 mod;

Hi all,

could you please review this small fix to make java/io/File/GetXSpace.java work again on windows?

the test has been updated to work under cygwin, which includes the following changes:
 - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
 - uses the same regexp to parse df on windows as on other platforms
 - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is corresponding windows path, and the test expect Space's name to be appropriate path

the patch also includes some small faceliftings:
 - printing out a bit more information to facilitate failure analyses, e.g. df output, exception stack traces
 - usage of try-w/-resources
 - remove of code duplication
 - usage of generics

webrev: http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00
testing: java/io/File/GetXSpace.java 100 times on {linux,windows}-x64
JBS: https://bugs.openjdk.java.net/browse/JDK-6501010

Thanks,
-- Igor

From mandy.chung at oracle.com  Mon Jul 20 18:57:09 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Jul 2020 11:57:09 -0700
Subject: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should
 use @requires instead of @ignore
In-Reply-To: <956AE2D8-1D95-4357-9DBD-9A9D5ABF9CD1@oracle.com>
References: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>
 <60806519-8e57-d126-8a2e-800053b4ee9a@oracle.com>
 <956AE2D8-1D95-4357-9DBD-9A9D5ABF9CD1@oracle.com>
Message-ID: <9f5959b8-f9ff-9962-77f7-7807b247ae90@oracle.com>

Hi Igor,

OK.? Should this revert the change by 7049122 then? i.e. simply change 
-DRicochetTest.MAX_ARITY=10 to 255

Your proposed patch adds a new @run instead of modifying the existing 
@run command:

 ? * @run junit/othervm/timeout=3600 -XX:+IgnoreUnrecognizedVMOptions 
-XX:-VerifyDependencies -DRicochetTest.MAX_ARITY=10 
test.java.lang.invoke.RicochetTest

I looked at the history and this @run was modified by JDK-7197210 that 
adds -XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies options 
and reduce MAX_ARITY from 50 to 10.

This issue is not critical to target for 15.? It may worth considering 
target this test fix for 16.? Just a suggestion.

Mandy

On 7/20/20 10:13 AM, Igor Ignatyev wrote:
> Hi Mandy,
>
> that's actually the opposite, the 2nd subtest is run only in modes 
> other than Xcomp, as w/ Xcomp the test creates lots of adapters and 
> used to lead to JVM failure as described in?7049122. I tried to 
> reproduce this failure, but in vain,.. ?after a bit more historical 
> digging, I realized that the underlying problem was?7009641, which has 
> been fixed in hs25/jdk8. so I've changed the fix for?8249697 to simply 
> return run w/ '-DRicochetTest.MAX_ARITY=255': 
> http://cr.openjdk.java.net/~iignatyev//8249697/webrev.02
>
> I've verified that the test passes w/ Xcomp and
> ?- -XX:+TieredCompilation (c1 + c2);
> ?-?-XX:-TieredCompilation?(c2-only);
> ?- -XX:+NeverActAsServerClassMachine (emulated-client, c1-only)
>
> the test was run 100 times on {linux,windows,macos}-x64 w/ 0 failures.
> Thanks,
> -- Igor
>
>> On Jul 18, 2020, at 9:32 PM, Mandy Chung <mandy.chung at oracle.com 
>> <mailto:mandy.chung at oracle.com>> wrote:
>>
>>
>>
>> On 7/17/20 8:54 PM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
>>>
>>
>> I suggest to change this:
>> ? 32? * @comment The following test creates an unreasonable number of 
>> adapters in -Xcomp mode (7049122)
>>
>> To:
>>
>> ?? @bug 8249697
>> ?? @summary verify very high number of adapters in -Xcomp mode
>>
>> Otherwise, looks fine.
>>
>> Mandy
>>> Hi all,
>>>
>>> could you please review this small and trivial patch for java/lang/invoke/RicochetTest.java test?
>>> from JBS:
>>>> a run of java/lang/invoke/RicochetTest.java w/ MAX_ARITY=255 was removed from all configurations by JDK-7049122, yet the problem manifests itself only w/ Xcomp. as now we have @requires to filter out tests from certain configurations, the test can be updated to run MAX_ARITY=255 in all configs but Xcomp.
>>> the patch splits the test into two subtests, each one w/ one @run, and use @requires to exclude one w/ MAX_ARITY=255 from execution if Xcomp flag is used.
>>>
>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8249697
>>> webrev:http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
>>> testing: java/lang/invoke/RicochetTest.java on {linux,windows,macos}-x64 w/ and w/o -Xcomp; Xcomp runs, as expected, had only 1 test run
>>>
>>> Thanks,
>>> -- Igor
>>>
>>> JDK-7049122 :https://bugs.openjdk.java.net/browse/JDK-7049122
>>
>


From igor.ignatyev at oracle.com  Mon Jul 20 19:22:05 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Jul 2020 12:22:05 -0700
Subject: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should
 use @requires instead of @ignore
In-Reply-To: <9f5959b8-f9ff-9962-77f7-7807b247ae90@oracle.com>
References: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>
 <60806519-8e57-d126-8a2e-800053b4ee9a@oracle.com>
 <956AE2D8-1D95-4357-9DBD-9A9D5ABF9CD1@oracle.com>
 <9f5959b8-f9ff-9962-77f7-7807b247ae90@oracle.com>
Message-ID: <3BD624C3-D3B7-4306-959A-1062CA34DF64@oracle.com>

Hi Mandy,

you are right, it's better to have just one @run, and as I don't think that 7197210 changes '-XX:-VerifyDependencies' nor '/timeout=3600' are needed anymore, I suggest to restore the test to its original version w/  `@run junit/othervm -DRicochetTest.MAX_ARITY=255 test.java.lang.invoke.RicochetTest`, so the patch (http://cr.openjdk.java.net/~iignatyev//8249697/webrev.03) would be just:

> -/* @test
> +/*
> + * @test
>   * @summary unit tests for recursive method handles
> - * @run junit/othervm/timeout=3600 -XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies -DRicochetTest.MAX_ARITY=10 test.java.lang.invoke.RicochetTest
> - */
> -/*
> - * @ignore The following test creates an unreasonable number of adapters in -Xcomp mode (7049122)
>   * @run junit/othervm -DRicochetTest.MAX_ARITY=255 test.java.lang.invoke.RicochetTest
>   */


and then the bug's summary would be smth like 'remove temporary fixes from java/lang/invoke/RicochetTest.java' .

sure there is no reason for it to be pushed into 15, I've retargeted to 16.

-- Igor

> On Jul 20, 2020, at 11:57 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Igor,
> 
> OK.  Should this revert the change by 7049122 then? i.e. simply change -DRicochetTest.MAX_ARITY=10 to 255
> 
> Your proposed patch adds a new @run instead of modifying the existing @run command:
> 
>   * @run junit/othervm/timeout=3600 -XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies -DRicochetTest.MAX_ARITY=10 test.java.lang.invoke.RicochetTest
> 
> I looked at the history and this @run was modified by JDK-7197210 that adds -XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies options and reduce MAX_ARITY from 50 to 10.
> 
> This issue is not critical to target for 15.  It may worth considering target this test fix for 16.  Just a suggestion.
> 
> Mandy
> 
> On 7/20/20 10:13 AM, Igor Ignatyev wrote:
>> Hi Mandy,
>> 
>> that's actually the opposite, the 2nd subtest is run only in modes other than Xcomp, as w/ Xcomp the test creates lots of adapters and used to lead to JVM failure as described in 7049122. I tried to reproduce this failure, but in vain,..  after a bit more historical digging, I realized that the underlying problem was 7009641, which has been fixed in hs25/jdk8. so I've changed the fix for 8249697 to simply return run w/ '-DRicochetTest.MAX_ARITY=255': http://cr.openjdk.java.net/~iignatyev//8249697/webrev.02 <http://cr.openjdk.java.net/~iignatyev//8249697/webrev.02>
>> 
>> I've verified that the test passes w/ Xcomp and 
>>  - -XX:+TieredCompilation (c1 + c2);
>>  - -XX:-TieredCompilation (c2-only);
>>  - -XX:+NeverActAsServerClassMachine (emulated-client, c1-only)
>> 
>> the test was run 100 times on {linux,windows,macos}-x64 w/ 0 failures.
>>  
>> Thanks,
>> -- Igor
>> 
>>> On Jul 18, 2020, at 9:32 PM, Mandy Chung <mandy.chung at oracle.com <mailto:mandy.chung at oracle.com>> wrote:
>>> 
>>> 
>>> 
>>> On 7/17/20 8:54 PM, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/>
>>>> 
>>> 
>>> I suggest to change this:
>>>   32  * @comment The following test creates an unreasonable number of adapters in -Xcomp mode (7049122)
>>> 
>>> To:
>>> 
>>>    @bug 8249697
>>>    @summary verify very high number of adapters in -Xcomp mode
>>> 
>>> Otherwise, looks fine.
>>> 
>>> Mandy
>>>> Hi all,
>>>> 
>>>> could you please review this small and trivial patch for java/lang/invoke/RicochetTest.java test?
>>>> from JBS:
>>>>> a run of java/lang/invoke/RicochetTest.java w/ MAX_ARITY=255 was removed from all configurations by JDK-7049122, yet the problem manifests itself only w/ Xcomp. as now we have @requires to filter out tests from certain configurations, the test can be updated to run MAX_ARITY=255 in all configs but Xcomp.
>>>> the patch splits the test into two subtests, each one w/ one @run, and use @requires to exclude one w/ MAX_ARITY=255 from execution if Xcomp flag is used.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249697 <https://bugs.openjdk.java.net/browse/JDK-8249697>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/ <http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/>
>>>> testing: java/lang/invoke/RicochetTest.java on {linux,windows,macos}-x64 w/ and w/o -Xcomp; Xcomp runs, as expected, had only 1 test run
>>>> 
>>>> Thanks,
>>>> -- Igor
>>>> 
>>>> JDK-7049122 : https://bugs.openjdk.java.net/browse/JDK-7049122 <https://bugs.openjdk.java.net/browse/JDK-7049122>
>> 
> 


From daniel.fuchs at oracle.com  Mon Jul 20 19:25:24 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 20 Jul 2020 20:25:24 +0100
Subject: 8249774: Add java/foreign/TestMismatch.java to ProblemList.txt
Message-ID: <5d8997a8-261a-873b-465e-9c75521c8a53@oracle.com>

Hi,

Please find below a fix for:

8249774: Add java/foreign/TestMismatch.java to ProblemList.txt
https://bugs.openjdk.java.net/browse/JDK-8249774

The test has failed twice in timeout on macOS in the tier1 CI.
Requesting to put it into a problem list until a fix is proposed.


best regards,

-- daniel

patch:
----------------------------------------------------------------------------


diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -559,6 +559,12 @@

 
############################################################################

+# jdk_foreign
+
+java/foreign/TestMismatch.java 8249684 macosx-all
+
+############################################################################
+
  # jdk_lang

  java/lang/StringCoding/CheckEncodings.sh 
7008363 generic-all

From LANCE.ANDERSEN at ORACLE.COM  Mon Jul 20 19:27:12 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Mon, 20 Jul 2020 15:27:12 -0400
Subject: 8249774: Add java/foreign/TestMismatch.java to ProblemList.txt
In-Reply-To: <5d8997a8-261a-873b-465e-9c75521c8a53@oracle.com>
References: <5d8997a8-261a-873b-465e-9c75521c8a53@oracle.com>
Message-ID: <EC4E8164-2573-48FA-9D7A-7993D5CC65E0@ORACLE.COM>

+1

> On Jul 20, 2020, at 3:25 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8249774: Add java/foreign/TestMismatch.java to ProblemList.txt
> https://bugs.openjdk.java.net/browse/JDK-8249774
> 
> The test has failed twice in timeout on macOS in the tier1 CI.
> Requesting to put it into a problem list until a fix is proposed.
> 
> 
> best regards,
> 
> -- daniel
> 
> patch:
> ----------------------------------------------------------------------------
> 
> 
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -559,6 +559,12 @@
> 
> ############################################################################
> 
> +# jdk_foreign
> +
> +java/foreign/TestMismatch.java 8249684 macosx-all
> +
> +############################################################################
> +
> # jdk_lang
> 
> java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From mandy.chung at oracle.com  Mon Jul 20 19:44:02 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Jul 2020 12:44:02 -0700
Subject: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should
 use @requires instead of @ignore
In-Reply-To: <3BD624C3-D3B7-4306-959A-1062CA34DF64@oracle.com>
References: <054E0326-B61C-40FA-A8E3-89C433A49EE3@oracle.com>
 <60806519-8e57-d126-8a2e-800053b4ee9a@oracle.com>
 <956AE2D8-1D95-4357-9DBD-9A9D5ABF9CD1@oracle.com>
 <9f5959b8-f9ff-9962-77f7-7807b247ae90@oracle.com>
 <3BD624C3-D3B7-4306-959A-1062CA34DF64@oracle.com>
Message-ID: <1ceb03d9-5f15-22ed-286e-881dfa751c06@oracle.com>

webrev.03 looks good.

Mandy

On 7/20/20 12:22 PM, Igor Ignatyev wrote:
> Hi Mandy,
>
> you are right, it's better to have just one @run, and as I don't think 
> that 7197210 changes '-XX:-VerifyDependencies' nor '/timeout=3600' are 
> needed anymore, I suggest to restore the test to its original version 
> w/ ?`@run junit/othervm -DRicochetTest.MAX_ARITY=255 
> test.java.lang.invoke.RicochetTest`, so the patch 
> (http://cr.openjdk.java.net/~iignatyev//8249697/webrev.03) would be just:
>
>> -/* @test
>> +/*
>> + * @test
>> ??* @summary unit tests for recursive method handles
>> - * @run junit/othervm/timeout=3600 -XX:+IgnoreUnrecognizedVMOptions 
>> -XX:-VerifyDependencies -DRicochetTest.MAX_ARITY=10 
>> test.java.lang.invoke.RicochetTest
>> - */
>> -/*
>> - * @ignore The following test creates an unreasonable number of 
>> adapters in -Xcomp mode (7049122)
>> ??* @run junit/othervm -DRicochetTest.MAX_ARITY=255 
>> test.java.lang.invoke.RicochetTest
>> ??*/
>
> and then the bug's summary would be smth like 'remove temporary fixes 
> from?java/lang/invoke/RicochetTest.java' .
>
> sure there is no reason for it to be pushed into 15, I've retargeted 
> to 16.
>
> -- Igor
>
>> On Jul 20, 2020, at 11:57 AM, Mandy Chung <mandy.chung at oracle.com 
>> <mailto:mandy.chung at oracle.com>> wrote:
>>
>> Hi Igor,
>>
>> OK.? Should this revert the change by 7049122 then? i.e. simply 
>> change -DRicochetTest.MAX_ARITY=10 to 255
>>
>> Your proposed patch adds a new @run instead of modifying the existing 
>> @run command:
>>
>> ? * @run junit/othervm/timeout=3600 -XX:+IgnoreUnrecognizedVMOptions 
>> -XX:-VerifyDependencies -DRicochetTest.MAX_ARITY=10 
>> test.java.lang.invoke.RicochetTest
>>
>> I looked at the history and this @run was modified by JDK-7197210 
>> that adds -XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies 
>> options and reduce MAX_ARITY from 50 to 10.
>>
>> This issue is not critical to target for 15.? It may worth 
>> considering target this test fix for 16.? Just a suggestion.
>>
>> Mandy
>>
>> On 7/20/20 10:13 AM, Igor Ignatyev wrote:
>>> Hi Mandy,
>>>
>>> that's actually the opposite, the 2nd subtest is run only in modes 
>>> other than Xcomp, as w/ Xcomp the test creates lots of adapters and 
>>> used to lead to JVM failure as described in?7049122. I tried to 
>>> reproduce this failure, but in vain,.. ?after a bit more historical 
>>> digging, I realized that the underlying problem was?7009641, which 
>>> has been fixed in hs25/jdk8. so I've changed the fix for?8249697 to 
>>> simply return run w/ '-DRicochetTest.MAX_ARITY=255': 
>>> http://cr.openjdk.java.net/~iignatyev//8249697/webrev.02
>>>
>>> I've verified that the test passes w/ Xcomp and
>>> ?- -XX:+TieredCompilation (c1 + c2);
>>> ?-?-XX:-TieredCompilation?(c2-only);
>>> ?- -XX:+NeverActAsServerClassMachine (emulated-client, c1-only)
>>>
>>> the test was run 100 times on {linux,windows,macos}-x64 w/ 0 failures.
>>> Thanks,
>>> -- Igor
>>>
>>>> On Jul 18, 2020, at 9:32 PM, Mandy Chung <mandy.chung at oracle.com 
>>>> <mailto:mandy.chung at oracle.com>> wrote:
>>>>
>>>>
>>>>
>>>> On 7/17/20 8:54 PM, Igor Ignatyev wrote:
>>>>> http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
>>>>>
>>>>
>>>> I suggest to change this:
>>>> ? 32? * @comment The following test creates an unreasonable number 
>>>> of adapters in -Xcomp mode (7049122)
>>>>
>>>> To:
>>>>
>>>> ?? @bug 8249697
>>>> ?? @summary verify very high number of adapters in -Xcomp mode
>>>>
>>>> Otherwise, looks fine.
>>>>
>>>> Mandy
>>>>> Hi all,
>>>>>
>>>>> could you please review this small and trivial patch for java/lang/invoke/RicochetTest.java test?
>>>>> from JBS:
>>>>>> a run of java/lang/invoke/RicochetTest.java w/ MAX_ARITY=255 was removed from all configurations by JDK-7049122, yet the problem manifests itself only w/ Xcomp. as now we have @requires to filter out tests from certain configurations, the test can be updated to run MAX_ARITY=255 in all configs but Xcomp.
>>>>> the patch splits the test into two subtests, each one w/ one @run, and use @requires to exclude one w/ MAX_ARITY=255 from execution if Xcomp flag is used.
>>>>>
>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8249697
>>>>> webrev:http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/
>>>>> testing: java/lang/invoke/RicochetTest.java on {linux,windows,macos}-x64 w/ and w/o -Xcomp; Xcomp runs, as expected, had only 1 test run
>>>>>
>>>>> Thanks,
>>>>> -- Igor
>>>>>
>>>>> JDK-7049122 :https://bugs.openjdk.java.net/browse/JDK-7049122
>>>>
>>>
>>
>


From alexander.matveev at oracle.com  Mon Jul 20 20:43:47 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Mon, 20 Jul 2020 13:43:47 -0700
Subject: 8248248: [macos] EmptyFolderPackageTest.java fails
 EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code
Message-ID: <00f2df8d-e1d5-df11-18fe-a86cf88f7699@oracle.com>

Please review the jpackage fix for bug [1] at [2].

It is not clear why script was hanging for more than 7 minutes which 
caused test to timeout. Fixed by limiting script execution time to 3 
minutes. Also, EmptyFolderPackageTest was removed from ProblemList.

[1] https://bugs.openjdk.java.net/browse/JDK-8248248
[2] http://cr.openjdk.java.net/~almatvee/8248248/webrev.00/

Thanks,
Alexander

From alexey.semenyuk at oracle.com  Mon Jul 20 20:49:28 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 20 Jul 2020 16:49:28 -0400
Subject: 8248248: [macos] EmptyFolderPackageTest.java fails
 EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code
In-Reply-To: <00f2df8d-e1d5-df11-18fe-a86cf88f7699@oracle.com>
References: <00f2df8d-e1d5-df11-18fe-a86cf88f7699@oracle.com>
Message-ID: <7efc8d94-f7d8-9761-1413-cd4f0dd0a47c@oracle.com>

Looks good.

Minor suggestion: introduce a constant for infinite timeout and use it 
instead of "-1".

- Alexey

On 7/20/2020 4:43 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> It is not clear why script was hanging for more than 7 minutes which 
> caused test to timeout. Fixed by limiting script execution time to 3 
> minutes. Also, EmptyFolderPackageTest was removed from ProblemList.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8248248
> [2] http://cr.openjdk.java.net/~almatvee/8248248/webrev.00/
>
> Thanks,
> Alexander


From naoto.sato at oracle.com  Mon Jul 20 21:39:09 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 20 Jul 2020 14:39:09 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
Message-ID: <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>

Hi Joe,

Thank you for your comments.

On 7/20/20 11:20 AM, Joe Wang wrote:
> Hi Naoto,
> 
> StringUTF16: line 384 - 388 seem unnecessary since you'd only get there 
> if 389:isHighSurrogate is not true. 

Good point.

But more importantly, StringUTF16
> has existing method "codePointAt" you may want to consider instead of 
> adding a new method.

If we call codePointAt/Before, it would call an extra getChar(). Since 
we know one codepoint as an input, I would avoid the extra calls.

> 
> Comparing to the base benchmark:
> StringCompareToIgnoreCase.lower????????? 8.5%
> StringCompareToIgnoreCase.supLower????? 139%
> StringCompareToIgnoreCase.supUpperLower? -21.8%
> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
> 
> 
> "lower" was 8.5% slower, if such test exists in the specJVM, it would be 
> considered a regression. I would suggest you run the specJVM. I agree 
> with you on surrogate check being a requirement, thus supLower being 
> 139% slower is ok since it won't otherwise be correct anyways.

Yes, it would be a regression if SPECjvm produces 8+% degradation, but 
the test suite is aimed at the entire application performance. But for 
this one, it is a micro benchmark for relatively rarely issued methods 
(I would think normal cases fall into Latin1 equivalents), I would 
consider it is acceptable.

> But after 
> introducing additional operations supUpperLower and upperLower ran 
> faster? That may indicate irregularity in the tests. Maybe we should 
> consider running tests with short, long and very long sample strings to 
> see if we can reduce the noise level and also see how it fares for a 
> longer string. I assume the machine you're running the test on was 
> isolated.

This result pretty much depends on the data it is testing for. As I 
wrote in the previous email, (sup)UpperLower tests use the data that are 
almost identical, but one last character is case insensitively equal. So 
in these cases, the new short cut works really well and not call 
toLower/UpperCase() at all for most of the characters. Thus the new 
results are faster. Again the test result is very dependent on the input 
data, Unless the result showed 100% slower or something (except supLower 
case), I think it is OK.

Anyways, here is the updated webrev addressing your first suggestion:

http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/

Naoto

> 
> Regards,
> Joe
> 
> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>> Hi Mark,
>>
>> Thank you for your comments.
>>
>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>> One option is to have a fast path that uses char functions, up to the 
>>> point where you hit a high surrogate, then drop into the slower 
>>> codepoint path. That saves time for the high-runner cases.
>>>
>>> On the other hand, if the times are good enough, you might not need 
>>> the complication.
>>
>> The implementation is dealing with bare byte arrays. Only methods that 
>> it uses from Character class are toLowerCase(int) and toUpperCase(int) 
>> (sans surrogate check, which is needed at each iteration anyways), and 
>> their "char" equivalents are merely casting (char) to the int result. 
>> So it might not be so beneficial to differentiate char and int paths.
>>
>> Having said that, I found that there was an unnecessary surrogate 
>> check (always checks high *and* low surrogate on each iteration), so I 
>> revised the fix (added line 380-383 in StringUTF16.java):
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>
>> Naoto
>>
>>>
>>> Mark
>>> //////
>>>
>>>
>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>
>>> ??? Hi,
>>>
>>> ??? Based on the suggestions, I modified the fix as follows:
>>>
>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>
>>> ??? Changes from the initial revision are:
>>>
>>> ??? - Shared the implementation between compareToCI() and 
>>> regionMatchesCI()
>>> ??? - Enabled immediate short cut if two code points match.
>>> ??? - Created a simple JMH benchmark. Here is the scores before and 
>>> after
>>> ??? the change:
>>>
>>> ??? before:
>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score ?Error 
>>> ??? Units
>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 53.764 ? 
>>> 2.811 ??? ns/op
>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 24.211 ? 
>>> 1.135 ??? ns/op
>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 30.595 ? 
>>> 1.344 ??? ns/op
>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 18.859 ? 
>>> 1.499 ??? ns/op
>>>
>>> ??? after:
>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score ?Error 
>>> ??? Units
>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 58.354 ? 
>>> 4.603 ??? ns/op
>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 57.975 ? 
>>> 5.672 ??? ns/op
>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 23.912 ? 
>>> 0.965 ??? ns/op
>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 17.744 ? 
>>> 0.272 ??? ns/op
>>>
>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>> "lower"
>>> ??? means each character requires upper->lower casemap. "upperLower" 
>>> means
>>> ??? all characters are the same, except the last character which 
>>> requires
>>> ??? casemap.
>>>
>>> ??? I think the result is reasonable, considering surrogates check 
>>> are now
>>> ??? mandatory. I have tried Roger's suggestion to use 
>>> Arrays.mismatch() but
>>> ??? it did not seem to benefit here. In fact, the performance degraded
>>> ??? partly because I implemented the short cut, and possibly for the
>>> ??? overhead of extra checks.
>>>
>>> ??? Naoto
>>>
>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>> ???? > Hello,
>>> ???? >
>>> ???? > Please review the fix to the following issues:
>>> ???? >
>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>> ???? >
>>> ???? > The proposed changeset and its CSR are located at:
>>> ???? >
>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>> ???? >
>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>> ???? > case-insensitive date format/parse failed in some of the new
>>> ??? locales in
>>> ???? > JDK15. The root cause was that case-insensitive
>>> ??? String.regionMatches()
>>> ???? > method did not work with supplementary characters. The problem is
>>> ??? that
>>> ???? > the method's spec does not expect case mappings of supplementary
>>> ???? > characters, possibly because it was overlooked in the first
>>> ??? place, JSR
>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>> behavior is
>>> ???? > observed in other two case-insensitive methods, i.e.,
>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>> ???? >
>>> ???? > The fix is straightforward to compare strings by code point 
>>> basis,
>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>> ??? change will
>>> ???? > introduce a backward incompatibility, but I believe it is an
>>> ???? > incompatibility to wrong behavior, not true to the meaning of 
>>> those
>>> ???? > methods' expectations.
>>> ???? >
>>> ???? > Naoto
>>>
> 

From naoto.sato at oracle.com  Mon Jul 20 22:20:18 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 20 Jul 2020 15:20:18 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
Message-ID: <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>

Small correction in the updated part:

http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/

Naoto

On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
> 
> Thank you for your comments.
> 
> On 7/20/20 11:20 AM, Joe Wang wrote:
>> Hi Naoto,
>>
>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>> there if 389:isHighSurrogate is not true. 
> 
> Good point.
> 
> But more importantly, StringUTF16
>> has existing method "codePointAt" you may want to consider instead of 
>> adding a new method.
> 
> If we call codePointAt/Before, it would call an extra getChar(). Since 
> we know one codepoint as an input, I would avoid the extra calls.
> 
>>
>> Comparing to the base benchmark:
>> StringCompareToIgnoreCase.lower????????? 8.5%
>> StringCompareToIgnoreCase.supLower????? 139%
>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>
>>
>> "lower" was 8.5% slower, if such test exists in the specJVM, it would 
>> be considered a regression. I would suggest you run the specJVM. I 
>> agree with you on surrogate check being a requirement, thus supLower 
>> being 139% slower is ok since it won't otherwise be correct anyways.
> 
> Yes, it would be a regression if SPECjvm produces 8+% degradation, but 
> the test suite is aimed at the entire application performance. But for 
> this one, it is a micro benchmark for relatively rarely issued methods 
> (I would think normal cases fall into Latin1 equivalents), I would 
> consider it is acceptable.
> 
>> But after introducing additional operations supUpperLower and 
>> upperLower ran faster? That may indicate irregularity in the tests. 
>> Maybe we should consider running tests with short, long and very long 
>> sample strings to see if we can reduce the noise level and also see 
>> how it fares for a longer string. I assume the machine you're running 
>> the test on was isolated.
> 
> This result pretty much depends on the data it is testing for. As I 
> wrote in the previous email, (sup)UpperLower tests use the data that are 
> almost identical, but one last character is case insensitively equal. So 
> in these cases, the new short cut works really well and not call 
> toLower/UpperCase() at all for most of the characters. Thus the new 
> results are faster. Again the test result is very dependent on the input 
> data, Unless the result showed 100% slower or something (except supLower 
> case), I think it is OK.
> 
> Anyways, here is the updated webrev addressing your first suggestion:
> 
> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
> 
> Naoto
> 
>>
>> Regards,
>> Joe
>>
>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>> Hi Mark,
>>>
>>> Thank you for your comments.
>>>
>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>> One option is to have a fast path that uses char functions, up to 
>>>> the point where you hit a high surrogate, then drop into the slower 
>>>> codepoint path. That saves time for the high-runner cases.
>>>>
>>>> On the other hand, if the times are good enough, you might not need 
>>>> the complication.
>>>
>>> The implementation is dealing with bare byte arrays. Only methods 
>>> that it uses from Character class are toLowerCase(int) and 
>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>> iteration anyways), and their "char" equivalents are merely casting 
>>> (char) to the int result. So it might not be so beneficial to 
>>> differentiate char and int paths.
>>>
>>> Having said that, I found that there was an unnecessary surrogate 
>>> check (always checks high *and* low surrogate on each iteration), so 
>>> I revised the fix (added line 380-383 in StringUTF16.java):
>>>
>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>
>>> Naoto
>>>
>>>>
>>>> Mark
>>>> //////
>>>>
>>>>
>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>
>>>> ??? Hi,
>>>>
>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>
>>>> ??? Changes from the initial revision are:
>>>>
>>>> ??? - Shared the implementation between compareToCI() and 
>>>> regionMatchesCI()
>>>> ??? - Enabled immediate short cut if two code points match.
>>>> ??? - Created a simple JMH benchmark. Here is the scores before and 
>>>> after
>>>> ??? the change:
>>>>
>>>> ??? before:
>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score 
>>>> ?Error ??? Units
>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 53.764 ? 
>>>> 2.811 ??? ns/op
>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 24.211 ? 
>>>> 1.135 ??? ns/op
>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 30.595 ? 
>>>> 1.344 ??? ns/op
>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 18.859 ? 
>>>> 1.499 ??? ns/op
>>>>
>>>> ??? after:
>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score 
>>>> ?Error ??? Units
>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 58.354 ? 
>>>> 4.603 ??? ns/op
>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 57.975 ? 
>>>> 5.672 ??? ns/op
>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 23.912 ? 
>>>> 0.965 ??? ns/op
>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 17.744 ? 
>>>> 0.272 ??? ns/op
>>>>
>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>> "lower"
>>>> ??? means each character requires upper->lower casemap. "upperLower" 
>>>> means
>>>> ??? all characters are the same, except the last character which 
>>>> requires
>>>> ??? casemap.
>>>>
>>>> ??? I think the result is reasonable, considering surrogates check 
>>>> are now
>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>> Arrays.mismatch() but
>>>> ??? it did not seem to benefit here. In fact, the performance degraded
>>>> ??? partly because I implemented the short cut, and possibly for the
>>>> ??? overhead of extra checks.
>>>>
>>>> ??? Naoto
>>>>
>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>> ???? > Hello,
>>>> ???? >
>>>> ???? > Please review the fix to the following issues:
>>>> ???? >
>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>> ???? >
>>>> ???? > The proposed changeset and its CSR are located at:
>>>> ???? >
>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>> ???? >
>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>> ??? locales in
>>>> ???? > JDK15. The root cause was that case-insensitive
>>>> ??? String.regionMatches()
>>>> ???? > method did not work with supplementary characters. The 
>>>> problem is
>>>> ??? that
>>>> ???? > the method's spec does not expect case mappings of supplementary
>>>> ???? > characters, possibly because it was overlooked in the first
>>>> ??? place, JSR
>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>> behavior is
>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>> ???? >
>>>> ???? > The fix is straightforward to compare strings by code point 
>>>> basis,
>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>> ??? change will
>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>> ???? > incompatibility to wrong behavior, not true to the meaning of 
>>>> those
>>>> ???? > methods' expectations.
>>>> ???? >
>>>> ???? > Naoto
>>>>
>>

From huizhe.wang at oracle.com  Tue Jul 21 02:14:47 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 20 Jul 2020 19:14:47 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
Message-ID: <186dfcff-5c57-bc5f-7e0f-a29d1ba65446@oracle.com>

Hi Naoto,

"Unless it showed 100% slower", wow, your tolerance is quite high :-). 
On the other hand, I do agree it's unlikely to show in specJVM (that's a 
speculation though).

The short-cut worked well. There's maybe a further optimization we could 
do to rid us of the performance concern (or the need to run additional 
performance tests). Consider the cases where strings in comparison don't 
contain any sup characters, if we make the toLower/UpperCase() block a 
method and call it before and after the surrogate-check block, the 
routine would be effectively the same as prior to the introduction of 
the surrogate-check block, and regular comparisons would suffer the 
surrogate-check only once (the last check). For strings that do contain 
sup characters then, the toLower/UpperCase() method would have been 
called twice, but then we don't care about the performance in that 
situation. You may call the existing codePointAt method too when an 
extra getChar and performance is not a concern (but that's your call.

Regards,
Joe

On 7/20/20 3:20 PM, naoto.sato at oracle.com wrote:
> Small correction in the updated part:
>
> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/
>
> Naoto
>
> On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Thank you for your comments.
>>
>> On 7/20/20 11:20 AM, Joe Wang wrote:
>>> Hi Naoto,
>>>
>>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>>> there if 389:isHighSurrogate is not true. 
>>
>> Good point.
>>
>> But more importantly, StringUTF16
>>> has existing method "codePointAt" you may want to consider instead 
>>> of adding a new method.
>>
>> If we call codePointAt/Before, it would call an extra getChar(). 
>> Since we know one codepoint as an input, I would avoid the extra calls.
>>
>>>
>>> Comparing to the base benchmark:
>>> StringCompareToIgnoreCase.lower????????? 8.5%
>>> StringCompareToIgnoreCase.supLower????? 139%
>>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>>
>>>
>>> "lower" was 8.5% slower, if such test exists in the specJVM, it 
>>> would be considered a regression. I would suggest you run the 
>>> specJVM. I agree with you on surrogate check being a requirement, 
>>> thus supLower being 139% slower is ok since it won't otherwise be 
>>> correct anyways.
>>
>> Yes, it would be a regression if SPECjvm produces 8+% degradation, 
>> but the test suite is aimed at the entire application performance. 
>> But for this one, it is a micro benchmark for relatively rarely 
>> issued methods (I would think normal cases fall into Latin1 
>> equivalents), I would consider it is acceptable.
>>
>>> But after introducing additional operations supUpperLower and 
>>> upperLower ran faster? That may indicate irregularity in the tests. 
>>> Maybe we should consider running tests with short, long and very 
>>> long sample strings to see if we can reduce the noise level and also 
>>> see how it fares for a longer string. I assume the machine you're 
>>> running the test on was isolated.
>>
>> This result pretty much depends on the data it is testing for. As I 
>> wrote in the previous email, (sup)UpperLower tests use the data that 
>> are almost identical, but one last character is case insensitively 
>> equal. So in these cases, the new short cut works really well and not 
>> call toLower/UpperCase() at all for most of the characters. Thus the 
>> new results are faster. Again the test result is very dependent on 
>> the input data, Unless the result showed 100% slower or something 
>> (except supLower case), I think it is OK.
>>
>> Anyways, here is the updated webrev addressing your first suggestion:
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
>>
>> Naoto
>>
>>>
>>> Regards,
>>> Joe
>>>
>>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>>> Hi Mark,
>>>>
>>>> Thank you for your comments.
>>>>
>>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>>> One option is to have a fast path that uses char functions, up to 
>>>>> the point where you hit a high surrogate, then drop into the 
>>>>> slower codepoint path. That saves time for the high-runner cases.
>>>>>
>>>>> On the other hand, if the times are good enough, you might not 
>>>>> need the complication.
>>>>
>>>> The implementation is dealing with bare byte arrays. Only methods 
>>>> that it uses from Character class are toLowerCase(int) and 
>>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>>> iteration anyways), and their "char" equivalents are merely casting 
>>>> (char) to the int result. So it might not be so beneficial to 
>>>> differentiate char and int paths.
>>>>
>>>> Having said that, I found that there was an unnecessary surrogate 
>>>> check (always checks high *and* low surrogate on each iteration), 
>>>> so I revised the fix (added line 380-383 in StringUTF16.java):
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Mark
>>>>> //////
>>>>>
>>>>>
>>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>>
>>>>> ??? Hi,
>>>>>
>>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>
>>>>> ??? Changes from the initial revision are:
>>>>>
>>>>> ??? - Shared the implementation between compareToCI() and 
>>>>> regionMatchesCI()
>>>>> ??? - Enabled immediate short cut if two code points match.
>>>>> ??? - Created a simple JMH benchmark. Here is the scores before 
>>>>> and after
>>>>> ??? the change:
>>>>>
>>>>> ??? before:
>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>> ?Error ??? Units
>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 53.764 ? 
>>>>> 2.811 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 24.211 ? 
>>>>> 1.135 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 30.595 ? 
>>>>> 1.344 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 18.859 ? 
>>>>> 1.499 ??? ns/op
>>>>>
>>>>> ??? after:
>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>> ?Error ??? Units
>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 58.354 ? 
>>>>> 4.603 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 57.975 ? 
>>>>> 5.672 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 23.912 ? 
>>>>> 0.965 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 17.744 ? 
>>>>> 0.272 ??? ns/op
>>>>>
>>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>> "lower"
>>>>> ??? means each character requires upper->lower casemap. 
>>>>> "upperLower" means
>>>>> ??? all characters are the same, except the last character which 
>>>>> requires
>>>>> ??? casemap.
>>>>>
>>>>> ??? I think the result is reasonable, considering surrogates check 
>>>>> are now
>>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>>> Arrays.mismatch() but
>>>>> ??? it did not seem to benefit here. In fact, the performance 
>>>>> degraded
>>>>> ??? partly because I implemented the short cut, and possibly for the
>>>>> ??? overhead of extra checks.
>>>>>
>>>>> ??? Naoto
>>>>>
>>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>>> ???? > Hello,
>>>>> ???? >
>>>>> ???? > Please review the fix to the following issues:
>>>>> ???? >
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>> ???? >
>>>>> ???? > The proposed changeset and its CSR are located at:
>>>>> ???? >
>>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>> ???? >
>>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>>> ??? locales in
>>>>> ???? > JDK15. The root cause was that case-insensitive
>>>>> ??? String.regionMatches()
>>>>> ???? > method did not work with supplementary characters. The 
>>>>> problem is
>>>>> ??? that
>>>>> ???? > the method's spec does not expect case mappings of 
>>>>> supplementary
>>>>> ???? > characters, possibly because it was overlooked in the first
>>>>> ??? place, JSR
>>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>>> behavior is
>>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>>> ???? >
>>>>> ???? > The fix is straightforward to compare strings by code point 
>>>>> basis,
>>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>>> ??? change will
>>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>>> ???? > incompatibility to wrong behavior, not true to the meaning 
>>>>> of those
>>>>> ???? > methods' expectations.
>>>>> ???? >
>>>>> ???? > Naoto
>>>>>
>>>


From naoto.sato at oracle.com  Tue Jul 21 03:58:08 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 20 Jul 2020 20:58:08 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <186dfcff-5c57-bc5f-7e0f-a29d1ba65446@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
 <186dfcff-5c57-bc5f-7e0f-a29d1ba65446@oracle.com>
Message-ID: <36cb163f-9902-9d34-9c5a-c31f3b905eb9@oracle.com>

Hi Joe,

On 7/20/20 7:14 PM, Joe Wang wrote:
> Hi Naoto,
> 
> "Unless it showed 100% slower", wow, your tolerance is quite high :-). 
> On the other hand, I do agree it's unlikely to show in specJVM (that's a 
> speculation though).

I am not saying 100% slowing is permissible :-) That's an example of 
definite no.

> 
> The short-cut worked well. There's maybe a further optimization we could 
> do to rid us of the performance concern (or the need to run additional 
> performance tests). Consider the cases where strings in comparison don't 
> contain any sup characters, if we make the toLower/UpperCase() block a 
> method and call it before and after the surrogate-check block, the 
> routine would be effectively the same as prior to the introduction of 
> the surrogate-check block, and regular comparisons would suffer the 
> surrogate-check only once (the last check). For strings that do contain 
> sup characters then, the toLower/UpperCase() method would have been 
> called twice, but then we don't care about the performance in that 
> situation. You may call the existing codePointAt method too when an 
> extra getChar and performance is not a concern (but that's your call.

Can you please elaborate this more? What's "the last check" here?

Naoto

> 
> Regards,
> Joe
> 
> On 7/20/20 3:20 PM, naoto.sato at oracle.com wrote:
>> Small correction in the updated part:
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/
>>
>> Naoto
>>
>> On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for your comments.
>>>
>>> On 7/20/20 11:20 AM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>>>> there if 389:isHighSurrogate is not true. 
>>>
>>> Good point.
>>>
>>> But more importantly, StringUTF16
>>>> has existing method "codePointAt" you may want to consider instead 
>>>> of adding a new method.
>>>
>>> If we call codePointAt/Before, it would call an extra getChar(). 
>>> Since we know one codepoint as an input, I would avoid the extra calls.
>>>
>>>>
>>>> Comparing to the base benchmark:
>>>> StringCompareToIgnoreCase.lower????????? 8.5%
>>>> StringCompareToIgnoreCase.supLower????? 139%
>>>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>>>
>>>>
>>>> "lower" was 8.5% slower, if such test exists in the specJVM, it 
>>>> would be considered a regression. I would suggest you run the 
>>>> specJVM. I agree with you on surrogate check being a requirement, 
>>>> thus supLower being 139% slower is ok since it won't otherwise be 
>>>> correct anyways.
>>>
>>> Yes, it would be a regression if SPECjvm produces 8+% degradation, 
>>> but the test suite is aimed at the entire application performance. 
>>> But for this one, it is a micro benchmark for relatively rarely 
>>> issued methods (I would think normal cases fall into Latin1 
>>> equivalents), I would consider it is acceptable.
>>>
>>>> But after introducing additional operations supUpperLower and 
>>>> upperLower ran faster? That may indicate irregularity in the tests. 
>>>> Maybe we should consider running tests with short, long and very 
>>>> long sample strings to see if we can reduce the noise level and also 
>>>> see how it fares for a longer string. I assume the machine you're 
>>>> running the test on was isolated.
>>>
>>> This result pretty much depends on the data it is testing for. As I 
>>> wrote in the previous email, (sup)UpperLower tests use the data that 
>>> are almost identical, but one last character is case insensitively 
>>> equal. So in these cases, the new short cut works really well and not 
>>> call toLower/UpperCase() at all for most of the characters. Thus the 
>>> new results are faster. Again the test result is very dependent on 
>>> the input data, Unless the result showed 100% slower or something 
>>> (except supLower case), I think it is OK.
>>>
>>> Anyways, here is the updated webrev addressing your first suggestion:
>>>
>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
>>>
>>> Naoto
>>>
>>>>
>>>> Regards,
>>>> Joe
>>>>
>>>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>>>> Hi Mark,
>>>>>
>>>>> Thank you for your comments.
>>>>>
>>>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>>>> One option is to have a fast path that uses char functions, up to 
>>>>>> the point where you hit a high surrogate, then drop into the 
>>>>>> slower codepoint path. That saves time for the high-runner cases.
>>>>>>
>>>>>> On the other hand, if the times are good enough, you might not 
>>>>>> need the complication.
>>>>>
>>>>> The implementation is dealing with bare byte arrays. Only methods 
>>>>> that it uses from Character class are toLowerCase(int) and 
>>>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>>>> iteration anyways), and their "char" equivalents are merely casting 
>>>>> (char) to the int result. So it might not be so beneficial to 
>>>>> differentiate char and int paths.
>>>>>
>>>>> Having said that, I found that there was an unnecessary surrogate 
>>>>> check (always checks high *and* low surrogate on each iteration), 
>>>>> so I revised the fix (added line 380-383 in StringUTF16.java):
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Mark
>>>>>> //////
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>>>
>>>>>> ??? Hi,
>>>>>>
>>>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>>
>>>>>> ??? Changes from the initial revision are:
>>>>>>
>>>>>> ??? - Shared the implementation between compareToCI() and 
>>>>>> regionMatchesCI()
>>>>>> ??? - Enabled immediate short cut if two code points match.
>>>>>> ??? - Created a simple JMH benchmark. Here is the scores before 
>>>>>> and after
>>>>>> ??? the change:
>>>>>>
>>>>>> ??? before:
>>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>>> ?Error ??? Units
>>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 53.764 ? 
>>>>>> 2.811 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 24.211 ? 
>>>>>> 1.135 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 30.595 ? 
>>>>>> 1.344 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 18.859 ? 
>>>>>> 1.499 ??? ns/op
>>>>>>
>>>>>> ??? after:
>>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>>> ?Error ??? Units
>>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 58.354 ? 
>>>>>> 4.603 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 57.975 ? 
>>>>>> 5.672 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 23.912 ? 
>>>>>> 0.965 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 17.744 ? 
>>>>>> 0.272 ??? ns/op
>>>>>>
>>>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>>> "lower"
>>>>>> ??? means each character requires upper->lower casemap. 
>>>>>> "upperLower" means
>>>>>> ??? all characters are the same, except the last character which 
>>>>>> requires
>>>>>> ??? casemap.
>>>>>>
>>>>>> ??? I think the result is reasonable, considering surrogates check 
>>>>>> are now
>>>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>>>> Arrays.mismatch() but
>>>>>> ??? it did not seem to benefit here. In fact, the performance 
>>>>>> degraded
>>>>>> ??? partly because I implemented the short cut, and possibly for the
>>>>>> ??? overhead of extra checks.
>>>>>>
>>>>>> ??? Naoto
>>>>>>
>>>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>>>> ???? > Hello,
>>>>>> ???? >
>>>>>> ???? > Please review the fix to the following issues:
>>>>>> ???? >
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>>> ???? >
>>>>>> ???? > The proposed changeset and its CSR are located at:
>>>>>> ???? >
>>>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>>> ???? >
>>>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>>>> ??? locales in
>>>>>> ???? > JDK15. The root cause was that case-insensitive
>>>>>> ??? String.regionMatches()
>>>>>> ???? > method did not work with supplementary characters. The 
>>>>>> problem is
>>>>>> ??? that
>>>>>> ???? > the method's spec does not expect case mappings of 
>>>>>> supplementary
>>>>>> ???? > characters, possibly because it was overlooked in the first
>>>>>> ??? place, JSR
>>>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>>>> behavior is
>>>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>>>> ???? >
>>>>>> ???? > The fix is straightforward to compare strings by code point 
>>>>>> basis,
>>>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>>>> ??? change will
>>>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>>>> ???? > incompatibility to wrong behavior, not true to the meaning 
>>>>>> of those
>>>>>> ???? > methods' expectations.
>>>>>> ???? >
>>>>>> ???? > Naoto
>>>>>>
>>>>
> 

From Roger.Riggs at oracle.com  Tue Jul 21 13:57:30 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 21 Jul 2020 09:57:30 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <4202609E-F2B7-4C81-B325-B470BD79EA67@oracle.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
 <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
 <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>
 <9d351d78-88c1-9e6d-28a0-9aa6c552c251@gmail.com>
 <4202609E-F2B7-4C81-B325-B470BD79EA67@oracle.com>
Message-ID: <07bf53e1-9eee-8391-51aa-da814b7a37ee@oracle.com>

Hi Rafaello, Lance,

That looks good to me.

Thanks, Roger

On 7/19/20 2:31 PM, Lance Andersen wrote:
> Hi Raffaello,
>
> I think the changes look reasonable.
>
> I have created a webrev, 
> http://cr.openjdk.java.net/~lancea/8222187/webrev.00/, for others to 
> review as it is a bit easier than the patch.
>
> I have also run the JCK tests in this area as well as mach5 tiers1-3 
> (which I believe Roger has also)
>
> Best
> Lance
>
>> On Jul 15, 2020, at 5:44 PM, Raffaello Giulietti 
>> <raffaello.giulietti at gmail.com 
>> <mailto:raffaello.giulietti at gmail.com>> wrote:
>>
>> Hi Roger,
>>
>> On 2020-07-15 22:21, Roger Riggs wrote:
>>> Hi Raffaello,
>>> Base64.java:
>>> 2: Please update 2nd copyright year to 2020
>>
>> I was unsure what to do here, thanks for guidance.
>> I also removed the seemingly useless import at former L33.
>>
>>
>>
>>> leftovers():
>>> 996: "&" the shortcutting && is more typical in a condition.
>>> 997: the -= is buried in an expression and a reader might miss it.
>>
>> Corrected, as well as the analogous -= usage for wpos now at L1106-7
>>
>>
>>> 1053:? "can be reallocated to other vars":? not a useful comment, 
>>> reflecting on only one possible implementation that is out of the 
>>> control of the developer.
>>> I'd almost rather see 'len' than 'limit - off'; it might be 
>>> informative to the reader if 'limit' was declared final. (1056:)
>>
>> Done, as well as declaring i and v final in the loop.
>>
>>
>>
>>> TestBase54.java:
>>> 2: Update 2nd copyright year to 2020
>>> 27:? Please add the bug number to the @bug line.
>>> Style-wise, I would remove the blank lines at the beginning of 
>>> blocks. (1095, 1115)
>>
>> Done.
>>
>>
>>> Thanks, Roger
>>> On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
>>>> Hi Roger,
>>>>
>>>> here's the latest version of the patch.
>>>>
>>>> I did:
>>>> * Withdraw the simplification in encodedOutLength(), as it is 
>>>> indeed out of scope for this bug fix.
>>>> * Restore field names in DecInputStream except for nextin (now 
>>>> wpos) and nextout (now rpos) because they have slightly different 
>>>> semantics. That's just for clarity. I would have nothing against 
>>>> reusing the old names for the proposed purpose.
>>>> * Switch back to the original no-arg read() implementation.
>>>> * Adjust comment continuation lines.
>>>> * Preserve the proposed logic of read(byte[], int, int) and the 
>>>> supporting methods.
>>>>
>>>> Others needed changes are:
>>>> * Correct the copyright years: that's something better left to Oracle.
>>>> * Remove the apparently useless import at L33. I could build and 
>>>> run without it.
>>>>
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>
>>
>> ----
>>
>> # HG changeset patch
>> # User lello
>> # Date 1594848775 -7200
>> # ?????Wed Jul 15 23:32:55 2020 +0200
>> # Node ID f7407f35e83ab508f0e6deab4f776bb1a1c85e68
>> # Parent ?a5649ebf94193770ca763391dd63807059d333b4
>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes 
>> at the end
>> Reviewed-by: TBD
>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com 
>> <mailto:raffaello.giulietti at gmail.com>>
>>
>> diff --git a/src/java.base/share/classes/java/util/Base64.java 
>> b/src/java.base/share/classes/java/util/Base64.java
>> --- a/src/java.base/share/classes/java/util/Base64.java
>> +++ b/src/java.base/share/classes/java/util/Base64.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2012, 2020, 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
>> @@ -30,7 +30,6 @@
>> import java.io.IOException;
>> import java.io.OutputStream;
>> import java.nio.ByteBuffer;
>> -import java.nio.charset.StandardCharsets;
>>
>> import sun.nio.cs.ISO_8859_1;
>>
>> @@ -961,12 +960,15 @@
>>
>> ????????private final InputStream is;
>> ????????private final boolean isMIME;
>> - ???????private final int[] base64; ?????// base64 -> byte mapping
>> - ???????private int bits = 0; ???????????// 24-bit buffer for decoding
>> - ???????private int nextin = 18; ????????// next available "off" in 
>> "bits" for input;
>> - ????????????????????????????????????????// -> 18, 12, 6, 0
>> - ???????private int nextout = -8; ???????// next available "off" in 
>> "bits" for output;
>> - ????????????????????????????????????????// -> 8, 0, -8 (no byte for 
>> output)
>> + ???????private final int[] base64; ????// base64 -> byte mapping
>> + ???????private int bits = 0; ??????????// 24-bit buffer for decoding
>> +
>> + ???????/* writing bit pos inside bits; one of 24 (left, msb), 18, 
>> 12, 6, 0 */
>> + ???????private int wpos = 0;
>> +
>> + ???????/* reading bit pos inside bits: one of 24 (left, msb), 16, 
>> 8, 0 */
>> + ???????private int rpos = 0;
>> +
>> ????????private boolean eof = false;
>> ????????private boolean closed = false;
>>
>> @@ -983,107 +985,153 @@
>> ????????????return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>> ????????}
>>
>> - ???????private int eof(byte[] b, int off, int len, int oldOff)
>> - ???????????throws IOException
>> - ???????{
>> + ???????private int leftovers(byte[] b, int off, int pos, int limit) {
>> ????????????eof = true;
>> - ???????????if (nextin != 18) {
>> - ???????????????if (nextin == 12)
>> - ???????????????????throw new IOException("Base64 stream has one 
>> un-decoded dangling byte.");
>> - ???????????????// treat ending xx/xxx without padding character legal.
>> - ???????????????// same logic as v == '=' below
>> - ???????????????b[off++] = (byte)(bits >> (16));
>> - ???????????????if (nextin == 0) { ??????????// only one padding byte
>> - ???????????????????if (len == 1) { ?????????// no enough output space
>> - ???????????????????????bits >>= 8; ?????????// shift to lowest byte
>> - ???????????????????????nextout = 0;
>> - ???????????????????} else {
>> - ???????????????????????b[off++] = (byte) (bits >> ?8);
>> - ???????????????????}
>> - ???????????????}
>> +
>> + ???????????/*
>> + ????????????* We use a loop here, as this method is executed only a 
>> few times.
>> + ????????????* Unrolling the loop would probably not contribute much 
>> here.
>> + ????????????*/
>> + ???????????while (rpos - 8 >= wpos && pos != limit) {
>> + ???????????????rpos -= 8;
>> + ???????????????b[pos++] = (byte) (bits >> rpos);
>> ????????????}
>> - ???????????return off == oldOff ? -1 : off - oldOff;
>> + ???????????return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
>> ????????}
>>
>> - ???????private int padding(byte[] b, int off, int len, int oldOff)
>> - ???????????throws IOException
>> - ???????{
>> - ???????????// = ????shiftto==18 unnecessary padding
>> - ???????????// x= ???shiftto==12 dangling x, invalid unit
>> - ???????????// xx= ??shiftto==6 && missing last '='
>> - ???????????// xx=y ?or last is not '='
>> - ???????????if (nextin == 18 || nextin == 12 ||
>> - ???????????????nextin == 6 && is.read() != '=') {
>> - ???????????????throw new IOException("Illegal base64 ending 
>> sequence:" + nextin);
>> + ???????private int eof(byte[] b, int off, int pos, int limit) 
>> throws IOException {
>> + ???????????/*
>> + ????????????* pos != limit
>> + ????????????*
>> + ????????????* wpos == 18: x ????dangling single x, invalid unit
>> + ????????????* accept ending xx or xxx without padding characters
>> + ????????????*/
>> + ???????????if (wpos == 18) {
>> + ???????????????throw new IOException("Base64 stream has one 
>> un-decoded dangling byte.");
>> ????????????}
>> - ???????????b[off++] = (byte)(bits >> (16));
>> - ???????????if (nextin == 0) { ??????????// only one padding byte
>> - ???????????????if (len == 1) { ?????????// no enough output space
>> - ???????????????????bits >>= 8; ?????????// shift to lowest byte
>> - ???????????????????nextout = 0;
>> - ???????????????} else {
>> - ???????????????????b[off++] = (byte) (bits >> ?8);
>> - ???????????????}
>> + ???????????rpos = 24;
>> + ???????????return leftovers(b, off, pos, limit);
>> + ???????}
>> +
>> + ???????private int padding(byte[] b, int off, int pos, int limit) 
>> throws IOException {
>> + ???????????/*
>> + ????????????* pos != limit
>> + ????????????*
>> + ????????????* wpos == 24: = ???(unnecessary padding)
>> + ????????????* wpos == 18: x= ??(dangling single x, invalid unit)
>> + ????????????* wpos == 12 and missing last '=': xx= ?(invalid padding)
>> + ????????????* wpos == 12 and last is not '=': xx=x (invalid padding)
>> + ????????????*/
>> + ???????????if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>> + ???????????????throw new IOException("Illegal base64 ending 
>> sequence:" + wpos);
>> ????????????}
>> - ???????????eof = true;
>> - ???????????return off - oldOff;
>> + ???????????rpos = 24;
>> + ???????????return leftovers(b, off, pos, limit);
>> ????????}
>>
>> ????????@Override
>> ????????public int read(byte[] b, int off, int len) throws IOException {
>> - ???????????if (closed)
>> + ???????????if (closed) {
>> ????????????????throw new IOException("Stream is closed");
>> - ???????????if (eof && nextout < 0) ???// eof and no leftover
>> - ???????????????return -1;
>> - ???????????if (off < 0 || len < 0 || len > b.length - off)
>> - ???????????????throw new IndexOutOfBoundsException();
>> - ???????????int oldOff = off;
>> - ???????????while (nextout >= 0) { ??????// leftover output byte(s) 
>> in bits buf
>> - ???????????????if (len == 0)
>> - ???????????????????return off - oldOff;
>> - ???????????????b[off++] = (byte)(bits >> nextout);
>> - ???????????????len--;
>> - ???????????????nextout -= 8;
>> + ???????????}
>> + ???????????Objects.checkFromIndexSize(off, len, b.length);
>> + ???????????if (len == 0) {
>> + ???????????????return 0;
>> ????????????}
>> - ???????????bits = 0;
>> - ???????????while (len > 0) {
>> - ???????????????int v = is.read();
>> - ???????????????if (v == -1) {
>> - ???????????????????return eof(b, off, len, oldOff);
>> +
>> + ???????????/*
>> + ????????????* Rather than keeping 2 running vars (e.g., off and len),
>> + ????????????* we only keep one (pos), while definitely fixing the 
>> boundaries
>> + ????????????* of the range [off, limit).
>> + ????????????* More specifically, each use of pos as an index in b meets
>> + ????????????* ?????pos - off >= 0 & limit - pos > 0
>> + ????????????*
>> + ????????????* Note that limit can overflow to Integer.MIN_VALUE. 
>> However,
>> + ????????????* as long as comparisons with pos are as coded, there's 
>> no harm.
>> + ????????????*/
>> + ???????????int pos = off;
>> + ???????????final int limit = off + len;
>> + ???????????if (eof) {
>> + ???????????????return leftovers(b, off, pos, limit);
>> + ???????????}
>> +
>> + ???????????/*
>> + ????????????* Leftovers from previous invocation; here, wpos = 0.
>> + ????????????* There can be at most 2 leftover bytes (rpos <= 16).
>> + ????????????* Further, b has at least one free place.
>> + ????????????*
>> + ????????????* The logic could be coded as a loop, (as in method 
>> leftovers())
>> + ????????????* but the explicit "unrolling" makes it possible to 
>> generate
>> + ????????????* better byte extraction code.
>> + ????????????*/
>> + ???????????if (rpos == 16) {
>> + ???????????????b[pos++] = (byte) (bits >> 8);
>> + ???????????????rpos = 8;
>> + ???????????????if (pos == limit) {
>> + ???????????????????return len;
>> ????????????????}
>> - ???????????????if ((v = base64[v]) < 0) {
>> - ???????????????????if (v == -2) { ??????// padding byte(s)
>> - ???????????????????????return padding(b, off, len, oldOff);
>> - ???????????????????}
>> - ???????????????????if (v == -1) {
>> - ???????????????????????if (!isMIME)
>> - ???????????????????????????throw new IOException("Illegal base64 
>> character " +
>> - ???????????????????????????????Integer.toString(v, 16));
>> - ???????????????????????continue; ???????// skip if for rfc2045
>> - ???????????????????}
>> - ???????????????????// neve be here
>> - ???????????????}
>> - ???????????????bits |= (v << nextin);
>> - ???????????????if (nextin == 0) {
>> - ???????????????????nextin = 18; ????????// clear for next in
>> - ???????????????????b[off++] = (byte)(bits >> 16);
>> - ???????????????????if (len == 1) {
>> - ???????????????????????nextout = 8; ???// 2 bytes left in bits
>> - ???????????????????????break;
>> - ???????????????????}
>> - ???????????????????b[off++] = (byte)(bits >> 8);
>> - ???????????????????if (len == 2) {
>> - ???????????????????????nextout = 0; ???// 1 byte left in bits
>> - ???????????????????????break;
>> - ???????????????????}
>> - ???????????????????b[off++] = (byte)bits;
>> - ???????????????????len -= 3;
>> - ???????????????????bits = 0;
>> - ???????????????} else {
>> - ???????????????????nextin -= 6;
>> + ???????????}
>> + ???????????if (rpos == 8) {
>> + ???????????????b[pos++] = (byte) bits;
>> + ???????????????rpos = 0;
>> + ???????????????if (pos == limit) {
>> + ???????????????????return len;
>> ????????????????}
>> ????????????}
>> - ???????????return off - oldOff;
>> +
>> + ???????????bits = 0;
>> + ???????????wpos = 24;
>> + ???????????for (;;) {
>> + ???????????????/* pos != limit & rpos == 0 */
>> + ???????????????final int i = is.read();
>> + ???????????????if (i < 0) {
>> + ???????????????????return eof(b, off, pos, limit);
>> + ???????????????}
>> + ???????????????final int v = base64[i];
>> + ???????????????if (v < 0) {
>> + ???????????????????/*
>> + ????????????????????* i not in alphabet, thus
>> + ????????????????????* ?????v == -2: i is '=', the padding
>> + ????????????????????* ?????v == -1: i is something else, typically 
>> CR or LF
>> + ????????????????????*/
>> + ???????????????????if (v == -1) {
>> + ???????????????????????if (isMIME) {
>> + ???????????????????????????continue;
>> + ???????????????????????}
>> + ???????????????????????throw new IOException("Illegal base64 
>> character 0x" +
>> + ???????????????????????????????Integer.toHexString(i));
>> + ???????????????????}
>> + ???????????????????return padding(b, off, pos, limit);
>> + ???????????????}
>> + ???????????????wpos -= 6;
>> + ???????????????bits |= v << wpos;
>> + ???????????????if (wpos != 0) {
>> + ???????????????????continue;
>> + ???????????????}
>> + ???????????????if (limit - pos >= 3) {
>> + ???????????????????/* frequently taken fast path, no need to track 
>> rpos */
>> + ???????????????????b[pos++] = (byte) (bits >> 16);
>> + ???????????????????b[pos++] = (byte) (bits >> 8);
>> + ???????????????????b[pos++] = (byte) bits;
>> + ???????????????????bits = 0;
>> + ???????????????????wpos = 24;
>> + ???????????????????if (pos == limit) {
>> + ???????????????????????return len;
>> + ???????????????????}
>> + ???????????????????continue;
>> + ???????????????}
>> +
>> + ???????????????/* b has either 1 or 2 free places */
>> + ???????????????b[pos++] = (byte) (bits >> 16);
>> + ???????????????if (pos == limit) {
>> + ???????????????????rpos = 16;
>> + ???????????????????return len;
>> + ???????????????}
>> + ???????????????b[pos++] = (byte) (bits >> 8);
>> + ???????????????/* pos == limit, no need for an if */
>> + ???????????????rpos = 8;
>> + ???????????????return len;
>> + ???????????}
>> ????????}
>>
>> ????????@Override
>> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
>> b/test/jdk/java/util/Base64/TestBase64.java
>> --- a/test/jdk/java/util/Base64/TestBase64.java
>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2012, 2020, 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
>> @@ -24,7 +24,7 @@
>> /**
>> ?* @test
>> ?* @bug 4235519 8004212 8005394 8007298 8006295 8006315 8006530 
>> 8007379 8008925
>> - * ?????8014217 8025003 8026330 8028397 8129544 8165243 8176379
>> + * ?????8014217 8025003 8026330 8028397 8129544 8165243 8176379 8222187
>> ?* @summary tests java.util.Base64
>> ?* @library /test/lib
>> ?* @build jdk.test.lib.RandomFactory
>> @@ -144,6 +144,10 @@
>> ????????testDecoderKeepsAbstinence(Base64.getDecoder());
>> ????????testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>> ????????testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>> +
>> + ???????// tests patch addressing JDK-8222187
>> + ???????// https://bugs.openjdk.java.net/browse/JDK-8222187
>> + ???????testJDK_8222187();
>> ????}
>>
>> ????private static void test(Base64.Encoder enc, Base64.Decoder dec,
>> @@ -607,4 +611,26 @@
>> ????????????}
>> ????????}
>> ????}
>> +
>> + ???private static void testJDK_8222187() throws Throwable {
>> + ???????byte[] orig = "12345678".getBytes("US-ASCII");
>> + ???????byte[] encoded = Base64.getEncoder().encode(orig);
>> + ???????// decode using different buffer sizes, up to a longer one 
>> than needed
>> + ???????for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
>> bufferSize++) {
>> + ???????????try (
>> + ???????????????????InputStream in = Base64.getDecoder().wrap(
>> + ???????????????????????????new ByteArrayInputStream(encoded));
>> + ???????????????????ByteArrayOutputStream baos = new 
>> ByteArrayOutputStream();
>> + ???????????) {
>> + ???????????????byte[] buffer = new byte[bufferSize];
>> + ???????????????int read;
>> + ???????????????while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>> + ???????????????????baos.write(buffer, 0, read);
>> + ???????????????}
>> + ???????????????// compare result, output info if lengths do not match
>> + ???????????????byte[] decoded = baos.toByteArray();
>> + ???????????????checkEqual(decoded, orig, "Base64 stream decoding 
>> failed!");
>> + ???????????}
>> + ???????}
>> + ???}
>> }
>> <JDK-8222187.patch>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From Roger.Riggs at oracle.com  Tue Jul 21 14:50:38 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 21 Jul 2020 10:50:38 -0400
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
Message-ID: <05073b40-3824-4ad4-555d-125a052fd447@oracle.com>

Hi Naoto,

StringUTF16.java:

343, 348: The masking and comparisons seem awkward.
I'd suggest just negating the value and testing for < 0 to flag the less 
usual case.
If you continue with the flag bit, define your own static final constant 
for that bit;
It looks odd to be using Integer.MIN_VALUE with bit operators.

Performance wise, I'm a bit cautious about all the if's and branches;

And only calling getSupplementaryCodePoint if cp was a suggorate might 
have some
benefit, but its hard to tell what will be inlined and when.

Thanks, Roger



On 7/20/20 6:20 PM, naoto.sato at oracle.com wrote:
> Small correction in the updated part:
>
> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/
>
> Naoto
>
> On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Thank you for your comments.
>>
>> On 7/20/20 11:20 AM, Joe Wang wrote:
>>> Hi Naoto,
>>>
>>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>>> there if 389:isHighSurrogate is not true. 
>>
>> Good point.
>>
>> But more importantly, StringUTF16
>>> has existing method "codePointAt" you may want to consider instead 
>>> of adding a new method.
>>
>> If we call codePointAt/Before, it would call an extra getChar(). 
>> Since we know one codepoint as an input, I would avoid the extra calls.
>>
>>>
>>> Comparing to the base benchmark:
>>> StringCompareToIgnoreCase.lower????????? 8.5%
>>> StringCompareToIgnoreCase.supLower????? 139%
>>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>>
>>>
>>> "lower" was 8.5% slower, if such test exists in the specJVM, it 
>>> would be considered a regression. I would suggest you run the 
>>> specJVM. I agree with you on surrogate check being a requirement, 
>>> thus supLower being 139% slower is ok since it won't otherwise be 
>>> correct anyways.
>>
>> Yes, it would be a regression if SPECjvm produces 8+% degradation, 
>> but the test suite is aimed at the entire application performance. 
>> But for this one, it is a micro benchmark for relatively rarely 
>> issued methods (I would think normal cases fall into Latin1 
>> equivalents), I would consider it is acceptable.
>>
>>> But after introducing additional operations supUpperLower and 
>>> upperLower ran faster? That may indicate irregularity in the tests. 
>>> Maybe we should consider running tests with short, long and very 
>>> long sample strings to see if we can reduce the noise level and also 
>>> see how it fares for a longer string. I assume the machine you're 
>>> running the test on was isolated.
>>
>> This result pretty much depends on the data it is testing for. As I 
>> wrote in the previous email, (sup)UpperLower tests use the data that 
>> are almost identical, but one last character is case insensitively 
>> equal. So in these cases, the new short cut works really well and not 
>> call toLower/UpperCase() at all for most of the characters. Thus the 
>> new results are faster. Again the test result is very dependent on 
>> the input data, Unless the result showed 100% slower or something 
>> (except supLower case), I think it is OK.
>>
>> Anyways, here is the updated webrev addressing your first suggestion:
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
>>
>> Naoto
>>
>>>
>>> Regards,
>>> Joe
>>>
>>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>>> Hi Mark,
>>>>
>>>> Thank you for your comments.
>>>>
>>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>>> One option is to have a fast path that uses char functions, up to 
>>>>> the point where you hit a high surrogate, then drop into the 
>>>>> slower codepoint path. That saves time for the high-runner cases.
>>>>>
>>>>> On the other hand, if the times are good enough, you might not 
>>>>> need the complication.
>>>>
>>>> The implementation is dealing with bare byte arrays. Only methods 
>>>> that it uses from Character class are toLowerCase(int) and 
>>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>>> iteration anyways), and their "char" equivalents are merely casting 
>>>> (char) to the int result. So it might not be so beneficial to 
>>>> differentiate char and int paths.
>>>>
>>>> Having said that, I found that there was an unnecessary surrogate 
>>>> check (always checks high *and* low surrogate on each iteration), 
>>>> so I revised the fix (added line 380-383 in StringUTF16.java):
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Mark
>>>>> //////
>>>>>
>>>>>
>>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>>
>>>>> ??? Hi,
>>>>>
>>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>
>>>>> ??? Changes from the initial revision are:
>>>>>
>>>>> ??? - Shared the implementation between compareToCI() and 
>>>>> regionMatchesCI()
>>>>> ??? - Enabled immediate short cut if two code points match.
>>>>> ??? - Created a simple JMH benchmark. Here is the scores before 
>>>>> and after
>>>>> ??? the change:
>>>>>
>>>>> ??? before:
>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>> ?Error ??? Units
>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 53.764 ? 
>>>>> 2.811 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 24.211 ? 
>>>>> 1.135 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 30.595 ? 
>>>>> 1.344 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 18.859 ? 
>>>>> 1.499 ??? ns/op
>>>>>
>>>>> ??? after:
>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>> ?Error ??? Units
>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 58.354 ? 
>>>>> 4.603 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 57.975 ? 
>>>>> 5.672 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 23.912 ? 
>>>>> 0.965 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 17.744 ? 
>>>>> 0.272 ??? ns/op
>>>>>
>>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>> "lower"
>>>>> ??? means each character requires upper->lower casemap. 
>>>>> "upperLower" means
>>>>> ??? all characters are the same, except the last character which 
>>>>> requires
>>>>> ??? casemap.
>>>>>
>>>>> ??? I think the result is reasonable, considering surrogates check 
>>>>> are now
>>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>>> Arrays.mismatch() but
>>>>> ??? it did not seem to benefit here. In fact, the performance 
>>>>> degraded
>>>>> ??? partly because I implemented the short cut, and possibly for the
>>>>> ??? overhead of extra checks.
>>>>>
>>>>> ??? Naoto
>>>>>
>>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>>> ???? > Hello,
>>>>> ???? >
>>>>> ???? > Please review the fix to the following issues:
>>>>> ???? >
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>> ???? >
>>>>> ???? > The proposed changeset and its CSR are located at:
>>>>> ???? >
>>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>> ???? >
>>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>>> ??? locales in
>>>>> ???? > JDK15. The root cause was that case-insensitive
>>>>> ??? String.regionMatches()
>>>>> ???? > method did not work with supplementary characters. The 
>>>>> problem is
>>>>> ??? that
>>>>> ???? > the method's spec does not expect case mappings of 
>>>>> supplementary
>>>>> ???? > characters, possibly because it was overlooked in the first
>>>>> ??? place, JSR
>>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>>> behavior is
>>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>>> ???? >
>>>>> ???? > The fix is straightforward to compare strings by code point 
>>>>> basis,
>>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>>> ??? change will
>>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>>> ???? > incompatibility to wrong behavior, not true to the meaning 
>>>>> of those
>>>>> ???? > methods' expectations.
>>>>> ???? >
>>>>> ???? > Naoto
>>>>>
>>>


From aleksei.voitylov at bell-sw.com  Tue Jul 21 15:42:29 2020
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 21 Jul 2020 18:42:29 +0300
Subject: RFR: JDK-8248239: jpackage adds some arguments twice in case it
 is re-executed by JLI
In-Reply-To: <e0bb7682-ac03-6958-cb35-ada96ab5583f@oracle.com>
References: <c95dc5a8-650a-2bdf-0225-1d902ab8ae5f@bell-sw.com>
 <6d4fabe6-37ce-7d1d-bf7d-e2b07e0ba92b@oracle.com>
 <f59c4014-6d2f-9c2a-4846-d3e41991a9e4@bell-sw.com>
 <e0bb7682-ac03-6958-cb35-ada96ab5583f@oracle.com>
Message-ID: <6f2ae108-0c11-4294-7ff0-f7a975a0a8c3@bell-sw.com>

Hi,

This is the updated fix which checks if LD_LIBRARY_PATH has been changed
during jpackage executions:

http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/

The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
algorithm is used because standard C++ hash requires -std=c++11 or
-std=gnu++11 compiler options.

All test/jdk/tools/jpackage tests but ModulePathTest3.java pass on Linux
x86_64, MacOSX x86_64, and Windows x86_64. The test ModulePathTest3.java
is excluded in test/jdk/ProblemList.txt (8248418 generic-all).

Thanks,

-Aleksei

On 26/06/2020 20:23, Alexey Semenyuk wrote:
> Hi Aleksei,
>
> I think the idea of partial reading data from cfg file when the
> launcher is restarted has a flaw.
> It would be better if app launcher can detect if it was restarted and
> if it was, not read cfg file at all, but pass command line arguments
> as is in JLI_Launch().
> Let my think on ideas how to address this.
>
> - Alexey
>
> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>> Hi Alexey,
>>
>> Thank you for looking into it. As far as using parent pid, it does not
>> seem to work as example [1] demonstrates. The parent process remains the
>> same after re-execution and does not become the current process.
>>
>> I checked passing arguments in the "ArgOption" section using several
>> cases [2, 3, 4] with the proposed fix and app re-execution. The proposed
>> fix handles this case well, and the results are the same as without the
>> fix when the app is not re-executed.
>>
>> Case [3] where only JavaOptions without ArgOptions are passed to app
>> looks suspicious because default ArgOptions are not used. But it works
>> the same way without the proposed fix, which seems like a different
>> issue. According to jpackage documentation:
>>
>> ?? --arguments main class arguments
>> ???????? Command line arguments to pass to the main class if no command
>> line arguments are given to the launcher.
>>
>> I filed a separate issue [5] to handle that.
>>
>> Thanks,
>> -Aleksei
>>
>>
>> [1]
>> cd jdk-dev
>> make jdk-image
>> export PATH=build/linux-x86_64-server-release/images/jdk/bin:$PATH
>> export
>> LD_LIBRARY_PATH=build/linux-x86_64-server-release/images/jdk/lib/server
>> jpackage --dest output --name app --type app-image --module-path
>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>> --verbose --java-options -Dparam1=Param1
>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>> -------------
>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>> pid: 15927, parent? process: /bin/bash
>> JvmLauncher args: 10 [/home/sample/jdk-dev/output/app/bin/app
>> -Dparam1=Param1 --module-path
>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>> pid: 15927, parent? process: /bin/bash
>> JvmLauncher args: 15 [/home/sample/jdk-dev/output/app/bin/app
>> -Dparam1=Param1 --module-path
>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>> com.hello/com.hello.Hello -Dparam1=Param1 --module-path
>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>> -------------
>>
>> [2]
>> jpackage --dest output --name app --type app-image --module-path
>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>> --java-options -Dparam1=Param1
>> ./output/app/bin/app
>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>
>> [3]
>> jpackage --dest output --name app --type app-image --module-path
>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>> --java-options -Dparam1=Param1
>> ./output/app/bin/app -Dparam2=Param2
>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>
>> [4]
>> jpackage --dest output --name app --type app-image --module-path
>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>> --java-options -Dparam1=Param1
>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>> B2 B ]
>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>> B2 B ]
>>
>> [5] https://bugs.openjdk.java.net/browse/JDK-8248397
>>
>>
>> On 24/06/2020 19:34, Alexey Semenyuk wrote:
>>> Aleksei,
>>>
>>> If I get it right, the fix would not work for the case when there are
>>> `arguments` properties in `ArgOptions` section of a config file.
>>> Why not just check if the parent process is the same executable as the
>>> current one and if this is the case don't read data from the config
>>> file but pass executable arguments as is in JLI_Launch() call?
>>>
>>> - Alexey
>>>
>>> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>>>> Hi,
>>>>
>>>> There are systems that update LD_LIBRARY_PATH or directly return
>>>> JNI_TRUE in method RequiresSetenv(const char *jvmpath) from java_md.c
>>>> file to request re-execution of the current executable. This leads to
>>>> the fact that jpackage application adds some provided arguments twice.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
>>>> Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
>>>>
>>>> The root cause of the issue is that jpackage application expects one
>>>> number of arguments but JLI reexecutes them with another number of
>>>> arguments.
>>>> ?? For example, a jpackage application can be run with arguments:
>>>> ????? ./app/bin/app -Dparam2=Param2 B1 B2 B3
>>>> it adds arguments from the config file and calls JLI with arguments:
>>>> ????? app/bin/app -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello
>>>> -Dparam2=Param2 B1 B2 B3
>>>> JLI re-executes the app with new arguments so the app adds some
>>>> arguments one more time after the re-execution.
>>>> ????? ./app/bin/app -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
>>>>
>>>> A step by step example that illustrates the issue:
>>>>
>>>> Run jpackage to create an executable application:
>>>> ??? jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A1 A2
>>>> A3"
>>>> --verbose --java-options -Dparam1=Param1
>>>>
>>>> Executable application with the app/lib/app/app.cfg config file is
>>>> created:
>>>> ---- app.cfg? ----
>>>> [Application]
>>>> app.name=app
>>>> app.version=1.0
>>>> app.runtime=$ROOTDIR/lib/runtime
>>>> app.identifier=com.hello
>>>> app.classpath=
>>>> app.mainmodule=com.hello/com.hello.Hello
>>>>
>>>> [JavaOptions]
>>>> java-options=-Dparam1=Param1
>>>>
>>>> [ArgOptions]
>>>> arguments=A1
>>>> arguments=A2
>>>> arguments=A3
>>>> -----------
>>>>
>>>> Run the application:
>>>> ???? ./output/app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>
>>>> Chain of JDK methods execution:
>>>>
>>>> LinuxLauncher main()
>>>> ???? args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
>>>> AppLauncher createJvmLauncher()
>>>> ???? args: 4 [-Dparam2=Param2 B1 B2 B3 ]
>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>> app.cfg
>>>> ???? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>> AppLauncher Jvm::launch() -? JLI re-executes the app
>>>> LinuxLauncher main()
>>>> ??? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>> AppLauncher createJvmLauncher()
>>>> ???? args: 9 [-classpath? -Dparam1=Param1 -m com.hello/com.hello.Hello
>>>> -Dparam2=Param2 B1 B2 B3 ]
>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>> app.cfg
>>>> ???? args: 15 [./app/bin/app -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>> ????? ^^^
>>>>
>>>> Some arguments like "-classpath? -Dparam1=Param1 -m
>>>> com.hello/com.hello.Hello" are added twice.
>>>>
>>>> Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
>>>> regressions on Linux, Windows, Mac. On systems affected, the tests
>>>> now pass.
>>>>
>>>> Thanks,
>>>>
>>>> -Aleksei
>>>>
>>>>
>

From ioi.lam at oracle.com  Tue Jul 21 15:47:09 2020
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 21 Jul 2020 08:47:09 -0700
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <17cd90dd-2af5-2179-0d7e-4360f175a6de@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <17cd90dd-2af5-2179-0d7e-4360f175a6de@oss.nttdata.com>
Message-ID: <8fc34f52-7410-7579-a5da-b0f55bbb28fa@oracle.com>



On 7/17/20 6:48 AM, Yasumasa Suenaga wrote:
> Hi Koichi,
>
> On 2020/07/17 20:26, Koichi Sakata wrote:
>> Hi Daniel,
>>
>> ?> The changes to NetworkInterface.c look good to me.
>>
>> Thank you.
>>
>> ?> You'll need to find a reviewer that understands what that
>> ?> method is supposed to do in that case, that's not me ;-)
>>
>> I understand. This ML is suitable for finding a reviewer, isn't it?
>> Or, there is another way. We can avoid the error by the accepting 
>> maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.
>>
>> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk 
>> b/make/modules/java.base/lib/CoreLibraries.gmk
>> --- a/make/modules/java.base/lib/CoreLibraries.gmk
>> +++ b/make/modules/java.base/lib/CoreLibraries.gmk
>> @@ -48,7 +48,7 @@
>> ????? CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \
>> ????? CFLAGS_windows_debug := -DLOGGING, \
>> ????? CFLAGS_aix := -qfloat=nomaf, \
>> -??? DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
>> array-bounds, \
>> +??? DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
>> array-bounds maybe-uninitialized, \
>> ????? DISABLED_WARNINGS_clang := sign-compare, \
>> ????? DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>> ????? ARFLAGS := $(ARFLAGS), \
>
> This change affects all of C sources in core-libs.
> So I think it is better affect to k_standard.c only as below:
>
> ```
> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk 
> b/make/modules/java.base/lib/CoreLibraries.gmk
> --- a/make/modules/java.base/lib/CoreLibraries.gmk
> +++ b/make/modules/java.base/lib/CoreLibraries.gmk
> @@ -39,6 +39,10 @@
> ?LIBFDLIBM_SRC := $(TOPDIR)/src/java.base/share/native/libfdlibm
> ?LIBFDLIBM_CFLAGS := -I$(LIBFDLIBM_SRC) $(FDLIBM_CFLAGS)
>
> +ifeq ($(call isTargetOs, linux), true)
> +? BUILD_LIBFDLIBM_k_standard.c_CFLAGS += -Wno-maybe-uninitialized
> +endif
> +
> ?$(eval $(call SetupNativeCompilation, BUILD_LIBFDLIBM, \
> ???? NAME := fdlibm, \
> ???? TYPE := STATIC_LIBRARY, \
> ```
>
> You can pass compiler option to specified file.
>
>


Instead of modifying the makefiles, how about using a pragma in 
k_standard.c?

#ifdef __GNUC__
#if __GNUC__ >= 10
#pragma GCC diagnostic ignored "-Wno-maybe-uninitialized"
#endif
#endif


Thanks
- Ioi


> Thanks,
>
> Yasumasa
>
>
>> Thanks,
>> Koichi
>>
>> On 2020/07/15 3:36, Daniel Fuchs wrote:
>>> Hi Koichi,
>>>
>>> On 13/07/2020 08:03, Koichi Sakata wrote:
>>> ?> I understand that. I respect your idea.
>>> ?> I fixed the patch as follows.
>>> The changes to NetworkInterface.c look good to me.
>>>
>>> ?>
>>> ?> By the way, k_standard.c still remains. Is there a way to proceed 
>>> with it?
>>>
>>> You'll need to find a reviewer that understands what that
>>> method is supposed to do in that case, that's not me ;-)
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>> Thanks, > Koichi
>>>>
>>>> ===== PATCH =====
>>>> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
>>>> b/src/java.base/unix/native/libnet/NetworkInterface.c
>>>> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
>>>> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
>>>> @@ -1296,7 +1296,8 @@
>>>> ??static int getIndex(int sock, const char *name) {
>>>> ????? struct ifreq if2;
>>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>>> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
>>>> +??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
>>>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>>
>>>> ????? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>>>> ????????? return -1;
>>>> @@ -1359,7 +1360,8 @@
>>>> ??static int getFlags(int sock, const char *ifname, int *flags) {
>>>> ????? struct ifreq if2;
>>>> ????? memset((char *)&if2, 0, sizeof(if2));
>>>> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
>>>> +??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
>>>> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
>>>>
>>>> ????? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>>>> ????????? return -1;
>>>> diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
>>>> b/src/java.base/share/native/libfdlibm/k_standard.c
>>>> --- a/src/java.base/share/native/libfdlibm/k_standard.c
>>>> +++ b/src/java.base/share/native/libfdlibm/k_standard.c
>>>> @@ -739,6 +739,10 @@
>>>> ????????????????????????? errno = EDOM;
>>>> ????????????????? }
>>>> ????????????????? break;
>>>> +??????????? default:
>>>> +??????????????? exc.retval = zero;
>>>> +??????????????? errno = EINVAL;
>>>> +??????????????? break;
>>>> ????????? }
>>>> ????????? return exc.retval;
>>>> ??}
>>>>
>>>>
>>>


From huizhe.wang at oracle.com  Tue Jul 21 17:05:25 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 21 Jul 2020 10:05:25 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <36cb163f-9902-9d34-9c5a-c31f3b905eb9@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
 <186dfcff-5c57-bc5f-7e0f-a29d1ba65446@oracle.com>
 <36cb163f-9902-9d34-9c5a-c31f3b905eb9@oracle.com>
Message-ID: <6d7a2b63-de1c-698a-85d8-7b8be46e57ec@oracle.com>



On 7/20/2020 8:58 PM, naoto.sato at oracle.com wrote:
>> The short-cut worked well. There's maybe a further optimization we 
>> could do to rid us of the performance concern (or the need to run 
>> additional performance tests). Consider the cases where strings in 
>> comparison don't contain any sup characters, if we make the 
>> toLower/UpperCase() block a method and call it before and after the 
>> surrogate-check block, the routine would be effectively the same as 
>> prior to the introduction of the surrogate-check block, and regular 
>> comparisons would suffer the surrogate-check only once (the last 
>> check). For strings that do contain sup characters then, the 
>> toLower/UpperCase() method would have been called twice, but then we 
>> don't care about the performance in that situation. You may call the 
>> existing codePointAt method too when an extra getChar and performance 
>> is not a concern (but that's your call.
>
> Can you please elaborate this more? What's "the last check" here?

What I meant was that we could expand the 'short-cut' from case 
sensitive to case insensitive, that is in addition to the line 337, do 
that line 353 - 370 case-insensitive check as well.

I guess it can be explained better with code. I added inline comment:

 ??????? for (int k1 = toffset, k2 = ooffset; k1 < tlast && k2 < olast; 
k1++, k2++) {
 ??????????? int cp1 = (int)getChar(value, k1);
 ??????????? int cp2 = (int)getChar(other, k2);

// does a case-insensitive check:

 ??????????? if (checkEqual(cp1, cp2) == 0) {
 ??????????????? continue;
 ??????????? }

// this block will be run once for strings that don't contain any 
supplementary characters

 ???????????? // Check for supplementary characters case
 ??????????? cp1 = getSupplementaryCodePoint(value, cp1, k1, toffset, 
tlast);
 ??????????? if ((cp1 & Integer.MIN_VALUE) != 0) {
 ??????????????? k1++;
 ??????????????? cp1 ^= Integer.MIN_VALUE;
 ??????????? }
 ??????????? cp2 = getSupplementaryCodePoint(other, cp2, k2, ooffset, 
olast);
 ??????????? if ((cp2 & Integer.MIN_VALUE) != 0) {
 ??????????????? k2++;
 ??????????????? cp2 ^= Integer.MIN_VALUE;
 ??????????? }


// thischeck will have been called twice for strings that contain 
supplementary characters
// but only one more for strings that don't

 ??????????? int diff = checkEqual(cp1, cp2);
 ??????????? if (diff != 0) {
 ??????????????? return diff;
 ??????????? }
 ??????? }
 ??????? return tlen - olen;
 ??? }

// the code block between line 353 - 370 in webrev.04 except the last 
line (return 0):
 ??? private static int checkEqual(int cp1, int cp2) {
 ??????? if (cp1 != cp2) {
 ??????????? // try converting both characters to uppercase.
 ??????????? // If the results match, then the comparison scan should
 ??????????? // continue.
 ??????????? cp1 = Character.toUpperCase(cp1);
 ??????????? cp2 = Character.toUpperCase(cp2);
 ??????????? if (cp1 != cp2) {
 ??????????????? // Unfortunately, conversion to uppercase does not work 
properly
 ??????????????? // for the Georgian alphabet, which has strange rules 
about case
 ??????????????? // conversion.? So we need to make one last check before
 ??????????????? // exiting.
 ??????????????? cp1 = Character.toLowerCase(cp1);
 ??????????????? cp2 = Character.toLowerCase(cp2);
 ??????????????? if (cp1 != cp2) {
 ??????????????????? return cp1 - cp2;
 ??????????????? }
 ??????????? }
 ??????? }
 ??????? return 0;
 ??? }



>
> Naoto 


From jwrisavi at gmail.com  Tue Jul 21 07:29:54 2020
From: jwrisavi at gmail.com (Jessica)
Date: Tue, 21 Jul 2020 01:29:54 -0600
Subject: Feature Request
Message-ID: <CAOUAjNyJVEQLNbx6_GK9+Tmtujn1f4uWzzqaaWJ7QS9ATEgUfA@mail.gmail.com>

Hi,

I would like to strongly request Java have the ability to do string
interpolation.
It is such a great convenience and allows for faster, more efficient coding
that is easier to read.

Is this feature on the roadmap in the foreseeable future?

Thank you!

Jessica Risavi

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From mark at macchiato.com  Sat Jul 18 03:03:01 2020
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Fri, 17 Jul 2020 20:03:01 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
Message-ID: <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>

One option is to have a fast path that uses char functions, up to the point
where you hit a high surrogate, then drop into the slower codepoint path.
That saves time for the high-runner cases.

On the other hand, if the times are good enough, you might not need the
complication.

Mark


On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com> wrote:

> Hi,
>
> Based on the suggestions, I modified the fix as follows:
>
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>
> Changes from the initial revision are:
>
> - Shared the implementation between compareToCI() and regionMatchesCI()
> - Enabled immediate short cut if two code points match.
> - Created a simple JMH benchmark. Here is the scores before and after
> the change:
>
> before:
> Benchmark                                Mode  Cnt   Score   Error  Units
> StringCompareToIgnoreCase.lower          avgt   25  53.764 ? 2.811  ns/op
> StringCompareToIgnoreCase.supLower       avgt   25  24.211 ? 1.135  ns/op
> StringCompareToIgnoreCase.supUpperLower  avgt   25  30.595 ? 1.344  ns/op
> StringCompareToIgnoreCase.upperLower     avgt   25  18.859 ? 1.499  ns/op
>
> after:
> Benchmark                                Mode  Cnt   Score   Error  Units
> StringCompareToIgnoreCase.lower          avgt   25  58.354 ? 4.603  ns/op
> StringCompareToIgnoreCase.supLower       avgt   25  57.975 ? 5.672  ns/op
> StringCompareToIgnoreCase.supUpperLower  avgt   25  23.912 ? 0.965  ns/op
> StringCompareToIgnoreCase.upperLower     avgt   25  17.744 ? 0.272  ns/op
>
> Here, "sup" means all supplementary characters, BMP otherwise. "lower"
> means each character requires upper->lower casemap. "upperLower" means
> all characters are the same, except the last character which requires
> casemap.
>
> I think the result is reasonable, considering surrogates check are now
> mandatory. I have tried Roger's suggestion to use Arrays.mismatch() but
> it did not seem to benefit here. In fact, the performance degraded
> partly because I implemented the short cut, and possibly for the
> overhead of extra checks.
>
> Naoto
>
> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
> > Hello,
> >
> > Please review the fix to the following issues:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8248655
> > https://bugs.openjdk.java.net/browse/JDK-8248434
> >
> > The proposed changeset and its CSR are located at:
> >
> > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
> > https://bugs.openjdk.java.net/browse/JDK-8248664
> >
> > A bug was filed against SimpleDateFormat (8248434) where
> > case-insensitive date format/parse failed in some of the new locales in
> > JDK15. The root cause was that case-insensitive String.regionMatches()
> > method did not work with supplementary characters. The problem is that
> > the method's spec does not expect case mappings of supplementary
> > characters, possibly because it was overlooked in the first place, JSR
> > 204 - "Unicode Supplementary Character support". Similar behavior is
> > observed in other two case-insensitive methods, i.e.,
> > compareToIgnoreCase() and equalsIgnoreCase().
> >
> > The fix is straightforward to compare strings by code point basis,
> > instead of code unit (16bit "char") basis. Technically this change will
> > introduce a backward incompatibility, but I believe it is an
> > incompatibility to wrong behavior, not true to the meaning of those
> > methods' expectations.
> >
> > Naoto
>

From ningsheng.jian at arm.com  Mon Jul 20 03:51:25 2020
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Mon, 20 Jul 2020 11:51:25 +0800
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
Message-ID: <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>

Hi Andrew and all,

Since we are getting ready to propose Vector API target to JDK 16 [1]. I 
have regenerated webrev of aarch64 backend parts from panama repo, which 
has been rebased to jdk/jdk very recently, by:

$ hg update vector-unstable && hg diff -r default > all.patch
$ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk 
'{print $4}' > aarch64_list
$ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list

The new webrev:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Could you please help to take a look?

Yang's previous webrevs can still be found at [2], with review comments 
addressed in the latest webrev above.

[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-July/042427.html
[2] 
http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/


Thanks,
Ningsheng

On 7/8/20 3:05 PM, Yang Zhang wrote:
> Hi Andrew
> 
> I have updated this patch. Could you please help to review it again?
> In this patch, the following changes are made:
> 1. Separate newly added NEON instructions to a new ad file
>     aarch64_neon.ad
> 2. Add assembler tests for NEON instructions. Trailing spaces
>     in the python script are also removed.
> 
> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/
> 
> Thanks,
> Yang
> 
> 
> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Tuesday, June 30, 2020 12:10 AM
> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes
> 
> On 29/06/2020 08:48, Yang Zhang wrote:
>> 1. Instructions that can be matched with NEON instructions directly.
>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>
>> 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly.
>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved.
>>
>> 3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc.
>> These instructions cannot be moved into jdk master first because there isn't middle-end support.
>>
>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again.
> 
> Thank you *very* much for your hard work. Appreciated!
> 
> --
> 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 LANCE.ANDERSEN at ORACLE.COM  Tue Jul 21 17:18:57 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Tue, 21 Jul 2020 13:18:57 -0400
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <07bf53e1-9eee-8391-51aa-da814b7a37ee@oracle.com>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
 <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
 <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>
 <9d351d78-88c1-9e6d-28a0-9aa6c552c251@gmail.com>
 <4202609E-F2B7-4C81-B325-B470BD79EA67@oracle.com>
 <07bf53e1-9eee-8391-51aa-da814b7a37ee@oracle.com>
Message-ID: <85BFF8D3-ACEE-49FC-AC37-64FB2CBB05CE@ORACLE.COM>

Hi Roger,

I will plan to push tomorrow morning pending any last minute reviews

Best
Lance

> On Jul 21, 2020, at 9:57 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Rafaello, Lance,
> 
> That looks good to me.  
> 
> Thanks, Roger
> 
> On 7/19/20 2:31 PM, Lance Andersen wrote:
>> Hi Raffaello,
>> 
>> I think the changes look reasonable.
>> 
>> I have created a webrev, http://cr.openjdk.java.net/~lancea/8222187/webrev.00/ <http://cr.openjdk.java.net/~lancea/8222187/webrev.00/>, for others to review as it is a bit easier than the patch.
>> 
>> I have also run the JCK tests in this area as well as mach5 tiers1-3 (which I believe Roger has also)
>> 
>> Best
>> Lance
>> 
>>> On Jul 15, 2020, at 5:44 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com <mailto:raffaello.giulietti at gmail.com>> wrote:
>>> 
>>> Hi Roger,
>>> 
>>> On 2020-07-15 22:21, Roger Riggs wrote:
>>>> Hi Raffaello,
>>>> Base64.java:
>>>> 2: Please update 2nd copyright year to 2020
>>> 
>>> I was unsure what to do here, thanks for guidance.
>>> I also removed the seemingly useless import at former L33.
>>> 
>>> 
>>> 
>>>> leftovers():
>>>> 996: "&" the shortcutting && is more typical in a condition.
>>>> 997: the -= is buried in an expression and a reader might miss it.
>>> 
>>> Corrected, as well as the analogous -= usage for wpos now at L1106-7
>>> 
>>> 
>>>> 1053:  "can be reallocated to other vars":  not a useful comment, reflecting on only one possible implementation that is out of the control of the developer.
>>>> I'd almost rather see 'len' than 'limit - off'; it might be informative to the reader if 'limit' was declared final. (1056:)
>>> 
>>> Done, as well as declaring i and v final in the loop.
>>> 
>>> 
>>> 
>>>> TestBase54.java:
>>>> 2: Update 2nd copyright year to 2020
>>>> 27:  Please add the bug number to the @bug line.
>>>> Style-wise, I would remove the blank lines at the beginning of blocks. (1095, 1115)
>>> 
>>> Done.
>>> 
>>> 
>>>> Thanks, Roger
>>>> On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
>>>>> Hi Roger,
>>>>> 
>>>>> here's the latest version of the patch.
>>>>> 
>>>>> I did:
>>>>> * Withdraw the simplification in encodedOutLength(), as it is indeed out of scope for this bug fix.
>>>>> * Restore field names in DecInputStream except for nextin (now wpos) and nextout (now rpos) because they have slightly different semantics. That's just for clarity. I would have nothing against reusing the old names for the proposed purpose.
>>>>> * Switch back to the original no-arg read() implementation.
>>>>> * Adjust comment continuation lines.
>>>>> * Preserve the proposed logic of read(byte[], int, int) and the supporting methods.
>>>>> 
>>>>> Others needed changes are:
>>>>> * Correct the copyright years: that's something better left to Oracle.
>>>>> * Remove the apparently useless import at L33. I could build and run without it.
>>>>> 
>>>>> 
>>>>> Greetings
>>>>> Raffaello
>>>>> 
>>> 
>>> 
>>> ----
>>> 
>>> # HG changeset patch
>>> # User lello
>>> # Date 1594848775 -7200
>>> #      Wed Jul 15 23:32:55 2020 +0200
>>> # Node ID f7407f35e83ab508f0e6deab4f776bb1a1c85e68
>>> # Parent  a5649ebf94193770ca763391dd63807059d333b4
>>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end
>>> Reviewed-by: TBD
>>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com <mailto:raffaello.giulietti at gmail.com>>
>>> 
>>> diff --git a/src/java.base/share/classes/java/util/Base64.java b/src/java.base/share/classes/java/util/Base64.java
>>> --- a/src/java.base/share/classes/java/util/Base64.java
>>> +++ b/src/java.base/share/classes/java/util/Base64.java
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2012, 2020, 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
>>> @@ -30,7 +30,6 @@
>>> import java.io.IOException;
>>> import java.io.OutputStream;
>>> import java.nio.ByteBuffer;
>>> -import java.nio.charset.StandardCharsets;
>>> 
>>> import sun.nio.cs.ISO_8859_1;
>>> 
>>> @@ -961,12 +960,15 @@
>>> 
>>>         private final InputStream is;
>>>         private final boolean isMIME;
>>> -        private final int[] base64;      // base64 -> byte mapping
>>> -        private int bits = 0;            // 24-bit buffer for decoding
>>> -        private int nextin = 18;         // next available "off" in "bits" for input;
>>> -                                         // -> 18, 12, 6, 0
>>> -        private int nextout = -8;        // next available "off" in "bits" for output;
>>> -                                         // -> 8, 0, -8 (no byte for output)
>>> +        private final int[] base64;     // base64 -> byte mapping
>>> +        private int bits = 0;           // 24-bit buffer for decoding
>>> +
>>> +        /* writing bit pos inside bits; one of 24 (left, msb), 18, 12, 6, 0 */
>>> +        private int wpos = 0;
>>> +
>>> +        /* reading bit pos inside bits: one of 24 (left, msb), 16, 8, 0 */
>>> +        private int rpos = 0;
>>> +
>>>         private boolean eof = false;
>>>         private boolean closed = false;
>>> 
>>> @@ -983,107 +985,153 @@
>>>             return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>>>         }
>>> 
>>> -        private int eof(byte[] b, int off, int len, int oldOff)
>>> -            throws IOException
>>> -        {
>>> +        private int leftovers(byte[] b, int off, int pos, int limit) {
>>>             eof = true;
>>> -            if (nextin != 18) {
>>> -                if (nextin == 12)
>>> -                    throw new IOException("Base64 stream has one un-decoded dangling byte.");
>>> -                // treat ending xx/xxx without padding character legal.
>>> -                // same logic as v == '=' below
>>> -                b[off++] = (byte)(bits >> (16));
>>> -                if (nextin == 0) {           // only one padding byte
>>> -                    if (len == 1) {          // no enough output space
>>> -                        bits >>= 8;          // shift to lowest byte
>>> -                        nextout = 0;
>>> -                    } else {
>>> -                        b[off++] = (byte) (bits >>  8);
>>> -                    }
>>> -                }
>>> +
>>> +            /*
>>> +             * We use a loop here, as this method is executed only a few times.
>>> +             * Unrolling the loop would probably not contribute much here.
>>> +             */
>>> +            while (rpos - 8 >= wpos && pos != limit) {
>>> +                rpos -= 8;
>>> +                b[pos++] = (byte) (bits >> rpos);
>>>             }
>>> -            return off == oldOff ? -1 : off - oldOff;
>>> +            return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
>>>         }
>>> 
>>> -        private int padding(byte[] b, int off, int len, int oldOff)
>>> -            throws IOException
>>> -        {
>>> -            // =     shiftto==18 unnecessary padding
>>> -            // x=    shiftto==12 dangling x, invalid unit
>>> -            // xx=   shiftto==6 && missing last '='
>>> -            // xx=y  or last is not '='
>>> -            if (nextin == 18 || nextin == 12 ||
>>> -                nextin == 6 && is.read() != '=') {
>>> -                throw new IOException("Illegal base64 ending sequence:" + nextin);
>>> +        private int eof(byte[] b, int off, int pos, int limit) throws IOException {
>>> +            /*
>>> +             * pos != limit
>>> +             *
>>> +             * wpos == 18: x     dangling single x, invalid unit
>>> +             * accept ending xx or xxx without padding characters
>>> +             */
>>> +            if (wpos == 18) {
>>> +                throw new IOException("Base64 stream has one un-decoded dangling byte.");
>>>             }
>>> -            b[off++] = (byte)(bits >> (16));
>>> -            if (nextin == 0) {           // only one padding byte
>>> -                if (len == 1) {          // no enough output space
>>> -                    bits >>= 8;          // shift to lowest byte
>>> -                    nextout = 0;
>>> -                } else {
>>> -                    b[off++] = (byte) (bits >>  8);
>>> -                }
>>> +            rpos = 24;
>>> +            return leftovers(b, off, pos, limit);
>>> +        }
>>> +
>>> +        private int padding(byte[] b, int off, int pos, int limit) throws IOException {
>>> +            /*
>>> +             * pos != limit
>>> +             *
>>> +             * wpos == 24: =    (unnecessary padding)
>>> +             * wpos == 18: x=   (dangling single x, invalid unit)
>>> +             * wpos == 12 and missing last '=': xx=  (invalid padding)
>>> +             * wpos == 12 and last is not '=': xx=x (invalid padding)
>>> +             */
>>> +            if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>>> +                throw new IOException("Illegal base64 ending sequence:" + wpos);
>>>             }
>>> -            eof = true;
>>> -            return off - oldOff;
>>> +            rpos = 24;
>>> +            return leftovers(b, off, pos, limit);
>>>         }
>>> 
>>>         @Override
>>>         public int read(byte[] b, int off, int len) throws IOException {
>>> -            if (closed)
>>> +            if (closed) {
>>>                 throw new IOException("Stream is closed");
>>> -            if (eof && nextout < 0)    // eof and no leftover
>>> -                return -1;
>>> -            if (off < 0 || len < 0 || len > b.length - off)
>>> -                throw new IndexOutOfBoundsException();
>>> -            int oldOff = off;
>>> -            while (nextout >= 0) {       // leftover output byte(s) in bits buf
>>> -                if (len == 0)
>>> -                    return off - oldOff;
>>> -                b[off++] = (byte)(bits >> nextout);
>>> -                len--;
>>> -                nextout -= 8;
>>> +            }
>>> +            Objects.checkFromIndexSize(off, len, b.length);
>>> +            if (len == 0) {
>>> +                return 0;
>>>             }
>>> -            bits = 0;
>>> -            while (len > 0) {
>>> -                int v = is.read();
>>> -                if (v == -1) {
>>> -                    return eof(b, off, len, oldOff);
>>> +
>>> +            /*
>>> +             * Rather than keeping 2 running vars (e.g., off and len),
>>> +             * we only keep one (pos), while definitely fixing the boundaries
>>> +             * of the range [off, limit).
>>> +             * More specifically, each use of pos as an index in b meets
>>> +             *      pos - off >= 0 & limit - pos > 0
>>> +             *
>>> +             * Note that limit can overflow to Integer.MIN_VALUE. However,
>>> +             * as long as comparisons with pos are as coded, there's no harm.
>>> +             */
>>> +            int pos = off;
>>> +            final int limit = off + len;
>>> +            if (eof) {
>>> +                return leftovers(b, off, pos, limit);
>>> +            }
>>> +
>>> +            /*
>>> +             * Leftovers from previous invocation; here, wpos = 0.
>>> +             * There can be at most 2 leftover bytes (rpos <= 16).
>>> +             * Further, b has at least one free place.
>>> +             *
>>> +             * The logic could be coded as a loop, (as in method leftovers())
>>> +             * but the explicit "unrolling" makes it possible to generate
>>> +             * better byte extraction code.
>>> +             */
>>> +            if (rpos == 16) {
>>> +                b[pos++] = (byte) (bits >> 8);
>>> +                rpos = 8;
>>> +                if (pos == limit) {
>>> +                    return len;
>>>                 }
>>> -                if ((v = base64[v]) < 0) {
>>> -                    if (v == -2) {       // padding byte(s)
>>> -                        return padding(b, off, len, oldOff);
>>> -                    }
>>> -                    if (v == -1) {
>>> -                        if (!isMIME)
>>> -                            throw new IOException("Illegal base64 character " +
>>> -                                Integer.toString(v, 16));
>>> -                        continue;        // skip if for rfc2045
>>> -                    }
>>> -                    // neve be here
>>> -                }
>>> -                bits |= (v << nextin);
>>> -                if (nextin == 0) {
>>> -                    nextin = 18;         // clear for next in
>>> -                    b[off++] = (byte)(bits >> 16);
>>> -                    if (len == 1) {
>>> -                        nextout = 8;    // 2 bytes left in bits
>>> -                        break;
>>> -                    }
>>> -                    b[off++] = (byte)(bits >> 8);
>>> -                    if (len == 2) {
>>> -                        nextout = 0;    // 1 byte left in bits
>>> -                        break;
>>> -                    }
>>> -                    b[off++] = (byte)bits;
>>> -                    len -= 3;
>>> -                    bits = 0;
>>> -                } else {
>>> -                    nextin -= 6;
>>> +            }
>>> +            if (rpos == 8) {
>>> +                b[pos++] = (byte) bits;
>>> +                rpos = 0;
>>> +                if (pos == limit) {
>>> +                    return len;
>>>                 }
>>>             }
>>> -            return off - oldOff;
>>> +
>>> +            bits = 0;
>>> +            wpos = 24;
>>> +            for (;;) {
>>> +                /* pos != limit & rpos == 0 */
>>> +                final int i = is.read();
>>> +                if (i < 0) {
>>> +                    return eof(b, off, pos, limit);
>>> +                }
>>> +                final int v = base64[i];
>>> +                if (v < 0) {
>>> +                    /*
>>> +                     * i not in alphabet, thus
>>> +                     *      v == -2: i is '=', the padding
>>> +                     *      v == -1: i is something else, typically CR or LF
>>> +                     */
>>> +                    if (v == -1) {
>>> +                        if (isMIME) {
>>> +                            continue;
>>> +                        }
>>> +                        throw new IOException("Illegal base64 character 0x" +
>>> +                                Integer.toHexString(i));
>>> +                    }
>>> +                    return padding(b, off, pos, limit);
>>> +                }
>>> +                wpos -= 6;
>>> +                bits |= v << wpos;
>>> +                if (wpos != 0) {
>>> +                    continue;
>>> +                }
>>> +                if (limit - pos >= 3) {
>>> +                    /* frequently taken fast path, no need to track rpos */
>>> +                    b[pos++] = (byte) (bits >> 16);
>>> +                    b[pos++] = (byte) (bits >> 8);
>>> +                    b[pos++] = (byte) bits;
>>> +                    bits = 0;
>>> +                    wpos = 24;
>>> +                    if (pos == limit) {
>>> +                        return len;
>>> +                    }
>>> +                    continue;
>>> +                }
>>> +
>>> +                /* b has either 1 or 2 free places */
>>> +                b[pos++] = (byte) (bits >> 16);
>>> +                if (pos == limit) {
>>> +                    rpos = 16;
>>> +                    return len;
>>> +                }
>>> +                b[pos++] = (byte) (bits >> 8);
>>> +                /* pos == limit, no need for an if */
>>> +                rpos = 8;
>>> +                return len;
>>> +            }
>>>         }
>>> 
>>>         @Override
>>> diff --git a/test/jdk/java/util/Base64/TestBase64.java b/test/jdk/java/util/Base64/TestBase64.java
>>> --- a/test/jdk/java/util/Base64/TestBase64.java
>>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2012, 2020, 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
>>> @@ -24,7 +24,7 @@
>>> /**
>>>  * @test
>>>  * @bug 4235519 8004212 8005394 8007298 8006295 8006315 8006530 8007379 8008925
>>> - *      8014217 8025003 8026330 8028397 8129544 8165243 8176379
>>> + *      8014217 8025003 8026330 8028397 8129544 8165243 8176379 8222187
>>>  * @summary tests java.util.Base64
>>>  * @library /test/lib
>>>  * @build jdk.test.lib.RandomFactory
>>> @@ -144,6 +144,10 @@
>>>         testDecoderKeepsAbstinence(Base64.getDecoder());
>>>         testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>>>         testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>>> +
>>> +        // tests patch addressing JDK-8222187
>>> +        // https://bugs.openjdk.java.net/browse/JDK-8222187 <https://bugs.openjdk.java.net/browse/JDK-8222187>
>>> +        testJDK_8222187();
>>>     }
>>> 
>>>     private static void test(Base64.Encoder enc, Base64.Decoder dec,
>>> @@ -607,4 +611,26 @@
>>>             }
>>>         }
>>>     }
>>> +
>>> +    private static void testJDK_8222187() throws Throwable {
>>> +        byte[] orig = "12345678".getBytes("US-ASCII");
>>> +        byte[] encoded = Base64.getEncoder().encode(orig);
>>> +        // decode using different buffer sizes, up to a longer one than needed
>>> +        for (int bufferSize = 1; bufferSize <= encoded.length + 1; bufferSize++) {
>>> +            try (
>>> +                    InputStream in = Base64.getDecoder().wrap(
>>> +                            new ByteArrayInputStream(encoded));
>>> +                    ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>> +            ) {
>>> +                byte[] buffer = new byte[bufferSize];
>>> +                int read;
>>> +                while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>>> +                    baos.write(buffer, 0, read);
>>> +                }
>>> +                // compare result, output info if lengths do not match
>>> +                byte[] decoded = baos.toByteArray();
>>> +                checkEqual(decoded, orig, "Base64 stream decoding failed!");
>>> +            }
>>> +        }
>>> +    }
>>> }
>>> <JDK-8222187.patch>
>> 
>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From openjdk at icemanx.nl  Tue Jul 21 17:32:16 2020
From: openjdk at icemanx.nl (Rob Spoor)
Date: Tue, 21 Jul 2020 19:32:16 +0200
Subject: Feature Request
In-Reply-To: <CAOUAjNyJVEQLNbx6_GK9+Tmtujn1f4uWzzqaaWJ7QS9ATEgUfA@mail.gmail.com>
References: <CAOUAjNyJVEQLNbx6_GK9+Tmtujn1f4uWzzqaaWJ7QS9ATEgUfA@mail.gmail.com>
Message-ID: <2e89b901-cdca-ef25-6518-ef115e84a904@icemanx.nl>

If you need something right now, you can try 
https://commons.apache.org/proper/commons-text/javadocs/api-release/org/apache/commons/text/StringSubstitutor.html.


On 21/07/2020 09:29, Jessica wrote:
> Hi,
> 
> I would like to strongly request Java have the ability to do string
> interpolation.
> It is such a great convenience and allows for faster, more efficient coding
> that is easier to read.
> 
> Is this feature on the roadmap in the foreseeable future?
> 
> Thank you!
> 
> Jessica Risavi
> 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From aleksei.voitylov at bell-sw.com  Tue Jul 21 17:37:36 2020
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 21 Jul 2020 20:37:36 +0300
Subject: RFR: JDK-8247592: refactor
 test/jdk/tools/launcher/Test7029048.java
In-Reply-To: <0bd8fc50-81d4-c40c-ede5-907bd7fc6144@bell-sw.com>
References: <0bd8fc50-81d4-c40c-ede5-907bd7fc6144@bell-sw.com>
Message-ID: <8f811a92-a646-4732-8edd-4f8baae43180@bell-sw.com>

Hi,

gently reminiding about this simple test refactoring. The patch still
applies cleanly.

-Aleksei

On 24/06/2020 11:44, Aleksei Voitylov wrote:
> Hi,
>
> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
> logic easier to follow and remove some magic numbers from the test:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8247592
> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>
> Testing: the test passes on Linux x86, Linux x86_64, Linux ARM, Linux
> AArch64, Linux PPC, Windows x86, Windows x86_64, Mac, AIX. Special
> thanks to SAP team for helping test on AIX.
>
> Thanks,
> -Aleksei
>

From justin.dekeyser at gmail.com  Tue Jul 21 17:39:04 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Tue, 21 Jul 2020 19:39:04 +0200
Subject: Feature Request
In-Reply-To: <CAOUAjNyJVEQLNbx6_GK9+Tmtujn1f4uWzzqaaWJ7QS9ATEgUfA@mail.gmail.com>
References: <CAOUAjNyJVEQLNbx6_GK9+Tmtujn1f4uWzzqaaWJ7QS9ATEgUfA@mail.gmail.com>
Message-ID: <CAO5-QM1qOHAVh0QuzhdK6Q4SEFko7pt=MABdKpenLi65ysq1UA@mail.gmail.com>

Hello,

Wouldn't that be too dangerous, in the sense that it makes us lose control
over how the String are actually constructed and aggregated together?

Aside from that, what kind of interpolation are you looking for, and how
the String.format utility does not meet your needs?

Regards,

D.J.


On Tue, Jul 21, 2020 at 7:08 PM Jessica <jwrisavi at gmail.com> wrote:

> Hi,
>
> I would like to strongly request Java have the ability to do string
> interpolation.
> It is such a great convenience and allows for faster, more efficient coding
> that is easier to read.
>
> Is this feature on the roadmap in the foreseeable future?
>
> Thank you!
>
> Jessica Risavi
>
> <
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

From alexey.semenyuk at oracle.com  Tue Jul 21 18:27:18 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 21 Jul 2020 14:27:18 -0400
Subject: RFR: JDK-8248239: jpackage adds some arguments twice in case it
 is re-executed by JLI
In-Reply-To: <6f2ae108-0c11-4294-7ff0-f7a975a0a8c3@bell-sw.com>
References: <c95dc5a8-650a-2bdf-0225-1d902ab8ae5f@bell-sw.com>
 <6d4fabe6-37ce-7d1d-bf7d-e2b07e0ba92b@oracle.com>
 <f59c4014-6d2f-9c2a-4846-d3e41991a9e4@bell-sw.com>
 <e0bb7682-ac03-6958-cb35-ada96ab5583f@oracle.com>
 <6f2ae108-0c11-4294-7ff0-f7a975a0a8c3@bell-sw.com>
Message-ID: <dff41f8f-fdd2-d99f-c292-fb6003ce06fd@oracle.com>

Hi Aleksei,

Looks good!

- Alexey

On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
> Hi,
>
> This is the updated fix which checks if LD_LIBRARY_PATH has been changed
> during jpackage executions:
>
> http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
>
> The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
> variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
> algorithm is used because standard C++ hash requires -std=c++11 or
> -std=gnu++11 compiler options.
>
> All test/jdk/tools/jpackage tests but ModulePathTest3.java pass on Linux
> x86_64, MacOSX x86_64, and Windows x86_64. The test ModulePathTest3.java
> is excluded in test/jdk/ProblemList.txt (8248418 generic-all).
>
> Thanks,
>
> -Aleksei
>
> On 26/06/2020 20:23, Alexey Semenyuk wrote:
>> Hi Aleksei,
>>
>> I think the idea of partial reading data from cfg file when the
>> launcher is restarted has a flaw.
>> It would be better if app launcher can detect if it was restarted and
>> if it was, not read cfg file at all, but pass command line arguments
>> as is in JLI_Launch().
>> Let my think on ideas how to address this.
>>
>> - Alexey
>>
>> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>>> Hi Alexey,
>>>
>>> Thank you for looking into it. As far as using parent pid, it does not
>>> seem to work as example [1] demonstrates. The parent process remains the
>>> same after re-execution and does not become the current process.
>>>
>>> I checked passing arguments in the "ArgOption" section using several
>>> cases [2, 3, 4] with the proposed fix and app re-execution. The proposed
>>> fix handles this case well, and the results are the same as without the
>>> fix when the app is not re-executed.
>>>
>>> Case [3] where only JavaOptions without ArgOptions are passed to app
>>> looks suspicious because default ArgOptions are not used. But it works
>>> the same way without the proposed fix, which seems like a different
>>> issue. According to jpackage documentation:
>>>
>>>  ?? --arguments main class arguments
>>>  ???????? Command line arguments to pass to the main class if no command
>>> line arguments are given to the launcher.
>>>
>>> I filed a separate issue [5] to handle that.
>>>
>>> Thanks,
>>> -Aleksei
>>>
>>>
>>> [1]
>>> cd jdk-dev
>>> make jdk-image
>>> export PATH=build/linux-x86_64-server-release/images/jdk/bin:$PATH
>>> export
>>> LD_LIBRARY_PATH=build/linux-x86_64-server-release/images/jdk/lib/server
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --verbose --java-options -Dparam1=Param1
>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>> -------------
>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>> pid: 15927, parent? process: /bin/bash
>>> JvmLauncher args: 10 [/home/sample/jdk-dev/output/app/bin/app
>>> -Dparam1=Param1 --module-path
>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>> pid: 15927, parent? process: /bin/bash
>>> JvmLauncher args: 15 [/home/sample/jdk-dev/output/app/bin/app
>>> -Dparam1=Param1 --module-path
>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>> com.hello/com.hello.Hello -Dparam1=Param1 --module-path
>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>> -------------
>>>
>>> [2]
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --java-options -Dparam1=Param1
>>> ./output/app/bin/app
>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>
>>> [3]
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --java-options -Dparam1=Param1
>>> ./output/app/bin/app -Dparam2=Param2
>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>>
>>> [4]
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --java-options -Dparam1=Param1
>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>> B2 B ]
>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>> B2 B ]
>>>
>>> [5] https://bugs.openjdk.java.net/browse/JDK-8248397
>>>
>>>
>>> On 24/06/2020 19:34, Alexey Semenyuk wrote:
>>>> Aleksei,
>>>>
>>>> If I get it right, the fix would not work for the case when there are
>>>> `arguments` properties in `ArgOptions` section of a config file.
>>>> Why not just check if the parent process is the same executable as the
>>>> current one and if this is the case don't read data from the config
>>>> file but pass executable arguments as is in JLI_Launch() call?
>>>>
>>>> - Alexey
>>>>
>>>> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>>>>> Hi,
>>>>>
>>>>> There are systems that update LD_LIBRARY_PATH or directly return
>>>>> JNI_TRUE in method RequiresSetenv(const char *jvmpath) from java_md.c
>>>>> file to request re-execution of the current executable. This leads to
>>>>> the fact that jpackage application adds some provided arguments twice.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
>>>>> Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
>>>>>
>>>>> The root cause of the issue is that jpackage application expects one
>>>>> number of arguments but JLI reexecutes them with another number of
>>>>> arguments.
>>>>>  ?? For example, a jpackage application can be run with arguments:
>>>>>  ????? ./app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>> it adds arguments from the config file and calls JLI with arguments:
>>>>>  ????? app/bin/app -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello
>>>>> -Dparam2=Param2 B1 B2 B3
>>>>> JLI re-executes the app with new arguments so the app adds some
>>>>> arguments one more time after the re-execution.
>>>>>  ????? ./app/bin/app -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
>>>>>
>>>>> A step by step example that illustrates the issue:
>>>>>
>>>>> Run jpackage to create an executable application:
>>>>>  ??? jpackage --dest output --name app --type app-image --module-path
>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A1 A2
>>>>> A3"
>>>>> --verbose --java-options -Dparam1=Param1
>>>>>
>>>>> Executable application with the app/lib/app/app.cfg config file is
>>>>> created:
>>>>> ---- app.cfg? ----
>>>>> [Application]
>>>>> app.name=app
>>>>> app.version=1.0
>>>>> app.runtime=$ROOTDIR/lib/runtime
>>>>> app.identifier=com.hello
>>>>> app.classpath=
>>>>> app.mainmodule=com.hello/com.hello.Hello
>>>>>
>>>>> [JavaOptions]
>>>>> java-options=-Dparam1=Param1
>>>>>
>>>>> [ArgOptions]
>>>>> arguments=A1
>>>>> arguments=A2
>>>>> arguments=A3
>>>>> -----------
>>>>>
>>>>> Run the application:
>>>>>  ???? ./output/app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>
>>>>> Chain of JDK methods execution:
>>>>>
>>>>> LinuxLauncher main()
>>>>>  ???? args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
>>>>> AppLauncher createJvmLauncher()
>>>>>  ???? args: 4 [-Dparam2=Param2 B1 B2 B3 ]
>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>> app.cfg
>>>>>  ???? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>> AppLauncher Jvm::launch() -? JLI re-executes the app
>>>>> LinuxLauncher main()
>>>>>  ??? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>> AppLauncher createJvmLauncher()
>>>>>  ???? args: 9 [-classpath? -Dparam1=Param1 -m com.hello/com.hello.Hello
>>>>> -Dparam2=Param2 B1 B2 B3 ]
>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>> app.cfg
>>>>>  ???? args: 15 [./app/bin/app -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>  ????? ^^^
>>>>>
>>>>> Some arguments like "-classpath? -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello" are added twice.
>>>>>
>>>>> Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
>>>>> regressions on Linux, Windows, Mac. On systems affected, the tests
>>>>> now pass.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Aleksei
>>>>>
>>>>>


From naoto.sato at oracle.com  Tue Jul 21 21:01:35 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jul 2020 14:01:35 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <6d7a2b63-de1c-698a-85d8-7b8be46e57ec@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
 <186dfcff-5c57-bc5f-7e0f-a29d1ba65446@oracle.com>
 <36cb163f-9902-9d34-9c5a-c31f3b905eb9@oracle.com>
 <6d7a2b63-de1c-698a-85d8-7b8be46e57ec@oracle.com>
Message-ID: <fbefd763-69b7-3845-8bd4-458d034a934d@oracle.com>

Thank you, Joe. I got it now. Will try out and benchmark.

Naoto

On 7/21/20 10:05 AM, Joe Wang wrote:
> 
> 
> On 7/20/2020 8:58 PM, naoto.sato at oracle.com wrote:
>>> The short-cut worked well. There's maybe a further optimization we 
>>> could do to rid us of the performance concern (or the need to run 
>>> additional performance tests). Consider the cases where strings in 
>>> comparison don't contain any sup characters, if we make the 
>>> toLower/UpperCase() block a method and call it before and after the 
>>> surrogate-check block, the routine would be effectively the same as 
>>> prior to the introduction of the surrogate-check block, and regular 
>>> comparisons would suffer the surrogate-check only once (the last 
>>> check). For strings that do contain sup characters then, the 
>>> toLower/UpperCase() method would have been called twice, but then we 
>>> don't care about the performance in that situation. You may call the 
>>> existing codePointAt method too when an extra getChar and performance 
>>> is not a concern (but that's your call.
>>
>> Can you please elaborate this more? What's "the last check" here?
> 
> What I meant was that we could expand the 'short-cut' from case 
> sensitive to case insensitive, that is in addition to the line 337, do 
> that line 353 - 370 case-insensitive check as well.
> 
> I guess it can be explained better with code. I added inline comment:
> 
>  ??????? for (int k1 = toffset, k2 = ooffset; k1 < tlast && k2 < olast; 
> k1++, k2++) {
>  ??????????? int cp1 = (int)getChar(value, k1);
>  ??????????? int cp2 = (int)getChar(other, k2);
> 
> // does a case-insensitive check:
> 
>  ??????????? if (checkEqual(cp1, cp2) == 0) {
>  ??????????????? continue;
>  ??????????? }
> 
> // this block will be run once for strings that don't contain any 
> supplementary characters
> 
>  ???????????? // Check for supplementary characters case
>  ??????????? cp1 = getSupplementaryCodePoint(value, cp1, k1, toffset, 
> tlast);
>  ??????????? if ((cp1 & Integer.MIN_VALUE) != 0) {
>  ??????????????? k1++;
>  ??????????????? cp1 ^= Integer.MIN_VALUE;
>  ??????????? }
>  ??????????? cp2 = getSupplementaryCodePoint(other, cp2, k2, ooffset, 
> olast);
>  ??????????? if ((cp2 & Integer.MIN_VALUE) != 0) {
>  ??????????????? k2++;
>  ??????????????? cp2 ^= Integer.MIN_VALUE;
>  ??????????? }
> 
> 
> // thischeck will have been called twice for strings that contain 
> supplementary characters
> // but only one more for strings that don't
> 
>  ??????????? int diff = checkEqual(cp1, cp2);
>  ??????????? if (diff != 0) {
>  ??????????????? return diff;
>  ??????????? }
>  ??????? }
>  ??????? return tlen - olen;
>  ??? }
> 
> // the code block between line 353 - 370 in webrev.04 except the last 
> line (return 0):
>  ??? private static int checkEqual(int cp1, int cp2) {
>  ??????? if (cp1 != cp2) {
>  ??????????? // try converting both characters to uppercase.
>  ??????????? // If the results match, then the comparison scan should
>  ??????????? // continue.
>  ??????????? cp1 = Character.toUpperCase(cp1);
>  ??????????? cp2 = Character.toUpperCase(cp2);
>  ??????????? if (cp1 != cp2) {
>  ??????????????? // Unfortunately, conversion to uppercase does not work 
> properly
>  ??????????????? // for the Georgian alphabet, which has strange rules 
> about case
>  ??????????????? // conversion.? So we need to make one last check before
>  ??????????????? // exiting.
>  ??????????????? cp1 = Character.toLowerCase(cp1);
>  ??????????????? cp2 = Character.toLowerCase(cp2);
>  ??????????????? if (cp1 != cp2) {
>  ??????????????????? return cp1 - cp2;
>  ??????????????? }
>  ??????????? }
>  ??????? }
>  ??????? return 0;
>  ??? }
> 
> 
> 
>>
>> Naoto 
> 

From naoto.sato at oracle.com  Tue Jul 21 21:03:40 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jul 2020 14:03:40 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <05073b40-3824-4ad4-555d-125a052fd447@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
 <05073b40-3824-4ad4-555d-125a052fd447@oracle.com>
Message-ID: <c43aa6cf-e010-3f85-748a-c357e10beb7e@oracle.com>

Thank you, Roger.

On 7/21/20 7:50 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> StringUTF16.java:
> 
> 343, 348: The masking and comparisons seem awkward.
> I'd suggest just negating the value and testing for < 0 to flag the less 
> usual case.
> If you continue with the flag bit, define your own static final constant 
> for that bit;
> It looks odd to be using Integer.MIN_VALUE with bit operators.

Right. I will change it to negating.

> 
> Performance wise, I'm a bit cautious about all the if's and branches;
> 
> And only calling getSupplementaryCodePoint if cp was a suggorate might 
> have some
> benefit, but its hard to tell what will be inlined and when.

I think Joe's suggestion will help here. Will update the webrev.

Naoto

> 
> Thanks, Roger
> 
> 
> 
> On 7/20/20 6:20 PM, naoto.sato at oracle.com wrote:
>> Small correction in the updated part:
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/
>>
>> Naoto
>>
>> On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for your comments.
>>>
>>> On 7/20/20 11:20 AM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>>>> there if 389:isHighSurrogate is not true. 
>>>
>>> Good point.
>>>
>>> But more importantly, StringUTF16
>>>> has existing method "codePointAt" you may want to consider instead 
>>>> of adding a new method.
>>>
>>> If we call codePointAt/Before, it would call an extra getChar(). 
>>> Since we know one codepoint as an input, I would avoid the extra calls.
>>>
>>>>
>>>> Comparing to the base benchmark:
>>>> StringCompareToIgnoreCase.lower????????? 8.5%
>>>> StringCompareToIgnoreCase.supLower????? 139%
>>>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>>>
>>>>
>>>> "lower" was 8.5% slower, if such test exists in the specJVM, it 
>>>> would be considered a regression. I would suggest you run the 
>>>> specJVM. I agree with you on surrogate check being a requirement, 
>>>> thus supLower being 139% slower is ok since it won't otherwise be 
>>>> correct anyways.
>>>
>>> Yes, it would be a regression if SPECjvm produces 8+% degradation, 
>>> but the test suite is aimed at the entire application performance. 
>>> But for this one, it is a micro benchmark for relatively rarely 
>>> issued methods (I would think normal cases fall into Latin1 
>>> equivalents), I would consider it is acceptable.
>>>
>>>> But after introducing additional operations supUpperLower and 
>>>> upperLower ran faster? That may indicate irregularity in the tests. 
>>>> Maybe we should consider running tests with short, long and very 
>>>> long sample strings to see if we can reduce the noise level and also 
>>>> see how it fares for a longer string. I assume the machine you're 
>>>> running the test on was isolated.
>>>
>>> This result pretty much depends on the data it is testing for. As I 
>>> wrote in the previous email, (sup)UpperLower tests use the data that 
>>> are almost identical, but one last character is case insensitively 
>>> equal. So in these cases, the new short cut works really well and not 
>>> call toLower/UpperCase() at all for most of the characters. Thus the 
>>> new results are faster. Again the test result is very dependent on 
>>> the input data, Unless the result showed 100% slower or something 
>>> (except supLower case), I think it is OK.
>>>
>>> Anyways, here is the updated webrev addressing your first suggestion:
>>>
>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
>>>
>>> Naoto
>>>
>>>>
>>>> Regards,
>>>> Joe
>>>>
>>>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>>>> Hi Mark,
>>>>>
>>>>> Thank you for your comments.
>>>>>
>>>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>>>> One option is to have a fast path that uses char functions, up to 
>>>>>> the point where you hit a high surrogate, then drop into the 
>>>>>> slower codepoint path. That saves time for the high-runner cases.
>>>>>>
>>>>>> On the other hand, if the times are good enough, you might not 
>>>>>> need the complication.
>>>>>
>>>>> The implementation is dealing with bare byte arrays. Only methods 
>>>>> that it uses from Character class are toLowerCase(int) and 
>>>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>>>> iteration anyways), and their "char" equivalents are merely casting 
>>>>> (char) to the int result. So it might not be so beneficial to 
>>>>> differentiate char and int paths.
>>>>>
>>>>> Having said that, I found that there was an unnecessary surrogate 
>>>>> check (always checks high *and* low surrogate on each iteration), 
>>>>> so I revised the fix (added line 380-383 in StringUTF16.java):
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Mark
>>>>>> //////
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>>>
>>>>>> ??? Hi,
>>>>>>
>>>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>>
>>>>>> ??? Changes from the initial revision are:
>>>>>>
>>>>>> ??? - Shared the implementation between compareToCI() and 
>>>>>> regionMatchesCI()
>>>>>> ??? - Enabled immediate short cut if two code points match.
>>>>>> ??? - Created a simple JMH benchmark. Here is the scores before 
>>>>>> and after
>>>>>> ??? the change:
>>>>>>
>>>>>> ??? before:
>>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>>> ?Error ??? Units
>>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 53.764 ? 
>>>>>> 2.811 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 24.211 ? 
>>>>>> 1.135 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 30.595 ? 
>>>>>> 1.344 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 18.859 ? 
>>>>>> 1.499 ??? ns/op
>>>>>>
>>>>>> ??? after:
>>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt ?Score 
>>>>>> ?Error ??? Units
>>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25 58.354 ? 
>>>>>> 4.603 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25 57.975 ? 
>>>>>> 5.672 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25 23.912 ? 
>>>>>> 0.965 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25 17.744 ? 
>>>>>> 0.272 ??? ns/op
>>>>>>
>>>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>>> "lower"
>>>>>> ??? means each character requires upper->lower casemap. 
>>>>>> "upperLower" means
>>>>>> ??? all characters are the same, except the last character which 
>>>>>> requires
>>>>>> ??? casemap.
>>>>>>
>>>>>> ??? I think the result is reasonable, considering surrogates check 
>>>>>> are now
>>>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>>>> Arrays.mismatch() but
>>>>>> ??? it did not seem to benefit here. In fact, the performance 
>>>>>> degraded
>>>>>> ??? partly because I implemented the short cut, and possibly for the
>>>>>> ??? overhead of extra checks.
>>>>>>
>>>>>> ??? Naoto
>>>>>>
>>>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>>>> ???? > Hello,
>>>>>> ???? >
>>>>>> ???? > Please review the fix to the following issues:
>>>>>> ???? >
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>>> ???? >
>>>>>> ???? > The proposed changeset and its CSR are located at:
>>>>>> ???? >
>>>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>>> ???? >
>>>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>>>> ??? locales in
>>>>>> ???? > JDK15. The root cause was that case-insensitive
>>>>>> ??? String.regionMatches()
>>>>>> ???? > method did not work with supplementary characters. The 
>>>>>> problem is
>>>>>> ??? that
>>>>>> ???? > the method's spec does not expect case mappings of 
>>>>>> supplementary
>>>>>> ???? > characters, possibly because it was overlooked in the first
>>>>>> ??? place, JSR
>>>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>>>> behavior is
>>>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>>>> ???? >
>>>>>> ???? > The fix is straightforward to compare strings by code point 
>>>>>> basis,
>>>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>>>> ??? change will
>>>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>>>> ???? > incompatibility to wrong behavior, not true to the meaning 
>>>>>> of those
>>>>>> ???? > methods' expectations.
>>>>>> ???? >
>>>>>> ???? > Naoto
>>>>>>
>>>>
> 

From brent.christian at oracle.com  Tue Jul 21 21:56:01 2020
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 21 Jul 2020 14:56:01 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
Message-ID: <a1e4b896-e22a-3249-cb82-3b9821e47714@oracle.com>

Hi, Naoto

I have a few comments:

src/java.base/share/classes/java/lang/StringUTF16.java

379     private static int getSupplementaryCodePoint(byte[] ba, int cp, 
int index, int start, int end)

I think it would be worth a small addition to the comment to reflect 
that non-surrogate chars are returned as-is.

--

I thought about the scenario of an unpaired low or high surrogate at the 
beginning or end of the string, respectively:

384         if (Character.isLowSurrogate((char)cp)) {
385             if (index > start) {
                 ...
391         } else if (index + 1 < end) { // cp == high surrogate
392             char c = getChar(ba, index + 1);
                 ...
397         return cp;

It looks like the cp itself would be returned from 
getSupplementaryCodePoint(). And then back in compareToCIImpl(), it's 
converted using Character.to[Upper|Lower]Case(int), which will also 
return the cp itself.  I imagine that's the best we could do, so seems fine.

Is there a test case for unmatched surrogates at the beginning and end 
of the string ? Should there be ?

--

I see there are no changes to StringLatin1.regionMatchesCI_UTF16().  I 
presume there are no cases in which toUpperCase(toLowerCase()) of a 
supplementary character could yield a Latin-1 character, yes?

Also, thanks for adding the benchmark!

-Brent

On 7/20/20 3:20 PM, naoto.sato at oracle.com wrote:
> Small correction in the updated part:
> 
> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/
> 
> Naoto
> 
> On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Thank you for your comments.
>>
>> On 7/20/20 11:20 AM, Joe Wang wrote:
>>> Hi Naoto,
>>>
>>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>>> there if 389:isHighSurrogate is not true. 
>>
>> Good point.
>>
>> But more importantly, StringUTF16
>>> has existing method "codePointAt" you may want to consider instead of 
>>> adding a new method.
>>
>> If we call codePointAt/Before, it would call an extra getChar(). Since 
>> we know one codepoint as an input, I would avoid the extra calls.
>>
>>>
>>> Comparing to the base benchmark:
>>> StringCompareToIgnoreCase.lower????????? 8.5%
>>> StringCompareToIgnoreCase.supLower????? 139%
>>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>>
>>>
>>> "lower" was 8.5% slower, if such test exists in the specJVM, it would 
>>> be considered a regression. I would suggest you run the specJVM. I 
>>> agree with you on surrogate check being a requirement, thus supLower 
>>> being 139% slower is ok since it won't otherwise be correct anyways.
>>
>> Yes, it would be a regression if SPECjvm produces 8+% degradation, but 
>> the test suite is aimed at the entire application performance. But for 
>> this one, it is a micro benchmark for relatively rarely issued methods 
>> (I would think normal cases fall into Latin1 equivalents), I would 
>> consider it is acceptable.
>>
>>> But after introducing additional operations supUpperLower and 
>>> upperLower ran faster? That may indicate irregularity in the tests. 
>>> Maybe we should consider running tests with short, long and very long 
>>> sample strings to see if we can reduce the noise level and also see 
>>> how it fares for a longer string. I assume the machine you're running 
>>> the test on was isolated.
>>
>> This result pretty much depends on the data it is testing for. As I 
>> wrote in the previous email, (sup)UpperLower tests use the data that 
>> are almost identical, but one last character is case insensitively 
>> equal. So in these cases, the new short cut works really well and not 
>> call toLower/UpperCase() at all for most of the characters. Thus the 
>> new results are faster. Again the test result is very dependent on the 
>> input data, Unless the result showed 100% slower or something (except 
>> supLower case), I think it is OK.
>>
>> Anyways, here is the updated webrev addressing your first suggestion:
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
>>
>> Naoto
>>
>>>
>>> Regards,
>>> Joe
>>>
>>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>>> Hi Mark,
>>>>
>>>> Thank you for your comments.
>>>>
>>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>>> One option is to have a fast path that uses char functions, up to 
>>>>> the point where you hit a high surrogate, then drop into the slower 
>>>>> codepoint path. That saves time for the high-runner cases.
>>>>>
>>>>> On the other hand, if the times are good enough, you might not need 
>>>>> the complication.
>>>>
>>>> The implementation is dealing with bare byte arrays. Only methods 
>>>> that it uses from Character class are toLowerCase(int) and 
>>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>>> iteration anyways), and their "char" equivalents are merely casting 
>>>> (char) to the int result. So it might not be so beneficial to 
>>>> differentiate char and int paths.
>>>>
>>>> Having said that, I found that there was an unnecessary surrogate 
>>>> check (always checks high *and* low surrogate on each iteration), so 
>>>> I revised the fix (added line 380-383 in StringUTF16.java):
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Mark
>>>>> //////
>>>>>
>>>>>
>>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>>
>>>>> ??? Hi,
>>>>>
>>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>
>>>>> ??? Changes from the initial revision are:
>>>>>
>>>>> ??? - Shared the implementation between compareToCI() and 
>>>>> regionMatchesCI()
>>>>> ??? - Enabled immediate short cut if two code points match.
>>>>> ??? - Created a simple JMH benchmark. Here is the scores before and 
>>>>> after
>>>>> ??? the change:
>>>>>
>>>>> ??? before:
>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score 
>>>>> ?Error ??? Units
>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 53.764 ? 
>>>>> 2.811 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 24.211 ? 
>>>>> 1.135 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 30.595 ? 
>>>>> 1.344 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 18.859 ? 
>>>>> 1.499 ??? ns/op
>>>>>
>>>>> ??? after:
>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score 
>>>>> ?Error ??? Units
>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 58.354 ? 
>>>>> 4.603 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 57.975 ? 
>>>>> 5.672 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 23.912 ? 
>>>>> 0.965 ??? ns/op
>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 17.744 ? 
>>>>> 0.272 ??? ns/op
>>>>>
>>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>> "lower"
>>>>> ??? means each character requires upper->lower casemap. 
>>>>> "upperLower" means
>>>>> ??? all characters are the same, except the last character which 
>>>>> requires
>>>>> ??? casemap.
>>>>>
>>>>> ??? I think the result is reasonable, considering surrogates check 
>>>>> are now
>>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>>> Arrays.mismatch() but
>>>>> ??? it did not seem to benefit here. In fact, the performance degraded
>>>>> ??? partly because I implemented the short cut, and possibly for the
>>>>> ??? overhead of extra checks.
>>>>>
>>>>> ??? Naoto
>>>>>
>>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>>> ???? > Hello,
>>>>> ???? >
>>>>> ???? > Please review the fix to the following issues:
>>>>> ???? >
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>> ???? >
>>>>> ???? > The proposed changeset and its CSR are located at:
>>>>> ???? >
>>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>> ???? >
>>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>>> ??? locales in
>>>>> ???? > JDK15. The root cause was that case-insensitive
>>>>> ??? String.regionMatches()
>>>>> ???? > method did not work with supplementary characters. The 
>>>>> problem is
>>>>> ??? that
>>>>> ???? > the method's spec does not expect case mappings of 
>>>>> supplementary
>>>>> ???? > characters, possibly because it was overlooked in the first
>>>>> ??? place, JSR
>>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>>> behavior is
>>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>>> ???? >
>>>>> ???? > The fix is straightforward to compare strings by code point 
>>>>> basis,
>>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>>> ??? change will
>>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>>> ???? > incompatibility to wrong behavior, not true to the meaning 
>>>>> of those
>>>>> ???? > methods' expectations.
>>>>> ???? >
>>>>> ???? > Naoto
>>>>>
>>>

From naoto.sato at oracle.com  Tue Jul 21 22:26:43 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jul 2020 15:26:43 -0700
Subject: <i18n dev> RFR: 8248655: Support supplementary characters in
 String case insensitive operations
In-Reply-To: <a1e4b896-e22a-3249-cb82-3b9821e47714@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <CAJ2xs_GRK_xjkS=51sd07q0kQA5YUyYykd2-MJ24MHM+5y0maA@mail.gmail.com>
 <5de5993a-766c-3e95-f6f7-4cea3ad82834@oracle.com>
 <bcd2403f-7004-c71a-ed1e-e9bbb2437f19@oracle.com>
 <9f6030cb-0099-bf7d-e581-636ba1f791ca@oracle.com>
 <74d5bf34-8c44-e000-5161-a030c8d59593@oracle.com>
 <a1e4b896-e22a-3249-cb82-3b9821e47714@oracle.com>
Message-ID: <5c8f19e8-a58d-b6d8-64ab-772838e3d356@oracle.com>

Hi Brent,

On 7/21/20 2:56 PM, Brent Christian wrote:
> Hi, Naoto
> 
> I have a few comments:
> 
> src/java.base/share/classes/java/lang/StringUTF16.java
> 
> 379???? private static int getSupplementaryCodePoint(byte[] ba, int cp, 
> int index, int start, int end)
> 
> I think it would be worth a small addition to the comment to reflect 
> that non-surrogate chars are returned as-is.

Sure, I will add some more comments to the method.

> 
> -- 
> 
> I thought about the scenario of an unpaired low or high surrogate at the 
> beginning or end of the string, respectively:
> 
> 384???????? if (Character.isLowSurrogate((char)cp)) {
> 385???????????? if (index > start) {
>  ??????????????? ...
> 391???????? } else if (index + 1 < end) { // cp == high surrogate
> 392???????????? char c = getChar(ba, index + 1);
>  ??????????????? ...
> 397???????? return cp;
> 
> It looks like the cp itself would be returned from 
> getSupplementaryCodePoint(). And then back in compareToCIImpl(), it's 
> converted using Character.to[Upper|Lower]Case(int), which will also 
> return the cp itself.? I imagine that's the best we could do, so seems 
> fine.

Yes, that is exactly what is intended.

> 
> Is there a test case for unmatched surrogates at the beginning and end 
> of the string ? Should there be ?

Interestingly, there has been a test case for supplementary characters 
before this change, where it intentionally begins from a low surrogate, 
and ends with a high surrogate, so that it would succeed in the previous 
*exact match* logic. Line 82 in RegionMatches.java tests:
"\uD801\uDC28\uD801\uDC29\uFF41a".regionMatches(true, 1, "\uDC28\uD801", 
0, 2) == true
And the proposed change is compatible with this test case.

> 
> -- 
> 
> I see there are no changes to StringLatin1.regionMatchesCI_UTF16().? I 
> presume there are no cases in which toUpperCase(toLowerCase()) of a 
> supplementary character could yield a Latin-1 character, yes?

Yes, that is correct.

Naoto

> 
> Also, thanks for adding the benchmark!
> 
> -Brent
> 
> On 7/20/20 3:20 PM, naoto.sato at oracle.com wrote:
>> Small correction in the updated part:
>>
>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/
>>
>> Naoto
>>
>> On 7/20/20 2:39 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for your comments.
>>>
>>> On 7/20/20 11:20 AM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> StringUTF16: line 384 - 388 seem unnecessary since you'd only get 
>>>> there if 389:isHighSurrogate is not true. 
>>>
>>> Good point.
>>>
>>> But more importantly, StringUTF16
>>>> has existing method "codePointAt" you may want to consider instead 
>>>> of adding a new method.
>>>
>>> If we call codePointAt/Before, it would call an extra getChar(). 
>>> Since we know one codepoint as an input, I would avoid the extra calls.
>>>
>>>>
>>>> Comparing to the base benchmark:
>>>> StringCompareToIgnoreCase.lower????????? 8.5%
>>>> StringCompareToIgnoreCase.supLower????? 139%
>>>> StringCompareToIgnoreCase.supUpperLower? -21.8%
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? -5.9%
>>>>
>>>>
>>>> "lower" was 8.5% slower, if such test exists in the specJVM, it 
>>>> would be considered a regression. I would suggest you run the 
>>>> specJVM. I agree with you on surrogate check being a requirement, 
>>>> thus supLower being 139% slower is ok since it won't otherwise be 
>>>> correct anyways.
>>>
>>> Yes, it would be a regression if SPECjvm produces 8+% degradation, 
>>> but the test suite is aimed at the entire application performance. 
>>> But for this one, it is a micro benchmark for relatively rarely 
>>> issued methods (I would think normal cases fall into Latin1 
>>> equivalents), I would consider it is acceptable.
>>>
>>>> But after introducing additional operations supUpperLower and 
>>>> upperLower ran faster? That may indicate irregularity in the tests. 
>>>> Maybe we should consider running tests with short, long and very 
>>>> long sample strings to see if we can reduce the noise level and also 
>>>> see how it fares for a longer string. I assume the machine you're 
>>>> running the test on was isolated.
>>>
>>> This result pretty much depends on the data it is testing for. As I 
>>> wrote in the previous email, (sup)UpperLower tests use the data that 
>>> are almost identical, but one last character is case insensitively 
>>> equal. So in these cases, the new short cut works really well and not 
>>> call toLower/UpperCase() at all for most of the characters. Thus the 
>>> new results are faster. Again the test result is very dependent on 
>>> the input data, Unless the result showed 100% slower or something 
>>> (except supLower case), I think it is OK.
>>>
>>> Anyways, here is the updated webrev addressing your first suggestion:
>>>
>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.03/
>>>
>>> Naoto
>>>
>>>>
>>>> Regards,
>>>> Joe
>>>>
>>>> On 7/19/2020 11:05 AM, naoto.sato at oracle.com wrote:
>>>>> Hi Mark,
>>>>>
>>>>> Thank you for your comments.
>>>>>
>>>>> On 7/17/20 8:03 PM, Mark Davis ? wrote:
>>>>>> One option is to have a fast path that uses char functions, up to 
>>>>>> the point where you hit a high surrogate, then drop into the 
>>>>>> slower codepoint path. That saves time for the high-runner cases.
>>>>>>
>>>>>> On the other hand, if the times are good enough, you might not 
>>>>>> need the complication.
>>>>>
>>>>> The implementation is dealing with bare byte arrays. Only methods 
>>>>> that it uses from Character class are toLowerCase(int) and 
>>>>> toUpperCase(int) (sans surrogate check, which is needed at each 
>>>>> iteration anyways), and their "char" equivalents are merely casting 
>>>>> (char) to the int result. So it might not be so beneficial to 
>>>>> differentiate char and int paths.
>>>>>
>>>>> Having said that, I found that there was an unnecessary surrogate 
>>>>> check (always checks high *and* low surrogate on each iteration), 
>>>>> so I revised the fix (added line 380-383 in StringUTF16.java):
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.02/
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Mark
>>>>>> //////
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 17, 2020 at 4:39 PM <naoto.sato at oracle.com 
>>>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>>>
>>>>>> ??? Hi,
>>>>>>
>>>>>> ??? Based on the suggestions, I modified the fix as follows:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>>
>>>>>> ??? Changes from the initial revision are:
>>>>>>
>>>>>> ??? - Shared the implementation between compareToCI() and 
>>>>>> regionMatchesCI()
>>>>>> ??? - Enabled immediate short cut if two code points match.
>>>>>> ??? - Created a simple JMH benchmark. Here is the scores before 
>>>>>> and after
>>>>>> ??? the change:
>>>>>>
>>>>>> ??? before:
>>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score 
>>>>>> ?Error ??? Units
>>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 53.764 ? 
>>>>>> 2.811 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 24.211 ? 
>>>>>> 1.135 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 30.595 ? 
>>>>>> 1.344 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 18.859 ? 
>>>>>> 1.499 ??? ns/op
>>>>>>
>>>>>> ??? after:
>>>>>> ??? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Mode? Cnt? ?Score 
>>>>>> ?Error ??? Units
>>>>>> ??? StringCompareToIgnoreCase.lower? ? ? ? ? avgt? ?25? 58.354 ? 
>>>>>> 4.603 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supLower? ? ? ?avgt? ?25? 57.975 ? 
>>>>>> 5.672 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.supUpperLower? avgt? ?25? 23.912 ? 
>>>>>> 0.965 ??? ns/op
>>>>>> ??? StringCompareToIgnoreCase.upperLower? ? ?avgt? ?25? 17.744 ? 
>>>>>> 0.272 ??? ns/op
>>>>>>
>>>>>> ??? Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>>> "lower"
>>>>>> ??? means each character requires upper->lower casemap. 
>>>>>> "upperLower" means
>>>>>> ??? all characters are the same, except the last character which 
>>>>>> requires
>>>>>> ??? casemap.
>>>>>>
>>>>>> ??? I think the result is reasonable, considering surrogates check 
>>>>>> are now
>>>>>> ??? mandatory. I have tried Roger's suggestion to use 
>>>>>> Arrays.mismatch() but
>>>>>> ??? it did not seem to benefit here. In fact, the performance 
>>>>>> degraded
>>>>>> ??? partly because I implemented the short cut, and possibly for the
>>>>>> ??? overhead of extra checks.
>>>>>>
>>>>>> ??? Naoto
>>>>>>
>>>>>> ??? On 7/15/20 9:00 AM, naoto.sato at oracle.com
>>>>>> ??? <mailto:naoto.sato at oracle.com> wrote:
>>>>>> ???? > Hello,
>>>>>> ???? >
>>>>>> ???? > Please review the fix to the following issues:
>>>>>> ???? >
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>>> ???? >
>>>>>> ???? > The proposed changeset and its CSR are located at:
>>>>>> ???? >
>>>>>> ???? > https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>>> ???? > https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>>> ???? >
>>>>>> ???? > A bug was filed against SimpleDateFormat (8248434) where
>>>>>> ???? > case-insensitive date format/parse failed in some of the new
>>>>>> ??? locales in
>>>>>> ???? > JDK15. The root cause was that case-insensitive
>>>>>> ??? String.regionMatches()
>>>>>> ???? > method did not work with supplementary characters. The 
>>>>>> problem is
>>>>>> ??? that
>>>>>> ???? > the method's spec does not expect case mappings of 
>>>>>> supplementary
>>>>>> ???? > characters, possibly because it was overlooked in the first
>>>>>> ??? place, JSR
>>>>>> ???? > 204 - "Unicode Supplementary Character support". Similar 
>>>>>> behavior is
>>>>>> ???? > observed in other two case-insensitive methods, i.e.,
>>>>>> ???? > compareToIgnoreCase() and equalsIgnoreCase().
>>>>>> ???? >
>>>>>> ???? > The fix is straightforward to compare strings by code point 
>>>>>> basis,
>>>>>> ???? > instead of code unit (16bit "char") basis. Technically this
>>>>>> ??? change will
>>>>>> ???? > introduce a backward incompatibility, but I believe it is an
>>>>>> ???? > incompatibility to wrong behavior, not true to the meaning 
>>>>>> of those
>>>>>> ???? > methods' expectations.
>>>>>> ???? >
>>>>>> ???? > Naoto
>>>>>>
>>>>

From mandy.chung at oracle.com  Tue Jul 21 23:26:16 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 21 Jul 2020 16:26:16 -0700
Subject: RFR: JDK-8247592: refactor
 test/jdk/tools/launcher/Test7029048.java
In-Reply-To: <8f811a92-a646-4732-8edd-4f8baae43180@bell-sw.com>
References: <0bd8fc50-81d4-c40c-ede5-907bd7fc6144@bell-sw.com>
 <8f811a92-a646-4732-8edd-4f8baae43180@bell-sw.com>
Message-ID: <7f41bb5f-0b80-5cdf-39aa-7d85bebcb1ed@oracle.com>

Hi Aleksei,

> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/

This refactoring seems okay.? I would suggest to change the run method 
to return an int or boolean to indicate the test passed or failed.?? The 
caller of the run method (i.e. runTest will add to the failedTests list 
if the return value indicates test failure.?? No need to pass the 
failedTest list to the run method as an argument.

Typo in line 90: s/bug got/but got/

Otherwise, looks okay.

Mandy

On 7/21/20 10:37 AM, Aleksei Voitylov wrote:
> Hi,
>
> gently reminiding about this simple test refactoring. The patch still
> applies cleanly.
>
> -Aleksei
>
> On 24/06/2020 11:44, Aleksei Voitylov wrote:
>> Hi,
>>
>> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
>> logic easier to follow and remove some magic numbers from the test:
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247592
>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>>
>> Testing: the test passes on Linux x86, Linux x86_64, Linux ARM, Linux
>> AArch64, Linux PPC, Windows x86, Windows x86_64, Mac, AIX. Special
>> thanks to SAP team for helping test on AIX.
>>
>> Thanks,
>> -Aleksei
>>


From kim.barrett at oracle.com  Wed Jul 22 08:04:57 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 22 Jul 2020 04:04:57 -0400
Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate
In-Reply-To: <8f0baa70-0bc3-caa7-13eb-364c45a466d6@oracle.com>
References: <E125A0B6-7FC4-4007-A9C4-7A7DFB86EEE4@oracle.com>
 <8f0baa70-0bc3-caa7-13eb-364c45a466d6@oracle.com>
Message-ID: <F353471D-8C42-4A8F-A63A-70CA20FAD98F@oracle.com>

> On Apr 8, 2020, at 5:27 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,

Apparently I lost track of these comments and forgot to respond.

I still won't be sending out a new webrev until some of the other
discussion gets settled.  There's been some internal discussion, but
I'm currently waiting on some other folks to have time to chime in.

Replies to your comments inline below.

> On 8/04/2020 10:25 am, Kim Barrett wrote:
>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose
>> either when replying.]
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> This function is needed to test the referent of a Reference object
>> without artificially extending the lifetime of the referent object, as
>> may happen when calling Reference.get.  Some garbage collectors
>> require extending the lifetime of a weak referent when accessed, in
>> order to maintain collector invariants.  Lifetime extension may occur
>> with any collector when the Reference is a SoftReference, as calling
>> get indicates recent access.  This new function also allows testing
>> the referent of a PhantomReference, which can't be accessed by calling
>> get.
> 
> This causes a slight conflict with the documentation for get() which states:
> 
> "Because the referent of a phantom reference is always inaccessible ..."
> 
> when the new method obviously accesses it.

I take that "inaccessible" to mean "inaccessible to the application",
and refersTo doesn't make the referent accessible to the application.

>> The new function uses a native method whose implementation is in the
>> VM so it can use the Access API.  It is the intent that this function
>> will be intrinsified by optimizing compilers like C2 or graal, but
>> that hasn't been implemented yet.  Bear that in mind before rushing
>> off to change existing uses of Reference.get.
> 
> I assume such intrinsification is intended for JDK 15 as well though, as end users may well rush to change their code!

Looks like we missed the JDK 15 train.

>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8188055
>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR)
> 
> In the specification:
> 
> * @param   obj is the object to compare with the referenced object, or
> *          {@code null}.
> 
> First delete "is", the commone style for @param is just to say "the xxx" or "a yyy?.

Done locally.

> Second I suggest:
> 
> s/the referenced object/this reference object's referent/

Done locally.

> In the apinote:
> 
> * collection cycle.  {@link #refersTo(Object) refersTo} can be used to
> 
> I suggest:
> 
> * collection cycle.  The {@link #refersTo(Object) refersTo} method can be used to
> 
> so we don't start a sentence with a lower-case code-font word.

Done locally.

> Also a query in the apinote:
> 
> * This method returns a strong reference to the referent. This may cause
> * the garbage collector to treat it as strongly reachable until some later
> 
> Surely if the method returns a strong reference then the GC _will_ treat it as strongly reachable, not "may? ?

Something like refersTo is needed because an access using get may
force some phases of some collectors to treat the referent as strongly
reachable for some additional period, even if the application
immediately drops all references to it.  Other collectors may not need
to do anything of the sort.  And even collectors that do sometimes
need to do so may not always need to do so.  It's all vaguely
weasel-worded because there is so much potential variation.

>> Webrev:
>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
> 
> Code changes look good. No comment on the test - I'll leave it to others to analyse that.

Thanks.


From aleksei.voitylov at bell-sw.com  Wed Jul 22 08:32:42 2020
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Wed, 22 Jul 2020 11:32:42 +0300
Subject: RFR: JDK-8247592: refactor
 test/jdk/tools/launcher/Test7029048.java
In-Reply-To: <7f41bb5f-0b80-5cdf-39aa-7d85bebcb1ed@oracle.com>
References: <0bd8fc50-81d4-c40c-ede5-907bd7fc6144@bell-sw.com>
 <8f811a92-a646-4732-8edd-4f8baae43180@bell-sw.com>
 <7f41bb5f-0b80-5cdf-39aa-7d85bebcb1ed@oracle.com>
Message-ID: <69932e63-8a4f-67cf-bd52-98fd899da420@bell-sw.com>

Hi Mandy,

here is the webrev which addresses your comments:

http://cr.openjdk.java.net/~avoitylov/webrev.8247592.02/

Thanks,

-Aleksei

On 22/07/2020 02:26, Mandy Chung wrote:
> Hi Aleksei,
>
>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>
> This refactoring seems okay.? I would suggest to change the run method
> to return an int or boolean to indicate the test passed or failed.??
> The caller of the run method (i.e. runTest will add to the failedTests
> list if the return value indicates test failure.?? No need to pass the
> failedTest list to the run method as an argument.
>
> Typo in line 90: s/bug got/but got/
>
> Otherwise, looks okay.
>
> Mandy
>
> On 7/21/20 10:37 AM, Aleksei Voitylov wrote:
>> Hi,
>>
>> gently reminiding about this simple test refactoring. The patch still
>> applies cleanly.
>>
>> -Aleksei
>>
>> On 24/06/2020 11:44, Aleksei Voitylov wrote:
>>> Hi,
>>>
>>> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
>>> logic easier to follow and remove some magic numbers from the test:
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247592
>>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>>>
>>> Testing: the test passes on Linux x86, Linux x86_64, Linux ARM, Linux
>>> AArch64, Linux PPC, Windows x86, Windows x86_64, Mac, AIX. Special
>>> thanks to SAP team for helping test on AIX.
>>>
>>> Thanks,
>>> -Aleksei
>>>
>

From aph at redhat.com  Wed Jul 22 08:24:00 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 22 Jul 2020 09:24:00 +0100
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
Message-ID: <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>

On 17/07/2020 12:26, Koichi Sakata wrote:
> 
>  > You'll need to find a reviewer that understands what that
>  > method is supposed to do in that case, that's not me ;-)
> 
> I understand. This ML is suitable for finding a reviewer, isn't it?
> Or, there is another way. We can avoid the error by the accepting 
> maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.

I think it'd be better to fix it. Although the logic is such that all of
the cases are covered by the switch statement in k_standard.c, the default
case should return NaN in retval: use zero/zero.

I'll approve 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 raffaello.giulietti at gmail.com  Wed Jul 22 11:52:23 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 22 Jul 2020 13:52:23 +0200
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
Message-ID: <78944404-e2c3-a1cb-5809-967d99282b10@gmail.com>

Hello,

the CSR for read(char[],int,int) does not explicitly specify that "line 
terminators are compressed into single newline ('\n') characters", as 
the no-arg read() spec does.

Thus, it's not entirely clear what happens when the buffer is just large 
enough to accept the \r in a \r\n sequence, potentially giving the 
impression that this leaves a pending unread \n that might be counted 
again in later invocations of either read() or read(char[],int,int).

It might be helpful to explicitly repeat the "compression" rule of the 
no-arg read() even for read(char[],int,int).



Besides, the JDK 14 API states that the invocation
"Returns:
The number of *bytes* read, or -1 if the end of the stream has already 
been reached"

I think it should say "characters" rather than "bytes" but perhaps this 
has already been corrected.


Greetings
Raffaello



> The CSR [2] has been approved so unless there are further comments I?ll push this change [1] this week.
> 
> Thanks,
> 
> Brian
> 
>> On Mar 19, 2020, at 7:43 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>> 
>> Another webrev [1] which is adjusted from the previous one per the comments on the CSR [2] is available for review. The only change is to the class-level specification:
>> 
>> --- a/src/java.base/share/classes/java/io/LineNumberReader.java
>> +++ b/src/java.base/share/classes/java/io/LineNumberReader.java
>> @@ -41,7 +41,8 @@
>>   *
>>   * <p> A line is considered to be <a id="lt">terminated</a> by any one of a
>>   * line feed ('\n'), a carriage return ('\r'), or a carriage return followed
>> - * immediately by a linefeed.
>> + * immediately by a linefeed, or any of the previous terminators followed by
>> + * end of stream, or end of stream not preceded by another terminator.
>>   *
>> 
>> Thanks,
>> 
>> Brian
>> 
>>> On Mar 13, 2020, at 10:28 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>>> 
>>> An updated webrev is at [1] and a CSR has been filed [2].
> 
> [1] http://cr.openjdk.java.net/~bpb/8235792/webrev.02/
> [2] https://bugs.openjdk.java.net/browse/JDK-8241020
> 

From sakatakui at oss.nttdata.com  Wed Jul 22 14:48:48 2020
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Wed, 22 Jul 2020 23:48:48 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>
Message-ID: <10f1641b-3302-50ee-f7e7-e283685b2535@oss.nttdata.com>

Hi Andrew,

Thank you for teaching me.
I made the patch that returns NaN. Could you please sponsor it?

In this case I think it is better to fix k_standard.c itself rather than 
ignoring the warning. However, I was able to learn there are some good 
ways to suppress warnings. So I'd like to thank Ioi and Yasumasa.

Thanks,
Koichi

===== PATCH =====
diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
b/src/java.base/share/native/libfdlibm/k_standard.c
--- a/src/java.base/share/native/libfdlibm/k_standard.c
+++ b/src/java.base/share/native/libfdlibm/k_standard.c
@@ -739,6 +739,10 @@
                          errno = EDOM;
                  }
                  break;
+            default:
+                exc.retval = zero / zero;
+                errno = EINVAL;
+                break;
          }
          return exc.retval;
  }
diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
b/src/java.base/unix/native/libnet/NetworkInterface.c
--- a/src/java.base/unix/native/libnet/NetworkInterface.c
+++ b/src/java.base/unix/native/libnet/NetworkInterface.c
@@ -1296,7 +1296,8 @@
  static int getIndex(int sock, const char *name) {
      struct ifreq if2;
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
+    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
+    if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

      if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
          return -1;
@@ -1359,7 +1360,8 @@
  static int getFlags(int sock, const char *ifname, int *flags) {
      struct ifreq if2;
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
+    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
+    if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

      if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
          return -1;


On 2020/07/22 17:24, Andrew Haley wrote:
> On 17/07/2020 12:26, Koichi Sakata wrote:
>>
>>   > You'll need to find a reviewer that understands what that
>>   > method is supposed to do in that case, that's not me ;-)
>>
>> I understand. This ML is suitable for finding a reviewer, isn't it?
>> Or, there is another way. We can avoid the error by the accepting
>> maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.
> 
> I think it'd be better to fix it. Although the logic is such that all of
> the cases are covered by the switch statement in k_standard.c, the default
> case should return NaN in retval: use zero/zero.
> 
> I'll approve that.
> 

From Roger.Riggs at oracle.com  Wed Jul 22 14:51:15 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 10:51:15 -0400
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread
 still happens
Message-ID: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>

Please review a change to the Process reaper thread initialization to 
preemptively
make sure classes ThreadLocalRandom and ConcurrentHashMap are initialized.
 From the stack overflow failures, it seems that the classes have not 
been initialized
before they are used during processing the termination of a process.
When the initialization is performed on the smaller reaper stack, it 
occasionally
exceeds the available stack.

As an aid to diagnostics, 
-XX:AbortVMOnException=java.lang.StackOverflowError
is added to TestHumongousNonArrayAllocation that has failed intermittently.
If the problem happens again it will produce an hs_error file with 
useful details
and will otherwise not change the test behavior.

Webrev:
 ?? http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/

Issue:
 ? https://bugs.openjdk.java.net/browse/JDK-8249217

Thanks, Roger


From peter.levart at gmail.com  Wed Jul 22 14:58:42 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 22 Jul 2020 16:58:42 +0200
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
Message-ID: <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>

Hi Roger,


I don't think resolving the ConcurrentHashMap.class ensures 
initialization of the class. Just loading. But I think CHM is already 
initialized at that time as it is used in ClassLoader to maintain class 
loading locks (per class name).


Regards, Peter


On 7/22/20 4:51 PM, Roger Riggs wrote:
> Please review a change to the Process reaper thread initialization to 
> preemptively
> make sure classes ThreadLocalRandom and ConcurrentHashMap are 
> initialized.
> From the stack overflow failures, it seems that the classes have not 
> been initialized
> before they are used during processing the termination of a process.
> When the initialization is performed on the smaller reaper stack, it 
> occasionally
> exceeds the available stack.
>
> As an aid to diagnostics, 
> -XX:AbortVMOnException=java.lang.StackOverflowError
> is added to TestHumongousNonArrayAllocation that has failed 
> intermittently.
> If the problem happens again it will produce an hs_error file with 
> useful details
> and will otherwise not change the test behavior.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>
> Issue:
> ? https://bugs.openjdk.java.net/browse/JDK-8249217
>
> Thanks, Roger
>

From naoto.sato at oracle.com  Wed Jul 22 17:23:16 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 Jul 2020 10:23:16 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
Message-ID: <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>

Hi,

I revised the fix again, based on further suggestions:

https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/

Changes from v.04 are (all in StringUTF16.java):

- The short cut now does case insensitive comparison that makes the fix 
closer to the previous implementation (for BMP characters).
- Changed the bit operation to negating for detecting needed index 
increment.
- Method name is changed to better reflect what it is doing, with more 
descriptive comments.

Here is the benchmark results:

before:
Benchmark                                Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.lower          avgt   25  49.960 ? 1.923  ns/op
StringCompareToIgnoreCase.supLower       avgt   25  21.003 ? 0.354  ns/op
StringCompareToIgnoreCase.supUpperLower  avgt   25  30.863 ? 4.529  ns/op
StringCompareToIgnoreCase.upperLower     avgt   25  15.417 ? 1.046  ns/op

after:
Benchmark                                Mode  Cnt    Score   Error  Units
StringCompareToIgnoreCase.lower          avgt   25   46.857 ? 0.524  ns/op
StringCompareToIgnoreCase.supLower       avgt   25  148.688 ? 6.546  ns/op
StringCompareToIgnoreCase.supUpperLower  avgt   25   37.160 ? 0.259  ns/op
StringCompareToIgnoreCase.upperLower     avgt   25   15.126 ? 0.338  ns/op

Now non-supplementary operations ("lower" and "upperLower") are on par 
with the "before" result (I am not quite sure why the "after" results 
are somewhat faster though). For supplementary test cases, "supLower" is 
very slow. The reason is two fold; one is because "before" one exits at 
the very first character (which I am addressing here) while "after" 
continues to compare to the last characters, the other reason is the 
test suffers from the change where supplementary cases double the case 
insensitivity checks (compared to the "after" result just below). Also 
"supUpperLower" gets slower for the same reason. These are expected 
results for supplementary comparisons (as we discussed).

Naoto

On 7/17/20 4:36 PM, naoto.sato at oracle.com wrote:
> Hi,
> 
> Based on the suggestions, I modified the fix as follows:
> 
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
> 
> Changes from the initial revision are:
> 
> - Shared the implementation between compareToCI() and regionMatchesCI()
> - Enabled immediate short cut if two code points match.
> - Created a simple JMH benchmark. Here is the scores before and after 
> the change:
> 
> before:
> Benchmark??????????????????????????????? Mode? Cnt?? Score?? Error? Units
> StringCompareToIgnoreCase.lower????????? avgt?? 25? 53.764 ? 2.811? ns/op
> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 24.211 ? 1.135? ns/op
> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.595 ? 1.344? ns/op
> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 18.859 ? 1.499? ns/op
> 
> after:
> Benchmark??????????????????????????????? Mode? Cnt?? Score?? Error? Units
> StringCompareToIgnoreCase.lower????????? avgt?? 25? 58.354 ? 4.603? ns/op
> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 57.975 ? 5.672? ns/op
> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 23.912 ? 0.965? ns/op
> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 17.744 ? 0.272? ns/op
> 
> Here, "sup" means all supplementary characters, BMP otherwise. "lower" 
> means each character requires upper->lower casemap. "upperLower" means 
> all characters are the same, except the last character which requires 
> casemap.
> 
> I think the result is reasonable, considering surrogates check are now 
> mandatory. I have tried Roger's suggestion to use Arrays.mismatch() but 
> it did not seem to benefit here. In fact, the performance degraded 
> partly because I implemented the short cut, and possibly for the 
> overhead of extra checks.
> 
> Naoto
> 
> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issues:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8248655
>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>
>> The proposed changeset and its CSR are located at:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>
>> A bug was filed against SimpleDateFormat (8248434) where 
>> case-insensitive date format/parse failed in some of the new locales 
>> in JDK15. The root cause was that case-insensitive 
>> String.regionMatches() method did not work with supplementary 
>> characters. The problem is that the method's spec does not expect case 
>> mappings of supplementary characters, possibly because it was 
>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>> Character support". Similar behavior is observed in other two 
>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>> equalsIgnoreCase().
>>
>> The fix is straightforward to compare strings by code point basis, 
>> instead of code unit (16bit "char") basis. Technically this change 
>> will introduce a backward incompatibility, but I believe it is an 
>> incompatibility to wrong behavior, not true to the meaning of those 
>> methods' expectations.
>>
>> Naoto

From brian.burkhalter at oracle.com  Wed Jul 22 18:36:06 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 22 Jul 2020 11:36:06 -0700
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <78944404-e2c3-a1cb-5809-967d99282b10@gmail.com>
References: <78944404-e2c3-a1cb-5809-967d99282b10@gmail.com>
Message-ID: <892E385E-6744-44DB-B2E3-ABDCCA18BBDD@oracle.com>

Hello,

> On Jul 22, 2020, at 4:52 AM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
> 
> the CSR for read(char[],int,int) does not explicitly specify that "line terminators are compressed into single newline ('\n') characters", as the no-arg read() spec does.
> 
> Thus, it's not entirely clear what happens when the buffer is just large enough to accept the \r in a \r\n sequence, potentially giving the impression that this leaves a pending unread \n that might be counted again in later invocations of either read() or read(char[],int,int).
> 
> It might be helpful to explicitly repeat the "compression" rule of the no-arg read() even for read(char[],int,int).

Yes, I think that the sentence

+     * <a href="#lt">Line terminators</a> are compressed into single newline
+     * ('\n') characters.

should be added to the specs of read(char[],int,int) and readLine(), or some equivalent statement be added to the class level doc.

> Besides, the JDK 14 API states that the invocation
> "Returns:
> The number of *bytes* read, or -1 if the end of the stream has already been reached"
> 
> I think it should say "characters" rather than "bytes" but perhaps this has already been corrected.

No, it has not been correct and I agree that it should be ?characters,? not ?bytes.?

Thanks,

Brian

From mandy.chung at oracle.com  Wed Jul 22 19:04:06 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Jul 2020 12:04:06 -0700
Subject: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated method
 to match the proxy interface method
Message-ID: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>

Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/

A small improvement to the dynamic proxy generated method to have
ACC_VARARGS matching the method declared in a proxy interface if set.
If there are two or more proxy interfaces declaring such a method,
it matches the method declared in the first proxy interface.

thanks
Mandy


From ioi.lam at oracle.com  Wed Jul 22 19:36:17 2020
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 22 Jul 2020 12:36:17 -0700
Subject: RFR(L) 8244778 Archive full module graph in CDS
Message-ID: <c3b14359-e91e-5bab-bc92-384bb50a6949@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8244778
http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v01/

Please review this patch that stores the full module graph in the CDS
archive heap. This reduces the initialization time of the basic JVM by
about 22%:

$ perf stat -r 100 bin/java -version
before: 98,219,329 instructions 0.03971 secs elapsed (+- 0.44%)
after:? 55,835,815 instructions 0.03109 secs elapsed (+- 0.65%)

[1] Start with ModuleBootstrap.java. The current implementation is
 ??? quite restrictive: the archived module graph is used only when no
 ??? module options are specified.

 ??? See ModuleBootstrap.mayUseArchivedBootLayer().

 ??? We can probably support options such as main module and module path
 ??? in a future RFE.

[2] In the current JDK implementation, there is no single object
 ??? that represents "the module graph". Most of the information
 ??? is stored in the archive bootLayer object, but a few additional
 ??? restoration operations need to be performed:

 ??? + See ModuleBootstrap.getArchivedBootLayer()
 ??? + Some static fields need to be archived/restored in
 ????? Module.java, BuiltinClassLoader.java, ClassLoaders.java
 ????? and BootLoader.java

[3] I ran into a complication with two loader instances of
 ??? PlatformClassLoader and AppClassLoader. They are stored in
 ??? multiple tables inside the module graph (e.g.,
 ??? BuiltinClassLoader$LoadedModule) so I cannot easily recreate
 ??? them at runtime.

 ??? However, these two loaders contain information specific to the
 ??? dump time VM lifecycle (such as the classes that were loaded
 ??? during CDS dumping) that need to be scrubbed. I couldn't find an
 ??? elegant way of doing this, so I added a private "resetArchivedStates"
 ??? method to a few classes. They are called inside
 ??? HeapShared::reset_archived_object_states().

[4] Related native data structures (PackageEntry and ModuleEntry)
 ??? are also archived. Start with classLoaderData.cpp

Passes mach5 tiers 1-4. I will test with additional tiers.

Thanks
- Ioi

From Roger.Riggs at oracle.com  Wed Jul 22 19:36:51 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 15:36:51 -0400
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
Message-ID: <966c2d88-5001-db5f-5a6d-69baa2da9d08@oracle.com>

Hi Peter,

yes, the reference to ConcurrentHashMap seems ineffective and unnecessary.

Updated Webrev:

http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-1/

Thanks, Roger



On 7/22/20 10:58 AM, Peter Levart wrote:
> Hi Roger,
>
>
> I don't think resolving the ConcurrentHashMap.class ensures 
> initialization of the class. Just loading. But I think CHM is already 
> initialized at that time as it is used in ClassLoader to maintain 
> class loading locks (per class name).
>
>
> Regards, Peter
>
>
> On 7/22/20 4:51 PM, Roger Riggs wrote:
>> Please review a change to the Process reaper thread initialization to 
>> preemptively
>> make sure classes ThreadLocalRandom and ConcurrentHashMap are 
>> initialized.
>> From the stack overflow failures, it seems that the classes have not 
>> been initialized
>> before they are used during processing the termination of a process.
>> When the initialization is performed on the smaller reaper stack, it 
>> occasionally
>> exceeds the available stack.
>>
>> As an aid to diagnostics, 
>> -XX:AbortVMOnException=java.lang.StackOverflowError
>> is added to TestHumongousNonArrayAllocation that has failed 
>> intermittently.
>> If the problem happens again it will produce an hs_error file with 
>> useful details
>> and will otherwise not change the test behavior.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>
>> Issue:
>> ? https://bugs.openjdk.java.net/browse/JDK-8249217
>>
>> Thanks, Roger
>>


From Roger.Riggs at oracle.com  Wed Jul 22 19:42:44 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 15:42:44 -0400
Subject: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated
 method to match the proxy interface method
In-Reply-To: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>
References: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>
Message-ID: <00e3b2bb-f37b-dca9-b496-55da809771ca@oracle.com>

Hi Mandy,

Looks fine.

Roger

On 7/22/20 3:04 PM, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
>
> A small improvement to the dynamic proxy generated method to have
> ACC_VARARGS matching the method declared in a proxy interface if set.
> If there are two or more proxy interfaces declaring such a method,
> it matches the method declared in the first proxy interface.
>
> thanks
> Mandy
>


From alexey.semenyuk at oracle.com  Wed Jul 22 19:44:12 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 22 Jul 2020 15:44:12 -0400
Subject: RFR: 8245311: [macos] misc package tests failed due to "execution
 error: Finder got an error: AppleEvent timed out."
In-Reply-To: <0e84d08e-fe9c-57fc-8178-dd96dcbb1c69@oracle.com>
References: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>
 <6cfe91cc-b74c-3c1e-184a-8e30d8740b48@oracle.com>
 <6e17d63b-e839-19cf-1ac4-bb175831768e@oracle.com>
 <0e84d08e-fe9c-57fc-8178-dd96dcbb1c69@oracle.com>
Message-ID: <4723b5ca-4994-b52c-e1b9-ace7b0590a2d@oracle.com>

Looks good!

- Alexey

On 7/17/2020 10:35 PM, alexander.matveev at oracle.com wrote:
> Hi Alexey,
>
> Fixed as per your suggestion:
> http://cr.openjdk.java.net/~almatvee/8245311/webrev.01/
>
> Thanks,
> Alexander
>
> On 7/17/20 4:26 PM, Alexey Semenyuk wrote:
>> Alexander,
>>
>> The change in RetryExecutor.java results in Executor instance created 
>> only once and not every time command line should be executed.
>>
>> I'd suggest to have
>> ---
>> void execute(String cmdline[]) throws IOException {
>> ??? executeLoop(() -> Executor.of(cmdline));
>> }
>>
>> private void executeLoop(Supplier<Executor> execSupplier) throws 
>> IOException {
>> ???? ...
>> ???? Executor exec = execSupplier.get();
>> }
>> ---
>>
>> instead.
>>
>> - Alexey
>>
>> On 7/17/2020 1:03 PM, Andy Herrick wrote:
>>> Looks OK - I approve.
>>>
>>> /Andy
>>>
>>> On 7/15/2020 7:29 PM, alexander.matveev at oracle.com wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> - "hdiutil detach" resource busy error is fixed in same way as 
>>>> JDK-8242786 by repeating detach several times.
>>>> - pkgbuild timeout will be covered with JDK-8249395.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8245311
>>>> [2] http://cr.openjdk.java.net/~almatvee/8245311/webrev.00/
>>>>
>>>> Thanks,
>>>> Alexander
>>
>


From andy.herrick at oracle.com  Wed Jul 22 20:01:08 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 22 Jul 2020 16:01:08 -0400
Subject: RFR: 8245311: [macos] misc package tests failed due to "execution
 error: Finder got an error: AppleEvent timed out."
In-Reply-To: <0e84d08e-fe9c-57fc-8178-dd96dcbb1c69@oracle.com>
References: <f71d0272-c17f-bab8-a6ba-b0acfd415f64@oracle.com>
 <6cfe91cc-b74c-3c1e-184a-8e30d8740b48@oracle.com>
 <6e17d63b-e839-19cf-1ac4-bb175831768e@oracle.com>
 <0e84d08e-fe9c-57fc-8178-dd96dcbb1c69@oracle.com>
Message-ID: <78abe9dc-30d8-ae85-8ed4-f95b2e504cde@oracle.com>

looks good.

/Andy

On 7/17/2020 10:35 PM, alexander.matveev at oracle.com wrote:
> Hi Alexey,
>
> Fixed as per your suggestion:
> http://cr.openjdk.java.net/~almatvee/8245311/webrev.01/
>
> Thanks,
> Alexander
>
> On 7/17/20 4:26 PM, Alexey Semenyuk wrote:
>> Alexander,
>>
>> The change in RetryExecutor.java results in Executor instance created 
>> only once and not every time command line should be executed.
>>
>> I'd suggest to have
>> ---
>> void execute(String cmdline[]) throws IOException {
>> ??? executeLoop(() -> Executor.of(cmdline));
>> }
>>
>> private void executeLoop(Supplier<Executor> execSupplier) throws 
>> IOException {
>> ???? ...
>> ???? Executor exec = execSupplier.get();
>> }
>> ---
>>
>> instead.
>>
>> - Alexey
>>
>> On 7/17/2020 1:03 PM, Andy Herrick wrote:
>>> Looks OK - I approve.
>>>
>>> /Andy
>>>
>>> On 7/15/2020 7:29 PM, alexander.matveev at oracle.com wrote:
>>>> Please review the jpackage fix for bug [1] at [2].
>>>>
>>>> - "hdiutil detach" resource busy error is fixed in same way as 
>>>> JDK-8242786 by repeating detach several times.
>>>> - pkgbuild timeout will be covered with JDK-8249395.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8245311
>>>> [2] http://cr.openjdk.java.net/~almatvee/8245311/webrev.00/
>>>>
>>>> Thanks,
>>>> Alexander
>>
>

From huizhe.wang at oracle.com  Wed Jul 22 20:20:20 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 22 Jul 2020 13:20:20 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
Message-ID: <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>

Hi Naoto,

The change looks good to me. "supLower" is indeed super slow :-)

The only minor comment I have is that the compareCodePointCI method 
performs toUpperCase unconditionally. That's not a problem for the 
regular case, where a check on cp1 == cp2 (line 337) is done prior to 
the method call. But for the sup case (starting at line 341), the method 
is called unconditionally while in webrev.04 there was a check "cp1 != 
cp2".? One option to fix it is to include the "cp1 != cp2" check in the 
method compareCodePointCI, then cp1 == cp2 at line 337 can be omitted.

Regards,
Joe

On 7/22/20 10:23 AM, naoto.sato at oracle.com wrote:
> Hi,
>
> I revised the fix again, based on further suggestions:
>
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
>
> Changes from v.04 are (all in StringUTF16.java):
>
> - The short cut now does case insensitive comparison that makes the 
> fix closer to the previous implementation (for BMP characters).
> - Changed the bit operation to negating for detecting needed index 
> increment.
> - Method name is changed to better reflect what it is doing, with more 
> descriptive comments.
>
> Here is the benchmark results:
>
> before:
> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
> StringCompareToIgnoreCase.lower????????? avgt?? 25? 49.960 ? 1.923? ns/op
> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 21.003 ? 0.354? ns/op
> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.863 ? 4.529? ns/op
> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 15.417 ? 1.046? ns/op
>
> after:
> Benchmark??????????????????????????????? Mode? Cnt??? Score Error? Units
> StringCompareToIgnoreCase.lower????????? avgt?? 25?? 46.857 ? 0.524? 
> ns/op
> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 148.688 ? 6.546? 
> ns/op
> StringCompareToIgnoreCase.supUpperLower? avgt?? 25?? 37.160 ? 0.259? 
> ns/op
> StringCompareToIgnoreCase.upperLower???? avgt?? 25?? 15.126 ? 0.338? 
> ns/op
>
> Now non-supplementary operations ("lower" and "upperLower") are on par 
> with the "before" result (I am not quite sure why the "after" results 
> are somewhat faster though). For supplementary test cases, "supLower" 
> is very slow. The reason is two fold; one is because "before" one 
> exits at the very first character (which I am addressing here) while 
> "after" continues to compare to the last characters, the other reason 
> is the test suffers from the change where supplementary cases double 
> the case insensitivity checks (compared to the "after" result just 
> below). Also "supUpperLower" gets slower for the same reason. These 
> are expected results for supplementary comparisons (as we discussed).
>
> Naoto
>
> On 7/17/20 4:36 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Based on the suggestions, I modified the fix as follows:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>
>> Changes from the initial revision are:
>>
>> - Shared the implementation between compareToCI() and regionMatchesCI()
>> - Enabled immediate short cut if two code points match.
>> - Created a simple JMH benchmark. Here is the scores before and after 
>> the change:
>>
>> before:
>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 53.764 ? 2.811? 
>> ns/op
>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 24.211 ? 1.135? 
>> ns/op
>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.595 ? 1.344? 
>> ns/op
>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 18.859 ? 1.499? 
>> ns/op
>>
>> after:
>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 58.354 ? 4.603? 
>> ns/op
>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 57.975 ? 5.672? 
>> ns/op
>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 23.912 ? 0.965? 
>> ns/op
>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 17.744 ? 0.272? 
>> ns/op
>>
>> Here, "sup" means all supplementary characters, BMP otherwise. 
>> "lower" means each character requires upper->lower casemap. 
>> "upperLower" means all characters are the same, except the last 
>> character which requires casemap.
>>
>> I think the result is reasonable, considering surrogates check are 
>> now mandatory. I have tried Roger's suggestion to use 
>> Arrays.mismatch() but it did not seem to benefit here. In fact, the 
>> performance degraded partly because I implemented the short cut, and 
>> possibly for the overhead of extra checks.
>>
>> Naoto
>>
>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issues:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>
>>> The proposed changeset and its CSR are located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>
>>> A bug was filed against SimpleDateFormat (8248434) where 
>>> case-insensitive date format/parse failed in some of the new locales 
>>> in JDK15. The root cause was that case-insensitive 
>>> String.regionMatches() method did not work with supplementary 
>>> characters. The problem is that the method's spec does not expect 
>>> case mappings of supplementary characters, possibly because it was 
>>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>>> Character support". Similar behavior is observed in other two 
>>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>>> equalsIgnoreCase().
>>>
>>> The fix is straightforward to compare strings by code point basis, 
>>> instead of code unit (16bit "char") basis. Technically this change 
>>> will introduce a backward incompatibility, but I believe it is an 
>>> incompatibility to wrong behavior, not true to the meaning of those 
>>> methods' expectations.
>>>
>>> Naoto


From naoto.sato at oracle.com  Wed Jul 22 20:37:21 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 Jul 2020 13:37:21 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
 <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>
Message-ID: <cf4cae61-3293-df24-221c-0dc03edd1eb5@oracle.com>

Hi Joe,

Thank you for the consecutive reviews!

On 7/22/20 1:20 PM, Joe Wang wrote:
> Hi Naoto,
> 
> The change looks good to me. "supLower" is indeed super slow :-)
> 
> The only minor comment I have is that the compareCodePointCI method 
> performs toUpperCase unconditionally. That's not a problem for the 
> regular case, where a check on cp1 == cp2 (line 337) is done prior to 
> the method call. But for the sup case (starting at line 341), the method 
> is called unconditionally while in webrev.04 there was a check "cp1 != 
> cp2".? One option to fix it is to include the "cp1 != cp2" check in the 
> method compareCodePointCI, then cp1 == cp2 at line 337 can be omitted.

That was intentional, as at the point when it calls compareCodePointCI() 
for the second time, it is guaranteed that the supplementary code points 
differ because either their high surrogates or low surrogates differ.

Naoto

> 
> Regards,
> Joe
> 
> On 7/22/20 10:23 AM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> I revised the fix again, based on further suggestions:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
>>
>> Changes from v.04 are (all in StringUTF16.java):
>>
>> - The short cut now does case insensitive comparison that makes the 
>> fix closer to the previous implementation (for BMP characters).
>> - Changed the bit operation to negating for detecting needed index 
>> increment.
>> - Method name is changed to better reflect what it is doing, with more 
>> descriptive comments.
>>
>> Here is the benchmark results:
>>
>> before:
>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 49.960 ? 1.923? ns/op
>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 21.003 ? 0.354? ns/op
>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.863 ? 4.529? ns/op
>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 15.417 ? 1.046? ns/op
>>
>> after:
>> Benchmark??????????????????????????????? Mode? Cnt??? Score Error? Units
>> StringCompareToIgnoreCase.lower????????? avgt?? 25?? 46.857 ? 0.524 ns/op
>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 148.688 ? 6.546 ns/op
>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25?? 37.160 ? 0.259 ns/op
>> StringCompareToIgnoreCase.upperLower???? avgt?? 25?? 15.126 ? 0.338 ns/op
>>
>> Now non-supplementary operations ("lower" and "upperLower") are on par 
>> with the "before" result (I am not quite sure why the "after" results 
>> are somewhat faster though). For supplementary test cases, "supLower" 
>> is very slow. The reason is two fold; one is because "before" one 
>> exits at the very first character (which I am addressing here) while 
>> "after" continues to compare to the last characters, the other reason 
>> is the test suffers from the change where supplementary cases double 
>> the case insensitivity checks (compared to the "after" result just 
>> below). Also "supUpperLower" gets slower for the same reason. These 
>> are expected results for supplementary comparisons (as we discussed).
>>
>> Naoto
>>
>> On 7/17/20 4:36 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Based on the suggestions, I modified the fix as follows:
>>>
>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>
>>> Changes from the initial revision are:
>>>
>>> - Shared the implementation between compareToCI() and regionMatchesCI()
>>> - Enabled immediate short cut if two code points match.
>>> - Created a simple JMH benchmark. Here is the scores before and after 
>>> the change:
>>>
>>> before:
>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 53.764 ? 2.811 ns/op
>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 24.211 ? 1.135 ns/op
>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.595 ? 1.344 ns/op
>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 18.859 ? 1.499 ns/op
>>>
>>> after:
>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 58.354 ? 4.603 ns/op
>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 57.975 ? 5.672 ns/op
>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 23.912 ? 0.965 ns/op
>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 17.744 ? 0.272 ns/op
>>>
>>> Here, "sup" means all supplementary characters, BMP otherwise. 
>>> "lower" means each character requires upper->lower casemap. 
>>> "upperLower" means all characters are the same, except the last 
>>> character which requires casemap.
>>>
>>> I think the result is reasonable, considering surrogates check are 
>>> now mandatory. I have tried Roger's suggestion to use 
>>> Arrays.mismatch() but it did not seem to benefit here. In fact, the 
>>> performance degraded partly because I implemented the short cut, and 
>>> possibly for the overhead of extra checks.
>>>
>>> Naoto
>>>
>>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issues:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>
>>>> The proposed changeset and its CSR are located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>
>>>> A bug was filed against SimpleDateFormat (8248434) where 
>>>> case-insensitive date format/parse failed in some of the new locales 
>>>> in JDK15. The root cause was that case-insensitive 
>>>> String.regionMatches() method did not work with supplementary 
>>>> characters. The problem is that the method's spec does not expect 
>>>> case mappings of supplementary characters, possibly because it was 
>>>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>>>> Character support". Similar behavior is observed in other two 
>>>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>>>> equalsIgnoreCase().
>>>>
>>>> The fix is straightforward to compare strings by code point basis, 
>>>> instead of code unit (16bit "char") basis. Technically this change 
>>>> will introduce a backward incompatibility, but I believe it is an 
>>>> incompatibility to wrong behavior, not true to the meaning of those 
>>>> methods' expectations.
>>>>
>>>> Naoto
> 

From Roger.Riggs at oracle.com  Wed Jul 22 20:38:36 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 16:38:36 -0400
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
 <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>
Message-ID: <7ccb33b7-c464-8472-ca0d-bdfafecaee40@oracle.com>

Hi Naoto,

Looks fine. (with Joe's suggestion)

On 7/22/20 4:20 PM, Joe Wang wrote:
> Hi Naoto,
>
> The change looks good to me. "supLower" is indeed super slow :-)
>
> The only minor comment I have is that the compareCodePointCI method 
> performs toUpperCase unconditionally. That's not a problem for the 
> regular case, where a check on cp1 == cp2 (line 337) is done prior to 
> the method call. But for the sup case (starting at line 341), the 
> method is called unconditionally while in webrev.04 there was a check 
> "cp1 != cp2".? One option to fix it is to include the "cp1 != cp2" 
> check in the method compareCodePointCI, then cp1 == cp2 at line 337 
> can be omitted.
I would have added to line 353 the same cp1 == cp2 check as 337 to avoid 
the method call
unless it was needed.

Roger

>
> Regards,
> Joe
>
> On 7/22/20 10:23 AM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> I revised the fix again, based on further suggestions:
>>
>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
>>
>> Changes from v.04 are (all in StringUTF16.java):
>>
>> - The short cut now does case insensitive comparison that makes the 
>> fix closer to the previous implementation (for BMP characters).
>> - Changed the bit operation to negating for detecting needed index 
>> increment.
>> - Method name is changed to better reflect what it is doing, with 
>> more descriptive comments.
>>
>> Here is the benchmark results:
>>
>> before:
>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 49.960 ? 1.923? 
>> ns/op
>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 21.003 ? 0.354? 
>> ns/op
>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.863 ? 4.529? 
>> ns/op
>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 15.417 ? 1.046? 
>> ns/op
>>
>> after:
>> Benchmark??????????????????????????????? Mode? Cnt??? Score Error? Units
>> StringCompareToIgnoreCase.lower????????? avgt?? 25?? 46.857 ? 0.524? 
>> ns/op
>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 148.688 ? 6.546? 
>> ns/op
>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25?? 37.160 ? 0.259? 
>> ns/op
>> StringCompareToIgnoreCase.upperLower???? avgt?? 25?? 15.126 ? 0.338? 
>> ns/op
>>
>> Now non-supplementary operations ("lower" and "upperLower") are on 
>> par with the "before" result (I am not quite sure why the "after" 
>> results are somewhat faster though). For supplementary test cases, 
>> "supLower" is very slow. The reason is two fold; one is because 
>> "before" one exits at the very first character (which I am addressing 
>> here) while "after" continues to compare to the last characters, the 
>> other reason is the test suffers from the change where supplementary 
>> cases double the case insensitivity checks (compared to the "after" 
>> result just below). Also "supUpperLower" gets slower for the same 
>> reason. These are expected results for supplementary comparisons (as 
>> we discussed).
>>
>> Naoto
>>
>> On 7/17/20 4:36 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Based on the suggestions, I modified the fix as follows:
>>>
>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>
>>> Changes from the initial revision are:
>>>
>>> - Shared the implementation between compareToCI() and regionMatchesCI()
>>> - Enabled immediate short cut if two code points match.
>>> - Created a simple JMH benchmark. Here is the scores before and 
>>> after the change:
>>>
>>> before:
>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 53.764 ? 2.811? 
>>> ns/op
>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 24.211 ? 1.135? 
>>> ns/op
>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.595 ? 1.344? 
>>> ns/op
>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 18.859 ? 1.499? 
>>> ns/op
>>>
>>> after:
>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 58.354 ? 4.603? 
>>> ns/op
>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 57.975 ? 5.672? 
>>> ns/op
>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 23.912 ? 0.965? 
>>> ns/op
>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 17.744 ? 0.272? 
>>> ns/op
>>>
>>> Here, "sup" means all supplementary characters, BMP otherwise. 
>>> "lower" means each character requires upper->lower casemap. 
>>> "upperLower" means all characters are the same, except the last 
>>> character which requires casemap.
>>>
>>> I think the result is reasonable, considering surrogates check are 
>>> now mandatory. I have tried Roger's suggestion to use 
>>> Arrays.mismatch() but it did not seem to benefit here. In fact, the 
>>> performance degraded partly because I implemented the short cut, and 
>>> possibly for the overhead of extra checks.
>>>
>>> Naoto
>>>
>>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issues:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>
>>>> The proposed changeset and its CSR are located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>
>>>> A bug was filed against SimpleDateFormat (8248434) where 
>>>> case-insensitive date format/parse failed in some of the new 
>>>> locales in JDK15. The root cause was that case-insensitive 
>>>> String.regionMatches() method did not work with supplementary 
>>>> characters. The problem is that the method's spec does not expect 
>>>> case mappings of supplementary characters, possibly because it was 
>>>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>>>> Character support". Similar behavior is observed in other two 
>>>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>>>> equalsIgnoreCase().
>>>>
>>>> The fix is straightforward to compare strings by code point basis, 
>>>> instead of code unit (16bit "char") basis. Technically this change 
>>>> will introduce a backward incompatibility, but I believe it is an 
>>>> incompatibility to wrong behavior, not true to the meaning of those 
>>>> methods' expectations.
>>>>
>>>> Naoto
>


From naoto.sato at oracle.com  Wed Jul 22 20:43:54 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 Jul 2020 13:43:54 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <7ccb33b7-c464-8472-ca0d-bdfafecaee40@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
 <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>
 <7ccb33b7-c464-8472-ca0d-bdfafecaee40@oracle.com>
Message-ID: <793963e6-70d7-acc8-e76c-5d22a09ff43c@oracle.com>

Thanks Roger,

Ah, I just saw your email just after I sent mine!

On 7/22/20 1:38 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> Looks fine. (with Joe's suggestion)
> 
> On 7/22/20 4:20 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> The change looks good to me. "supLower" is indeed super slow :-)
>>
>> The only minor comment I have is that the compareCodePointCI method 
>> performs toUpperCase unconditionally. That's not a problem for the 
>> regular case, where a check on cp1 == cp2 (line 337) is done prior to 
>> the method call. But for the sup case (starting at line 341), the 
>> method is called unconditionally while in webrev.04 there was a check 
>> "cp1 != cp2".? One option to fix it is to include the "cp1 != cp2" 
>> check in the method compareCodePointCI, then cp1 == cp2 at line 337 
>> can be omitted.
> I would have added to line 353 the same cp1 == cp2 check as 337 to avoid 
> the method call
> unless it was needed.

As in the previous email, cp1 != cp2 at that point, since either high or 
low surrogates differ.

Naoto

> 
> Roger
> 
>>
>> Regards,
>> Joe
>>
>> On 7/22/20 10:23 AM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> I revised the fix again, based on further suggestions:
>>>
>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
>>>
>>> Changes from v.04 are (all in StringUTF16.java):
>>>
>>> - The short cut now does case insensitive comparison that makes the 
>>> fix closer to the previous implementation (for BMP characters).
>>> - Changed the bit operation to negating for detecting needed index 
>>> increment.
>>> - Method name is changed to better reflect what it is doing, with 
>>> more descriptive comments.
>>>
>>> Here is the benchmark results:
>>>
>>> before:
>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 49.960 ? 1.923 ns/op
>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 21.003 ? 0.354 ns/op
>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.863 ? 4.529 ns/op
>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 15.417 ? 1.046 ns/op
>>>
>>> after:
>>> Benchmark??????????????????????????????? Mode? Cnt??? Score Error? Units
>>> StringCompareToIgnoreCase.lower????????? avgt?? 25?? 46.857 ? 0.524 
>>> ns/op
>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 148.688 ? 6.546 
>>> ns/op
>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25?? 37.160 ? 0.259 
>>> ns/op
>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25?? 15.126 ? 0.338 
>>> ns/op
>>>
>>> Now non-supplementary operations ("lower" and "upperLower") are on 
>>> par with the "before" result (I am not quite sure why the "after" 
>>> results are somewhat faster though). For supplementary test cases, 
>>> "supLower" is very slow. The reason is two fold; one is because 
>>> "before" one exits at the very first character (which I am addressing 
>>> here) while "after" continues to compare to the last characters, the 
>>> other reason is the test suffers from the change where supplementary 
>>> cases double the case insensitivity checks (compared to the "after" 
>>> result just below). Also "supUpperLower" gets slower for the same 
>>> reason. These are expected results for supplementary comparisons (as 
>>> we discussed).
>>>
>>> Naoto
>>>
>>> On 7/17/20 4:36 PM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Based on the suggestions, I modified the fix as follows:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>
>>>> Changes from the initial revision are:
>>>>
>>>> - Shared the implementation between compareToCI() and regionMatchesCI()
>>>> - Enabled immediate short cut if two code points match.
>>>> - Created a simple JMH benchmark. Here is the scores before and 
>>>> after the change:
>>>>
>>>> before:
>>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 53.764 ? 2.811 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 24.211 ? 1.135 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.595 ? 1.344 
>>>> ns/op
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 18.859 ? 1.499 
>>>> ns/op
>>>>
>>>> after:
>>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? Units
>>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 58.354 ? 4.603 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 57.975 ? 5.672 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 23.912 ? 0.965 
>>>> ns/op
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 17.744 ? 0.272 
>>>> ns/op
>>>>
>>>> Here, "sup" means all supplementary characters, BMP otherwise. 
>>>> "lower" means each character requires upper->lower casemap. 
>>>> "upperLower" means all characters are the same, except the last 
>>>> character which requires casemap.
>>>>
>>>> I think the result is reasonable, considering surrogates check are 
>>>> now mandatory. I have tried Roger's suggestion to use 
>>>> Arrays.mismatch() but it did not seem to benefit here. In fact, the 
>>>> performance degraded partly because I implemented the short cut, and 
>>>> possibly for the overhead of extra checks.
>>>>
>>>> Naoto
>>>>
>>>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix to the following issues:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>>
>>>>> The proposed changeset and its CSR are located at:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>>
>>>>> A bug was filed against SimpleDateFormat (8248434) where 
>>>>> case-insensitive date format/parse failed in some of the new 
>>>>> locales in JDK15. The root cause was that case-insensitive 
>>>>> String.regionMatches() method did not work with supplementary 
>>>>> characters. The problem is that the method's spec does not expect 
>>>>> case mappings of supplementary characters, possibly because it was 
>>>>> overlooked in the first place, JSR 204 - "Unicode Supplementary 
>>>>> Character support". Similar behavior is observed in other two 
>>>>> case-insensitive methods, i.e., compareToIgnoreCase() and 
>>>>> equalsIgnoreCase().
>>>>>
>>>>> The fix is straightforward to compare strings by code point basis, 
>>>>> instead of code unit (16bit "char") basis. Technically this change 
>>>>> will introduce a backward incompatibility, but I believe it is an 
>>>>> incompatibility to wrong behavior, not true to the meaning of those 
>>>>> methods' expectations.
>>>>>
>>>>> Naoto
>>
> 

From joe.darcy at oracle.com  Wed Jul 22 20:55:12 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 22 Jul 2020 13:55:12 -0700
Subject: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated
 method to match the proxy interface method
In-Reply-To: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>
References: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>
Message-ID: <6eda7ac3-0632-4f73-929b-1c3e89b33b26@oracle.com>

Hi Mandy,

The behavior change looks okay; please file a CSR for this too.

Thanks,

-Joe

On 7/22/2020 12:04 PM, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
>
> A small improvement to the dynamic proxy generated method to have
> ACC_VARARGS matching the method declared in a proxy interface if set.
> If there are two or more proxy interfaces declaring such a method,
> it matches the method declared in the first proxy interface.
>
> thanks
> Mandy
>

From huizhe.wang at oracle.com  Wed Jul 22 21:32:51 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 22 Jul 2020 14:32:51 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <793963e6-70d7-acc8-e76c-5d22a09ff43c@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
 <db719edd-aded-3274-e958-6ff44d6e577b@oracle.com>
 <7ccb33b7-c464-8472-ca0d-bdfafecaee40@oracle.com>
 <793963e6-70d7-acc8-e76c-5d22a09ff43c@oracle.com>
Message-ID: <95c3a383-72a7-31cc-6f67-5f46f91d3073@oracle.com>


On 7/22/20 1:43 PM, naoto.sato at oracle.com wrote:
> Thanks Roger,
>
> Ah, I just saw your email just after I sent mine!

They probably saw each other crossing and said hi on the way to inboxes ;-)
>
> On 7/22/20 1:38 PM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> Looks fine. (with Joe's suggestion)
>>
>> On 7/22/20 4:20 PM, Joe Wang wrote:
>>> Hi Naoto,
>>>
>>> The change looks good to me. "supLower" is indeed super slow :-)
>>>
>>> The only minor comment I have is that the compareCodePointCI method 
>>> performs toUpperCase unconditionally. That's not a problem for the 
>>> regular case, where a check on cp1 == cp2 (line 337) is done prior 
>>> to the method call. But for the sup case (starting at line 341), the 
>>> method is called unconditionally while in webrev.04 there was a 
>>> check "cp1 != cp2".? One option to fix it is to include the "cp1 != 
>>> cp2" check in the method compareCodePointCI, then cp1 == cp2 at line 
>>> 337 can be omitted.
>> I would have added to line 353 the same cp1 == cp2 check as 337 to 
>> avoid the method call
>> unless it was needed.
>
> As in the previous email, cp1 != cp2 at that point, since either high 
> or low surrogates differ.

Make sense. The webrev looks good to me.

-Joe

>
> Naoto
>
>>
>> Roger
>>
>>>
>>> Regards,
>>> Joe
>>>
>>> On 7/22/20 10:23 AM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> I revised the fix again, based on further suggestions:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
>>>>
>>>> Changes from v.04 are (all in StringUTF16.java):
>>>>
>>>> - The short cut now does case insensitive comparison that makes the 
>>>> fix closer to the previous implementation (for BMP characters).
>>>> - Changed the bit operation to negating for detecting needed index 
>>>> increment.
>>>> - Method name is changed to better reflect what it is doing, with 
>>>> more descriptive comments.
>>>>
>>>> Here is the benchmark results:
>>>>
>>>> before:
>>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? 
>>>> Units
>>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 49.960 ? 1.923 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 21.003 ? 0.354 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.863 ? 4.529 
>>>> ns/op
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 15.417 ? 1.046 
>>>> ns/op
>>>>
>>>> after:
>>>> Benchmark??????????????????????????????? Mode? Cnt??? Score Error? 
>>>> Units
>>>> StringCompareToIgnoreCase.lower????????? avgt?? 25?? 46.857 ? 0.524 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 148.688 ? 6.546 
>>>> ns/op
>>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25?? 37.160 ? 0.259 
>>>> ns/op
>>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25?? 15.126 ? 0.338 
>>>> ns/op
>>>>
>>>> Now non-supplementary operations ("lower" and "upperLower") are on 
>>>> par with the "before" result (I am not quite sure why the "after" 
>>>> results are somewhat faster though). For supplementary test cases, 
>>>> "supLower" is very slow. The reason is two fold; one is because 
>>>> "before" one exits at the very first character (which I am 
>>>> addressing here) while "after" continues to compare to the last 
>>>> characters, the other reason is the test suffers from the change 
>>>> where supplementary cases double the case insensitivity checks 
>>>> (compared to the "after" result just below). Also "supUpperLower" 
>>>> gets slower for the same reason. These are expected results for 
>>>> supplementary comparisons (as we discussed).
>>>>
>>>> Naoto
>>>>
>>>> On 7/17/20 4:36 PM, naoto.sato at oracle.com wrote:
>>>>> Hi,
>>>>>
>>>>> Based on the suggestions, I modified the fix as follows:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.01/
>>>>>
>>>>> Changes from the initial revision are:
>>>>>
>>>>> - Shared the implementation between compareToCI() and 
>>>>> regionMatchesCI()
>>>>> - Enabled immediate short cut if two code points match.
>>>>> - Created a simple JMH benchmark. Here is the scores before and 
>>>>> after the change:
>>>>>
>>>>> before:
>>>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? 
>>>>> Units
>>>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 53.764 ? 2.811 
>>>>> ns/op
>>>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 24.211 ? 1.135 
>>>>> ns/op
>>>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 30.595 ? 1.344 
>>>>> ns/op
>>>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 18.859 ? 1.499 
>>>>> ns/op
>>>>>
>>>>> after:
>>>>> Benchmark??????????????????????????????? Mode? Cnt?? Score Error? 
>>>>> Units
>>>>> StringCompareToIgnoreCase.lower????????? avgt?? 25? 58.354 ? 4.603 
>>>>> ns/op
>>>>> StringCompareToIgnoreCase.supLower?????? avgt?? 25? 57.975 ? 5.672 
>>>>> ns/op
>>>>> StringCompareToIgnoreCase.supUpperLower? avgt?? 25? 23.912 ? 0.965 
>>>>> ns/op
>>>>> StringCompareToIgnoreCase.upperLower???? avgt?? 25? 17.744 ? 0.272 
>>>>> ns/op
>>>>>
>>>>> Here, "sup" means all supplementary characters, BMP otherwise. 
>>>>> "lower" means each character requires upper->lower casemap. 
>>>>> "upperLower" means all characters are the same, except the last 
>>>>> character which requires casemap.
>>>>>
>>>>> I think the result is reasonable, considering surrogates check are 
>>>>> now mandatory. I have tried Roger's suggestion to use 
>>>>> Arrays.mismatch() but it did not seem to benefit here. In fact, 
>>>>> the performance degraded partly because I implemented the short 
>>>>> cut, and possibly for the overhead of extra checks.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 7/15/20 9:00 AM, naoto.sato at oracle.com wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix to the following issues:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8248655
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8248434
>>>>>>
>>>>>> The proposed changeset and its CSR are located at:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8248664
>>>>>>
>>>>>> A bug was filed against SimpleDateFormat (8248434) where 
>>>>>> case-insensitive date format/parse failed in some of the new 
>>>>>> locales in JDK15. The root cause was that case-insensitive 
>>>>>> String.regionMatches() method did not work with supplementary 
>>>>>> characters. The problem is that the method's spec does not expect 
>>>>>> case mappings of supplementary characters, possibly because it 
>>>>>> was overlooked in the first place, JSR 204 - "Unicode 
>>>>>> Supplementary Character support". Similar behavior is observed in 
>>>>>> other two case-insensitive methods, i.e., compareToIgnoreCase() 
>>>>>> and equalsIgnoreCase().
>>>>>>
>>>>>> The fix is straightforward to compare strings by code point 
>>>>>> basis, instead of code unit (16bit "char") basis. Technically 
>>>>>> this change will introduce a backward incompatibility, but I 
>>>>>> believe it is an incompatibility to wrong behavior, not true to 
>>>>>> the meaning of those methods' expectations.
>>>>>>
>>>>>> Naoto
>>>
>>


From vladimir.x.ivanov at oracle.com  Wed Jul 22 21:36:52 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 23 Jul 2020 00:36:52 +0300
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
Message-ID: <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>

> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 

FTR there's one more aarch64-specific change in shared code to enable 
aarch64_neon.ad processing:

diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
b/make/hotspot/gensrc/GensrcAdlc.gmk
--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -129,6 +129,12 @@
 
$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
\
      )))

+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
+    AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \
+ 
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
+    )))
+  endif
+
    ifeq ($(call check-jvm-feature, shenandoahgc), true)
      AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \
 
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
\

Best regards,
Vladimir Ivanov

> On 7/8/20 3:05 PM, Yang Zhang wrote:
>> Hi Andrew
>>
>> I have updated this patch. Could you please help to review it again?
>> In this patch, the following changes are made:
>> 1. Separate newly added NEON instructions to a new ad file
>> ??? aarch64_neon.ad
>> 2. Add assembler tests for NEON instructions. Trailing spaces
>> ??? in the python script are also removed.
>>
>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>
>>
>> Thanks,
>> Yang
>>
>>
>> -----Original Message-----
>> From: Andrew Haley <aph at redhat.com>
>> Sent: Tuesday, June 30, 2020 12:10 AM
>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>> aarch64-port-dev at openjdk.java.net
>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>> Vector API (Incubator): AArch64 backend changes
>>
>> On 29/06/2020 08:48, Yang Zhang wrote:
>>> 1. Instructions that can be matched with NEON instructions directly.
>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>
>>> 2. Instructions that jdk master has middle end support for, but they 
>>> cannot be matched with NEON instructions directly.
>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>> new instructions can be moved into jdk master first, but for 
>>> auto-vectorization, the performance might not get improved.
>>>
>>> 3. Panama/Vector API specific? instructions such as Load/StoreVector 
>>> ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend 
>>> etc.
>>> These instructions cannot be moved into jdk master first because 
>>> there isn't middle-end support.
>>>
>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>> ready, I will send it again.
>>
>> Thank you *very* much for your hard work. Appreciated!
>>
>> -- 
>> 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 brent.christian at oracle.com  Wed Jul 22 22:13:39 2020
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 22 Jul 2020 15:13:39 -0700
Subject: RFR: 8248655: Support supplementary characters in String case
 insensitive operations
In-Reply-To: <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
References: <bdae317d-617f-6ec8-44d7-4a2194591050@oracle.com>
 <1c9dad7c-bda7-f060-0c97-0bb5f848d0ef@oracle.com>
 <439b2c80-72d1-92fb-7691-c2a1e59f1aad@oracle.com>
Message-ID: <2a1dedcb-28a5-a14c-bb7f-52da57c1a381@oracle.com>

Hi, Naoto

The latest changes look good to me.

-Brent

On 7/22/20 10:23 AM, naoto.sato at oracle.com wrote:
> Hi,
> 
> I revised the fix again, based on further suggestions:
> 
> https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
> 
> Changes from v.04 are (all in StringUTF16.java):
> 
> - The short cut now does case insensitive comparison that makes the fix 
> closer to the previous implementation (for BMP characters).
> - Changed the bit operation to negating for detecting needed index 
> increment.
> - Method name is changed to better reflect what it is doing, with more 
> descriptive comments.
> 

From mandy.chung at oracle.com  Wed Jul 22 22:40:50 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Jul 2020 15:40:50 -0700
Subject: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated
 method to match the proxy interface method
In-Reply-To: <6eda7ac3-0632-4f73-929b-1c3e89b33b26@oracle.com>
References: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>
 <6eda7ac3-0632-4f73-929b-1c3e89b33b26@oracle.com>
Message-ID: <03fe3710-9d88-7924-9be0-cd2edf6ac4d6@oracle.com>

Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8249939

Thanks
Mandy

On 7/22/20 1:55 PM, Joe Darcy wrote:
> Hi Mandy,
>
> The behavior change looks okay; please file a CSR for this too.
>
> Thanks,
>
> -Joe
>
> On 7/22/2020 12:04 PM, Mandy Chung wrote:
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
>>
>> A small improvement to the dynamic proxy generated method to have
>> ACC_VARARGS matching the method declared in a proxy interface if set.
>> If there are two or more proxy interfaces declaring such a method,
>> it matches the method declared in the first proxy interface.
>>
>> thanks
>> Mandy
>>


From david.holmes at oracle.com  Wed Jul 22 23:00:43 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jul 2020 09:00:43 +1000
Subject: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h in
 native tests
Message-ID: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/

A number of native tests in hotspot and jdk include the jni_util.h 
header file which is part of the sources for libjava and not part of the 
testing framework, nor an exported interface for the JDK. This seems to 
have occurred through copy-and-paste when creating the tests as the 
include is not needed.

test/hotspot/jtreg/runtime/jni/FindClass/libbootLoaderTest.c
test/hotspot/jtreg/runtime/jni/registerNativesWarning/libregisterNativesWarning.c
test/hotspot/jtreg/runtime/jni/terminatedThread/libterminatedThread.c
test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c
test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c
test/jdk/jdk/internal/loader/NativeLibraries/libnativeLibrariesTest.c

There is one test that includes jni_util.h and uses the utility function 
declared there:
./jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c
so that is left as-is.

Thanks,
David
-----

From igor.ignatyev at oracle.com  Wed Jul 22 23:09:13 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 22 Jul 2020 16:09:13 -0700
Subject: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h
 in native tests
In-Reply-To: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>
References: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>
Message-ID: <498178C1-A8AD-4A4A-B94F-F61DC02C2B0F@oracle.com>

Hi David,

looks good to me.

-- Igor

> On Jul 22, 2020, at 4:00 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
> webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
> 
> A number of native tests in hotspot and jdk include the jni_util.h header file which is part of the sources for libjava and not part of the testing framework, nor an exported interface for the JDK. This seems to have occurred through copy-and-paste when creating the tests as the include is not needed.
> 
> test/hotspot/jtreg/runtime/jni/FindClass/libbootLoaderTest.c
> test/hotspot/jtreg/runtime/jni/registerNativesWarning/libregisterNativesWarning.c
> test/hotspot/jtreg/runtime/jni/terminatedThread/libterminatedThread.c
> test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c
> test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c
> test/jdk/jdk/internal/loader/NativeLibraries/libnativeLibrariesTest.c
> 
> There is one test that includes jni_util.h and uses the utility function declared there:
> ./jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c
> so that is left as-is.
> 
> Thanks,
> David
> -----


From david.holmes at oracle.com  Wed Jul 22 23:29:45 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jul 2020 09:29:45 +1000
Subject: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h
 in native tests
In-Reply-To: <498178C1-A8AD-4A4A-B94F-F61DC02C2B0F@oracle.com>
References: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>
 <498178C1-A8AD-4A4A-B94F-F61DC02C2B0F@oracle.com>
Message-ID: <2358514a-c8a5-3b10-b0c3-6fba4d1848dc@oracle.com>

Thanks Igor!

David

On 23/07/2020 9:09 am, Igor Ignatyev wrote:
> Hi David,
> 
> looks good to me.
> 
> -- Igor
> 
>> On Jul 22, 2020, at 4:00 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
>> webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
>>
>> A number of native tests in hotspot and jdk include the jni_util.h header file which is part of the sources for libjava and not part of the testing framework, nor an exported interface for the JDK. This seems to have occurred through copy-and-paste when creating the tests as the include is not needed.
>>
>> test/hotspot/jtreg/runtime/jni/FindClass/libbootLoaderTest.c
>> test/hotspot/jtreg/runtime/jni/registerNativesWarning/libregisterNativesWarning.c
>> test/hotspot/jtreg/runtime/jni/terminatedThread/libterminatedThread.c
>> test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c
>> test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c
>> test/jdk/jdk/internal/loader/NativeLibraries/libnativeLibrariesTest.c
>>
>> There is one test that includes jni_util.h and uses the utility function declared there:
>> ./jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c
>> so that is left as-is.
>>
>> Thanks,
>> David
>> -----
> 

From Roger.Riggs at oracle.com  Wed Jul 22 23:47:56 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 19:47:56 -0400
Subject: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated
 method to match the proxy interface method
In-Reply-To: <03fe3710-9d88-7924-9be0-cd2edf6ac4d6@oracle.com>
References: <f00d3900-ef86-2f83-c407-72afe1cefe7e@oracle.com>
 <6eda7ac3-0632-4f73-929b-1c3e89b33b26@oracle.com>
 <03fe3710-9d88-7924-9be0-cd2edf6ac4d6@oracle.com>
Message-ID: <411d9c3b-7166-67cd-2829-9ab0f511356a@oracle.com>

Hi Mandy,

Looks good.

On 7/22/20 6:40 PM, Mandy Chung wrote:
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8249939
>
> Thanks
> Mandy
>
> On 7/22/20 1:55 PM, Joe Darcy wrote:
>> Hi Mandy,
>>
>> The behavior change looks okay; please file a CSR for this too.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 7/22/2020 12:04 PM, Mandy Chung wrote:
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
>>>
>>> A small improvement to the dynamic proxy generated method to have
>>> ACC_VARARGS matching the method declared in a proxy interface if set.
>>> If there are two or more proxy interfaces declaring such a method,
>>> it matches the method declared in the first proxy interface.
>>>
>>> thanks
>>> Mandy
>>>
>


From martinrb at google.com  Thu Jul 23 00:06:34 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 22 Jul 2020 17:06:34 -0700
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
Message-ID: <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>

Looks good.

I might move the static class preloading into a static method of the
reaper thread class, to make it clearly the responsibility of the
reaper thread class to enumerate and pre-load its dependencies.

On Wed, Jul 22, 2020 at 7:59 AM Peter Levart <peter.levart at gmail.com> wrote:
>
> Hi Roger,
>
>
> I don't think resolving the ConcurrentHashMap.class ensures
> initialization of the class. Just loading. But I think CHM is already
> initialized at that time as it is used in ClassLoader to maintain class
> loading locks (per class name).
>
>
> Regards, Peter
>
>
> On 7/22/20 4:51 PM, Roger Riggs wrote:
> > Please review a change to the Process reaper thread initialization to
> > preemptively
> > make sure classes ThreadLocalRandom and ConcurrentHashMap are
> > initialized.
> > From the stack overflow failures, it seems that the classes have not
> > been initialized
> > before they are used during processing the termination of a process.
> > When the initialization is performed on the smaller reaper stack, it
> > occasionally
> > exceeds the available stack.
> >
> > As an aid to diagnostics,
> > -XX:AbortVMOnException=java.lang.StackOverflowError
> > is added to TestHumongousNonArrayAllocation that has failed
> > intermittently.
> > If the problem happens again it will produce an hs_error file with
> > useful details
> > and will otherwise not change the test behavior.
> >
> > Webrev:
> > http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
> >
> > Issue:
> >   https://bugs.openjdk.java.net/browse/JDK-8249217
> >
> > Thanks, Roger
> >

From Roger.Riggs at oracle.com  Thu Jul 23 00:24:55 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 20:24:55 -0400
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
 <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>
Message-ID: <507f8eaf-4f6f-1b07-4ab2-049032f4e729@oracle.com>

Hi Martin,

That's a good idea, but unless I miss your point, there is no Reaper class,
only a lambda that is used as to create the Executor for the reaper 
thread pool.

Do you mean to put it before or after lines 91-93?? [1]

Thanks, Roger

[1] 
http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/src/java.base/share/classes/java/lang/ProcessHandleImpl.java.sdiff.html


On 7/22/20 8:06 PM, Martin Buchholz wrote:
> Looks good.
>
> I might move the static class preloading into a static method of the
> reaper thread class, to make it clearly the responsibility of the
> reaper thread class to enumerate and pre-load its dependencies.
>
> On Wed, Jul 22, 2020 at 7:59 AM Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Roger,
>>
>>
>> I don't think resolving the ConcurrentHashMap.class ensures
>> initialization of the class. Just loading. But I think CHM is already
>> initialized at that time as it is used in ClassLoader to maintain class
>> loading locks (per class name).
>>
>>
>> Regards, Peter
>>
>>
>> On 7/22/20 4:51 PM, Roger Riggs wrote:
>>> Please review a change to the Process reaper thread initialization to
>>> preemptively
>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
>>> initialized.
>>>  From the stack overflow failures, it seems that the classes have not
>>> been initialized
>>> before they are used during processing the termination of a process.
>>> When the initialization is performed on the smaller reaper stack, it
>>> occasionally
>>> exceeds the available stack.
>>>
>>> As an aid to diagnostics,
>>> -XX:AbortVMOnException=java.lang.StackOverflowError
>>> is added to TestHumongousNonArrayAllocation that has failed
>>> intermittently.
>>> If the problem happens again it will produce an hs_error file with
>>> useful details
>>> and will otherwise not change the test behavior.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>>
>>> Issue:
>>>    https://bugs.openjdk.java.net/browse/JDK-8249217
>>>
>>> Thanks, Roger
>>>


From martinrb at google.com  Thu Jul 23 00:35:55 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 22 Jul 2020 17:35:55 -0700
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <507f8eaf-4f6f-1b07-4ab2-049032f4e729@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
 <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>
 <507f8eaf-4f6f-1b07-4ab2-049032f4e729@oracle.com>
Message-ID: <CA+kOe08ZykW3HB64h78DoUmo9B_LsL147=XnhMo05fo725XJaA@mail.gmail.com>

Roger: You're absolutely right!  I should have looked.

On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
> Hi Martin,
>
> That's a good idea, but unless I miss your point, there is no Reaper class,
> only a lambda that is used as to create the Executor for the reaper
> thread pool.
>
> Do you mean to put it before or after lines 91-93?  [1]
>
> Thanks, Roger
>
> [1]
> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/src/java.base/share/classes/java/lang/ProcessHandleImpl.java.sdiff.html
>
>
> On 7/22/20 8:06 PM, Martin Buchholz wrote:
> > Looks good.
> >
> > I might move the static class preloading into a static method of the
> > reaper thread class, to make it clearly the responsibility of the
> > reaper thread class to enumerate and pre-load its dependencies.
> >
> > On Wed, Jul 22, 2020 at 7:59 AM Peter Levart <peter.levart at gmail.com> wrote:
> >> Hi Roger,
> >>
> >>
> >> I don't think resolving the ConcurrentHashMap.class ensures
> >> initialization of the class. Just loading. But I think CHM is already
> >> initialized at that time as it is used in ClassLoader to maintain class
> >> loading locks (per class name).
> >>
> >>
> >> Regards, Peter
> >>
> >>
> >> On 7/22/20 4:51 PM, Roger Riggs wrote:
> >>> Please review a change to the Process reaper thread initialization to
> >>> preemptively
> >>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
> >>> initialized.
> >>>  From the stack overflow failures, it seems that the classes have not
> >>> been initialized
> >>> before they are used during processing the termination of a process.
> >>> When the initialization is performed on the smaller reaper stack, it
> >>> occasionally
> >>> exceeds the available stack.
> >>>
> >>> As an aid to diagnostics,
> >>> -XX:AbortVMOnException=java.lang.StackOverflowError
> >>> is added to TestHumongousNonArrayAllocation that has failed
> >>> intermittently.
> >>> If the problem happens again it will produce an hs_error file with
> >>> useful details
> >>> and will otherwise not change the test behavior.
> >>>
> >>> Webrev:
> >>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
> >>>
> >>> Issue:
> >>>    https://bugs.openjdk.java.net/browse/JDK-8249217
> >>>
> >>> Thanks, Roger
> >>>
>

From david.holmes at oracle.com  Thu Jul 23 01:16:39 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jul 2020 11:16:39 +1000
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
Message-ID: <4f5ca21b-794c-aa0e-0195-c217729cd506@oracle.com>

Hi Roger,

On 23/07/2020 12:51 am, Roger Riggs wrote:
> Please review a change to the Process reaper thread initialization to 
> preemptively
> make sure classes ThreadLocalRandom and ConcurrentHashMap are initialized.

I don't see ThreadLocalRandom  appearing in any of the stack traces. ??

David
-----

>  From the stack overflow failures, it seems that the classes have not 
> been initialized
> before they are used during processing the termination of a process.
> When the initialization is performed on the smaller reaper stack, it 
> occasionally
> exceeds the available stack.
> 
> As an aid to diagnostics, 
> -XX:AbortVMOnException=java.lang.StackOverflowError
> is added to TestHumongousNonArrayAllocation that has failed intermittently.
> If the problem happens again it will produce an hs_error file with 
> useful details
> and will otherwise not change the test behavior.
> 
> Webrev:
>  ?? http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
> 
> Issue:
>  ? https://bugs.openjdk.java.net/browse/JDK-8249217
> 
> Thanks, Roger
> 

From Roger.Riggs at oracle.com  Thu Jul 23 01:27:09 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 Jul 2020 21:27:09 -0400
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <4f5ca21b-794c-aa0e-0195-c217729cd506@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <4f5ca21b-794c-aa0e-0195-c217729cd506@oracle.com>
Message-ID: <ef5a9850-ad6f-a3fd-cb89-a37d2822c064@oracle.com>

Hi David,

It took some digging in the hs_err files and looking at a core dump to 
determine what class
was being initialized.

I attached one to the current bug, there are others on the previous bug.

The "call_class_initializer" is the hook.

Roger

Stack: [0x00007f41eeeb8000,0x00007f41eeedc000], sp=0x00007f41eeed1e80,? 
free space=103k
Native frames: (J=compiled Java code, A=aot compiled Java code, 
j=interpreted, Vv=VM code, C=native code)
V? [libjvm.so+0xa78e24] Exceptions::debug_check_abort_helper(Handle, 
char const*)+0x184
V? [libjvm.so+0xa79b01]? Exceptions::_throw(Thread*, char const*, int, 
Handle, char const*)+0x121
V? [libjvm.so+0xa7b69e] 
Exceptions::throw_stack_overflow_exception(Thread*, char const*, int, 
methodHandle const&)+0xde
V? [libjvm.so+0xcfff7f]? JavaCalls::call_helper(JavaValue*, methodHandle 
const&, JavaCallArguments*, Thread*)+0x39f
V? [libjvm.so+0xcc128f] InstanceKlass::call_class_initializer(Thread*)+0x1bf
V? [libjvm.so+0xcc2787] InstanceKlass::initialize_impl(Thread*)+0x637
V? [libjvm.so+0x113093f] LinkResolver::resolve_static_call(CallInfo&, 
LinkInfo const&, bool, Thread*)+0xcf
V? [libjvm.so+0x11377e3] LinkResolver::resolve_invoke(CallInfo&, Handle, 
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x183
V? [libjvm.so+0x15474e3] 
SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&, 
Bytecodes::Code&, CallInfo&, Thread*)+0x5f3
V? [libjvm.so+0x15498ae] SharedRuntime::resolve_sub_helper(JavaThread*, 
bool, bool, Thread*)+0x18e
V? [libjvm.so+0x1549eae]? SharedRuntime::resolve_helper(JavaThread*, 
bool, bool, Thread*)+0x4e
V? [libjvm.so+0x154a1b1] 
SharedRuntime::resolve_static_call_C(JavaThread*)+0x131
v? ~RuntimeStub::resolve_static_call
J 5841 c1 java.util.concurrent.ConcurrentHashMap.fullAddCount(JZ)V 
java.base at 16-internal (462 bytes) @ 0x00007f4209952e4c 
[0x00007f4209952de0+0x000000000000006c]
J 4202 c2 java.util.concurrent.ConcurrentHashMap.addCount(JI)V 
java.base at 16-internal (280 bytes) @ 0x00007f42109cf734 
[0x00007f42109cf6e0+0x0000000000000054]
J 4213 c1 
java.util.concurrent.ConcurrentHashMap.putVal(Ljava/lang/Object;Ljava/lang/Object;Z)Ljava/lang/Object; 
java.base at 16-internal (432 bytes) @ 0x00007f4209a5a374 
[0x00007f4209a59800+0x0000000000000b74]
J 798 c1 
java.lang.invoke.MethodType$ConcurrentWeakInternSet.add(Ljava/lang/Object;)Ljava/lang/Object; 
java.base at 16-internal (66 bytes) @ 0x00007f42094af3b4 
[0x00007f42094af0a0+0x0000000000000314]
J 880 c1 
java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; 
java.base at 16-internal (108 bytes) @ 0x00007f42094e2bcc 
[0x00007f42094e2720+0x00000000000004ac]
J 1001 c1 
java.lang.invoke.MethodHandleNatives.findMethodHandleType(Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType; 
java.base at 16-internal (7 bytes) @ 0x00007f420955997c 
[0x00007f4209559940+0x000000000000003c]
v? ~StubRoutines::call_stub
V? [libjvm.so+0xd0020a]? JavaCalls::call_helper(JavaValue*, methodHandle 
const&, JavaCallArguments*, Thread*)+0x62a
V? [libjvm.so+0xd017e2]? JavaCalls::call_static(JavaValue*, Klass*, 
Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x312
V? [libjvm.so+0x166c2e1] 
SystemDictionary::find_method_handle_type(Symbol*, Klass*, Thread*)+0x1541
V? [libjvm.so+0x166e31f] 
SystemDictionary::find_method_handle_invoker(Klass*, Symbol*, Symbol*, 
Klass*, Handle*, Thread*)+0x5f
V? [libjvm.so+0x112a15b] 
LinkResolver::lookup_polymorphic_method(LinkInfo const&, Handle*, 
Thread*)+0x52b
V? [libjvm.so+0x112a6a7] LinkResolver::resolve_handle_call(CallInfo&, 
LinkInfo const&, Thread*)+0xa7
V? [libjvm.so+0x112a944] LinkResolver::resolve_invokehandle(CallInfo&, 
constantPoolHandle const&, int, Thread*)+0x184
V? [libjvm.so+0x11376c9] LinkResolver::resolve_invoke(CallInfo&, Handle, 
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x69
V? [libjvm.so+0x727eec]? Runtime1::patch_code(JavaThread*, 
Runtime1::StubID)+0x156c
V? [libjvm.so+0x72a847] Runtime1::move_appendix_patching(JavaThread*)+0x37
v? ~RuntimeStub::load_appendix_patching Runtime1 stub
J 5283 c1 java.lang.ProcessHandleImpl$1.run()V java.base at 16-internal 
(136 bytes) @ 0x00007f420946c262 [0x00007f420946b3c0+0x0000000000000ea2]
J 5275 c1 
java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V 
java.base at 16-internal (187 bytes) @ 0x00007f420946d91c 
[0x00007f420946d680+0x000000000000029c]
J 5272 c1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V 
java.base at 16-internal (9 bytes) @ 0x00007f4209916c7c 
[0x00007f4209916be0+0x000000000000009c]
J 3308 c1 java.lang.Thread.run()V java.base at 16-internal (17 bytes) @ 
0x00007f42097c2bf4 [0x00007f42097c2b60+0x0000000000000094]
v? ~StubRoutines::call_stub
V? [libjvm.so+0xd0020a]? JavaCalls::call_helper(JavaValue*, methodHandle 
const&, JavaCallArguments*, Thread*)+0x62a
V? [libjvm.so+0xd00b15]? JavaCalls::call_virtual(JavaValue*, Klass*, 
Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x4b5
V? [libjvm.so+0xd00fc1]? JavaCalls::call_virtual(JavaValue*, Handle, 
Klass*, Symbol*, Symbol*, Thread*)+0xb1
V? [libjvm.so+0xe7ed63]? thread_entry(JavaThread*, Thread*)+0x123
V? [libjvm.so+0x16d3f9c]? JavaThread::thread_main_inner()+0x21c
V? [libjvm.so+0x16d9d20]? Thread::call_run()+0x100
V? [libjvm.so+0x13ddbe6]? thread_native_entry(Thread*)+0x116




On 7/22/20 9:16 PM, David Holmes wrote:
> Hi Roger,
>
> On 23/07/2020 12:51 am, Roger Riggs wrote:
>> Please review a change to the Process reaper thread initialization to 
>> preemptively
>> make sure classes ThreadLocalRandom and ConcurrentHashMap are 
>> initialized.
>
> I don't see ThreadLocalRandom? appearing in any of the stack traces. ??
>
> David
> -----
>
>> ?From the stack overflow failures, it seems that the classes have not 
>> been initialized
>> before they are used during processing the termination of a process.
>> When the initialization is performed on the smaller reaper stack, it 
>> occasionally
>> exceeds the available stack.
>>
>> As an aid to diagnostics, 
>> -XX:AbortVMOnException=java.lang.StackOverflowError
>> is added to TestHumongousNonArrayAllocation that has failed 
>> intermittently.
>> If the problem happens again it will produce an hs_error file with 
>> useful details
>> and will otherwise not change the test behavior.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>
>> Issue:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8249217
>>
>> Thanks, Roger
>>


From david.holmes at oracle.com  Thu Jul 23 01:46:28 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jul 2020 11:46:28 +1000
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <ef5a9850-ad6f-a3fd-cb89-a37d2822c064@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <4f5ca21b-794c-aa0e-0195-c217729cd506@oracle.com>
 <ef5a9850-ad6f-a3fd-cb89-a37d2822c064@oracle.com>
Message-ID: <ed8467ce-afdc-24b9-e4b1-e6da25ae6e9f@oracle.com>

On 23/07/2020 11:27 am, Roger Riggs wrote:
> Hi David,
> 
> It took some digging in the hs_err files and looking at a core dump to 
> determine what class was being initialized.

Doh! I knew that [1]:

"So what are we trying to initialize? Unfortunately that's not 
discernible from the hs_err file, but looking at fullAddCount we would 
have to suspect this:

   if ((h = ThreadLocalRandom.getProbe()) == 0) { "

but forgot.

Sorry for the noise.

I'm still a bit perplexed with why this issue only seems to arise with 
debug builds but ...

David
-----

[1] 
https://bugs.openjdk.java.net/browse/JDK-8217475?focusedCommentId=14350680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14350680

> 
> I attached one to the current bug, there are others on the previous bug.
> 
> The "call_class_initializer" is the hook.
> 
> Roger
> 
> Stack: [0x00007f41eeeb8000,0x00007f41eeedc000], sp=0x00007f41eeed1e80, 
> free space=103k
> Native frames: (J=compiled Java code, A=aot compiled Java code, 
> j=interpreted, Vv=VM code, C=native code)
> V? [libjvm.so+0xa78e24] Exceptions::debug_check_abort_helper(Handle, 
> char const*)+0x184
> V? [libjvm.so+0xa79b01]? Exceptions::_throw(Thread*, char const*, int, 
> Handle, char const*)+0x121
> V? [libjvm.so+0xa7b69e] 
> Exceptions::throw_stack_overflow_exception(Thread*, char const*, int, 
> methodHandle const&)+0xde
> V? [libjvm.so+0xcfff7f]? JavaCalls::call_helper(JavaValue*, methodHandle 
> const&, JavaCallArguments*, Thread*)+0x39f
> V? [libjvm.so+0xcc128f] 
> InstanceKlass::call_class_initializer(Thread*)+0x1bf
> V? [libjvm.so+0xcc2787] InstanceKlass::initialize_impl(Thread*)+0x637
> V? [libjvm.so+0x113093f] LinkResolver::resolve_static_call(CallInfo&, 
> LinkInfo const&, bool, Thread*)+0xcf
> V? [libjvm.so+0x11377e3] LinkResolver::resolve_invoke(CallInfo&, Handle, 
> constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x183
> V? [libjvm.so+0x15474e3] 
> SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&, 
> Bytecodes::Code&, CallInfo&, Thread*)+0x5f3
> V? [libjvm.so+0x15498ae] SharedRuntime::resolve_sub_helper(JavaThread*, 
> bool, bool, Thread*)+0x18e
> V? [libjvm.so+0x1549eae]? SharedRuntime::resolve_helper(JavaThread*, 
> bool, bool, Thread*)+0x4e
> V? [libjvm.so+0x154a1b1] 
> SharedRuntime::resolve_static_call_C(JavaThread*)+0x131
> v? ~RuntimeStub::resolve_static_call
> J 5841 c1 java.util.concurrent.ConcurrentHashMap.fullAddCount(JZ)V 
> java.base at 16-internal (462 bytes) @ 0x00007f4209952e4c 
> [0x00007f4209952de0+0x000000000000006c]
> J 4202 c2 java.util.concurrent.ConcurrentHashMap.addCount(JI)V 
> java.base at 16-internal (280 bytes) @ 0x00007f42109cf734 
> [0x00007f42109cf6e0+0x0000000000000054]
> J 4213 c1 
> java.util.concurrent.ConcurrentHashMap.putVal(Ljava/lang/Object;Ljava/lang/Object;Z)Ljava/lang/Object; 
> java.base at 16-internal (432 bytes) @ 0x00007f4209a5a374 
> [0x00007f4209a59800+0x0000000000000b74]
> J 798 c1 
> java.lang.invoke.MethodType$ConcurrentWeakInternSet.add(Ljava/lang/Object;)Ljava/lang/Object; 
> java.base at 16-internal (66 bytes) @ 0x00007f42094af3b4 
> [0x00007f42094af0a0+0x0000000000000314]
> J 880 c1 
> java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; 
> java.base at 16-internal (108 bytes) @ 0x00007f42094e2bcc 
> [0x00007f42094e2720+0x00000000000004ac]
> J 1001 c1 
> java.lang.invoke.MethodHandleNatives.findMethodHandleType(Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType; 
> java.base at 16-internal (7 bytes) @ 0x00007f420955997c 
> [0x00007f4209559940+0x000000000000003c]
> v? ~StubRoutines::call_stub
> V? [libjvm.so+0xd0020a]? JavaCalls::call_helper(JavaValue*, methodHandle 
> const&, JavaCallArguments*, Thread*)+0x62a
> V? [libjvm.so+0xd017e2]? JavaCalls::call_static(JavaValue*, Klass*, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x312
> V? [libjvm.so+0x166c2e1] 
> SystemDictionary::find_method_handle_type(Symbol*, Klass*, Thread*)+0x1541
> V? [libjvm.so+0x166e31f] 
> SystemDictionary::find_method_handle_invoker(Klass*, Symbol*, Symbol*, 
> Klass*, Handle*, Thread*)+0x5f
> V? [libjvm.so+0x112a15b] 
> LinkResolver::lookup_polymorphic_method(LinkInfo const&, Handle*, 
> Thread*)+0x52b
> V? [libjvm.so+0x112a6a7] LinkResolver::resolve_handle_call(CallInfo&, 
> LinkInfo const&, Thread*)+0xa7
> V? [libjvm.so+0x112a944] LinkResolver::resolve_invokehandle(CallInfo&, 
> constantPoolHandle const&, int, Thread*)+0x184
> V? [libjvm.so+0x11376c9] LinkResolver::resolve_invoke(CallInfo&, Handle, 
> constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x69
> V? [libjvm.so+0x727eec]? Runtime1::patch_code(JavaThread*, 
> Runtime1::StubID)+0x156c
> V? [libjvm.so+0x72a847] Runtime1::move_appendix_patching(JavaThread*)+0x37
> v? ~RuntimeStub::load_appendix_patching Runtime1 stub
> J 5283 c1 java.lang.ProcessHandleImpl$1.run()V java.base at 16-internal 
> (136 bytes) @ 0x00007f420946c262 [0x00007f420946b3c0+0x0000000000000ea2]
> J 5275 c1 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V 
> java.base at 16-internal (187 bytes) @ 0x00007f420946d91c 
> [0x00007f420946d680+0x000000000000029c]
> J 5272 c1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V 
> java.base at 16-internal (9 bytes) @ 0x00007f4209916c7c 
> [0x00007f4209916be0+0x000000000000009c]
> J 3308 c1 java.lang.Thread.run()V java.base at 16-internal (17 bytes) @ 
> 0x00007f42097c2bf4 [0x00007f42097c2b60+0x0000000000000094]
> v? ~StubRoutines::call_stub
> V? [libjvm.so+0xd0020a]? JavaCalls::call_helper(JavaValue*, methodHandle 
> const&, JavaCallArguments*, Thread*)+0x62a
> V? [libjvm.so+0xd00b15]? JavaCalls::call_virtual(JavaValue*, Klass*, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x4b5
> V? [libjvm.so+0xd00fc1]? JavaCalls::call_virtual(JavaValue*, Handle, 
> Klass*, Symbol*, Symbol*, Thread*)+0xb1
> V? [libjvm.so+0xe7ed63]? thread_entry(JavaThread*, Thread*)+0x123
> V? [libjvm.so+0x16d3f9c]? JavaThread::thread_main_inner()+0x21c
> V? [libjvm.so+0x16d9d20]? Thread::call_run()+0x100
> V? [libjvm.so+0x13ddbe6]? thread_native_entry(Thread*)+0x116
> 
> 
> 
> 
> On 7/22/20 9:16 PM, David Holmes wrote:
>> Hi Roger,
>>
>> On 23/07/2020 12:51 am, Roger Riggs wrote:
>>> Please review a change to the Process reaper thread initialization to 
>>> preemptively
>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are 
>>> initialized.
>>
>> I don't see ThreadLocalRandom? appearing in any of the stack traces. ??
>>
>> David
>> -----
>>
>>> ?From the stack overflow failures, it seems that the classes have not 
>>> been initialized
>>> before they are used during processing the termination of a process.
>>> When the initialization is performed on the smaller reaper stack, it 
>>> occasionally
>>> exceeds the available stack.
>>>
>>> As an aid to diagnostics, 
>>> -XX:AbortVMOnException=java.lang.StackOverflowError
>>> is added to TestHumongousNonArrayAllocation that has failed 
>>> intermittently.
>>> If the problem happens again it will produce an hs_error file with 
>>> useful details
>>> and will otherwise not change the test behavior.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>>
>>> Issue:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8249217
>>>
>>> Thanks, Roger
>>>
> 

From Roger.Riggs at oracle.com  Thu Jul 23 04:00:43 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jul 2020 00:00:43 -0400
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <ed8467ce-afdc-24b9-e4b1-e6da25ae6e9f@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <4f5ca21b-794c-aa0e-0195-c217729cd506@oracle.com>
 <ef5a9850-ad6f-a3fd-cb89-a37d2822c064@oracle.com>
 <ed8467ce-afdc-24b9-e4b1-e6da25ae6e9f@oracle.com>
Message-ID: <e01188ff-bb1f-cb0e-0a69-6fa8a2754b7a@oracle.com>

Hi David,

Yep, that's the focal point.
Its both debug and -Xcomp.
There must be something that changes the timing or the synchronization
or the sizes; but that's more than I know about how the VM works.

Running the TestHumongousNonArrayAllocation test repeatedly does show 
the problem
intermittently but it would take a HS engineer to figure it out.

For now, all I have is an avoidence attempt.

Thanks, Roger


On 7/22/20 9:46 PM, David Holmes wrote:
> On 23/07/2020 11:27 am, Roger Riggs wrote:
>> Hi David,
>>
>> It took some digging in the hs_err files and looking at a core dump 
>> to determine what class was being initialized.
>
> Doh! I knew that [1]:
>
> "So what are we trying to initialize? Unfortunately that's not 
> discernible from the hs_err file, but looking at fullAddCount we would 
> have to suspect this:
>
> ? if ((h = ThreadLocalRandom.getProbe()) == 0) { "
>
> but forgot.
>
> Sorry for the noise.
>
> I'm still a bit perplexed with why this issue only seems to arise with 
> debug builds but ...
>
> David
> -----
>
> [1] 
> https://bugs.openjdk.java.net/browse/JDK-8217475?focusedCommentId=14350680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14350680
>
>>
>> I attached one to the current bug, there are others on the previous bug.
>>
>> The "call_class_initializer" is the hook.
>>
>> Roger
>>
>> Stack: [0x00007f41eeeb8000,0x00007f41eeedc000], 
>> sp=0x00007f41eeed1e80, free space=103k
>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>> j=interpreted, Vv=VM code, C=native code)
>> V? [libjvm.so+0xa78e24] Exceptions::debug_check_abort_helper(Handle, 
>> char const*)+0x184
>> V? [libjvm.so+0xa79b01]? Exceptions::_throw(Thread*, char const*, 
>> int, Handle, char const*)+0x121
>> V? [libjvm.so+0xa7b69e] 
>> Exceptions::throw_stack_overflow_exception(Thread*, char const*, int, 
>> methodHandle const&)+0xde
>> V? [libjvm.so+0xcfff7f]? JavaCalls::call_helper(JavaValue*, 
>> methodHandle const&, JavaCallArguments*, Thread*)+0x39f
>> V? [libjvm.so+0xcc128f] 
>> InstanceKlass::call_class_initializer(Thread*)+0x1bf
>> V? [libjvm.so+0xcc2787] InstanceKlass::initialize_impl(Thread*)+0x637
>> V? [libjvm.so+0x113093f] LinkResolver::resolve_static_call(CallInfo&, 
>> LinkInfo const&, bool, Thread*)+0xcf
>> V? [libjvm.so+0x11377e3] LinkResolver::resolve_invoke(CallInfo&, 
>> Handle, constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x183
>> V? [libjvm.so+0x15474e3] 
>> SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&, 
>> Bytecodes::Code&, CallInfo&, Thread*)+0x5f3
>> V? [libjvm.so+0x15498ae] 
>> SharedRuntime::resolve_sub_helper(JavaThread*, bool, bool, 
>> Thread*)+0x18e
>> V? [libjvm.so+0x1549eae] SharedRuntime::resolve_helper(JavaThread*, 
>> bool, bool, Thread*)+0x4e
>> V? [libjvm.so+0x154a1b1] 
>> SharedRuntime::resolve_static_call_C(JavaThread*)+0x131
>> v? ~RuntimeStub::resolve_static_call
>> J 5841 c1 java.util.concurrent.ConcurrentHashMap.fullAddCount(JZ)V 
>> java.base at 16-internal (462 bytes) @ 0x00007f4209952e4c 
>> [0x00007f4209952de0+0x000000000000006c]
>> J 4202 c2 java.util.concurrent.ConcurrentHashMap.addCount(JI)V 
>> java.base at 16-internal (280 bytes) @ 0x00007f42109cf734 
>> [0x00007f42109cf6e0+0x0000000000000054]
>> J 4213 c1 
>> java.util.concurrent.ConcurrentHashMap.putVal(Ljava/lang/Object;Ljava/lang/Object;Z)Ljava/lang/Object; 
>> java.base at 16-internal (432 bytes) @ 0x00007f4209a5a374 
>> [0x00007f4209a59800+0x0000000000000b74]
>> J 798 c1 
>> java.lang.invoke.MethodType$ConcurrentWeakInternSet.add(Ljava/lang/Object;)Ljava/lang/Object; 
>> java.base at 16-internal (66 bytes) @ 0x00007f42094af3b4 
>> [0x00007f42094af0a0+0x0000000000000314]
>> J 880 c1 
>> java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; 
>> java.base at 16-internal (108 bytes) @ 0x00007f42094e2bcc 
>> [0x00007f42094e2720+0x00000000000004ac]
>> J 1001 c1 
>> java.lang.invoke.MethodHandleNatives.findMethodHandleType(Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType; 
>> java.base at 16-internal (7 bytes) @ 0x00007f420955997c 
>> [0x00007f4209559940+0x000000000000003c]
>> v? ~StubRoutines::call_stub
>> V? [libjvm.so+0xd0020a]? JavaCalls::call_helper(JavaValue*, 
>> methodHandle const&, JavaCallArguments*, Thread*)+0x62a
>> V? [libjvm.so+0xd017e2]? JavaCalls::call_static(JavaValue*, Klass*, 
>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x312
>> V? [libjvm.so+0x166c2e1] 
>> SystemDictionary::find_method_handle_type(Symbol*, Klass*, 
>> Thread*)+0x1541
>> V? [libjvm.so+0x166e31f] 
>> SystemDictionary::find_method_handle_invoker(Klass*, Symbol*, 
>> Symbol*, Klass*, Handle*, Thread*)+0x5f
>> V? [libjvm.so+0x112a15b] 
>> LinkResolver::lookup_polymorphic_method(LinkInfo const&, Handle*, 
>> Thread*)+0x52b
>> V? [libjvm.so+0x112a6a7] LinkResolver::resolve_handle_call(CallInfo&, 
>> LinkInfo const&, Thread*)+0xa7
>> V? [libjvm.so+0x112a944] 
>> LinkResolver::resolve_invokehandle(CallInfo&, constantPoolHandle 
>> const&, int, Thread*)+0x184
>> V? [libjvm.so+0x11376c9] LinkResolver::resolve_invoke(CallInfo&, 
>> Handle, constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x69
>> V? [libjvm.so+0x727eec]? Runtime1::patch_code(JavaThread*, 
>> Runtime1::StubID)+0x156c
>> V? [libjvm.so+0x72a847] 
>> Runtime1::move_appendix_patching(JavaThread*)+0x37
>> v? ~RuntimeStub::load_appendix_patching Runtime1 stub
>> J 5283 c1 java.lang.ProcessHandleImpl$1.run()V java.base at 16-internal 
>> (136 bytes) @ 0x00007f420946c262 [0x00007f420946b3c0+0x0000000000000ea2]
>> J 5275 c1 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V 
>> java.base at 16-internal (187 bytes) @ 0x00007f420946d91c 
>> [0x00007f420946d680+0x000000000000029c]
>> J 5272 c1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V 
>> java.base at 16-internal (9 bytes) @ 0x00007f4209916c7c 
>> [0x00007f4209916be0+0x000000000000009c]
>> J 3308 c1 java.lang.Thread.run()V java.base at 16-internal (17 bytes) @ 
>> 0x00007f42097c2bf4 [0x00007f42097c2b60+0x0000000000000094]
>> v? ~StubRoutines::call_stub
>> V? [libjvm.so+0xd0020a]? JavaCalls::call_helper(JavaValue*, 
>> methodHandle const&, JavaCallArguments*, Thread*)+0x62a
>> V? [libjvm.so+0xd00b15]? JavaCalls::call_virtual(JavaValue*, Klass*, 
>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x4b5
>> V? [libjvm.so+0xd00fc1]? JavaCalls::call_virtual(JavaValue*, Handle, 
>> Klass*, Symbol*, Symbol*, Thread*)+0xb1
>> V? [libjvm.so+0xe7ed63]? thread_entry(JavaThread*, Thread*)+0x123
>> V? [libjvm.so+0x16d3f9c]? JavaThread::thread_main_inner()+0x21c
>> V? [libjvm.so+0x16d9d20]? Thread::call_run()+0x100
>> V? [libjvm.so+0x13ddbe6]? thread_native_entry(Thread*)+0x116
>>
>>
>>
>>
>> On 7/22/20 9:16 PM, David Holmes wrote:
>>> Hi Roger,
>>>
>>> On 23/07/2020 12:51 am, Roger Riggs wrote:
>>>> Please review a change to the Process reaper thread initialization 
>>>> to preemptively
>>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are 
>>>> initialized.
>>>
>>> I don't see ThreadLocalRandom? appearing in any of the stack traces. ??
>>>
>>> David
>>> -----
>>>
>>>> ?From the stack overflow failures, it seems that the classes have 
>>>> not been initialized
>>>> before they are used during processing the termination of a process.
>>>> When the initialization is performed on the smaller reaper stack, 
>>>> it occasionally
>>>> exceeds the available stack.
>>>>
>>>> As an aid to diagnostics, 
>>>> -XX:AbortVMOnException=java.lang.StackOverflowError
>>>> is added to TestHumongousNonArrayAllocation that has failed 
>>>> intermittently.
>>>> If the problem happens again it will produce an hs_error file with 
>>>> useful details
>>>> and will otherwise not change the test behavior.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>>>
>>>> Issue:
>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8249217
>>>>
>>>> Thanks, Roger
>>>>
>>


From mandy.chung at oracle.com  Thu Jul 23 04:22:17 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Jul 2020 21:22:17 -0700
Subject: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h
 in native tests
In-Reply-To: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>
References: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>
Message-ID: <6ed5dca4-2258-a3bc-4e71-8541c43f885f@oracle.com>

Hi David,

Looks good.

Mandy

On 7/22/20 4:00 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
> webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
>
> A number of native tests in hotspot and jdk include the jni_util.h 
> header file which is part of the sources for libjava and not part of 
> the testing framework, nor an exported interface for the JDK. This 
> seems to have occurred through copy-and-paste when creating the tests 
> as the include is not needed.
>
> test/hotspot/jtreg/runtime/jni/FindClass/libbootLoaderTest.c
> test/hotspot/jtreg/runtime/jni/registerNativesWarning/libregisterNativesWarning.c 
>
> test/hotspot/jtreg/runtime/jni/terminatedThread/libterminatedThread.c
> test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c
> test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c
> test/jdk/jdk/internal/loader/NativeLibraries/libnativeLibrariesTest.c
>
> There is one test that includes jni_util.h and uses the utility 
> function declared there:
> ./jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c
> so that is left as-is.
>
> Thanks,
> David
> -----


From mandy.chung at oracle.com  Thu Jul 23 04:24:07 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 22 Jul 2020 21:24:07 -0700
Subject: RFR: JDK-8247592: refactor
 test/jdk/tools/launcher/Test7029048.java
In-Reply-To: <69932e63-8a4f-67cf-bd52-98fd899da420@bell-sw.com>
References: <0bd8fc50-81d4-c40c-ede5-907bd7fc6144@bell-sw.com>
 <8f811a92-a646-4732-8edd-4f8baae43180@bell-sw.com>
 <7f41bb5f-0b80-5cdf-39aa-7d85bebcb1ed@oracle.com>
 <69932e63-8a4f-67cf-bd52-98fd899da420@bell-sw.com>
Message-ID: <7ffbad8f-65bb-5baf-9709-614f3b73dd0b@oracle.com>

Hi Aleksei,

Looks good.? I can sponsor this.

Mandy

On 7/22/20 1:32 AM, Aleksei Voitylov wrote:
> Hi Mandy,
>
> here is the webrev which addresses your comments:
>
> http://cr.openjdk.java.net/~avoitylov/webrev.8247592.02/
>
> Thanks,
>
> -Aleksei
>
> On 22/07/2020 02:26, Mandy Chung wrote:
>> Hi Aleksei,
>>
>>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>> This refactoring seems okay.? I would suggest to change the run method
>> to return an int or boolean to indicate the test passed or failed.
>> The caller of the run method (i.e. runTest will add to the failedTests
>> list if the return value indicates test failure.?? No need to pass the
>> failedTest list to the run method as an argument.
>>
>> Typo in line 90: s/bug got/but got/
>>
>> Otherwise, looks okay.
>>
>> Mandy
>>
>> On 7/21/20 10:37 AM, Aleksei Voitylov wrote:
>>> Hi,
>>>
>>> gently reminiding about this simple test refactoring. The patch still
>>> applies cleanly.
>>>
>>> -Aleksei
>>>
>>> On 24/06/2020 11:44, Aleksei Voitylov wrote:
>>>> Hi,
>>>>
>>>> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
>>>> logic easier to follow and remove some magic numbers from the test:
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247592
>>>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>>>>
>>>> Testing: the test passes on Linux x86, Linux x86_64, Linux ARM, Linux
>>>> AArch64, Linux PPC, Windows x86, Windows x86_64, Mac, AIX. Special
>>>> thanks to SAP team for helping test on AIX.
>>>>
>>>> Thanks,
>>>> -Aleksei
>>>>


From david.holmes at oracle.com  Thu Jul 23 04:42:55 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Jul 2020 14:42:55 +1000
Subject: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h
 in native tests
In-Reply-To: <6ed5dca4-2258-a3bc-4e71-8541c43f885f@oracle.com>
References: <8eb62661-dc95-bba1-ac2f-092d637f57c5@oracle.com>
 <6ed5dca4-2258-a3bc-4e71-8541c43f885f@oracle.com>
Message-ID: <0048a4d0-9a94-3e94-734e-fc77945504da@oracle.com>

Thanks Mandy!

David

On 23/07/2020 2:22 pm, Mandy Chung wrote:
> Hi David,
> 
> Looks good.
> 
> Mandy
> 
> On 7/22/20 4:00 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
>> webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
>>
>> A number of native tests in hotspot and jdk include the jni_util.h 
>> header file which is part of the sources for libjava and not part of 
>> the testing framework, nor an exported interface for the JDK. This 
>> seems to have occurred through copy-and-paste when creating the tests 
>> as the include is not needed.
>>
>> test/hotspot/jtreg/runtime/jni/FindClass/libbootLoaderTest.c
>> test/hotspot/jtreg/runtime/jni/registerNativesWarning/libregisterNativesWarning.c 
>>
>> test/hotspot/jtreg/runtime/jni/terminatedThread/libterminatedThread.c
>> test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c
>> test/jdk/java/lang/ProcessBuilder/checkHandles/libCheckHandles.c
>> test/jdk/jdk/internal/loader/NativeLibraries/libnativeLibrariesTest.c
>>
>> There is one test that includes jni_util.h and uses the utility 
>> function declared there:
>> ./jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c
>> so that is left as-is.
>>
>> Thanks,
>> David
>> -----
> 

From thomas.stuefe at gmail.com  Thu Jul 23 04:24:26 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 23 Jul 2020 06:24:26 +0200
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <e01188ff-bb1f-cb0e-0a69-6fa8a2754b7a@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <4f5ca21b-794c-aa0e-0195-c217729cd506@oracle.com>
 <ef5a9850-ad6f-a3fd-cb89-a37d2822c064@oracle.com>
 <ed8467ce-afdc-24b9-e4b1-e6da25ae6e9f@oracle.com>
 <e01188ff-bb1f-cb0e-0a69-6fa8a2754b7a@oracle.com>
Message-ID: <CAA-vtUz+0Ai26P8+E4bJBjia3Bk6OeAkzDAuKEW=cFPW1Ac3KQ@mail.gmail.com>

Hi,

On Thu, Jul 23, 2020 at 6:01 AM Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi David,
>
> Yep, that's the focal point.
> Its both debug and -Xcomp.
> There must be something that changes the timing or the synchronization
> or the sizes; but that's more than I know about how the VM works.
>

Just a really wild guess but:
- debug code may have more C++ frames on stack since we have no inlining
- compiled code may do scalar replacement so we may use more stack slots.

I have similar thoughts about IBMs upcoming c2 scalar replacement
prototype; while the work is cool, it may shake a few tests loose which
rely on exact thread stack sizes.

Cheers, Thomas


>
> Running the TestHumongousNonArrayAllocation test repeatedly does show
> the problem
> intermittently but it would take a HS engineer to figure it out.
>
> For now, all I have is an avoidence attempt.
>
> Thanks, Roger
>
>
> On 7/22/20 9:46 PM, David Holmes wrote:
> > On 23/07/2020 11:27 am, Roger Riggs wrote:
> >> Hi David,
> >>
> >> It took some digging in the hs_err files and looking at a core dump
> >> to determine what class was being initialized.
> >
> > Doh! I knew that [1]:
> >
> > "So what are we trying to initialize? Unfortunately that's not
> > discernible from the hs_err file, but looking at fullAddCount we would
> > have to suspect this:
> >
> >   if ((h = ThreadLocalRandom.getProbe()) == 0) { "
> >
> > but forgot.
> >
> > Sorry for the noise.
> >
> > I'm still a bit perplexed with why this issue only seems to arise with
> > debug builds but ...
> >
> > David
> > -----
> >
> > [1]
> >
> https://bugs.openjdk.java.net/browse/JDK-8217475?focusedCommentId=14350680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14350680
> >
> >>
> >> I attached one to the current bug, there are others on the previous bug.
> >>
> >> The "call_class_initializer" is the hook.
> >>
> >> Roger
> >>
> >> Stack: [0x00007f41eeeb8000,0x00007f41eeedc000],
> >> sp=0x00007f41eeed1e80, free space=103k
> >> Native frames: (J=compiled Java code, A=aot compiled Java code,
> >> j=interpreted, Vv=VM code, C=native code)
> >> V  [libjvm.so+0xa78e24] Exceptions::debug_check_abort_helper(Handle,
> >> char const*)+0x184
> >> V  [libjvm.so+0xa79b01]  Exceptions::_throw(Thread*, char const*,
> >> int, Handle, char const*)+0x121
> >> V  [libjvm.so+0xa7b69e]
> >> Exceptions::throw_stack_overflow_exception(Thread*, char const*, int,
> >> methodHandle const&)+0xde
> >> V  [libjvm.so+0xcfff7f]  JavaCalls::call_helper(JavaValue*,
> >> methodHandle const&, JavaCallArguments*, Thread*)+0x39f
> >> V  [libjvm.so+0xcc128f]
> >> InstanceKlass::call_class_initializer(Thread*)+0x1bf
> >> V  [libjvm.so+0xcc2787] InstanceKlass::initialize_impl(Thread*)+0x637
> >> V  [libjvm.so+0x113093f] LinkResolver::resolve_static_call(CallInfo&,
> >> LinkInfo const&, bool, Thread*)+0xcf
> >> V  [libjvm.so+0x11377e3] LinkResolver::resolve_invoke(CallInfo&,
> >> Handle, constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x183
> >> V  [libjvm.so+0x15474e3]
> >> SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&,
> >> Bytecodes::Code&, CallInfo&, Thread*)+0x5f3
> >> V  [libjvm.so+0x15498ae]
> >> SharedRuntime::resolve_sub_helper(JavaThread*, bool, bool,
> >> Thread*)+0x18e
> >> V  [libjvm.so+0x1549eae] SharedRuntime::resolve_helper(JavaThread*,
> >> bool, bool, Thread*)+0x4e
> >> V  [libjvm.so+0x154a1b1]
> >> SharedRuntime::resolve_static_call_C(JavaThread*)+0x131
> >> v  ~RuntimeStub::resolve_static_call
> >> J 5841 c1 java.util.concurrent.ConcurrentHashMap.fullAddCount(JZ)V
> >> java.base at 16-internal (462 bytes) @ 0x00007f4209952e4c
> >> [0x00007f4209952de0+0x000000000000006c]
> >> J 4202 c2 java.util.concurrent.ConcurrentHashMap.addCount(JI)V
> >> java.base at 16-internal (280 bytes) @ 0x00007f42109cf734
> >> [0x00007f42109cf6e0+0x0000000000000054]
> >> J 4213 c1
> >>
> java.util.concurrent.ConcurrentHashMap.putVal(Ljava/lang/Object;Ljava/lang/Object;Z)Ljava/lang/Object;
>
> >> java.base at 16-internal (432 bytes) @ 0x00007f4209a5a374
> >> [0x00007f4209a59800+0x0000000000000b74]
> >> J 798 c1
> >>
> java.lang.invoke.MethodType$ConcurrentWeakInternSet.add(Ljava/lang/Object;)Ljava/lang/Object;
>
> >> java.base at 16-internal (66 bytes) @ 0x00007f42094af3b4
> >> [0x00007f42094af0a0+0x0000000000000314]
> >> J 880 c1
> >>
> java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType;
>
> >> java.base at 16-internal (108 bytes) @ 0x00007f42094e2bcc
> >> [0x00007f42094e2720+0x00000000000004ac]
> >> J 1001 c1
> >>
> java.lang.invoke.MethodHandleNatives.findMethodHandleType(Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType;
>
> >> java.base at 16-internal (7 bytes) @ 0x00007f420955997c
> >> [0x00007f4209559940+0x000000000000003c]
> >> v  ~StubRoutines::call_stub
> >> V  [libjvm.so+0xd0020a]  JavaCalls::call_helper(JavaValue*,
> >> methodHandle const&, JavaCallArguments*, Thread*)+0x62a
> >> V  [libjvm.so+0xd017e2]  JavaCalls::call_static(JavaValue*, Klass*,
> >> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x312
> >> V  [libjvm.so+0x166c2e1]
> >> SystemDictionary::find_method_handle_type(Symbol*, Klass*,
> >> Thread*)+0x1541
> >> V  [libjvm.so+0x166e31f]
> >> SystemDictionary::find_method_handle_invoker(Klass*, Symbol*,
> >> Symbol*, Klass*, Handle*, Thread*)+0x5f
> >> V  [libjvm.so+0x112a15b]
> >> LinkResolver::lookup_polymorphic_method(LinkInfo const&, Handle*,
> >> Thread*)+0x52b
> >> V  [libjvm.so+0x112a6a7] LinkResolver::resolve_handle_call(CallInfo&,
> >> LinkInfo const&, Thread*)+0xa7
> >> V  [libjvm.so+0x112a944]
> >> LinkResolver::resolve_invokehandle(CallInfo&, constantPoolHandle
> >> const&, int, Thread*)+0x184
> >> V  [libjvm.so+0x11376c9] LinkResolver::resolve_invoke(CallInfo&,
> >> Handle, constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x69
> >> V  [libjvm.so+0x727eec]  Runtime1::patch_code(JavaThread*,
> >> Runtime1::StubID)+0x156c
> >> V  [libjvm.so+0x72a847]
> >> Runtime1::move_appendix_patching(JavaThread*)+0x37
> >> v  ~RuntimeStub::load_appendix_patching Runtime1 stub
> >> J 5283 c1 java.lang.ProcessHandleImpl$1.run()V java.base at 16-internal
> >> (136 bytes) @ 0x00007f420946c262 [0x00007f420946b3c0+0x0000000000000ea2]
> >> J 5275 c1
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>
> >> java.base at 16-internal (187 bytes) @ 0x00007f420946d91c
> >> [0x00007f420946d680+0x000000000000029c]
> >> J 5272 c1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V
> >> java.base at 16-internal (9 bytes) @ 0x00007f4209916c7c
> >> [0x00007f4209916be0+0x000000000000009c]
> >> J 3308 c1 java.lang.Thread.run()V java.base at 16-internal (17 bytes) @
> >> 0x00007f42097c2bf4 [0x00007f42097c2b60+0x0000000000000094]
> >> v  ~StubRoutines::call_stub
> >> V  [libjvm.so+0xd0020a]  JavaCalls::call_helper(JavaValue*,
> >> methodHandle const&, JavaCallArguments*, Thread*)+0x62a
> >> V  [libjvm.so+0xd00b15]  JavaCalls::call_virtual(JavaValue*, Klass*,
> >> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x4b5
> >> V  [libjvm.so+0xd00fc1]  JavaCalls::call_virtual(JavaValue*, Handle,
> >> Klass*, Symbol*, Symbol*, Thread*)+0xb1
> >> V  [libjvm.so+0xe7ed63]  thread_entry(JavaThread*, Thread*)+0x123
> >> V  [libjvm.so+0x16d3f9c]  JavaThread::thread_main_inner()+0x21c
> >> V  [libjvm.so+0x16d9d20]  Thread::call_run()+0x100
> >> V  [libjvm.so+0x13ddbe6]  thread_native_entry(Thread*)+0x116
> >>
> >>
> >>
> >>
> >> On 7/22/20 9:16 PM, David Holmes wrote:
> >>> Hi Roger,
> >>>
> >>> On 23/07/2020 12:51 am, Roger Riggs wrote:
> >>>> Please review a change to the Process reaper thread initialization
> >>>> to preemptively
> >>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
> >>>> initialized.
> >>>
> >>> I don't see ThreadLocalRandom  appearing in any of the stack traces. ??
> >>>
> >>> David
> >>> -----
> >>>
> >>>>  From the stack overflow failures, it seems that the classes have
> >>>> not been initialized
> >>>> before they are used during processing the termination of a process.
> >>>> When the initialization is performed on the smaller reaper stack,
> >>>> it occasionally
> >>>> exceeds the available stack.
> >>>>
> >>>> As an aid to diagnostics,
> >>>> -XX:AbortVMOnException=java.lang.StackOverflowError
> >>>> is added to TestHumongousNonArrayAllocation that has failed
> >>>> intermittently.
> >>>> If the problem happens again it will produce an hs_error file with
> >>>> useful details
> >>>> and will otherwise not change the test behavior.
> >>>>
> >>>> Webrev:
> >>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
> >>>>
> >>>> Issue:
> >>>>    https://bugs.openjdk.java.net/browse/JDK-8249217
> >>>>
> >>>> Thanks, Roger
> >>>>
> >>
>
>

From aleksei.voitylov at bell-sw.com  Thu Jul 23 08:43:56 2020
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Thu, 23 Jul 2020 11:43:56 +0300
Subject: RFR: JDK-8247592: refactor
 test/jdk/tools/launcher/Test7029048.java
In-Reply-To: <7ffbad8f-65bb-5baf-9709-614f3b73dd0b@oracle.com>
References: <0bd8fc50-81d4-c40c-ede5-907bd7fc6144@bell-sw.com>
 <8f811a92-a646-4732-8edd-4f8baae43180@bell-sw.com>
 <7f41bb5f-0b80-5cdf-39aa-7d85bebcb1ed@oracle.com>
 <69932e63-8a4f-67cf-bd52-98fd899da420@bell-sw.com>
 <7ffbad8f-65bb-5baf-9709-614f3b73dd0b@oracle.com>
Message-ID: <9441bddf-08d8-da99-ea89-b21c5a23b853@bell-sw.com>

Thanks Mandy, that would be much appreciated!

On 23/07/2020 07:24, Mandy Chung wrote:
> Hi Aleksei,
>
> Looks good.? I can sponsor this.
>
> Mandy
>
> On 7/22/20 1:32 AM, Aleksei Voitylov wrote:
>> Hi Mandy,
>>
>> here is the webrev which addresses your comments:
>>
>> http://cr.openjdk.java.net/~avoitylov/webrev.8247592.02/
>>
>> Thanks,
>>
>> -Aleksei
>>
>> On 22/07/2020 02:26, Mandy Chung wrote:
>>> Hi Aleksei,
>>>
>>>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>>> This refactoring seems okay.? I would suggest to change the run method
>>> to return an int or boolean to indicate the test passed or failed.??
>>> The caller of the run method (i.e. runTest will add to the failedTests
>>> list if the return value indicates test failure.?? No need to pass the
>>> failedTest list to the run method as an argument.
>>>
>>> Typo in line 90: s/bug got/but got/
>>>
>>> Otherwise, looks okay.
>>>
>>> Mandy
>>>
>>> On 7/21/20 10:37 AM, Aleksei Voitylov wrote:
>>>> Hi,
>>>>
>>>> gently reminiding about this simple test refactoring. The patch still
>>>> applies cleanly.
>>>>
>>>> -Aleksei
>>>>
>>>> On 24/06/2020 11:44, Aleksei Voitylov wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
>>>>> logic easier to follow and remove some magic numbers from the test:
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8247592
>>>>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>>>>>
>>>>> Testing: the test passes on Linux x86, Linux x86_64, Linux ARM, Linux
>>>>> AArch64, Linux PPC, Windows x86, Windows x86_64, Mac, AIX. Special
>>>>> thanks to SAP team for helping test on AIX.
>>>>>
>>>>> Thanks,
>>>>> -Aleksei
>>>>>
>

From Roger.Riggs at oracle.com  Thu Jul 23 14:11:09 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jul 2020 10:11:09 -0400
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <CA+kOe08ZykW3HB64h78DoUmo9B_LsL147=XnhMo05fo725XJaA@mail.gmail.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
 <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>
 <507f8eaf-4f6f-1b07-4ab2-049032f4e729@oracle.com>
 <CA+kOe08ZykW3HB64h78DoUmo9B_LsL147=XnhMo05fo725XJaA@mail.gmail.com>
Message-ID: <d7ee8055-b964-714f-602d-b04760a3445b@oracle.com>

Webrev updated with Martin's suggestion:

http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/

Thanks, Roger


On 7/22/20 8:35 PM, Martin Buchholz wrote:
> Roger: You're absolutely right!  I should have looked.
>
> On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi Martin,
>>
>> That's a good idea, but unless I miss your point, there is no Reaper class,
>> only a lambda that is used as to create the Executor for the reaper
>> thread pool.
>>
>> Do you mean to put it before or after lines 91-93?  [1]
>>
>> Thanks, Roger
>>
>> [1]
>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/src/java.base/share/classes/java/lang/ProcessHandleImpl.java.sdiff.html
>>
>>
>> On 7/22/20 8:06 PM, Martin Buchholz wrote:
>>> Looks good.
>>>
>>> I might move the static class preloading into a static method of the
>>> reaper thread class, to make it clearly the responsibility of the
>>> reaper thread class to enumerate and pre-load its dependencies.
>>>
>>> On Wed, Jul 22, 2020 at 7:59 AM Peter Levart <peter.levart at gmail.com> wrote:
>>>> Hi Roger,
>>>>
>>>>
>>>> I don't think resolving the ConcurrentHashMap.class ensures
>>>> initialization of the class. Just loading. But I think CHM is already
>>>> initialized at that time as it is used in ClassLoader to maintain class
>>>> loading locks (per class name).
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>> On 7/22/20 4:51 PM, Roger Riggs wrote:
>>>>> Please review a change to the Process reaper thread initialization to
>>>>> preemptively
>>>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
>>>>> initialized.
>>>>>   From the stack overflow failures, it seems that the classes have not
>>>>> been initialized
>>>>> before they are used during processing the termination of a process.
>>>>> When the initialization is performed on the smaller reaper stack, it
>>>>> occasionally
>>>>> exceeds the available stack.
>>>>>
>>>>> As an aid to diagnostics,
>>>>> -XX:AbortVMOnException=java.lang.StackOverflowError
>>>>> is added to TestHumongousNonArrayAllocation that has failed
>>>>> intermittently.
>>>>> If the problem happens again it will produce an hs_error file with
>>>>> useful details
>>>>> and will otherwise not change the test behavior.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>>>>
>>>>> Issue:
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8249217
>>>>>
>>>>> Thanks, Roger
>>>>>


From raffaello.giulietti at gmail.com  Thu Jul 23 14:44:53 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 23 Jul 2020 16:44:53 +0200
Subject: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected
 null bytes at the end
In-Reply-To: <85BFF8D3-ACEE-49FC-AC37-64FB2CBB05CE@ORACLE.COM>
References: <faa32a60-c60d-82c9-9bed-aff684a73eee@gmail.com>
 <F9D4ACBD-1036-4133-9A7C-A70113A783D7@oracle.com>
 <a2a7a714-3c6a-680e-e001-8981e25e8892@gmail.com>
 <3ec10c63-d628-a6f2-1751-bcc62215967a@gmail.com>
 <1fdd25d6-6ade-acc4-4311-5b9618349d88@gmail.com>
 <959a75ca-2e5b-ce1e-0cc9-54a36b506cc2@gmail.com>
 <545cc626-0a81-e1a8-3983-3feed7717470@oracle.com>
 <c0b28d75-5bbc-6859-c139-05eb9c4d5278@gmail.com>
 <09ad7e8e-89ff-39b4-1551-1344a455be38@oracle.com>
 <f64f1b6f-1312-a1f6-e467-c25ac12ffc16@gmail.com>
 <45b11e40-baa0-5f95-0e1d-01a89925f7c2@gmail.com>
 <c66794e1-9f6c-f520-9164-a3bbeb636271@oracle.com>
 <9d351d78-88c1-9e6d-28a0-9aa6c552c251@gmail.com>
 <4202609E-F2B7-4C81-B325-B470BD79EA67@oracle.com>
 <07bf53e1-9eee-8391-51aa-da814b7a37ee@oracle.com>
 <85BFF8D3-ACEE-49FC-AC37-64FB2CBB05CE@ORACLE.COM>
Message-ID: <115e15cc-59d6-49fc-ae2f-0f8b72d17a29@gmail.com>

Thanks for pushing changeset 865b5ca81009.
Raffaello



On 2020-07-21 19:18, Lance Andersen wrote:
> Hi Roger,
> 
> I will plan to push tomorrow morning pending any last minute reviews
> 
> Best
> Lance
> 
>> On Jul 21, 2020, at 9:57 AM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>> Hi Rafaello, Lance,
>>
>> That looks good to me.
>>
>> Thanks, Roger
>>
>> On 7/19/20 2:31 PM, Lance Andersen wrote:
>>> Hi Raffaello,
>>>
>>> I think the changes look reasonable.
>>>
>>> I have created a webrev, 
>>> http://cr.openjdk.java.net/~lancea/8222187/webrev.00/, for others to 
>>> review as it is a bit easier than the patch.
>>>
>>> I have also run the JCK tests in this area as well as mach5 tiers1-3 
>>> (which I believe Roger has also)
>>>
>>> Best
>>> Lance
>>>
>>>> On Jul 15, 2020, at 5:44 PM, Raffaello Giulietti 
>>>> <raffaello.giulietti at gmail.com 
>>>> <mailto:raffaello.giulietti at gmail.com>> wrote:
>>>>
>>>> Hi Roger,
>>>>
>>>> On 2020-07-15 22:21, Roger Riggs wrote:
>>>>> Hi Raffaello,
>>>>> Base64.java:
>>>>> 2: Please update 2nd copyright year to 2020
>>>>
>>>> I was unsure what to do here, thanks for guidance.
>>>> I also removed the seemingly useless import at former L33.
>>>>
>>>>
>>>>
>>>>> leftovers():
>>>>> 996: "&" the shortcutting && is more typical in a condition.
>>>>> 997: the -= is buried in an expression and a reader might miss it.
>>>>
>>>> Corrected, as well as the analogous -= usage for wpos now at L1106-7
>>>>
>>>>
>>>>> 1053:? "can be reallocated to other vars":? not a useful comment, 
>>>>> reflecting on only one possible implementation that is out of the 
>>>>> control of the developer.
>>>>> I'd almost rather see 'len' than 'limit - off'; it might be 
>>>>> informative to the reader if 'limit' was declared final. (1056:)
>>>>
>>>> Done, as well as declaring i and v final in the loop.
>>>>
>>>>
>>>>
>>>>> TestBase54.java:
>>>>> 2: Update 2nd copyright year to 2020
>>>>> 27:? Please add the bug number to the @bug line.
>>>>> Style-wise, I would remove the blank lines at the beginning of 
>>>>> blocks. (1095, 1115)
>>>>
>>>> Done.
>>>>
>>>>
>>>>> Thanks, Roger
>>>>> On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> here's the latest version of the patch.
>>>>>>
>>>>>> I did:
>>>>>> * Withdraw the simplification in encodedOutLength(), as it is 
>>>>>> indeed out of scope for this bug fix.
>>>>>> * Restore field names in DecInputStream except for nextin (now 
>>>>>> wpos) and nextout (now rpos) because they have slightly different 
>>>>>> semantics. That's just for clarity. I would have nothing against 
>>>>>> reusing the old names for the proposed purpose.
>>>>>> * Switch back to the original no-arg read() implementation.
>>>>>> * Adjust comment continuation lines.
>>>>>> * Preserve the proposed logic of read(byte[], int, int) and the 
>>>>>> supporting methods.
>>>>>>
>>>>>> Others needed changes are:
>>>>>> * Correct the copyright years: that's something better left to Oracle.
>>>>>> * Remove the apparently useless import at L33. I could build and 
>>>>>> run without it.
>>>>>>
>>>>>>
>>>>>> Greetings
>>>>>> Raffaello
>>>>>>
>>>>
>>>>
>>>> ----
>>>>
>>>> # HG changeset patch
>>>> # User lello
>>>> # Date 1594848775 -7200
>>>> # ?????Wed Jul 15 23:32:55 2020 +0200
>>>> # Node ID f7407f35e83ab508f0e6deab4f776bb1a1c85e68
>>>> # Parent ?a5649ebf94193770ca763391dd63807059d333b4
>>>> 8222187: java.util.Base64.Decoder stream adds unexpected null bytes 
>>>> at the end
>>>> Reviewed-by: TBD
>>>> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com 
>>>> <mailto:raffaello.giulietti at gmail.com>>
>>>>
>>>> diff --git a/src/java.base/share/classes/java/util/Base64.java 
>>>> b/src/java.base/share/classes/java/util/Base64.java
>>>> --- a/src/java.base/share/classes/java/util/Base64.java
>>>> +++ b/src/java.base/share/classes/java/util/Base64.java
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 2012, 2020, 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
>>>> @@ -30,7 +30,6 @@
>>>> import java.io.IOException;
>>>> import java.io.OutputStream;
>>>> import java.nio.ByteBuffer;
>>>> -import java.nio.charset.StandardCharsets;
>>>>
>>>> import sun.nio.cs.ISO_8859_1;
>>>>
>>>> @@ -961,12 +960,15 @@
>>>>
>>>> ????????private final InputStream is;
>>>> ????????private final boolean isMIME;
>>>> - ???????private final int[] base64; ?????// base64 -> byte mapping
>>>> - ???????private int bits = 0; ???????????// 24-bit buffer for decoding
>>>> - ???????private int nextin = 18; ????????// next available "off" in 
>>>> "bits" for input;
>>>> - ????????????????????????????????????????// -> 18, 12, 6, 0
>>>> - ???????private int nextout = -8; ???????// next available "off" in 
>>>> "bits" for output;
>>>> - ????????????????????????????????????????// -> 8, 0, -8 (no byte 
>>>> for output)
>>>> + ???????private final int[] base64; ????// base64 -> byte mapping
>>>> + ???????private int bits = 0; ??????????// 24-bit buffer for decoding
>>>> +
>>>> + ???????/* writing bit pos inside bits; one of 24 (left, msb), 18, 
>>>> 12, 6, 0 */
>>>> + ???????private int wpos = 0;
>>>> +
>>>> + ???????/* reading bit pos inside bits: one of 24 (left, msb), 16, 
>>>> 8, 0 */
>>>> + ???????private int rpos = 0;
>>>> +
>>>> ????????private boolean eof = false;
>>>> ????????private boolean closed = false;
>>>>
>>>> @@ -983,107 +985,153 @@
>>>> ????????????return read(sbBuf, 0, 1) == -1 ? -1 : sbBuf[0] & 0xff;
>>>> ????????}
>>>>
>>>> - ???????private int eof(byte[] b, int off, int len, int oldOff)
>>>> - ???????????throws IOException
>>>> - ???????{
>>>> + ???????private int leftovers(byte[] b, int off, int pos, int limit) {
>>>> ????????????eof = true;
>>>> - ???????????if (nextin != 18) {
>>>> - ???????????????if (nextin == 12)
>>>> - ???????????????????throw new IOException("Base64 stream has one 
>>>> un-decoded dangling byte.");
>>>> - ???????????????// treat ending xx/xxx without padding character legal.
>>>> - ???????????????// same logic as v == '=' below
>>>> - ???????????????b[off++] = (byte)(bits >> (16));
>>>> - ???????????????if (nextin == 0) { ??????????// only one padding byte
>>>> - ???????????????????if (len == 1) { ?????????// no enough output space
>>>> - ???????????????????????bits >>= 8; ?????????// shift to lowest byte
>>>> - ???????????????????????nextout = 0;
>>>> - ???????????????????} else {
>>>> - ???????????????????????b[off++] = (byte) (bits >> ?8);
>>>> - ???????????????????}
>>>> - ???????????????}
>>>> +
>>>> + ???????????/*
>>>> + ????????????* We use a loop here, as this method is executed only 
>>>> a few times.
>>>> + ????????????* Unrolling the loop would probably not contribute 
>>>> much here.
>>>> + ????????????*/
>>>> + ???????????while (rpos - 8 >= wpos && pos != limit) {
>>>> + ???????????????rpos -= 8;
>>>> + ???????????????b[pos++] = (byte) (bits >> rpos);
>>>> ????????????}
>>>> - ???????????return off == oldOff ? -1 : off - oldOff;
>>>> + ???????????return pos - off != 0 || rpos - 8 >= wpos ? pos - off : -1;
>>>> ????????}
>>>>
>>>> - ???????private int padding(byte[] b, int off, int len, int oldOff)
>>>> - ???????????throws IOException
>>>> - ???????{
>>>> - ???????????// = ????shiftto==18 unnecessary padding
>>>> - ???????????// x= ???shiftto==12 dangling x, invalid unit
>>>> - ???????????// xx= ??shiftto==6 && missing last '='
>>>> - ???????????// xx=y ?or last is not '='
>>>> - ???????????if (nextin == 18 || nextin == 12 ||
>>>> - ???????????????nextin == 6 && is.read() != '=') {
>>>> - ???????????????throw new IOException("Illegal base64 ending 
>>>> sequence:" + nextin);
>>>> + ???????private int eof(byte[] b, int off, int pos, int limit) 
>>>> throws IOException {
>>>> + ???????????/*
>>>> + ????????????* pos != limit
>>>> + ????????????*
>>>> + ????????????* wpos == 18: x ????dangling single x, invalid unit
>>>> + ????????????* accept ending xx or xxx without padding characters
>>>> + ????????????*/
>>>> + ???????????if (wpos == 18) {
>>>> + ???????????????throw new IOException("Base64 stream has one 
>>>> un-decoded dangling byte.");
>>>> ????????????}
>>>> - ???????????b[off++] = (byte)(bits >> (16));
>>>> - ???????????if (nextin == 0) { ??????????// only one padding byte
>>>> - ???????????????if (len == 1) { ?????????// no enough output space
>>>> - ???????????????????bits >>= 8; ?????????// shift to lowest byte
>>>> - ???????????????????nextout = 0;
>>>> - ???????????????} else {
>>>> - ???????????????????b[off++] = (byte) (bits >> ?8);
>>>> - ???????????????}
>>>> + ???????????rpos = 24;
>>>> + ???????????return leftovers(b, off, pos, limit);
>>>> + ???????}
>>>> +
>>>> + ???????private int padding(byte[] b, int off, int pos, int limit) 
>>>> throws IOException {
>>>> + ???????????/*
>>>> + ????????????* pos != limit
>>>> + ????????????*
>>>> + ????????????* wpos == 24: = ???(unnecessary padding)
>>>> + ????????????* wpos == 18: x= ??(dangling single x, invalid unit)
>>>> + ????????????* wpos == 12 and missing last '=': xx= ?(invalid padding)
>>>> + ????????????* wpos == 12 and last is not '=': xx=x (invalid padding)
>>>> + ????????????*/
>>>> + ???????????if (wpos >= 18 || wpos == 12 && is.read() != '=') {
>>>> + ???????????????throw new IOException("Illegal base64 ending 
>>>> sequence:" + wpos);
>>>> ????????????}
>>>> - ???????????eof = true;
>>>> - ???????????return off - oldOff;
>>>> + ???????????rpos = 24;
>>>> + ???????????return leftovers(b, off, pos, limit);
>>>> ????????}
>>>>
>>>> ????????@Override
>>>> ????????public int read(byte[] b, int off, int len) throws IOException {
>>>> - ???????????if (closed)
>>>> + ???????????if (closed) {
>>>> ????????????????throw new IOException("Stream is closed");
>>>> - ???????????if (eof && nextout < 0) ???// eof and no leftover
>>>> - ???????????????return -1;
>>>> - ???????????if (off < 0 || len < 0 || len > b.length - off)
>>>> - ???????????????throw new IndexOutOfBoundsException();
>>>> - ???????????int oldOff = off;
>>>> - ???????????while (nextout >= 0) { ??????// leftover output byte(s) 
>>>> in bits buf
>>>> - ???????????????if (len == 0)
>>>> - ???????????????????return off - oldOff;
>>>> - ???????????????b[off++] = (byte)(bits >> nextout);
>>>> - ???????????????len--;
>>>> - ???????????????nextout -= 8;
>>>> + ???????????}
>>>> + ???????????Objects.checkFromIndexSize(off, len, b.length);
>>>> + ???????????if (len == 0) {
>>>> + ???????????????return 0;
>>>> ????????????}
>>>> - ???????????bits = 0;
>>>> - ???????????while (len > 0) {
>>>> - ???????????????int v = is.read();
>>>> - ???????????????if (v == -1) {
>>>> - ???????????????????return eof(b, off, len, oldOff);
>>>> +
>>>> + ???????????/*
>>>> + ????????????* Rather than keeping 2 running vars (e.g., off and len),
>>>> + ????????????* we only keep one (pos), while definitely fixing the 
>>>> boundaries
>>>> + ????????????* of the range [off, limit).
>>>> + ????????????* More specifically, each use of pos as an index in b 
>>>> meets
>>>> + ????????????* ?????pos - off >= 0 & limit - pos > 0
>>>> + ????????????*
>>>> + ????????????* Note that limit can overflow to Integer.MIN_VALUE. 
>>>> However,
>>>> + ????????????* as long as comparisons with pos are as coded, 
>>>> there's no harm.
>>>> + ????????????*/
>>>> + ???????????int pos = off;
>>>> + ???????????final int limit = off + len;
>>>> + ???????????if (eof) {
>>>> + ???????????????return leftovers(b, off, pos, limit);
>>>> + ???????????}
>>>> +
>>>> + ???????????/*
>>>> + ????????????* Leftovers from previous invocation; here, wpos = 0.
>>>> + ????????????* There can be at most 2 leftover bytes (rpos <= 16).
>>>> + ????????????* Further, b has at least one free place.
>>>> + ????????????*
>>>> + ????????????* The logic could be coded as a loop, (as in method 
>>>> leftovers())
>>>> + ????????????* but the explicit "unrolling" makes it possible to 
>>>> generate
>>>> + ????????????* better byte extraction code.
>>>> + ????????????*/
>>>> + ???????????if (rpos == 16) {
>>>> + ???????????????b[pos++] = (byte) (bits >> 8);
>>>> + ???????????????rpos = 8;
>>>> + ???????????????if (pos == limit) {
>>>> + ???????????????????return len;
>>>> ????????????????}
>>>> - ???????????????if ((v = base64[v]) < 0) {
>>>> - ???????????????????if (v == -2) { ??????// padding byte(s)
>>>> - ???????????????????????return padding(b, off, len, oldOff);
>>>> - ???????????????????}
>>>> - ???????????????????if (v == -1) {
>>>> - ???????????????????????if (!isMIME)
>>>> - ???????????????????????????throw new IOException("Illegal base64 
>>>> character " +
>>>> - ???????????????????????????????Integer.toString(v, 16));
>>>> - ???????????????????????continue; ???????// skip if for rfc2045
>>>> - ???????????????????}
>>>> - ???????????????????// neve be here
>>>> - ???????????????}
>>>> - ???????????????bits |= (v << nextin);
>>>> - ???????????????if (nextin == 0) {
>>>> - ???????????????????nextin = 18; ????????// clear for next in
>>>> - ???????????????????b[off++] = (byte)(bits >> 16);
>>>> - ???????????????????if (len == 1) {
>>>> - ???????????????????????nextout = 8; ???// 2 bytes left in bits
>>>> - ???????????????????????break;
>>>> - ???????????????????}
>>>> - ???????????????????b[off++] = (byte)(bits >> 8);
>>>> - ???????????????????if (len == 2) {
>>>> - ???????????????????????nextout = 0; ???// 1 byte left in bits
>>>> - ???????????????????????break;
>>>> - ???????????????????}
>>>> - ???????????????????b[off++] = (byte)bits;
>>>> - ???????????????????len -= 3;
>>>> - ???????????????????bits = 0;
>>>> - ???????????????} else {
>>>> - ???????????????????nextin -= 6;
>>>> + ???????????}
>>>> + ???????????if (rpos == 8) {
>>>> + ???????????????b[pos++] = (byte) bits;
>>>> + ???????????????rpos = 0;
>>>> + ???????????????if (pos == limit) {
>>>> + ???????????????????return len;
>>>> ????????????????}
>>>> ????????????}
>>>> - ???????????return off - oldOff;
>>>> +
>>>> + ???????????bits = 0;
>>>> + ???????????wpos = 24;
>>>> + ???????????for (;;) {
>>>> + ???????????????/* pos != limit & rpos == 0 */
>>>> + ???????????????final int i = is.read();
>>>> + ???????????????if (i < 0) {
>>>> + ???????????????????return eof(b, off, pos, limit);
>>>> + ???????????????}
>>>> + ???????????????final int v = base64[i];
>>>> + ???????????????if (v < 0) {
>>>> + ???????????????????/*
>>>> + ????????????????????* i not in alphabet, thus
>>>> + ????????????????????* ?????v == -2: i is '=', the padding
>>>> + ????????????????????* ?????v == -1: i is something else, typically 
>>>> CR or LF
>>>> + ????????????????????*/
>>>> + ???????????????????if (v == -1) {
>>>> + ???????????????????????if (isMIME) {
>>>> + ???????????????????????????continue;
>>>> + ???????????????????????}
>>>> + ???????????????????????throw new IOException("Illegal base64 
>>>> character 0x" +
>>>> + ???????????????????????????????Integer.toHexString(i));
>>>> + ???????????????????}
>>>> + ???????????????????return padding(b, off, pos, limit);
>>>> + ???????????????}
>>>> + ???????????????wpos -= 6;
>>>> + ???????????????bits |= v << wpos;
>>>> + ???????????????if (wpos != 0) {
>>>> + ???????????????????continue;
>>>> + ???????????????}
>>>> + ???????????????if (limit - pos >= 3) {
>>>> + ???????????????????/* frequently taken fast path, no need to track 
>>>> rpos */
>>>> + ???????????????????b[pos++] = (byte) (bits >> 16);
>>>> + ???????????????????b[pos++] = (byte) (bits >> 8);
>>>> + ???????????????????b[pos++] = (byte) bits;
>>>> + ???????????????????bits = 0;
>>>> + ???????????????????wpos = 24;
>>>> + ???????????????????if (pos == limit) {
>>>> + ???????????????????????return len;
>>>> + ???????????????????}
>>>> + ???????????????????continue;
>>>> + ???????????????}
>>>> +
>>>> + ???????????????/* b has either 1 or 2 free places */
>>>> + ???????????????b[pos++] = (byte) (bits >> 16);
>>>> + ???????????????if (pos == limit) {
>>>> + ???????????????????rpos = 16;
>>>> + ???????????????????return len;
>>>> + ???????????????}
>>>> + ???????????????b[pos++] = (byte) (bits >> 8);
>>>> + ???????????????/* pos == limit, no need for an if */
>>>> + ???????????????rpos = 8;
>>>> + ???????????????return len;
>>>> + ???????????}
>>>> ????????}
>>>>
>>>> ????????@Override
>>>> diff --git a/test/jdk/java/util/Base64/TestBase64.java 
>>>> b/test/jdk/java/util/Base64/TestBase64.java
>>>> --- a/test/jdk/java/util/Base64/TestBase64.java
>>>> +++ b/test/jdk/java/util/Base64/TestBase64.java
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All 
>>>> rights reserved.
>>>> + * Copyright (c) 2012, 2020, 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
>>>> @@ -24,7 +24,7 @@
>>>> /**
>>>> ?* @test
>>>> ?* @bug 4235519 8004212 8005394 8007298 8006295 8006315 8006530 
>>>> 8007379 8008925
>>>> - * ?????8014217 8025003 8026330 8028397 8129544 8165243 8176379
>>>> + * ?????8014217 8025003 8026330 8028397 8129544 8165243 8176379 8222187
>>>> ?* @summary tests java.util.Base64
>>>> ?* @library /test/lib
>>>> ?* @build jdk.test.lib.RandomFactory
>>>> @@ -144,6 +144,10 @@
>>>> ????????testDecoderKeepsAbstinence(Base64.getDecoder());
>>>> ????????testDecoderKeepsAbstinence(Base64.getUrlDecoder());
>>>> ????????testDecoderKeepsAbstinence(Base64.getMimeDecoder());
>>>> +
>>>> + ???????// tests patch addressing JDK-8222187
>>>> + ???????// https://bugs.openjdk.java.net/browse/JDK-8222187
>>>> + ???????testJDK_8222187();
>>>> ????}
>>>>
>>>> ????private static void test(Base64.Encoder enc, Base64.Decoder dec,
>>>> @@ -607,4 +611,26 @@
>>>> ????????????}
>>>> ????????}
>>>> ????}
>>>> +
>>>> + ???private static void testJDK_8222187() throws Throwable {
>>>> + ???????byte[] orig = "12345678".getBytes("US-ASCII");
>>>> + ???????byte[] encoded = Base64.getEncoder().encode(orig);
>>>> + ???????// decode using different buffer sizes, up to a longer one 
>>>> than needed
>>>> + ???????for (int bufferSize = 1; bufferSize <= encoded.length + 1; 
>>>> bufferSize++) {
>>>> + ???????????try (
>>>> + ???????????????????InputStream in = Base64.getDecoder().wrap(
>>>> + ???????????????????????????new ByteArrayInputStream(encoded));
>>>> + ???????????????????ByteArrayOutputStream baos = new 
>>>> ByteArrayOutputStream();
>>>> + ???????????) {
>>>> + ???????????????byte[] buffer = new byte[bufferSize];
>>>> + ???????????????int read;
>>>> + ???????????????while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
>>>> + ???????????????????baos.write(buffer, 0, read);
>>>> + ???????????????}
>>>> + ???????????????// compare result, output info if lengths do not match
>>>> + ???????????????byte[] decoded = baos.toByteArray();
>>>> + ???????????????checkEqual(decoded, orig, "Base64 stream decoding 
>>>> failed!");
>>>> + ???????????}
>>>> + ???????}
>>>> + ???}
>>>> }
>>>> <JDK-8222187.patch>
>>>
>>> <oracle_sig_logo.gif> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle?Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
> 
> 
> Best
> Lance
> ------------------
> 
> 
> 
> Lance Andersen| Principal?Member of Technical Staff |?+1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 
> 

From erik.joelsson at oracle.com  Thu Jul 23 13:06:22 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Jul 2020 06:06:22 -0700
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
 <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>
Message-ID: <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com>

Hello Ningsheng,

Build change looks good.

/Erik

On 2020-07-23 01:02, Ningsheng Jian wrote:
> Hi Vladimir,
>
> Thanks for pointing out this. Yes, I missed that change in shared 
> code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
> included:
>
> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>
>
> Also add build-dev.
>
> Thanks,
> Ningsheng
>
> On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>>
>>
>>
>> FTR there's one more aarch64-specific change in shared code to enable 
>> aarch64_neon.ad processing:
>>
>> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
>> b/make/hotspot/gensrc/GensrcAdlc.gmk
>> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
>> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
>> @@ -129,6 +129,12 @@
>>
>> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
>> \
>> ????? )))
>>
>> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
>> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>> $(AD_SRC_ROOTS), \
>> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
>> +??? )))
>> +? endif
>> +
>> ??? ifeq ($(call check-jvm-feature, shenandoahgc), true)
>> ????? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>> $(AD_SRC_ROOTS), \
>>
>> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
>> \
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>> On 7/8/20 3:05 PM, Yang Zhang wrote:
>>>> Hi Andrew
>>>>
>>>> I have updated this patch. Could you please help to review it again?
>>>> In this patch, the following changes are made:
>>>> 1. Separate newly added NEON instructions to a new ad file
>>>> ??? aarch64_neon.ad
>>>> 2. Add assembler tests for NEON instructions. Trailing spaces
>>>> ??? in the python script are also removed.
>>>>
>>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>>>
>>>>
>>>> Thanks,
>>>> Yang
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Andrew Haley <aph at redhat.com>
>>>> Sent: Tuesday, June 30, 2020 12:10 AM
>>>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>>>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>>>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>>>> aarch64-port-dev at openjdk.java.net
>>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>>>> Vector API (Incubator): AArch64 backend changes
>>>>
>>>> On 29/06/2020 08:48, Yang Zhang wrote:
>>>>> 1. Instructions that can be matched with NEON instructions directly.
>>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>>>
>>>>> 2. Instructions that jdk master has middle end support for, but 
>>>>> they cannot be matched with NEON instructions directly.
>>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>>>> new instructions can be moved into jdk master first, but for 
>>>>> auto-vectorization, the performance might not get improved.
>>>>>
>>>>> 3. Panama/Vector API specific? instructions such as 
>>>>> Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
>>>>> MaxV/MinV, VectorBlend etc.
>>>>> These instructions cannot be moved into jdk master first because 
>>>>> there isn't middle-end support.
>>>>>
>>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>>>> ready, I will send it again.
>>>>
>>>> Thank you *very* much for your hard work. Appreciated!
>>>>
>>>> -- 
>>>> 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 ningsheng.jian at arm.com  Thu Jul 23 08:02:47 2020
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Thu, 23 Jul 2020 16:02:47 +0800
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
Message-ID: <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>

Hi Vladimir,

Thanks for pointing out this. Yes, I missed that change in shared code. 
I've regenerated the webrev, with GensrcAdlc.gmk file change included:

http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Also add build-dev.

Thanks,
Ningsheng

On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
> 
> 
> FTR there's one more aarch64-specific change in shared code to enable 
> aarch64_neon.ad processing:
> 
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
> b/make/hotspot/gensrc/GensrcAdlc.gmk
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
> @@ -129,6 +129,12 @@
> 
> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
> \
>  ???? )))
> 
> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
> $(AD_SRC_ROOTS), \
> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
> +??? )))
> +? endif
> +
>  ?? ifeq ($(call check-jvm-feature, shenandoahgc), true)
>  ???? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
> $(AD_SRC_ROOTS), \
> 
> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
> \
> 
> Best regards,
> Vladimir Ivanov
> 
>> On 7/8/20 3:05 PM, Yang Zhang wrote:
>>> Hi Andrew
>>>
>>> I have updated this patch. Could you please help to review it again?
>>> In this patch, the following changes are made:
>>> 1. Separate newly added NEON instructions to a new ad file
>>> ??? aarch64_neon.ad
>>> 2. Add assembler tests for NEON instructions. Trailing spaces
>>> ??? in the python script are also removed.
>>>
>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>>
>>>
>>> Thanks,
>>> Yang
>>>
>>>
>>> -----Original Message-----
>>> From: Andrew Haley <aph at redhat.com>
>>> Sent: Tuesday, June 30, 2020 12:10 AM
>>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>>> aarch64-port-dev at openjdk.java.net
>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>>> Vector API (Incubator): AArch64 backend changes
>>>
>>> On 29/06/2020 08:48, Yang Zhang wrote:
>>>> 1. Instructions that can be matched with NEON instructions directly.
>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>>
>>>> 2. Instructions that jdk master has middle end support for, but they 
>>>> cannot be matched with NEON instructions directly.
>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>>> new instructions can be moved into jdk master first, but for 
>>>> auto-vectorization, the performance might not get improved.
>>>>
>>>> 3. Panama/Vector API specific? instructions such as Load/StoreVector 
>>>> ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend 
>>>> etc.
>>>> These instructions cannot be moved into jdk master first because 
>>>> there isn't middle-end support.
>>>>
>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>>> ready, I will send it again.
>>>
>>> Thank you *very* much for your hard work. Appreciated!
>>>
>>> -- 
>>> 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 volker.simonis at gmail.com  Thu Jul 23 17:18:25 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 23 Jul 2020 19:18:25 +0200
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
Message-ID: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>

Hi,

can I please get some reviews for the following small enhancement
which will allow you to configure different zlib implementations at VM
start-up and get up to 100% better throughput for compression and
about 50% better throughput for decompression (depending on the
selected zlib implementation). We're using a similar change
productively in Amazon since quite a while with good results on
compression/decompression heavy workloads.

As usual, my write-up is moch longer and much more complex than the
change itself :)

http://cr.openjdk.java.net/~simonis/webrevs/2020/8249963/
https://bugs.openjdk.java.net/browse/JDK-8249963

I've tested these changes locally on Linux/Windows/Mac without any
problems but got a Mach5 build error for Windows after sending them to
the submit repo (Job:
mach5-one-simonis-JDK-8249963-20200723-1236-12890347, BuildId:
2020-07-23-1235507.volker.simonis.source). Would be great if somebody
from Oracle could shed some light on that issue.

Thank you and best regards,
Volker

Following some background, benchmarks and implementation details for the change:

The JDK bundles the original zlib implementation [1] almost from the
very beginning, starting with zlib 1.0.4 in JDK 1.1. In the meantime,
the bundled zlib implementation was updated to the latest released
version 1.2.11. However, the innovation velocity in the original zlib
version has considerably slowed down in the last years.

Lately, new projects have picked up the original zlib implementation
and considerably improved its deflate and inflate speed. Testing shows
that compression throughput can be improved between 50 and 100% with
Cloudflare's zlib version [2] and decompression throughput between 30
and 60% using the zlib implementation from the Chromium project [3].

Overview
--------

This enhancement proposes some simple changes to the JDK's zlib
wrapper libzip which make it possible to choose alternative zlib
implementations selectively for deflation and/or inflation at VM
startup based on a system property. As an additional benefit it makes
it possible to use the system zlib version even if the JDK was
configured with a bundled zlib.

Already now, the JDK can be configured at build time to either use the
bundled zlib version or to dynamically link against the system zlib.
If linked dynamically, LD_LIBRARY_PATH or LD_PRELOAD can be used to
run the JDK with an alternative zlib implementation. This approach is
however not very flexible because:
 - once configured with a "bundled" zlib it's not possible to use
another implementation any more. Some platforms like Windows don't
have a default, system provided zlib version so they are always built
with "--with-zlib=bundled" and therefore can't change the
implementation at runtime.
 - even if configured with "--with-zlib=system", it is only possible a
single alternative version as a substitute for the system zlib. But
we've found (see benchmarks [4]) that there's no single zlib
implementation which improves both compression and decompression
equally well. It may therefore make sense to have the possibility to
selectively use one implementation for compression and another one for
decompression.

This enhancement proposes three new system properties:

org.openjdk.zlib.implementation
org.openjdk.zlib.implementation.inflate
org.openjdk.zlib.implementation.deflate

which can be used to either replace the full zlib functionality or
selectively just the deflate or inflate part with a new
implementation. As an argument they take an absolute or relative path
to an API-compatible, shared zlib library. E.g.

-Dorg.openjdk.zlib.implementation=zlib-cloudflare.so
-Dorg.openjdk.zlib.implementation.deflate=/Git/zlib-bench/lib/x86_64/zlib-cloudflare.dylib
-Dorg.openjdk.zlib.implementation.inflate='D:\Git\zlib-bench\lib\x86_64\zlib-chromium.dll`

An argument with the value "system" can be used to instruct the JDK to
load the default zlib version on the corresponding system. Notice that
this option now also works in the case where the JDK was configured
with a bundled zlib.

The naming of the properties is of course subject to discussion. If we
get an agreement on this change and the naming, I'll be happy to open
a CSR for the introduction of the new properties.

For testing purpose I've made some precompiled version of
zlib-cloudflare and zlib-chromium for Linux/x86_64, Linux/aarch64,
MacOS/x86_64 and Windows/x86_64 available in my GitHub repository [6].

The implementation of this whole enhancement is fairly simple. Instead
of calling right into zlib from libzip I've replaced all direct calls
by indirect calls through function pointers. By default, these
function pointers are pointing either to the corresponding functions
in the bundled zlib implementation or to the corresponding functions
in the dynamically linked system zlib. If none of the above system
properties will be used, the only change to the current implementation
is the replacement of some direct calls by indirect calls. Because
these function calls are usually made through JNI and because the
underlying code is usually quite compute intensive, I couldn't measure
any performance regression because of this change.

If one of the above system properties will be set, the selected shared
library will be dynamically loaded and the corresponding function
pointers will be redirected to point to the new implementation. I have
verified that this works on Linux, Windows and Mac OS X. You can find
some more implementation details at the end of this write-up.

Benchmarks
----------

I've run native benchmarks to compare the compression/decompression
throughput and the compression ratio at various compression levels for
zlib-adler [7], zlib-chromium [8], zlib-ng [9], zlib-ipp [10],
zlib-cloudflare [11] and the isa-l [12] library. The results and more
details can be found in my zlib-bench GitHub repository [5].

After that I've used precompiled versions of zlib-cloudflare,
zlib-chromium and the changes proposed by this enhancement to rerun
these benchmarks in Java on Linux/x86_64 and Linux/aarch64. I think
the results are quite impressive [4] showing around 100% higher
throughput for compression and around 50% higher throughput for
decompression on both architectures.

Implementation details
----------------------

Before change "8237750: Load libzip.so only if necessary" [13] libzip
(and transitively libz) was loaded early at VM startup in
"init_globals() -> ClassLoader::initialize()". For this change I've
re-enabled this early loading if and only if one of the new system
properties was given on the command line. I think these new properties
will only be used if heavy compression/decompression usage is expected
and in such a case it doesn't harm to load libzip early at startup.
Loading libzip later and on demand would otherwise make the
synchronization of the function pointer initialization unnecessary
hard because libzip can be loaded independently from the VM as well as
from the class library.

An alternative approach would be to use __attribute(constructor) (on
Linux) or DLLMain() (on Windows) to perform the function pointer
initialization once when libzip gets loaded. But first, this approach
is quite system dependent and I'm not sure it is available on all
platforms (I'm pretty sure it doesn't work on AIX :). Second, I think
it is not possible to dynamically load DLLs from DLLMain() on Windows
which would be required in this case.

A third possibility would be to define a JNI OnLoad function for
libzip. But unfortunately, libzip can not only be loaded from
java.util.zip where we have a JNIEnv but also from HotSpot or directly
with dlopen() from libjimage.

I've also removed the following, OpenJDK-specific patch to "zconf.h"
in the bundled zlib version which seems to have been there "since
ever" but which I don't think is required any more:

src/java.base/share/native/libzip/zlib/zconf.h
-#ifdef _LP64
-typedef unsigned int  uLong;  /* 32 bits or more */
-#else
 typedef unsigned long  uLong; /* 32 bits or more */
-#endif

The change is needed to make the bundled zlib compatible with the
system or the other zlib implementations which all do not have this
change. Notice that if we're building with the system zlib, we are
already using this setting today because in that case "zconf.h" is
taken from the system include path.

Finally, it has to be noticed that although we are loading libzip
early there are still two call sites of zlib functionality which won't
be able to benefit from the new implementations because they either
statically link in parts of the bundled zlib version or directly and
dynamically link against the system zlib version. That's
libsplashscreen and libjli. Both are only used at startup and both
only make limited use of zlib (if they use it at all) so I don't think
that they are relevant.

Risks
-----

Unfortunately ZipInputStream/ZipOutputStream have been designed such
that it is very easy to use them in an unsupported way. It is in
general not possible to read a ZipEntry from a ZipInputStream and
write that exact ZipEntry into a ZipOutputStream followed by the
inflated and re-deflated data of that entry. However this naive
approach is sometimes used to copy zip entries from a zip input file
into another zip output file. This approach will only work in the case
where the exact same deflate implementation and compression was used
for the initial compression like for the recompression.

This is because the ZipEntry will contain the compressed size of the
data belonging to that entry. But the Deflate format doesn't mandate a
specific, fixed compression algorithm which will always result in the
same compressed size. Instead, different implementations are free to
use different approaches for compression which can result in valid
entries but potentially with a different compressed size.

Actually, even if just a single implementation is used for both
compression and decompression, it is still not possible to detect the
compression level from the compressed data. It is  therefore possible
that decompressing and re-compressing that data into a ZipOutputStream
will result in a different compressed size. However, ZipOutputStream
will throw an exception if the compressed size entry in a ZipEntry is
different from the actual size of the compressed data.

I've recently fixed two such cases in the OpenJDK (JDK-8240333 [14],
JDK-8240235 [15]) itself, but there may be other such use cases in the
wild which may throw an "ZipException: invalid entry compressed size
(expected 66 but got 67 bytes)". If that happens, the user can either
fix his code (which is trivial and advised because of the problems
explained before) or simply remove the new system properties in order
to fall back to the bundled or system implementation.

[1] https://www.zlib.net/
[2] https://github.com/cloudflare/zlib
[3] https://chromium.googlesource.com/chromium/src/third_party/zlib/
[4] https://github.com/simonis/zlib-bench/blob/master/Results-ojdk.md
[5] https://github.com/simonis/zlib-bench/blob/master/Results.md
[6] https://github.com/simonis/zlib-bench/tree/master/lib
[7] https://github.com/madler/zlib
[8] https://chromium.googlesource.com/chromium/src/third_party/zlib/
[9] https://github.com/zlib-ng/zlib-ng
[10] https://software.intel.com/en-us/articles/intel-ipp-zlib-coding-functions
[11] https://github.com/cloudflare/zlib
[12] https://github.com/intel/isa-l
[13] https://bugs.openjdk.java.net/browse/JDK-8237750
[14] https://bugs.openjdk.java.net/browse/JDK-8240333
[15] https://bugs.openjdk.java.net/browse/JDK-8240235

From joe.darcy at oracle.com  Thu Jul 23 17:37:58 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 23 Jul 2020 10:37:58 -0700
Subject: JDK 16 RFR of JDK-8250221: Address use of default constructors in
 java.logging
Message-ID: <cd7dda07-5e34-ae26-7772-9051bba2c3e5@oracle.com>

Hello,

Please review the changes for

 ??? JDK-8250221: Address use of default constructors in java.logging
 ??? webrev: http://cr.openjdk.java.net/~darcy/8250221.0/
 ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250223

This is part of a larger effort to remove reliance of default 
constructors in the JDK's exported API in preparation for introduction 
of a lint warning for this situation.

Patch below; I'll update copyright years as needed before a push.

Thanks,

-Joe

--- 
old/src/java.logging/share/classes/java/util/logging/ErrorManager.java 
2020-07-23 10:30:58.570574191 -0700
+++ 
new/src/java.logging/share/classes/java/util/logging/ErrorManager.java 
2020-07-23 10:30:58.126574191 -0700
@@ -39,6 +39,11 @@
 ?public class ErrorManager {
 ??? private boolean reported = false;

+??? /**
+???? * Create an {@code ErrorManager}.
+???? */
+??? public ErrorManager() {}
+
 ???? /*
 ????? * We declare standard error codes for important categories of errors.
 ????? */
--- 
old/src/java.logging/share/classes/java/util/logging/SimpleFormatter.java 
2020-07-23 10:30:59.390574191 -0700
+++ 
new/src/java.logging/share/classes/java/util/logging/SimpleFormatter.java 
2020-07-23 10:30:58.942574191 -0700
@@ -66,6 +66,11 @@
SurrogateLogger.getSimpleFormat(SimpleFormatter::getLoggingProperty);

 ???? /**
+???? * Create a {@code SimpleFormatter}.
+???? */
+??? public SimpleFormatter() {}
+
+??? /**
 ????? * Format the given LogRecord.
 ????? * <p>
 ????? * The formatting can be customized by specifying the format string


From lance.andersen at oracle.com  Thu Jul 23 17:43:50 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Jul 2020 13:43:50 -0400
Subject: JDK 16 RFR of JDK-8250221: Address use of default constructors in
 java.logging
In-Reply-To: <cd7dda07-5e34-ae26-7772-9051bba2c3e5@oracle.com>
References: <cd7dda07-5e34-ae26-7772-9051bba2c3e5@oracle.com>
Message-ID: <51344823-E004-4D84-9E8C-D65734F36255@oracle.com>

+1

> On Jul 23, 2020, at 1:37 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> ErrorManager.jav

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From mandy.chung at oracle.com  Thu Jul 23 18:40:40 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 23 Jul 2020 11:40:40 -0700
Subject: RFR JDK-8250219: Proxy::newProxyInstance spec should specify the
 behavior if a given proxy interface is hidden
Message-ID: <f7862c61-6c13-601e-7c20-908fdff26e00@oracle.com>

CSR: https://bugs.openjdk.java.net/browse/JDK-8250224

Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8250219/webrev.00/

This patch updates the `|Proxy::newProxyInstance` |spec to explicitly 
list that the given interfaces must be non-hidden interfaces.|? 
Proxy::newProxyInstance| currently throws IAE if a given proxy interface 
cannot be found by the given class loader. This covers for the case of a 
hidden proxy interface since it is not discoverable by any class loader. 
However the spec should clearly document the behavior about hidden 
interfaces and the exception message indicates if the interface is 
hidden clearly.

thanks
Mandy





From Alan.Bateman at oracle.com  Thu Jul 23 18:47:54 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Jul 2020 19:47:54 +0100
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
Message-ID: <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>

On 23/07/2020 18:18, Volker Simonis wrote:
> Hi,
>
> can I please get some reviews for the following small enhancement
> which will allow you to configure different zlib implementations at VM
> start-up and get up to 100% better throughput for compression and
> about 50% better throughput for decompression (depending on the
> selected zlib implementation). We're using a similar change
> productively in Amazon since quite a while with good results on
> compression/decompression heavy workloads.
>
> As usual, my write-up is moch longer and much more complex than the
> change itself :)
Yes, this needs discussion and agreement before starting an RFR. As 
you've summarized in the JIRA issue, we have configure 
--with-zlib=system and --with-zlib=bundled today. The former is the way 
to build when what to make it possible to use an alternative zlib.? The 
new requirement that I think you are brining up is the case where 
someone wants to use several zlib libraries at the same time, because 
they somehow know that one version has superior performance than the 
other on some functions. I think it's reasonable to ask if the JDK 
really needs to support this complexity. I could imagine testing or 
support folks in tears when they see the implications of this. Have you 
looked at alternatives that would benefit other users of zlib, e.g. an 
interposer that dispatches to the appropriate zlib based on configuration?

-Alan


From Alan.Bateman at oracle.com  Thu Jul 23 18:51:45 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Jul 2020 19:51:45 +0100
Subject: RFR JDK-8250219: Proxy::newProxyInstance spec should specify the
 behavior if a given proxy interface is hidden
In-Reply-To: <f7862c61-6c13-601e-7c20-908fdff26e00@oracle.com>
References: <f7862c61-6c13-601e-7c20-908fdff26e00@oracle.com>
Message-ID: <f9958968-cd12-0091-8c8c-099e2bb7181b@oracle.com>

On 23/07/2020 19:40, Mandy Chung wrote:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8250224
>
> Webrev: 
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8250219/webrev.00/
>
> This patch updates the `|Proxy::newProxyInstance` |spec to explicitly 
> list that the given interfaces must be non-hidden interfaces.|? 
> Proxy::newProxyInstance| currently throws IAE if a given proxy 
> interface cannot be found by the given class loader. This covers for 
> the case of a hidden proxy interface since it is not discoverable by 
> any class loader. However the spec should clearly document the 
> behavior about hidden interfaces and the exception message indicates 
> if the interface is hidden clearly.
>
This looks good.

-Alan.

From daniel.fuchs at oracle.com  Thu Jul 23 18:52:23 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 Jul 2020 19:52:23 +0100
Subject: JDK 16 RFR of JDK-8250221: Address use of default constructors in
 java.logging
In-Reply-To: <cd7dda07-5e34-ae26-7772-9051bba2c3e5@oracle.com>
References: <cd7dda07-5e34-ae26-7772-9051bba2c3e5@oracle.com>
Message-ID: <350e6901-bd97-be83-34cb-1eddf7bc60c2@oracle.com>

Hi Joe,

LGTM.

best regards,

-- daniel

On 23/07/2020 18:37, Joe Darcy wrote:
> Hello,
> 
> Please review the changes for
> 
>  ??? JDK-8250221: Address use of default constructors in java.logging
>  ??? webrev: http://cr.openjdk.java.net/~darcy/8250221.0/
>  ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250223
> 
> This is part of a larger effort to remove reliance of default 
> constructors in the JDK's exported API in preparation for introduction 
> of a lint warning for this situation.
> 
> Patch below; I'll update copyright years as needed before a push.
> 
> Thanks,
> 
> -Joe
> 
> --- 
> old/src/java.logging/share/classes/java/util/logging/ErrorManager.java 
> 2020-07-23 10:30:58.570574191 -0700
> +++ 
> new/src/java.logging/share/classes/java/util/logging/ErrorManager.java 
> 2020-07-23 10:30:58.126574191 -0700
> @@ -39,6 +39,11 @@
>  ?public class ErrorManager {
>  ??? private boolean reported = false;
> 
> +??? /**
> +???? * Create an {@code ErrorManager}.
> +???? */
> +??? public ErrorManager() {}
> +
>  ???? /*
>  ????? * We declare standard error codes for important categories of 
> errors.
>  ????? */
> --- 
> old/src/java.logging/share/classes/java/util/logging/SimpleFormatter.java 2020-07-23 
> 10:30:59.390574191 -0700
> +++ 
> new/src/java.logging/share/classes/java/util/logging/SimpleFormatter.java 2020-07-23 
> 10:30:58.942574191 -0700
> @@ -66,6 +66,11 @@
> SurrogateLogger.getSimpleFormat(SimpleFormatter::getLoggingProperty);
> 
>  ???? /**
> +???? * Create a {@code SimpleFormatter}.
> +???? */
> +??? public SimpleFormatter() {}
> +
> +??? /**
>  ????? * Format the given LogRecord.
>  ????? * <p>
>  ????? * The formatting can be customized by specifying the format string
> 


From lance.andersen at oracle.com  Thu Jul 23 19:35:24 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Jul 2020 15:35:24 -0400
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
Message-ID: <E8775DB1-A3A7-415E-A703-817436D2A5A0@oracle.com>

Hi Volker,

A change such as this I believe would require a JEP to fully define the changes/risks/benefits

I do have concerns about using multiple implementations for compression/decompression.  From a testing and support perspective, this adds additional burden.  What type of testing matrix are you proposing?

Thought has to be given as to what it would mean to be compatible which could require updates to the compatibility rules for JCK testing.

I am also concerned whether the proposed change adds enough value for the additional complexity (and support burden)  it brings.

Perhaps a proposal to replace  the current zlib with an alternative might be an easier path forward

I believe to move forward some, if not all of the above, including a JEP needs to be further flushed out.

Best,
Lance

> On Jul 23, 2020, at 1:18 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> can I please get some reviews for the following small enhancement
> which will allow you to configure different zlib implementations at VM
> start-up and get up to 100% better throughput for compression and
> about 50% better throughput for decompression (depending on the
> selected zlib implementation). We're using a similar change
> productively in Amazon since quite a while with good results on
> compression/decompression heavy workloads.
> 
> As usual, my write-up is moch longer and much more complex than the
> change itself :)
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2020/8249963/
> https://bugs.openjdk.java.net/browse/JDK-8249963
> 
> I've tested these changes locally on Linux/Windows/Mac without any
> problems but got a Mach5 build error for Windows after sending them to
> the submit repo (Job:
> mach5-one-simonis-JDK-8249963-20200723-1236-12890347, BuildId:
> 2020-07-23-1235507.volker.simonis.source). Would be great if somebody
> from Oracle could shed some light on that issue.
> 
> Thank you and best regards,
> Volker
> 
> Following some background, benchmarks and implementation details for the change:
> 
> The JDK bundles the original zlib implementation [1] almost from the
> very beginning, starting with zlib 1.0.4 in JDK 1.1. In the meantime,
> the bundled zlib implementation was updated to the latest released
> version 1.2.11. However, the innovation velocity in the original zlib
> version has considerably slowed down in the last years.
> 
> Lately, new projects have picked up the original zlib implementation
> and considerably improved its deflate and inflate speed. Testing shows
> that compression throughput can be improved between 50 and 100% with
> Cloudflare's zlib version [2] and decompression throughput between 30
> and 60% using the zlib implementation from the Chromium project [3].
> 
> Overview
> --------
> 
> This enhancement proposes some simple changes to the JDK's zlib
> wrapper libzip which make it possible to choose alternative zlib
> implementations selectively for deflation and/or inflation at VM
> startup based on a system property. As an additional benefit it makes
> it possible to use the system zlib version even if the JDK was
> configured with a bundled zlib.
> 
> Already now, the JDK can be configured at build time to either use the
> bundled zlib version or to dynamically link against the system zlib.
> If linked dynamically, LD_LIBRARY_PATH or LD_PRELOAD can be used to
> run the JDK with an alternative zlib implementation. This approach is
> however not very flexible because:
> - once configured with a "bundled" zlib it's not possible to use
> another implementation any more. Some platforms like Windows don't
> have a default, system provided zlib version so they are always built
> with "--with-zlib=bundled" and therefore can't change the
> implementation at runtime.
> - even if configured with "--with-zlib=system", it is only possible a
> single alternative version as a substitute for the system zlib. But
> we've found (see benchmarks [4]) that there's no single zlib
> implementation which improves both compression and decompression
> equally well. It may therefore make sense to have the possibility to
> selectively use one implementation for compression and another one for
> decompression.
> 
> This enhancement proposes three new system properties:
> 
> org.openjdk.zlib.implementation
> org.openjdk.zlib.implementation.inflate
> org.openjdk.zlib.implementation.deflate
> 
> which can be used to either replace the full zlib functionality or
> selectively just the deflate or inflate part with a new
> implementation. As an argument they take an absolute or relative path
> to an API-compatible, shared zlib library. E.g.
> 
> -Dorg.openjdk.zlib.implementation=zlib-cloudflare.so
> -Dorg.openjdk.zlib.implementation.deflate=/Git/zlib-bench/lib/x86_64/zlib-cloudflare.dylib
> -Dorg.openjdk.zlib.implementation.inflate='D:\Git\zlib-bench\lib\x86_64\zlib-chromium.dll`
> 
> An argument with the value "system" can be used to instruct the JDK to
> load the default zlib version on the corresponding system. Notice that
> this option now also works in the case where the JDK was configured
> with a bundled zlib.
> 
> The naming of the properties is of course subject to discussion. If we
> get an agreement on this change and the naming, I'll be happy to open
> a CSR for the introduction of the new properties.
> 
> For testing purpose I've made some precompiled version of
> zlib-cloudflare and zlib-chromium for Linux/x86_64, Linux/aarch64,
> MacOS/x86_64 and Windows/x86_64 available in my GitHub repository [6].
> 
> The implementation of this whole enhancement is fairly simple. Instead
> of calling right into zlib from libzip I've replaced all direct calls
> by indirect calls through function pointers. By default, these
> function pointers are pointing either to the corresponding functions
> in the bundled zlib implementation or to the corresponding functions
> in the dynamically linked system zlib. If none of the above system
> properties will be used, the only change to the current implementation
> is the replacement of some direct calls by indirect calls. Because
> these function calls are usually made through JNI and because the
> underlying code is usually quite compute intensive, I couldn't measure
> any performance regression because of this change.
> 
> If one of the above system properties will be set, the selected shared
> library will be dynamically loaded and the corresponding function
> pointers will be redirected to point to the new implementation. I have
> verified that this works on Linux, Windows and Mac OS X. You can find
> some more implementation details at the end of this write-up.
> 
> Benchmarks
> ----------
> 
> I've run native benchmarks to compare the compression/decompression
> throughput and the compression ratio at various compression levels for
> zlib-adler [7], zlib-chromium [8], zlib-ng [9], zlib-ipp [10],
> zlib-cloudflare [11] and the isa-l [12] library. The results and more
> details can be found in my zlib-bench GitHub repository [5].
> 
> After that I've used precompiled versions of zlib-cloudflare,
> zlib-chromium and the changes proposed by this enhancement to rerun
> these benchmarks in Java on Linux/x86_64 and Linux/aarch64. I think
> the results are quite impressive [4] showing around 100% higher
> throughput for compression and around 50% higher throughput for
> decompression on both architectures.
> 
> Implementation details
> ----------------------
> 
> Before change "8237750: Load libzip.so only if necessary" [13] libzip
> (and transitively libz) was loaded early at VM startup in
> "init_globals() -> ClassLoader::initialize()". For this change I've
> re-enabled this early loading if and only if one of the new system
> properties was given on the command line. I think these new properties
> will only be used if heavy compression/decompression usage is expected
> and in such a case it doesn't harm to load libzip early at startup.
> Loading libzip later and on demand would otherwise make the
> synchronization of the function pointer initialization unnecessary
> hard because libzip can be loaded independently from the VM as well as
> from the class library.
> 
> An alternative approach would be to use __attribute(constructor) (on
> Linux) or DLLMain() (on Windows) to perform the function pointer
> initialization once when libzip gets loaded. But first, this approach
> is quite system dependent and I'm not sure it is available on all
> platforms (I'm pretty sure it doesn't work on AIX :). Second, I think
> it is not possible to dynamically load DLLs from DLLMain() on Windows
> which would be required in this case.
> 
> A third possibility would be to define a JNI OnLoad function for
> libzip. But unfortunately, libzip can not only be loaded from
> java.util.zip where we have a JNIEnv but also from HotSpot or directly
> with dlopen() from libjimage.
> 
> I've also removed the following, OpenJDK-specific patch to "zconf.h"
> in the bundled zlib version which seems to have been there "since
> ever" but which I don't think is required any more:
> 
> src/java.base/share/native/libzip/zlib/zconf.h
> -#ifdef _LP64
> -typedef unsigned int  uLong;  /* 32 bits or more */
> -#else
> typedef unsigned long  uLong; /* 32 bits or more */
> -#endif
> 
> The change is needed to make the bundled zlib compatible with the
> system or the other zlib implementations which all do not have this
> change. Notice that if we're building with the system zlib, we are
> already using this setting today because in that case "zconf.h" is
> taken from the system include path.
> 
> Finally, it has to be noticed that although we are loading libzip
> early there are still two call sites of zlib functionality which won't
> be able to benefit from the new implementations because they either
> statically link in parts of the bundled zlib version or directly and
> dynamically link against the system zlib version. That's
> libsplashscreen and libjli. Both are only used at startup and both
> only make limited use of zlib (if they use it at all) so I don't think
> that they are relevant.
> 
> Risks
> -----
> 
> Unfortunately ZipInputStream/ZipOutputStream have been designed such
> that it is very easy to use them in an unsupported way. It is in
> general not possible to read a ZipEntry from a ZipInputStream and
> write that exact ZipEntry into a ZipOutputStream followed by the
> inflated and re-deflated data of that entry. However this naive
> approach is sometimes used to copy zip entries from a zip input file
> into another zip output file. This approach will only work in the case
> where the exact same deflate implementation and compression was used
> for the initial compression like for the recompression.
> 
> This is because the ZipEntry will contain the compressed size of the
> data belonging to that entry. But the Deflate format doesn't mandate a
> specific, fixed compression algorithm which will always result in the
> same compressed size. Instead, different implementations are free to
> use different approaches for compression which can result in valid
> entries but potentially with a different compressed size.
> 
> Actually, even if just a single implementation is used for both
> compression and decompression, it is still not possible to detect the
> compression level from the compressed data. It is  therefore possible
> that decompressing and re-compressing that data into a ZipOutputStream
> will result in a different compressed size. However, ZipOutputStream
> will throw an exception if the compressed size entry in a ZipEntry is
> different from the actual size of the compressed data.
> 
> I've recently fixed two such cases in the OpenJDK (JDK-8240333 [14],
> JDK-8240235 [15]) itself, but there may be other such use cases in the
> wild which may throw an "ZipException: invalid entry compressed size
> (expected 66 but got 67 bytes)". If that happens, the user can either
> fix his code (which is trivial and advised because of the problems
> explained before) or simply remove the new system properties in order
> to fall back to the bundled or system implementation.
> 
> [1] https://www.zlib.net/
> [2] https://github.com/cloudflare/zlib
> [3] https://chromium.googlesource.com/chromium/src/third_party/zlib/
> [4] https://github.com/simonis/zlib-bench/blob/master/Results-ojdk.md
> [5] https://github.com/simonis/zlib-bench/blob/master/Results.md
> [6] https://github.com/simonis/zlib-bench/tree/master/lib
> [7] https://github.com/madler/zlib
> [8] https://chromium.googlesource.com/chromium/src/third_party/zlib/
> [9] https://github.com/zlib-ng/zlib-ng
> [10] https://software.intel.com/en-us/articles/intel-ipp-zlib-coding-functions
> [11] https://github.com/cloudflare/zlib
> [12] https://github.com/intel/isa-l
> [13] https://bugs.openjdk.java.net/browse/JDK-8237750
> [14] https://bugs.openjdk.java.net/browse/JDK-8240333
> [15] https://bugs.openjdk.java.net/browse/JDK-8240235

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From Roger.Riggs at oracle.com  Thu Jul 23 20:27:15 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jul 2020 16:27:15 -0400
Subject: RFR 8250235:
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java should be on the
 problem list
Message-ID: <06b7fc01-a6e5-55f5-4507-7fb032187d9e@oracle.com>

Please review adding an intermittent test to the ProblemList.

The test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 
has been failing
intermittently and fairly frequently. [1]

diff a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -569,10 +569,11 @@
  
  java/lang/StringCoding/CheckEncodings.sh                        7008363 generic-all
  java/lang/ProcessHandle/InfoTest.java                           8211847 aix-ppc64
  java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java        8151492 generic-all
  java/lang/invoke/LFCaching/LFGarbageCollectedTest.java          8078602 generic-all
+java/lang/invoke/lambda/LambdaFileEncodingSerialization.java    8249079 linux-x64
  
  ############################################################################
  
  # jdk_instrument


Issue:
 ? https://bugs.openjdk.java.net/browse/JDK-8250235

Webrev:
 ? http://cr.openjdk.java.net/~rriggs/webrev-problem-8250235/

[1] https://bugs.openjdk.java.net/browse/JDK-8249079
 ?? LambdaFileEncodingSerialization.java failed "exitCode = 1 expected 
[true] but found [false]"

Thanks, Roger


From daniel.daugherty at oracle.com  Thu Jul 23 20:28:18 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 23 Jul 2020 16:28:18 -0400
Subject: RFR(T): 8250236: ProblemList
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64
Message-ID: <28f472e4-b3c5-783d-b0a1-b5c0af72e6df@oracle.com>

Greetings,

I'm making another pass at reducing the noise in the JDK16 CI.

There are currently 34 sightings of this test failure since I filed
the bug on 2020.07.08. I think it is time to ProblemList this test. For
whatever reason, this failures only seems to be happening on Linux-X64
machines.

Here's the context diff for this trivial review:

$ hg diff
diff -r d62da6fc4074 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt??? Thu Jul 23 20:25:41 2020 +0100
+++ b/test/jdk/ProblemList.txt??? Thu Jul 23 16:20:37 2020 -0400
@@ -571,6 +571,7 @@
 ?java/lang/ProcessHandle/InfoTest.java 8211847 aix-ppc64
 ?java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java 8151492 
generic-all
 ?java/lang/invoke/LFCaching/LFGarbageCollectedTest.java 8078602 generic-all
+java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 8249079 
linux-x64

 ?############################################################################


Thanks, in advance, for any comments, questions or suggestions.

Dan

From daniel.daugherty at oracle.com  Thu Jul 23 20:30:38 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 23 Jul 2020 16:30:38 -0400
Subject: RFR(T): 8250236: ProblemList
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64
Message-ID: <5a510876-73de-4043-47eb-65520fb973eb@oracle.com>

Accidentally pushed send before I was done. Please ignore the previous 
email...

Greetings,

I'm making another pass at reducing the noise in the JDK16 CI.

There are currently 34 sightings of this test failure since I filed
the bug on 2020.07.08. I think it is time to ProblemList this test. For
whatever reason, this failures only seems to be happening on Linux-X64
machines.

Here's the bug:

 ??? JDK-8249079 LambdaFileEncodingSerialization.java failed "exitCode = 
1 expected [true] but found [false]"
 ??? https://bugs.openjdk.java.net/browse/JDK-8249079

Here's the ProblemListing bug:

 ??? JDK-8250236 ProblemList 
java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64
 ??? https://bugs.openjdk.java.net/browse/JDK-8250236

Here's the context diff for this trivial review:

$ hg diff
diff -r d62da6fc4074 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt??? Thu Jul 23 20:25:41 2020 +0100
+++ b/test/jdk/ProblemList.txt??? Thu Jul 23 16:20:37 2020 -0400
@@ -571,6 +571,7 @@
 ?java/lang/ProcessHandle/InfoTest.java 8211847 aix-ppc64
 ?java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java 8151492 
generic-all
 ?java/lang/invoke/LFCaching/LFGarbageCollectedTest.java 8078602 generic-all
+java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 8249079 
linux-x64

 ?############################################################################


Thanks, in advance, for any comments, questions or suggestions.

Dan


From lance.andersen at oracle.com  Thu Jul 23 20:30:56 2020
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 23 Jul 2020 16:30:56 -0400
Subject: RFR 8250235:
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java should be on the
 problem list
In-Reply-To: <06b7fc01-a6e5-55f5-4507-7fb032187d9e@oracle.com>
References: <06b7fc01-a6e5-55f5-4507-7fb032187d9e@oracle.com>
Message-ID: <4DEE7E9E-8FC1-4DD8-B0A6-D322765A3AA6@oracle.com>

+1

Best,
Lance



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Jul 23, 2020, at 4:28 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> ?Please review adding an intermittent test to the ProblemList.
> 
> The test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java has been failing
> intermittently and fairly frequently. [1]
> 
> diff a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -569,10 +569,11 @@
>  java/lang/StringCoding/CheckEncodings.sh                        7008363 generic-all
> java/lang/ProcessHandle/InfoTest.java                           8211847 aix-ppc64
> java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java        8151492 generic-all
> java/lang/invoke/LFCaching/LFGarbageCollectedTest.java          8078602 generic-all
> +java/lang/invoke/lambda/LambdaFileEncodingSerialization.java    8249079 linux-x64
>  ############################################################################
>  # jdk_instrument
> 
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8250235
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-problem-8250235/
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8249079
>    LambdaFileEncodingSerialization.java failed "exitCode = 1 expected [true] but found [false]"
> 
> Thanks, Roger
> 

From Roger.Riggs at oracle.com  Thu Jul 23 20:34:40 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jul 2020 16:34:40 -0400
Subject: RFR(T): 8250236: ProblemList
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64
In-Reply-To: <5a510876-73de-4043-47eb-65520fb973eb@oracle.com>
References: <5a510876-73de-4043-47eb-65520fb973eb@oracle.com>
Message-ID: <7b772558-3f78-e075-18dd-d3d6a40cb9dd@oracle.com>

Looks good, thanks

On 7/23/20 4:30 PM, Daniel D. Daugherty wrote:
> Accidentally pushed send before I was done. Please ignore the previous 
> email...
>
> Greetings,
>
> I'm making another pass at reducing the noise in the JDK16 CI.
>
> There are currently 34 sightings of this test failure since I filed
> the bug on 2020.07.08. I think it is time to ProblemList this test. For
> whatever reason, this failures only seems to be happening on Linux-X64
> machines.
>
> Here's the bug:
>
> ??? JDK-8249079 LambdaFileEncodingSerialization.java failed "exitCode 
> = 1 expected [true] but found [false]"
> ??? https://bugs.openjdk.java.net/browse/JDK-8249079
>
> Here's the ProblemListing bug:
>
> ??? JDK-8250236 ProblemList 
> java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64
> ??? https://bugs.openjdk.java.net/browse/JDK-8250236
>
> Here's the context diff for this trivial review:
>
> $ hg diff
> diff -r d62da6fc4074 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt??? Thu Jul 23 20:25:41 2020 +0100
> +++ b/test/jdk/ProblemList.txt??? Thu Jul 23 16:20:37 2020 -0400
> @@ -571,6 +571,7 @@
> ?java/lang/ProcessHandle/InfoTest.java 8211847 aix-ppc64
> ?java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java 8151492 
> generic-all
> ?java/lang/invoke/LFCaching/LFGarbageCollectedTest.java 8078602 
> generic-all
> +java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 8249079 
> linux-x64
>
> ?############################################################################ 
>
>
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>


From Roger.Riggs at oracle.com  Thu Jul 23 20:36:30 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 Jul 2020 16:36:30 -0400
Subject: RFR 8250235:
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java should be on the
 problem list
In-Reply-To: <4DEE7E9E-8FC1-4DD8-B0A6-D322765A3AA6@oracle.com>
References: <06b7fc01-a6e5-55f5-4507-7fb032187d9e@oracle.com>
 <4DEE7E9E-8FC1-4DD8-B0A6-D322765A3AA6@oracle.com>
Message-ID: <13a4f2b1-ee76-f343-3eda-b77117d27e2d@oracle.com>

Thanks, but never mind,
Dan and I had a race to get this on the Problem List;? I lost. (Or Won, 
I'm not sure which).

On 7/23/20 4:30 PM, Lance @ Oracle wrote:
> +1
>
> Best,
> Lance
>
> [null] <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> _
> _
> Lance Andersen| Principal Member of Technical Staff |+1.781.442.2037 
> <tel:+1.781.442.2037>
> Oracle?Java Engineering
> 1 Network Drive <x-apple-data-detectors://1/1>
> Burlington, MA 01803 <x-apple-data-detectors://1/1>
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> Sent from my iPad
>
>> On Jul 23, 2020, at 4:28 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>> ?Please review adding an intermittent test to the ProblemList.
>>
>> The test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 
>> has been failing
>> intermittently and fairly frequently. [1]
>>
>> diff a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -569,10 +569,11 @@
>> ?java/lang/StringCoding/CheckEncodings.sh 
>> ???????????????????????7008363 generic-all
>> java/lang/ProcessHandle/InfoTest.java 
>> ??????????????????????????8211847 aix-ppc64
>> java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java 
>> ???????8151492 generic-all
>> java/lang/invoke/LFCaching/LFGarbageCollectedTest.java 
>> ?????????8078602 generic-all
>> +java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 
>> ???8249079 linux-x64
>> ?############################################################################
>> ?# jdk_instrument
>>
>>
>> Issue:
>> ? https://bugs.openjdk.java.net/browse/JDK-8250235
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-problem-8250235/
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8249079
>> ?? LambdaFileEncodingSerialization.java failed "exitCode = 1 expected 
>> [true] but found [false]"
>>
>> Thanks, Roger
>>


From daniel.daugherty at oracle.com  Thu Jul 23 20:35:34 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 23 Jul 2020 16:35:34 -0400
Subject: RFR(T): 8250236: ProblemList
 java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-x64
In-Reply-To: <7b772558-3f78-e075-18dd-d3d6a40cb9dd@oracle.com>
References: <5a510876-73de-4043-47eb-65520fb973eb@oracle.com>
 <7b772558-3f78-e075-18dd-d3d6a40cb9dd@oracle.com>
Message-ID: <7ec832a4-4484-631e-da1c-6e7704a48991@oracle.com>

Thanks for the fast review.

Dan



On 7/23/20 4:34 PM, Roger Riggs wrote:
> Looks good, thanks
>
> On 7/23/20 4:30 PM, Daniel D. Daugherty wrote:
>> Accidentally pushed send before I was done. Please ignore the 
>> previous email...
>>
>> Greetings,
>>
>> I'm making another pass at reducing the noise in the JDK16 CI.
>>
>> There are currently 34 sightings of this test failure since I filed
>> the bug on 2020.07.08. I think it is time to ProblemList this test. For
>> whatever reason, this failures only seems to be happening on Linux-X64
>> machines.
>>
>> Here's the bug:
>>
>> ??? JDK-8249079 LambdaFileEncodingSerialization.java failed "exitCode 
>> = 1 expected [true] but found [false]"
>> ??? https://bugs.openjdk.java.net/browse/JDK-8249079
>>
>> Here's the ProblemListing bug:
>>
>> ??? JDK-8250236 ProblemList 
>> java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on 
>> linux-x64
>> ??? https://bugs.openjdk.java.net/browse/JDK-8250236
>>
>> Here's the context diff for this trivial review:
>>
>> $ hg diff
>> diff -r d62da6fc4074 test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt??? Thu Jul 23 20:25:41 2020 +0100
>> +++ b/test/jdk/ProblemList.txt??? Thu Jul 23 16:20:37 2020 -0400
>> @@ -571,6 +571,7 @@
>> ?java/lang/ProcessHandle/InfoTest.java 8211847 aix-ppc64
>> ?java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java 8151492 
>> generic-all
>> ?java/lang/invoke/LFCaching/LFGarbageCollectedTest.java 8078602 
>> generic-all
>> +java/lang/invoke/lambda/LambdaFileEncodingSerialization.java 8249079 
>> linux-x64
>>
>> ?############################################################################ 
>>
>>
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>


From thomas.stuefe at gmail.com  Thu Jul 23 20:44:53 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 23 Jul 2020 22:44:53 +0200
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <E8775DB1-A3A7-415E-A703-817436D2A5A0@oracle.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <E8775DB1-A3A7-415E-A703-817436D2A5A0@oracle.com>
Message-ID: <CAA-vtUwxv7mreJHS9866kM_7jLHOC_oNfo9CU0PNDtn9ezxE4Q@mail.gmail.com>

Hi,

Could this not be handled like any other third party provided binary which
can run in our process? Say, a jvmti agent, any JNI library, or any system
library? For all these cases we expect the user to know what he is doing,
resp. the system library not to be buggy. Why not here? This seems like an
arbitrary distinction.

Cheers, Thomas




On Thu 23. Jul 2020 at 21:35, Lance Andersen <lance.andersen at oracle.com>
wrote:

> Hi Volker,
>
> A change such as this I believe would require a JEP to fully define the
> changes/risks/benefits
>
> I do have concerns about using multiple implementations for
> compression/decompression.  From a testing and support perspective, this
> adds additional burden.  What type of testing matrix are you proposing?
>
> Thought has to be given as to what it would mean to be compatible which
> could require updates to the compatibility rules for JCK testing.
>
> I am also concerned whether the proposed change adds enough value for the
> additional complexity (and support burden)  it brings.
>
> Perhaps a proposal to replace  the current zlib with an alternative might
> be an easier path forward
>
> I believe to move forward some, if not all of the above, including a JEP
> needs to be further flushed out.
>
> Best,
> Lance
>
> > On Jul 23, 2020, at 1:18 PM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
> >
> > Hi,
> >
> > can I please get some reviews for the following small enhancement
> > which will allow you to configure different zlib implementations at VM
> > start-up and get up to 100% better throughput for compression and
> > about 50% better throughput for decompression (depending on the
> > selected zlib implementation). We're using a similar change
> > productively in Amazon since quite a while with good results on
> > compression/decompression heavy workloads.
> >
> > As usual, my write-up is moch longer and much more complex than the
> > change itself :)
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2020/8249963/
> > https://bugs.openjdk.java.net/browse/JDK-8249963
> >
> > I've tested these changes locally on Linux/Windows/Mac without any
> > problems but got a Mach5 build error for Windows after sending them to
> > the submit repo (Job:
> > mach5-one-simonis-JDK-8249963-20200723-1236-12890347, BuildId:
> > 2020-07-23-1235507.volker.simonis.source). Would be great if somebody
> > from Oracle could shed some light on that issue.
> >
> > Thank you and best regards,
> > Volker
> >
> > Following some background, benchmarks and implementation details for the
> change:
> >
> > The JDK bundles the original zlib implementation [1] almost from the
> > very beginning, starting with zlib 1.0.4 in JDK 1.1. In the meantime,
> > the bundled zlib implementation was updated to the latest released
> > version 1.2.11. However, the innovation velocity in the original zlib
> > version has considerably slowed down in the last years.
> >
> > Lately, new projects have picked up the original zlib implementation
> > and considerably improved its deflate and inflate speed. Testing shows
> > that compression throughput can be improved between 50 and 100% with
> > Cloudflare's zlib version [2] and decompression throughput between 30
> > and 60% using the zlib implementation from the Chromium project [3].
> >
> > Overview
> > --------
> >
> > This enhancement proposes some simple changes to the JDK's zlib
> > wrapper libzip which make it possible to choose alternative zlib
> > implementations selectively for deflation and/or inflation at VM
> > startup based on a system property. As an additional benefit it makes
> > it possible to use the system zlib version even if the JDK was
> > configured with a bundled zlib.
> >
> > Already now, the JDK can be configured at build time to either use the
> > bundled zlib version or to dynamically link against the system zlib.
> > If linked dynamically, LD_LIBRARY_PATH or LD_PRELOAD can be used to
> > run the JDK with an alternative zlib implementation. This approach is
> > however not very flexible because:
> > - once configured with a "bundled" zlib it's not possible to use
> > another implementation any more. Some platforms like Windows don't
> > have a default, system provided zlib version so they are always built
> > with "--with-zlib=bundled" and therefore can't change the
> > implementation at runtime.
> > - even if configured with "--with-zlib=system", it is only possible a
> > single alternative version as a substitute for the system zlib. But
> > we've found (see benchmarks [4]) that there's no single zlib
> > implementation which improves both compression and decompression
> > equally well. It may therefore make sense to have the possibility to
> > selectively use one implementation for compression and another one for
> > decompression.
> >
> > This enhancement proposes three new system properties:
> >
> > org.openjdk.zlib.implementation
> > org.openjdk.zlib.implementation.inflate
> > org.openjdk.zlib.implementation.deflate
> >
> > which can be used to either replace the full zlib functionality or
> > selectively just the deflate or inflate part with a new
> > implementation. As an argument they take an absolute or relative path
> > to an API-compatible, shared zlib library. E.g.
> >
> > -Dorg.openjdk.zlib.implementation=zlib-cloudflare.so
> >
> -Dorg.openjdk.zlib.implementation.deflate=/Git/zlib-bench/lib/x86_64/zlib-cloudflare.dylib
> >
> -Dorg.openjdk.zlib.implementation.inflate='D:\Git\zlib-bench\lib\x86_64\zlib-chromium.dll`
> >
> > An argument with the value "system" can be used to instruct the JDK to
> > load the default zlib version on the corresponding system. Notice that
> > this option now also works in the case where the JDK was configured
> > with a bundled zlib.
> >
> > The naming of the properties is of course subject to discussion. If we
> > get an agreement on this change and the naming, I'll be happy to open
> > a CSR for the introduction of the new properties.
> >
> > For testing purpose I've made some precompiled version of
> > zlib-cloudflare and zlib-chromium for Linux/x86_64, Linux/aarch64,
> > MacOS/x86_64 and Windows/x86_64 available in my GitHub repository [6].
> >
> > The implementation of this whole enhancement is fairly simple. Instead
> > of calling right into zlib from libzip I've replaced all direct calls
> > by indirect calls through function pointers. By default, these
> > function pointers are pointing either to the corresponding functions
> > in the bundled zlib implementation or to the corresponding functions
> > in the dynamically linked system zlib. If none of the above system
> > properties will be used, the only change to the current implementation
> > is the replacement of some direct calls by indirect calls. Because
> > these function calls are usually made through JNI and because the
> > underlying code is usually quite compute intensive, I couldn't measure
> > any performance regression because of this change.
> >
> > If one of the above system properties will be set, the selected shared
> > library will be dynamically loaded and the corresponding function
> > pointers will be redirected to point to the new implementation. I have
> > verified that this works on Linux, Windows and Mac OS X. You can find
> > some more implementation details at the end of this write-up.
> >
> > Benchmarks
> > ----------
> >
> > I've run native benchmarks to compare the compression/decompression
> > throughput and the compression ratio at various compression levels for
> > zlib-adler [7], zlib-chromium [8], zlib-ng [9], zlib-ipp [10],
> > zlib-cloudflare [11] and the isa-l [12] library. The results and more
> > details can be found in my zlib-bench GitHub repository [5].
> >
> > After that I've used precompiled versions of zlib-cloudflare,
> > zlib-chromium and the changes proposed by this enhancement to rerun
> > these benchmarks in Java on Linux/x86_64 and Linux/aarch64. I think
> > the results are quite impressive [4] showing around 100% higher
> > throughput for compression and around 50% higher throughput for
> > decompression on both architectures.
> >
> > Implementation details
> > ----------------------
> >
> > Before change "8237750: Load libzip.so only if necessary" [13] libzip
> > (and transitively libz) was loaded early at VM startup in
> > "init_globals() -> ClassLoader::initialize()". For this change I've
> > re-enabled this early loading if and only if one of the new system
> > properties was given on the command line. I think these new properties
> > will only be used if heavy compression/decompression usage is expected
> > and in such a case it doesn't harm to load libzip early at startup.
> > Loading libzip later and on demand would otherwise make the
> > synchronization of the function pointer initialization unnecessary
> > hard because libzip can be loaded independently from the VM as well as
> > from the class library.
> >
> > An alternative approach would be to use __attribute(constructor) (on
> > Linux) or DLLMain() (on Windows) to perform the function pointer
> > initialization once when libzip gets loaded. But first, this approach
> > is quite system dependent and I'm not sure it is available on all
> > platforms (I'm pretty sure it doesn't work on AIX :). Second, I think
> > it is not possible to dynamically load DLLs from DLLMain() on Windows
> > which would be required in this case.
> >
> > A third possibility would be to define a JNI OnLoad function for
> > libzip. But unfortunately, libzip can not only be loaded from
> > java.util.zip where we have a JNIEnv but also from HotSpot or directly
> > with dlopen() from libjimage.
> >
> > I've also removed the following, OpenJDK-specific patch to "zconf.h"
> > in the bundled zlib version which seems to have been there "since
> > ever" but which I don't think is required any more:
> >
> > src/java.base/share/native/libzip/zlib/zconf.h
> > -#ifdef _LP64
> > -typedef unsigned int  uLong;  /* 32 bits or more */
> > -#else
> > typedef unsigned long  uLong; /* 32 bits or more */
> > -#endif
> >
> > The change is needed to make the bundled zlib compatible with the
> > system or the other zlib implementations which all do not have this
> > change. Notice that if we're building with the system zlib, we are
> > already using this setting today because in that case "zconf.h" is
> > taken from the system include path.
> >
> > Finally, it has to be noticed that although we are loading libzip
> > early there are still two call sites of zlib functionality which won't
> > be able to benefit from the new implementations because they either
> > statically link in parts of the bundled zlib version or directly and
> > dynamically link against the system zlib version. That's
> > libsplashscreen and libjli. Both are only used at startup and both
> > only make limited use of zlib (if they use it at all) so I don't think
> > that they are relevant.
> >
> > Risks
> > -----
> >
> > Unfortunately ZipInputStream/ZipOutputStream have been designed such
> > that it is very easy to use them in an unsupported way. It is in
> > general not possible to read a ZipEntry from a ZipInputStream and
> > write that exact ZipEntry into a ZipOutputStream followed by the
> > inflated and re-deflated data of that entry. However this naive
> > approach is sometimes used to copy zip entries from a zip input file
> > into another zip output file. This approach will only work in the case
> > where the exact same deflate implementation and compression was used
> > for the initial compression like for the recompression.
> >
> > This is because the ZipEntry will contain the compressed size of the
> > data belonging to that entry. But the Deflate format doesn't mandate a
> > specific, fixed compression algorithm which will always result in the
> > same compressed size. Instead, different implementations are free to
> > use different approaches for compression which can result in valid
> > entries but potentially with a different compressed size.
> >
> > Actually, even if just a single implementation is used for both
> > compression and decompression, it is still not possible to detect the
> > compression level from the compressed data. It is  therefore possible
> > that decompressing and re-compressing that data into a ZipOutputStream
> > will result in a different compressed size. However, ZipOutputStream
> > will throw an exception if the compressed size entry in a ZipEntry is
> > different from the actual size of the compressed data.
> >
> > I've recently fixed two such cases in the OpenJDK (JDK-8240333 [14],
> > JDK-8240235 [15]) itself, but there may be other such use cases in the
> > wild which may throw an "ZipException: invalid entry compressed size
> > (expected 66 but got 67 bytes)". If that happens, the user can either
> > fix his code (which is trivial and advised because of the problems
> > explained before) or simply remove the new system properties in order
> > to fall back to the bundled or system implementation.
> >
> > [1] https://www.zlib.net/
> > [2] https://github.com/cloudflare/zlib
> > [3] https://chromium.googlesource.com/chromium/src/third_party/zlib/
> > [4] https://github.com/simonis/zlib-bench/blob/master/Results-ojdk.md
> > [5] https://github.com/simonis/zlib-bench/blob/master/Results.md
> > [6] https://github.com/simonis/zlib-bench/tree/master/lib
> > [7] https://github.com/madler/zlib
> > [8] https://chromium.googlesource.com/chromium/src/third_party/zlib/
> > [9] https://github.com/zlib-ng/zlib-ng
> > [10]
> https://software.intel.com/en-us/articles/intel-ipp-zlib-coding-functions
> > [11] https://github.com/cloudflare/zlib
> > [12] https://github.com/intel/isa-l
> > [13] https://bugs.openjdk.java.net/browse/JDK-8237750
> > [14] https://bugs.openjdk.java.net/browse/JDK-8240333
> > [15] https://bugs.openjdk.java.net/browse/JDK-8240235
>
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <
> http://oracle.com/us/design/oracle-email-sig-198324.gif>
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>
>

From joe.darcy at oracle.com  Thu Jul 23 21:24:36 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 23 Jul 2020 14:24:36 -0700
Subject: JDK 16 RFR of JDK-8250237: Address use of default constructors in the
 javax.script package
Message-ID: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>

Hello,

One class in the javax.script package uses a default constructor; please 
review the patch below and CSR 
(https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an 
explicit constructor.

Thanks,

-Joe

diff -r d62da6fc4074 
src/java.scripting/share/classes/javax/script/CompiledScript.java
--- a/src/java.scripting/share/classes/javax/script/CompiledScript.java 
Thu Jul 23 20:25:41 2020 +0100
+++ b/src/java.scripting/share/classes/javax/script/CompiledScript.java 
Thu Jul 23 14:15:08 2020 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2020, 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
@@ -42,6 +42,10 @@
 ? * @since 1.6
 ? */
 ?public abstract class CompiledScript {
+??? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public CompiledScript() {}

 ???? /**
 ????? * Executes the program stored in this <code>CompiledScript</code> 
object.


From paul.sandoz at oracle.com  Thu Jul 23 21:29:35 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 23 Jul 2020 14:29:35 -0700
Subject: JDK 16 RFR of JDK-8250237: Address use of default constructors in
 the javax.script package
In-Reply-To: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>
References: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>
Message-ID: <D0114517-22E0-41B1-B834-5CD4EED6DDDB@oracle.com>

+1

Paul.

> On Jul 23, 2020, at 2:24 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> One class in the javax.script package uses a default constructor; please review the patch below and CSR (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an explicit constructor.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d62da6fc4074 src/java.scripting/share/classes/javax/script/CompiledScript.java
> --- a/src/java.scripting/share/classes/javax/script/CompiledScript.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.scripting/share/classes/javax/script/CompiledScript.java Thu Jul 23 14:15:08 2020 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2020, 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
> @@ -42,6 +42,10 @@
>   * @since 1.6
>   */
>  public abstract class CompiledScript {
> +    /**
> +     * Constructor for subclasses to call.
> +     */
> +    public CompiledScript() {}
> 
>      /**
>       * Executes the program stored in this <code>CompiledScript</code> object.
> 


From lance.andersen at oracle.com  Thu Jul 23 21:34:16 2020
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 23 Jul 2020 17:34:16 -0400
Subject: JDK 16 RFR of JDK-8250237: Address use of default constructors in
 the javax.script package
In-Reply-To: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>
References: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>
Message-ID: <BF858FBD-82FE-4769-B432-4AA9B5FD0B51@oracle.com>

+1

Best,
Lance



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Jul 23, 2020, at 5:24 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> ?Hello,
> 
> One class in the javax.script package uses a default constructor; please review the patch below and CSR (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an explicit constructor.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d62da6fc4074 src/java.scripting/share/classes/javax/script/CompiledScript.java
> --- a/src/java.scripting/share/classes/javax/script/CompiledScript.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.scripting/share/classes/javax/script/CompiledScript.java Thu Jul 23 14:15:08 2020 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2020, 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
> @@ -42,6 +42,10 @@
>   * @since 1.6
>   */
>  public abstract class CompiledScript {
> +    /**
> +     * Constructor for subclasses to call.
> +     */
> +    public CompiledScript() {}
> 
>      /**
>       * Executes the program stored in this <code>CompiledScript</code> object.
> 

From joe.darcy at oracle.com  Thu Jul 23 22:04:44 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 23 Jul 2020 15:04:44 -0700
Subject: JDK 16 RFR of JDK-8250240: Address use of default constructors in the
 java.util.concurrent
Message-ID: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>

Hello,

Martin, how would you prefer these changes, or equivalent ones, to get 
into the java.util.concurrent upstream sources?

Several classes in java.util.concurrent rely on default constructors, 
which is not recommended.? Please review the patch below which removes 
them along with the corresponding CSR 
(https://bugs.openjdk.java.net/browse/JDK-8250241); webrev at 
http://cr.openjdk.java.net/~darcy/8250240.0/.

Thanks,

-Joe

diff -r d62da6fc4074 
src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
--- 
a/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java 
Thu Jul 23 20:25:41 2020 +0100
+++ 
b/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java 
Thu Jul 23 15:01:27 2020 -0700
@@ -77,6 +77,11 @@
 ?public abstract class AbstractExecutorService implements ExecutorService {

 ???? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public AbstractExecutorService() {}
+
+??? /**
 ????? * Returns a {@code RunnableFuture} for the given runnable and default
 ????? * value.
 ????? *
diff -r d62da6fc4074 
src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
--- a/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java 
Thu Jul 23 20:25:41 2020 +0100
+++ b/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java 
Thu Jul 23 15:01:27 2020 -0700
@@ -242,6 +242,11 @@
 ???? private static final int SIGNAL?? = 1 << 16; // true if joiner waiting
 ???? private static final int SMASK??? = 0xffff;? // short bits for tags

+??? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public ForkJoinTask() {}
+
 ???? static boolean isExceptionalStatus(int s) {? // needed by subclasses
 ???????? return (s & THROWN) != 0;
 ???? }
diff -r d62da6fc4074 
src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
--- 
a/src/java.base/share/classes/java/util/concurrent/RecursiveAction.java 
Thu Jul 23 20:25:41 2020 +0100
+++ 
b/src/java.base/share/classes/java/util/concurrent/RecursiveAction.java 
Thu Jul 23 15:01:27 2020 -0700
@@ -166,6 +166,11 @@
 ???? private static final long serialVersionUID = 5232453952276485070L;

 ???? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public RecursiveAction() {}
+
+??? /**
 ????? * The main computation performed by this task.
 ????? */
 ???? protected abstract void compute();
diff -r d62da6fc4074 
src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
--- 
a/src/java.base/share/classes/java/util/concurrent/RecursiveTask.java 
Thu Jul 23 20:25:41 2020 +0100
+++ 
b/src/java.base/share/classes/java/util/concurrent/RecursiveTask.java 
Thu Jul 23 15:01:27 2020 -0700
@@ -69,6 +69,11 @@
 ???? private static final long serialVersionUID = 5232453952276485270L;

 ???? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public RecursiveTask() {}
+
+??? /**
 ????? * The result of the computation.
 ????? */
 ???? @SuppressWarnings("serial") // Conditionally serializable
diff -r d62da6fc4074 
src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
--- 
a/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java 
Thu Jul 23 20:25:41 2020 +0100
+++ 
b/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java 
Thu Jul 23 15:01:27 2020 -0700
@@ -65,6 +65,11 @@

 ???? private static final long serialVersionUID = 7373984972572414692L;

+??? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public AbstractQueuedLongSynchronizer() {}
+
 ???? /*
 ????? * To keep sources in sync, the remainder of this source file is
 ????? * exactly cloned from AbstractQueuedSynchronizer, replacing class


From Lance.Andersen at oracle.com  Thu Jul 23 22:43:08 2020
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Jul 2020 18:43:08 -0400
Subject: JDK 16 RFR of JDK-8250240: Address use of default constructors in
 the java.util.concurrent
In-Reply-To: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
References: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
Message-ID: <67D22025-F8B2-4802-9C2C-73F8682424D7@oracle.com>

+1

--

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com

Sent from my iPhone

> On Jul 23, 2020, at 6:04 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> ?Hello,
> 
> Martin, how would you prefer these changes, or equivalent ones, to get into the java.util.concurrent upstream sources?
> 
> Several classes in java.util.concurrent rely on default constructors, which is not recommended.  Please review the patch below which removes them along with the corresponding CSR (https://bugs.openjdk.java.net/browse/JDK-8250241); webrev at http://cr.openjdk.java.net/~darcy/8250240.0/.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d62da6fc4074 src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
> --- a/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java Thu Jul 23 15:01:27 2020 -0700
> @@ -77,6 +77,11 @@
>  public abstract class AbstractExecutorService implements ExecutorService {
> 
>      /**
> +     * Constructor for subclasses to call.
> +     */
> +    public AbstractExecutorService() {}
> +
> +    /**
>       * Returns a {@code RunnableFuture} for the given runnable and default
>       * value.
>       *
> diff -r d62da6fc4074 src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
> --- a/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java Thu Jul 23 15:01:27 2020 -0700
> @@ -242,6 +242,11 @@
>      private static final int SIGNAL   = 1 << 16; // true if joiner waiting
>      private static final int SMASK    = 0xffff;  // short bits for tags
> 
> +    /**
> +     * Constructor for subclasses to call.
> +     */
> +    public ForkJoinTask() {}
> +
>      static boolean isExceptionalStatus(int s) {  // needed by subclasses
>          return (s & THROWN) != 0;
>      }
> diff -r d62da6fc4074 src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
> --- a/src/java.base/share/classes/java/util/concurrent/RecursiveAction.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.base/share/classes/java/util/concurrent/RecursiveAction.java Thu Jul 23 15:01:27 2020 -0700
> @@ -166,6 +166,11 @@
>      private static final long serialVersionUID = 5232453952276485070L;
> 
>      /**
> +     * Constructor for subclasses to call.
> +     */
> +    public RecursiveAction() {}
> +
> +    /**
>       * The main computation performed by this task.
>       */
>      protected abstract void compute();
> diff -r d62da6fc4074 src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
> --- a/src/java.base/share/classes/java/util/concurrent/RecursiveTask.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.base/share/classes/java/util/concurrent/RecursiveTask.java Thu Jul 23 15:01:27 2020 -0700
> @@ -69,6 +69,11 @@
>      private static final long serialVersionUID = 5232453952276485270L;
> 
>      /**
> +     * Constructor for subclasses to call.
> +     */
> +    public RecursiveTask() {}
> +
> +    /**
>       * The result of the computation.
>       */
>      @SuppressWarnings("serial") // Conditionally serializable
> diff -r d62da6fc4074 src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
> --- a/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java Thu Jul 23 15:01:27 2020 -0700
> @@ -65,6 +65,11 @@
> 
>      private static final long serialVersionUID = 7373984972572414692L;
> 
> +    /**
> +     * Constructor for subclasses to call.
> +     */
> +    public AbstractQueuedLongSynchronizer() {}
> +
>      /*
>       * To keep sources in sync, the remainder of this source file is
>       * exactly cloned from AbstractQueuedSynchronizer, replacing class
> 

From david.holmes at oracle.com  Thu Jul 23 22:50:21 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jul 2020 08:50:21 +1000
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <d7ee8055-b964-714f-602d-b04760a3445b@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
 <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>
 <507f8eaf-4f6f-1b07-4ab2-049032f4e729@oracle.com>
 <CA+kOe08ZykW3HB64h78DoUmo9B_LsL147=XnhMo05fo725XJaA@mail.gmail.com>
 <d7ee8055-b964-714f-602d-b04760a3445b@oracle.com>
Message-ID: <3f327e74-3353-83c3-b314-e2dd142c713f@oracle.com>

Still good.

Thanks,
David

On 24/07/2020 12:11 am, Roger Riggs wrote:
> Webrev updated with Martin's suggestion:
> 
> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/
> 
> Thanks, Roger
> 
> 
> On 7/22/20 8:35 PM, Martin Buchholz wrote:
>> Roger: You're absolutely right!? I should have looked.
>>
>> On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs <Roger.Riggs at oracle.com> 
>> wrote:
>>> Hi Martin,
>>>
>>> That's a good idea, but unless I miss your point, there is no Reaper 
>>> class,
>>> only a lambda that is used as to create the Executor for the reaper
>>> thread pool.
>>>
>>> Do you mean to put it before or after lines 91-93?? [1]
>>>
>>> Thanks, Roger
>>>
>>> [1]
>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/src/java.base/share/classes/java/lang/ProcessHandleImpl.java.sdiff.html 
>>>
>>>
>>>
>>> On 7/22/20 8:06 PM, Martin Buchholz wrote:
>>>> Looks good.
>>>>
>>>> I might move the static class preloading into a static method of the
>>>> reaper thread class, to make it clearly the responsibility of the
>>>> reaper thread class to enumerate and pre-load its dependencies.
>>>>
>>>> On Wed, Jul 22, 2020 at 7:59 AM Peter Levart 
>>>> <peter.levart at gmail.com> wrote:
>>>>> Hi Roger,
>>>>>
>>>>>
>>>>> I don't think resolving the ConcurrentHashMap.class ensures
>>>>> initialization of the class. Just loading. But I think CHM is already
>>>>> initialized at that time as it is used in ClassLoader to maintain 
>>>>> class
>>>>> loading locks (per class name).
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>
>>>>> On 7/22/20 4:51 PM, Roger Riggs wrote:
>>>>>> Please review a change to the Process reaper thread initialization to
>>>>>> preemptively
>>>>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
>>>>>> initialized.
>>>>>> ? From the stack overflow failures, it seems that the classes have 
>>>>>> not
>>>>>> been initialized
>>>>>> before they are used during processing the termination of a process.
>>>>>> When the initialization is performed on the smaller reaper stack, it
>>>>>> occasionally
>>>>>> exceeds the available stack.
>>>>>>
>>>>>> As an aid to diagnostics,
>>>>>> -XX:AbortVMOnException=java.lang.StackOverflowError
>>>>>> is added to TestHumongousNonArrayAllocation that has failed
>>>>>> intermittently.
>>>>>> If the problem happens again it will produce an hs_error file with
>>>>>> useful details
>>>>>> and will otherwise not change the test behavior.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
>>>>>>
>>>>>> Issue:
>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8249217
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
> 

From martinrb at google.com  Thu Jul 23 22:57:07 2020
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 23 Jul 2020 15:57:07 -0700
Subject: RFR 8249217: Unexpected StackOverflowError in "process reaper"
 thread still happens
In-Reply-To: <3f327e74-3353-83c3-b314-e2dd142c713f@oracle.com>
References: <1c2693ac-0c79-2a83-1b51-a66a07e56ebc@oracle.com>
 <10c6b504-f8f7-ece9-228a-867e112cfa46@gmail.com>
 <CA+kOe0_EhO5jzMs-Y_HRmhN1cX3bbJyHMGQkQtW6CYTz+egCgw@mail.gmail.com>
 <507f8eaf-4f6f-1b07-4ab2-049032f4e729@oracle.com>
 <CA+kOe08ZykW3HB64h78DoUmo9B_LsL147=XnhMo05fo725XJaA@mail.gmail.com>
 <d7ee8055-b964-714f-602d-b04760a3445b@oracle.com>
 <3f327e74-3353-83c3-b314-e2dd142c713f@oracle.com>
Message-ID: <CA+kOe09c1CooqF0fAJxsJbNmdUf7LUzodKD1iMCKYE2nkgBwxg@mail.gmail.com>

+1

On Thu, Jul 23, 2020 at 3:50 PM David Holmes <david.holmes at oracle.com> wrote:
>
> Still good.
>
> Thanks,
> David
>
> On 24/07/2020 12:11 am, Roger Riggs wrote:
> > Webrev updated with Martin's suggestion:
> >
> > http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/
> >
> > Thanks, Roger
> >
> >
> > On 7/22/20 8:35 PM, Martin Buchholz wrote:
> >> Roger: You're absolutely right!  I should have looked.
> >>
> >> On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs <Roger.Riggs at oracle.com>
> >> wrote:
> >>> Hi Martin,
> >>>
> >>> That's a good idea, but unless I miss your point, there is no Reaper
> >>> class,
> >>> only a lambda that is used as to create the Executor for the reaper
> >>> thread pool.
> >>>
> >>> Do you mean to put it before or after lines 91-93?  [1]
> >>>
> >>> Thanks, Roger
> >>>
> >>> [1]
> >>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/src/java.base/share/classes/java/lang/ProcessHandleImpl.java.sdiff.html
> >>>
> >>>
> >>>
> >>> On 7/22/20 8:06 PM, Martin Buchholz wrote:
> >>>> Looks good.
> >>>>
> >>>> I might move the static class preloading into a static method of the
> >>>> reaper thread class, to make it clearly the responsibility of the
> >>>> reaper thread class to enumerate and pre-load its dependencies.
> >>>>
> >>>> On Wed, Jul 22, 2020 at 7:59 AM Peter Levart
> >>>> <peter.levart at gmail.com> wrote:
> >>>>> Hi Roger,
> >>>>>
> >>>>>
> >>>>> I don't think resolving the ConcurrentHashMap.class ensures
> >>>>> initialization of the class. Just loading. But I think CHM is already
> >>>>> initialized at that time as it is used in ClassLoader to maintain
> >>>>> class
> >>>>> loading locks (per class name).
> >>>>>
> >>>>>
> >>>>> Regards, Peter
> >>>>>
> >>>>>
> >>>>> On 7/22/20 4:51 PM, Roger Riggs wrote:
> >>>>>> Please review a change to the Process reaper thread initialization to
> >>>>>> preemptively
> >>>>>> make sure classes ThreadLocalRandom and ConcurrentHashMap are
> >>>>>> initialized.
> >>>>>>   From the stack overflow failures, it seems that the classes have
> >>>>>> not
> >>>>>> been initialized
> >>>>>> before they are used during processing the termination of a process.
> >>>>>> When the initialization is performed on the smaller reaper stack, it
> >>>>>> occasionally
> >>>>>> exceeds the available stack.
> >>>>>>
> >>>>>> As an aid to diagnostics,
> >>>>>> -XX:AbortVMOnException=java.lang.StackOverflowError
> >>>>>> is added to TestHumongousNonArrayAllocation that has failed
> >>>>>> intermittently.
> >>>>>> If the problem happens again it will produce an hs_error file with
> >>>>>> useful details
> >>>>>> and will otherwise not change the test behavior.
> >>>>>>
> >>>>>> Webrev:
> >>>>>> http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217/
> >>>>>>
> >>>>>> Issue:
> >>>>>>     https://bugs.openjdk.java.net/browse/JDK-8249217
> >>>>>>
> >>>>>> Thanks, Roger
> >>>>>>
> >

From alexander.matveev at oracle.com  Thu Jul 23 23:17:31 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Thu, 23 Jul 2020 16:17:31 -0700
Subject: 8248248: [macos] EmptyFolderPackageTest.java fails
 EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code
In-Reply-To: <7efc8d94-f7d8-9761-1413-cd4f0dd0a47c@oracle.com>
References: <00f2df8d-e1d5-df11-18fe-a86cf88f7699@oracle.com>
 <7efc8d94-f7d8-9761-1413-cd4f0dd0a47c@oracle.com>
Message-ID: <85f8d651-c0ea-c854-4e3c-5665ff605845@oracle.com>

http://cr.openjdk.java.net/~almatvee/8248248/webrev.01/

- Added INFINITE_TIMEOUT instead of -1.
- Fix actually did not work correctly and process never timeout, since 
we were reading process output and wait with timeout never executed, 
since reading output was continue until process terminated. Fix by 
forcing using file for output, since in this case we will wait for 
process before reading output.

Thanks,
Alexander

On 7/20/20 1:49 PM, Alexey Semenyuk wrote:
> Looks good.
>
> Minor suggestion: introduce a constant for infinite timeout and use it 
> instead of "-1".
>
> - Alexey
>
> On 7/20/2020 4:43 PM, alexander.matveev at oracle.com wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> It is not clear why script was hanging for more than 7 minutes which 
>> caused test to timeout. Fixed by limiting script execution time to 3 
>> minutes. Also, EmptyFolderPackageTest was removed from ProblemList.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8248248
>> [2] http://cr.openjdk.java.net/~almatvee/8248248/webrev.00/
>>
>> Thanks,
>> Alexander
>


From alexey.semenyuk at oracle.com  Thu Jul 23 23:39:50 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 23 Jul 2020 19:39:50 -0400
Subject: 8248248: [macos] EmptyFolderPackageTest.java fails
 EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code
In-Reply-To: <85f8d651-c0ea-c854-4e3c-5665ff605845@oracle.com>
References: <00f2df8d-e1d5-df11-18fe-a86cf88f7699@oracle.com>
 <7efc8d94-f7d8-9761-1413-cd4f0dd0a47c@oracle.com>
 <85f8d651-c0ea-c854-4e3c-5665ff605845@oracle.com>
Message-ID: <d932f257-d25f-4ed2-f1d9-207c9f1bf3a7@oracle.com>

Looks good.

- Alexey

On 7/23/2020 7:17 PM, alexander.matveev at oracle.com wrote:
> http://cr.openjdk.java.net/~almatvee/8248248/webrev.01/
>
> - Added INFINITE_TIMEOUT instead of -1.
> - Fix actually did not work correctly and process never timeout, since 
> we were reading process output and wait with timeout never executed, 
> since reading output was continue until process terminated. Fix by 
> forcing using file for output, since in this case we will wait for 
> process before reading output.
>
> Thanks,
> Alexander
>
> On 7/20/20 1:49 PM, Alexey Semenyuk wrote:
>> Looks good.
>>
>> Minor suggestion: introduce a constant for infinite timeout and use 
>> it instead of "-1".
>>
>> - Alexey
>>
>> On 7/20/2020 4:43 PM, alexander.matveev at oracle.com wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> It is not clear why script was hanging for more than 7 minutes which 
>>> caused test to timeout. Fixed by limiting script execution time to 3 
>>> minutes. Also, EmptyFolderPackageTest was removed from ProblemList.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248248
>>> [2] http://cr.openjdk.java.net/~almatvee/8248248/webrev.00/
>>>
>>> Thanks,
>>> Alexander
>>
>


From martinrb at google.com  Fri Jul 24 00:24:39 2020
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 23 Jul 2020 17:24:39 -0700
Subject: JDK 16 RFR of JDK-8250240: Address use of default constructors in
 the java.util.concurrent
In-Reply-To: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
References: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
Message-ID: <CA+kOe08EKxxfvdXauQ7CazZfn23G8AKSEu7K5Faf45JHvgSxBg@mail.gmail.com>

So these are all abstract classes where the constructor can only be
called via super() ?
In which case one would expect the constructors to be protected, not public.
But I'm probably missing some reason why "protected" would not be 100%
compatible.

Historically, we've preferred to put changes in via CVS, but in 2020,
we might prefer you make the change directly in openjdk.
Doug?

On Thu, Jul 23, 2020 at 3:04 PM Joe Darcy <joe.darcy at oracle.com> wrote:
>
> Hello,
>
> Martin, how would you prefer these changes, or equivalent ones, to get
> into the java.util.concurrent upstream sources?
>
> Several classes in java.util.concurrent rely on default constructors,
> which is not recommended.  Please review the patch below which removes
> them along with the corresponding CSR
> (https://bugs.openjdk.java.net/browse/JDK-8250241); webrev at
> http://cr.openjdk.java.net/~darcy/8250240.0/.
>
> Thanks,
>
> -Joe
>
> diff -r d62da6fc4074
> src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
> Thu Jul 23 20:25:41 2020 +0100
> +++
> b/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
> Thu Jul 23 15:01:27 2020 -0700
> @@ -77,6 +77,11 @@
>   public abstract class AbstractExecutorService implements ExecutorService {
>
>       /**
> +     * Constructor for subclasses to call.
> +     */
> +    public AbstractExecutorService() {}
> +
> +    /**
>        * Returns a {@code RunnableFuture} for the given runnable and default
>        * value.
>        *
> diff -r d62da6fc4074
> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
> --- a/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
> Thu Jul 23 20:25:41 2020 +0100
> +++ b/src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
> Thu Jul 23 15:01:27 2020 -0700
> @@ -242,6 +242,11 @@
>       private static final int SIGNAL   = 1 << 16; // true if joiner waiting
>       private static final int SMASK    = 0xffff;  // short bits for tags
>
> +    /**
> +     * Constructor for subclasses to call.
> +     */
> +    public ForkJoinTask() {}
> +
>       static boolean isExceptionalStatus(int s) {  // needed by subclasses
>           return (s & THROWN) != 0;
>       }
> diff -r d62da6fc4074
> src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
> Thu Jul 23 20:25:41 2020 +0100
> +++
> b/src/java.base/share/classes/java/util/concurrent/RecursiveAction.java
> Thu Jul 23 15:01:27 2020 -0700
> @@ -166,6 +166,11 @@
>       private static final long serialVersionUID = 5232453952276485070L;
>
>       /**
> +     * Constructor for subclasses to call.
> +     */
> +    public RecursiveAction() {}
> +
> +    /**
>        * The main computation performed by this task.
>        */
>       protected abstract void compute();
> diff -r d62da6fc4074
> src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
> Thu Jul 23 20:25:41 2020 +0100
> +++
> b/src/java.base/share/classes/java/util/concurrent/RecursiveTask.java
> Thu Jul 23 15:01:27 2020 -0700
> @@ -69,6 +69,11 @@
>       private static final long serialVersionUID = 5232453952276485270L;
>
>       /**
> +     * Constructor for subclasses to call.
> +     */
> +    public RecursiveTask() {}
> +
> +    /**
>        * The result of the computation.
>        */
>       @SuppressWarnings("serial") // Conditionally serializable
> diff -r d62da6fc4074
> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
> Thu Jul 23 20:25:41 2020 +0100
> +++
> b/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
> Thu Jul 23 15:01:27 2020 -0700
> @@ -65,6 +65,11 @@
>
>       private static final long serialVersionUID = 7373984972572414692L;
>
> +    /**
> +     * Constructor for subclasses to call.
> +     */
> +    public AbstractQueuedLongSynchronizer() {}
> +
>       /*
>        * To keep sources in sync, the remainder of this source file is
>        * exactly cloned from AbstractQueuedSynchronizer, replacing class
>

From joe.darcy at oracle.com  Fri Jul 24 00:43:21 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 23 Jul 2020 17:43:21 -0700
Subject: JDK 16 RFR of JDK-8250240: Address use of default constructors in
 the java.util.concurrent
In-Reply-To: <CA+kOe08EKxxfvdXauQ7CazZfn23G8AKSEu7K5Faf45JHvgSxBg@mail.gmail.com>
References: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
 <CA+kOe08EKxxfvdXauQ7CazZfn23G8AKSEu7K5Faf45JHvgSxBg@mail.gmail.com>
Message-ID: <32c0cb9f-4ed0-bc1f-86c2-98ad7e552d45@oracle.com>

Hi Martin,

On 7/23/2020 5:24 PM, Martin Buchholz wrote:
> So these are all abstract classes where the constructor can only be
> called via super() ?

Yep.

> In which case one would expect the constructors to be protected, not public.
> But I'm probably missing some reason why "protected" would not be 100%
> compatible.

It would be compatible (AFAICT), but the current (implicit) default 
constructors are public, since the classes are public, so I made the new 
explicit constructors public.

On the assumption the upstream JDK 166-alpha repo would want to take in 
this change for as many releases as possible, the public constructors 
could be used for earlier release trains too.

> Historically, we've preferred to put changes in via CVS, but in 2020,
> we might prefer you make the change directly in openjdk.
> Doug?
>
I'm happy to make the changes in OpenJDK for JDK 16.

Thanks,

-Joe


From sundararajan.athijegannathan at oracle.com  Fri Jul 24 01:19:25 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 24 Jul 2020 06:49:25 +0530
Subject: JDK 16 RFR of JDK-8250237: Address use of default constructors in
 the javax.script package
In-Reply-To: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>
References: <6b1d6a8b-f689-a564-27c4-84ee3fc692d8@oracle.com>
Message-ID: <165a531a-6c92-e5ad-dd9d-1f0805fad6ff@oracle.com>

Looks good

-Sundar

On 24/07/20 2:54 am, Joe Darcy wrote:
> Hello,
>
> One class in the javax.script package uses a default constructor; 
> please review the patch below and CSR 
> (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with 
> an explicit constructor.
>
> Thanks,
>
> -Joe
>
> diff -r d62da6fc4074 
> src/java.scripting/share/classes/javax/script/CompiledScript.java
> --- 
> a/src/java.scripting/share/classes/javax/script/CompiledScript.java 
> Thu Jul 23 20:25:41 2020 +0100
> +++ 
> b/src/java.scripting/share/classes/javax/script/CompiledScript.java 
> Thu Jul 23 14:15:08 2020 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2020, 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
> @@ -42,6 +42,10 @@
> ? * @since 1.6
> ? */
> ?public abstract class CompiledScript {
> +??? /**
> +???? * Constructor for subclasses to call.
> +???? */
> +??? public CompiledScript() {}
>
> ???? /**
> ????? * Executes the program stored in this 
> <code>CompiledScript</code> object.
>

From martinrb at google.com  Fri Jul 24 02:49:08 2020
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 23 Jul 2020 19:49:08 -0700
Subject: JDK 16 RFR of JDK-8250240: Address use of default constructors in
 the java.util.concurrent
In-Reply-To: <32c0cb9f-4ed0-bc1f-86c2-98ad7e552d45@oracle.com>
References: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
 <CA+kOe08EKxxfvdXauQ7CazZfn23G8AKSEu7K5Faf45JHvgSxBg@mail.gmail.com>
 <32c0cb9f-4ed0-bc1f-86c2-98ad7e552d45@oracle.com>
Message-ID: <CA+kOe09qJamrapRDhHqka6x7pnWWVFKc3cjiqOWhrZFHU3nBMA@mail.gmail.com>

I'm happy with this change whether or not the slightly more evocative
"protected" is used.

On Thu, Jul 23, 2020 at 5:43 PM Joe Darcy <joe.darcy at oracle.com> wrote:
>
> Hi Martin,
>
> On 7/23/2020 5:24 PM, Martin Buchholz wrote:
> > So these are all abstract classes where the constructor can only be
> > called via super() ?
>
> Yep.
>
> > In which case one would expect the constructors to be protected, not public.
> > But I'm probably missing some reason why "protected" would not be 100%
> > compatible.
>
> It would be compatible (AFAICT), but the current (implicit) default
> constructors are public, since the classes are public, so I made the new
> explicit constructors public.
>
> On the assumption the upstream JDK 166-alpha repo would want to take in
> this change for as many releases as possible, the public constructors
> could be used for earlier release trains too.
>
> > Historically, we've preferred to put changes in via CVS, but in 2020,
> > we might prefer you make the change directly in openjdk.
> > Doug?
> >
> I'm happy to make the changes in OpenJDK for JDK 16.
>
> Thanks,
>
> -Joe
>

From david.holmes at oracle.com  Fri Jul 24 03:01:56 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jul 2020 13:01:56 +1000
Subject: RFR(s): Support graceful application termination on Windows
 shutdown/logoff
In-Reply-To: <DM6PR21MB12890934E3B440B16CB962B1F5770@DM6PR21MB1289.namprd21.prod.outlook.com>
References: <DM6PR21MB12890934E3B440B16CB962B1F5770@DM6PR21MB1289.namprd21.prod.outlook.com>
Message-ID: <b1d37679-f376-b9d8-0745-23c4f78ba304@oracle.com>

Hi Nikola,

I'm redirecting this to the core-libs team initially because this is an 
issue that has been raised and discussed considerably in the past 
(possibly with some misunderstanding relating to the WM_ENDSESSION 
event). The core-libs team need to confirm the intended semantics here 
and we (runtime) can then implement whatever is determined to be needed. 
Interaction with the client team for AWT interoperability may also be 
needed.

Thanks,
David

On 24/07/2020 11:47 am, Nikola Grcevski wrote:
> Hello hotspot-runtime-dev,
> 
> After some recent investigation into stale files remaining after Java process terminates
> on Windows shutdown, we noticed that there's missing support for detecting Windows
> shutdown/logoff events for interactive Java applications. Given that Java loads both
> GDI32.dll and USER32.dll, even for console applications, this means that almost all Java
> processes launched on Windows don't run any shutdown hooks at the moment on
> user logoff or system shutdown/restart.
> 
> Since Windows 7, all Windows applications that load (or transitively call) GDI32.dll or USER32.dll
> will not receive the CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT events, but
> instead they will be sent WM_ENDSESSION.
> 
> This is documented in MSDN under the following article:
> 
> https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
> 
> It appears that this issue was logged in JSB at some point, but it was
> made duplicate of another issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8079631
> 
> The behaviour changed going from Windows Vista to Windows 7.
> 
> I've made a proposal patch to address this issue under the following webrev:
> 
> http://cr.openjdk.java.net/~adityam/nikola/wm_endsession_handling/
> 
> At the moment only AWT applications would terminate gracefully on
> shutdown/logoff, because they have support for listening on WM_ENDSESSION.
> There's a bug in the AWT code, it doesn't check for wparam upon receiving the
> event, but it will work in most cases. If this patch is accepted I can submit a
> follow-up patch for AWT to resolve the possible issues.
> 
> Finally, there are third set of events for service processes, for example
> java applications which are started with a Windows Service wrappers. These
> services work with SERVICE_ACCEPT_SHUTDOWN and SERVICE_CONTROL_SHUTDOWN.
> Once the most common case is resolved, I'd like to submit perhaps a follow-up patch
> to support graceful termination of Java as Windows service programs.
> 
> We are working to amend the MSDN documentation for SetConsoleCtrlHandler
> to specify that this behaviour change is also present on server OSs. The documentation only
> mentions the workstation OS flavours at the moment.
> 
> Thanks in advance for reviewing this.
> 
> Nikola Grcevski
> Microsoft
> 

From david.holmes at oracle.com  Fri Jul 24 04:41:28 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jul 2020 14:41:28 +1000
Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate
In-Reply-To: <F353471D-8C42-4A8F-A63A-70CA20FAD98F@oracle.com>
References: <E125A0B6-7FC4-4007-A9C4-7A7DFB86EEE4@oracle.com>
 <8f0baa70-0bc3-caa7-13eb-364c45a466d6@oracle.com>
 <F353471D-8C42-4A8F-A63A-70CA20FAD98F@oracle.com>
Message-ID: <3e54b6b9-d237-bcf8-ddcb-f8821d9a0016@oracle.com>

Hi Kim,

On 22/07/2020 6:04 pm, Kim Barrett wrote:
>> On Apr 8, 2020, at 5:27 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kim,
> 
> Apparently I lost track of these comments and forgot to respond.

Thanks for the follow up - I figured it was all "on hold".

Cheers,
David

> I still won't be sending out a new webrev until some of the other
> discussion gets settled.  There's been some internal discussion, but
> I'm currently waiting on some other folks to have time to chime in.
> 
> Replies to your comments inline below.
> 
>> On 8/04/2020 10:25 am, Kim Barrett wrote:
>>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose
>>> either when replying.]
>>> Please review a new function: java.lang.ref.Reference.refersTo.
>>> This function is needed to test the referent of a Reference object
>>> without artificially extending the lifetime of the referent object, as
>>> may happen when calling Reference.get.  Some garbage collectors
>>> require extending the lifetime of a weak referent when accessed, in
>>> order to maintain collector invariants.  Lifetime extension may occur
>>> with any collector when the Reference is a SoftReference, as calling
>>> get indicates recent access.  This new function also allows testing
>>> the referent of a PhantomReference, which can't be accessed by calling
>>> get.
>>
>> This causes a slight conflict with the documentation for get() which states:
>>
>> "Because the referent of a phantom reference is always inaccessible ..."
>>
>> when the new method obviously accesses it.
> 
> I take that "inaccessible" to mean "inaccessible to the application",
> and refersTo doesn't make the referent accessible to the application.
> 
>>> The new function uses a native method whose implementation is in the
>>> VM so it can use the Access API.  It is the intent that this function
>>> will be intrinsified by optimizing compilers like C2 or graal, but
>>> that hasn't been implemented yet.  Bear that in mind before rushing
>>> off to change existing uses of Reference.get.
>>
>> I assume such intrinsification is intended for JDK 15 as well though, as end users may well rush to change their code!
> 
> Looks like we missed the JDK 15 train.
> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8188055
>>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR)
>>
>> In the specification:
>>
>> * @param   obj is the object to compare with the referenced object, or
>> *          {@code null}.
>>
>> First delete "is", the commone style for @param is just to say "the xxx" or "a yyy?.
> 
> Done locally.
> 
>> Second I suggest:
>>
>> s/the referenced object/this reference object's referent/
> 
> Done locally.
> 
>> In the apinote:
>>
>> * collection cycle.  {@link #refersTo(Object) refersTo} can be used to
>>
>> I suggest:
>>
>> * collection cycle.  The {@link #refersTo(Object) refersTo} method can be used to
>>
>> so we don't start a sentence with a lower-case code-font word.
> 
> Done locally.
> 
>> Also a query in the apinote:
>>
>> * This method returns a strong reference to the referent. This may cause
>> * the garbage collector to treat it as strongly reachable until some later
>>
>> Surely if the method returns a strong reference then the GC _will_ treat it as strongly reachable, not "may? ?
> 
> Something like refersTo is needed because an access using get may
> force some phases of some collectors to treat the referent as strongly
> reachable for some additional period, even if the application
> immediately drops all references to it.  Other collectors may not need
> to do anything of the sort.  And even collectors that do sometimes
> need to do so may not always need to do so.  It's all vaguely
> weasel-worded because there is so much potential variation.
> 
>>> Webrev:
>>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
>>
>> Code changes look good. No comment on the test - I'll leave it to others to analyse that.
> 
> Thanks.
> 

From joe.darcy at oracle.com  Fri Jul 24 05:40:22 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 23 Jul 2020 22:40:22 -0700
Subject: JDK 16 RFR of JDK-8250240: Address use of default constructors in
 the java.util.concurrent
In-Reply-To: <CA+kOe09qJamrapRDhHqka6x7pnWWVFKc3cjiqOWhrZFHU3nBMA@mail.gmail.com>
References: <c3aee1e8-32c0-0329-00ad-c56c5307204e@oracle.com>
 <CA+kOe08EKxxfvdXauQ7CazZfn23G8AKSEu7K5Faf45JHvgSxBg@mail.gmail.com>
 <32c0cb9f-4ed0-bc1f-86c2-98ad7e552d45@oracle.com>
 <CA+kOe09qJamrapRDhHqka6x7pnWWVFKc3cjiqOWhrZFHU3nBMA@mail.gmail.com>
Message-ID: <12c7b5b0-12f2-e49b-ca02-f01099b1e01a@oracle.com>

Hi Martin,

Okay; I'll push with "public", but would be fine if the 166-alpha crew 
want to revisit for "protected".

Thanks for the review,

-Joe

On 7/23/2020 7:49 PM, Martin Buchholz wrote:
> I'm happy with this change whether or not the slightly more evocative
> "protected" is used.
>
> On Thu, Jul 23, 2020 at 5:43 PM Joe Darcy <joe.darcy at oracle.com> wrote:
>>

From volker.simonis at gmail.com  Fri Jul 24 11:32:45 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jul 2020 13:32:45 +0200
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <E8775DB1-A3A7-415E-A703-817436D2A5A0@oracle.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <E8775DB1-A3A7-415E-A703-817436D2A5A0@oracle.com>
Message-ID: <CA+3eh1181K=oni1DuC+uDy1H55yVmbFWt=9-o7yaP7kE--8TAw@mail.gmail.com>

On Thu, Jul 23, 2020 at 9:35 PM Lance Andersen
<lance.andersen at oracle.com> wrote:
>
> Hi Volker,
>
Hi Lance,

thanks for looking at my proposal. Please find my comments inline:

>
> A change such as this I believe would require a JEP to fully define the changes/risks/benefits
>

The change itself is quite small and it doesn't change any default
behaviour at all so I didn't think a JEP will be required.

I've summarized the risks in the JBS isse and my initial mail. The
only risk I see is related to the wrong usage of the ZipEntry in
conjunction with ZipInputStream/ZipOutputStream. These problems
already exist today. They may only be revealed more often if somebody
takes advantage of the proposed feature. But I have to repeat myself:
the proposed feature gives interested parties an option to selectively
use alternative implementations.  It's an "opt-in" feature and we
always have the safe-guard to fall back to the default implementation
(be it the bundled or the system library).

The benefit of being able to compress data at double speed seems to
make this change worthwhile, especially if we take into account that
it won't affect anybody who is not using this feature.

However, if it's the general consensus and  the only way to get this
in, I'll be happy to rewrite all this into a JEP.

> I do have concerns about using multiple implementations for compression/decompression.  From a testing and support perspective, this adds additional burden.  What type of testing matrix are you proposing?
>

I don't think we have to test all (or even various) zlib
implementations as part of the regular OpenJDK testing. I'll be happy
to add some tests which test the (rather trivial) loading and
dispatching mechanism to make sure it works correctly and has no
impact on the default implementation.

Besides that, everybody who chooses to use an alternative
implementation can test this however he likes. One simple possibility
would be to run the "jdk/java/util/zip" and "jdk/jdk/nio/zipfs" JTreg
tests with "vmoptions" set to his favourite implementation (e.g.
"vmoptions:-Dorg.openjdk.zlib.implementation.deflate=super-libz.so").
But that's up to the user. We only make sure the selection mechanism
is working.

We also don't do any special testing today just because the user can
use LD_LIBRARY_PATH/LD_PRELOAD to choose a different zlib version. If
the user does that, it's up to him to make sure that his version
behaves as expected. The feature proposed by me is just a more
convenient and more powerful way for simplifying things which are
already possible today.

> Thought has to be given as to what it would mean to be compatible which could require updates to the compatibility rules for JCK testing.
>

Sorry, but I can't see how this is related to JCK at all. The JDK has
a long history of implementing some of its features by leveraging
native libraries. And it is not uncommon that various native libraries
can be used to implement the same feature. Two examples which pop into
my head immediately are the two font renderers T2K / Freetype and the
Marlin / Pisces graphics renderers. The latter can be controlled with
the system property "-Dsun.java2d.renderer" which is very similar to
what I propose.  The mere fact of having several implementations
doesn't have any impact on JCK testing at all (i.e. there's no T2K or
Pices mode in the TCK). You just certify a default implementation but
give users the option to choose other implementations in cases where
they can be beneficial.

You may argue that all the different implementations I've mentioned in
my previous example are (or have been bundled) with the JDK itself.
But from my point of view that makes no fundamental difference. I
would be happy to add two new zlib implementations to the OpenJDK
sources (and in fact that's how our internal solution is working), but
I think that would be a much more controversial change.

Finally, you are already doing JCK testing today with a JDK which is
dynamically linked against the zlib on the test system but which is in
general different from the zlib version on the system where the JDK
will finally be installed and running and I don't think that has been
a problem until now.

> I am also concerned whether the proposed change adds enough value for the additional complexity (and support burden)  it brings.
>

The support burden is zero. The only change to OpenJDK is to replace
the direct calls into the zlib library by indirect calls through
function pointers. Once these (rather trivial) changes are reviewed
they can live there without being touched for the next twenty years
(much like the current implementation has outlived the last twenty
years without any basic changes :)

I hope the possibility to compress data at double speed will be
appealing to others. For us at Amazon it's definitely worth it :)

> Perhaps a proposal to replace  the current zlib with an alternative might be an easier path forward
>

As I wrote, there's no single library which performs equally well at
compression and decompression. I'll be happy to add new
implementations to OpenJDK but I think that would be a much more
controversial change. Or would you be more supportive to such an
approach compared to this change?

> I believe to move forward some, if not all of the above, including a JEP needs to be further flushed out.
>

I think this topic is by far not that complex to justify a JEP and I
think I've answered all your questions and concerns. However, if you
still insist on getting these answers in a JEP I'll be happy to do so
:)

Thanks again and best regards,
Volker

> Best,
> Lance
>
> On Jul 23, 2020, at 1:18 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> Hi,
>
> can I please get some reviews for the following small enhancement
> which will allow you to configure different zlib implementations at VM
> start-up and get up to 100% better throughput for compression and
> about 50% better throughput for decompression (depending on the
> selected zlib implementation). We're using a similar change
> productively in Amazon since quite a while with good results on
> compression/decompression heavy workloads.
>
> As usual, my write-up is moch longer and much more complex than the
> change itself :)
>
> http://cr.openjdk.java.net/~simonis/webrevs/2020/8249963/
> https://bugs.openjdk.java.net/browse/JDK-8249963
>
> I've tested these changes locally on Linux/Windows/Mac without any
> problems but got a Mach5 build error for Windows after sending them to
> the submit repo (Job:
> mach5-one-simonis-JDK-8249963-20200723-1236-12890347, BuildId:
> 2020-07-23-1235507.volker.simonis.source). Would be great if somebody
> from Oracle could shed some light on that issue.
>
> Thank you and best regards,
> Volker
>
> Following some background, benchmarks and implementation details for the change:
>
> The JDK bundles the original zlib implementation [1] almost from the
> very beginning, starting with zlib 1.0.4 in JDK 1.1. In the meantime,
> the bundled zlib implementation was updated to the latest released
> version 1.2.11. However, the innovation velocity in the original zlib
> version has considerably slowed down in the last years.
>
> Lately, new projects have picked up the original zlib implementation
> and considerably improved its deflate and inflate speed. Testing shows
> that compression throughput can be improved between 50 and 100% with
> Cloudflare's zlib version [2] and decompression throughput between 30
> and 60% using the zlib implementation from the Chromium project [3].
>
> Overview
> --------
>
> This enhancement proposes some simple changes to the JDK's zlib
> wrapper libzip which make it possible to choose alternative zlib
> implementations selectively for deflation and/or inflation at VM
> startup based on a system property. As an additional benefit it makes
> it possible to use the system zlib version even if the JDK was
> configured with a bundled zlib.
>
> Already now, the JDK can be configured at build time to either use the
> bundled zlib version or to dynamically link against the system zlib.
> If linked dynamically, LD_LIBRARY_PATH or LD_PRELOAD can be used to
> run the JDK with an alternative zlib implementation. This approach is
> however not very flexible because:
> - once configured with a "bundled" zlib it's not possible to use
> another implementation any more. Some platforms like Windows don't
> have a default, system provided zlib version so they are always built
> with "--with-zlib=bundled" and therefore can't change the
> implementation at runtime.
> - even if configured with "--with-zlib=system", it is only possible a
> single alternative version as a substitute for the system zlib. But
> we've found (see benchmarks [4]) that there's no single zlib
> implementation which improves both compression and decompression
> equally well. It may therefore make sense to have the possibility to
> selectively use one implementation for compression and another one for
> decompression.
>
> This enhancement proposes three new system properties:
>
> org.openjdk.zlib.implementation
> org.openjdk.zlib.implementation.inflate
> org.openjdk.zlib.implementation.deflate
>
> which can be used to either replace the full zlib functionality or
> selectively just the deflate or inflate part with a new
> implementation. As an argument they take an absolute or relative path
> to an API-compatible, shared zlib library. E.g.
>
> -Dorg.openjdk.zlib.implementation=zlib-cloudflare.so
> -Dorg.openjdk.zlib.implementation.deflate=/Git/zlib-bench/lib/x86_64/zlib-cloudflare.dylib
> -Dorg.openjdk.zlib.implementation.inflate='D:\Git\zlib-bench\lib\x86_64\zlib-chromium.dll`
>
> An argument with the value "system" can be used to instruct the JDK to
> load the default zlib version on the corresponding system. Notice that
> this option now also works in the case where the JDK was configured
> with a bundled zlib.
>
> The naming of the properties is of course subject to discussion. If we
> get an agreement on this change and the naming, I'll be happy to open
> a CSR for the introduction of the new properties.
>
> For testing purpose I've made some precompiled version of
> zlib-cloudflare and zlib-chromium for Linux/x86_64, Linux/aarch64,
> MacOS/x86_64 and Windows/x86_64 available in my GitHub repository [6].
>
> The implementation of this whole enhancement is fairly simple. Instead
> of calling right into zlib from libzip I've replaced all direct calls
> by indirect calls through function pointers. By default, these
> function pointers are pointing either to the corresponding functions
> in the bundled zlib implementation or to the corresponding functions
> in the dynamically linked system zlib. If none of the above system
> properties will be used, the only change to the current implementation
> is the replacement of some direct calls by indirect calls. Because
> these function calls are usually made through JNI and because the
> underlying code is usually quite compute intensive, I couldn't measure
> any performance regression because of this change.
>
> If one of the above system properties will be set, the selected shared
> library will be dynamically loaded and the corresponding function
> pointers will be redirected to point to the new implementation. I have
> verified that this works on Linux, Windows and Mac OS X. You can find
> some more implementation details at the end of this write-up.
>
> Benchmarks
> ----------
>
> I've run native benchmarks to compare the compression/decompression
> throughput and the compression ratio at various compression levels for
> zlib-adler [7], zlib-chromium [8], zlib-ng [9], zlib-ipp [10],
> zlib-cloudflare [11] and the isa-l [12] library. The results and more
> details can be found in my zlib-bench GitHub repository [5].
>
> After that I've used precompiled versions of zlib-cloudflare,
> zlib-chromium and the changes proposed by this enhancement to rerun
> these benchmarks in Java on Linux/x86_64 and Linux/aarch64. I think
> the results are quite impressive [4] showing around 100% higher
> throughput for compression and around 50% higher throughput for
> decompression on both architectures.
>
> Implementation details
> ----------------------
>
> Before change "8237750: Load libzip.so only if necessary" [13] libzip
> (and transitively libz) was loaded early at VM startup in
> "init_globals() -> ClassLoader::initialize()". For this change I've
> re-enabled this early loading if and only if one of the new system
> properties was given on the command line. I think these new properties
> will only be used if heavy compression/decompression usage is expected
> and in such a case it doesn't harm to load libzip early at startup.
> Loading libzip later and on demand would otherwise make the
> synchronization of the function pointer initialization unnecessary
> hard because libzip can be loaded independently from the VM as well as
> from the class library.
>
> An alternative approach would be to use __attribute(constructor) (on
> Linux) or DLLMain() (on Windows) to perform the function pointer
> initialization once when libzip gets loaded. But first, this approach
> is quite system dependent and I'm not sure it is available on all
> platforms (I'm pretty sure it doesn't work on AIX :). Second, I think
> it is not possible to dynamically load DLLs from DLLMain() on Windows
> which would be required in this case.
>
> A third possibility would be to define a JNI OnLoad function for
> libzip. But unfortunately, libzip can not only be loaded from
> java.util.zip where we have a JNIEnv but also from HotSpot or directly
> with dlopen() from libjimage.
>
> I've also removed the following, OpenJDK-specific patch to "zconf.h"
> in the bundled zlib version which seems to have been there "since
> ever" but which I don't think is required any more:
>
> src/java.base/share/native/libzip/zlib/zconf.h
> -#ifdef _LP64
> -typedef unsigned int  uLong;  /* 32 bits or more */
> -#else
> typedef unsigned long  uLong; /* 32 bits or more */
> -#endif
>
> The change is needed to make the bundled zlib compatible with the
> system or the other zlib implementations which all do not have this
> change. Notice that if we're building with the system zlib, we are
> already using this setting today because in that case "zconf.h" is
> taken from the system include path.
>
> Finally, it has to be noticed that although we are loading libzip
> early there are still two call sites of zlib functionality which won't
> be able to benefit from the new implementations because they either
> statically link in parts of the bundled zlib version or directly and
> dynamically link against the system zlib version. That's
> libsplashscreen and libjli. Both are only used at startup and both
> only make limited use of zlib (if they use it at all) so I don't think
> that they are relevant.
>
> Risks
> -----
>
> Unfortunately ZipInputStream/ZipOutputStream have been designed such
> that it is very easy to use them in an unsupported way. It is in
> general not possible to read a ZipEntry from a ZipInputStream and
> write that exact ZipEntry into a ZipOutputStream followed by the
> inflated and re-deflated data of that entry. However this naive
> approach is sometimes used to copy zip entries from a zip input file
> into another zip output file. This approach will only work in the case
> where the exact same deflate implementation and compression was used
> for the initial compression like for the recompression.
>
> This is because the ZipEntry will contain the compressed size of the
> data belonging to that entry. But the Deflate format doesn't mandate a
> specific, fixed compression algorithm which will always result in the
> same compressed size. Instead, different implementations are free to
> use different approaches for compression which can result in valid
> entries but potentially with a different compressed size.
>
> Actually, even if just a single implementation is used for both
> compression and decompression, it is still not possible to detect the
> compression level from the compressed data. It is  therefore possible
> that decompressing and re-compressing that data into a ZipOutputStream
> will result in a different compressed size. However, ZipOutputStream
> will throw an exception if the compressed size entry in a ZipEntry is
> different from the actual size of the compressed data.
>
> I've recently fixed two such cases in the OpenJDK (JDK-8240333 [14],
> JDK-8240235 [15]) itself, but there may be other such use cases in the
> wild which may throw an "ZipException: invalid entry compressed size
> (expected 66 but got 67 bytes)". If that happens, the user can either
> fix his code (which is trivial and advised because of the problems
> explained before) or simply remove the new system properties in order
> to fall back to the bundled or system implementation.
>
> [1] https://www.zlib.net/
> [2] https://github.com/cloudflare/zlib
> [3] https://chromium.googlesource.com/chromium/src/third_party/zlib/
> [4] https://github.com/simonis/zlib-bench/blob/master/Results-ojdk.md
> [5] https://github.com/simonis/zlib-bench/blob/master/Results.md
> [6] https://github.com/simonis/zlib-bench/tree/master/lib
> [7] https://github.com/madler/zlib
> [8] https://chromium.googlesource.com/chromium/src/third_party/zlib/
> [9] https://github.com/zlib-ng/zlib-ng
> [10] https://software.intel.com/en-us/articles/intel-ipp-zlib-coding-functions
> [11] https://github.com/cloudflare/zlib
> [12] https://github.com/intel/isa-l
> [13] https://bugs.openjdk.java.net/browse/JDK-8237750
> [14] https://bugs.openjdk.java.net/browse/JDK-8240333
> [15] https://bugs.openjdk.java.net/browse/JDK-8240235
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>

From volker.simonis at gmail.com  Fri Jul 24 11:48:39 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jul 2020 13:48:39 +0200
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
Message-ID: <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>

On Thu, Jul 23, 2020 at 8:48 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 23/07/2020 18:18, Volker Simonis wrote:
> > Hi,
> >

Hi Alan,

thanks for promptly looking into my proposal. Please find my answers inline:

> > can I please get some reviews for the following small enhancement
> > which will allow you to configure different zlib implementations at VM
> > start-up and get up to 100% better throughput for compression and
> > about 50% better throughput for decompression (depending on the
> > selected zlib implementation). We're using a similar change
> > productively in Amazon since quite a while with good results on
> > compression/decompression heavy workloads.
> >
> > As usual, my write-up is moch longer and much more complex than the
> > change itself :)
> Yes, this needs discussion and agreement before starting an RFR.

That's why we're here :) I'm happy to discuss all your concerns. But I
don't think it does any harm to have a working implementation and
detailed benchmark data as a basis for such a discussion :)

> As you've summarized in the JIRA issue, we have configure
> --with-zlib=system and --with-zlib=bundled today. The former is the way
> to build when what to make it possible to use an alternative zlib.  The
> new requirement that I think you are brining up is the case where
> someone wants to use several zlib libraries at the same time, because
> they somehow know that one version has superior performance than the
> other on some functions.

That's true. And in addition it allows always choosing an alternative
(e.g. the system) version even if the JDK was configured with a
"bundled" zlib. That's not possible today and from my point of view
already worth this change alone.

> I think it's reasonable to ask if the JDK
> really needs to support this complexity.

I can't see much complexity here. If you look at the change you'll see
that it's rather trivial. All it does is substituting some direct
calls into the zlib library by indirect calls through
function pointers.

> I could imagine testing or
> support folks in tears when they see the implications of this. Have you

I don't see any implications for testing here. Please see my answer to
Lance's mail for more details.

> looked at alternatives that would benefit other users of zlib, e.g. an
> interposer that dispatches to the appropriate zlib based on configuration?

But that's exactly what I've implemented - a simple interposer which
dispatches between various zlib implemations. It's pretty simple and
convenient to use because of the fact that a lot of alternative, but
fully API-cpmatible zlib implementations already exist today. I don't
want to create and maintain a new, native library. I just want to
enable users to leverage the existing ones.

Best regards,
Volker

>
> -Alan
>

From andy.herrick at oracle.com  Fri Jul 24 12:11:22 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 24 Jul 2020 08:11:22 -0400
Subject: 8248248: [macos] EmptyFolderPackageTest.java fails
 EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code
In-Reply-To: <85f8d651-c0ea-c854-4e3c-5665ff605845@oracle.com>
References: <00f2df8d-e1d5-df11-18fe-a86cf88f7699@oracle.com>
 <7efc8d94-f7d8-9761-1413-cd4f0dd0a47c@oracle.com>
 <85f8d651-c0ea-c854-4e3c-5665ff605845@oracle.com>
Message-ID: <b9dd843c-71d6-4c35-6aad-b29d3bab531a@oracle.com>

looks good.

/Andy

On 7/23/2020 7:17 PM, alexander.matveev at oracle.com wrote:
> http://cr.openjdk.java.net/~almatvee/8248248/webrev.01/
>
> - Added INFINITE_TIMEOUT instead of -1.
> - Fix actually did not work correctly and process never timeout, since 
> we were reading process output and wait with timeout never executed, 
> since reading output was continue until process terminated. Fix by 
> forcing using file for output, since in this case we will wait for 
> process before reading output.
>
> Thanks,
> Alexander
>
> On 7/20/20 1:49 PM, Alexey Semenyuk wrote:
>> Looks good.
>>
>> Minor suggestion: introduce a constant for infinite timeout and use 
>> it instead of "-1".
>>
>> - Alexey
>>
>> On 7/20/2020 4:43 PM, alexander.matveev at oracle.com wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> It is not clear why script was hanging for more than 7 minutes which 
>>> caused test to timeout. Fixed by limiting script execution time to 3 
>>> minutes. Also, EmptyFolderPackageTest was removed from ProblemList.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248248
>>> [2] http://cr.openjdk.java.net/~almatvee/8248248/webrev.00/
>>>
>>> Thanks,
>>> Alexander
>>
>

From Alan.Bateman at oracle.com  Fri Jul 24 12:15:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Jul 2020 13:15:46 +0100
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
 <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
Message-ID: <699d27a4-351c-add5-ef6d-f732cfc06bf6@oracle.com>


On 24/07/2020 12:48, Volker Simonis wrote:
> :
>
> I can't see much complexity here. If you look at the change you'll see
> that it's rather trivial. All it does is substituting some direct
> calls into the zlib library by indirect calls through
> function pointers.
>
I don't think the JDK should be in the business of loading several 
versions of zlib at the same time and using some functions from one 
version, and some functions from another. Have you explored solutions 
that don't burden the JDK? Has there been any attempt to bring the 
performance improvements from the different sources into one build as 
that seems to be what you are really looking for.

I would expect most/all of the Linux distributions to configure 
--with-zlib=system as they don't want a zlib in the JDK run-time image. 
So it might be unusual to build with --with-zlib=bundled and then expect 
to be able to use an alternative zlib. There was a good discussion on 
this topic on build-dev in 2016 as there was interest from Intel 
engineers at the time to be able to use their accelerated library.

Separately, I think it would be useful to explore some of the examples 
to see if they make use of the Vector API or if there are opportunities 
to do pure Java implementations that would benefit from the runtime 
compilers.

-Alan

From aleksei.voitylov at bell-sw.com  Fri Jul 24 12:36:39 2020
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Fri, 24 Jul 2020 15:36:39 +0300
Subject: RFR: JDK-8248239: jpackage adds some arguments twice in case it
 is re-executed by JLI
In-Reply-To: <dff41f8f-fdd2-d99f-c292-fb6003ce06fd@oracle.com>
References: <c95dc5a8-650a-2bdf-0225-1d902ab8ae5f@bell-sw.com>
 <6d4fabe6-37ce-7d1d-bf7d-e2b07e0ba92b@oracle.com>
 <f59c4014-6d2f-9c2a-4846-d3e41991a9e4@bell-sw.com>
 <e0bb7682-ac03-6958-cb35-ada96ab5583f@oracle.com>
 <6f2ae108-0c11-4294-7ff0-f7a975a0a8c3@bell-sw.com>
 <dff41f8f-fdd2-d99f-c292-fb6003ce06fd@oracle.com>
Message-ID: <4093330f-214f-0c2a-513b-a94997881c31@bell-sw.com>

Thanks Alexey for the review!

Unless we need another review, would you sponsor the change?

Thanks,

-Aleksei

On 21/07/2020 21:27, Alexey Semenyuk wrote:
> Hi Aleksei,
>
> Looks good!
>
> - Alexey
>
> On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
>> Hi,
>>
>> This is the updated fix which checks if LD_LIBRARY_PATH has been changed
>> during jpackage executions:
>>
>> http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
>>
>> The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
>> variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
>> algorithm is used because standard C++ hash requires -std=c++11 or
>> -std=gnu++11 compiler options.
>>
>> All test/jdk/tools/jpackage tests but ModulePathTest3.java pass on Linux
>> x86_64, MacOSX x86_64, and Windows x86_64. The test ModulePathTest3.java
>> is excluded in test/jdk/ProblemList.txt (8248418 generic-all).
>>
>> Thanks,
>>
>> -Aleksei
>>
>> On 26/06/2020 20:23, Alexey Semenyuk wrote:
>>> Hi Aleksei,
>>>
>>> I think the idea of partial reading data from cfg file when the
>>> launcher is restarted has a flaw.
>>> It would be better if app launcher can detect if it was restarted and
>>> if it was, not read cfg file at all, but pass command line arguments
>>> as is in JLI_Launch().
>>> Let my think on ideas how to address this.
>>>
>>> - Alexey
>>>
>>> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>>>> Hi Alexey,
>>>>
>>>> Thank you for looking into it. As far as using parent pid, it does not
>>>> seem to work as example [1] demonstrates. The parent process
>>>> remains the
>>>> same after re-execution and does not become the current process.
>>>>
>>>> I checked passing arguments in the "ArgOption" section using several
>>>> cases [2, 3, 4] with the proposed fix and app re-execution. The
>>>> proposed
>>>> fix handles this case well, and the results are the same as without
>>>> the
>>>> fix when the app is not re-executed.
>>>>
>>>> Case [3] where only JavaOptions without ArgOptions are passed to app
>>>> looks suspicious because default ArgOptions are not used. But it works
>>>> the same way without the proposed fix, which seems like a different
>>>> issue. According to jpackage documentation:
>>>>
>>>> ??? --arguments main class arguments
>>>> ????????? Command line arguments to pass to the main class if no
>>>> command
>>>> line arguments are given to the launcher.
>>>>
>>>> I filed a separate issue [5] to handle that.
>>>>
>>>> Thanks,
>>>> -Aleksei
>>>>
>>>>
>>>> [1]
>>>> cd jdk-dev
>>>> make jdk-image
>>>> export PATH=build/linux-x86_64-server-release/images/jdk/bin:$PATH
>>>> export
>>>> LD_LIBRARY_PATH=build/linux-x86_64-server-release/images/jdk/lib/server
>>>>
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --verbose --java-options -Dparam1=Param1
>>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>>> -------------
>>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>>> pid: 15927, parent? process: /bin/bash
>>>> JvmLauncher args: 10 [/home/sample/jdk-dev/output/app/bin/app
>>>> -Dparam1=Param1 --module-path
>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>>> pid: 15927, parent? process: /bin/bash
>>>> JvmLauncher args: 15 [/home/sample/jdk-dev/output/app/bin/app
>>>> -Dparam1=Param1 --module-path
>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>> com.hello/com.hello.Hello -Dparam1=Param1 --module-path
>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>>> -------------
>>>>
>>>> [2]
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --java-options -Dparam1=Param1
>>>> ./output/app/bin/app
>>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>>
>>>> [3]
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --java-options -Dparam1=Param1
>>>> ./output/app/bin/app -Dparam2=Param2
>>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>>>
>>>> [4]
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --java-options -Dparam1=Param1
>>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>>> B2 B ]
>>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>>> B2 B ]
>>>>
>>>> [5] https://bugs.openjdk.java.net/browse/JDK-8248397
>>>>
>>>>
>>>> On 24/06/2020 19:34, Alexey Semenyuk wrote:
>>>>> Aleksei,
>>>>>
>>>>> If I get it right, the fix would not work for the case when there are
>>>>> `arguments` properties in `ArgOptions` section of a config file.
>>>>> Why not just check if the parent process is the same executable as
>>>>> the
>>>>> current one and if this is the case don't read data from the config
>>>>> file but pass executable arguments as is in JLI_Launch() call?
>>>>>
>>>>> - Alexey
>>>>>
>>>>> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> There are systems that update LD_LIBRARY_PATH or directly return
>>>>>> JNI_TRUE in method RequiresSetenv(const char *jvmpath) from
>>>>>> java_md.c
>>>>>> file to request re-execution of the current executable. This
>>>>>> leads to
>>>>>> the fact that jpackage application adds some provided arguments
>>>>>> twice.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
>>>>>> Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
>>>>>>
>>>>>> The root cause of the issue is that jpackage application expects one
>>>>>> number of arguments but JLI reexecutes them with another number of
>>>>>> arguments.
>>>>>> ??? For example, a jpackage application can be run with arguments:
>>>>>> ?????? ./app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>> it adds arguments from the config file and calls JLI with arguments:
>>>>>> ?????? app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello
>>>>>> -Dparam2=Param2 B1 B2 B3
>>>>>> JLI re-executes the app with new arguments so the app adds some
>>>>>> arguments one more time after the re-execution.
>>>>>> ?????? ./app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
>>>>>>
>>>>>> A step by step example that illustrates the issue:
>>>>>>
>>>>>> Run jpackage to create an executable application:
>>>>>> ???? jpackage --dest output --name app --type app-image
>>>>>> --module-path
>>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A1 A2
>>>>>> A3"
>>>>>> --verbose --java-options -Dparam1=Param1
>>>>>>
>>>>>> Executable application with the app/lib/app/app.cfg config file is
>>>>>> created:
>>>>>> ---- app.cfg? ----
>>>>>> [Application]
>>>>>> app.name=app
>>>>>> app.version=1.0
>>>>>> app.runtime=$ROOTDIR/lib/runtime
>>>>>> app.identifier=com.hello
>>>>>> app.classpath=
>>>>>> app.mainmodule=com.hello/com.hello.Hello
>>>>>>
>>>>>> [JavaOptions]
>>>>>> java-options=-Dparam1=Param1
>>>>>>
>>>>>> [ArgOptions]
>>>>>> arguments=A1
>>>>>> arguments=A2
>>>>>> arguments=A3
>>>>>> -----------
>>>>>>
>>>>>> Run the application:
>>>>>> ????? ./output/app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>>
>>>>>> Chain of JDK methods execution:
>>>>>>
>>>>>> LinuxLauncher main()
>>>>>> ????? args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
>>>>>> AppLauncher createJvmLauncher()
>>>>>> ????? args: 4 [-Dparam2=Param2 B1 B2 B3 ]
>>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>>> app.cfg
>>>>>> ????? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>> AppLauncher Jvm::launch() -? JLI re-executes the app
>>>>>> LinuxLauncher main()
>>>>>> ???? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>> AppLauncher createJvmLauncher()
>>>>>> ????? args: 9 [-classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello
>>>>>> -Dparam2=Param2 B1 B2 B3 ]
>>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>>> app.cfg
>>>>>> ????? args: 15 [./app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>> ?????? ^^^
>>>>>>
>>>>>> Some arguments like "-classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello" are added twice.
>>>>>>
>>>>>> Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
>>>>>> regressions on Linux, Windows, Mac. On systems affected, the tests
>>>>>> now pass.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Aleksei
>>>>>>
>>>>>>
>


From volker.simonis at gmail.com  Fri Jul 24 14:47:14 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Jul 2020 16:47:14 +0200
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <699d27a4-351c-add5-ef6d-f732cfc06bf6@oracle.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
 <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
 <699d27a4-351c-add5-ef6d-f732cfc06bf6@oracle.com>
Message-ID: <CA+3eh12odB8-QxKoqJV-R9U4+qJVOFxsb_LpGdCk2D0x-1b7yA@mail.gmail.com>

On Fri, Jul 24, 2020 at 2:15 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>
> On 24/07/2020 12:48, Volker Simonis wrote:
> > :
> >
> > I can't see much complexity here. If you look at the change you'll see
> > that it's rather trivial. All it does is substituting some direct
> > calls into the zlib library by indirect calls through
> > function pointers.
> >
> I don't think the JDK should be in the business of loading several
> versions of zlib at the same time and using some functions from one
> version, and some functions from another. Have you explored solutions
> that don't burden the JDK? Has there been any attempt to bring the
> performance improvements from the different sources into one build as
> that seems to be what you are really looking for.
>

I really don't want to maintain yet another native zlib clone or a
merge of existing ones. There are plenty of them available with their
own strengths and weaknesses. I only want to make it easy and
convenient for everybody to consume them from the JDK. The whole
proposal is really just a simpler, more standard (because system
independant) and more powerful way of using LD_LIBRAY_PATH.
Additionally, it gives you the choice to use an alternative
implementation even on platforms like Windows where we currently can't
link dynamically because a default system version doesn't exist.

Until now I'm only hearing mostly high-level ,theoretical arguments
against the proposal rather than technical objections. Why are you so
strictly against providing this additional choice to users which comes
at almost zero costs for the JDK?

> I would expect most/all of the Linux distributions to configure
> --with-zlib=system as they don't want a zlib in the JDK run-time image.
> So it might be unusual to build with --with-zlib=bundled and then expect
> to be able to use an alternative zlib. There was a good discussion on
> this topic on build-dev in 2016 as there was interest from Intel
> engineers at the time to be able to use their accelerated library.
>

Yes, I know that discussion [1] and the previous one from Sandhya in
2015 [2] as well. The latter was a similar, but much more limited idea
compared to my solution. It prosed an option/property to switch
between the bundled and the system version at startup. The former was
merely about changing the build default from "bundled" to "system" on
Linux/Solaris. During that discussion, concerns were raised and
finally disregarded that dynamic linking might introduce unpredictable
risks compared to the bundled solution.

I think my proposal is really combining and extending all the requests
and concerns of the previous discussions in an ideal way by offering
maximum flexibility paired with the ability of a safe fall-back at
virtually no costs.

[1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/thread.html#38649
[2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/thread.html#32106

> Separately, I think it would be useful to explore some of the examples
> to see if they make use of the Vector API or if there are opportunities
> to do pure Java implementations that would benefit from the runtime
> compilers.
>

I've briefly looked into the alternative implementations and they all
make use of vector instructions, assembler coding and optimizations
like manual loop unrolling etc. Most of these optimizations are
currently hard to realize in a bundled, native version because we
don't have a framework in the class library for dynamically checking
CPU features. Implementing Inflation/Deflation in pure Java would
surely be an interesting project but from my point of view not very
realistic in the foreseeable future (I remember you were already
throwing in similar ideas in the 2016 discussion mentioned above :)

Best regards,
Volker

> -Alan

From sgehwolf at redhat.com  Fri Jul 24 16:13:49 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 24 Jul 2020 18:13:49 +0200
Subject: No way to disable Java Container Metrics
Message-ID: <be6ec1f41119684cb9e6eb9acf1f85163c6489b6.camel@redhat.com>

Hi,

For hotspot one can disable container detection with a simple switch:

$ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
[0.000s][trace][os,container] OSContainer::init: Initializing Container Support
[0.000s][trace][os,container] Container Support not enabled
openjdk version "15-internal" 2020-09-15
OpenJDK Runtime Environment (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2)
OpenJDK 64-Bit Server VM (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)

The same cannot be achieved with the Java code,
jdk.internal.platform.Metrics.java and friends in the JDK. At the time
Metrics were added the only consumer of them was the Java Launcher via
-XshowSettings:system. This has changed with JDK-8226575:
OperatingSystemMXBean should be made container aware.

It is known that in certain cases the container detection code will
detect for a system to be supposedly in a container where it actually
isn't:
https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604

For hotspot there is a flag, to turn auto-detection off for exactly the
case when heuristics are wrong: -XX:-UseContainerSupport. However, this
flag has no effect on the Java metrics code. There is a risk that on
some systems the auto-detection will be wrong and might cause
regressions.

I propose to make the Java metrics code adhere to -XX:+/-
UseContainerSupport flag. Do you think this would be useful? If yes,
I'll file a bug and propose a patch for it.

Thoughts? Opinions?

Thanks,
Severin


From brian.burkhalter at oracle.com  Fri Jul 24 18:38:38 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 24 Jul 2020 11:38:38 -0700
Subject: [15] 8235792: LineNumberReader.getLineNumber() behavior is
 inconsistent with respect to EOF
In-Reply-To: <892E385E-6744-44DB-B2E3-ABDCCA18BBDD@oracle.com>
References: <78944404-e2c3-a1cb-5809-967d99282b10@gmail.com>
 <892E385E-6744-44DB-B2E3-ABDCCA18BBDD@oracle.com>
Message-ID: <72F3F0F9-2F98-433B-AE8F-BBB59C26FA55@oracle.com>

The CSR [1] has been updated as described below.

Thanks,

Brian

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

> On Jul 22, 2020, at 11:36 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Yes, I think that the sentence
> 
> +     * <a href="#lt">Line terminators</a> are compressed into single newline
> +     * ('\n') characters.
> 
> should be added to the specs of read(char[],int,int) and readLine(), or some equivalent statement be added to the class level doc.
> 
>> Besides, the JDK 14 API states that the invocation
>> "Returns:
>> The number of *bytes* read, or -1 if the end of the stream has already been reached"
>> 
>> I think it should say "characters" rather than "bytes" but perhaps this has already been corrected.
> 
> No, it has not been correct and I agree that it should be ?characters,? not ?bytes.?


From mik3hall at gmail.com  Fri Jul 24 18:55:55 2020
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 24 Jul 2020 13:55:55 -0500
Subject: OS X jpackage exception FYI
Message-ID: <FBA38A66-CD97-4A99-9ACF-24AD71E214C4@gmail.com>

Doesn?t appear to be causing any problems to the application build?

WARNING: Using incubator modules: jdk.incubator.jpackage
14.0.2

Running [/usr/bin/SetFile, -c, icnC, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15486534363011883928/images/FastRGraalHP/.VolumeIcon.icns]
Running [/usr/bin/SetFile, -a, C, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15486534363011883928/images/FastRGraalHP]
Running [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15486534363011883928/config/FastRGraalHP-dmg-setup.scpt]
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15486534363011883928/config/FastRGraalHP-dmg-setup.scpt:57:61: execution error: Finder got an error: Can?t get disk "FastRGraalHP". (-1728)
java.io.IOException: Command [osascript, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage15486534363011883928/config/FastRGraalHP-dmg-setup.scpt] exited with 1 code
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:348)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:75)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:451)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:641)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97)
	at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51)

Command issued:

${PACKAGER} \
	--verbose \
	--input ../HalfPipe12.app/Contents/Java \
	--icon GenericApp.icns \
	--install-dir outputdir \
	--name FastRGraalHP \
	--main-jar halfpipe.jar \
	--main-class us.hall.hp.common.LoaderLaunchStub \
	--runtime-image /Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.1.0-dev/Contents/Home \
	--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -Djava.security.policy=$APPDIR/all.policy -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe -Dconsole=pane' \
	--mac-package-identifier us.hall.FastRGraalHP


From bob.vandette at oracle.com  Fri Jul 24 19:21:29 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 24 Jul 2020 15:21:29 -0400
Subject: No way to disable Java Container Metrics
In-Reply-To: <be6ec1f41119684cb9e6eb9acf1f85163c6489b6.camel@redhat.com>
References: <be6ec1f41119684cb9e6eb9acf1f85163c6489b6.camel@redhat.com>
Message-ID: <BBD758E1-6157-4144-86D7-A274D26702E3@oracle.com>

I?ve been monitoring the discussion on your jdk8u alias and I can?t help wondering if
my original decision to provide two different implementations of this container detection
logic was the best way to go.

I didn?t want to have an all Java implementation since the VM needs to initialize it?s
memory and cpu sizing very early on prior to its ability to run Java code.

If we put all of the logic in the VM, then we?d end up with a pretty wide interface to
the VM and more overhead extracting values (due to JNI) although the Java logic 
typically ends up in native code anyway.  Having the functionality in the VM
makes it easier to add JFR events.  Having a pure Java implementation makes it
easier to support the OS MBeans.  The maintenance of supporting both implementations
is a bit of a pain.

Assuming no one has the time or desire to migrate the logic to the VM and provide
Java wrapper logic, I?m ok with what you are proposing.  It?s one step on the path.
The VM support and the Java level support are really for two different consumers
but I think it would be cleaner and less confusing to disable both on one flag rather
than support two options.

Bob.

> On Jul 24, 2020, at 12:13 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> Hi,
> 
> For hotspot one can disable container detection with a simple switch:
> 
> $ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
> [0.000s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.000s][trace][os,container] Container Support not enabled
> openjdk version "15-internal" 2020-09-15
> OpenJDK Runtime Environment (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2)
> OpenJDK 64-Bit Server VM (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> 
> The same cannot be achieved with the Java code,
> jdk.internal.platform.Metrics.java and friends in the JDK. At the time
> Metrics were added the only consumer of them was the Java Launcher via
> -XshowSettings:system. This has changed with JDK-8226575:
> OperatingSystemMXBean should be made container aware.
> 
> It is known that in certain cases the container detection code will
> detect for a system to be supposedly in a container where it actually
> isn't:
> https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
> 
> For hotspot there is a flag, to turn auto-detection off for exactly the
> case when heuristics are wrong: -XX:-UseContainerSupport. However, this
> flag has no effect on the Java metrics code. There is a risk that on
> some systems the auto-detection will be wrong and might cause
> regressions.
> 
> I propose to make the Java metrics code adhere to -XX:+/-
> UseContainerSupport flag. Do you think this would be useful? If yes,
> I'll file a bug and propose a patch for it.
> 
> Thoughts? Opinions?
> 
> Thanks,
> Severin
> 


From andy.herrick at oracle.com  Fri Jul 24 19:39:01 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 24 Jul 2020 15:39:01 -0400
Subject: RFR: JDK-8248239: jpackage adds some arguments twice in case it
 is re-executed by JLI
In-Reply-To: <dff41f8f-fdd2-d99f-c292-fb6003ce06fd@oracle.com>
References: <c95dc5a8-650a-2bdf-0225-1d902ab8ae5f@bell-sw.com>
 <6d4fabe6-37ce-7d1d-bf7d-e2b07e0ba92b@oracle.com>
 <f59c4014-6d2f-9c2a-4846-d3e41991a9e4@bell-sw.com>
 <e0bb7682-ac03-6958-cb35-ada96ab5583f@oracle.com>
 <6f2ae108-0c11-4294-7ff0-f7a975a0a8c3@bell-sw.com>
 <dff41f8f-fdd2-d99f-c292-fb6003ce06fd@oracle.com>
Message-ID: <33f79d09-d6e8-b0f6-0d56-5ba4fa7cf19e@oracle.com>

looks good

/Andy

On 7/21/2020 2:27 PM, Alexey Semenyuk wrote:
> Hi Aleksei,
>
> Looks good!
>
> - Alexey
>
> On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
>> Hi,
>>
>> This is the updated fix which checks if LD_LIBRARY_PATH has been changed
>> during jpackage executions:
>>
>> http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
>>
>> The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
>> variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
>> algorithm is used because standard C++ hash requires -std=c++11 or
>> -std=gnu++11 compiler options.
>>
>> All test/jdk/tools/jpackage tests but ModulePathTest3.java pass on Linux
>> x86_64, MacOSX x86_64, and Windows x86_64. The test ModulePathTest3.java
>> is excluded in test/jdk/ProblemList.txt (8248418 generic-all).
>>
>> Thanks,
>>
>> -Aleksei
>>
>> On 26/06/2020 20:23, Alexey Semenyuk wrote:
>>> Hi Aleksei,
>>>
>>> I think the idea of partial reading data from cfg file when the
>>> launcher is restarted has a flaw.
>>> It would be better if app launcher can detect if it was restarted and
>>> if it was, not read cfg file at all, but pass command line arguments
>>> as is in JLI_Launch().
>>> Let my think on ideas how to address this.
>>>
>>> - Alexey
>>>
>>> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>>>> Hi Alexey,
>>>>
>>>> Thank you for looking into it. As far as using parent pid, it does not
>>>> seem to work as example [1] demonstrates. The parent process 
>>>> remains the
>>>> same after re-execution and does not become the current process.
>>>>
>>>> I checked passing arguments in the "ArgOption" section using several
>>>> cases [2, 3, 4] with the proposed fix and app re-execution. The 
>>>> proposed
>>>> fix handles this case well, and the results are the same as without 
>>>> the
>>>> fix when the app is not re-executed.
>>>>
>>>> Case [3] where only JavaOptions without ArgOptions are passed to app
>>>> looks suspicious because default ArgOptions are not used. But it works
>>>> the same way without the proposed fix, which seems like a different
>>>> issue. According to jpackage documentation:
>>>>
>>>> ??? --arguments main class arguments
>>>> ????????? Command line arguments to pass to the main class if no 
>>>> command
>>>> line arguments are given to the launcher.
>>>>
>>>> I filed a separate issue [5] to handle that.
>>>>
>>>> Thanks,
>>>> -Aleksei
>>>>
>>>>
>>>> [1]
>>>> cd jdk-dev
>>>> make jdk-image
>>>> export PATH=build/linux-x86_64-server-release/images/jdk/bin:$PATH
>>>> export
>>>> LD_LIBRARY_PATH=build/linux-x86_64-server-release/images/jdk/lib/server 
>>>>
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --verbose --java-options -Dparam1=Param1
>>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>>> -------------
>>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>>> pid: 15927, parent? process: /bin/bash
>>>> JvmLauncher args: 10 [/home/sample/jdk-dev/output/app/bin/app
>>>> -Dparam1=Param1 --module-path
>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>>> pid: 15927, parent? process: /bin/bash
>>>> JvmLauncher args: 15 [/home/sample/jdk-dev/output/app/bin/app
>>>> -Dparam1=Param1 --module-path
>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>> com.hello/com.hello.Hello -Dparam1=Param1 --module-path
>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>>> -------------
>>>>
>>>> [2]
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --java-options -Dparam1=Param1
>>>> ./output/app/bin/app
>>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>>
>>>> [3]
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --java-options -Dparam1=Param1
>>>> ./output/app/bin/app -Dparam2=Param2
>>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>>>
>>>> [4]
>>>> jpackage --dest output --name app --type app-image --module-path
>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>> --java-options -Dparam1=Param1
>>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>>> B2 B ]
>>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>>> B2 B ]
>>>>
>>>> [5] https://bugs.openjdk.java.net/browse/JDK-8248397
>>>>
>>>>
>>>> On 24/06/2020 19:34, Alexey Semenyuk wrote:
>>>>> Aleksei,
>>>>>
>>>>> If I get it right, the fix would not work for the case when there are
>>>>> `arguments` properties in `ArgOptions` section of a config file.
>>>>> Why not just check if the parent process is the same executable as 
>>>>> the
>>>>> current one and if this is the case don't read data from the config
>>>>> file but pass executable arguments as is in JLI_Launch() call?
>>>>>
>>>>> - Alexey
>>>>>
>>>>> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> There are systems that update LD_LIBRARY_PATH or directly return
>>>>>> JNI_TRUE in method RequiresSetenv(const char *jvmpath) from 
>>>>>> java_md.c
>>>>>> file to request re-execution of the current executable. This 
>>>>>> leads to
>>>>>> the fact that jpackage application adds some provided arguments 
>>>>>> twice.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
>>>>>> Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
>>>>>>
>>>>>> The root cause of the issue is that jpackage application expects one
>>>>>> number of arguments but JLI reexecutes them with another number of
>>>>>> arguments.
>>>>>> ??? For example, a jpackage application can be run with arguments:
>>>>>> ?????? ./app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>> it adds arguments from the config file and calls JLI with arguments:
>>>>>> ?????? app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello
>>>>>> -Dparam2=Param2 B1 B2 B3
>>>>>> JLI re-executes the app with new arguments so the app adds some
>>>>>> arguments one more time after the re-execution.
>>>>>> ?????? ./app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
>>>>>>
>>>>>> A step by step example that illustrates the issue:
>>>>>>
>>>>>> Run jpackage to create an executable application:
>>>>>> ???? jpackage --dest output --name app --type app-image 
>>>>>> --module-path
>>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A1 A2
>>>>>> A3"
>>>>>> --verbose --java-options -Dparam1=Param1
>>>>>>
>>>>>> Executable application with the app/lib/app/app.cfg config file is
>>>>>> created:
>>>>>> ---- app.cfg? ----
>>>>>> [Application]
>>>>>> app.name=app
>>>>>> app.version=1.0
>>>>>> app.runtime=$ROOTDIR/lib/runtime
>>>>>> app.identifier=com.hello
>>>>>> app.classpath=
>>>>>> app.mainmodule=com.hello/com.hello.Hello
>>>>>>
>>>>>> [JavaOptions]
>>>>>> java-options=-Dparam1=Param1
>>>>>>
>>>>>> [ArgOptions]
>>>>>> arguments=A1
>>>>>> arguments=A2
>>>>>> arguments=A3
>>>>>> -----------
>>>>>>
>>>>>> Run the application:
>>>>>> ????? ./output/app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>>
>>>>>> Chain of JDK methods execution:
>>>>>>
>>>>>> LinuxLauncher main()
>>>>>> ????? args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
>>>>>> AppLauncher createJvmLauncher()
>>>>>> ????? args: 4 [-Dparam2=Param2 B1 B2 B3 ]
>>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>>> app.cfg
>>>>>> ????? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>> AppLauncher Jvm::launch() -? JLI re-executes the app
>>>>>> LinuxLauncher main()
>>>>>> ???? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>> AppLauncher createJvmLauncher()
>>>>>> ????? args: 9 [-classpath? -Dparam1=Param1 -m 
>>>>>> com.hello/com.hello.Hello
>>>>>> -Dparam2=Param2 B1 B2 B3 ]
>>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>>> app.cfg
>>>>>> ????? args: 15 [./app/bin/app -classpath -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>> ?????? ^^^
>>>>>>
>>>>>> Some arguments like "-classpath? -Dparam1=Param1 -m
>>>>>> com.hello/com.hello.Hello" are added twice.
>>>>>>
>>>>>> Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
>>>>>> regressions on Linux, Windows, Mac. On systems affected, the tests
>>>>>> now pass.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Aleksei
>>>>>>
>>>>>>
>

From brian.goetz at oracle.com  Fri Jul 24 20:16:07 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 24 Jul 2020 16:16:07 -0400
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
 <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
Message-ID: <8341dc8c-1f77-219e-a308-f4e2eb473c39@oracle.com>



On 7/24/2020 7:48 AM, Volker Simonis wrote:
>> I think it's reasonable to ask if the JDK
>> really needs to support this complexity.
> I can't see much complexity here.

Then I think we should start there.?? Until you can see the complexity 
here that is obvious to Alan, Lance, myself, and others, then there is 
no point discussing the specific technical issue.

Every configuration knob or flag creates complexity, because it creates 
a transient environmental dependence -- yet another thing that can cause 
behavior to change even when running the same JDK on the same underlying 
platform.

I think you are looking at _your patch_ and saying "it's not that 
complex", but that's not the kind of complexity we're talking about.? 
We're talking about the number of potential axes that can interact with 
each other to cause surprising or hard-to-debug behavior.? Can you 
honestly not imagine something going wrong with having Inflater use one 
zlib, Deflator another, and crc32 a third?

> Until now I'm only hearing mostly high-level ,theoretical arguments
> against the proposal rather than technical objections.

That's like when your mother tells you not to run with scissors, 
complaining that her concern is only theoretical, because not only do we 
not know anyone who has injured themselves running with scissors, but 
even if we did, they were not running with THIS pair of scissors."? But 
of course, your mother was right, and Alan (and all the others that 
reponded) are right too.? One of the most important roles of JDK 
stewards is pushing back on unnecessary complexity.? This is what Alan 
is doing.

> The change itself is quite small

Small changes can still introduce complexity.? (It's one line of code to 
enforce that methods in Java only have an odd number of checked 
exceptions on tuesdays, but that would surely be new complexity.)

> and it doesn't change any default
> behaviour at all so I didn't think a JEP will be required.

Which means either it will not be tested, or we have to double the 
number of test modes.

> I don't think we have to test all (or even various) zlib
which means customers using this will be running on an effectively 
untested configuration.? Does that seem wise?


Stepping back, we're in the classic trap where you've skipped over all 
the important discussion, and as a result we've gotten the obvious 
outcome, which is that we're talking about the wrong thing. Steps you 
should have run before getting tied to your solution, at a minimum, include:

 ?- Develop a clear and shared understanding about what the problem is
 ?- Develop consensus that it is a problem
 ?- Develop consensus that it is a problem that needs to be solved in 
the JDK
 ?- Brainstorm possible solutions, with tradeoffs, pros, and cons
 ?- Identify the best solution, and build consensus around that
 ?- Implement
 ?- Test
 ?- Review
 ?- Iterate

But you skipped straight to "Implement", and are now surprised that 
you're getting pushback against what should have been steps 1 or 2. You 
are trying to drive the discussion to "what changes do I have to make to 
have this patch accepted", but the conversation we should be having is 
"should we solve this problem at all" and then "if so, is this the right 
solution."? And it seems you're not finding anyone who is very compelled 
by either the problem or the solution.

I realize it sucks when you've done a lot of work and someone says "but 
we don't want/need that"; this is why you socialize the idea first.? 
Alan said in his first mail "I don't think the JDK should be in the 
business of ..." -- that's a clear "this is not a problem that needs to 
be solved in the JDK."? That's why we start at the top of the list.



From alexander.matveev at oracle.com  Fri Jul 24 22:37:03 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Fri, 24 Jul 2020 15:37:03 -0700
Subject: RFR: JDK-8248239: jpackage adds some arguments twice in case it
 is re-executed by JLI
In-Reply-To: <33f79d09-d6e8-b0f6-0d56-5ba4fa7cf19e@oracle.com>
References: <c95dc5a8-650a-2bdf-0225-1d902ab8ae5f@bell-sw.com>
 <6d4fabe6-37ce-7d1d-bf7d-e2b07e0ba92b@oracle.com>
 <f59c4014-6d2f-9c2a-4846-d3e41991a9e4@bell-sw.com>
 <e0bb7682-ac03-6958-cb35-ada96ab5583f@oracle.com>
 <6f2ae108-0c11-4294-7ff0-f7a975a0a8c3@bell-sw.com>
 <dff41f8f-fdd2-d99f-c292-fb6003ce06fd@oracle.com>
 <33f79d09-d6e8-b0f6-0d56-5ba4fa7cf19e@oracle.com>
Message-ID: <c88334d7-cad5-dc96-a6a5-539eb89eec59@oracle.com>

Looks good.

Thanks,
Alexander

On 7/24/20 12:39 PM, Andy Herrick wrote:
> looks good
>
> /Andy
>
> On 7/21/2020 2:27 PM, Alexey Semenyuk wrote:
>> Hi Aleksei,
>>
>> Looks good!
>>
>> - Alexey
>>
>> On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
>>> Hi,
>>>
>>> This is the updated fix which checks if LD_LIBRARY_PATH has been 
>>> changed
>>> during jpackage executions:
>>>
>>> http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
>>>
>>> The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
>>> variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
>>> algorithm is used because standard C++ hash requires -std=c++11 or
>>> -std=gnu++11 compiler options.
>>>
>>> All test/jdk/tools/jpackage tests but ModulePathTest3.java pass on 
>>> Linux
>>> x86_64, MacOSX x86_64, and Windows x86_64. The test 
>>> ModulePathTest3.java
>>> is excluded in test/jdk/ProblemList.txt (8248418 generic-all).
>>>
>>> Thanks,
>>>
>>> -Aleksei
>>>
>>> On 26/06/2020 20:23, Alexey Semenyuk wrote:
>>>> Hi Aleksei,
>>>>
>>>> I think the idea of partial reading data from cfg file when the
>>>> launcher is restarted has a flaw.
>>>> It would be better if app launcher can detect if it was restarted and
>>>> if it was, not read cfg file at all, but pass command line arguments
>>>> as is in JLI_Launch().
>>>> Let my think on ideas how to address this.
>>>>
>>>> - Alexey
>>>>
>>>> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> Thank you for looking into it. As far as using parent pid, it does 
>>>>> not
>>>>> seem to work as example [1] demonstrates. The parent process 
>>>>> remains the
>>>>> same after re-execution and does not become the current process.
>>>>>
>>>>> I checked passing arguments in the "ArgOption" section using several
>>>>> cases [2, 3, 4] with the proposed fix and app re-execution. The 
>>>>> proposed
>>>>> fix handles this case well, and the results are the same as 
>>>>> without the
>>>>> fix when the app is not re-executed.
>>>>>
>>>>> Case [3] where only JavaOptions without ArgOptions are passed to app
>>>>> looks suspicious because default ArgOptions are not used. But it 
>>>>> works
>>>>> the same way without the proposed fix, which seems like a different
>>>>> issue. According to jpackage documentation:
>>>>>
>>>>> ??? --arguments main class arguments
>>>>> ????????? Command line arguments to pass to the main class if no 
>>>>> command
>>>>> line arguments are given to the launcher.
>>>>>
>>>>> I filed a separate issue [5] to handle that.
>>>>>
>>>>> Thanks,
>>>>> -Aleksei
>>>>>
>>>>>
>>>>> [1]
>>>>> cd jdk-dev
>>>>> make jdk-image
>>>>> export PATH=build/linux-x86_64-server-release/images/jdk/bin:$PATH
>>>>> export
>>>>> LD_LIBRARY_PATH=build/linux-x86_64-server-release/images/jdk/lib/server 
>>>>>
>>>>> jpackage --dest output --name app --type app-image --module-path
>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>>> --verbose --java-options -Dparam1=Param1
>>>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>>>> -------------
>>>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>>>> pid: 15927, parent? process: /bin/bash
>>>>> JvmLauncher args: 10 [/home/sample/jdk-dev/output/app/bin/app
>>>>> -Dparam1=Param1 --module-path
>>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>>>> pid: 15927, parent? process: /bin/bash
>>>>> JvmLauncher args: 15 [/home/sample/jdk-dev/output/app/bin/app
>>>>> -Dparam1=Param1 --module-path
>>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>>> com.hello/com.hello.Hello -Dparam1=Param1 --module-path
>>>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>>>> -------------
>>>>>
>>>>> [2]
>>>>> jpackage --dest output --name app --type app-image --module-path
>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>>> --java-options -Dparam1=Param1
>>>>> ./output/app/bin/app
>>>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>>>
>>>>> [3]
>>>>> jpackage --dest output --name app --type app-image --module-path
>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>>> --java-options -Dparam1=Param1
>>>>> ./output/app/bin/app -Dparam2=Param2
>>>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello 
>>>>> -Dparam2=Param2 ]
>>>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello 
>>>>> -Dparam2=Param2 ]
>>>>>
>>>>> [4]
>>>>> jpackage --dest output --name app --type app-image --module-path
>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>>>> --java-options -Dparam1=Param1
>>>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 
>>>>> --module-path
>>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello 
>>>>> -Dparam2=Param2 B
>>>>> B2 B ]
>>>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 
>>>>> --module-path
>>>>> output/app/lib/app/mods -m com.hello/com.hello.Hello 
>>>>> -Dparam2=Param2 B
>>>>> B2 B ]
>>>>>
>>>>> [5] https://bugs.openjdk.java.net/browse/JDK-8248397
>>>>>
>>>>>
>>>>> On 24/06/2020 19:34, Alexey Semenyuk wrote:
>>>>>> Aleksei,
>>>>>>
>>>>>> If I get it right, the fix would not work for the case when there 
>>>>>> are
>>>>>> `arguments` properties in `ArgOptions` section of a config file.
>>>>>> Why not just check if the parent process is the same executable 
>>>>>> as the
>>>>>> current one and if this is the case don't read data from the config
>>>>>> file but pass executable arguments as is in JLI_Launch() call?
>>>>>>
>>>>>> - Alexey
>>>>>>
>>>>>> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> There are systems that update LD_LIBRARY_PATH or directly return
>>>>>>> JNI_TRUE in method RequiresSetenv(const char *jvmpath) from 
>>>>>>> java_md.c
>>>>>>> file to request re-execution of the current executable. This 
>>>>>>> leads to
>>>>>>> the fact that jpackage application adds some provided arguments 
>>>>>>> twice.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
>>>>>>> Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
>>>>>>>
>>>>>>> The root cause of the issue is that jpackage application expects 
>>>>>>> one
>>>>>>> number of arguments but JLI reexecutes them with another number of
>>>>>>> arguments.
>>>>>>> ??? For example, a jpackage application can be run with arguments:
>>>>>>> ?????? ./app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>>> it adds arguments from the config file and calls JLI with 
>>>>>>> arguments:
>>>>>>> ?????? app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello
>>>>>>> -Dparam2=Param2 B1 B2 B3
>>>>>>> JLI re-executes the app with new arguments so the app adds some
>>>>>>> arguments one more time after the re-execution.
>>>>>>> ?????? ./app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
>>>>>>>
>>>>>>> A step by step example that illustrates the issue:
>>>>>>>
>>>>>>> Run jpackage to create an executable application:
>>>>>>> ???? jpackage --dest output --name app --type app-image 
>>>>>>> --module-path
>>>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A1 A2
>>>>>>> A3"
>>>>>>> --verbose --java-options -Dparam1=Param1
>>>>>>>
>>>>>>> Executable application with the app/lib/app/app.cfg config file is
>>>>>>> created:
>>>>>>> ---- app.cfg? ----
>>>>>>> [Application]
>>>>>>> app.name=app
>>>>>>> app.version=1.0
>>>>>>> app.runtime=$ROOTDIR/lib/runtime
>>>>>>> app.identifier=com.hello
>>>>>>> app.classpath=
>>>>>>> app.mainmodule=com.hello/com.hello.Hello
>>>>>>>
>>>>>>> [JavaOptions]
>>>>>>> java-options=-Dparam1=Param1
>>>>>>>
>>>>>>> [ArgOptions]
>>>>>>> arguments=A1
>>>>>>> arguments=A2
>>>>>>> arguments=A3
>>>>>>> -----------
>>>>>>>
>>>>>>> Run the application:
>>>>>>> ????? ./output/app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>>>
>>>>>>> Chain of JDK methods execution:
>>>>>>>
>>>>>>> LinuxLauncher main()
>>>>>>> ????? args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
>>>>>>> AppLauncher createJvmLauncher()
>>>>>>> ????? args: 4 [-Dparam2=Param2 B1 B2 B3 ]
>>>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>>>> app.cfg
>>>>>>> ????? args: 10 [app/bin/app -classpath -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>>> AppLauncher Jvm::launch() -? JLI re-executes the app
>>>>>>> LinuxLauncher main()
>>>>>>> ???? args: 10 [app/bin/app -classpath? -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>>> AppLauncher createJvmLauncher()
>>>>>>> ????? args: 9 [-classpath? -Dparam1=Param1 -m 
>>>>>>> com.hello/com.hello.Hello
>>>>>>> -Dparam2=Param2 B1 B2 B3 ]
>>>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>>>> app.cfg
>>>>>>> ????? args: 15 [./app/bin/app -classpath -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello -classpath? -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>>> ?????? ^^^
>>>>>>>
>>>>>>> Some arguments like "-classpath? -Dparam1=Param1 -m
>>>>>>> com.hello/com.hello.Hello" are added twice.
>>>>>>>
>>>>>>> Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
>>>>>>> regressions on Linux, Windows, Mac. On systems affected, the tests
>>>>>>> now pass.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Aleksei
>>>>>>>
>>>>>>>
>>


From joe.darcy at oracle.com  Sat Jul 25 02:25:34 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 24 Jul 2020 19:25:34 -0700
Subject: JDK 16 RFR of JDK-8250578: Address reliance on default constructors
 in javax.sql
Message-ID: <6a02bac2-cad4-5784-fa29-6ca6552a2361@oracle.com>

Hello,

Another module, another use of a default constructor. Please review the 
fix and CSR for:

 ??? JDK-8250578: Address reliance on default constructors in javax.sql
 ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250579
 ??? http://cr.openjdk.java.net/~darcy/8250578.0/

Patch below.

Thanks,

-Joe

--- 
old/src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java 
2020-07-24 19:16:43.633847343 -0700
+++ 
new/src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java 
2020-07-24 19:16:42.941847343 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2020, 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
@@ -52,6 +52,10 @@
 ? * @since 1.5
 ? */
 ?public class RowSetMetaDataImpl implements RowSetMetaData, Serializable {
+??? /**
+???? * Constructs a {@code RowSetMetaDataImpl} object.
+???? */
+??? public RowSetMetaDataImpl() {}

 ???? /**
 ????? * The number of columns in the <code>RowSet</code> object that 
created


From joe.darcy at oracle.com  Sat Jul 25 02:45:53 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 24 Jul 2020 19:45:53 -0700
Subject: JDK 16 RFR of 8250580: Address reliance on default constructors in
 java.rmi
Message-ID: <4ccf6bba-1500-dd50-3fab-ea523db80ac7@oracle.com>

Hello,

Another bug in the quest to remove use of default constructors in the 
JDK's public API, this time in the java.rmi module:

 ??? webrev: http://cr.openjdk.java.nhet/~darcy/8250580.0/
 ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250581

Patch below; thanks,

-Joe

--- 
old/src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java 
2020-07-24 19:42:16.353847343 -0700
+++ 
new/src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java 
2020-07-24 19:42:15.645847343 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, 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
@@ -62,6 +62,11 @@
 ?public abstract class RMIClassLoaderSpi {

 ???? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public RMIClassLoaderSpi() {}
+
+??? /**
 ????? * Provides the implementation for
 ????? * {@link RMIClassLoader#loadClass(URL,String)},
 ????? * {@link RMIClassLoader#loadClass(String,String)}, and


From LANCE.ANDERSEN at ORACLE.COM  Sat Jul 25 10:38:19 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Sat, 25 Jul 2020 06:38:19 -0400
Subject: JDK 16 RFR of 8250580: Address reliance on default constructors
 in java.rmi
In-Reply-To: <4ccf6bba-1500-dd50-3fab-ea523db80ac7@oracle.com>
References: <4ccf6bba-1500-dd50-3fab-ea523db80ac7@oracle.com>
Message-ID: <FACD2801-D0F0-44CF-90BE-C2DA1A4093A9@ORACLE.COM>

+1

> On Jul 24, 2020, at 10:45 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Another bug in the quest to remove use of default constructors in the JDK's public API, this time in the java.rmi module:
> 
>     webrev: http://cr.openjdk.java.nhet/~darcy/8250580.0/
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8250581
> 
> Patch below; thanks,
> 
> -Joe
> 
> --- old/src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java 2020-07-24 19:42:16.353847343 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java 2020-07-24 19:42:15.645847343 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, 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
> @@ -62,6 +62,11 @@
>  public abstract class RMIClassLoaderSpi {
> 
>      /**
> +     * Constructor for subclasses to call.
> +     */
> +    public RMIClassLoaderSpi() {}
> +
> +    /**
>       * Provides the implementation for
>       * {@link RMIClassLoader#loadClass(URL,String)},
>       * {@link RMIClassLoader#loadClass(String,String)}, and
> 


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From LANCE.ANDERSEN at ORACLE.COM  Sat Jul 25 10:38:40 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Sat, 25 Jul 2020 06:38:40 -0400
Subject: JDK 16 RFR of JDK-8250578: Address reliance on default
 constructors in javax.sql
In-Reply-To: <6a02bac2-cad4-5784-fa29-6ca6552a2361@oracle.com>
References: <6a02bac2-cad4-5784-fa29-6ca6552a2361@oracle.com>
Message-ID: <A60D65B1-4FC4-4723-A9C0-58ADEF7016AD@ORACLE.COM>

+1

> On Jul 24, 2020, at 10:25 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Another module, another use of a default constructor. Please review the fix and CSR for:
> 
>     JDK-8250578: Address reliance on default constructors in javax.sql
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8250579
>     http://cr.openjdk.java.net/~darcy/8250578.0/
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java 2020-07-24 19:16:43.633847343 -0700
> +++ new/src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java 2020-07-24 19:16:42.941847343 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2020, 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
> @@ -52,6 +52,10 @@
>   * @since 1.5
>   */
>  public class RowSetMetaDataImpl implements RowSetMetaData, Serializable {
> +    /**
> +     * Constructs a {@code RowSetMetaDataImpl} object.
> +     */
> +    public RowSetMetaDataImpl() {}
> 
>      /**
>       * The number of columns in the <code>RowSet</code> object that created
> 


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From amaembo at gmail.com  Sun Jul 26 16:04:47 2020
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 26 Jul 2020 23:04:47 +0700
Subject: RFR: JDK-8244288 Specialized implementations for putIfAbsent,
 merge, compute* methods in TreeMap derived maps
In-Reply-To: <CAE+3fjYAp-bvXJnF-Nvih2LSJoJFvx=g3ZNBHkmUcrm_FBX+5w@mail.gmail.com>
References: <CAE+3fjYAp-bvXJnF-Nvih2LSJoJFvx=g3ZNBHkmUcrm_FBX+5w@mail.gmail.com>
Message-ID: <CAE+3fja2CiSCU=zzTD2R=6YRWVg==0EwP7CRYuPmNz7xMmt1aQ@mail.gmail.com>

Hello!

A gentle ping: please review
https://bugs.openjdk.java.net/browse/JDK-8244288
http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
The details are listed below.

With best regards,
Tagir Valeev.

On Sun, May 3, 2020 at 4:36 PM Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> Please review the following change:
> https://bugs.openjdk.java.net/browse/JDK-8244288
> http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
>
> We already implemented putIfAbsent, merge, computeIfAbsent,
> computeIfPresent, and compute for TreeMap class (see JDK-8176894).
> However, default implementations of these methods are still used for
> TreeMap derived maps, such as descendingMap(), tailMap(), headMap()
> and subMap(). The implementation is pretty straightforward, just a
> range-check+delegation for each of these methods inside the
> TreeMap.NavigableSubMap (+32 lines in TreeMap.java). Care should be
> taken to avoid throwing IAE from compute* methods if the key is
> outside of the range but we don't actually add the entry. This mimics
> the previous behavior and also consistent with other modification
> methods like Map.remove (we don't throw from remove if the key is out
> of range, simply do nothing).
>
> To cover these changes with tests, I added new
> TreeMap().descendingMap() to
> InPlaceOpsCollisions.nullValueFriendlyMaps and
> MapWithCollisionsProviders.makeMapsMoreTypes. This map should behave
> like a normal Map modulo iteration order but implementation goes
> through NavigableSubMap. Also, I added more adders to
> LockStep::randomAdder (lines 572+) to cover new methods, as well as
> some more throws IAE asserts around line 806. At the same time, I took
> the liberty to modernize this test:
> - Convert all the raw-types to properly parameterized (using 'var' for
> local vars where resulting type is long)
> - Convert MapFrobber and SetFrobber to interfaces, and convert all the
> implementations to lambdas (automatic conversion via IntelliJ IDEA +
> rename of conflicting parameter names)
> - Use for-each loop instead of indexed for loop where possible
> - 'elts' array was created in two places but unused afterward. I added
> size assert to these arrays to use it at least somehow (though
> probably content should be checked as well).
> - Use Comparator.naturalOrder() instead of manually written one in
> comparator() methods (should not affect the testing in any way as it's
> only used directly, not passed e.g. to TreeMap constructor).
> - Use Objects.equals inside LockStep#equal
> - Inverted 'if' at line 299 to avoid empty block.
> If the cleanup really complicates the review I can post the cleanup as
> a separate changeset. Though it should not be very problematic as the
> actual changes are quite compact (as said above, near lines 572 and
> 806)
>
> I also improved the previously added benchmark TreeMapUpdate to check
> descendingMap and tailMap cases to confirm the hypothesis that the
> change improves the performance of derived maps. This is indeed the
> case. E.g. merge test yields (comparator = false, size = 1000) for
> unpatched JDK:
>
> (benchmark)                 (mode) (prefill)    Score      Error  Units
> TreeMapUpdate.merge        TreeMap   true   63589,075 ? 1028,065  ns/op
> TreeMapUpdate.merge        TreeMap  false   65414,367 ? 1011,442  ns/op
> TreeMapUpdate.merge  descendingMap   true  121501,618 ? 1849,108  ns/op
> TreeMapUpdate.merge  descendingMap  false   95913,212 ? 2854,063  ns/op
> TreeMapUpdate.merge        tailMap   true  126657,309 ? 4467,733  ns/op
> TreeMapUpdate.merge        tailMap  false   93448,840 ? 1359,392  ns/op
>
> As you can see, the merge on derived maps is significantly slower.
> After the patch is applied the results are much better:
>
> (benchmark)                 (mode)  (prefill)     Score      Error  Units
> TreeMapUpdate.merge        TreeMap       true 64059,189 ?  808,230  ns/op
> TreeMapUpdate.merge        TreeMap      false 65156,912 ? 1229,965  ns/op
> TreeMapUpdate.merge  descendingMap       true 69938,131 ? 1697,357  ns/op
> TreeMapUpdate.merge  descendingMap      false 67783,829 ?  263,061  ns/op
> TreeMapUpdate.merge        tailMap       true 71079,529 ?  841,738  ns/op
> TreeMapUpdate.merge        tailMap      false 68577,169 ? 1196,758  ns/op
>
> I don't think this requires a CSR, as the changed class is
> package-private, so it cannot be extended by clients.
>
> With best regards,
> Tagir Valeev.

From justin.dekeyser at gmail.com  Sun Jul 26 17:22:20 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Sun, 26 Jul 2020 19:22:20 +0200
Subject: Type inference: bug or feature?
Message-ID: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>

Dear all,

I'm not sure but I think I've found a bug in Java type inference mechanism.
It may also be a feature, so I'll expose the problem to you below; in terms
of Integer, Number and List, although you'll quickly realize it will work
wrong in any similar situation.

Let's assume I have

static <U, V extends U> List<U> emptyList(Class<U> magnet) {
   return Collections.emptyList();
}

Then the following codes does not compile (for the same reason):

var x = (List<Integer>) emptyList(Number.class);
List<Integer> x = (List<Integer>) emptyList(Number.class);

incompatible types: List<Number> cannot be converted to List<Integer>

however, the following do compile:

var x = emptyList(Number.class); // inferred to List<Number>
List<Integer> x = emptyList(Number.class); // no mistake here, it's Integer
on the left

Is this the expected behavior? Why does casting operation here interfere
with type inference like this?

Regards,

Justin Dekeyser




<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Garanti
sans virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From fweimer at redhat.com  Mon Jul 27 07:43:24 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 27 Jul 2020 09:43:24 +0200
Subject: Type inference: bug or feature?
In-Reply-To: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 (Justin Dekeyser's message of "Sun, 26 Jul 2020 19:22:20 +0200")
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
Message-ID: <878sf54d43.fsf@oldenburg2.str.redhat.com>

* Justin Dekeyser:

> Then the following codes does not compile (for the same reason):
>
> var x = (List<Integer>) emptyList(Number.class);
> List<Integer> x = (List<Integer>) emptyList(Number.class);
>
> incompatible types: List<Number> cannot be converted to List<Integer>
>
> however, the following do compile:
>
> var x = emptyList(Number.class); // inferred to List<Number>
> List<Integer> x = emptyList(Number.class); // no mistake here, it's Integer
> on the left
>
> Is this the expected behavior? Why does casting operation here interfere
> with type inference like this?

emptyList() is special, it only works this way because the returned list
is always empty, so that the element type does not matter.  For any
other list-returning function, the types List<Integer> and List<Number>
are not interchangeable because for each type, there are operations
which are not valid for the other.  That's why we often need wildcards
once type hierarchies are involved (List<? super Integer> or
List<? extends Number>, depending on context).

A somewhat similar case is functions which do not return (normally).
They too can have a very general generic type which does not depend on
function arguments.

Thanks,
Florian


From justin.dekeyser at gmail.com  Mon Jul 27 08:19:21 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Mon, 27 Jul 2020 10:19:21 +0200
Subject: Type inference: bug or feature?
In-Reply-To: <878sf54d43.fsf@oldenburg2.str.redhat.com>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <878sf54d43.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAO5-QM29Lz6N9fLizaxHweq1OWFkSCGXxzv8bKum_qtct0uOzg@mail.gmail.com>

Hello,

Thanks for the answer.

Nevertheless, the point was not really about list stuffs, and is not
related to the lack of co/contra variance.
You may replace List with any other generic class  Foo<T> and Integer and
Number with any other class satisfying the same inheritance relations.

The behavior is really about casting, which prevents type inference to work
"as one would expect".
This is even weirder because, in case of lambda expressions, casting does
help in desambiguising the type.

So on the one side, we have a casting operation that helps in type
inference,
on the other side, we have a casting operation that prevents some inference.

I'm really not sure this is no bug :/

Regards,

Justin Dekeyser



On Mon, Jul 27, 2020 at 9:43 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Justin Dekeyser:
>
> > Then the following codes does not compile (for the same reason):
> >
> > var x = (List<Integer>) emptyList(Number.class);
> > List<Integer> x = (List<Integer>) emptyList(Number.class);
> >
> > incompatible types: List<Number> cannot be converted to List<Integer>
> >
> > however, the following do compile:
> >
> > var x = emptyList(Number.class); // inferred to List<Number>
> > List<Integer> x = emptyList(Number.class); // no mistake here, it's
> Integer
> > on the left
> >
> > Is this the expected behavior? Why does casting operation here interfere
> > with type inference like this?
>
> emptyList() is special, it only works this way because the returned list
> is always empty, so that the element type does not matter.  For any
> other list-returning function, the types List<Integer> and List<Number>
> are not interchangeable because for each type, there are operations
> which are not valid for the other.  That's why we often need wildcards
> once type hierarchies are involved (List<? super Integer> or
> List<? extends Number>, depending on context).
>
> A somewhat similar case is functions which do not return (normally).
> They too can have a very general generic type which does not depend on
> function arguments.
>
> Thanks,
> Florian
>
>

From fweimer at redhat.com  Mon Jul 27 08:21:34 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 27 Jul 2020 10:21:34 +0200
Subject: Type inference: bug or feature?
In-Reply-To: <CAO5-QM29Lz6N9fLizaxHweq1OWFkSCGXxzv8bKum_qtct0uOzg@mail.gmail.com>
 (Justin Dekeyser's message of "Mon, 27 Jul 2020 10:19:21 +0200")
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <878sf54d43.fsf@oldenburg2.str.redhat.com>
 <CAO5-QM29Lz6N9fLizaxHweq1OWFkSCGXxzv8bKum_qtct0uOzg@mail.gmail.com>
Message-ID: <87v9i92ws1.fsf@oldenburg2.str.redhat.com>

* Justin Dekeyser:

> Nevertheless, the point was not really about list stuffs, and is not
> related to the lack of co/contra variance.

> You may replace List with any other generic class Foo<T> and Integer
> and Number with any other class satisfying the same inheritance
> relations.

Ahh, well, but why are such casts useful?  The results will be wrong in
pretty much every case.  Their correctness cannot be checked at run
time, either.

Thanks,
Florian


From justin.dekeyser at gmail.com  Mon Jul 27 08:44:43 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Mon, 27 Jul 2020 10:44:43 +0200
Subject: Type inference: bug or feature?
In-Reply-To: <87v9i92ws1.fsf@oldenburg2.str.redhat.com>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <878sf54d43.fsf@oldenburg2.str.redhat.com>
 <CAO5-QM29Lz6N9fLizaxHweq1OWFkSCGXxzv8bKum_qtct0uOzg@mail.gmail.com>
 <87v9i92ws1.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAO5-QM1TciRzwzqnn9wJAAuWvXwRhYx=MBo5i6ciBUN8zM56+Q@mail.gmail.com>

Hello,

Again, thanks for the prompt response!

Well, I'm not really sure about the answer but, to my understanding, if
this:
List<Integer> x = emptyList(Number.class);
compiles correctly (thus U inferred as Number, V inferred as Integer as
expected),
then why this
List<Integer> x = (List<Integer>) emptyList(Number.class);
does not compile ? (with explicit or var-typing)

On the other hand, the following code
var x = (Function<String,String>) x -> x;
compile with no error, hence in this case, casting does help in type
inference.

I really feel that, although a bit "over complicated", there is something
that I either really don't get, or something else :/

Regards,

Justin Dekeyser



On Mon, Jul 27, 2020 at 10:21 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Justin Dekeyser:
>
> > Nevertheless, the point was not really about list stuffs, and is not
> > related to the lack of co/contra variance.
>
> > You may replace List with any other generic class Foo<T> and Integer
> > and Number with any other class satisfying the same inheritance
> > relations.
>
> Ahh, well, but why are such casts useful?  The results will be wrong in
> pretty much every case.  Their correctness cannot be checked at run
> time, either.
>
> Thanks,
> Florian
>
>

From sergei.tsypanov at yandex.ru  Mon Jul 27 08:46:08 2020
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 27 Jul 2020 10:46:08 +0200
Subject: [PATCH] Use byte[] instead of char[] in Integer.digits
Message-ID: <1021261595838211@mail.yandex.ru>

Hello, I'd like to contribute this trivial patch to JDK.

The idea behind it is that with compact strings we don't need char[] when all symbols are ASCII.

This allows to slightly reduce footprint of java.lang.Integer.class and drop casts from char to byte.

I've measured performance of patched code using Integer/Long.toString() and toHexString() methods for short and long values
and the patch is likely to improve it slightly, at least for Long:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g", "-XX:+UseParallelGC"})
public class IntegerToString {
  @Benchmark
  public String integerToHexString(Data data) { return Integer.toHexString(data.value); }

  @Benchmark
  public String integerToString(Data data) { return Integer.toString(data.value); }

  @State(Scope.Thread)
  public static class Data {
    @Param({"0", "2147483647"}) private int value;
  }
}


Gives

Benchmark                                       (value)  Mode  Cnt   Score   Error  Units
IntegerToString.integerToHexString                    0  avgt   50   7.833 ? 0.172  ns/op
IntegerToString.integerToString                       0  avgt   50   7.550 ? 0.070  ns/op
IntegerToString.integerToHexString           2147483647  avgt   50  13.200 ? 0.268  ns/op
IntegerToString.integerToString              2147483647  avgt   50  17.028 ? 0.572  ns/op

after

Benchmark                                       (value)  Mode  Cnt   Score   Error  Units
IntegerToString.integerToHexString                    0  avgt   50   7.771 ? 0.410  ns/op
IntegerToString.integerToString                       0  avgt   50   7.779 ? 0.321  ns/op
IntegerToString.integerToHexString           2147483647  avgt   50  13.193 ? 0.450  ns/op
IntegerToString.integerToString              2147483647  avgt   50  16.641 ? 0.332  ns/op

As of Long the corresponding benchmark

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g", "-XX:+UseParallelGC"})
public class LongToString {
  @Benchmark
  public String longToHexString(Data data) { return Long.toHexString(data.longValue); }

  @Benchmark
  public String longToString(Data data) { return Long.toString(data.longValue); }

  @State(Scope.Thread)
  public static class Data {
    @Param({"0", "9223372036854775807"}) private long longValue;
  }
}


gives

before

LongToString.longToHexString                          0  avgt   50   7.711 ? 0.303  ns/op
LongToString.longToString                             0  avgt   50   7.321 ? 0.439  ns/op
LongToString.longToHexString        9223372036854775807  avgt   50  17.393 ? 0.515  ns/op
LongToString.longToString           9223372036854775807  avgt   50  30.192 ? 1.365  ns/op

after

LongToString.longToHexString                          0  avgt   50   7.796 ? 0.250  ns/op
LongToString.longToString                             0  avgt   50   6.497 ? 0.015  ns/op
LongToString.longToHexString        9223372036854775807  avgt   50  17.720 ? 0.914  ns/op
LongToString.longToString           9223372036854775807  avgt   50  27.089 ? 0.232  ns/op

Also I've included into that patch trivial change for Integer.IntegerCache where we can use local variable size
instead of c.length where c is array. This is likely to slightly improve startup time as this code is executed at class
loading time and likely to be executed in interpreter mode rather than beingcompiled by optimizing compiler.

Regards,
Sergey Tsypanov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytes.patch
Type: text/x-diff
Size: 2583 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200727/b2e6120f/bytes.patch>

From maurizio.cimadamore at oracle.com  Mon Jul 27 10:26:40 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Jul 2020 11:26:40 +0100
Subject: Type inference: bug or feature?
In-Reply-To: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
Message-ID: <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>

CC'ing compiler-dev

Hi Justin,
the behavior you are observing is normal. For a Java expression to be 
able to be influenced by type inference it has to be a poly expression 
(where poly stands for _many_ as in, the same expression can have many 
types).

At the time we did Java 8 we briefly considered making cast expressions 
part of the poly expression dance (like lambdas, method references, 
method calls, parens, new creation expression, conditionals and switch 
expression - see JLS 15.2), but the rule which dictate cast conversion 
(JLS 5.5) are so complex (as they have to take into account possibility 
for unchecked cast, etc.) that it felt like touching them was a very 
risky move, with no clear benefit.

The behavior you see is caused by the fact that the cast expression acts 
as a "shield" - that is, whenever a method call appears after a cast 
expression (as in your case), the method call is type-checked as if it 
were in isolation, and _then_ the result of type checking is validated 
against the cast. In other words, your example is no different than doing:

var x = (List<Integer>)(Object)emptyList(Number.class);


That is, the emptyList call will see no meaningful target type (just 
Object), so Number will be inferred and a List<Number> will be returned, 
which will then be incompatible with the type of the cast expression 
(List<Integer>).

Your second set of examples, since it does not make use of cast 
expressions, works as expected, as the target type can freely flow 
inside the method call typing, and thus influence the type inference 
result (e.g. the inference engine now sees two constraints, for Integer 
and for Number, and is of course able to pick the "best" one).

Hope this helps.

Cheers
Maurizio

On 26/07/2020 18:22, Justin Dekeyser wrote:
> Dear all,
>
> I'm not sure but I think I've found a bug in Java type inference mechanism.
> It may also be a feature, so I'll expose the problem to you below; in terms
> of Integer, Number and List, although you'll quickly realize it will work
> wrong in any similar situation.
>
> Let's assume I have
>
> static <U, V extends U> List<U> emptyList(Class<U> magnet) {
>     return Collections.emptyList();
> }
>
> Then the following codes does not compile (for the same reason):
>
> var x = (List<Integer>) emptyList(Number.class);
> List<Integer> x = (List<Integer>) emptyList(Number.class);
>
> incompatible types: List<Number> cannot be converted to List<Integer>
>
> however, the following do compile:
>
> var x = emptyList(Number.class); // inferred to List<Number>
> List<Integer> x = emptyList(Number.class); // no mistake here, it's Integer
> on the left
>
> Is this the expected behavior? Why does casting operation here interfere
> with type inference like this?
>
> Regards,
>
> Justin Dekeyser
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Garanti
> sans virus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From maurizio.cimadamore at oracle.com  Mon Jul 27 10:27:11 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Jul 2020 11:27:11 +0100
Subject: Type inference: bug or feature?
In-Reply-To: <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
Message-ID: <86d4c0ad-e757-a335-efdd-aa14b4d93a25@oracle.com>


On 27/07/2020 11:26, Maurizio Cimadamore wrote:
> CC'ing compiler-dev
>
> Hi Justin,
> the behavior you are observing is normal. For a Java expression to be 
> able to be influenced by type inference it has to be a poly expression 
> (where poly stands for _many_ as in, the same expression can have many 
> types).
>
> At the time we did Java 8 we briefly considered making cast 
> expressions part of the poly expression dance (like lambdas, method 
> references, method calls, parens, new creation expression, 
> conditionals and switch expression - see JLS 15.2), but the rule which 
> dictate cast conversion (JLS 5.5) are so complex (as they have to take 
> into account possibility for unchecked cast, etc.) that it felt like 
> touching them was a very risky move, with no clear benefit.
>
> The behavior you see is caused by the fact that the cast expression 
> acts as a "shield" - that is, whenever a method call appears after a 
> cast expression (as in your case), the method call is type-checked as 
> if it were in isolation, and _then_ the result of type checking is 
> validated against the cast. In other words, your example is no 
> different than doing:
>
> var x = (List<Integer>)(Object)emptyList(Number.class);
>
>
> That is, the emptyList call will see no meaningful target type (just 
> Object), so Number will be inferred and a List<Number> will be 
> returned, which will then be incompatible with the type of the cast 
> expression (List<Integer>).
>
> Your second set of examples, since it does not make use of cast 
> expressions, works as expected, as the target type can freely flow 
> inside the method call typing, and thus influence the type inference 
> result (e.g. the inference engine now sees two constraints, for 
> Integer and for Number, and is of course able to pick the "best" one).
>
> Hope this helps.
>
> Cheers
> Maurizio
>
> On 26/07/2020 18:22, Justin Dekeyser wrote:
>> Dear all,
>>
>> I'm not sure but I think I've found a bug in Java type inference 
>> mechanism.
>> It may also be a feature, so I'll expose the problem to you below; in 
>> terms
>> of Integer, Number and List, although you'll quickly realize it will 
>> work
>> wrong in any similar situation.
>>
>> Let's assume I have
>>
>> static <U, V extends U> List<U> emptyList(Class<U> magnet) {
>> ??? return Collections.emptyList();
>> }
>>
>> Then the following codes does not compile (for the same reason):
>>
>> var x = (List<Integer>) emptyList(Number.class);
>> List<Integer> x = (List<Integer>) emptyList(Number.class);
>>
>> incompatible types: List<Number> cannot be converted to List<Integer>
>>
>> however, the following do compile:
>>
>> var x = emptyList(Number.class); // inferred to List<Number>
>> List<Integer> x = emptyList(Number.class); // no mistake here, it's 
>> Integer
>> on the left
>>
>> Is this the expected behavior? Why does casting operation here interfere
>> with type inference like this?
>>
>> Regards,
>>
>> Justin Dekeyser
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 
>>
>> Garanti
>> sans virus. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From volker.simonis at gmail.com  Mon Jul 27 10:27:36 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 27 Jul 2020 12:27:36 +0200
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <8341dc8c-1f77-219e-a308-f4e2eb473c39@oracle.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
 <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
 <8341dc8c-1f77-219e-a308-f4e2eb473c39@oracle.com>
Message-ID: <CA+3eh13qShsjwv3CO5TPse7nwHtn1acCjo+o4h-rBODyH_4TPw@mail.gmail.com>

Hi Brian,

thanks a lot for your detailed answer. I've replied to some of your
comments inline but I don't expect another answer because it seems that all
arguments have been exchanged and we're happily agreeing to disagree :)

There's just a single remaining question for which I would appreciate an
answer. I perfectly understood that the OpenJDK maintainers don't want this
change but this list is obviously biased towards the developers of the
OpenJDK and not its users. So from your (and Alan's and Lance's) point of
view does it still make sense to create a JEP for this enhancement and have
a broader discussion about its usefulness on the "discuss" list? Or is your
rejection definitive, no matter what the outcome of such a discussion will
be?

Thank you and best regards,
Volker

On Fri, Jul 24, 2020 at 10:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> On 7/24/2020 7:48 AM, Volker Simonis wrote:
>
> I think it's reasonable to ask if the JDK
> really needs to support this complexity.
>
> I can't see much complexity here.
>
>
> Then I think we should start there.   Until you can see the complexity
> here that is obvious to Alan, Lance, myself, and others, then there is no
> point discussing the specific technical issue.
>
> Every configuration knob or flag creates complexity, because it creates a
> transient environmental dependence -- yet another thing that can cause
> behavior to change even when running the same JDK on the same underlying
> platform.
>
> I think you are looking at _your patch_ and saying "it's not that
> complex", but that's not the kind of complexity we're talking about.  We're
> talking about the number of potential axes that can interact with each
> other to cause surprising or hard-to-debug behavior.  Can you honestly not
> imagine something going wrong with having Inflater use one zlib, Deflator
> another, and crc32 a third?
>
> Until now I'm only hearing mostly high-level ,theoretical arguments
> against the proposal rather than technical objections.
>
>
> That's like when your mother tells you not to run with scissors,
> complaining that her concern is only theoretical, because not only do we
> not know anyone who has injured themselves running with scissors, but even
> if we did, they were not running with THIS pair of scissors."  But of
> course, your mother was right, and Alan (and all the others that reponded)
> are right too.  One of the most important roles of JDK stewards is pushing
> back on unnecessary complexity.  This is what Alan is doing.
>
> The change itself is quite small
>
>
> Small changes can still introduce complexity.  (It's one line of code to
> enforce that methods in Java only have an odd number of checked exceptions
> on tuesdays, but that would surely be new complexity.)
>
> and it doesn't change any default
> behaviour at all so I didn't think a JEP will be required.
>
>
> Which means either it will not be tested, or we have to double the number
> of test modes.
>

The proposed dispatching mechanism should obviously be tested and it should
work flawlessly. But every customer who will use or everybody who will ship
or bundle a combination of alternative libraries will just as obviously
have to test them. Or is Oracle testing all the available native Java
agents which a customer can use just because Java offers an interface which
allows native agents connecting to the VM?


>
> I don't think we have to test all (or even various) zlib
>
> which means customers using this will be running on an effectively
> untested configuration.  Does that seem wise?
>

See my comment above. I just propose to give customers the possibility to
use alternative configurations and I think that's wise. Nobody will ever
run in an untested configuration until he is actively choosing to do so
because he expects that the benefits will outweigh the risks.


> Stepping back, we're in the classic trap where you've skipped over all the
> important discussion, and as a result we've gotten the obvious outcome,
> which is that we're talking about the wrong thing.  Steps you should have
> run before getting tied to your solution, at a minimum, include:
>
>  - Develop a clear and shared understanding about what the problem is
>  - Develop consensus that it is a problem
>  - Develop consensus that it is a problem that needs to be solved in the
> JDK
>  - Brainstorm possible solutions, with tradeoffs, pros, and cons
>  - Identify the best solution, and build consensus around that
>  - Implement
>  - Test
>  - Review
>  - Iterate
>
> But you skipped straight to "Implement", and are now surprised that you're
> getting pushback against what should have been steps 1 or 2.  You are
> trying to drive the discussion to "what changes do I have to make to have
> this patch accepted", but the conversation we should be having is "should
> we solve this problem at all" and then "if so, is this the right
> solution."  And it seems you're not finding anyone who is very compelled by
> either the problem or the solution.
>
> I realize it sucks when you've done a lot of work and someone says "but we
> don't want/need that"; this is why you socialize the idea first.  Alan said
> in his first mail "I don't think the JDK should be in the business of ..."
> -- that's a clear "this is not a problem that needs to be solved in the
> JDK."  That's why we start at the top of the list.
>
>
 That's simply not true. I've developed this change to solve a real problem
and while doing so I went through all the points you've listed above. I'm
quite happy with it because we're using it productively with good results.
I've just proposed it here because I thought it might be useful for others
as well but if that's not the case it's perfectly fine for me.

From justin.dekeyser at gmail.com  Mon Jul 27 10:47:50 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Mon, 27 Jul 2020 12:47:50 +0200
Subject: Type inference: bug or feature?
In-Reply-To: <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
Message-ID: <CAO5-QM1Eb83asq_ApdUJLH6KhiScF7C9iPrQXfBgxtC1N-aM2w@mail.gmail.com>

Dear all,

Okay, thank you very much for the many references you gave me!
Indeed I wasn't aware of this specificity of cast expressions you
mentioned, very interesting !

Sorry for the long email chain, though!

Have a nice day,

Justin Dekeyser


On Mon, Jul 27, 2020 at 12:26 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> CC'ing compiler-dev
>
> Hi Justin,
> the behavior you are observing is normal. For a Java expression to be
> able to be influenced by type inference it has to be a poly expression
> (where poly stands for _many_ as in, the same expression can have many
> types).
>
> At the time we did Java 8 we briefly considered making cast expressions
> part of the poly expression dance (like lambdas, method references,
> method calls, parens, new creation expression, conditionals and switch
> expression - see JLS 15.2), but the rule which dictate cast conversion
> (JLS 5.5) are so complex (as they have to take into account possibility
> for unchecked cast, etc.) that it felt like touching them was a very
> risky move, with no clear benefit.
>
> The behavior you see is caused by the fact that the cast expression acts
> as a "shield" - that is, whenever a method call appears after a cast
> expression (as in your case), the method call is type-checked as if it
> were in isolation, and _then_ the result of type checking is validated
> against the cast. In other words, your example is no different than doing:
>
> var x = (List<Integer>)(Object)emptyList(Number.class);
>
>
> That is, the emptyList call will see no meaningful target type (just
> Object), so Number will be inferred and a List<Number> will be returned,
> which will then be incompatible with the type of the cast expression
> (List<Integer>).
>
> Your second set of examples, since it does not make use of cast
> expressions, works as expected, as the target type can freely flow
> inside the method call typing, and thus influence the type inference
> result (e.g. the inference engine now sees two constraints, for Integer
> and for Number, and is of course able to pick the "best" one).
>
> Hope this helps.
>
> Cheers
> Maurizio
>
> On 26/07/2020 18:22, Justin Dekeyser wrote:
> > Dear all,
> >
> > I'm not sure but I think I've found a bug in Java type inference
> mechanism.
> > It may also be a feature, so I'll expose the problem to you below; in
> terms
> > of Integer, Number and List, although you'll quickly realize it will work
> > wrong in any similar situation.
> >
> > Let's assume I have
> >
> > static <U, V extends U> List<U> emptyList(Class<U> magnet) {
> >     return Collections.emptyList();
> > }
> >
> > Then the following codes does not compile (for the same reason):
> >
> > var x = (List<Integer>) emptyList(Number.class);
> > List<Integer> x = (List<Integer>) emptyList(Number.class);
> >
> > incompatible types: List<Number> cannot be converted to List<Integer>
> >
> > however, the following do compile:
> >
> > var x = emptyList(Number.class); // inferred to List<Number>
> > List<Integer> x = emptyList(Number.class); // no mistake here, it's
> Integer
> > on the left
> >
> > Is this the expected behavior? Why does casting operation here interfere
> > with type inference like this?
> >
> > Regards,
> >
> > Justin Dekeyser
> >
> >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > Garanti
> > sans virus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

From forax at univ-mlv.fr  Mon Jul 27 10:54:57 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 27 Jul 2020 12:54:57 +0200 (CEST)
Subject: Type inference: bug or feature?
In-Reply-To: <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
Message-ID: <987448180.133479.1595847297819.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> ?: "Justin Dekeyser" <justin.dekeyser at gmail.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 27 Juillet 2020 12:26:40
> Objet: Re: Type inference: bug or feature?

> CC'ing compiler-dev
> 
> Hi Justin,
> the behavior you are observing is normal. For a Java expression to be
> able to be influenced by type inference it has to be a poly expression
> (where poly stands for _many_ as in, the same expression can have many
> types).
> 
> At the time we did Java 8 we briefly considered making cast expressions
> part of the poly expression dance (like lambdas, method references,
> method calls, parens, new creation expression, conditionals and switch
> expression - see JLS 15.2), but the rule which dictate cast conversion
> (JLS 5.5) are so complex (as they have to take into account possibility
> for unchecked cast, etc.) that it felt like touching them was a very
> risky move, with no clear benefit.

There was another reason :)

The idea behind introducing generics is to get ride of casts because they are a hazard at runtime.
So allowing people to use casts as poly expression goes in the wrong direction, add more casts.

Instead of using a cast, it's better to use explicit type arguments,
  TheClass.<TheTypeYouWantHere>emptyList()

[...]

> 
> Cheers
> Maurizio

regards,
R?mi

> 
> On 26/07/2020 18:22, Justin Dekeyser wrote:
>> Dear all,
>>
>> I'm not sure but I think I've found a bug in Java type inference mechanism.
>> It may also be a feature, so I'll expose the problem to you below; in terms
>> of Integer, Number and List, although you'll quickly realize it will work
>> wrong in any similar situation.
>>
>> Let's assume I have
>>
>> static <U, V extends U> List<U> emptyList(Class<U> magnet) {
>>     return Collections.emptyList();
>> }
>>
>> Then the following codes does not compile (for the same reason):
>>
>> var x = (List<Integer>) emptyList(Number.class);
>> List<Integer> x = (List<Integer>) emptyList(Number.class);
>>
>> incompatible types: List<Number> cannot be converted to List<Integer>
>>
>> however, the following do compile:
>>
>> var x = emptyList(Number.class); // inferred to List<Number>
>> List<Integer> x = emptyList(Number.class); // no mistake here, it's Integer
>> on the left
>>
>> Is this the expected behavior? Why does casting operation here interfere
>> with type inference like this?
>>
>> Regards,
>>
>> Justin Dekeyser
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> Garanti
>> sans virus. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From justin.dekeyser at gmail.com  Mon Jul 27 11:19:37 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Mon, 27 Jul 2020 13:19:37 +0200
Subject: Type inference: bug or feature?
In-Reply-To: <987448180.133479.1595847297819.JavaMail.zimbra@u-pem.fr>
References: <CAO5-QM2a92ejpGjyOLMwGMq-1YexHq3tSvv7K_r2mojW7OUceQ@mail.gmail.com>
 <939bf719-2414-b1c9-ac03-7de8b441e638@oracle.com>
 <987448180.133479.1595847297819.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAO5-QM3RDbpuazJrZBU-9K_PmCDGGnOd65RfpxXp-8KNcmJ45Q@mail.gmail.com>

Hello,

Thank you for your input!
Indeed, the reason of such a choice sounds legit and confirms the idea of
having more safety.

I just came with this situation while playing around with Java, and I was
surprised;
But it definitely was an academic example that was not planned for real use
cases! ;-)

Thank you very much,

Have a nice day,

Justin Dekeyser



On Mon, Jul 27, 2020 at 12:55 PM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Mail original -----
> > De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> > ?: "Justin Dekeyser" <justin.dekeyser at gmail.com>, "core-libs-dev" <
> core-libs-dev at openjdk.java.net>
> > Envoy?: Lundi 27 Juillet 2020 12:26:40
> > Objet: Re: Type inference: bug or feature?
>
> > CC'ing compiler-dev
> >
> > Hi Justin,
> > the behavior you are observing is normal. For a Java expression to be
> > able to be influenced by type inference it has to be a poly expression
> > (where poly stands for _many_ as in, the same expression can have many
> > types).
> >
> > At the time we did Java 8 we briefly considered making cast expressions
> > part of the poly expression dance (like lambdas, method references,
> > method calls, parens, new creation expression, conditionals and switch
> > expression - see JLS 15.2), but the rule which dictate cast conversion
> > (JLS 5.5) are so complex (as they have to take into account possibility
> > for unchecked cast, etc.) that it felt like touching them was a very
> > risky move, with no clear benefit.
>
> There was another reason :)
>
> The idea behind introducing generics is to get ride of casts because they
> are a hazard at runtime.
> So allowing people to use casts as poly expression goes in the wrong
> direction, add more casts.
>
> Instead of using a cast, it's better to use explicit type arguments,
>   TheClass.<TheTypeYouWantHere>emptyList()
>
> [...]
>
> >
> > Cheers
> > Maurizio
>
> regards,
> R?mi
>
> >
> > On 26/07/2020 18:22, Justin Dekeyser wrote:
> >> Dear all,
> >>
> >> I'm not sure but I think I've found a bug in Java type inference
> mechanism.
> >> It may also be a feature, so I'll expose the problem to you below; in
> terms
> >> of Integer, Number and List, although you'll quickly realize it will
> work
> >> wrong in any similar situation.
> >>
> >> Let's assume I have
> >>
> >> static <U, V extends U> List<U> emptyList(Class<U> magnet) {
> >>     return Collections.emptyList();
> >> }
> >>
> >> Then the following codes does not compile (for the same reason):
> >>
> >> var x = (List<Integer>) emptyList(Number.class);
> >> List<Integer> x = (List<Integer>) emptyList(Number.class);
> >>
> >> incompatible types: List<Number> cannot be converted to List<Integer>
> >>
> >> however, the following do compile:
> >>
> >> var x = emptyList(Number.class); // inferred to List<Number>
> >> List<Integer> x = emptyList(Number.class); // no mistake here, it's
> Integer
> >> on the left
> >>
> >> Is this the expected behavior? Why does casting operation here interfere
> >> with type inference like this?
> >>
> >> Regards,
> >>
> >> Justin Dekeyser
> >>
> >>
> >>
> >>
> >> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> >> Garanti
> >> sans virus. www.avast.com
> >> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

From sgehwolf at redhat.com  Mon Jul 27 15:32:54 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 27 Jul 2020 17:32:54 +0200
Subject: No way to disable Java Container Metrics
In-Reply-To: <BBD758E1-6157-4144-86D7-A274D26702E3@oracle.com>
References: <be6ec1f41119684cb9e6eb9acf1f85163c6489b6.camel@redhat.com>
 <BBD758E1-6157-4144-86D7-A274D26702E3@oracle.com>
Message-ID: <b51d4798f6bd1c24dbdc9ff98cae805569cc908d.camel@redhat.com>

Hi Bob,

On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> I?ve been monitoring the discussion on your jdk8u alias and I can?t help wondering if
> my original decision to provide two different implementations of this container detection
> logic was the best way to go.
> 
> I didn?t want to have an all Java implementation since the VM needs to initialize it?s
> memory and cpu sizing very early on prior to its ability to run Java code.
> 
> If we put all of the logic in the VM, then we?d end up with a pretty wide interface to
> the VM and more overhead extracting values (due to JNI) although the Java logic 
> typically ends up in native code anyway.  Having the functionality in the VM
> makes it easier to add JFR events.  Having a pure Java implementation makes it
> easier to support the OS MBeans.  The maintenance of supporting both implementations
> is a bit of a pain.

Add to that that Java metrics return non-null for any controller it
finds. The JVM doesn't. Container support is turned on there only if
all cpu and memory controllers are found.

> Assuming no one has the time or desire to migrate the logic to the VM and provide
> Java wrapper logic, I?m ok with what you are proposing.  It?s one step on the path.
> The VM support and the Java level support are really for two different consumers
> but I think it would be cleaner and less confusing to disable both on one flag rather
> than support two options.

OK, agreed. I've filed:
https://bugs.openjdk.java.net/browse/JDK-8250627

Thanks,
Severin

> Bob.
> 
> > On Jul 24, 2020, at 12:13 PM, Severin Gehwolf <sgehwolf at redhat.com>
> > wrote:
> > 
> > Hi,
> > 
> > For hotspot one can disable container detection with a simple
> > switch:
> > 
> > $ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
> > [0.000s][trace][os,container] OSContainer::init: Initializing
> > Container Support
> > [0.000s][trace][os,container] Container Support not enabled
> > openjdk version "15-internal" 2020-09-15
> > OpenJDK Runtime Environment (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2)
> > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> > 
> > The same cannot be achieved with the Java code,
> > jdk.internal.platform.Metrics.java and friends in the JDK. At the
> > time
> > Metrics were added the only consumer of them was the Java Launcher
> > via
> > -XshowSettings:system. This has changed with JDK-8226575:
> > OperatingSystemMXBean should be made container aware.
> > 
> > It is known that in certain cases the container detection code will
> > detect for a system to be supposedly in a container where it
> > actually
> > isn't:
> > https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
> > 
> > For hotspot there is a flag, to turn auto-detection off for exactly
> > the
> > case when heuristics are wrong: -XX:-UseContainerSupport. However,
> > this
> > flag has no effect on the Java metrics code. There is a risk that
> > on
> > some systems the auto-detection will be wrong and might cause
> > regressions.
> > 
> > I propose to make the Java metrics code adhere to -XX:+/-
> > UseContainerSupport flag. Do you think this would be useful? If
> > yes,
> > I'll file a bug and propose a patch for it.
> > 
> > Thoughts? Opinions?
> > 
> > Thanks,
> > Severin
> > 


From bob.vandette at oracle.com  Mon Jul 27 15:52:53 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 27 Jul 2020 11:52:53 -0400
Subject: No way to disable Java Container Metrics
In-Reply-To: <b51d4798f6bd1c24dbdc9ff98cae805569cc908d.camel@redhat.com>
References: <be6ec1f41119684cb9e6eb9acf1f85163c6489b6.camel@redhat.com>
 <BBD758E1-6157-4144-86D7-A274D26702E3@oracle.com>
 <b51d4798f6bd1c24dbdc9ff98cae805569cc908d.camel@redhat.com>
Message-ID: <811D4028-B350-4BF7-B963-5318DCE05820@oracle.com>



> On Jul 27, 2020, at 11:32 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> Hi Bob,
> 
> On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
>> I?ve been monitoring the discussion on your jdk8u alias and I can?t help wondering if
>> my original decision to provide two different implementations of this container detection
>> logic was the best way to go.
>> 
>> I didn?t want to have an all Java implementation since the VM needs to initialize it?s
>> memory and cpu sizing very early on prior to its ability to run Java code.
>> 
>> If we put all of the logic in the VM, then we?d end up with a pretty wide interface to
>> the VM and more overhead extracting values (due to JNI) although the Java logic 
>> typically ends up in native code anyway.  Having the functionality in the VM
>> makes it easier to add JFR events.  Having a pure Java implementation makes it
>> easier to support the OS MBeans.  The maintenance of supporting both implementations
>> is a bit of a pain.
> 
> Add to that that Java metrics return non-null for any controller it
> finds. The JVM doesn't. Container support is turned on there only if
> all cpu and memory controllers are found.

That was intentional.  I wanted the VM to configure itself consistently.
Either all needed value are present or revert to non container mode.
For Metrics, I felt it was ok to report whatever is available.

Bob.


> 
>> Assuming no one has the time or desire to migrate the logic to the VM and provide
>> Java wrapper logic, I?m ok with what you are proposing.  It?s one step on the path.
>> The VM support and the Java level support are really for two different consumers
>> but I think it would be cleaner and less confusing to disable both on one flag rather
>> than support two options.
> 
> OK, agreed. I've filed:
> https://bugs.openjdk.java.net/browse/JDK-8250627
> 
> Thanks,
> Severin
> 
>> Bob.
>> 
>>> On Jul 24, 2020, at 12:13 PM, Severin Gehwolf <sgehwolf at redhat.com>
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> For hotspot one can disable container detection with a simple
>>> switch:
>>> 
>>> $ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
>>> [0.000s][trace][os,container] OSContainer::init: Initializing
>>> Container Support
>>> [0.000s][trace][os,container] Container Support not enabled
>>> openjdk version "15-internal" 2020-09-15
>>> OpenJDK Runtime Environment (build 15-internal+0-
>>> adhoc.sgehwolf.openjdk-head-2)
>>> OpenJDK 64-Bit Server VM (build 15-internal+0-
>>> adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
>>> 
>>> The same cannot be achieved with the Java code,
>>> jdk.internal.platform.Metrics.java and friends in the JDK. At the
>>> time
>>> Metrics were added the only consumer of them was the Java Launcher
>>> via
>>> -XshowSettings:system. This has changed with JDK-8226575:
>>> OperatingSystemMXBean should be made container aware.
>>> 
>>> It is known that in certain cases the container detection code will
>>> detect for a system to be supposedly in a container where it
>>> actually
>>> isn't:
>>> https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
>>> 
>>> For hotspot there is a flag, to turn auto-detection off for exactly
>>> the
>>> case when heuristics are wrong: -XX:-UseContainerSupport. However,
>>> this
>>> flag has no effect on the Java metrics code. There is a risk that
>>> on
>>> some systems the auto-detection will be wrong and might cause
>>> regressions.
>>> 
>>> I propose to make the Java metrics code adhere to -XX:+/-
>>> UseContainerSupport flag. Do you think this would be useful? If
>>> yes,
>>> I'll file a bug and propose a patch for it.
>>> 
>>> Thoughts? Opinions?
>>> 
>>> Thanks,
>>> Severin
>>> 
> 


From sgehwolf at redhat.com  Mon Jul 27 16:06:23 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 27 Jul 2020 18:06:23 +0200
Subject: No way to disable Java Container Metrics
In-Reply-To: <811D4028-B350-4BF7-B963-5318DCE05820@oracle.com>
References: <be6ec1f41119684cb9e6eb9acf1f85163c6489b6.camel@redhat.com>
 <BBD758E1-6157-4144-86D7-A274D26702E3@oracle.com>
 <b51d4798f6bd1c24dbdc9ff98cae805569cc908d.camel@redhat.com>
 <811D4028-B350-4BF7-B963-5318DCE05820@oracle.com>
Message-ID: <bd7b6bf9d9f0797256cb7008c855c793c2666119.camel@redhat.com>

On Mon, 2020-07-27 at 11:52 -0400, Bob Vandette wrote:
> > On Jul 27, 2020, at 11:32 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > 
> > Hi Bob,
> > 
> > On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> > > I?ve been monitoring the discussion on your jdk8u alias and I can?t help wondering if
> > > my original decision to provide two different implementations of this container detection
> > > logic was the best way to go.
> > > 
> > > I didn?t want to have an all Java implementation since the VM needs to initialize it?s
> > > memory and cpu sizing very early on prior to its ability to run Java code.
> > > 
> > > If we put all of the logic in the VM, then we?d end up with a pretty wide interface to
> > > the VM and more overhead extracting values (due to JNI) although the Java logic 
> > > typically ends up in native code anyway.  Having the functionality in the VM
> > > makes it easier to add JFR events.  Having a pure Java implementation makes it
> > > easier to support the OS MBeans.  The maintenance of supporting both implementations
> > > is a bit of a pain.
> > 
> > Add to that that Java metrics return non-null for any controller it
> > finds. The JVM doesn't. Container support is turned on there only if
> > all cpu and memory controllers are found.
> 
> That was intentional.  I wanted the VM to configure itself consistently.
> Either all needed value are present or revert to non container mode.
> For Metrics, I felt it was ok to report whatever is available.

Yes, I know. Thanks. What I meant to say was that it's another
consideration to take into account if at some point a JVM-only-impl +
Java wrapper approach would be taken.

Thanks,
Severin
> 
> 
> > > Assuming no one has the time or desire to migrate the logic to
> > > the VM and provide
> > > Java wrapper logic, I?m ok with what you are proposing.  It?s one
> > > step on the path.
> > > The VM support and the Java level support are really for two
> > > different consumers
> > > but I think it would be cleaner and less confusing to disable
> > > both on one flag rather
> > > than support two options.
> > 
> > OK, agreed. I've filed:
> > https://bugs.openjdk.java.net/browse/JDK-8250627
> > 
> > Thanks,
> > Severin
> > 
> > > Bob.
> > > 
> > > > On Jul 24, 2020, at 12:13 PM, Severin Gehwolf <
> > > > sgehwolf at redhat.com>
> > > > wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > For hotspot one can disable container detection with a simple
> > > > switch:
> > > > 
> > > > $ java -XX:-UseContainerSupport -Xlog:os+container=trace
> > > > -version
> > > > [0.000s][trace][os,container] OSContainer::init: Initializing
> > > > Container Support
> > > > [0.000s][trace][os,container] Container Support not enabled
> > > > openjdk version "15-internal" 2020-09-15
> > > > OpenJDK Runtime Environment (build 15-internal+0-
> > > > adhoc.sgehwolf.openjdk-head-2)
> > > > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > > > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> > > > 
> > > > The same cannot be achieved with the Java code,
> > > > jdk.internal.platform.Metrics.java and friends in the JDK. At
> > > > the
> > > > time
> > > > Metrics were added the only consumer of them was the Java
> > > > Launcher
> > > > via
> > > > -XshowSettings:system. This has changed with JDK-8226575:
> > > > OperatingSystemMXBean should be made container aware.
> > > > 
> > > > It is known that in certain cases the container detection code
> > > > will
> > > > detect for a system to be supposedly in a container where it
> > > > actually
> > > > isn't:
> > > > https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
> > > > 
> > > > For hotspot there is a flag, to turn auto-detection off for
> > > > exactly
> > > > the
> > > > case when heuristics are wrong: -XX:-UseContainerSupport.
> > > > However,
> > > > this
> > > > flag has no effect on the Java metrics code. There is a risk
> > > > that
> > > > on
> > > > some systems the auto-detection will be wrong and might cause
> > > > regressions.
> > > > 
> > > > I propose to make the Java metrics code adhere to -XX:+/-
> > > > UseContainerSupport flag. Do you think this would be useful? If
> > > > yes,
> > > > I'll file a bug and propose a patch for it.
> > > > 
> > > > Thoughts? Opinions?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 


From igor.ignatyev at oracle.com  Mon Jul 27 18:17:38 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 27 Jul 2020 11:17:38 -0700
Subject: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on
 Windows
In-Reply-To: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>
References: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>
Message-ID: <B3D3781C-B4A6-4A3D-9579-9574C7F9D439@oracle.com>

ping?

-- Igor

> On Jul 20, 2020, at 11:28 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00
>> 98 lines changed: 18 ins; 31 del; 49 mod;
> 
> Hi all,
> 
> could you please review this small fix to make java/io/File/GetXSpace.java work again on windows?
> 
> the test has been updated to work under cygwin, which includes the following changes:
> - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
> - uses the same regexp to parse df on windows as on other platforms
> - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is corresponding windows path, and the test expect Space's name to be appropriate path
> 
> the patch also includes some small faceliftings:
> - printing out a bit more information to facilitate failure analyses, e.g. df output, exception stack traces
> - usage of try-w/-resources
> - remove of code duplication
> - usage of generics
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00
> testing: java/io/File/GetXSpace.java 100 times on {linux,windows}-x64
> JBS: https://bugs.openjdk.java.net/browse/JDK-6501010
> 
> Thanks,
> -- Igor


From naoto.sato at oracle.com  Mon Jul 27 18:51:02 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 27 Jul 2020 11:51:02 -0700
Subject: RFR: 8247546: Pattern matching does not skip correctly over
 supplementary characters
Message-ID: <7e5d9751-737e-deea-45e0-7684726bc3ff@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8247546/webrev.00/

On compiling the regex pattern, the start node is chosen based on the 
pattern, i.e, whether it involves supplementary processing or not. On 
deciding which implementation to use, surrogates were not taken into 
consideration, which leads to the issue in the bug report. The proposed 
fix is to make it aware of surrogates, and choose the correct 
supplementary-aware implementation for the start node.

Apart from the original issue, there was a bug in Range() method 
(Pattern.java:5795), so it is fixed along.

Naoto

From brian.goetz at oracle.com  Mon Jul 27 19:37:34 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 27 Jul 2020 15:37:34 -0400
Subject: RFR(M): 8249963: Make the zlib implementation selectively
 configurable at startup
In-Reply-To: <CA+3eh13qShsjwv3CO5TPse7nwHtn1acCjo+o4h-rBODyH_4TPw@mail.gmail.com>
References: <CA+3eh13-2SaeR-+TD4upFOY+nFieukc5nNKg8+7xZHZqHrGSkw@mail.gmail.com>
 <9f8c11c4-7a8b-2f49-b977-96dbf9298c87@oracle.com>
 <CA+3eh12o70E9-GtaV3-rk5+LPRVddc2Mqw_MUgdipPvo8REaJg@mail.gmail.com>
 <8341dc8c-1f77-219e-a308-f4e2eb473c39@oracle.com>
 <CA+3eh13qShsjwv3CO5TPse7nwHtn1acCjo+o4h-rBODyH_4TPw@mail.gmail.com>
Message-ID: <e199488f-4869-a6e3-a56d-60710f6889d6@oracle.com>


> So from your (and Alan's and Lance's) point of view does it still make 
> sense to create a JEP for this enhancement and have a broader 
> discussion about its usefulness on the "discuss" list? Or is your 
> rejection definitive, no matter what the outcome of such a discussion 
> will be?

I think it's perfectly fine to start a discussion.? I wouldn't start 
with a JEP draft, though, as that will have many of the same problems 
that the RFR did.? You'll want to start with what you see as the 
problem, why it is a problem, why it needs to be solved in the JDK, etc, 
and then proceed to evaluating solutions, as I outlined in my mail, and 
build consensus at each step.

Given the discussions we've had already, it seems highly unlikely that a 
JEP that enshrined _this exact solution_ would gain consensus.? But, it 
is entirely possible that an open-minded discussion of the problem and 
the many possible solutions, might lead to a solution that you could 
build some consensus around.? (Or it might not; that's OK too.)

>
>
>     I realize it sucks when you've done a lot of work and someone says
>     "but we don't want/need that"; this is why you socialize the idea
>     first.? Alan said in his first mail "I don't think the JDK should
>     be in the business of ..." -- that's a clear "this is not a
>     problem that needs to be solved in the JDK."? That's why we start
>     at the top of the list.
>
>
> That's simply not true. I've developed this change to solve a real 
> problem and while doing so I went through all the points you've listed 
> above. I'm quite happy with it because we're using it productively 
> with good results. I've just proposed it here because I thought it 
> might be useful for others as well but if that's not the case it's 
> perfectly fine for me.
>

I will answer this one as it speaks to a common mis-assumption about 
OpenJDK.? You obviously had some variant of the problem+solutions 
discussion internally on your team, and came to a solution that worked 
in your situation.? That's all good!? But, you should be prepared to 
start back at the beginning if you want to change "everybody's Java"; 
the set of considerations for a feature in a given deployment or even 
distribution are not the same as for the upstream, so the discussion 
might go differently.? (In particular, the answer to "is this a problem 
that needs to be solved in <distribution>" may well vary with 
<distribution>.)



From vipinsharma85 at gmail.com  Mon Jul 27 19:37:39 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Tue, 28 Jul 2020 01:07:39 +0530
Subject: Fix for Javadoc errors in java.base
Message-ID: <CAGRQqB4WS=uLURsLOYpL04fHdSi+VB3HyY5Dx9sx2Y+n=+tPcw@mail.gmail.com>

Hi,

This patch fixes Javadoc errors in java.base, please sponsor this patch and
help to create a bug id for this.
I have signed OCA, this is my third patch.

---
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:21.233726447 +0530
+++
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
      * @param p the prime modulus
      * @param g the base generator
      * @param l the private-value length
-     *
-     * @exception InvalidKeyException if the key cannot be encoded
      */
     DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) {
         this.x = x;
---
old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
2020-07-25 23:46:22.241737383 +0530
+++
new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
2020-07-25 23:46:21.745732013 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2012, 2020, 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
@@ -208,7 +208,7 @@
      *
      * @return a CallSite, which, when invoked, will return an instance of
the
      * functional interface
-     * @throws ReflectiveOperationException
+     * @throws LambdaConversionException
      */
     abstract CallSite buildCallSite()
             throws LambdaConversionException;
---
old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
2020-07-25 23:46:23.261748361 +0530
+++
new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
2020-07-25 23:46:22.761742991 +0530
@@ -200,7 +200,6 @@
      *
      * @return a CallSite, which, when invoked, will return an instance of
the
      * functional interface
-     * @throws ReflectiveOperationException
      * @throws LambdaConversionException If properly formed functional
interface
      * is not found
      */
--- old/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
23:46:24.285759291 +0530
+++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
23:46:23.785753966 +0530
@@ -5413,7 +5413,7 @@
      *
      * @param n the numerator; must be negative
      * @param d the denominator; must not be unity
-     * @return a two-element {@long} array with the remainder and quotient
in
+     * @return a two-element {@code long} array with the remainder and
quotient in
      *         the initial and final elements, respectively
      */
     private static long[] divRemNegativeLong(long n, long d) {
--- old/src/java.base/share/classes/java/math/MutableBigInteger.java
2020-07-25 23:46:25.381770889 +0530
+++ new/src/java.base/share/classes/java/math/MutableBigInteger.java
2020-07-25 23:46:24.877765572 +0530
@@ -145,7 +145,6 @@
      * Makes this number an {@code n}-int number all of whose bits are
ones.
      * Used by Burnikel-Ziegler division.
      * @param n number of ints in the {@code value} array
-     * @return a number equal to {@code ((1<<(32*n)))-1}
      */
     private void ones(int n) {
         if (n > value.length)
--- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
23:46:26.449782093 +0530
+++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
23:46:25.937776742 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2020, 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
@@ -315,7 +315,7 @@
     /**
      * Creates the socket implementation.
      *
-     * @throws IOException if creation fails
+     * @throws SocketException if creation fails
      * @since 1.4
      */
     void createImpl() throws SocketException {
--- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25
23:46:27.485792869 +0530
+++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25
23:46:26.973787565 +0530
@@ -533,7 +533,7 @@
      *
      * @param stream a {@code boolean} value : {@code true} for a TCP
socket,
      *               {@code false} for UDP.
-     * @throws IOException if creation fails
+     * @throws SocketException if creation fails
      * @since 1.4
      */
      void createImpl(boolean stream) throws SocketException {
---
old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
2020-07-25 23:46:28.545803801 +0530
+++
new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
2020-07-25 23:46:28.029798501 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2020, 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
@@ -773,7 +773,7 @@
      * an "annotation structure" OR two bytes into an annotation
      * structure (i.e., after the type index).
      *
-     * @parameter complete true if the byte buffer points to the beginning
+     * @param complete true if the byte buffer points to the beginning
      *     of an annotation structure (rather than two bytes in).
      */
     private static void skipAnnotation(ByteBuffer buf, boolean complete) {


Regards,
Vipin

From ningsheng.jian at arm.com  Mon Jul 27 01:58:38 2020
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Mon, 27 Jul 2020 09:58:38 +0800
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
 <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>
 <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com>
Message-ID: <942c4be0-4f5d-acd6-86ae-e6769215ca37@arm.com>

Thank you Erik!

Regards,
Ningsheng

On 7/23/20 9:06 PM, Erik Joelsson wrote:
> Hello Ningsheng,
> 
> Build change looks good.
> 
> /Erik
> 
> On 2020-07-23 01:02, Ningsheng Jian wrote:
>> Hi Vladimir,
>>
>> Thanks for pointing out this. Yes, I missed that change in shared 
>> code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
>> included:
>>
>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>>
>>
>> Also add build-dev.
>>
>> Thanks,
>> Ningsheng
>>
>> On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>>>
>>>
>>>
>>>
>>> FTR there's one more aarch64-specific change in shared code to enable 
>>> aarch64_neon.ad processing:
>>>
>>> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
>>> b/make/hotspot/gensrc/GensrcAdlc.gmk
>>> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
>>> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
>>> @@ -129,6 +129,12 @@
>>>
>>> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
>>> \
>>> ????? )))
>>>
>>> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
>>> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>>> $(AD_SRC_ROOTS), \
>>> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
>>> +??? )))
>>> +? endif
>>> +
>>> ??? ifeq ($(call check-jvm-feature, shenandoahgc), true)
>>> ????? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>>> $(AD_SRC_ROOTS), \
>>>
>>> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
>>> \
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> On 7/8/20 3:05 PM, Yang Zhang wrote:
>>>>> Hi Andrew
>>>>>
>>>>> I have updated this patch. Could you please help to review it again?
>>>>> In this patch, the following changes are made:
>>>>> 1. Separate newly added NEON instructions to a new ad file
>>>>> ??? aarch64_neon.ad
>>>>> 2. Add assembler tests for NEON instructions. Trailing spaces
>>>>> ??? in the python script are also removed.
>>>>>
>>>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Yang
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Haley <aph at redhat.com>
>>>>> Sent: Tuesday, June 30, 2020 12:10 AM
>>>>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>>>>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>>>>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>>>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>>>>> aarch64-port-dev at openjdk.java.net
>>>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>>>>> Vector API (Incubator): AArch64 backend changes
>>>>>
>>>>> On 29/06/2020 08:48, Yang Zhang wrote:
>>>>>> 1. Instructions that can be matched with NEON instructions directly.
>>>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>>>>
>>>>>> 2. Instructions that jdk master has middle end support for, but 
>>>>>> they cannot be matched with NEON instructions directly.
>>>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>>>>> new instructions can be moved into jdk master first, but for 
>>>>>> auto-vectorization, the performance might not get improved.
>>>>>>
>>>>>> 3. Panama/Vector API specific? instructions such as 
>>>>>> Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
>>>>>> MaxV/MinV, VectorBlend etc.
>>>>>> These instructions cannot be moved into jdk master first because 
>>>>>> there isn't middle-end support.
>>>>>>
>>>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>>>>> ready, I will send it again.
>>>>>
>>>>> Thank you *very* much for your hard work. Appreciated!
>>>>>
>>>>> -- 
>>>>> 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 naoto.sato at oracle.com  Mon Jul 27 21:18:53 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 27 Jul 2020 14:18:53 -0700
Subject: RFR: 8247546: Pattern matching does not skip correctly over
 supplementary characters
In-Reply-To: <7e5d9751-737e-deea-45e0-7684726bc3ff@oracle.com>
References: <7e5d9751-737e-deea-45e0-7684726bc3ff@oracle.com>
Message-ID: <5edd5d46-347d-363f-58ec-f61cd77c0de3@oracle.com>

On 7/27/20 11:51 AM, naoto.sato at oracle.com wrote:
> Apart from the original issue, there was a bug in Range() method 
> (Pattern.java:5795), so it is fixed along.

Created a test case for this:

--- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
+++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
@@ -149,6 +149,11 @@
  \ud83d\udca9
  false 0

+// @bug 8247546
+[\x{dc00}-\x{dfff}]
+\ud83d\udca9
+false 0
+
  // use of x modifier
  \ud800\udc61bc(?x)bl\ud800\udc61h
  \ud800\udc61bcbl\ud800\udc61h

Low surrogate range check falls into using BmpCharPredicate, which 
results in the same bug. The entire webrev is also revised:

http://cr.openjdk.java.net/~naoto/8247546/webrev.01/

Naoto

From joe.darcy at oracle.com  Tue Jul 28 00:21:17 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 27 Jul 2020 17:21:17 -0700
Subject: Fix for Javadoc errors in java.base
In-Reply-To: <CAGRQqB4WS=uLURsLOYpL04fHdSi+VB3HyY5Dx9sx2Y+n=+tPcw@mail.gmail.com>
References: <CAGRQqB4WS=uLURsLOYpL04fHdSi+VB3HyY5Dx9sx2Y+n=+tPcw@mail.gmail.com>
Message-ID: <193fee5f-ef90-1048-7455-8363a5e616b4@oracle.com>

Hello Vipin,

What tooling was used to find these errors? Running doclint against 
private methods too?

Thanks,

-Joe

On 7/27/2020 12:37 PM, Vipin Sharma wrote:
> Hi,
>
> This patch fixes Javadoc errors in java.base, please sponsor this patch and
> help to create a bug id for this.
> I have signed OCA, this is my third patch.
>
> ---
> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
> 2020-07-25 23:46:21.233726447 +0530
> +++
> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
> 2020-07-25 23:46:20.721720857 +0530
> @@ -96,8 +96,6 @@
>        * @param p the prime modulus
>        * @param g the base generator
>        * @param l the private-value length
> -     *
> -     * @exception InvalidKeyException if the key cannot be encoded
>        */
>       DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) {
>           this.x = x;
> ---
> old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> 2020-07-25 23:46:22.241737383 +0530
> +++
> new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> 2020-07-25 23:46:21.745732013 +0530
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2012, 2020, 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
> @@ -208,7 +208,7 @@
>        *
>        * @return a CallSite, which, when invoked, will return an instance of
> the
>        * functional interface
> -     * @throws ReflectiveOperationException
> +     * @throws LambdaConversionException
>        */
>       abstract CallSite buildCallSite()
>               throws LambdaConversionException;
> ---
> old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
> 2020-07-25 23:46:23.261748361 +0530
> +++
> new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
> 2020-07-25 23:46:22.761742991 +0530
> @@ -200,7 +200,6 @@
>        *
>        * @return a CallSite, which, when invoked, will return an instance of
> the
>        * functional interface
> -     * @throws ReflectiveOperationException
>        * @throws LambdaConversionException If properly formed functional
> interface
>        * is not found
>        */
> --- old/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
> 23:46:24.285759291 +0530
> +++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
> 23:46:23.785753966 +0530
> @@ -5413,7 +5413,7 @@
>        *
>        * @param n the numerator; must be negative
>        * @param d the denominator; must not be unity
> -     * @return a two-element {@long} array with the remainder and quotient
> in
> +     * @return a two-element {@code long} array with the remainder and
> quotient in
>        *         the initial and final elements, respectively
>        */
>       private static long[] divRemNegativeLong(long n, long d) {
> --- old/src/java.base/share/classes/java/math/MutableBigInteger.java
> 2020-07-25 23:46:25.381770889 +0530
> +++ new/src/java.base/share/classes/java/math/MutableBigInteger.java
> 2020-07-25 23:46:24.877765572 +0530
> @@ -145,7 +145,6 @@
>        * Makes this number an {@code n}-int number all of whose bits are
> ones.
>        * Used by Burnikel-Ziegler division.
>        * @param n number of ints in the {@code value} array
> -     * @return a number equal to {@code ((1<<(32*n)))-1}
>        */
>       private void ones(int n) {
>           if (n > value.length)
> --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
> 23:46:26.449782093 +0530
> +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
> 23:46:25.937776742 +0530
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1995, 2020, 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
> @@ -315,7 +315,7 @@
>       /**
>        * Creates the socket implementation.
>        *
> -     * @throws IOException if creation fails
> +     * @throws SocketException if creation fails
>        * @since 1.4
>        */
>       void createImpl() throws SocketException {
> --- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25
> 23:46:27.485792869 +0530
> +++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25
> 23:46:26.973787565 +0530
> @@ -533,7 +533,7 @@
>        *
>        * @param stream a {@code boolean} value : {@code true} for a TCP
> socket,
>        *               {@code false} for UDP.
> -     * @throws IOException if creation fails
> +     * @throws SocketException if creation fails
>        * @since 1.4
>        */
>        void createImpl(boolean stream) throws SocketException {
> ---
> old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
> 2020-07-25 23:46:28.545803801 +0530
> +++
> new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
> 2020-07-25 23:46:28.029798501 +0530
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2003, 2020, 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
> @@ -773,7 +773,7 @@
>        * an "annotation structure" OR two bytes into an annotation
>        * structure (i.e., after the type index).
>        *
> -     * @parameter complete true if the byte buffer points to the beginning
> +     * @param complete true if the byte buffer points to the beginning
>        *     of an annotation structure (rather than two bytes in).
>        */
>       private static void skipAnnotation(ByteBuffer buf, boolean complete) {
>
>
> Regards,
> Vipin

From huizhe.wang at oracle.com  Tue Jul 28 01:04:14 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 27 Jul 2020 18:04:14 -0700
Subject: RFR: 8247546: Pattern matching does not skip correctly over
 supplementary characters
In-Reply-To: <5edd5d46-347d-363f-58ec-f61cd77c0de3@oracle.com>
References: <7e5d9751-737e-deea-45e0-7684726bc3ff@oracle.com>
 <5edd5d46-347d-363f-58ec-f61cd77c0de3@oracle.com>
Message-ID: <8cd064ae-d9f3-57db-d654-bc44ae6e0442@oracle.com>

Hi Naoto,

Looks good to me, using the correct supplementary-aware implementation 
is an improvement for the impl to handle the situation.

A note (probably a workaround) for the user's case, to replace invalid 
surrogate characters, he could have used Unicode escape sequences 
[\ud800-\udfff] instead.

For the test, I wonder if it'd be better to combine the 1st and 2nd, 3rd 
and 4th cases into: xxx\udca9\ud83d\udca9\ud83dyyy to represent two lone 
surrogates plus a valid pair.

A minor comment on the comments of the test cases (in 
SupplementaryTestCases.txt): instead of repeating the bug id (that is: 
// @bug 8247546), it may be good to provide a short note (e.g. match 
lone/invalid surrogates).

Regards,
Joe

On 7/27/20 2:18 PM, naoto.sato at oracle.com wrote:
> On 7/27/20 11:51 AM, naoto.sato at oracle.com wrote:
>> Apart from the original issue, there was a bug in Range() method 
>> (Pattern.java:5795), so it is fixed along.
>
> Created a test case for this:
>
> --- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
> +++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
> @@ -149,6 +149,11 @@
> ?\ud83d\udca9
> ?false 0
>
> +// @bug 8247546
> +[\x{dc00}-\x{dfff}]
> +\ud83d\udca9
> +false 0
> +
> ?// use of x modifier
> ?\ud800\udc61bc(?x)bl\ud800\udc61h
> ?\ud800\udc61bcbl\ud800\udc61h
>
> Low surrogate range check falls into using BmpCharPredicate, which 
> results in the same bug. The entire webrev is also revised:
>
> http://cr.openjdk.java.net/~naoto/8247546/webrev.01/
>
> Naoto


From naoto.sato at oracle.com  Tue Jul 28 02:11:38 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 27 Jul 2020 19:11:38 -0700
Subject: RFR: 8247546: Pattern matching does not skip correctly over
 supplementary characters
In-Reply-To: <8cd064ae-d9f3-57db-d654-bc44ae6e0442@oracle.com>
References: <7e5d9751-737e-deea-45e0-7684726bc3ff@oracle.com>
 <5edd5d46-347d-363f-58ec-f61cd77c0de3@oracle.com>
 <8cd064ae-d9f3-57db-d654-bc44ae6e0442@oracle.com>
Message-ID: <5a59c1f9-f413-4eef-0e98-e484d2d13ea9@oracle.com>

Hi Joe,

Thank you for the review!

On 7/27/20 6:04 PM, Joe Wang wrote:
> Hi Naoto,
> 
> Looks good to me, using the correct supplementary-aware implementation 
> is an improvement for the impl to handle the situation.
> 
> A note (probably a workaround) for the user's case, to replace invalid 
> surrogate characters, he could have used Unicode escape sequences 
> [\ud800-\udfff] instead.

Yes.

> 
> For the test, I wonder if it'd be better to combine the 1st and 2nd, 3rd 
> and 4th cases into: xxx\udca9\ud83d\udca9\ud83dyyy to represent two lone 
> surrogates plus a valid pair.

If we combine test strings into the one mentioned above, I think it 
cannot distinguish the case we wanted to test. They all match with the 
first unpaired surrogate, i.e., \udca9.

> 
> A minor comment on the comments of the test cases (in 
> SupplementaryTestCases.txt): instead of repeating the bug id (that is: 
> // @bug 8247546), it may be good to provide a short note (e.g. match 
> lone/invalid surrogates).

Right, there is no reason to leave bug id since it can be found from hg 
log. Instead, I replaced them with more useful short notes.

Revised webrev:
https://cr.openjdk.java.net/~naoto/8247546/webrev.02/

Naoto

> 
> Regards,
> Joe
> 
> On 7/27/20 2:18 PM, naoto.sato at oracle.com wrote:
>> On 7/27/20 11:51 AM, naoto.sato at oracle.com wrote:
>>> Apart from the original issue, there was a bug in Range() method 
>>> (Pattern.java:5795), so it is fixed along.
>>
>> Created a test case for this:
>>
>> --- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
>> +++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
>> @@ -149,6 +149,11 @@
>> ?\ud83d\udca9
>> ?false 0
>>
>> +// @bug 8247546
>> +[\x{dc00}-\x{dfff}]
>> +\ud83d\udca9
>> +false 0
>> +
>> ?// use of x modifier
>> ?\ud800\udc61bc(?x)bl\ud800\udc61h
>> ?\ud800\udc61bcbl\ud800\udc61h
>>
>> Low surrogate range check falls into using BmpCharPredicate, which 
>> results in the same bug. The entire webrev is also revised:
>>
>> http://cr.openjdk.java.net/~naoto/8247546/webrev.01/
>>
>> Naoto
> 

From vipinsharma85 at gmail.com  Tue Jul 28 05:28:03 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Tue, 28 Jul 2020 10:58:03 +0530
Subject: Fix for Javadoc errors in java.base
In-Reply-To: <193fee5f-ef90-1048-7455-8363a5e616b4@oracle.com>
References: <CAGRQqB4WS=uLURsLOYpL04fHdSi+VB3HyY5Dx9sx2Y+n=+tPcw@mail.gmail.com>
 <193fee5f-ef90-1048-7455-8363a5e616b4@oracle.com>
Message-ID: <CAGRQqB6atNJzBGJGp9PoJvzxOFLz78f3RgLVsrFPasK25JCAcQ@mail.gmail.com>

Hi Joe,

I ran an IntelliJ inspection to find these errors.

Regards,
Vipin

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Jul 28, 2020 at 5:53 AM Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello Vipin,
>
> What tooling was used to find these errors? Running doclint against
> private methods too?
>
> Thanks,
>
> -Joe
>
> On 7/27/2020 12:37 PM, Vipin Sharma wrote:
> > Hi,
> >
> > This patch fixes Javadoc errors in java.base, please sponsor this patch
> and
> > help to create a bug id for this.
> > I have signed OCA, this is my third patch.
> >
> > ---
> > old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
> > 2020-07-25 23:46:21.233726447 +0530
> > +++
> > new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
> > 2020-07-25 23:46:20.721720857 +0530
> > @@ -96,8 +96,6 @@
> >        * @param p the prime modulus
> >        * @param g the base generator
> >        * @param l the private-value length
> > -     *
> > -     * @exception InvalidKeyException if the key cannot be encoded
> >        */
> >       DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) {
> >           this.x = x;
> > ---
> >
> old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> > 2020-07-25 23:46:22.241737383 +0530
> > +++
> >
> new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> > 2020-07-25 23:46:21.745732013 +0530
> > @@ -1,5 +1,5 @@
> >   /*
> > - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
> > reserved.
> > + * Copyright (c) 2012, 2020, 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
> > @@ -208,7 +208,7 @@
> >        *
> >        * @return a CallSite, which, when invoked, will return an
> instance of
> > the
> >        * functional interface
> > -     * @throws ReflectiveOperationException
> > +     * @throws LambdaConversionException
> >        */
> >       abstract CallSite buildCallSite()
> >               throws LambdaConversionException;
> > ---
> >
> old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
> > 2020-07-25 23:46:23.261748361 +0530
> > +++
> >
> new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
> > 2020-07-25 23:46:22.761742991 +0530
> > @@ -200,7 +200,6 @@
> >        *
> >        * @return a CallSite, which, when invoked, will return an
> instance of
> > the
> >        * functional interface
> > -     * @throws ReflectiveOperationException
> >        * @throws LambdaConversionException If properly formed functional
> > interface
> >        * is not found
> >        */
> > --- old/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
> > 23:46:24.285759291 +0530
> > +++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25
> > 23:46:23.785753966 +0530
> > @@ -5413,7 +5413,7 @@
> >        *
> >        * @param n the numerator; must be negative
> >        * @param d the denominator; must not be unity
> > -     * @return a two-element {@long} array with the remainder and
> quotient
> > in
> > +     * @return a two-element {@code long} array with the remainder and
> > quotient in
> >        *         the initial and final elements, respectively
> >        */
> >       private static long[] divRemNegativeLong(long n, long d) {
> > --- old/src/java.base/share/classes/java/math/MutableBigInteger.java
> > 2020-07-25 23:46:25.381770889 +0530
> > +++ new/src/java.base/share/classes/java/math/MutableBigInteger.java
> > 2020-07-25 23:46:24.877765572 +0530
> > @@ -145,7 +145,6 @@
> >        * Makes this number an {@code n}-int number all of whose bits are
> > ones.
> >        * Used by Burnikel-Ziegler division.
> >        * @param n number of ints in the {@code value} array
> > -     * @return a number equal to {@code ((1<<(32*n)))-1}
> >        */
> >       private void ones(int n) {
> >           if (n > value.length)
> > --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
> > 23:46:26.449782093 +0530
> > +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25
> > 23:46:25.937776742 +0530
> > @@ -1,5 +1,5 @@
> >   /*
> > - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights
> > reserved.
> > + * Copyright (c) 1995, 2020, 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
> > @@ -315,7 +315,7 @@
> >       /**
> >        * Creates the socket implementation.
> >        *
> > -     * @throws IOException if creation fails
> > +     * @throws SocketException if creation fails
> >        * @since 1.4
> >        */
> >       void createImpl() throws SocketException {
> > --- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25
> > 23:46:27.485792869 +0530
> > +++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25
> > 23:46:26.973787565 +0530
> > @@ -533,7 +533,7 @@
> >        *
> >        * @param stream a {@code boolean} value : {@code true} for a TCP
> > socket,
> >        *               {@code false} for UDP.
> > -     * @throws IOException if creation fails
> > +     * @throws SocketException if creation fails
> >        * @since 1.4
> >        */
> >        void createImpl(boolean stream) throws SocketException {
> > ---
> >
> old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
> > 2020-07-25 23:46:28.545803801 +0530
> > +++
> >
> new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
> > 2020-07-25 23:46:28.029798501 +0530
> > @@ -1,5 +1,5 @@
> >   /*
> > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
> > reserved.
> > + * Copyright (c) 2003, 2020, 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
> > @@ -773,7 +773,7 @@
> >        * an "annotation structure" OR two bytes into an annotation
> >        * structure (i.e., after the type index).
> >        *
> > -     * @parameter complete true if the byte buffer points to the
> beginning
> > +     * @param complete true if the byte buffer points to the beginning
> >        *     of an annotation structure (rather than two bytes in).
> >        */
> >       private static void skipAnnotation(ByteBuffer buf, boolean
> complete) {
> >
> >
> > Regards,
> > Vipin
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From sgehwolf at redhat.com  Tue Jul 28 08:27:05 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 28 Jul 2020 10:27:05 +0200
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
Message-ID: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>

Hi,

Please review this patch which makes the Java container metrics adhere
to -XX:+/-UseContainerSupport so they can be disabled if heuristics
turn out to be wrong. The approach taken is to use JNI and call into
the JVM in order to determine the setting of UseContainerSupport before
Metrics are being instantiated.

The intention is for this patch to be backported to older JDKs so as to
provide a means to disable container metrics should things go wrong
with backports of the likes of JDK-8226575.

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

Testing: New container test. Existing container tests. jdk/submit.
         tier1 on Linux x86_64.

Thoughts?

Thanks,
Severin


From aph at redhat.com  Tue Jul 28 08:49:42 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 28 Jul 2020 09:49:42 +0100
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
Message-ID: <aec80330-aa89-6bda-ae1e-e2c9aa03ef90@redhat.com>

On 7/28/20 9:27 AM, Severin Gehwolf wrote:
> The intention is for this patch to be backported to older JDKs so as to
> provide a means to disable container metrics should things go wrong
> with backports of the likes of JDK-8226575.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
> 
> Testing: New container test. Existing container tests. jdk/submit.
>          tier1 on Linux x86_64.

That looks right, and pleasingly simple.

-- 
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  Tue Jul 28 09:01:59 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 28 Jul 2020 11:01:59 +0200
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <aec80330-aa89-6bda-ae1e-e2c9aa03ef90@redhat.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <aec80330-aa89-6bda-ae1e-e2c9aa03ef90@redhat.com>
Message-ID: <42c27014e5276476cb24868b7db2814e96e3e2ea.camel@redhat.com>

On Tue, 2020-07-28 at 09:49 +0100, Andrew Haley wrote:
> On 7/28/20 9:27 AM, Severin Gehwolf wrote:
> > The intention is for this patch to be backported to older JDKs so as to
> > provide a means to disable container metrics should things go wrong
> > with backports of the likes of JDK-8226575.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
> > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
> > 
> > Testing: New container test. Existing container tests. jdk/submit.
> >          tier1 on Linux x86_64.
> 
> That looks right, and pleasingly simple.

Thanks for the review!

Cheers,
Severin


From david.holmes at oracle.com  Tue Jul 28 11:17:43 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Jul 2020 21:17:43 +1000
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
Message-ID: <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>

Hi Severin,

On 28/07/2020 6:27 pm, Severin Gehwolf wrote:
> Hi,
> 
> Please review this patch which makes the Java container metrics adhere
> to -XX:+/-UseContainerSupport so they can be disabled if heuristics
> turn out to be wrong. The approach taken is to use JNI and call into
> the JVM in order to determine the setting of UseContainerSupport before
> Metrics are being instantiated.
> 
> The intention is for this patch to be backported to older JDKs so as to
> provide a means to disable container metrics should things go wrong
> with backports of the likes of JDK-8226575.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/

Seems quite simple and clean.

One query though, I'm not clear on who the expected caller of 
Metrics.getInstance() is? (Coming from the perspective of "might we want 
to cache the fact container support is not enabled?".)

Also note that we no longer update JVM_INTERFACE_VERSION (last update 
was JDK 13) - it is meaningless now the JDK and hotspot are in sync 
version wise.

Thanks,
David

> Testing: New container test. Existing container tests. jdk/submit.
>           tier1 on Linux x86_64.
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

From sgehwolf at redhat.com  Tue Jul 28 13:23:48 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 28 Jul 2020 15:23:48 +0200
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
Message-ID: <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>

Hi David,

On Tue, 2020-07-28 at 21:17 +1000, David Holmes wrote:
> Hi Severin,
> 
> On 28/07/2020 6:27 pm, Severin Gehwolf wrote:
> > Hi,
> > 
> > Please review this patch which makes the Java container metrics adhere
> > to -XX:+/-UseContainerSupport so they can be disabled if heuristics
> > turn out to be wrong. The approach taken is to use JNI and call into
> > the JVM in order to determine the setting of UseContainerSupport before
> > Metrics are being instantiated.
> > 
> > The intention is for this patch to be backported to older JDKs so as to
> > provide a means to disable container metrics should things go wrong
> > with backports of the likes of JDK-8226575.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
> > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
> 
> Seems quite simple and clean.
> 
> One query though, I'm not clear on who the expected caller of 
> Metrics.getInstance() is? (Coming from the perspective of "might we want 
> to cache the fact container support is not enabled?".)

I know of two uses so far:

1) Launcher (-XshowSettings:system):
http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/java.base/share/classes/sun/launcher/LauncherHelper.java#l318

2) OperatingSystemMXBean:
http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java#l48

Both uses seem OK as is. Is it worth caching something here?

> Also note that we no longer update JVM_INTERFACE_VERSION (last update 
> was JDK 13) - it is meaningless now the JDK and hotspot are in sync 
> version wise.

OK. Does that mean I should revert the version increment, then?

Thanks,
Severin

> Thanks,
> David
> 
> > Testing: New container test. Existing container tests. jdk/submit.
> >           tier1 on Linux x86_64.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 


From david.holmes at oracle.com  Tue Jul 28 13:49:00 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Jul 2020 23:49:00 +1000
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
 <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>
Message-ID: <08475a75-aa37-c649-6585-404d42e10d6d@oracle.com>

Hi Severin,

On 28/07/2020 11:23 pm, Severin Gehwolf wrote:
> Hi David,
> 
> On Tue, 2020-07-28 at 21:17 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> On 28/07/2020 6:27 pm, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Please review this patch which makes the Java container metrics adhere
>>> to -XX:+/-UseContainerSupport so they can be disabled if heuristics
>>> turn out to be wrong. The approach taken is to use JNI and call into
>>> the JVM in order to determine the setting of UseContainerSupport before
>>> Metrics are being instantiated.
>>>
>>> The intention is for this patch to be backported to older JDKs so as to
>>> provide a means to disable container metrics should things go wrong
>>> with backports of the likes of JDK-8226575.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
>>> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
>>
>> Seems quite simple and clean.
>>
>> One query though, I'm not clear on who the expected caller of
>> Metrics.getInstance() is? (Coming from the perspective of "might we want
>> to cache the fact container support is not enabled?".)
> 
> I know of two uses so far:
> 
> 1) Launcher (-XshowSettings:system):
> http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/java.base/share/classes/sun/launcher/LauncherHelper.java#l318
> 
> 2) OperatingSystemMXBean:
> http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java#l48
> 
> Both uses seem OK as is. Is it worth caching something here?

No that looks fine. I didn't find them because of the reflective 
invocation in Metrics.systemMetrics().

>> Also note that we no longer update JVM_INTERFACE_VERSION (last update
>> was JDK 13) - it is meaningless now the JDK and hotspot are in sync
>> version wise.
> 
> OK. Does that mean I should revert the version increment, then?

I would leave it unchanged, yes.

Thanks,
David
-----


> Thanks,
> Severin
> 
>> Thanks,
>> David
>>
>>> Testing: New container test. Existing container tests. jdk/submit.
>>>            tier1 on Linux x86_64.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
> 

From sgehwolf at redhat.com  Tue Jul 28 14:01:31 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 28 Jul 2020 16:01:31 +0200
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <08475a75-aa37-c649-6585-404d42e10d6d@oracle.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
 <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>
 <08475a75-aa37-c649-6585-404d42e10d6d@oracle.com>
Message-ID: <ad1d4523cc67ef22b74729bfeef035a17dbbc1e0.camel@redhat.com>

Hi David,

Thanks for the review.

On Tue, 2020-07-28 at 23:49 +1000, David Holmes wrote:
> Hi Severin,
> 
> On 28/07/2020 11:23 pm, Severin Gehwolf wrote:
> > Hi David,
> > 
> > On Tue, 2020-07-28 at 21:17 +1000, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > On 28/07/2020 6:27 pm, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Please review this patch which makes the Java container metrics adhere
> > > > to -XX:+/-UseContainerSupport so they can be disabled if heuristics
> > > > turn out to be wrong. The approach taken is to use JNI and call into
> > > > the JVM in order to determine the setting of UseContainerSupport before
> > > > Metrics are being instantiated.
> > > > 
> > > > The intention is for this patch to be backported to older JDKs so as to
> > > > provide a means to disable container metrics should things go wrong
> > > > with backports of the likes of JDK-8226575.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
> > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
> > > 
> > > Seems quite simple and clean.
> > > 
> > > One query though, I'm not clear on who the expected caller of
> > > Metrics.getInstance() is? (Coming from the perspective of "might we want
> > > to cache the fact container support is not enabled?".)
> > 
> > I know of two uses so far:
> > 
> > 1) Launcher (-XshowSettings:system):
> > http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/java.base/share/classes/sun/launcher/LauncherHelper.java#l318
> > 
> > 2) OperatingSystemMXBean:
> > http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java#l48
> > 
> > Both uses seem OK as is. Is it worth caching something here?
> 
> No that looks fine. I didn't find them because of the reflective 
> invocation in Metrics.systemMetrics().
> 
> > > Also note that we no longer update JVM_INTERFACE_VERSION (last update
> > > was JDK 13) - it is meaningless now the JDK and hotspot are in sync
> > > version wise.
> > 
> > OK. Does that mean I should revert the version increment, then?
> 
> I would leave it unchanged, yes.

Here you go:
https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/02/webrev/

OK?

Thanks,
Severin


From raffaello.giulietti at gmail.com  Tue Jul 28 14:04:20 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Tue, 28 Jul 2020 16:04:20 +0200
Subject: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not
 throw expected IndexOutOfBoundsExceptions
Message-ID: <59a871a4-d676-3b0c-2983-b9b9fc34ca37@gmail.com>

Hello,

here's a very simple patch to address issue 8245036.
HTH


Greetings
Raffaello

----

# HG changeset patch
# User lello
# Date 1595944637 -7200
#      Tue Jul 28 15:57:17 2020 +0200
# Node ID 1d66b831e5e2085fca5c3f71ca958c482d4aebd7
# Parent  89fe9e02a522b57c356f0dd5279085a075c2945b
Patch to fix JDK-8245036
8245036: DataInputStream.readFully(byte[], int, int) does not throw 
expected IndexOutOfBoundsExceptions
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>

diff --git a/src/java.base/share/classes/java/io/DataInputStream.java 
b/src/java.base/share/classes/java/io/DataInputStream.java
--- a/src/java.base/share/classes/java/io/DataInputStream.java
+++ b/src/java.base/share/classes/java/io/DataInputStream.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1994, 2020, 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
@@ -25,6 +25,8 @@

  package java.io;

+import java.util.Objects;
+
  /**
   * A data input stream lets an application read primitive Java data
   * types from an underlying input stream in a machine-independent
@@ -192,8 +194,7 @@
       * @see        java.io.FilterInputStream#in
       */
      public final void readFully(byte b[], int off, int len) throws 
IOException {
-        if (len < 0)
-            throw new IndexOutOfBoundsException();
+        Objects.checkFromIndexSize(off, len, b.length);
          int n = 0;
          while (n < len) {
              int count = in.read(b, off + n, len - n);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8245036.patch
Type: text/x-patch
Size: 1596 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200728/8491fd88/JDK-8245036-0001.patch>

From bob.vandette at oracle.com  Tue Jul 28 14:14:42 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 28 Jul 2020 10:14:42 -0400
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <ad1d4523cc67ef22b74729bfeef035a17dbbc1e0.camel@redhat.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
 <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>
 <08475a75-aa37-c649-6585-404d42e10d6d@oracle.com>
 <ad1d4523cc67ef22b74729bfeef035a17dbbc1e0.camel@redhat.com>
Message-ID: <A18F659A-6C4F-4861-88A7-FA73DD816D5E@oracle.com>

Looks good to me.

Bob.


> On Jul 28, 2020, at 10:01 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> Hi David,
> 
> Thanks for the review.
> 
> On Tue, 2020-07-28 at 23:49 +1000, David Holmes wrote:
>> Hi Severin,
>> 
>> On 28/07/2020 11:23 pm, Severin Gehwolf wrote:
>>> Hi David,
>>> 
>>> On Tue, 2020-07-28 at 21:17 +1000, David Holmes wrote:
>>>> Hi Severin,
>>>> 
>>>> On 28/07/2020 6:27 pm, Severin Gehwolf wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review this patch which makes the Java container metrics adhere
>>>>> to -XX:+/-UseContainerSupport so they can be disabled if heuristics
>>>>> turn out to be wrong. The approach taken is to use JNI and call into
>>>>> the JVM in order to determine the setting of UseContainerSupport before
>>>>> Metrics are being instantiated.
>>>>> 
>>>>> The intention is for this patch to be backported to older JDKs so as to
>>>>> provide a means to disable container metrics should things go wrong
>>>>> with backports of the likes of JDK-8226575.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
>>>>> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
>>>> 
>>>> Seems quite simple and clean.
>>>> 
>>>> One query though, I'm not clear on who the expected caller of
>>>> Metrics.getInstance() is? (Coming from the perspective of "might we want
>>>> to cache the fact container support is not enabled?".)
>>> 
>>> I know of two uses so far:
>>> 
>>> 1) Launcher (-XshowSettings:system):
>>> http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/java.base/share/classes/sun/launcher/LauncherHelper.java#l318
>>> 
>>> 2) OperatingSystemMXBean:
>>> http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java#l48
>>> 
>>> Both uses seem OK as is. Is it worth caching something here?
>> 
>> No that looks fine. I didn't find them because of the reflective 
>> invocation in Metrics.systemMetrics().
>> 
>>>> Also note that we no longer update JVM_INTERFACE_VERSION (last update
>>>> was JDK 13) - it is meaningless now the JDK and hotspot are in sync
>>>> version wise.
>>> 
>>> OK. Does that mean I should revert the version increment, then?
>> 
>> I would leave it unchanged, yes.
> 
> Here you go:
> https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/02/webrev/
> 
> OK?
> 
> Thanks,
> Severin
> 


From sgehwolf at redhat.com  Tue Jul 28 14:17:12 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 28 Jul 2020 16:17:12 +0200
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <A18F659A-6C4F-4861-88A7-FA73DD816D5E@oracle.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
 <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>
 <08475a75-aa37-c649-6585-404d42e10d6d@oracle.com>
 <ad1d4523cc67ef22b74729bfeef035a17dbbc1e0.camel@redhat.com>
 <A18F659A-6C4F-4861-88A7-FA73DD816D5E@oracle.com>
Message-ID: <79f88ebd6cf72be5f8fcc32360fa561c7cd2988c.camel@redhat.com>

On Tue, 2020-07-28 at 10:14 -0400, Bob Vandette wrote:
> Looks good to me.

Thanks for the review, Bob!

Cheers,
Severin



From huizhe.wang at oracle.com  Tue Jul 28 17:21:21 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 28 Jul 2020 10:21:21 -0700
Subject: RFR: 8247546: Pattern matching does not skip correctly over
 supplementary characters
In-Reply-To: <5a59c1f9-f413-4eef-0e98-e484d2d13ea9@oracle.com>
References: <7e5d9751-737e-deea-45e0-7684726bc3ff@oracle.com>
 <5edd5d46-347d-363f-58ec-f61cd77c0de3@oracle.com>
 <8cd064ae-d9f3-57db-d654-bc44ae6e0442@oracle.com>
 <5a59c1f9-f413-4eef-0e98-e484d2d13ea9@oracle.com>
Message-ID: <132755af-6bf9-0e9b-9c38-4b37ab5fcf09@oracle.com>

Hi Naoto,

The new webrev looks good.

Best,
Joe

On 7/27/20 7:11 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thank you for the review!
>
> On 7/27/20 6:04 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> Looks good to me, using the correct supplementary-aware 
>> implementation is an improvement for the impl to handle the situation.
>>
>> A note (probably a workaround) for the user's case, to replace 
>> invalid surrogate characters, he could have used Unicode escape 
>> sequences [\ud800-\udfff] instead.
>
> Yes.
>
>>
>> For the test, I wonder if it'd be better to combine the 1st and 2nd, 
>> 3rd and 4th cases into: xxx\udca9\ud83d\udca9\ud83dyyy to represent 
>> two lone surrogates plus a valid pair.
>
> If we combine test strings into the one mentioned above, I think it 
> cannot distinguish the case we wanted to test. They all match with the 
> first unpaired surrogate, i.e., \udca9.
>
>>
>> A minor comment on the comments of the test cases (in 
>> SupplementaryTestCases.txt): instead of repeating the bug id (that 
>> is: // @bug 8247546), it may be good to provide a short note (e.g. 
>> match lone/invalid surrogates).
>
> Right, there is no reason to leave bug id since it can be found from 
> hg log. Instead, I replaced them with more useful short notes.
>
> Revised webrev:
> https://cr.openjdk.java.net/~naoto/8247546/webrev.02/
>
> Naoto
>
>>
>> Regards,
>> Joe
>>
>> On 7/27/20 2:18 PM, naoto.sato at oracle.com wrote:
>>> On 7/27/20 11:51 AM, naoto.sato at oracle.com wrote:
>>>> Apart from the original issue, there was a bug in Range() method 
>>>> (Pattern.java:5795), so it is fixed along.
>>>
>>> Created a test case for this:
>>>
>>> --- a/test/jdk/java/util/regex/SupplementaryTestCases.txt
>>> +++ b/test/jdk/java/util/regex/SupplementaryTestCases.txt
>>> @@ -149,6 +149,11 @@
>>> ?\ud83d\udca9
>>> ?false 0
>>>
>>> +// @bug 8247546
>>> +[\x{dc00}-\x{dfff}]
>>> +\ud83d\udca9
>>> +false 0
>>> +
>>> ?// use of x modifier
>>> ?\ud800\udc61bc(?x)bl\ud800\udc61h
>>> ?\ud800\udc61bcbl\ud800\udc61h
>>>
>>> Low surrogate range check falls into using BmpCharPredicate, which 
>>> results in the same bug. The entire webrev is also revised:
>>>
>>> http://cr.openjdk.java.net/~naoto/8247546/webrev.01/
>>>
>>> Naoto
>>


From huizhe.wang at oracle.com  Tue Jul 28 17:25:58 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 28 Jul 2020 10:25:58 -0700
Subject: RFR [16/java.xml] 8249643: Clarify DOM documentation
Message-ID: <c2aefa6a-72e1-2806-f22b-eafd7edf011e@oracle.com>

Hello,

Please review a doc clarification for the org.w3c.dom package.

JBS: https://bugs.openjdk.java.net/browse/JDK-8249643
CSR: https://bugs.openjdk.java.net/browse/JDK-8249904

webrev: http://cr.openjdk.java.net/~joehw/jdk16/8249643/webrev_02/

Thanks,
Joe


From lance.andersen at oracle.com  Tue Jul 28 17:28:36 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 28 Jul 2020 13:28:36 -0400
Subject: RFR [16/java.xml] 8249643: Clarify DOM documentation
In-Reply-To: <c2aefa6a-72e1-2806-f22b-eafd7edf011e@oracle.com>
References: <c2aefa6a-72e1-2806-f22b-eafd7edf011e@oracle.com>
Message-ID: <7B02A978-33E1-4D6A-BD09-22C1135C3860@oracle.com>

Hi Joe,

The changes look fine.

Best
Lance

> On Jul 28, 2020, at 1:25 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hello,
> 
> Please review a doc clarification for the org.w3c.dom package.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249643
> CSR: https://bugs.openjdk.java.net/browse/JDK-8249904
> 
> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8249643/webrev_02/
> 
> Thanks,
> Joe
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From vladimir.x.ivanov at oracle.com  Tue Jul 28 22:09:54 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 29 Jul 2020 01:09:54 +0300
Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator):
 Hotspot and x86 backend changes
In-Reply-To: <BYAPR11MB3543026ABF92A463562E5DE5EF7C0@BYAPR11MB3543.namprd11.prod.outlook.com>
References: <BYAPR11MB3543026ABF92A463562E5DE5EF7C0@BYAPR11MB3543.namprd11.prod.outlook.com>
Message-ID: <e4c76a68-97d1-6fe5-7a12-15ab04a216bf@oracle.com>


> Shared Hotspot:
>     Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.01/
>     Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/hs_webrev/webrev.00-webrev.01/

FTR here are the latest changes in HotSpot shared code:
 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01

Incremental changes:
 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00

Best regards,
Vladimir Ivanov

> Older webrev links for your reference:
> Shared Hotspot: http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/

From stuart.marks at oracle.com  Tue Jul 28 22:36:04 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 28 Jul 2020 15:36:04 -0700
Subject: JDK 16 RFR of 8250580: Address reliance on default constructors
 in java.rmi
In-Reply-To: <4ccf6bba-1500-dd50-3fab-ea523db80ac7@oracle.com>
References: <4ccf6bba-1500-dd50-3fab-ea523db80ac7@oracle.com>
Message-ID: <f533ea44-2ba0-e0ed-2311-68e60f3ead29@oracle.com>

Looks good Joe, thanks for doing this cleanup. CSR request reviewed.

s'marks

On 7/24/20 7:45 PM, Joe Darcy wrote:
> Hello,
> 
> Another bug in the quest to remove use of default constructors in the JDK's 
> public API, this time in the java.rmi module:
> 
>  ??? webrev: http://cr.openjdk.java.nhet/~darcy/8250580.0/
>  ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8250581
> 
> Patch below; thanks,
> 
> -Joe
> 
> --- old/src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java 
> 2020-07-24 19:42:16.353847343 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java 
> 2020-07-24 19:42:15.645847343 -0700
> @@ -1,5 +1,5 @@
>  ?/*
> - * Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, 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
> @@ -62,6 +62,11 @@
>  ?public abstract class RMIClassLoaderSpi {
> 
>  ???? /**
> +???? * Constructor for subclasses to call.
> +???? */
> +??? public RMIClassLoaderSpi() {}
> +
> +??? /**
>  ????? * Provides the implementation for
>  ????? * {@link RMIClassLoader#loadClass(URL,String)},
>  ????? * {@link RMIClassLoader#loadClass(String,String)}, and
> 

From david.holmes at oracle.com  Tue Jul 28 22:48:31 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Jul 2020 08:48:31 +1000
Subject: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for
 enabling/disabling Java container metrics
In-Reply-To: <ad1d4523cc67ef22b74729bfeef035a17dbbc1e0.camel@redhat.com>
References: <cd21de12e8c4b20b5d49be667476886aa1d4b3cd.camel@redhat.com>
 <94cf1c36-0f55-7027-f2d2-f8b0dadd9366@oracle.com>
 <5c91581298ac70a98587a01edba46314cf53b0c2.camel@redhat.com>
 <08475a75-aa37-c649-6585-404d42e10d6d@oracle.com>
 <ad1d4523cc67ef22b74729bfeef035a17dbbc1e0.camel@redhat.com>
Message-ID: <d6fd7bdc-7479-16e1-abd8-15e25f0ae597@oracle.com>

Update looks good.

Thanks,
David

On 29/07/2020 12:01 am, Severin Gehwolf wrote:
> Hi David,
> 
> Thanks for the review.
> 
> On Tue, 2020-07-28 at 23:49 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> On 28/07/2020 11:23 pm, Severin Gehwolf wrote:
>>> Hi David,
>>>
>>> On Tue, 2020-07-28 at 21:17 +1000, David Holmes wrote:
>>>> Hi Severin,
>>>>
>>>> On 28/07/2020 6:27 pm, Severin Gehwolf wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this patch which makes the Java container metrics adhere
>>>>> to -XX:+/-UseContainerSupport so they can be disabled if heuristics
>>>>> turn out to be wrong. The approach taken is to use JNI and call into
>>>>> the JVM in order to determine the setting of UseContainerSupport before
>>>>> Metrics are being instantiated.
>>>>>
>>>>> The intention is for this patch to be backported to older JDKs so as to
>>>>> provide a means to disable container metrics should things go wrong
>>>>> with backports of the likes of JDK-8226575.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250627
>>>>> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/01/webrev/
>>>>
>>>> Seems quite simple and clean.
>>>>
>>>> One query though, I'm not clear on who the expected caller of
>>>> Metrics.getInstance() is? (Coming from the perspective of "might we want
>>>> to cache the fact container support is not enabled?".)
>>>
>>> I know of two uses so far:
>>>
>>> 1) Launcher (-XshowSettings:system):
>>> http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/java.base/share/classes/sun/launcher/LauncherHelper.java#l318
>>>
>>> 2) OperatingSystemMXBean:
>>> http://hg.openjdk.java.net/jdk/jdk/file/89fe9e02a522/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java#l48
>>>
>>> Both uses seem OK as is. Is it worth caching something here?
>>
>> No that looks fine. I didn't find them because of the reflective
>> invocation in Metrics.systemMetrics().
>>
>>>> Also note that we no longer update JVM_INTERFACE_VERSION (last update
>>>> was JDK 13) - it is meaningless now the JDK and hotspot are in sync
>>>> version wise.
>>>
>>> OK. Does that mean I should revert the version increment, then?
>>
>> I would leave it unchanged, yes.
> 
> Here you go:
> https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250627/02/webrev/
> 
> OK?
> 
> Thanks,
> Severin
> 

From amaembo at gmail.com  Wed Jul 29 03:26:48 2020
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 29 Jul 2020 10:26:48 +0700
Subject: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does
 not throw expected IndexOutOfBoundsExceptions
In-Reply-To: <59a871a4-d676-3b0c-2983-b9b9fc34ca37@gmail.com>
References: <59a871a4-d676-3b0c-2983-b9b9fc34ca37@gmail.com>
Message-ID: <CAE+3fjbo6Y-DQFPAfZVpgJBoYBUy54vFde6XMAZ7aQtuWJfq7A@mail.gmail.com>

Hello!

Having a unit-test would be nice!

With best regards,
Tagir Valeev.

On Tue, Jul 28, 2020 at 9:04 PM Raffaello Giulietti
<raffaello.giulietti at gmail.com> wrote:
>
> Hello,
>
> here's a very simple patch to address issue 8245036.
> HTH
>
>
> Greetings
> Raffaello
>
> ----
>
> # HG changeset patch
> # User lello
> # Date 1595944637 -7200
> #      Tue Jul 28 15:57:17 2020 +0200
> # Node ID 1d66b831e5e2085fca5c3f71ca958c482d4aebd7
> # Parent  89fe9e02a522b57c356f0dd5279085a075c2945b
> Patch to fix JDK-8245036
> 8245036: DataInputStream.readFully(byte[], int, int) does not throw
> expected IndexOutOfBoundsExceptions
> Reviewed-by: TBD
> Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>
>
> diff --git a/src/java.base/share/classes/java/io/DataInputStream.java
> b/src/java.base/share/classes/java/io/DataInputStream.java
> --- a/src/java.base/share/classes/java/io/DataInputStream.java
> +++ b/src/java.base/share/classes/java/io/DataInputStream.java
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1994, 2020, 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
> @@ -25,6 +25,8 @@
>
>   package java.io;
>
> +import java.util.Objects;
> +
>   /**
>    * A data input stream lets an application read primitive Java data
>    * types from an underlying input stream in a machine-independent
> @@ -192,8 +194,7 @@
>        * @see        java.io.FilterInputStream#in
>        */
>       public final void readFully(byte b[], int off, int len) throws
> IOException {
> -        if (len < 0)
> -            throw new IndexOutOfBoundsException();
> +        Objects.checkFromIndexSize(off, len, b.length);
>           int n = 0;
>           while (n < len) {
>               int count = in.read(b, off + n, len - n);

From Alan.Bateman at oracle.com  Wed Jul 29 06:20:12 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jul 2020 07:20:12 +0100
Subject: RFR [16/java.xml] 8249643: Clarify DOM documentation
In-Reply-To: <c2aefa6a-72e1-2806-f22b-eafd7edf011e@oracle.com>
References: <c2aefa6a-72e1-2806-f22b-eafd7edf011e@oracle.com>
Message-ID: <a7564f27-55a8-91a7-7444-cbbdeaf1939c@oracle.com>

On 28/07/2020 18:25, Joe Wang wrote:
> Hello,
>
> Please review a doc clarification for the org.w3c.dom package.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249643
> CSR: https://bugs.openjdk.java.net/browse/JDK-8249904
>
> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8249643/webrev_02/
If there is deviation from the XML spec with characters in surrogate 
blocks then it will require a spec change to clarify the deviation, it 
can't be an implNote.

-Alan.

From aph at redhat.com  Wed Jul 29 11:44:50 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 29 Jul 2020 12:44:50 +0100
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
Message-ID: <852a3a09-a627-c0fc-89c6-8c8100ae17f5@redhat.com>

On 20/07/2020 04:51, Ningsheng Jian wrote:
> Since we are getting ready to propose Vector API target to JDK 16 [1]. I 
> have regenerated webrev of aarch64 backend parts from panama repo, which 
> has been rebased to jdk/jdk very recently, by:
> 
> $ hg update vector-unstable && hg diff -r default > all.patch
> $ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk 
> '{print $4}' > aarch64_list
> $ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list
> 
> The new webrev:
> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/
> 
> Could you please help to take a look?

OK, thanks. It all looks fine. Sorry for the delay.

-- 
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 raffaello.giulietti at gmail.com  Wed Jul 29 17:44:41 2020
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 29 Jul 2020 19:44:41 +0200
Subject: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does
 not throw expected IndexOutOfBoundsExceptions
In-Reply-To: <CAE+3fjbo6Y-DQFPAfZVpgJBoYBUy54vFde6XMAZ7aQtuWJfq7A@mail.gmail.com>
References: <59a871a4-d676-3b0c-2983-b9b9fc34ca37@gmail.com>
 <CAE+3fjbo6Y-DQFPAfZVpgJBoYBUy54vFde6XMAZ7aQtuWJfq7A@mail.gmail.com>
Message-ID: <858a70ac-f827-669a-58e2-e5b834aa36f4@gmail.com>

Hi Tagir,

here's yesterday's patch with added unit tests.


Greetings
Raffaello



On 2020-07-29 05:26, Tagir Valeev wrote:
> Hello!
> 
> Having a unit-test would be nice!
> 
> With best regards,
> Tagir Valeev.
> 
> On Tue, Jul 28, 2020 at 9:04 PM Raffaello Giulietti
> <raffaello.giulietti at gmail.com> wrote:
>>
>> Hello,
>>
>> here's a very simple patch to address issue 8245036.
>> HTH
>>
>>
>> Greetings
>> Raffaello




----

# HG changeset patch
# User lello
# Date 1596043874 -7200
#      Wed Jul 29 19:31:14 2020 +0200
# Node ID b9d417f53ddaae3801585b285f6eb8ba1606af8b
# Parent  89fe9e02a522b57c356f0dd5279085a075c2945b
Patch to fix JDK-8245036
8245036: DataInputStream.readFully(byte[], int, int) does not throw 
expected IndexOutOfBoundsExceptions
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti <raffaello.giulietti at gmail.com>

diff --git a/src/java.base/share/classes/java/io/DataInputStream.java 
b/src/java.base/share/classes/java/io/DataInputStream.java
--- a/src/java.base/share/classes/java/io/DataInputStream.java
+++ b/src/java.base/share/classes/java/io/DataInputStream.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1994, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1994, 2020, 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
@@ -25,6 +25,8 @@

  package java.io;

+import java.util.Objects;
+
  /**
   * A data input stream lets an application read primitive Java data
   * types from an underlying input stream in a machine-independent
@@ -192,8 +194,7 @@
       * @see        java.io.FilterInputStream#in
       */
      public final void readFully(byte b[], int off, int len) throws 
IOException {
-        if (len < 0)
-            throw new IndexOutOfBoundsException();
+        Objects.checkFromIndexSize(off, len, b.length);
          int n = 0;
          while (n < len) {
              int count = in.read(b, off + n, len - n);
diff --git a/test/jdk/java/io/DataInputStream/ReadFully.java 
b/test/jdk/java/io/DataInputStream/ReadFully.java
--- a/test/jdk/java/io/DataInputStream/ReadFully.java
+++ b/test/jdk/java/io/DataInputStream/ReadFully.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2020, 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
@@ -22,15 +22,36 @@
   */

  /* @test
- * @bug 4214513
- * @summary Passing a negative length argument for readFully must throw
- *          IndexOutOfBoundsException.
+ * @bug 4214513 8245036
+ * @summary Passing a negative offset or length,
+ *          or passing a combination of offset and length too big
+ *          for readFully must throw IndexOutOfBoundsException.
   */

+import java.io.*;

-import java.io.*;
  public class ReadFully {
-    public static final void main(String[] args) throws Exception {
+
+    private static final void testNegativeOffset() throws Exception {
+        byte[] buffer = new byte[100];
+        File file = new File(System.getProperty("test.src"),
+                "ReadFully.java");
+        FileInputStream in = new FileInputStream(file);
+        DataInputStream dis = new DataInputStream(in);
+
+        boolean caughtException = false;
+        try {
+            dis.readFully(buffer, -1, buffer.length);
+        } catch (IndexOutOfBoundsException ie) {
+            caughtException = true;
+        } finally {
+            dis.close();
+            if (!caughtException)
+                throw new RuntimeException("Test testNegativeOffset() 
failed");
+        }
+    }
+
+    private static final void testNegativeLength() throws Exception {
          byte[] buffer = new byte[100];
          File file = new File(System.getProperty("test.src"),
                  "ReadFully.java");
@@ -45,7 +66,53 @@
          } finally {
              dis.close();
              if (!caughtException)
-                throw new RuntimeException("Test failed");
+                throw new RuntimeException("Test testNegativeLength() 
failed");
+        }
+    }
+
+    private static final void testBigOffsetLength1() throws Exception {
+        byte[] buffer = new byte[100];
+        File file = new File(System.getProperty("test.src"),
+                "ReadFully.java");
+        FileInputStream in = new FileInputStream(file);
+        DataInputStream dis = new DataInputStream(in);
+
+        boolean caughtException = false;
+        try {
+            dis.readFully(buffer, 0, buffer.length + 1);
+        } catch (IndexOutOfBoundsException ie) {
+            caughtException = true;
+        } finally {
+            dis.close();
+            if (!caughtException)
+                throw new RuntimeException("Test testBigOffsetLength1() 
failed");
          }
      }
+
+    private static final void testBigOffsetLength2() throws Exception {
+        byte[] buffer = new byte[100];
+        File file = new File(System.getProperty("test.src"),
+                "ReadFully.java");
+        FileInputStream in = new FileInputStream(file);
+        DataInputStream dis = new DataInputStream(in);
+
+        boolean caughtException = false;
+        try {
+            dis.readFully(buffer, buffer.length, 1);
+        } catch (IndexOutOfBoundsException ie) {
+            caughtException = true;
+        } finally {
+            dis.close();
+            if (!caughtException)
+                throw new RuntimeException("Test testBigOffsetLength2() 
failed");
+        }
+    }
+
+    public static final void main(String[] args) throws Exception {
+        testNegativeOffset();
+        testNegativeLength();
+        testBigOffsetLength1();
+        testBigOffsetLength2();
+    }
+
  }

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK-8245036.patch
Type: text/x-patch
Size: 5466 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200729/1852aec0/JDK-8245036.patch>

From sgehwolf at redhat.com  Wed Jul 29 19:21:37 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 29 Jul 2020 21:21:37 +0200
Subject: [PING?] RFR(s): 8247863: Unreachable code in
 OperatingSystemImpl.getTotalSwapSpaceSize()
In-Reply-To: <AM0PR02MB5412A7A9AD7CA2987E913F09937E0@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <d526dcb167109fa23b510dcd87cb6cb365ba7c4b.camel@redhat.com>
 <40bd7c49d36c5775d86b9d2ff5740b50cf4359e9.camel@redhat.com>
 <AM0PR02MB5412A7A9AD7CA2987E913F09937E0@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <a92d552b3df0947a4481d15d94f6f3c0f3c29dd1.camel@redhat.com>

Hi Matthias,

On Wed, 2020-07-15 at 15:22 +0000, Baesken, Matthias wrote:
> Hello Severin ,  
> 
> > the new cgroups implementation
> > supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return   0
> 
> Wouldn?t it be possible that the  coding  of  getMemoryAndSwapLimit   returns a negative value  (might not happen on a "healthy" system but you never know) :

In short, no, unless the value is actually unlimited. With the caveat
that we cannot distinguish between "kernel not supporting swap" and
"unlimited" swap with a potential cgroup memory.memsw.limit_in_bytes
file missing.

The premise is that negative values are not possible in cgroup
interface files. So the only valid reason to return negative (-1, to be
precise) is if the interface files aren't there or the values in those
files are beyond a threshold indicating "unlimited".

Let's look at this in detail:

> jdk/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java
> 
> 444    public long getMemoryAndSwapLimit() {
> 445        long retval = getLongValue(memory, "memory.memsw.limit_in_bytes");

getLongValue() will not return a negative value unless an interface
file is missing, a string in the cgroup files is empty, or a very large
number is observed (which maps to unlimited, a.k.a non-container values
win).

> 446        if (retval > CgroupV1SubsystemController.UNLIMITED_MIN) {
> 447            if (memory.isHierarchical()) {
> 448                // memory.memsw.limit_in_bytes returned unlimited, attempt
> 449                // hierarchical memory limit
> 450                String match = "hierarchical_memsw_limit";
> 451                retval = CgroupV1SubsystemController.getLongValueMatchingLine(memory,
> 452                                                            "memory.stat",
> 453                                                            match);

Same for this.

> 454            }
> 455        }
> 456        return CgroupV1SubsystemController.longValOrUnlimited(retval);

At this point we map any large value to -1, unlimited, or return
'retval'.

> 457    }
> 
> 
> jdk/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
> 
> 278    public long getMemoryAndSwapLimit() {
> 279        String strVal = CgroupSubsystemController.getStringValue(unified, "memory.swap.max");

This will either return null, "MAX" or the actual value.

> 280        return limitFromString(strVal);

This maps MAX and null to -1 or the actual numberical value as string
to its representation as long.

> 281    }
> 
> So  the check you want to clean up does no harm, and might handle "strange" cases - why not keep it?

The comment in this block is now misleading:

if (limit >= 0 && memLimit >= 0) {
  // we see a limit == 0 on some machines where "kernel does not support swap limit capabilities"
  return (limit < memLimit) ? 0 : limit - memLimit;
}

The only reason why a 0 was observed, was because the cgroup interface
files were missing and the old code mapped that to a 0. That's no
longer the case and, thus, it seems it would make the code clearer if
it wouldn't be there any more.

I don't feel strongly about this, though, and can just drop this patch.

The fix of JDK-8236617 has been superseded by JDK-8244500.

Thanks,
Severin

> 
> 
> Best regards, Matthias
> 
> 
> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com> 
> Sent: Mittwoch, 15. Juli 2020 11:47
> To: core-libs-dev <core-libs-dev at openjdk.java.net>; serviceability-dev <serviceability-dev at openjdk.java.net>
> Cc: Baesken, Matthias <matthias.baesken at sap.com>; Bob Vandette <bob.vandette at oracle.com>
> Subject: Re: [PING?] RFR(s): 8247863: Unreachable code in OperatingSystemImpl.getTotalSwapSpaceSize()
> 
> Anyone?
> 
> On Mon, 2020-06-29 at 17:53 +0200, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review of this dead-code removal? During review of
> > JDK-8244500 it was discovered that with the new cgroups implementation
> > supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return
> > 0 when relevant cgroup files are missing. E.g. on a system where the
> > kernel doesn't support swap limit capabilities. Therefore this code
> > introduced with JDK-8236617 can no longer be reached and should get
> > removed.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8247863
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247863/01/webrev/
> > 
> > Testing: Matthias tested this on the affected system and it did pass
> > for him. Docker tests on cgroup v1 and cgroup v2.
> > 
> > Thanks,
> > Severin


From matthias.baesken at sap.com  Thu Jul 30 05:28:05 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 30 Jul 2020 05:28:05 +0000
Subject: [PING?] RFR(s): 8247863: Unreachable code in
 OperatingSystemImpl.getTotalSwapSpaceSize()
In-Reply-To: <a92d552b3df0947a4481d15d94f6f3c0f3c29dd1.camel@redhat.com>
References: <d526dcb167109fa23b510dcd87cb6cb365ba7c4b.camel@redhat.com>
 <40bd7c49d36c5775d86b9d2ff5740b50cf4359e9.camel@redhat.com>
 <AM0PR02MB5412A7A9AD7CA2987E913F09937E0@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <a92d552b3df0947a4481d15d94f6f3c0f3c29dd1.camel@redhat.com>
Message-ID: <AM0PR02MB5412FD7690F7762859E54AB193710@AM0PR02MB5412.eurprd02.prod.outlook.com>


>The only reason why a 0 was observed, was because the cgroup interface
>files were missing and the old code mapped that to a 0. That's no
>longer the case and, thus, it seems it would make the code clearer if
>it wouldn't be there any more.
>
>I don't feel strongly about this, though, and can just drop this patch.

Hi Severin, thanks for clarification, I'm fine with the patch !

Best regards, Matthias

From sakatakui at oss.nttdata.com  Thu Jul 30 05:58:47 2020
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Thu, 30 Jul 2020 14:58:47 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <10f1641b-3302-50ee-f7e7-e283685b2535@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>
 <10f1641b-3302-50ee-f7e7-e283685b2535@oss.nttdata.com>
Message-ID: <ea85cdaa-0442-6909-7334-c91c05e04489@oss.nttdata.com>

Hi Andrew,

I just formatted the patch to be same as the other code.

Moreover, I saw the following code in k_standard.c.

if (_LIB_VERSION == _SVID_)
   exc.retval = zero;
else
   exc.retval = zero/zero;

Do we need to do like that in this patch? It seems to be related to the 
old matherr(), but I'm not sure about that.

Thanks,
Koichi

===== PATCH =====
diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
b/src/java.base/share/native/libfdlibm/k_standard.c
--- a/src/java.base/share/native/libfdlibm/k_standard.c
+++ b/src/java.base/share/native/libfdlibm/k_standard.c
@@ -739,6 +739,10 @@
                          errno = EDOM;
                  }
                  break;
+            default:
+                exc.retval = zero/zero;
+                errno = EINVAL;
+                break;
          }
          return exc.retval;
  }
diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
b/src/java.base/unix/native/libnet/NetworkInterface.c
--- a/src/java.base/unix/native/libnet/NetworkInterface.c
+++ b/src/java.base/unix/native/libnet/NetworkInterface.c
@@ -1296,7 +1296,8 @@
  static int getIndex(int sock, const char *name) {
      struct ifreq if2;
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
+    strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
+    if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

      if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
          return -1;
@@ -1359,7 +1360,8 @@
  static int getFlags(int sock, const char *ifname, int *flags) {
      struct ifreq if2;
      memset((char *)&if2, 0, sizeof(if2));
-    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
+    strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
+    if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;

      if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
          return -1;


On 2020/07/22 23:48, Koichi Sakata wrote:
> Hi Andrew,
> 
> Thank you for teaching me.
> I made the patch that returns NaN. Could you please sponsor it?
> 
> In this case I think it is better to fix k_standard.c itself rather than 
> ignoring the warning. However, I was able to learn there are some good 
> ways to suppress warnings. So I'd like to thank Ioi and Yasumasa.
> 
> Thanks,
> Koichi
> 
> ===== PATCH =====
> diff --git a/src/java.base/share/native/libfdlibm/k_standard.c 
> b/src/java.base/share/native/libfdlibm/k_standard.c
> --- a/src/java.base/share/native/libfdlibm/k_standard.c
> +++ b/src/java.base/share/native/libfdlibm/k_standard.c
> @@ -739,6 +739,10 @@
>  ???????????????????????? errno = EDOM;
>  ???????????????? }
>  ???????????????? break;
> +??????????? default:
> +??????????????? exc.retval = zero / zero;
> +??????????????? errno = EINVAL;
> +??????????????? break;
>  ???????? }
>  ???????? return exc.retval;
>  ?}
> diff --git a/src/java.base/unix/native/libnet/NetworkInterface.c 
> b/src/java.base/unix/native/libnet/NetworkInterface.c
> --- a/src/java.base/unix/native/libnet/NetworkInterface.c
> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c
> @@ -1296,7 +1296,8 @@
>  ?static int getIndex(int sock, const char *name) {
>  ???? struct ifreq if2;
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
> +??? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name));
> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
>  ???? if (ioctl(sock, SIOCGIFINDEX, (char *)&if2) < 0) {
>  ???????? return -1;
> @@ -1359,7 +1360,8 @@
>  ?static int getFlags(int sock, const char *ifname, int *flags) {
>  ???? struct ifreq if2;
>  ???? memset((char *)&if2, 0, sizeof(if2));
> -??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1);
> +??? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name));
> +??? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0;
> 
>  ???? if (ioctl(sock, SIOCGIFFLAGS, (char *)&if2) < 0) {
>  ???????? return -1;
> 
> 
> On 2020/07/22 17:24, Andrew Haley wrote:
>> On 17/07/2020 12:26, Koichi Sakata wrote:
>>>
>>> ? > You'll need to find a reviewer that understands what that
>>> ? > method is supposed to do in that case, that's not me ;-)
>>>
>>> I understand. This ML is suitable for finding a reviewer, isn't it?
>>> Or, there is another way. We can avoid the error by the accepting
>>> maybe-uninitialized warning in libfdlibm instead of fixing k_standard.c.
>>
>> I think it'd be better to fix it. Although the logic is such that all of
>> the cases are covered by the switch statement in k_standard.c, the 
>> default
>> case should return NaN in retval: use zero/zero.
>>
>> I'll approve that.
>>

From alexey at azul.com  Thu Jul 30 09:17:11 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 30 Jul 2020 09:17:11 +0000
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com>
 <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com>
 <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
 <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
 <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
 <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com>
 <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com>
Message-ID: <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com>

Gentle ping

Regards
Alexey

> On 15 Jul 2020, at 14:18, Alexey Bakhtin <alexey at azul.com> wrote:
> 
> Hello Daniel,
> 
> I?ve updated CSR as you suggested and added kerberos ldap setup commands for the client host in the JDK-8245527
> 
> Regards
> Alexey


From sgehwolf at redhat.com  Thu Jul 30 09:23:14 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 30 Jul 2020 11:23:14 +0200
Subject: [PING?] RFR(s): 8247863: Unreachable code in
 OperatingSystemImpl.getTotalSwapSpaceSize()
In-Reply-To: <AM0PR02MB5412FD7690F7762859E54AB193710@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <d526dcb167109fa23b510dcd87cb6cb365ba7c4b.camel@redhat.com>
 <40bd7c49d36c5775d86b9d2ff5740b50cf4359e9.camel@redhat.com>
 <AM0PR02MB5412A7A9AD7CA2987E913F09937E0@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <a92d552b3df0947a4481d15d94f6f3c0f3c29dd1.camel@redhat.com>
 <AM0PR02MB5412FD7690F7762859E54AB193710@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <eddd531b16d13dbf4bf26bd0a868f438f6c72a9b.camel@redhat.com>

On Thu, 2020-07-30 at 05:28 +0000, Baesken, Matthias wrote:
> > The only reason why a 0 was observed, was because the cgroup interface
> > files were missing and the old code mapped that to a 0. That's no
> > longer the case and, thus, it seems it would make the code clearer if
> > it wouldn't be there any more.
> > 
> > I don't feel strongly about this, though, and can just drop this patch.
> 
> Hi Severin, thanks for clarification, I'm fine with the patch !

Thanks for the review, Matthias.

Cheers,
Severin


From aph at redhat.com  Thu Jul 30 09:45:14 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 30 Jul 2020 10:45:14 +0100
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <ea85cdaa-0442-6909-7334-c91c05e04489@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>
 <10f1641b-3302-50ee-f7e7-e283685b2535@oss.nttdata.com>
 <ea85cdaa-0442-6909-7334-c91c05e04489@oss.nttdata.com>
Message-ID: <38423736-076f-e5f6-1bd9-9130f56892a5@redhat.com>

On 7/30/20 6:58 AM, Koichi Sakata wrote:
> I just formatted the patch to be same as the other code.
> 
> Moreover, I saw the following code in k_standard.c.
> 
> if (_LIB_VERSION == _SVID_)
>    exc.retval = zero;
> else
>    exc.retval = zero/zero;
> 
> Do we need to do like that in this patch? It seems to be related to the 
> old matherr(), but I'm not sure about that.

We don't need it; this is ancient history. Nonetheless, feel free to
be consistent with the old style. 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 daniel.fuchs at oracle.com  Thu Jul 30 10:14:46 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Jul 2020 11:14:46 +0100
Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
In-Reply-To: <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com>
References: <FB26A0A9-9A52-4049-B4A8-74FE55A15E84@azul.com>
 <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com>
 <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com>
 <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com>
 <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com>
 <2267CBC7-85A9-4105-B405-E7499440B985@azul.com>
 <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com>
 <FAB28765-C3CA-40E2-8374-8A632BFCD62D@azul.com>
 <f65907af-4acc-ef57-8c2c-98a44da11b97@oracle.com>
 <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com>
 <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com>
 <C4E26D8A-0E40-4E50-BC80-4209FF8E7B1C@azul.com>
 <643f3744-cfa2-e871-1284-900d81709f53@oracle.com>
 <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com>
 <FA0B11BA-00A5-4677-9363-54E3C813ED92@azul.com>
 <ebf5fd6f-91b7-0aa2-0416-3a70d2c4ea38@oracle.com>
 <A8655FE2-C845-4B71-8B35-7E99D1E20F28@azul.com>
 <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com>
 <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com>
 <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com>
Message-ID: <abc1e0bb-2e14-bf82-0f3d-aee314e4ce84@oracle.com>

Hi Alexey,

I have added myself as a reviewer to the CSR [1].
It would be good to get someone from security-dev to do the
same, and then move the CSR state to "Proposed".

best regards,

-- daniel

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

On 30/07/2020 10:17, Alexey Bakhtin wrote:
> Gentle ping
> 
> Regards
> Alexey


From suenaga at oss.nttdata.com  Thu Jul 30 12:13:57 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Thu, 30 Jul 2020 21:13:57 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <38423736-076f-e5f6-1bd9-9130f56892a5@redhat.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>
 <10f1641b-3302-50ee-f7e7-e283685b2535@oss.nttdata.com>
 <ea85cdaa-0442-6909-7334-c91c05e04489@oss.nttdata.com>
 <38423736-076f-e5f6-1bd9-9130f56892a5@redhat.com>
Message-ID: <80516d65-e4d1-546b-2371-dd070a0ae569@oss.nttdata.com>

Hi Koichi,

Looks good your change.

BTW have you got a sponsor?
I will sponsor you if you do not have yet.


Thanks,

Yasumasa


On 2020/07/30 18:45, Andrew Haley wrote:
> On 7/30/20 6:58 AM, Koichi Sakata wrote:
>> I just formatted the patch to be same as the other code.
>>
>> Moreover, I saw the following code in k_standard.c.
>>
>> if (_LIB_VERSION == _SVID_)
>>     exc.retval = zero;
>> else
>>     exc.retval = zero/zero;
>>
>> Do we need to do like that in this patch? It seems to be related to the
>> old matherr(), but I'm not sure about that.
> 
> We don't need it; this is ancient history. Nonetheless, feel free to
> be consistent with the old style. I'll approve it.
> 

From sakatakui at oss.nttdata.com  Thu Jul 30 14:10:07 2020
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Thu, 30 Jul 2020 23:10:07 +0900
Subject: Build error with GCC 10 in NetworkInterface.c and k_standard.c
In-Reply-To: <80516d65-e4d1-546b-2371-dd070a0ae569@oss.nttdata.com>
References: <fc709889-41f5-d47a-490c-61e09fff9582@oss.nttdata.com>
 <4a4e595c-3f44-ce95-4e75-fced84badb88@oracle.com>
 <cce053b6-c0c6-9096-ddc9-1148882ee76f@oss.nttdata.com>
 <0fa2b8a5-9849-2aa6-ac4b-fdc0aa267ce4@oracle.com>
 <45808e63-511d-56f0-531b-835f1f3fdbf4@oss.nttdata.com>
 <0c83d309-0f80-cda9-9c81-8bf19948dd6f@oracle.com>
 <2b4a1bf6-f2fb-9107-dd4f-2ad019f8f3c1@oss.nttdata.com>
 <36d7746b-dbd8-018e-f871-0d80b1336282@redhat.com>
 <10f1641b-3302-50ee-f7e7-e283685b2535@oss.nttdata.com>
 <ea85cdaa-0442-6909-7334-c91c05e04489@oss.nttdata.com>
 <38423736-076f-e5f6-1bd9-9130f56892a5@redhat.com>
 <80516d65-e4d1-546b-2371-dd070a0ae569@oss.nttdata.com>
Message-ID: <cf662dfd-eeb6-1362-5411-1a963a524daf@oss.nttdata.com>

 >> We don't need it; this is ancient history. Nonetheless, feel free to
 >> be consistent with the old style. I'll approve it.

I understand. Thank you, Andrew!

On 2020/07/30 21:13, Yasumasa Suenaga wrote:
> Hi Koichi,
> 
> Looks good your change.
> 
> BTW have you got a sponsor?
> I will sponsor you if you do not have yet.
> 
> 
> Thanks,
> 
> Yasumasa

I haven't found a sponsor yet. So I would appreciate it if you could 
sponsor this patch.

Thanks,
Koichi


> 
> 
> On 2020/07/30 18:45, Andrew Haley wrote:
>> On 7/30/20 6:58 AM, Koichi Sakata wrote:
>>> I just formatted the patch to be same as the other code.
>>>
>>> Moreover, I saw the following code in k_standard.c.
>>>
>>> if (_LIB_VERSION == _SVID_)
>>> ??? exc.retval = zero;
>>> else
>>> ??? exc.retval = zero/zero;
>>>
>>> Do we need to do like that in this patch? It seems to be related to the
>>> old matherr(), but I'm not sure about that.
>>
>> We don't need it; this is ancient history. Nonetheless, feel free to
>> be consistent with the old style. I'll approve it.
>>

From paul.sandoz at oracle.com  Thu Jul 30 15:13:29 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Jul 2020 08:13:29 -0700
Subject: RFR: JDK-8244288 Specialized implementations for putIfAbsent,
 merge, compute* methods in TreeMap derived maps
In-Reply-To: <CAE+3fja2CiSCU=zzTD2R=6YRWVg==0EwP7CRYuPmNz7xMmt1aQ@mail.gmail.com>
References: <CAE+3fjYAp-bvXJnF-Nvih2LSJoJFvx=g3ZNBHkmUcrm_FBX+5w@mail.gmail.com>
 <CAE+3fja2CiSCU=zzTD2R=6YRWVg==0EwP7CRYuPmNz7xMmt1aQ@mail.gmail.com>
Message-ID: <E0F551DA-A263-4A96-AA07-9A00035B72C6@oracle.com>

Hi Tagir,

Thanks for your measured patience. I will take a look.

Paul.

> On Jul 26, 2020, at 9:04 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> A gentle ping: please review
> https://bugs.openjdk.java.net/browse/JDK-8244288
> http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
> The details are listed below.
> 
> With best regards,
> Tagir Valeev.
> 
> On Sun, May 3, 2020 at 4:36 PM Tagir Valeev <amaembo at gmail.com> wrote:
>> 
>> Hello!
>> 
>> Please review the following change:
>> https://bugs.openjdk.java.net/browse/JDK-8244288
>> http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
>> 
>> We already implemented putIfAbsent, merge, computeIfAbsent,
>> computeIfPresent, and compute for TreeMap class (see JDK-8176894).
>> However, default implementations of these methods are still used for
>> TreeMap derived maps, such as descendingMap(), tailMap(), headMap()
>> and subMap(). The implementation is pretty straightforward, just a
>> range-check+delegation for each of these methods inside the
>> TreeMap.NavigableSubMap (+32 lines in TreeMap.java). Care should be
>> taken to avoid throwing IAE from compute* methods if the key is
>> outside of the range but we don't actually add the entry. This mimics
>> the previous behavior and also consistent with other modification
>> methods like Map.remove (we don't throw from remove if the key is out
>> of range, simply do nothing).
>> 
>> To cover these changes with tests, I added new
>> TreeMap().descendingMap() to
>> InPlaceOpsCollisions.nullValueFriendlyMaps and
>> MapWithCollisionsProviders.makeMapsMoreTypes. This map should behave
>> like a normal Map modulo iteration order but implementation goes
>> through NavigableSubMap. Also, I added more adders to
>> LockStep::randomAdder (lines 572+) to cover new methods, as well as
>> some more throws IAE asserts around line 806. At the same time, I took
>> the liberty to modernize this test:
>> - Convert all the raw-types to properly parameterized (using 'var' for
>> local vars where resulting type is long)
>> - Convert MapFrobber and SetFrobber to interfaces, and convert all the
>> implementations to lambdas (automatic conversion via IntelliJ IDEA +
>> rename of conflicting parameter names)
>> - Use for-each loop instead of indexed for loop where possible
>> - 'elts' array was created in two places but unused afterward. I added
>> size assert to these arrays to use it at least somehow (though
>> probably content should be checked as well).
>> - Use Comparator.naturalOrder() instead of manually written one in
>> comparator() methods (should not affect the testing in any way as it's
>> only used directly, not passed e.g. to TreeMap constructor).
>> - Use Objects.equals inside LockStep#equal
>> - Inverted 'if' at line 299 to avoid empty block.
>> If the cleanup really complicates the review I can post the cleanup as
>> a separate changeset. Though it should not be very problematic as the
>> actual changes are quite compact (as said above, near lines 572 and
>> 806)
>> 
>> I also improved the previously added benchmark TreeMapUpdate to check
>> descendingMap and tailMap cases to confirm the hypothesis that the
>> change improves the performance of derived maps. This is indeed the
>> case. E.g. merge test yields (comparator = false, size = 1000) for
>> unpatched JDK:
>> 
>> (benchmark)                 (mode) (prefill)    Score      Error  Units
>> TreeMapUpdate.merge        TreeMap   true   63589,075 ? 1028,065  ns/op
>> TreeMapUpdate.merge        TreeMap  false   65414,367 ? 1011,442  ns/op
>> TreeMapUpdate.merge  descendingMap   true  121501,618 ? 1849,108  ns/op
>> TreeMapUpdate.merge  descendingMap  false   95913,212 ? 2854,063  ns/op
>> TreeMapUpdate.merge        tailMap   true  126657,309 ? 4467,733  ns/op
>> TreeMapUpdate.merge        tailMap  false   93448,840 ? 1359,392  ns/op
>> 
>> As you can see, the merge on derived maps is significantly slower.
>> After the patch is applied the results are much better:
>> 
>> (benchmark)                 (mode)  (prefill)     Score      Error  Units
>> TreeMapUpdate.merge        TreeMap       true 64059,189 ?  808,230  ns/op
>> TreeMapUpdate.merge        TreeMap      false 65156,912 ? 1229,965  ns/op
>> TreeMapUpdate.merge  descendingMap       true 69938,131 ? 1697,357  ns/op
>> TreeMapUpdate.merge  descendingMap      false 67783,829 ?  263,061  ns/op
>> TreeMapUpdate.merge        tailMap       true 71079,529 ?  841,738  ns/op
>> TreeMapUpdate.merge        tailMap      false 68577,169 ? 1196,758  ns/op
>> 
>> I don't think this requires a CSR, as the changed class is
>> package-private, so it cannot be extended by clients.
>> 
>> With best regards,
>> Tagir Valeev.


From huizhe.wang at oracle.com  Thu Jul 30 16:20:15 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 30 Jul 2020 09:20:15 -0700
Subject: RFR [16/java.xml] 8250638: Address reliance on default constructors
 in java.xml
Message-ID: <4aeb1c8d-241a-c4de-4bfe-2cc48391d906@oracle.com>

Hello,

Please review a change to remove reliance of default constructors in 
java.xml.

JBS: https://bugs.openjdk.java.net/browse/JDK-8250638
CSR: https://bugs.openjdk.java.net/browse/JDK-8250800

Patch:

diff --git a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java 
b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
--- a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
+++ b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, 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
@@ -58,7 +58,10 @@
 ?public class HandlerBase
 ???? implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler
 ?{
-
+??? /**
+???? * Constructs a {@code HandlerBase}.
+???? */
+??? public HandlerBase() {}

////////////////////////////////////////////////////////////////////
 ???? // Default implementation of the EntityResolver interface.
diff --git 
a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java 
b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
--- a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
+++ b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, 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
@@ -70,7 +70,10 @@
 ?public class DefaultHandler
 ???? implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
 ?{
-
+??? /**
+???? * Constructs a {@code DefaultHandler}.
+???? */
+??? public DefaultHandler() {}

////////////////////////////////////////////////////////////////////
 ???? // Default implementation of the EntityResolver interface.

Thanks,
Joe


From joe.darcy at oracle.com  Thu Jul 30 16:24:29 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 30 Jul 2020 09:24:29 -0700
Subject: RFR [16/java.xml] 8250638: Address reliance on default
 constructors in java.xml
In-Reply-To: <4aeb1c8d-241a-c4de-4bfe-2cc48391d906@oracle.com>
References: <4aeb1c8d-241a-c4de-4bfe-2cc48391d906@oracle.com>
Message-ID: <3b53796a-9eec-8ccc-b6b5-6c65c72bc407@oracle.com>

Look fine Joe; thanks,

-Joe

On 7/30/2020 9:20 AM, Joe Wang wrote:
> Hello,
>
> Please review a change to remove reliance of default constructors in 
> java.xml.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8250638
> CSR: https://bugs.openjdk.java.net/browse/JDK-8250800
>
> Patch:
>
> diff --git a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java 
> b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> --- a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> +++ b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2020, 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
> @@ -58,7 +58,10 @@
> ?public class HandlerBase
> ???? implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler
> ?{
> -
> +??? /**
> +???? * Constructs a {@code HandlerBase}.
> +???? */
> +??? public HandlerBase() {}
>
> ////////////////////////////////////////////////////////////////////
> ???? // Default implementation of the EntityResolver interface.
> diff --git 
> a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java 
> b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> --- a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> +++ b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2020, 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
> @@ -70,7 +70,10 @@
> ?public class DefaultHandler
> ???? implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
> ?{
> -
> +??? /**
> +???? * Constructs a {@code DefaultHandler}.
> +???? */
> +??? public DefaultHandler() {}
>
> ////////////////////////////////////////////////////////////////////
> ???? // Default implementation of the EntityResolver interface.
>
> Thanks,
> Joe
>

From Nikola.Grcevski at microsoft.com  Thu Jul 30 16:25:38 2020
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Thu, 30 Jul 2020 16:25:38 +0000
Subject: RFR(s): Support graceful application termination on Windows
 shutdown/logoff
In-Reply-To: <b1d37679-f376-b9d8-0745-23c4f78ba304@oracle.com>
References: <DM6PR21MB12890934E3B440B16CB962B1F5770@DM6PR21MB1289.namprd21.prod.outlook.com>
 <b1d37679-f376-b9d8-0745-23c4f78ba304@oracle.com>
Message-ID: <DM6PR21MB1289F17FF6B8DE7F51746ED9F5710@DM6PR21MB1289.namprd21.prod.outlook.com>

Hi core-libs-dev,

I've been searching extensively the mailing list archives and JBS, but I cannot
find any more information on this topic, apart from the two linked bug reports [1] and [2].

I apologize for my newbie ?? search skills, can someone please help review the email
I sent to hotspot-runtime-dev below. 

Essentially, no shutdown code runs on normal Windows logoff/shutdown since Windows 7, 
which I believe was reported as change in behaviour under [1].

I want to point out that the issue has nothing to do with Virtual Machines, the JVM
simply doesn't receive the correct events, unless there's an AWT window open.
The implementation for WM_ENDSESSION in AWT seems to have a small issue that
the java process will terminate regardless of the user changing their mind about shutting down.

Thanks,
Nikola

[1] https://bugs.openjdk.java.net/browse/JDK-8079631
[2] https://bugs.openjdk.java.net/browse/JDK-7068835

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: July 23, 2020 11:02 PM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>; core-libs-dev Libs <core-libs-dev at openjdk.java.net>
Cc: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(s): Support graceful application termination on Windows shutdown/logoff

Hi Nikola,

I'm redirecting this to the core-libs team initially because this is an issue that has been raised and discussed considerably in the past (possibly with some misunderstanding relating to the WM_ENDSESSION event). The core-libs team need to confirm the intended semantics here and we (runtime) can then implement whatever is determined to be needed. 
Interaction with the client team for AWT interoperability may also be needed.

Thanks,
David

On 24/07/2020 11:47 am, Nikola Grcevski wrote:
> Hello hotspot-runtime-dev,
> 
> After some recent investigation into stale files remaining after Java 
> process terminates on Windows shutdown, we noticed that there's 
> missing support for detecting Windows shutdown/logoff events for 
> interactive Java applications. Given that Java loads both GDI32.dll 
> and USER32.dll, even for console applications, this means that almost 
> all Java processes launched on Windows don't run any shutdown hooks at the moment on user logoff or system shutdown/restart.
> 
> Since Windows 7, all Windows applications that load (or transitively 
> call) GDI32.dll or USER32.dll will not receive the CTRL_LOGOFF_EVENT 
> and CTRL_SHUTDOWN_EVENT events, but instead they will be sent WM_ENDSESSION.
> 
> This is documented in MSDN under the following article:
> 
> https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
> 
> It appears that this issue was logged in JSB at some point, but it was 
> made duplicate of another issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8079631
> 
> The behaviour changed going from Windows Vista to Windows 7.
> 
> I've made a proposal patch to address this issue under the following webrev:
> 
> http://cr.openjdk.java.net/~adityam/nikola/wm_endsession_handling/
> 
> At the moment only AWT applications would terminate gracefully on 
> shutdown/logoff, because they have support for listening on WM_ENDSESSION.
> There's a bug in the AWT code, it doesn't check for wparam upon 
> receiving the event, but it will work in most cases. If this patch is 
> accepted I can submit a follow-up patch for AWT to resolve the possible issues.
> 
> Finally, there are third set of events for service processes, for 
> example java applications which are started with a Windows Service 
> wrappers. These services work with SERVICE_ACCEPT_SHUTDOWN and SERVICE_CONTROL_SHUTDOWN.
> Once the most common case is resolved, I'd like to submit perhaps a 
> follow-up patch to support graceful termination of Java as Windows service programs.
> 
> We are working to amend the MSDN documentation for 
> SetConsoleCtrlHandler to specify that this behaviour change is also 
> present on server OSs. The documentation only mentions the workstation OS flavours at the moment.
> 
> Thanks in advance for reviewing this.
> 
> Nikola Grcevski
> Microsoft
> 

From LANCE.ANDERSEN at ORACLE.COM  Thu Jul 30 16:33:31 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Thu, 30 Jul 2020 12:33:31 -0400
Subject: RFR [16/java.xml] 8250638: Address reliance on default
 constructors in java.xml
In-Reply-To: <4aeb1c8d-241a-c4de-4bfe-2cc48391d906@oracle.com>
References: <4aeb1c8d-241a-c4de-4bfe-2cc48391d906@oracle.com>
Message-ID: <4DE96BD3-8C9D-43B3-AA44-7039BBF45A26@ORACLE.COM>

+1

> On Jul 30, 2020, at 12:20 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hello,
> 
> Please review a change to remove reliance of default constructors in java.xml.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8250638
> CSR: https://bugs.openjdk.java.net/browse/JDK-8250800
> 
> Patch:
> 
> diff --git a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> --- a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> +++ b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, 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
> @@ -58,7 +58,10 @@
>  public class HandlerBase
>      implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler
>  {
> -
> +    /**
> +     * Constructs a {@code HandlerBase}.
> +     */
> +    public HandlerBase() {}
> 
> ////////////////////////////////////////////////////////////////////
>      // Default implementation of the EntityResolver interface.
> diff --git a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> --- a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> +++ b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, 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
> @@ -70,7 +70,10 @@
>  public class DefaultHandler
>      implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
>  {
> -
> +    /**
> +     * Constructs a {@code DefaultHandler}.
> +     */
> +    public DefaultHandler() {}
> 
> ////////////////////////////////////////////////////////////////////
>      // Default implementation of the EntityResolver interface.
> 
> Thanks,
> Joe
> 


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From ningsheng.jian at arm.com  Thu Jul 30 01:53:07 2020
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Thu, 30 Jul 2020 09:53:07 +0800
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <852a3a09-a627-c0fc-89c6-8c8100ae17f5@redhat.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <852a3a09-a627-c0fc-89c6-8c8100ae17f5@redhat.com>
Message-ID: <564c8283-0c8f-9487-af3c-c971fa6b736d@arm.com>

On 7/29/20 7:44 PM, Andrew Haley wrote:
> On 20/07/2020 04:51, Ningsheng Jian wrote:
>> Since we are getting ready to propose Vector API target to JDK 16 [1]. I
>> have regenerated webrev of aarch64 backend parts from panama repo, which
>> has been rebased to jdk/jdk very recently, by:
>>
>> $ hg update vector-unstable && hg diff -r default > all.patch
>> $ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk
>> '{print $4}' > aarch64_list
>> $ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list
>>
>> The new webrev:
>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/
>>
>> Could you please help to take a look?
> 
> OK, thanks. It all looks fine. Sorry for the delay.
> 
Thank you Andrew!

Regards,
Ningsheng

From brian.burkhalter at oracle.com  Thu Jul 30 21:39:57 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 30 Jul 2020 14:39:57 -0700
Subject: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on
 Windows
In-Reply-To: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>
References: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>
Message-ID: <ED20613D-D8D1-4836-8A23-B538756CEC7B@oracle.com>

Hi Igor,

This test looks all right to me.

Sorry for the late review.

Thanks,

Brian

> On Jul 20, 2020, at 11:28 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00 <http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00>
>> 98 lines changed: 18 ins; 31 del; 49 mod;
> 
> Hi all,
> 
> could you please review this small fix to make java/io/File/GetXSpace.java work again on windows?
> 
> the test has been updated to work under cygwin, which includes the following changes:
> - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
> - uses the same regexp to parse df on windows as on other platforms
> - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is corresponding windows path, and the test expect Space's name to be appropriate path


From naoto.sato at oracle.com  Thu Jul 30 21:53:29 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 30 Jul 2020 14:53:29 -0700
Subject: RFR 8233048: WeekFields.ISO is not a singleton
Message-ID: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed chageset is located at:

https://cr.openjdk.java.net/~naoto/8233048/webrev.00/

java.time.temporal.WeekFields.ISO is instantiated using the constructor, 
which is a different object returned from WeekFields.of(MONDAY, 4). Even 
though this itself does not cause any issues, since objects are "equal", 
but the fix will provide the identity, as WeekFields objects are 
supposed to be singletons.

Naoto


From scolebourne at joda.org  Thu Jul 30 23:21:23 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 31 Jul 2020 00:21:23 +0100
Subject: RFR 8233048: WeekFields.ISO is not a singleton
In-Reply-To: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>
References: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>
Message-ID: <CACzrW9Aff+1pFr0qfXg4fQV0OHQ=GTQmFspsWOgzb57X5vvNOg@mail.gmail.com>

 +1
Stephen

On Thu, 30 Jul 2020 at 22:54, <naoto.sato at oracle.com> wrote:
>
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233048
>
> The proposed chageset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233048/webrev.00/
>
> java.time.temporal.WeekFields.ISO is instantiated using the constructor,
> which is a different object returned from WeekFields.of(MONDAY, 4). Even
> though this itself does not cause any issues, since objects are "equal",
> but the fix will provide the identity, as WeekFields objects are
> supposed to be singletons.
>
> Naoto
>

From huizhe.wang at oracle.com  Thu Jul 30 23:25:01 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 30 Jul 2020 16:25:01 -0700
Subject: RFR 8233048: WeekFields.ISO is not a singleton
In-Reply-To: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>
References: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>
Message-ID: <57a7f527-342a-fdf5-a7ef-5f5a9146155f@oracle.com>

+1

-Joe

On 7/30/20 2:53 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233048
>
> The proposed chageset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233048/webrev.00/
>
> java.time.temporal.WeekFields.ISO is instantiated using the 
> constructor, which is a different object returned from 
> WeekFields.of(MONDAY, 4). Even though this itself does not cause any 
> issues, since objects are "equal", but the fix will provide the 
> identity, as WeekFields objects are supposed to be singletons.
>
> Naoto
>


From alexander.matveev at oracle.com  Fri Jul 31 00:10:29 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Thu, 30 Jul 2020 17:10:29 -0700
Subject: RFR: 8250646: hdiutil detach fix JDK-8245311 still fails sometimes
Message-ID: <fa73743d-5f01-9be2-d8df-7373d46d740e@oracle.com>

Please review the jpackage fix for bug [1] at [2].

- DMG image can get detach even if "hdiutil detach" return resource busy 
error. Fixed by stopping trying detach if DMG already got detach.

[1] https://bugs.openjdk.java.net/browse/JDK-8250646
[2] http://cr.openjdk.java.net/~almatvee/8250646/webrev.00/

Thanks,
Alexander

From roger.riggs at oracle.com  Fri Jul 31 00:32:48 2020
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 30 Jul 2020 20:32:48 -0400
Subject: RFR 8233048: WeekFields.ISO is not a singleton
In-Reply-To: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>
References: <35ec2615-4b54-1b85-6798-a03e697adaeb@oracle.com>
Message-ID: <c7c67f3f-ed19-1ffe-b961-60c69d4bd349@oracle.com>

Looks good Naoto.

Thanks, Roger

On 7/30/20 5:53 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233048
>
> The proposed chageset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233048/webrev.00/
>
> java.time.temporal.WeekFields.ISO is instantiated using the 
> constructor, which is a different object returned from 
> WeekFields.of(MONDAY, 4). Even though this itself does not cause any 
> issues, since objects are "equal", but the fix will provide the 
> identity, as WeekFields objects are supposed to be singletons.
>
> Naoto
>


From felix.yang at huawei.com  Fri Jul 31 01:45:04 2020
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Fri, 31 Jul 2020 01:45:04 +0000
Subject: [PING?] RFR(S): 8248910: NPE when freeing the memory for a slice
 from a buffer
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE7E9134D@dggeml507-mbx.china.huawei.com>

Ping...  Any suggestions?

Thanks,
Felix


> -----Original Message-----
> From: Yangfei (Felix)
> Sent: Wednesday, July 8, 2020 11:35 AM
> To: core-libs-dev at openjdk.java.net
> Subject: RFR(S): 8248910: NPE when freeing the memory for a slice from a
> buffer
> 
> Hi,
> 
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8248910
>     Webrev: http://cr.openjdk.java.net/~fyang/8248910/webrev.00/
> 
>     The overall procedure is described by the newly add test.
>     For a slice from a ByteBuffer, it does not have a cleaner, which leads to the
> NPE.
>     Here, I thinks we should not try to free the memory of a slice.
>     Proposed fix adds a null check for cleaner in Util.free before invoking its
> clean() method.
>     Another possible way would be catching slice in Util.
> releaseTemporaryDirectBuffer and exclude it.
> 
>     Tier1-3 tested on x86_64-linux-gnu.  Newly add test fail without the fix and
> pass otherwise.
>     Comments?
> 
> Thanks,
> Felix

From igor.ignatyev at oracle.com  Fri Jul 31 02:44:52 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 30 Jul 2020 19:44:52 -0700
Subject: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on
 Windows
In-Reply-To: <ED20613D-D8D1-4836-8A23-B538756CEC7B@oracle.com>
References: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>
 <ED20613D-D8D1-4836-8A23-B538756CEC7B@oracle.com>
Message-ID: <880A7150-A724-4205-93B2-E4C1CE20A67E@oracle.com>

Hi Brian,

thanks for your review. I've decided to push into jdk/jdk instead of jdk15. please let me know if you think this patch needs to be in jdk15, and I'll backport it there.

Cheers,
-- Igor

> On Jul 30, 2020, at 2:39 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Igor,
> 
> This test looks all right to me.
> 
> Sorry for the late review.
> 
> Thanks,
> 
> Brian
> 
>> On Jul 20, 2020, at 11:28 AM, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00 <http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00>
>>> 98 lines changed: 18 ins; 31 del; 49 mod;
>> 
>> Hi all,
>> 
>> could you please review this small fix to make java/io/File/GetXSpace.java work again on windows?
>> 
>> the test has been updated to work under cygwin, which includes the following changes:
>> - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
>> - uses the same regexp to parse df on windows as on other platforms
>> - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is corresponding windows path, and the test expect Space's name to be appropriate path
> 


From Alan.Bateman at oracle.com  Fri Jul 31 08:34:48 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 31 Jul 2020 09:34:48 +0100
Subject: [PING?] RFR(S): 8248910: NPE when freeing the memory for a slice
 from a buffer
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE7E9134D@dggeml507-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE7E9134D@dggeml507-mbx.china.huawei.com>
Message-ID: <765da797-37a8-16cc-71b5-81a9f85e35af@oracle.com>

On 31/07/2020 02:45, Yangfei (Felix) wrote:
> Ping...  Any suggestions?
>
Can you bring this to nio-dev for discussion? I don't know what 
"Randoop" is but it seems to be using sun.nio.ch.Util directly. I think 
I'd like to understand if there is a case where we would actually 
attempt to free a slice when using the exported buffer APIs.

-Alan

From andy.herrick at oracle.com  Fri Jul 31 14:35:22 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 31 Jul 2020 10:35:22 -0400
Subject: RFR: 8250646: hdiutil detach fix JDK-8245311 still fails sometimes
In-Reply-To: <fa73743d-5f01-9be2-d8df-7373d46d740e@oracle.com>
References: <fa73743d-5f01-9be2-d8df-7373d46d740e@oracle.com>
Message-ID: <ec82a91f-5f3c-4973-9904-0a2cabfe1280@oracle.com>

looks good to me

/Andy

On 7/30/2020 8:10 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - DMG image can get detach even if "hdiutil detach" return resource 
> busy error. Fixed by stopping trying detach if DMG already got detach.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8250646
> [2] http://cr.openjdk.java.net/~almatvee/8250646/webrev.00/
>
> Thanks,
> Alexander

From brian.burkhalter at oracle.com  Fri Jul 31 15:16:58 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 Jul 2020 08:16:58 -0700
Subject: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on
 Windows
In-Reply-To: <880A7150-A724-4205-93B2-E4C1CE20A67E@oracle.com>
References: <2236D17C-4A2E-4BA5-A9AA-7C50A96CC348@oracle.com>
 <ED20613D-D8D1-4836-8A23-B538756CEC7B@oracle.com>
 <880A7150-A724-4205-93B2-E4C1CE20A67E@oracle.com>
Message-ID: <0544A37E-C9F9-4E84-92D8-0631AE2F39A5@oracle.com>

Hi Igor,

No, I think JDK mainline is good, especially given that it is a test.

Thanks,

Brian

> On Jul 30, 2020, at 7:44 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> thanks for your review. I've decided to push into jdk/jdk instead of jdk15. please let me know if you think this patch needs to be in jdk15, and I'll backport it there.


From alexey.semenyuk at oracle.com  Fri Jul 31 16:27:50 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 31 Jul 2020 12:27:50 -0400
Subject: RFR: 8250646: hdiutil detach fix JDK-8245311 still fails sometimes
In-Reply-To: <fa73743d-5f01-9be2-d8df-7373d46d740e@oracle.com>
References: <fa73743d-5f01-9be2-d8df-7373d46d740e@oracle.com>
Message-ID: <7ff275fd-90f6-05c7-2979-4622daeb82e4@oracle.com>

Alexander,

Why introduce RetryExecutor.stop() method? Isn't RetryExecutor.abort() 
sufficient?

- Alexey

On 7/30/2020 8:10 PM, alexander.matveev at oracle.com wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> - DMG image can get detach even if "hdiutil detach" return resource 
> busy error. Fixed by stopping trying detach if DMG already got detach.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8250646
> [2] http://cr.openjdk.java.net/~almatvee/8250646/webrev.00/
>
> Thanks,
> Alexander


From brian.burkhalter at oracle.com  Fri Jul 31 17:42:30 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 Jul 2020 10:42:30 -0700
Subject: 8249703: test/jdk/java/io/File/GetXSpace.java fails on macos
Message-ID: <FAAE3D8F-09CF-48ED-BF7E-B70F9C348052@oracle.com>

On macOS, the number of 1024 byte blocks appears to be incorrectly calculated by 'df' using integer division by 2 of the number of 512 byte blocks, resulting in a size smaller than the actual value when the number of blocks is odd.

Possibly instead of having the IS_MAC and IS_WIN constants it should use the equivalent methods in jdk.test.lib.Platform?

Thanks,

Brian

https://bugs.openjdk.java.net/browse/JDK-8249703
http://cr.openjdk.java.net/~bpb/8249703/webrev.00/

From ecki at zusammenkunft.net  Fri Jul 31 20:17:24 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 31 Jul 2020 20:17:24 +0000
Subject: Language locales have different calendars than country locales in 9+
Message-ID: <AM6PR03MB43898D645E9BFEEAC0621364FF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

Just wanted to mention a thing I noticed when switching from 8 to 11. I knew before that the Locale data provider has changed, and I could notice that for example in the writing style for abbreviated words in dates. However something I did not expect is, that the definition of Calemdars change as well.

Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11 with CLDR as opposed to Java 8 or Java 11 with compat. The most notably changes are when calculating calendar weeks (min days in first week) or the start of a week (Sunday vs. Monday).

I haven't seen that explicitely mentioned and I also wonder if this should be mentioned in the Locale JavaDoc that language locales and country locales might differ severely in that aspect.


GERMANY:
Calendar.minDays 4 java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=?,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
11.0.1+13-LTS de_DE 2011-01-01 2010-52

GERMAN
Calendar.minDays 1 java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
11.0.1+13-LTS de    2011-01-01 2011-01

Sample code:

    Date d = new Date(1293843600000L);

    Locale l = Locale.GERMANY;

    Calendar c = Calendar.getInstance(l);
    System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + " " + c);

    SimpleDateFormat sdf = newSimpleDateFormat("yyyy-MM-DD YYYY-ww", l);
    System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), l, sdf.format(d));


--
http://bernd.eckenfels.net

From naoto.sato at oracle.com  Fri Jul 31 21:24:33 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 31 Jul 2020 14:24:33 -0700
Subject: Language locales have different calendars than country locales in
 9+
In-Reply-To: <AM6PR03MB43898D645E9BFEEAC0621364FF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <AM6PR03MB43898D645E9BFEEAC0621364FF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <ca84ad07-93f3-b108-6cf5-33e2a0012b7f@oracle.com>

Hi Bernd,

As you pointed out, the change you see here is the result of this change 
in JDK9:

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

where the default locale provider was switched to CLDR. Although we 
don't describe those behavior changes in the spec (as it is regarded as 
l10n changes which may differ across implementations), it was generally 
noted in JDK9's release note:

---
As a result, users may see differences in locale sensitive services 
behavior and/or translations. [1]
---

You can use the COMPAT provider through the java.locale.providers system 
property if you need the pre-JDK9 behavior.

HTH,
Naoto

[1] https://www.oracle.com/java/technologies/javase/v9-issues-relnotes.html

On 7/31/20 1:17 PM, Bernd Eckenfels wrote:
> Hello,
> 
> Just wanted to mention a thing I noticed when switching from 8 to 11. I knew before that the Locale data provider has changed, and I could notice that for example in the writing style for abbreviated words in dates. However something I did not expect is, that the definition of Calemdars change as well.
> 
> Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11 with CLDR as opposed to Java 8 or Java 11 with compat. The most notably changes are when calculating calendar weeks (min days in first week) or the start of a week (Sunday vs. Monday).
> 
> I haven't seen that explicitely mentioned and I also wonder if this should be mentioned in the Locale JavaDoc that language locales and country locales might differ severely in that aspect.
> 
> 
> GERMANY:
> Calendar.minDays 4 java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=?,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
> 11.0.1+13-LTS de_DE 2011-01-01 2010-52
> 
> GERMAN
> Calendar.minDays 1 java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
> 11.0.1+13-LTS de    2011-01-01 2011-01
> 
> Sample code:
> 
>      Date d = new Date(1293843600000L);
> 
>      Locale l = Locale.GERMANY;
> 
>      Calendar c = Calendar.getInstance(l);
>      System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + " " + c);
> 
>      SimpleDateFormat sdf = newSimpleDateFormat("yyyy-MM-DD YYYY-ww", l);
>      System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), l, sdf.format(d));
> 
> 
> --
> http://bernd.eckenfels.net
> 

From ecki at zusammenkunft.net  Fri Jul 31 22:08:26 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 31 Jul 2020 22:08:26 +0000
Subject: Language locales have different calendars than country locales in
 9+
In-Reply-To: <ca84ad07-93f3-b108-6cf5-33e2a0012b7f@oracle.com>
References: <AM6PR03MB43898D645E9BFEEAC0621364FF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>,
 <ca84ad07-93f3-b108-6cf5-33e2a0012b7f@oracle.com>
Message-ID: <AM6PR03MB43895C13B60C885DB5EA905FFF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

Is there a good description what calendar is actually used for a language-only locale? Is there a typical association of calendars with locales or is it a global default? If the unicode data does not have such a value, would it be better to fall back to the next provider (like COMPAT)?

I understand that it was hinted at in the release notes, but this is a very severe change in major locales - at least I was not expecting that (as opposed to textual changes to timezones or month names).

I am a bit burned by using compat flags as they might get removed in the futur, is there any plans on how long the JRE locale provider will be available, I.e. ist it s safe bet to use it?

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: naoto.sato at oracle.com <naoto.sato at oracle.com>
Gesendet: Friday, July 31, 2020 11:24:33 PM
An: Bernd Eckenfels <ecki at zusammenkunft.net>; core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: Re: Language locales have different calendars than country locales in 9+

Hi Bernd,

As you pointed out, the change you see here is the result of this change
in JDK9:

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

where the default locale provider was switched to CLDR. Although we
don't describe those behavior changes in the spec (as it is regarded as
l10n changes which may differ across implementations), it was generally
noted in JDK9's release note:

---
As a result, users may see differences in locale sensitive services
behavior and/or translations. [1]
---

You can use the COMPAT provider through the java.locale.providers system
property if you need the pre-JDK9 behavior.

HTH,
Naoto

[1] https://www.oracle.com/java/technologies/javase/v9-issues-relnotes.html

On 7/31/20 1:17 PM, Bernd Eckenfels wrote:
> Hello,
>
> Just wanted to mention a thing I noticed when switching from 8 to 11. I knew before that the Locale data provider has changed, and I could notice that for example in the writing style for abbreviated words in dates. However something I did not expect is, that the definition of Calemdars change as well.
>
> Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11 with CLDR as opposed to Java 8 or Java 11 with compat. The most notably changes are when calculating calendar weeks (min days in first week) or the start of a week (Sunday vs. Monday).
>
> I haven't seen that explicitely mentioned and I also wonder if this should be mentioned in the Locale JavaDoc that language locales and country locales might differ severely in that aspect.
>
>
> GERMANY:
> Calendar.minDays 4 java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=?,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
> 11.0.1+13-LTS de_DE 2011-01-01 2010-52
>
> GERMAN
> Calendar.minDays 1 java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
> 11.0.1+13-LTS de    2011-01-01 2011-01
>
> Sample code:
>
>      Date d = new Date(1293843600000L);
>
>      Locale l = Locale.GERMANY;
>
>      Calendar c = Calendar.getInstance(l);
>      System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + " " + c);
>
>      SimpleDateFormat sdf = newSimpleDateFormat("yyyy-MM-DD YYYY-ww", l);
>      System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), l, sdf.format(d));
>
>
> --
> http://bernd.eckenfels.net
>

From joe.darcy at oracle.com  Fri Jul 31 22:12:38 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 31 Jul 2020 15:12:38 -0700
Subject: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and
 AnnotatedWildcardType bounds methods return one
Message-ID: <9808e420-39a8-2045-9db1-629a551f82a0@oracle.com>

Hello,

Please review the doc clarification below to address

 ??? 8250660: Clarify that WildcardType and AnnotatedWildcardType bounds 
methods return one

Thanks,

-Joe

diff -r b0553ba43ba1 
src/java.base/share/classes/java/lang/reflect/AnnotatedWildcardType.java
--- 
a/src/java.base/share/classes/java/lang/reflect/AnnotatedWildcardType.java 
Fri Jul 31 11:35:25 2020 -0700
+++ 
b/src/java.base/share/classes/java/lang/reflect/AnnotatedWildcardType.java 
Fri Jul 31 15:12:14 2020 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2012, 2020, 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
@@ -30,6 +30,7 @@
 ? * wildcard type argument, whose upper or lower bounds may themselves 
represent
 ? * annotated uses of types.
 ? *
+ * @jls 4.5.1 Type Arguments of Parameterized Types
 ? * @since 1.8
 ? */
 ?public interface AnnotatedWildcardType extends AnnotatedType {
@@ -39,6 +40,9 @@
 ????? * If no lower bound is explicitly declared, the lower bound is the
 ????? * type of null. In this case, a zero length array is returned.
 ????? *
+???? * @apiNote In the current version of the Java Programming
+???? * Language, a wildcard may have at most one lower bound.
+???? *
 ????? * @return the potentially annotated lower bounds of this wildcard 
type or
 ????? * an empty array if no lower bound is explicitly declared.
 ????? * @see WildcardType#getLowerBounds()
@@ -50,6 +54,9 @@
 ????? * If no upper bound is explicitly declared, the upper bound is
 ????? * unannotated {@code Object}
 ????? *
+???? * @apiNote In the current version of the Java Programming
+???? * Language, a wildcard may have at most one upper bound.
+???? *
 ????? * @return the potentially annotated upper bounds of this wildcard 
type
 ????? * @see WildcardType#getUpperBounds()
 ????? */
diff -r b0553ba43ba1 
src/java.base/share/classes/java/lang/reflect/WildcardType.java
--- a/src/java.base/share/classes/java/lang/reflect/WildcardType.java 
Fri Jul 31 11:35:25 2020 -0700
+++ b/src/java.base/share/classes/java/lang/reflect/WildcardType.java 
Fri Jul 31 15:12:14 2020 -0700
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2020, 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 @@
 ? * WildcardType represents a wildcard type expression, such as
 ? * {@code ?}, {@code ? extends Number}, or {@code ? super Integer}.
 ? *
+ * @jls 4.5.1 Type Arguments of Parameterized Types
 ? * @since 1.5
 ? */
 ?public interface WildcardType extends Type {
@@ -45,6 +46,9 @@
 ????? *? <li>Otherwise, B is resolved.
 ????? * </ul>
 ????? *
+???? * @apiNote In the current version of the Java Programming
+???? * Language, a wildcard may have at most one upper bound.
+???? *
 ????? * @return an array of Types representing the upper bound(s) of this
 ????? *???? type variable
 ????? * @throws TypeNotPresentException if any of the
@@ -69,6 +73,9 @@
 ????? *?? <li>Otherwise, B is resolved.
 ????? * </ul>
 ????? *
+???? * @apiNote In the current version of the Java Programming
+???? * Language, a wildcard may have at most one lower bound.
+???? *
 ????? * @return an array of Types representing the lower bound(s) of this
 ????? *???? type variable
 ????? * @throws TypeNotPresentException if any of the
@@ -78,6 +85,4 @@
 ????? *???? for any reason
 ????? */
 ???? Type[] getLowerBounds();
-??? // one or many? Up to language spec; currently only one, but this API
-??? // allows for generalization.
 ?}


From naoto.sato at oracle.com  Fri Jul 31 22:40:25 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 31 Jul 2020 15:40:25 -0700
Subject: Language locales have different calendars than country locales in
 9+
In-Reply-To: <AM6PR03MB43895C13B60C885DB5EA905FFF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <AM6PR03MB43898D645E9BFEEAC0621364FF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <ca84ad07-93f3-b108-6cf5-33e2a0012b7f@oracle.com>
 <AM6PR03MB43895C13B60C885DB5EA905FFF4E0@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <6da595eb-cc57-9154-f061-e00b0254bf99@oracle.com>

On 7/31/20 3:08 PM, Bernd Eckenfels wrote:
> Hello,
> 
> Is there a good description what calendar is actually used for a language-only locale? Is there a typical association of calendars with locales or is it a global default? If the unicode data does not have such a value, would it be better to fall back to the next provider (like COMPAT)?

In CLDR, those calendar data are tied to territory:

https://unicode-org.github.io/cldr-staging/charts/37/supplemental/territory_information.html

So if the locale is language only, it falls back to the default values. 
There is a provider fallback mechanism for non-supported locales, i.e., 
if xx-YY is not supproted by CLDR, it will look into the next locale 
provider such as COMPAT, but as "de-DE/de" are supported by CLDR, it 
won't look into COMPAT. This is because CLDR itself has its own 
fallback, such as de-DE -> de -> ROOT, and if COMPAT cuts in between, 
unpredictable behavior may occur.

> 
> I understand that it was hinted at in the release notes, but this is a very severe change in major locales - at least I was not expecting that (as opposed to textual changes to timezones or month names).

Yes, I understand. However JDK is simply using CLDR's data as they are.

> 
> I am a bit burned by using compat flags as they might get removed in the futur, is there any plans on how long the JRE locale provider will be available, I.e. ist it s safe bet to use it?

Cannot comment on the future, but not likely in the near future, as some 
features such as collation is not implemented in CLDR provider.

Naoto

> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: naoto.sato at oracle.com <naoto.sato at oracle.com>
> Gesendet: Friday, July 31, 2020 11:24:33 PM
> An: Bernd Eckenfels <ecki at zusammenkunft.net>; core-libs-dev <core-libs-dev at openjdk.java.net>
> Betreff: Re: Language locales have different calendars than country locales in 9+
> 
> Hi Bernd,
> 
> As you pointed out, the change you see here is the result of this change
> in JDK9:
> 
> https://bugs.openjdk.java.net/browse/JDK-8008577
> 
> where the default locale provider was switched to CLDR. Although we
> don't describe those behavior changes in the spec (as it is regarded as
> l10n changes which may differ across implementations), it was generally
> noted in JDK9's release note:
> 
> ---
> As a result, users may see differences in locale sensitive services
> behavior and/or translations. [1]
> ---
> 
> You can use the COMPAT provider through the java.locale.providers system
> property if you need the pre-JDK9 behavior.
> 
> HTH,
> Naoto
> 
> [1] https://www.oracle.com/java/technologies/javase/v9-issues-relnotes.html
> 
> On 7/31/20 1:17 PM, Bernd Eckenfels wrote:
>> Hello,
>>
>> Just wanted to mention a thing I noticed when switching from 8 to 11. I knew before that the Locale data provider has changed, and I could notice that for example in the writing style for abbreviated words in dates. However something I did not expect is, that the definition of Calemdars change as well.
>>
>> Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11 with CLDR as opposed to Java 8 or Java 11 with compat. The most notably changes are when calculating calendar weeks (min days in first week) or the start of a week (Sunday vs. Monday).
>>
>> I haven't seen that explicitely mentioned and I also wonder if this should be mentioned in the Locale JavaDoc that language locales and country locales might differ severely in that aspect.
>>
>>
>> GERMANY:
>> Calendar.minDays 4 java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=?,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
>> 11.0.1+13-LTS de_DE 2011-01-01 2010-52
>>
>> GERMAN
>> Calendar.minDays 1 java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=3600000,DST_OFFSET=3600000]
>> 11.0.1+13-LTS de    2011-01-01 2011-01
>>
>> Sample code:
>>
>>       Date d = new Date(1293843600000L);
>>
>>       Locale l = Locale.GERMANY;
>>
>>       Calendar c = Calendar.getInstance(l);
>>       System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + " " + c);
>>
>>       SimpleDateFormat sdf = newSimpleDateFormat("yyyy-MM-DD YYYY-ww", l);
>>       System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), l, sdf.format(d));
>>
>>
>> --
>> http://bernd.eckenfels.net
>>

From alexander.matveev at oracle.com  Fri Jul 31 23:36:39 2020
From: alexander.matveev at oracle.com (alexander.matveev at oracle.com)
Date: Fri, 31 Jul 2020 16:36:39 -0700
Subject: RFR: 8250646: hdiutil detach fix JDK-8245311 still fails sometimes
In-Reply-To: <7ff275fd-90f6-05c7-2979-4622daeb82e4@oracle.com>
References: <fa73743d-5f01-9be2-d8df-7373d46d740e@oracle.com>
 <7ff275fd-90f6-05c7-2979-4622daeb82e4@oracle.com>
Message-ID: <76d775dd-fc4b-16e8-9517-cb9a0623509a@oracle.com>

Hi Alexey,

Without modifying some logic in Executor, yes stop is needed. After 
retryExecutor.stop(); is executed in MacDmgBundler we will still run 
command (same with abort), and this command will fail and exception will 
be thrown. Stop() is basically like abort, but exception is ignored.

Thanks,
Alexander

On 7/31/20 9:27 AM, Alexey Semenyuk wrote:
> Alexander,
>
> Why introduce RetryExecutor.stop() method? Isn't RetryExecutor.abort() 
> sufficient?
>
> - Alexey
>
> On 7/30/2020 8:10 PM, alexander.matveev at oracle.com wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> - DMG image can get detach even if "hdiutil detach" return resource 
>> busy error. Fixed by stopping trying detach if DMG already got detach.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8250646
>> [2] http://cr.openjdk.java.net/~almatvee/8250646/webrev.00/
>>
>> Thanks,
>> Alexander
>