Re: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily
On 2016-01-08 16:34, Alan Bateman wrote: On 08/01/2016 14:41, Claes Redestad wrote: Hi, please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a targetted microbenchmark which explicitly generate and retrieve the schemeSpecificPart. Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ This looks okay to me. The only thing that I wonder about is the original code returning null when getRawSchemeSpecificPart is specified to never return null. Yes, I think that can't ever happen for any valid URI since during parse either schemeSpecificPart or path will be set to a non-null value. I propagated this confusion in one of the recent patches to be semantically identical with the legacy implementation. /Claes -Alan.
Re: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily
On 08/01/2016 14:41, Claes Redestad wrote: Hi, please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a targetted microbenchmark which explicitly generate and retrieve the schemeSpecificPart. Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ This looks okay to me. The only thing that I wonder about is the original code returning null when getRawSchemeSpecificPart is specified to never return null. -Alan.
RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily
Hi, please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a targetted microbenchmark which explicitly generate and retrieve the schemeSpecificPart. Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ Thanks! /Claes
Re: RFR 8133704/9, java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use
Hi Felix, On 08/01/16 08:36, Felix Yang wrote: Hi all, please review the fix for java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java Bug: https://bugs.openjdk.java.net/browse/JDK-8133704 Webrev: http://cr.openjdk.java.net/~xiaofeya/8133704/webrev.00 This looks good. I think 'port' can be final ( rather than volatile ), as can 'socket'. No need to regenerate the webrev. -Chris. It is using hard-coded port 4445 for the server side. This fix updates the test to use a port number that is automatically allocated. Thanks, Felix
RFR 8133704/9, java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use
Hi all, please review the fix for java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java Bug: https://bugs.openjdk.java.net/browse/JDK-8133704 Webrev: http://cr.openjdk.java.net/~xiaofeya/8133704/webrev.00 It is using hard-coded port 4445 for the server side. This fix updates the test to use a port number that is automatically allocated. Thanks, Felix