RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]

[Claes Redestad]

On Wed, 30 Aug 2023 15:37:18 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution
>
> test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java line 180:
> 
>> 178:     @Benchmark
>> 179:     public void testEncodeUTF8(Blackhole bh) throws UnsupportedEncodingException {
>> 180:         for (String s : testStringsEncode) {
> 
> The consume is pretty cheap with compiler assisted blackholes, but can still overall be too noisy with small 's'
> 
> Worth running perfasm and see what it says and/or reading out of the encoded value and extract some property to accumulate in the for loop (sum.od length?) and see if is less costy/noisy.
> 
> Another point instead is related loop unrolling/strip mining; safepoint polls can create additional random noise depending how much loop unrolling is excercized (Vs the cost of encoding): it worth to enforce a specific unrolling level or disabling it as a whole, too, to get more stable results.

I think these are all valid concerns and it's a worthwhile endeavor to discuss and try and improve how we benchmark loops (or more specifically variable inputs). However I think this is out of scope for this improvement - which is mainly about correctness of data and making sure we're testing the right thing - and ought to be discussed and experimented with separately. If you don't strongly disagree I will integrate this so we can move ahead with other work in this area (#15354 for starters)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1311337979