RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

[Claes Redestad]

Indeed I did...

Oh well, another day...

/Claes

On 2017-05-26 20:12, Martin Buchholz wrote:
> I think you've fallen into the trap of confusing UTF-8 and Modified 
> UTF-8.
>
> The prevailing pattern seems to be to write an entirely new UTF-8 
> implementation for any performance problem involving UTF-8 :-(  e.g. 
> in StringCoding.
>
> On Fri, May 26, 2017 at 10:58 AM, Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     Hi,
>
>     various JNI methods in the JDK converts from java Strings to native
>     encoding using JNI_GetStringPlatformChars, which has long standing
>     optimizations for dealing with various default charsets.
>
>     However, UTF-8 is missing, which is a shame since we have optimized
>     utilities for converting from a String to UTF-8-encoded char* (since
>     this is the native encoding used by HotSpot internally).
>
>     Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/
>     <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.00/>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8181147
>     <https://bugs.openjdk.java.net/browse/JDK-8181147>
>
>     Allocation rate can drop significantly in microbenchmarks, e.g., -60%
>     in a trivial micro doing new File(path).isHidden() (along with a 30%
>     throughput win), while the rate of native allocation with is net
>     neutral.
>
>     (I think the code for FAST_646_US could be removed, since Solaris 8
>     support was dropped in JDK 8, but that's a separate RFE...)
>
>     Thanks!
>
>     /Claes
>
>