RFR: JDK-8224963: Char-Byte Performance Enhancement

[Eric Caspole]

Hi Adam,
It would be helpful if you could make a JMH to exercise your 
optimization webrev and add it to the webrev. Or, if you find one in the 
existing collection in the jdk repo[1] just point out which one it is.
Thanks,
Eric

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/bda9984d8ee4/test/micro/org/openjdk/bench


On 5/29/19 08:22, Vladimir Ivanov wrote:
> Hi Adam,
> 
> The bug mentions ~6x improvement in throughput. Are there have any 
> microbenchmarks you can share which demonstrate that? That would greatly 
> simplify the analysis of changes you propose.
> 
> Also, if you can elaborate on what optimization opportunities C2 misses 
> in original code, please, do.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 29/05/2019 12:45, Adam Farley8 wrote:
>> Hi All,
>>
>> Could someone familiar with the Hotspot JIT please review and opine on 
>> the below?
>>
>> The Char-Byte encoding/decoding methods inside some of the sun.nio.cs 
>> classes
>> (such as US_ASCII) see a lot of use, and OpenJDK on the OpenJ9 VM 
>> seems to
>> do this a lot faster.
>>
>> Is it possible to achieve a similar improvement on OpenJDK on Hotspot by
>> tweaking the CL code to match Hotspot JIT compiler idioms, or by 
>> introducing
>> a method name for the HS JIT to match on?
>>
>> An example of these changes to US_ASCII.java is linked below. No 
>> OpenJ9 code
>> is included in the work item or the webrev, to avoid contamination.
>>
>> Work item: https://bugs.openjdk.java.net/browse/JDK-8224963
>>
>> Example Webrev: _http://cr.openjdk.java.net/~afarley/8224963/webrev/_
>>
>> Best Regards
>>
>> Adam Farley
>> IBM Runtimes
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU