Re: RFR: 8268960: com/sun/net/httpserver/Headers.java: Ensure mutators normalize keys and disallow null for keys and values [v2]

2021-06-21 Thread Julia Boes
> `com.sun.net.httpserver.Headers` normalizes its keys to adhere to the 
> following format: First character uppercase, all other characters lowercase, 
> for example `"foo" -> "Foo"`. This behaviour is not consistent across the 
> mutator methods of the class, in particular `putAll()` and `replaceAll()` do 
> not apply normalization.
> 
> The suggested fix is to update the implementation of `putAll()` and to add an 
> implementation of of the java.util.Map default method `replaceAll()`. While 
> here, we can improve `equals()` by adding a type check and add a `toString()` 
> implementation.
> 
> Additionally,  the Headers class is updated to disallow null values for keys 
> and values.

Julia Boes has updated the pull request incrementally with two additional 
commits since the last revision:

 - disallow null for keys and values
 - disallow null for keys and values

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4528/files
  - new: https://git.openjdk.java.net/jdk/pull/4528/files/ee9cb576..6301bc1f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4528=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4528=00-01

  Stats: 249 lines in 2 files changed: 185 ins; 20 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4528/head:pull/4528

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


Re: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v4]

2021-06-21 Thread Michael McMahon
On Thu, 17 Jun 2021 16:23:08 GMT, Mahendra Chhipa 
 wrote:

>> …HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests
>
> Mahendra Chhipa has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 89:

> 87: return hostaddr + ":" + server.getAddress().getPort();
> 88: }
> 89: public void handle(HttpExchange req) throws IOException {

Minor style point. I would put a blank line between the two methods.

test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 170:

> 168: req.sendResponseHeaders(404, -1);
> 169: break;
> 170: }

Probably should add a call to "req.close()" at the end of the method.

test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 366:

> 364: TrustManagerFactory tmf = 
> TrustManagerFactory.getInstance("SunX509");
> 365: tmf.init(ts);
> 366: 

Could SimpleSSLContext be used here instead of manually writing this code? Same 
for other tests with same pattern.

-

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


Re: RFR: 8267840: Improve URLStreamHandler.parseURL()

2021-06-21 Thread Daniel Fuchs
On Fri, 18 Jun 2021 07:31:14 GMT, Сергей Цыпанов 
 wrote:

> There is an optimization opportunity for the widespread use-case when a 
> resource is read from classpath using 
> `getClass().getClassLoader().getResource()` or 
> `getClass().getClassLoader().getResourceAsStream()`.
> 
> Pay attention to lines starting from 261. In case I run something like
> 
> var props = 
> getClass().getClassLoader().getResource("/application.properties");
> 
> I get into the if-else block starting from 251 and here 'separator' variable 
> is an empty String. In this case we can skip 'separator' from concatenation 
> chain and use `String.concat()` as there are only two items concatenated.
> 
> In the opposite case `separator` variable is `"/"` and at the same time `ind` 
> variable is `-1`. This means that expression `path.substring(0, ind + 1)` 
> always returns an empty String and again can be excluded from concatenation 
> chain allowing usage of `String.concat()` which allows to dodge utilization 
> of `StringBuilder` (here `StringConcatFactory` is not available, see 
> https://github.com/openjdk/jdk/pull/3627)
> 
> In the next else-block, starting from 274, again, `String.concat()` is 
> applicable.
> 
> In another if-else block, starting from 277, when id is 0 again 
> path.substring(0, ind) returns empty String making concatenation pointless 
> and avoidable.
> 
> There are also some other minor clean-ups possible regarding constant 
> conditions (lines 252 and 161).
> 
> The change allows to reduce significantly resource look-up costs for a very 
> wide-spread case:
> 
> @State(Scope.Benchmark)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassGetResourceBenchmark {
> private final Class clazz = getClass();
> 
> @Benchmark
> public URL getResource() {
> return clazz.getResource("/application.properties");
> }
> }
> 
> The change allows to reduce memory consumption significantly:
> 
> before
> 
> Benchmark   Mode  
> Cnt Score Error   Units
> ClassGetResourceBenchmark.getResource   avgt  
> 100  1649,367 ±   5,904   ns/op
> ClassGetResourceBenchmark.getResource:·gc.alloc.rateavgt  
> 100   619,204 ±   2,413  MB/sec
> ClassGetResourceBenchmark.getResource:·gc.alloc.rate.norm   avgt  
> 100  1339,232 ±   4,909B/op
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Eden_Space   avgt  
> 100   627,192 ±  74,972  MB/sec
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Eden_Space.norm  avgt  
> 100  1356,681 ± 162,354B/op
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Survivor_Space   avgt  
> 100 0,119 ±   0,100  MB/sec
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Survivor_Space.norm  avgt  
> 100 0,257 ±   0,217B/op
> ClassGetResourceBenchmark.getResource:·gc.count avgt  
> 100   128,000counts
> ClassGetResourceBenchmark.getResource:·gc.time  avgt  
> 100   227,000ms
> 
> after
> 
> Benchmark   Mode  
> Cnt Score Error   Units
> ClassGetResourceBenchmark.getResource   avgt  
> 100  1599,948 ±   4,115   ns/op
> ClassGetResourceBenchmark.getResource:·gc.alloc.rateavgt  
> 100   358,434 ±   0,922  MB/sec
> ClassGetResourceBenchmark.getResource:·gc.alloc.rate.norm   avgt  
> 100   752,016 ±   0,004B/op
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Eden_Space   avgt  
> 100   342,778 ±  76,490  MB/sec
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Eden_Space.norm  avgt  
> 100   719,264 ± 160,513B/op
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Survivor_Space   avgt  
> 100 0,008 ±   0,005  MB/sec
> ClassGetResourceBenchmark.getResource:·gc.churn.G1_Survivor_Space.norm  avgt  
> 100 0,017 ±   0,010B/op
> ClassGetResourceBenchmark.getResource:·gc.count avgt  
> 10070,000counts
> ClassGetResourceBenchmark.getResource:·gc.time  avgt  
> 100   151,000ms

Hi Sergey,

The logics seems correct - but what test did you run? have you run tier1 and 
tier2?

best regards,
-- daniel

-

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