RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

[Chris Hegarty]

On 27 Jan 2016, at 17:24, Claes Redestad <claes.redestad at oracle.com> wrote:

> 
> On 2016-01-18 17:20, Claes Redestad wrote:
>> 
>> The ability for URLStreamHandler implementations to override the parseURL method seem to prevent this improvement unless we only do this for a subset of known, well-behaved URLStreamHandlers, which likely defeat the optimization by adding complexity. 
> 
> Right, the fast path can only be safely used for the non-overrideable handlers (jrt and file), but turns out we can make that work without penalizing other cases:
> 
> http://cr.openjdk.java.net/~redestad/8147462/webrev.04/

This looks fine Claes.

Maybe just a comment on the fact that character based comparison is
being used for perf reasons.

In an older version of the webrev, there was an updated to an existing test, 
test/java/net/URI/URItoURLTest.java. I assume this was just mistakenly
omitted from the latest version?

-Chris.

> Relevant micros[1] show that this brings a benefit to file/jrt, even when mixed with slow path URIs, while micros only hitting slow path (newHttpURIToURL, opaqueURIToURL) doesn't regress:
> 
> Before:
> Benchmark                 Mode  Cnt    Score    Error Units
> URIBench.mixedURIToURL    avgt   30  463.748 ± 14.445 ns/op
> URIBench.newHttpURIToURL  avgt   30  441.497 ± 20.173 ns/op
> URIBench.newURIToURL      avgt   30  227.106 ±  9.055 ns/op
> URIBench.opaqueURIToURL   avgt   30  320.904 ± 13.232 ns/op
> 
> Patched:
> Benchmark                 Mode  Cnt    Score    Error Units
> URIBench.mixedURIToURL    avgt   30  441.773 ± 16.530 ns/op
> URIBench.newHttpURIToURL  avgt   30  433.946 ± 18.569 ns/op
> URIBench.newURIToURL      avgt   30  147.379 ±  6.349 ns/op
> URIBench.opaqueURIToURL   avgt   30  316.632 ± 12.940 ns/op
> 
> /Claes
> 
> [1] http://cr.openjdk.java.net/~redestad/8147462/URIBench.java