RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8
claes.redestad at oracle.com
Fri May 26 18:33:42 UTC 2017
Indeed I did...
Oh well, another day...
On 2017-05-26 20:12, Martin Buchholz wrote:
> I think you've fallen into the trap of confusing UTF-8 and Modified
> 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:
> 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/
> Bug: 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
> (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...)
More information about the core-libs-dev