Integrated: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Sergey Bylokhov 
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

This pull request has now been integrated.

Changeset: ec2fc384
Author:Sergey Bylokhov 
URL:   
https://git.openjdk.java.net/jdk/commit/ec2fc384e50668b667335f973ffeb5a19bbcfb9b
Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod

8272120: Avoid looking for standard encodings in "java." modules

Reviewed-by: alanb, dfuchs, naoto

-

PR: https://git.openjdk.java.net/jdk/pull/5063

Re: JDK17 - Possible TLS issue.

2021-08-11 Thread Peter Firmstone 

Thanks Jamil,

You'll need to use JDK 8 for building / compiling,

Additional to the build instructions, to test the specific test in question:

Create a build.properties file in the project root directory (same 
directory as README.md), containing the following entries:


   jsk.home=absolute path to JGDMS project directory.
   
run.tests=org/apache/river/test/spec/lookupservice/test_set02/LookupNegMatches.td

These two files allow you to manipulate JVM arguments and logging:

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/qa/resources/qaDefaults.properties

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/resources/qa1.logging

JGDMS runs with a SecurityManager enabled by default, I haven't yet 
tested it without SM.


In the event that you experience an AccessControlException / 
SecurityException, insert the following two properties to 
qaDefaults.properties, at line 426:


-Djava.security.manager=org.apache.river.tool.SecurityPolicyWriter,\
-DSecurityPolicyWriter.path.properties=${qa.home}/harness/policy/securitypolicywriterpath.properties,\

These will update policy files with any missing permissions the next 
time you run the test (you may need to run it on JDK16), then you should 
remove these two options, as the policy files will have all necessary 
permissions.


I did manage to capture one passing run on JDK17, I haven't been able to 
reproduce it, but it suggests the failure might be related to timing, 
locking or gc:


https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-security-debug-fine-logging-tls-handshake.txt

Regards,

Peter.

On 12/08/2021 5:32 am, Jamil Nimeh wrote:

Hi Peter,

I've captured the issue in 
https://bugs.openjdk.java.net/browse/JDK-8272340.  The synopsis is a 
bit vague right now as I'm going through the logs.  I'll revise it 
once I have a little more info.  I was also looking at the JGDMS 
project just to see how easy it would be for me to replicate the 
specific tests that exhibit the failure.  I may contact you directly 
for a bit more info.  The instructions on the JGDMS page look pretty 
straightforward, so hopefully that won't take long to replicate.


Thanks,

--Jamil

On 8/11/2021 3:12 AM, Peter Firmstone wrote:

谢谢johnsjiang(江莎)，

I set the property:

-Djdk.tls.acknowledgeCloseNotify=true.

Unfortunately the test is still failing on JDK17, although the output 
has changed and acknowledges the duplex close, so it appears 
something else is causing the connection to close early. 
Interestingly, there is a WARNING that the socket didn't close, 
followed by an ERROR, then FATAL(UNEXPECTED MESSAGE).


致以诚挚的问候Peter.

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug-ack-close-notify-true.txt 



 [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) 
ConnectionManager.Reaper|2021-08-11 19:41:49.598 
AEST|SSLSocketImpl.java:572|duplex close of SSLSocket
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert 
message (

 [java] ActSys-err: "Alert": {
 [java] ActSys-err:   "level"  : "warning",
 [java] ActSys-err:   "description": "user_canceled"
 [java] ActSys-err: }
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) 
ConnectionManager.Reaper|2021-08-11 19:41:49.599 
AEST|SSLSocketImpl.java:1775|close the SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert 
message (

 [java] ActSys-err: "Alert": {
 [java] ActSys-err:   "level"  : "warning",
 [java] ActSys-err:   "description": "close_notify"
 [java] ActSys-err: }
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|ALL|A2|(JSK) mux 
writer|2021-08-11 19:41:49.599 AEST|SSLSocketImpl.java:1324|Closing 
output stream
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex 
close of SSLSocket
 [java] ActSys-err: javax.net.ssl|ALL|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1324|Closing 
output stream
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the 
SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex 
close of SSLSocket
 [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the 
SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1129|Closing 
input stream
 [java] ActSys-err: javax.net.ssl|WARNING|C2|(JSK) mux 
writer|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:600|SSLSocket 
close failed. Debug info only. Exception details: (

 [java]

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v9]

2021-08-11 Thread Valerie Peng 
On Wed, 11 Aug 2021 17:49:57 GMT, Smita Kamath  wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures 
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES 
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   comment update

Java changes look good. Thanks.

-

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4019

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Naoto Sato 
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by naoto (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5063

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Daniel Fuchs 
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by dfuchs (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5063

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Alan Bateman 
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5063

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Alan Bateman 
On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad  wrote:

> Yes, while I don't know exactly which changes resolved JDK-6764325, it's 
> clear from the microbenchmarks added for #2102 that it's no longer an issue - 
> at least not in the mainline.

Thanks for checking and for closing that issue.

-

PR: https://git.openjdk.java.net/jdk/pull/5063

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v9]

2021-08-11 Thread Smita Kamath 
> I would like to submit AES-GCM optimization for x86_64 architectures 
> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES 
> and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

Smita Kamath has updated the pull request incrementally with one additional 
commit since the last revision:

  comment update

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4019/files
  - new: https://git.openjdk.java.net/jdk/pull/4019/files/ecf8e6d7..112e3fce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4019=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4019=07-08

  Stats: 16 lines in 1 file changed: 0 ins; 10 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019

PR: https://git.openjdk.java.net/jdk/pull/4019

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Naoto Sato 
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

+1

-

PR: https://git.openjdk.java.net/jdk/pull/5063

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v8]

2021-08-11 Thread Andrew Haley 
On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath  wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures 
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES 
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   rewiew update

src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp line 1682:

> 1680: vpshufb(AAD_HASHx, AAD_HASHx, xmm24, Assembler::AVX_128bit);
> 1681: 
> 1682: // Compute #rounds for AES based on the length of the key array

Forget that, it's done everywhere. Deleted.

-

PR: https://git.openjdk.java.net/jdk/pull/4019

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v8]

2021-08-11 Thread Andrew Haley 
On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath  wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures 
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES 
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   rewiew update

src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp line 1682:

> 1680: vpshufb(AAD_HASHx, AAD_HASHx, xmm24, Assembler::AVX_128bit);
> 1681: 
> 1682: // Compute #rounds for AES based on the length of the key array

This is a bit of a hack. Wouldn't it make more sense to pass in the array oop, 
then derive both the length and the address of the base of the key array from 
the oop, rather than using a negative offset from the base address?

-

PR: https://git.openjdk.java.net/jdk/pull/4019

Re: JDK17 - Possible TLS issue.

2021-08-11 Thread Peter Firmstone 

谢谢johnsjiang(江莎)，

I set the property:

-Djdk.tls.acknowledgeCloseNotify=true.

Unfortunately the test is still failing on JDK17, although the output 
has changed and acknowledges the duplex close, so it appears something 
else is causing the connection to close early. Interestingly, there is a 
WARNING that the socket didn't close, followed by an ERROR, then 
FATAL(UNEXPECTED MESSAGE).


致以诚挚的问候Peter.

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug-ack-close-notify-true.txt

 [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) 
ConnectionManager.Reaper|2021-08-11 19:41:49.598 
AEST|SSLSocketImpl.java:572|duplex close of SSLSocket
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert message (

 [java] ActSys-err: "Alert": {
 [java] ActSys-err:   "level"  : "warning",
 [java] ActSys-err:   "description": "user_canceled"
 [java] ActSys-err: }
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) 
ConnectionManager.Reaper|2021-08-11 19:41:49.599 
AEST|SSLSocketImpl.java:1775|close the SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert message (

 [java] ActSys-err: "Alert": {
 [java] ActSys-err:   "level"  : "warning",
 [java] ActSys-err:   "description": "close_notify"
 [java] ActSys-err: }
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|ALL|A2|(JSK) mux 
writer|2021-08-11 19:41:49.599 AEST|SSLSocketImpl.java:1324|Closing 
output stream
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex close 
of SSLSocket
 [java] ActSys-err: javax.net.ssl|ALL|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1324|Closing 
output stream
 [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the 
SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex close 
of SSLSocket
 [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux 
writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the 
SSL connection (passive)
 [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux 
reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1129|Closing 
input stream
 [java] ActSys-err: javax.net.ssl|WARNING|C2|(JSK) mux 
writer|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:600|SSLSocket 
close failed. Debug info only. Exception details: (

 [java] ActSys-err: "throwable" : {
 [java] ActSys-err:   java.net.SocketException: Socket closed
 [java] ActSys-err:       at 
java.base/sun.nio.ch.NioSocketImpl.ensureOpenAndConnected(NioSocketImpl.java:165)
 [java] ActSys-err:       at 
java.base/sun.nio.ch.NioSocketImpl.available(NioSocketImpl.java:838)
 [java] ActSys-err:       at 
java.base/sun.nio.ch.NioSocketImpl$1.available(NioSocketImpl.java:807)
 [java] ActSys-err:       at 
java.base/java.net.Socket$SocketInputStream.available(Socket.java:970)
 [java] ActSys-err:       at 
java.base/sun.security.ssl.SSLSocketInputRecord.deplete(SSLSocketInputRecord.java:495)
 [java] ActSys-err:       at 
java.base/sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1785)
 [java] ActSys-err:       at 
java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:596)
 [java] ActSys-err:       at 
java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.close(SSLSocketImpl.java:1328)
 [java] ActSys-err:       at 
org.apache.river.jeri.internal.mux.StreamConnectionIO$2.close(StreamConnectionIO.java:427)
 [java] ActSys-err:       at 
org.apache.river.jeri.internal.mux.StreamConnectionIO$Writer.run(StreamConnectionIO.java:250)
 [java] ActSys-err:       at 
org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172)
 [java] ActSys-err:       at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
 [java] ActSys-err:       at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 [java] ActSys-err:       at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
 [java] ActSys-err:       at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 [java] ActSys-err:       at 
java.base/java.lang.Thread.run(Thread.java:833)}

 [java] ActSys-err:
 [java] ActSys-err: )
 [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux 
reader|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:1666|handling 
exception (

 [java] ActSys-err: "throwable" : {
 [java] ActSys-err:   java.net.SocketException: Socket closed
 [java] ActSys-err:       at

Re: JDK17 - Possible TLS issue.

2021-08-11 Thread 江莎 
+ security-dev

Hi Peter,
It looks both of file 1 and 5 contain that close_notify warning alert.
This point may be related to JDK-8208526: TLS 1.3 half-close and 
synchronization issues [1].

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

Best regards,
John Jiang

At 2021/8/11 PM 4:14, Peter Firmstone wrote:
> I'm testing on JDK17, having some issues communicating using TLS between 
> processes.
>
> With TLS disabled, the test passes on JDK17.
>
> The test passes using TLS on JDK 16 and earlier JDK versions.
>
> I've enabled TLS handshake debug on the output
>
>  1. 
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16-tls-handshake-debug.txt
>  2. 
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16.txt
>  3. 
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-disabled.txt
>  4. 
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-tls-handshake-debug.txt
>  5. 
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug2.txt
>
> There are 5 JVM instances created during this integration test and these 
> JVM's are communicating using network connections.  I have checked that 
> all JVM processes are running, it seems to be a communication issue.
>
> Using diff to compare files 1 and 5 above, it appears to be related to a 
> close notify in JDK17, on the (JSK) connection .
>
> Any suggestions?
>
> Thanks,
>
> Peter.
>
>   [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 
> 14:56:20.606 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive)
>   [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux writer|2021-08-11 
> 14:56:20.606 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket
>   [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux reader|2021-08-11 
> 14:56:20.606 AEST|SSLSocketImpl.java:1129|Closing input stream
>   [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux reader|2021-08-11 
> 14:56:20.607 AEST|SSLSocketImpl.java:1666|handling exception (
>   [java] ActSys-err: "throwable" : {
>   [java] ActSys-err:   java.net.SocketException: Socket closed
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248)
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327)
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350)
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803)
>   [java] ActSys-err:  at 
> java.base/java.net.Socket$SocketInputStream.read(Socket.java:966)
>   [java] ActSys-err:  at 
> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478)
>   [java] ActSys-err:  at 
> java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472)
>   [java] ActSys-err:  at 
> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)
>   [java] ActSys-err:  at 
> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455)
>   [java] ActSys-err:  at 
> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059)
>   [java] ActSys-err:  at 
> org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372)
>   [java] ActSys-err:  at 
> org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277)
>   [java] ActSys-err:  at 
> org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172)
>   [java] ActSys-err:  at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>   [java] ActSys-err:  at 
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   [java] ActSys-err:  at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>   [java] ActSys-err:  at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>   [java] ActSys-err:  at 
> java.base/java.lang.Thread.run(Thread.java:833)}
>   [java] ActSys-err:
>   [java] ActSys-err: )
>   [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux reader|2021-08-11 
> 14:56:20.607 AEST|TransportContext.java:363|Fatal (UNEXPECTED_MESSAGE): 
> Socket closed (
>   [java] ActSys-err: "throwable" : {
>   [java] ActSys-err:   java.net.SocketException: Socket closed
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248)
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327)
>   [java] ActSys-err:  at 
> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350)
>   [java] ActSys-err:  at 
>

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Daniel Fuchs 
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

>From my pure developer's perspective the proposed changes look good. If the 
>performance concerns are removed I'd say it looks good to me.

-

PR: https://git.openjdk.java.net/jdk/pull/5063