RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths

Claes Redestad redestad at openjdk.java.net
Tue Feb 16 13:48:43 UTC 2021


On Mon, 15 Feb 2021 20:34:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
> 
> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.

Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617

It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication.

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

PR: https://git.openjdk.java.net/jdk/pull/2574


More information about the core-libs-dev mailing list