RFR: 8278302: [s390] Implement fast-path for ASCII-compatible CharsetEncoders [v2]
Lutz Schmidt
lucy at openjdk.java.net
Tue Jan 18 08:00:26 UTC 2022
On Mon, 17 Jan 2022 11:34:55 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:
>> This pull request contains the s390x variant of the fast-path for ASCII-compatible CharsetEncoders.
>>
>> The intrinsic implementation is pretty much similar to that of PPC64. Compared to the previously existing intrinsic implementation, changes to program logic are minimal. There is a new match rule for ascii strings and the bit mask used to detect invalid bits in the string characters is set depending on the target charset: 0xff00 for ISO, 0xff80 for ascii.
>>
>> **Request:** SAP does not maintain a full build and test infrastructure for s390x anymore. Could somebody please test this PR on s390x? At least build and tier1 tests, the more the better. Thank you!
>>
>> With my private testing (some microbenchmarks, some SPEC benchmarks) I could not find any issues. With the fast-path active I see a 2x, sometime 2.5x, improvement of CharsetEncodeDecode.encode.
>>
>> **Without the fast-path patch:**
>>
>> CharsetEncodeDecode.encode 16384 UTF-8 avgt 30 16.350 ± 0.067 us/op
>> CharsetEncodeDecode.encode 16384 BIG5 avgt 30 15.972 ± 0.136 us/op
>> CharsetEncodeDecode.encode 16384 ISO-8859-15 avgt 30 14.372 ± 0.110 us/op
>> CharsetEncodeDecode.encode 16384 ASCII avgt 30 14.287 ± 0.051 us/op
>>
>>
>> **With the fast-path patch:**
>>
>> CharsetEncodeDecode.encode 16384 UTF-8 avgt 30 6.833 ± 0.064 us/op
>> CharsetEncodeDecode.encode 16384 BIG5 avgt 30 8.195 ± 0.059 us/op
>> CharsetEncodeDecode.encode 16384 ISO-8859-15 avgt 30 6.387 ± 0.149 us/op
>> CharsetEncodeDecode.encode 16384 ASCII avgt 30 6.321 ± 0.049 us/op
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>
> 8278302: fix bug in us-ascii mask generation
Thank you for your comments, Claes!
As SAP has passed on responsibility for the s390 port, I would like to receive a "lead" review from the new maintainers. Then, I could recruit a "second opinion" from my direct colleagues.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6738
More information about the hotspot-compiler-dev
mailing list